Hi,
First of all I must say that I am using RFM69 transceivers with the great RFM69 library (probably the one of 2015) since more that 6 years on various platforms with various sensors without any problem.
So before upgrading my sketches with the current library, I am looking at the changes, by doing some kind of reverse engineering.
So my astonishment and also my concern: the reason to extend the node ID to from 254 to 1023.
Here is here is my reasoning:
1. Usage of RFM69 nodes is mostly done in the same network and in the same RF range, which in a non-open space limits the physical distance between nodes and probably request to use the maximum power to ensure reliable communication (at least this is the way I could extend it in my house coverage from the basement to the attic))
2. RFM media access layer CSMA is rather simplistic, just carrier sense, no collision detection, no random retries, which of course makes it chaotic when lots of nodes are trying to access simultaneously the same RF network (collision, no acknowledgement and time-out).
3. Without actual network layer, the architecture is presumably one-to-one; so called end-nodes talking to a gateway (aka coordinator or broker).
Practically, I see usage of huge number of nodes in a very large plant. But this raise the need of extending the RF range by not just increasing the power.
For that purposes higher layers nodes types have to be implemented, typically:
1. Repeaters, but is not an actual solution for large number of nodes deployment because it will rapidly limited to the number of node to manage without buffering messages to re-transmit
2. So a Bridge will be a better solution but again with some buffer limitation
3. So a Router, the actual solution is to build a mesh network with routing (typically RIP, BGP, EIGRP, OSPF...) and pear-to-pear exchanges between gateways with rerouting capabilities in case of failure, duplicated message avoidance, etc... With this solution the number of nodes (255) is not actually a problem because multiple networks (255) may be to be implemented (giving amount of 255*255 nodes). Border nodes interfacing different networks at the edge of RF networks can be deployed
However as far as I know none of these are implemented.
So my question: In which particular case and why an extension to 1023 nodes is required?
Now practically as impact of this change is:
1. Broadcast address 255 can't be used anymore because , reason to change it to 0
2. Node address filtering can't be used anymore, because the RFM Node address register doesn't reflect the actual node address
NB: Probably few applications are using these features, but this means that upgrading the RFM library is to be done carefully
Robert
Hi Robert, thanks for the question.
Required? it is required, but it's nice to have when you need it ;)
But let me try to address a few points:
10bit address space:
This change was carefully considered. Having a 10bit address space (1024 addresses) is very useful. There are applications where a dense cluster of many hundred nodes are employed. A fast RFGateway board acts as an aggregator to collect data from all the RF nodes. A nice custom GUI based on the PiGateway project harvests the data and presents it to a user, along with alerts and other features which allows a fully integrated monitoring solution.
RFM69 library changes:
Broadcast address is rarely used, not in sleepy networks, which is where these low power nodes are mostly used. So it made sense to move it to address 0 with this address space expansion.
If you have to question the need of 1023 addresses, then I doubt address 255 has been used much as broadcast address in the version before this feature change.
ROUTING, BRIDGING, REPEATING RIP, BGP, EIGRP, OSPF.....
I have actually implemented a layer ontop of this library to do just that. I have rarely used it and not much in the last years and found the benefits are far outweighed by the downsides. Having worked with more real world implementations where no such overhead was required, I now do not believe this makes sense to layer, I cannot think of a single instance where it would be beneficial. There is LoRa if you need more range. If you want a layered approach you have bluetooth and other RF networks, but there range is the last priority.
CSMA is simplistic indeed, again haven't seen a need to increase complexity there. Adding some simple random timing repeating is the most I have considered (rather than the library parameter-fixed-timing in between retransmits).
BUT this is all just my experience, I have developed this library for my own use (personal and for custom projects) and released it publicly for free. There are others of course. Experiment and use what is best for your use case. Or there's the option to fork, modify/add features, the possibilities are infinite.
Hi Felix,
If I agree that adding routing to the RFM protocol will overkill the performance of the system.
However I still have difficulties to imagine a network of thousand nodes talking all together over the same RF network in a restricted area, with possible of data storm .... unless they are sending randomly data and only from time to time.
Was this a requirement for a specific project? but certainly not an house automation one :)
Thanks again for your feedback
Robert
Quote from: Robert on January 31, 2022, 10:55:27 AM
However I still have difficulties to imagine a network of thousand nodes talking all together over the same RF network in a restricted area, with possible of data storm .... unless they are sending randomly data and only from time to time.
Was this a requirement for a specific project? but certainly not an house automation one :)
Certainly not home automation ;D
IMO high throughput is not a priority in such dense networks. Even in small networks, we generally don't care to hear from a node all the time. Rather than constantly collecting data at a crazy frequency and looking at a straight graph line with many data points, we focus on writing firmware that collects data and aggregates it when necessary. There are some special use cases where the node has to take many samples per second, as fast as possible, ex. to measure a sensor load on a large machine that spins. All those samples need to be sent back to analyze how the machine behaves under different loads in a full cycle. Rather than sending 100 samples in 100 packets, we aggregate and pack the data using various techniques and unpackage them on the RFGateway side, then inject them into the PiGateway, where the user can zoom in an see all those samples in millisecond resolution.
This is usually by user request, and is requested from the GUI to the end node. The node can also monitor the sensors on its own without transmitting all the time, and depending on other parameters set by the user can generate a packet/alert when a out of range condition is true (or say when the battery is low). This reduces the need to transmit frequently, and only transmit at longer intervals.
Each project has to be designed to meet the requirements and work around constraints. Having people look at graphs is expensive, so we want to replace expensive human time with machines that can do the job and alert us about issues only when they arise.
And don't forget, if there is a need to have just 260 nodes, already the address space is too limited.
Felix,
OK I can't argue about that, just that deployment of such a huge network should be done knowing the limitation of data traffic impact.
Thanks for time you take to reply to my "theoretical" concern .
Robert