Using nRF24 Network Library and managing packets from several sensors at once.

I'm building a small network of sensors monitoring a few simple things like temperature and humidity. I want several sensors ( less than 8 ) to communicate with a receiver which will aggregate all the incoming data. I want this data to update every 2-3 seconds as well. As a twist, I have an accelerometer in this network as well which needs to transmit if the magnitude of the acceleration goes over a certain value. I built out the system using the library and the issue I have is that the sensors will sometimes interfere with each other and I will only receive input from one sensor and not others or nothing will update at times. I would say 70% of the time it works all the time :grinning: .I need help scheduling my sensor output and organizing them better at the receiver level so that ideally I am getting updates at a regular schedule with the ability for the accelerometer to send a message if it crosses a certain threshold. Attached are my programs and thanks for any help!

accelerometer_update_precise.ino (1.94 KB)

mcudemo_precise.ino (1.72 KB)

tempHumi_sensor_precise.ino (1.86 KB)

How far apart are the nRF24s? Can they all communicate with each other?

If they can then maybe there is no need to use the Network library at all. You can completely avoid the data collisions by treating one Arduino as the Master and having it poll the others in turn to collect information. It could easily do that at a rate of, say, 5 times per second which, from what you have said should be fast enough.

Have a look at the second example in this Simple nRF24L01+ Tutorial. It could be extended to communicate with several slaves.

...R

They're all within the proximity of a room so they can all communicate with each other if they had to. How would I set up the routine then where the master would check up on each sensor?

archeresque:
How would I set up the routine then where the master would check up on each sensor?

i guess you did not study the link I gave you.

...R

I did, I looked at your second example but I guess I'm not understanding the logic very well in terms of how it applies to my project. So would I simply apply your ackPayload example and have the different sensors all function as slaves in this case? Then the ackPayload feature would allow every packet sent from the slaves to reach the receiver in a predictable cadence? That's how I am understanding it.

archeresque:
Then the ackPayload feature would allow every packet sent from the slaves to reach the receiver in a predictable cadence? That's how I am understanding it.

That sounds correct. The master would send a short message to each slave in turn and the slaves data would be returned as the ackPayload. The message that the master sends has no relevance - it is just for the purpose of triggering the sending of the asckPayload.

What may not be immediately obvious is that the slave must put the data in the ackPayload buffer BEFORE the master calls. Think of it as putting a package in the mailbox for the postman to collect.

There is an example with master code to talk to 2 slaves in that Thread and I hope it should be reasonably obvious how to extend that to a larger number.

...R

Robin2:
What may not be immediately obvious is that the slave must put the data in the ackPayload buffer BEFORE the master calls. Think of it as putting a package in the mailbox for the postman to collect.

There is an example with master code to talk to 2 slaves in that Thread and I hope it should be reasonably obvious how to extend that to a larger number.

Thanks, this seems to be exactly what I'm looking for. Is the max amount of slaves that can be attached to the master limited to 6 I believe?

archeresque:
Thanks, this seems to be exactly what I'm looking for. Is the max amount of slaves that can be attached to the master limited to 6 I believe?

No. The incorrect (and widely held) belief that there is a limit of 6 is because the nRF24 has 6 things called pipes.

My examples just use one pipe and the number of slaves is only limited by the time it would take to communicate with them all. If you only need a message from each once per hour you could probably have hundreds of slaves. If you need to communicate with them all 10 times per second then you will only have time for maybe 20.

...R

Robin2:
No. The incorrect (and widely held) belief that there is a limit of 6 is because the nRF24 has 6 things called pipes.

My examples just use one pipe and the number of slaves is only limited by the time it would take to communicate with them all. If you only need a message from each once per hour you could probably have hundreds of slaves. If you need to communicate with them all 10 times per second then you will only have time for maybe 20.

...R

Excellent insight, I'm glad you cleared that up. I see now that essentially every sensor will share that pipe and simply transmit when its time for that specific sensor to send. I set up temperature sensors and this system appears to be a good solution to my problem.

archeresque:
I see now that essentially every sensor will share that pipe and simply transmit when its time for that specific sensor to send.

The important thing is that the sensor Arduino will only reply (send an ackPayload) when it gets a message from the master. All the timing is determined by the master.

...R