![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
For the last few months I was not working much on the SmartGarden project. It is winter now, and I have some time before next watering season to finish up all updates.
However last few weekends I had some time and used this opportunity to work on v1.6. SG v1.6 adds the ability to use RFM69 RF module instead of XBee for communication.
The advantage of RFM69 is two-fold - first of all it is way cheaper than XBee 900 modules, but at the same time RFM69 (especially its high-power version) are promising much better range, comparable with latest XBee HP modules at a small fraction of the cost. Also RFM69 is available as a native option on Moteino Mega, which reduces complexity and device size - it becomes possible to fit whole controller (MCU unit as well as RF module) into single small module.
All this is goodness, but the downside is that RFM69 is a simple, low-level transmitter. It does not have all the smarts and processing power of XBee, since unlike XBee it does not have onboard processor. RFM69 is a plain basic transmitter/receiver module, and it must rely on the host MCU for smarts.
Another complication for me was the need to restructure SmartGarden Remote Protocol stack to allow multiple types of RF transport. In the initial version I tried to separate out actual RProtocol implementation from underlying transport, but few unintended dependencies creep in, and I need to clean it up.
I did most of that work over the last few weekends. Now RProtocol is reasonably cleanly separated from the underlying transport, this allows using either XBee or RFM69 (and in theory even both simultaneously), and I also wrote suitable transport driver for RFM69. The driver relies on RFM69 library from LowPowerLab, but I had to add few workarounds to get it all going.
The main thing was to add support for polling mode. Normally RFM69 library relies on interrupts to handle incoming packets, but I found that in the SG Master controller it conflicts with SD card and Ethernet - all of them are sharing SPI bus, and RF module can break in a middle of SPI transfer of Ethernet or SD card. I could've disable interrupts to block RF while Ethernet or SD card are active, but it would defeat the purpose of the interrupt - I might as well pick up RF data in polling loop.
Also despite of the interrupt-driven incoming packets handling in RFM69, it relies on polling to send ACK and handle other duties, and it cannot really do much without polling. In the view of that I just added polling-only mode to RFM69 library and it seems to work fine. The only negative of this approach is reduced bufferisation of the receive path - you have to pick up incoming data sufficiently quickly before next packet arrives (with interrupts support you have one packet buffer). But since senders are using retries and generally expected activity rate on the channel is low, this is probably OK.
As usual, the code is available in the SmartGarden GitHub repo.
I tried few simple range tests with SG controller on RFM69 915MHz link, and it seems to work pretty well. I'm getting about 80db signal at few hundred yards distance, on a small 1/4 wave antennae, and in wet weather. Will try actual max distance I need to achieve in a few weeks.
One remaining bit - I need to add protection from packets duplication.LowPortLab RFM69 library is good and simple, but it does not have any protection from packets duplication on retries. For some of the requests it is kind of OK to receive two of these, but in some cases it is undesirable. I can add smarts to handle it in the SG driver for RFM69. XBee handles it in the XBee itself, with RFM69 you need to do it in the main MCU.
However last few weekends I had some time and used this opportunity to work on v1.6. SG v1.6 adds the ability to use RFM69 RF module instead of XBee for communication.
The advantage of RFM69 is two-fold - first of all it is way cheaper than XBee 900 modules, but at the same time RFM69 (especially its high-power version) are promising much better range, comparable with latest XBee HP modules at a small fraction of the cost. Also RFM69 is available as a native option on Moteino Mega, which reduces complexity and device size - it becomes possible to fit whole controller (MCU unit as well as RF module) into single small module.
All this is goodness, but the downside is that RFM69 is a simple, low-level transmitter. It does not have all the smarts and processing power of XBee, since unlike XBee it does not have onboard processor. RFM69 is a plain basic transmitter/receiver module, and it must rely on the host MCU for smarts.
Another complication for me was the need to restructure SmartGarden Remote Protocol stack to allow multiple types of RF transport. In the initial version I tried to separate out actual RProtocol implementation from underlying transport, but few unintended dependencies creep in, and I need to clean it up.
I did most of that work over the last few weekends. Now RProtocol is reasonably cleanly separated from the underlying transport, this allows using either XBee or RFM69 (and in theory even both simultaneously), and I also wrote suitable transport driver for RFM69. The driver relies on RFM69 library from LowPowerLab, but I had to add few workarounds to get it all going.
The main thing was to add support for polling mode. Normally RFM69 library relies on interrupts to handle incoming packets, but I found that in the SG Master controller it conflicts with SD card and Ethernet - all of them are sharing SPI bus, and RF module can break in a middle of SPI transfer of Ethernet or SD card. I could've disable interrupts to block RF while Ethernet or SD card are active, but it would defeat the purpose of the interrupt - I might as well pick up RF data in polling loop.
Also despite of the interrupt-driven incoming packets handling in RFM69, it relies on polling to send ACK and handle other duties, and it cannot really do much without polling. In the view of that I just added polling-only mode to RFM69 library and it seems to work fine. The only negative of this approach is reduced bufferisation of the receive path - you have to pick up incoming data sufficiently quickly before next packet arrives (with interrupts support you have one packet buffer). But since senders are using retries and generally expected activity rate on the channel is low, this is probably OK.
As usual, the code is available in the SmartGarden GitHub repo.
I tried few simple range tests with SG controller on RFM69 915MHz link, and it seems to work pretty well. I'm getting about 80db signal at few hundred yards distance, on a small 1/4 wave antennae, and in wet weather. Will try actual max distance I need to achieve in a few weeks.