I am trying to build a mesh network that has more than 5 remote nodes, (maybe 10 or so) each node has a specific task and they are dependent on each other. The remote nodes send the master a regular status update and, based on the state of each of the nodes the master sends specific commands to control each node.
So; a mesh network with hardwired node ID’s (not addresses) so their location and purpose can be identified. To start the master has to confirm which nodes are up and running and which are missing. It then regularly polls each node, with and command and the nodes respond with a status. At any time missing nodes can join in.
The problem I’m having is how do I get the messaging to occur synchronously? At the moment everything is running asynchronously and the Rx Fifos are continuously full (radio.rxFifoFull)
As the command from the master and status from the remotes are so small I would like to use the Ack Payload method, whilst using the RF24Mesh framework. So the first question is this possible and second question how do you do it? I’ve been working through examples and there doesn’t appear to be anything like what I’m trying to do.
OK thanks, that will stop me trying to get it to work. I spent a day on it yesterday
What I am really looking for is a method of sychronising the master polling of the remotes and the remotes replying. I have got messaging going back and forth but effectively the master is spamming the remotes with a continuos stream and the remotes are doing the same back. At times some remotes take over and others get blocked out.
So simply, to start the master does a "mesh.getAdress(node_ID) to all the known nodes, that creates a list of who is available and who isn't.
Then the master polls each remote, in turn, with the command message for that node and waits for a status reply from that node. But I've been having problems with segmentation faults when I add the network.read() into the polling loop but now, writing this has formed my thoughts and I may have that sorted.
I need mesh as it is a distributed system outside with a few hundred metres between nodes. The Master needs to be sure the nodes are there to be able to make decisions that affect the other nodes. I plan to use polling because it is then a positive response, rather than hoping that the remotes may send something.
Yes I'm using serial for testing but I can't hook up all the nodes at the same time.
I know but they are cheap. I'm using the plus version with the LNA, they say they can do a kilometer and I'll find out if they work once I've got some code doing something sensible.
I don't like polling but there is polling and polling. It is not like the code is going to sit and wait for a response. It will loop round continuously pinging the remote nodes and the responses will arrive in the frame buffer.
Once I've got something sensible working I may investigate tying it to the interrupts. Which is always my prefered approach.
My nodes broadcast their existence regularly, they don't retry,
here polling has an advantage.
If you want to deep-sleep nodes, polling is rarely feasible.
Polling creates a fixed access pattern, which can lead to false duplicate packets,
if constant packets are sent (which can be avoided easily, but must be done).
Not using interrupts is generally faster, if designed correctly.
Probably wise, but I believed the spec sheet and they are cheap. Even if they don't end up being the final solution, or indeed any solution, I'm learning something
If you are attempting to synchronise nrf24L01 devices in such a way that they can sleep and occasionally wake up and talk to each other (which is ideal for battery operation) you may find something you can use here. Synchronised NRF24L01+ Transceiver Pair for Low Power Operation Using the ATtiny1614
There is some scope to simplify it, for example not swapping clocks between sleeping and wakeUp and I'd also consider using a crystal oscillator instead of the internal oscillator to minimise drift. Anyway, it may give you some ideas.
And does the 'spec sheet' quote the exact circumstance and context of that 1km ??????????
For radio devices like this the differance between the distance with perfect line of sight conditions and what you might get with nodes at shoulder level in an urban environment can be more than 1000:1, so guess which distance the datasheet will quote ?
How long does it take to check that the range is good enough for your actual application, 5 minutes ?
I'll admit that I haven't looked into the implementation of interrupts in the Arduino framework. I did touch on it some years ago with a collegue and it appeared that it provided a grossly oversimplified interrupt API that dumbed down the underlying capabilities of the CPU. I could well be wrong and things have moved on since then. I did try them recently on an ESP32 with the Aurduino framework and anything but the simplest handling routines crashed.
I would be interested to know how you would implement a system with multiple external interfaces with events occuring at many different and variable timeframes without using interrupts? Your comments do appear to missinterpret how interrupts work. However, I don't really want to get into a lengthy debate of the pro's and cons of using interupts.
Thanks for this it looks interesting and very well documented. I'm guessing your username shows you've been doing this stuff for a while.
My application needs multiple remote nodes and the master needs be aware that they are there all the time or do something about it. I now have more than 5 slaves talking to the master in a mesh network without the need for the masters and slaves to 'hosepipe' each other with data hoping the messages will get across. Once I was aware that payloads in the ACK when using RF24Mesh weren't possible I could stop trying to get it to work and go back to the asynchronous sends. I realised that with more remotes than pipes there was possibility of the rx buffer being full when a remote tried to send, so slowing thinks down has increased message transfer reliability. Remote to master sends are set at 500ms and the interval between each when the master is receives them is within 10ms of that time which shows they are all getting through. Likewise master to slave messages are being received reliably. The system that is being monitored has timeframes measured in minutes whereas with the remotes sending data every ½ second, if one frame gets lost it will soon be resent without any impact.