Hello,
I am following the tutorials step by step to understand and proceed to develop from time to time more complex networks with PiGateway and moteinos.
Till today zero problems, very good product and tutorial.
I tried to search for this topic but I did not find anything. Let me explain my observations.
I was trying to improve the transmission period of 2 nodes to same PiGateway. Every of the 2 nodes with different nodeid transmits its status every 2 seconds. I noticed in different trials that sometimes only one of the two nodes is able to deliver its status and the second is not able not transmit. Sometimes both are able to transmit its status but I see on PiGateway refreshes every 6 to 10 seconds.
When only one node is connected, it refreshes every 2 seconds correctly.
The questions are: Is there a minimum transmit period to avoid two or more nodes to collision ?
Is there a way to manage lower transmit periods avoiding collisions of node transmitting ?
Thank you,
Mike
Collisions are managed in the RFM69 library automatically (best effort listen-before-talk approach). That does not guarantee collisions don't happen, especially at high TX frequency.
The gateway can receive as fast as the physical limits of the radio transmission allow (as radios settings dictate). That is once every few dozen ms or so at the default radio settings. The receiving part's (gateway) main task is to poll that radio as often as possible to ensure any received packet is handed off to the host (your Pi computer).
That said, there is a 1second limit (per node!) in the PiGateway internals. It can technically receive more often than that, but it cannot log more often than that (again - per node!).
In most normal situations that is plenty frequent.
In your case it sounds like that is not your problem, you should check that your signal is strong enough from both nodes, and that other code in the nodes themselves (including gateway - if you run something other than the default example) doesn't prevent the nodes to talk as frequent as expected.
You must also ensure that the nodes do indeed transmit and the gateway receives. The reception at gateway is always logged in the gateway.sys.log file (even if not logged in the node's DB), so check there for clues.
Another important aspect is that duplicate data is not logged by default in some of the default metrics. There is a 1 hour duplicate interval (for most default metrics, 3600 seconds) during which duplicate data (from last value) is skipped and node is not updated. You can change this for each metric in each node by giving a value (in seconds) to the duplicateInterval setting, see the metrics.js file for examples.
If this is a custom metric, the default value for this is null (ie it will fall back to 1 second).
Anyway, check that this is not in fact your issue.
Good to know, thank you!
No duplicateInterval setting in metrics.js
In my last test I have 3 nodes, with following transmitperiods:
const long CheckTimeLow = 11123;
unsigned long lastReportMed;
const long CheckTimeMed = 4234;
unsigned long lastReportLow;
const long CheckTimeHigh = 2513;
unsigned long lastReportHigh;
With this combination of numbers a collision happens about every 5 to 7 seconds, it means that every 5 to 7 seconds there is node that has not delivered its value.
If this statistic is normal for the tranceiver library limits, I think to manage collisions with some logic to implement on nodes and gateway to avoid collisions but trying to have a 2 seconds transimt frequency.
If this statistic is not normal, I will go deeper to tranceiver library to better use the APIs.
Could you give me an advice on how to proceed ?
Thanks,
Mike
Mike,
In your node's sketch, how do you send your message? With send or sendWithRetry?
And what's the average length (in bytes) of your message?
I use sendWithRetry and average lenght is 5 bytes (from 4 to 6 bytes depending on node).
m
That's good, and they are short enough that I am surprised you're having such issues, even at a few seconds apart in frequency this should be no problem.
I tried again with 4 nodes and statistics become a little worse... so more collisions, the worst case of a node with about 11 seconds transmit period, transmits only every 30 to 60 seconds.
That's strange considering the setup.
I'm trying to understand if the ACK messages will create some confusion for the nodes.
If gateway sends ACK after receiving a message, the second node trying to send but without delivering his payload, could consider the ACK destinated for node1 as good even for node2, and so it stop retrying.
Could this have sense ?
If yes I try to work on this, otherwise I'll try a synchronization handshake to avoid collisions.
m
No, the library filters packets by address so as long as your nodes do not have "promiscuous" mode ON (this is off by default, has to be turned ON explicitly), they should not see the packets destined for other nodes.
Ok thank you, I try to solve with an anti collision logic.
m