Project

General

Profile

RFM69 native vs compatible API

Added by damonb 8 months ago

hi all.
I am planning an expansion of my wireless sensor network to cover a wider physical area. Mostly it's concerned with environmental monitoring, including soil moisture which drives an irrigation system.

Currently my dozen or so nodes are all JeeNode with RFM12B, with several packet relay nodes to bring in packets from the distant sensors. I am thinking I could simplify and cover the whole area without relays by converting to RFM69 hardware throughout. Relays will be more difficult to include in the expanded network as mains power will not be available, necessitating solar panels charging LiPo batteries etc. Hence it is an opportune time to change over, before I start adding the new nodes.

So I have been reading the sequence of posts on this topic here: http://jeelabs.org/2015/05/27/rfm69-on-atmega/index.html
It seems the best range and performance would be achieved by using the RFM69 in its native mode rather than RFM12B compatibility mode.

Which brings me to my question:

Is my understanding correct that to operate the RFM69 in native mode, everything must use the RFM69 driver library (in the jeelabs/embello repository), and not the traditional jcw/JeeLib?
And it has a completely different API? i.e. all the nodes and receiving gateways code needs to be modified with different radio code?

I am trying to judge the magnitude of the effort involved... adding network complexity with extra solar powered relays but staying with JeeLib and RF69_COMPAT, or adding project complexity by upgrading to RFM69 native (but resulting in a simpler network).


Replies (3)

RE: RFM69 native vs compatible API - Added by martynj 8 months ago

Just concentrating on the physical aspects of your question, the first hop range is determined by the RF section, primarily the received signal/noise ratio and baud rate. The RFM69 family is more sensitive than the RFM12, but in practise using the highest sensitivity can be tricky. Bottom line is that using pairs of RFM69 modules sets you up for greater range if the local noise floor is low.
Compatibility/native mode is really about how the packets are formatted - way above where the action is on modulation/demodulation. To first order, the range is not dependent on packet format in use. The rider on this though is that driver enhancements like dynamic Rx noise floor adjustment tend to be on the most recent implementation (i.e. native packet format) and back porting may be a long way down the ToDo list.
Are the collector nodes uniformly distributed or is there some clustering that could be done so that relay nodes can remain powered? If you haven't already, I'd introduce at least one RFM69 module into the mesh running compatibility drivers - then you can get node RSSI values to work with (worst case is during heavy rain or mist - but probably losing soil moisture readings then is not a problem).

RE: RFM69 native vs compatible API - Added by damonb 8 months ago

Thanks @martynj, your thoughts helpful as always.

What you have helped me realise is I need some additional observations to inform my network design, starting with RSSI measurements.
One of the design changes I am planning is to switch from one central JeeLink collector node feeding my management PC over USB/serial to a number of distributed collector nodes with EtherCard direct to MQTT or XAP (the latter unattractive but compatible with my irrigation software).
If I switch my prototype Ethernet gateway node to running RFM69 I can gather some signal strength data.

My layout does not support a powered relay node that could reach all the way to the edge, unfortunately. House is near the front of the block, long garden.

How does one measure the noise floor using RFM69 (or RFM12B)?

RE: RFM69 native vs compatible API - Added by martynj 8 months ago

You can get a quick estimate of the local noise floor with the standard rf12demo compiled for RFM69CW. Open up the packet filter (q command) to allow reporting of bad CRC packets. Since random noise eventually looks like a valid preamble, junk "packets" get reported with a snapshot RSSI value.

You are lucky to see better than ~ -95dB and close to a laptop/power brick can easily report -65dB. For the standard baud rate, having the Rx RSSI 20dB above the noise floor is fine for accurate reception. If occasional bit errors can be tolerated (higher level recovery, redundant data etc) you can squeeze down to only 12db headroom.
The observed noise floor is obviously a statistical thing - it varies with time of day and weather as well as the use pattern of distant interferers. So reasonable headroom is needed for a robust implementation - but nothing like the typical room to room luxury of 40db or more.

    (1-3/3)