Assigning Unique nRF24 Slave Address via Master

Greetings,

I have read many threads to understand the nRF24 module. However, I am unable to find a response to the needs of my project.

The goal of my project is to have multiple sensors report back data to a controller as they receive it. The controller acts as a hub for the sensors and only writes to them for calibration purposes, which is optional. Otherwise it constantly listens for available data from the sensors. Once all sensors have reported data, the control module averages the data and displays it via LCD. The sensors will pick up data simultaneously, so the controller must be able to keep tabs on the order of the readings.

The major challenge I have is that I would like for sensors / slaves to be freely added or removed from the system without having to worry about hard coding unique addresses.

My question: With a nRF24 module, how would one have a master identify available slaves, possibly ones it hasn't communicated with before, and assign them with a unique address to establish communications?

Apologies if there was a thread related that I missed. TIA.

That is why DIP switches were invented!

If you have a central, always on control/master node,
you could use its fixed pipe address to request an unique new node address.

If the number of nodes is below or equal to 256,
you could use a fixed prefix with only the last byte variable.
This would allow placing such addresses freely into the six pipes,
without worrying about their placement limitations,
and handling of a one byte address is much simpler than handling the full 5 bytes.

I don't think I understand your intent with the use of DIP switches, could you elaborate?

To describe my intent further, multiple people will have access to their own controller and sensor combos. If somebody came to me for another sensor, or borrowed a sensor from someone else, My concern is that two sensors may share the same address and manually hardcoding a UID for each sensor ever produced would be an arduous task, as opposed to having the controller wirelessly assign the slaves a unique ID relative to the system.

I think you hit on my confusion so, to ensure I understand - We could assign a 'default' address to all the slaves, which would be reserved. When powered on along with the master, the master 'checks' or calls to the default address. If there is a response, we can pass the slave a new address, update the one on the master, iterate through the slaves until no defaults remain, and then open the pipes?

No.

Nodes need no own address to send, only to receive.
The receiver can attach data to the acknowledgement,
which has to be preloaded.

After he receives a packet on that pipe, he loads a new unique address,
and marks the last one as used.

I would not poll the clients, I would like my clients to report on their own.

1 Like

How many controllers, each with their own group of sensors, are you going to plan for ?
Each individual sensor is itself wired to a radio device which has a wireless connection with the controller.
How are you intending to ensure that specific sensor node is paired with the correct controller ? Do you envisage a sort of pairing process where the controller is held in a special mode while the sensor is paired with it or what ?

Are the controllers intended to be powered from mains based power supply (e.g. smartphone charger) ? If these are battery powered, care has to be taken with the design of the system to minimise power consumption.

Good questions. One controller paired to a max of 5 nodes and your assessment of the sensor connectivity is accurate.

Only one controller would be within range, we are not using these devices close to one another. Since I'm not concerned with controller interference, I do not intend to implement a pairing process. Ultimately, the intent is to make the system setup simple for the end user.

The power is intended to be supplied through 12v plug-in, so not concerned about battery, and my knowledge of these devices is probably too low to accomplish that.

Ahh I see, I misunderstood a piece of Robin's tutorial code. I reviewed the args for read and write in the RF24 library and I think I get it. And I agree, I would not want to poll the clients for data - their time is best spent collecting the data!

I cannot test this yet as my other devices are off-brand nanos which don't seem to produce enough amps off the 3v3 pin to power on, but after I get the breakout board, I'll give your suggestion a shot.

Thanks for your help.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.