Computing stuff tied to the physical world

Classic vs native packets

There are so many different wireless radio modules and different packet protocols, that it’s easy to get lost. In the context of JeeLabs, the radio modules currently in use are the RFM12 and RFM69, both produced by HopeRF.

At some point, a rumour started echoing on internet that the RFM12 was being abandoned and replaced by the RFM69, but after over a year it is now clear that both will continue to be produced for a long time to come – if only because there is plenty of demand.

The use cases for both types are quite similar, i.e. being able to send and receive short packets on the 433, 868, or 915 MHz bands, but there are also some major differences:

  • the RFM12 module can only store 1..2 bytes in its FIFO, meaning that data must be read and written at a fairly high rate (within 200 µs with the default JeeLib settings)

  • the RFM69 can store an entire packet, so there are no hard real-time timing requirements, other than to clear the FIFO for the next reception or transmission

  • the RFM69 is more sophisticated, in that many settings are more detailed – and it supports more modulation-, synchronisation-, and packet-formatting modes

  • the RFM69 supports hardware encryption, based on 128-bit AES, and data whitening, which helps better recover the data rate clock in some edge cases

  • the RFM69’s receiver is more sensitive, and its transmitter can be more powerful, leading to a potentially much larger range with the same current consumption

All in all, the RFM69 can indeed be considered a next-generation design – although the RFM12 continues to be just fine for lots of home-monitoring and -automation scenarios. But there is one tricky difference: the on-air packet format / protocol of the RF12 driver (implemented by software in JeeLib) is not the same as the format in the RFM69 hardware-based packet engine:

The “CLASSIC” packet layout used by the RF12 driver is:

  • preamble, SYNC bytes, header byte, packet length, payload, CRC bytes

The “NATIVE” packet layout used by the RFM69 hardware is:

  • preamble, SYNC bytes, packet length, payload, CRC bytes

We can easily designate the first byte of the payload to act as header byte, but we cannot change the order of the length and header bytes. Furthermore, the length differs: on the RFM12, it does not include the header byte, whereas on the RFM69 it does.

There are other differences in specific bits and in how the CRC is calculated, but the main difference preventing trivial inter-operability is really that header-/length-byte order.

Obviously, senders and receivers need to agree on the protocol used.

So far, the code in JeeLib for both RFM12 and RFM69 has been aimed at implementing the classic packet format everywhere. By adding the following define into our code:

#define RF69_COMPAT 1

… we have the option to use an RFM69 module, while keeping the classic packet layout. This effectively makes the RFM69 backwards compatible: it acts like an older RFM12.

But there is a price to pay, because we can’t use some of the newer features of the RFM69 this way, in particular full-packet buffering and hardware-based AES encryption.

On the ARM platform, we’ve been using a new native “RF69” driver (in rf69.h) which is considerably simpler (less code), doesn’t need fast interrupt support, and offers optional encryption. But while doing so, we’ve also introduced a serious incompatibility.

Now seems like a good time to re-investigate all the different options and combinations…

[Back to article index]