Computing stuff tied to the physical world

Flashback – RFM12B wireless

In AVR, Hardware, Software on Sep 29, 2013 at 00:01

After the ATmega µC, the second fascinating discovery in 2008 was the availability of very low-cost wireless modules, powerful enough to get some information across the house:

wireless-modules

It would take another few months until I settled on the RFM12B wireless module by HopeRF, but the uses were quickly falling into place – I had always wanted to track the energy consumption in the house, to try and identify the main energy consumers. That knowledge might then help reduce our yearly energy consumption – either by making changes to the house, or – as it turned out – by simply adjusting our behaviour a bit.

Here is the mouse trap which collected energy metering data at JeeLabs for several years:

mousetrap

This is also when I found Modern Devices’s Real Bare Bone Board Arduino clone by Paul Badger – all the good stuff of an Arduino, without the per-board FTDI interface, and with a much smaller form factor.

Yet another month would pass to get a decent interrupt-driven driver working, and some more tweaks to make transmission interrupt-based as well. The advantage of such as design is that you get the benefits of a multi-tasking setup without all the overhead: the RF12 driver does all its time-critical work in the background, while the main loop() can continue to use delay() calls and blocking I/O (including serial port transmission).

In February 2009, I started installing the RF12demo code on each ATmega, as a quick way to test and try out wireless. As it turned out, that sketch has become quite useful as central receiving node, even “in production” – and I still use it as interface for HouseMon.

In April 2009, a small but important change was made to the packet format, allowing more robust use of multiple netgroups. Without this change, a bit error in the netgroup byte will alter the packet in a way which is not caught by the CRC checksum, making it a valid packet in another netgroup. This is no big deal if you only use a single netgroup, but will make a difference when multiple netgroups are in use in the same area.

Apart from this change, the RF12 driver and the RFM12B modules have been remarkably reliable, with many nodes here communicating for years on end without a single hick-up.

I still find it pretty amazing that simple low-power wireless networking is available at such a low cost, with very limited software involvement, and suitable for so many low-speed data collection and signalling uses in and around the house. To me, wireless continues to feel like magic after all these years: things happening instantly and invisibly across a distance, using physical properties which we cannot sense or detect…

  1. I am exploring RF’s for wireless home sensors. Right now I’m looking at the nRF24L01. Given your research, do you have advice on an RF choice for home sensors? Thank you very much (and for your posts).

    • Well, the range of 2.4 GHz radios is less than 433/868/915 MHz radios for the same energy level (more signal attenuation). You can probably get from one room to the next just fine, but a few rooms or down the hallway might be harder. I haven’t tried the nRF24L01 myself though, so that’s just guessing on my part…

  2. RFM12B appears to be declared end-of-life. Are you looking at replacing it? Are there compatible alternatives, is it still worth “investing” in RFM12B devices? Planning to do some wireless home automation but a bit concerned about building on something that might be difficult to interface with later on. I’m new to this area so might be that I’m missing something obvious.

    • I’m exploring options – my plan is currently to take one of the alternative chips and make it work compatibly, so that a wireless network with mixed hardware continues to work. Having said that, the supply of RFM12B modules is still fine, and so is the current stock level in the shop.

  3. It’s not the Vendor declaring end-of-life for the RFM12B.

    All chip families do have some natural life cycle based on process/price point or similar issues. I guess the right approach is to abstract the functions via a library (sound familiar?) to allow future flexibility in choosing the hardware layer.

Comments are closed.