A Simple RF Protocol (or, what is the point of ZigBee?)

I’m going to start by admitting that this isn’t going to be a tirade of abuse against the oddly named 802.15.4-based wireless tech, but rather a request for comments on an open, lightweight alternative, particularly for low-cost sub-GHz applications.  I know what the point of ZigBee is, and the ability to form into self-organising mesh networks is an obvious advantage for large scale industrial automation, but for domestic applications it feels like overkill.

The industry is apparently thinking along the same lines, because the vast majority of DIY Home Automation (HA) stuff on the market in the UK at least is using proprietary sub-GHz like LightwaveRF.  The driver here is probably cost, but it is my view that the lack of interoperability that this leads to is holding back the mass-market acceptance of HA, and is unnecessary.

What I am looking for is a simple, open (as in freely available, properly documented, royalty free) standard for sub-GHz RF that could be implemented on the cheapest of radios in minimal code space.  I am aware of MQTT-S, although even that looks too complicated for simple sensor/actuator applications, and it doesn’t define the lower layers, instead running on top of something like ZigBee or 6LoWPAN.

Some outline requirements:

  • Both master/slave and peer-to-peer networks should be supported.  Meshing need not be ruled out, but is not a key design aim.
  • Security should be a primary design criterion – most proprietary protocols seem to be wide open.
  • The use of IP on the air interface should not be considered – bridging to IP networks is a job for  a central controller/bridge rather than pushing this complexity (read cost) out to every single node.
  • Battery powered nodes must be supported, e.g. discontinuous receive/timeslot techniques.
  • Unidirectional nodes must be supported for extreme cost-sensitive applications.
  • Obscure modulation schemes must be avoided to maximise the range of available radios.

An initial implementation would aim to support SiLabs EzRadio and EzRadioPro, which covers HopeRF RFM12/22/23 modules which are all in common use.

I am keen to hear from anyone with an interest in this area, particularly if there is something filling this need that I have missed.  I am also particularly interested in others’ views on the complexity of existing solutions – perhaps I am being over-sensitive!


11 thoughts on “A Simple RF Protocol (or, what is the point of ZigBee?)

  1. Mike Post author

    I’ve got an RFM23 (Si4431) designed-in to the sensors I am working on, but I’ve used CC1100 in the past so I’m familiar with the TI parts. They are quite similar. I suppose it might be worth looking at the likes of SimpliciTI, or the equivalent stacks from other vendors, but I’m really keen on the idea of promoting interoperability for this so it would be nice to come up with a fully open spec if one doesn’t exist already. Of course interoperability isn’t much use if no one else is interested, but I am hopeful!

    I was already keeping half an eye on some of your Sensemote stuff having come across it when looking into MQTT. I’ll take a closer look at the sensor side of it.


  2. Pingback: All-Outdoor Radios Part II: Three Ways to Choose the Right ODR « AVIAT NETWORKS: Official Wireless Transmission Blog

  3. Felix

    Hey Mike, I share the interest in a small footprint stack that would satisfy the requirements you mentioned. I’be been working with RFM12B for some time and even came up with my own version of a library for it (see website); I’m looking at RFM69W as an alternative due to rumors of RFM12B’s EOL – although there’s no library for it that I know of yet. But the specs on the RFM69W look real promising… 13dbm max TX power (vs 0dbm on the RFM12B).

  4. Mike Post author

    Hi Felix,

    I am actually awaiting samples of the RFM69W and will probably switch to those from RFM23B if it works out. The new modules have similar capabilities to the RFM23B, so the only potential problem will be minimum supply voltage, which at the 2.4V given in the datasheet is a bit high for battery powered nodes. However, the underlying chip also comes in a low-power version that goes down to 1.8V and would still meet the spec of the RFM69W, so I am hopeful that they used that in the non-H version of the module.

    I expect to start working on a protocol in the next few weeks, aiming for some amount of interoperability between at least RFM23B, RFM69W and probably Ciseco SRF. Crypto and authentication will be built in, which the RFM69W and SRF would be good at. If you are interested in collaborating I’ll get in touch once I get started?


  5. Felix

    Sure thing, I’m very interested, please let me know when you start work on a lib – I got some RFM69W samples already (I like them already) but have been super busy trying to keep up with my blog and store so I haven’t played with them yet – mostly because I couldn’t find AVR code for it and was planning on starting work on a lib myself. However it seems like a more complex radio than the RFM12B which was rather simple to interact with.

  6. Mike

    It’s good to see some current work on this. I’ve been wanting to use RFM12B for some wireless thermostat control (and other stuff). I would be very interested in your sensor nodes and the protocol that you come up with.

  7. Pavlos

    Hello Mike,

    Came across your blog/website through some google searches. I am coming to RF from a completely different angle and I am mostly interested in the design/implementation of a robust broadcast only protocol. The emphasis will be on the error correction design/implementation under severe noise conditions. Overall I am targeting an even simpler protocol (perhaps not sufficient for the purposes you define here) so I am naturally interested in your work simple RF protocols. Please keep me posted if not too much trouble.

  8. Mike Post author

    Will do, although this work has still not floated to the top of my project list unfortunately.

    I’d be interested to know what your application and requirements are. If you need really simple error correction could you just break the message into blocks and send them repeatedly, to allow the receiver to build up the complete message over time?

  9. Pavlos

    Thanks Mike,

    I have a background interest in information theory and I am interested to see how far one can extend (hopefully considerably) the range of very low power RF transceivers at the expense of bandwidth (other things being equal; antenna/position etc) especially in high noise ‘RF hostile’ environments.

    Under high noise environments your suggestion (essentially a repetition code) may very well end up being the optimal (in terms of complexity/performance ratio) but in general one can employ much more powerful/efficient error correcting codes these days. I do not know enough yet which is why I am keen to get access to some real field data.

    Good luck with your projects

Leave a Reply

Your email address will not be published. Required fields are marked *