There’s a new wireless radio driver in town for the JeeNode Zero and other µC boards running Mecrisp Forth. It’s called RF73 but it is in fact intended to be used with the RFM70, RFM73, and RFM75. These are low-cost 2.4 GHz wireless modules made by HopeRF, the same supplier as for RFM12 and RFM69. Thes modules are derived from designs created by Silicon Labs.
The current rf73.fs code is still very young, and not quite ready for general use. Part of this is due to the fact that the RFM7x’s use a slightly different routing model: each unit has the ability to receive data on 6 specific addresses, and is meant to be used in a 1:6 mesh topology. What this means is that the RF12/69’s idea of node IDs and net groups is slightly different. It’s going to take a little more head scratching to map the RF73 to a reasonably generic model and API.
The RFM7x’s can receive packets up to at most 32 bytes, but they do have 3 buffers, so more packets can be in-transit as the driver works its way through the send and receive data. This is important because the maximum data rate of these modules is a whopping 2 Mb/sec: you can send and receive a lot of data with these, plenty for audio and text streams over 115,200 baud.
The flip side (yes, everything is a trade-off), is that the range of the RFM7x is only 5..10 meter, especially indoor and when there are walls involved. Fine for a room, not for an entire house.
Here is the setup which was used to develop this first iteration of the RF73 driver:
(these are older “v1” versions of the JeeNode Zero, with each an RFM70 mounted on them)
The Quad Serial whown above is a 4-port FTDI interface, with support for the DTR + RTS pins needed to reset and re-flash attached µC boards. A custom-made plug-in board converts the header pinouts to four standard 6-pin FTDI ports, as used by JeeNodes and many others.
Writing a wireless driver from scratch and debugging it can be a challenge: you have to figure out which side of the RF link is not working. Without a Multi-Domain Oscilloscope, it’s hard to tell what’s going on (even that high-end scope is not capable of capturing 2.4 GHz, by the way!).
There already was an older driver written in C++, with a test program for two LPC824-based boards, and they were happily exchanging test messages. In that context, with known valid packets flying around, the first coding task was simply a matter of picking up those messages.
After that, things went fairly smoothly, leading to a 138-line driver written in Forth, which can send and receive individual 1..32-byte packets. Almost half of that code is for initialisation.
The RFM7x series has one very interesting feature: there’s an optional “auto-ack” mechanism, whereby the receiver immediately sends an ACK on proper reception, with the sender timing out and retrying a few times if it doesn’t see that ACK. Very much like the Easy Transmission mechanism implemented in software for the RF12 driver in JeeLib, but now all in hardware.
The performance with a 2 MB/s data rate and optional fast ACKs is quite impressive:
- sending a 10-byte packet without ACK takes some 300 µS
- sending that same packet and waiting for the ACK takes ≈ 500 µs
With ACKs, you get a reliable communication channel, since transmission errors lead to retries and much lower error rates. There will be a delay with retries, up to 60 ms with the maximum 4 ms timeout using 15 retries. Failures are still possible, of course - just considerably less likely.
The RFM7x modules are very similar to the nRF24L01 (and maybe even compatible on-air?). Both have been widely used in RF-based wireless audio headsets, for example.
So there you go: a new choice, for when you need more speed and can live with a lower range. And the JeeNode Zero already includes the proper footprint for these RFM7x’s on its PCB.