Computing stuff tied to the physical world

RF compatibility options

Let’s define the playing field first, and all the associated terminology:

  • Classic packets are the ones understood by the RF12 driver in JeeLib
  • Native packets are built into RFM69 hardware and the RF69 driver in Embello
  • RFM12 is a HopeRF wireless module, with limited FIFO & logic (one B variant)
  • RFM69 is the newer HopeRF module (there are W, CW, and HW variants)
  • RF12 is the driver in JeeLib for Arduino IDE use, supporting classic packets
  • RF69 is a slightly different API supporting the RFM69 in native mode
  • Arduino is the name of the IDE used to build/upload JeeLib-based code
  • Make is the Unix-style mechanism to build/upload Embello-based code
  • AVR is the architecture of ATmega and ATtiny chips made by Atmel
  • ARM is the architecture of NXP’s LPC8xx series and many other vendors

And to elaborate a bit more on this:

  • Classic vs Native refers to the packet format traveling through the air
  • RFM12 vs RFM69 refers to different wireless radio hardware modules
  • RF12 vs RF69 refers to different software and their slightly different API’s
  • Arduino vs Make refers to the cross-build + upload environments
  • AVR vs ARM refers to the different ┬ÁC architectures (and 8- vs 32-bit)

That’s five pairs of variations, for a theoretical 32 different build and usage combinations! Not all of them make sense, and fewer still need to be implemented for inter-operability.

The most widely used setup is currently (because it was the first available on JeeNodes):

  • Classic + RFM12 + RF12 + Arduino + AVR

While the most recent developments at JeeLabs have focused on this configuration:

  • Native + RFM69 + RF69 + Make + ARM

In other words: it couldn’t be more different and these two cannot inter-operate as is.


This configuration uses “#define RF69_COMPAT 1” and can be characterised as:

  • Classic + RFM69 + RF12 + Arduino + AVR

It’s what allows an RFM69-based node to play nice in an RFM12/RF12-type network.

On Raspberry Pi

Recent developments have made it possible to introduce a third platform, i.e. Linux running on Raspberry Pi’s (any model) or the mostly-header-compatible Odroid C1.

Though omitted from the above list of terms to avoid confusion, it could be described as:

  • Native + RFM69 + RF69 + Linux-make + RasPi

This implementation is designed to be used with the RasPi RF board.

Long term trend

Given some of the new features offered by the RFM69 in native mode, it’s safe to assume that in the long run, the following configurations will become mainstream at JeeLabs:

  • Native + RFM69 + RF69 + some-build-system + some-architecture

What this means, is that “on the air”, the NATIVE packet format will at some point start to dominate. And while we could easily set up our environment to support native and classic packets alongside each other – using a different frequency or net group or both, with two central nodes running in parallel – this wouldn’t be the most convenient setup, long term.

A much better strategy will be to just bite the bullet and make everything work in native packet format. Then we could mix and match, old and new, RFM12’s and RFM69’s, and still be able to treat the entire wireless network as a single one.

This is precisely what the upcoming two articles intend to describe.

Using RFM69 w/ Arduino

Luckily, the new RF69 driver is extremely portable. It started out on LPC8xx ARM chips, but has been extended to run under Linux as well – using a simple “RasPi RF” board. The next article in this series will show that it can also be used in the Arduino environment:

  • Native + RFM69 + RF69 + Arduino + AVR

A new “RF12_COMPAT” option

But the most interesting option perhaps, is to bring the RFM12 into the future with a modification to the RF12 driver to make it work with native packets (keeping its API):

  • Native + RFM12 + RF12 + Arduino + AVR

This could in fact be called “forward compatibility”: an RFM12 can be made to act as if it were a more recently produced RFM69. Because of this, an installed base of RFM12’s need not prevent progress and the use of the more advanced RFM69’s in the rest of the network.

There are trade-offs, of course. Perhaps the most important one is that the RFM69’s AES encryption engine is not available on the RFM12. But even this is not a hard restriction: in principle, AES could be implemented in software in a future extension of the RF12 driver.

Stay tuned for these two exciting new options…

[Back to article index]