RF24 question about channels and multiple receivers

Using Arduino Networking, Protocols, and Devices
#1

My setup is one nRF24L01 used as master control and 20 RF24 slaves that sometimes act as sensors (transmitting to the master) and sometimes act as receivers as the master figures out what to do with the data it received.

After reading countless lines of code and too many, sometimes conflicting descriptions about pipes and addresses, I realize this (for me) is still a confusing mess, and that there is no definitive, detailed text clarifying the pipes/address biz. And...Im not going to read Nordic's 78-page data sheet. So my solution to my ongoing headache is using channels - one per each receiver.

This would seem to require that the master has one 40-bit address, say 0xF0F0F0F001LL, and all the slaves each have this same 40-bit address, but they reside on separate channels. The same pipe 0 is always used for transmit and receive no matter who is doing what. The master loops thru all the specific channels (20) in void loop().

So if this is possible, and not totally beyond stupid, after using radio.setChannel(xxx), must there be a delay(xx)? I suppose when the slaves on their different channels are in transmit mode that setRetries(15,15) might be appropriate.

Please comment, hopefully with suggestions. Thanx in advance.

#2

But you expect people who did to explain it to you?

Good luck.

1 Like
#3

Make it a hub and spoke topology so you can control as many slaves as you want. The master (hub) determines which slave (spoke) can talk. Basically, all slaves listen to the same channel and pipe address, but you have to disable auto ACK on master and slaves, and you handle that in your code.

The master broadcast a message, all slaves receives it, but don't send an ACK. The master transitions to PRIM_RX, start a timer, and wait for a reply of the "addressed" slave. The addressing is done in the payload. That is where the slaves know if they are the one "addressed" by the master. If the timer expires without a reply, you then chose to re-transmit or proceed with another slave. That's how you handle the re-transmission

#4

Yes I do. I am an occasional user of Arduinos and of various
products used in conjunction with Arduinos. I dont intend
to make a career out of this. There are those who for whatever
reason do make careers of this stuff and use these products
on a daily basis. Those people dont have to ask questions on forums
like I do and 1000s of others. And when we get an answer after
thoroughly trying to research something of value to us, it would
be nice if responses were of value and not just snarky remarks
that are of no value. So do you have something of value to
contribute?

#5

Thank you Hzrnbgy. I am aware of most of what you said except for the stuff
about PRIM_RX (?) and the notion of a timer (millis() or timer library?) associated
with that...? Could you elaborate a bit? Im thinking the only pipe used in all cases
could be pipe 0 (unless there is a better reason to use another)? And, is there ever
any reason to insert small delays in any part of the process (available, read, write)
you have described? Thanx again.

#6

PRIM_RX determines whether its a transmitter or a receiver

Initially,

  • master is PRIM_RX = 0 (transmitter)

  • slaves are PRIM_RX = 1 (receiver)

  • the master sends data to all slaves (AUTO ACK must be disabled for this to work)

  • all slaves receives and process the payload

  • inside the payload is the address, and each slave must have a unique address, and compare what's in the payload

  • after transmission, the master changes to become a receiver, and starts a timer (lets say two seconds)

  • when a slave determines it is the one being addressed, it starts a timer (lets say 1 second), and after 1 seconds passes, it transitions to a transmitter and sends the reply

  • at this point two things can happen, the 2 second timeout of the master expires and didn't received any reply, or it receives the reply from the slave

Think of it as a teacher talking to the students. The teacher shouts the name of the student he needs to talk to. The student replies back.

#7

hzrnbgy: Thanx again. Those details have helped especially with
the timing.

#8

There is nothing wrong with not understanding the data sheet and asking, after having read it.
If you can't be bothered to read it, why should anyone compensate your lazyness?

Read the data sheet if you want to use a device, is the best advice you can get.

#9

This looks like an interesting project with a large network of NRF24L01 devices. I guess you've done a few tests to check that the radio performance is good enough for all proposed locations of these devices and also considered alternatives like WLAN etc.

