Hi, I have 20 arduino nano slaves (Tx) with nrf24l01+. I need that all this slaves send data to one master (RX). Is possible? The NRF has 5 pipes (address) for receive the data, but how can i read the data dor slave 1, then for slave 2, then for slave 3...............then for slave 20. Please help!
You need to provide more information.
If each slave is just dumping a bunch of existing data to the master, then the master could just ask each slave for its data, one at a time.
Example:
Master: Tells slave #1 to dump its data.
Slave #1: Dumps its data to master.
Master: Tells slave #2 to dump its data.
Slave #2: Dumps its data to master.
...
Master: Tells slave #20 to dump its data.
Slave #20: Dumps its data to master.
This works because each nRF24L01+ can act as both a transmitter and a receiver.
However, if the data comes continuously from all slaves, then you will have to work out a way to get them synchronized in time so that no two slaves transmit at the same time.
More information, please.
I must have missed seeing the information that I was looking for. I do see that a String is converted to a string and then back to a String for printing, and this is done twice.
I am willing to bet that the original code did not have italics in it. I would have expected that someone who had posted 36 times would know to use code tags.
When one is tempted to suffix variable names with numbers, it is time to learn to use arrays.
When temperatures are being read and sent, it is possible but unlikely that great speed is required. The master could easily ask each of 20 slaves for temperature readings every second. This would be fairly fast for most purposes.
criminalkaoz:
I use the rf24 library. ...
Please modify your post and use the code button </>
so your code looks like this
and is easy to copy to a text editor. See How to use the Forum Your code is too long for me to study quickly without copying to a text editor.
I assume (as you have not said otherwise) that all the slaves are close enough to the master to send data to it directly.
A big problem with lots of slaves is the risk that two (or more) transmit at the same time garbling both messages. If the slaves are always ON a simple way to avoid that is for the master to send a request to each one in turn and get the data from the slave as part of the acknowledgment process. There is an example in this Simple nRF24L01+ Tutorial showing how to do that.
If you need your slaves to sleep between messages then you do need them to send and take the risk of messages colliding. You will need some means to deal with that so that the master can know it has missed a message or got the same message twice. Keep in mind that the message might be received properly but the acknowledgement of it might be garbled. Also, increasing the number of automatic retries can make the situation worse, not better. This is really a question of thinking rather than programming.
The existence of the 6 pipes is just a distraction. You can implement your system with a single pipe. The nRF24 only has one wireless and the pipes are just different places to store incoming messages. If you include an ID as part of each message there will no confusion about which slave it comes from.
...R
If you are using an 8 bit AVR, drop all the String stuff.
Do not use blocking constructs like
while (!radio.available() && !timeout){
if (millis() - espera > 5000 ){
timeout = true;
}
}
What Robin2 wrote is true, but can the slaves hear each other?
vaj4088:
What Robin2 wrote is true, but can the slaves hear each other?
If the master can hear all of them reliably it would be very strange if they could not. There is no sharp cut-off for range.
...R
There could easily be a hill or directional antennas or other impediment that makes communication between two slaves unreliable although their communications with a master is reliable. It is not strange at all.
Interesting discussion, but we still have not heard from the OP to understand conditions, timing, amount of data, antenna gain/directionality, etc.
"a nrf24l01 antenna" is suggestive but does not really tell me anything.
vaj4088:
There could easily be a hill or directional antennas or other impediment that makes communication between two slaves unreliable although their communications with a master is reliable. It is not strange at all.
OK. I exaggerated a little for effect but I won't accept that NONE of the slaves could EVER hear any other slave without some serious evidence.
But, and I overlooked this in Reply #7, the problem is with the possibility of the slaves' signals interfering with each other when they arrive at the master. That has nothing to do with whether the slaves can hear each other.
...R
Robin2:
A big problem with lots of slaves is the risk that two (or more) transmit at the same time garbling both messages.
Depends very much on the duty cycle - if a 0.01% duty cycle it matters not a bit, if a 5% duty cycle
it will be unworkable (duty cycle on the air, that is).
With the nRF24L10 the high baud rates mean very short duration of packets which tends to a very
small duty cycle.
MarkT:
Depends very much on the duty cycle
I agree. But there still needs to be a system to deal with collisions. And my first choice is a system that avoids the risk of collisions.
...R
Robin2:
If the slaves are always ON a simple way to avoid that is for the master to send a request to each one in turn and get the data from the slave as part of the acknowledgment process. There is an example in this Simple nRF24L01+ Tutorial showing how to do that.
You will not get more help than already was offered.
Are the slaves battery powered ? If low power consumption is an important criterion, the communication strategy must seek to minimise the time the slave has its radio on (for either TX or RX).
Interesting synchronisation senarios come to mind. One is that the master could frequently send a schedule when it expects the next transimission from each slave, so the slave can wake up periodically, check the schedule, and knows how long it can sleep for.
With one central hub and a number of (possibly sleeping) data sources I would have the hub listen to
an address known to all sources and used in data packets originating from the sources.
These packets carry a source-id and/or a special personal address the source may provide and the data.
Sources could listen (without autoack) to that address too, if they are interested.
Polling sleepers just pollutes the air IMHO.