One major consideration is powering the devices. If these are all powered by mains adapters, there is no problem. As soon as you start wanting to use battery power, then that constrains what you can realistically do. For example, if a slave device is battery powered, then you cannot design a protocol where the master transmits broadcast messages to the slaves. That would mean that the slaves have to have their radios on all the time to hear any broadcast messages.

In the scenario where a mains powered receiver is always active and the slaves wake up occasionally to transmit their data then sleep again, then long term battery operation is perfectly feasible. This is where the "ack payload" feature can also be useful for getting data back to the transmitter.

#10

Why not ?

If I wanted to understand the use of addresses and pipes, I would feel obliged to at least to make an attempt to read and understand the datasheet, after all it might contain the answer. If after a while I make no progress then that would be maybe the time to ask for help from the volunteers in the forum.

I dont do this Arduino stuff for a living incidently, just for fun.

#11

Whandall: Nobody's lazy. What's your problem? Im here to get info from those experts who know something about the detailed workings of NRF24s. Obtaining additional info on a subject is the reason for this forum. Why are you here? Is it an ego problem that you must feed? Buzz off and stay away.

#12

Well srnet dude, I have spent countless hrs reading NRF24-related codes and the explanations that went with them. I guess that isnt good enough for you. I got mixed messages and a tangle of explanations. Reading the massive datasheet in hopes of finding the "true" answer to perhaps simple questions is another tangle that can be avoided and appreciated because of this forum. At least that is the hope. Im not interested in becoming a RF24 expert, I just want to use them confidently and intelligently. I dont have to read Atmel's datasheets to use their products. Was that a requirement for you? If I am to straighten out my use issues with my own research combing thru this giant datasheet, then what is the purpose of this forum? I am here to try and get some clarity on a few, perhaps simple issues. And...I do understand the use of addresses and pipes...mostly. But I have questions about what I dont know about them and what they CANNOT do. Where is that addressed? Now, you can take your narrow-mindedness and buzz off too.

#13

Hzrnbgy: Once again, I have another question...which I hope wont irritate the onlookers. I do understand using the payload to get to the right slave. NO ACK is necessary. As an alternative which seems to involve more code, is it possible to send via multiple addresses (one at a time) thru pipe 0 only? Here is what I had in mind:

  1. First off, set AUTO ACK on and specify RETRIES.
  2. Set stop listening.
  3. Then unleash a series of "open writing pipe"s and "writes":
    a: radio.openWritingPipe(Addy[1]);
    radio.write( &data, 2 );
    b: radio.openWritingPipe(Addy[2]);
    radio.write( &data, 2 );
    c: keep going, incrementing the element number in Addy[xx].
    This is only for 1 TX (master). No RX responses needed accept for AUTO ACKs (and they arent really needed).

For the record, this is some of what I dont know and havent been able to find out.

#14

6v6gt: I will be using a regulated DC bus (12V) with step downs when necessary to provide power for all devices. Each RF24 has an adaptor, so I wont be directly messing with 3.3V requirements. CMOS ICs on separate PCBs are partially driven off the supporting Arduinos, and those power requirements are low. Hopefully no stabilizing caps will be needed anywhere, except perhaps on the PCBs. Total slave count (with NANOs) is around 20 with an additional "master controller" (MEGA). The whole thing with the slaves has to be scaleable.

#15

That is perfectly fine. You can just use pipe0 and modify it whenever you need to talk to a specific slave. The only requirement is you just set RX_PIPE0_ADDR and TX_PIPE0_ADDR address the same so you get the AUTO_ACK part to work.

Maybe the library you are using already do this, but after each TXed message, you must clear the TX_DS bit in the STATUS register before you can send again, or clear the MAX_RT bit if the message wasn't ACKed

#16

hzrnbgy: Thanx once again.

#17

This may be simple, but I havent found out how to clear TX_DS. Ive searched for this for quite a while, and nothing comes up. Please explain. Perhaps something like this resetting the status register:
RF24.write_register(???)

#18

It's on register 0x07

Something like RF24.write_register(0x07, 1<<5) would do it since its a "write 1 to clear bit", as all the other bits in that register

bbb
bbb996×620 105 KB

#19

hzrnbgy: Thanx once again. Your help is greatly appreciated.

#20

Its amazing the stuff you can find in datasheets.