Questions about SE8R01 (NRF24L01)

Question

Soon I will receive some (2.4 GHz wireless) SE8R01's to be used in my new project (using Arduino).

The datasheet can be found here.

In my project I want to use several devices, that needs to send messages to a controller (master). Which based on that sends messages back (immediately or later). So it is really a bi-directional communication. But all (slave) devices have communication with only one single device. So the workflow is something like:

• Slave 1 sends data to Master
• Master sends data to slave 1
• Slave 2 sends data to Master
• Master sends data to slave 2
• Slave 3 sends data to Master
• Master sends data to slave 3

If the Master should be the initiator of everything, the possible workflow is also possible:

• Master asks slave 1 for data
• Master sends data to slave 1
• Master asks slave 2 for data
• Master sends data to slave 2
• Master asks slave 3 for data
• Master sends data to slave 3

Some data slaves sent to the master needs to be sent back fast (within around 10 ms), other data is less critical. This depends on the slave.

In the datasheet in paragraph 7.6 MultiSlave is handled. This is a 6-1 network (probably similar but not exactly like NRF24L01). I don't know why the SE8R01 and NRF24L01 are different (I thought they are compatible).

Anyway, in MultiSlave mode, it seems upto 6 devices are transmitters and 1 is receiver. But in my example, I want both: transmitter and receiver. The MultiSlave uses a protocol which changes the transmitter and receiver internally, but I am wondering if I can use this MultiSlave and protocol if I manually are going to change this.

Or should I make my own protocol?

Update: it seems that NRF24L01 is the same, the 'protocol' is ShockBurst in NRF24L01 and the MultiSlave mode is called MultiCeiver

Answer 1

The multi-slave (I don't congratulate them for the choice of wording) mode really is just a convenience function to give you "logical" channels at different adresses; it doesn't bring any new RF/network topology.

So, if you don't want 1:N communications, but M:N, just don't use it. Instead, address the packets like you want to, directly.

The device, reading from the state machines, doesn't have any arbitration – the Medium Access Control (MAC) strategy is a plain, unslotted Aloha – and I can't even seem to find an exponential backoff in there, so, errr – don't use this for anything where you get a substantial probability (say: 5% or higher) of two packets colliding in the air – you'll get colliding retransmits, new transmissions colliding with these retransmits, and even as the first transmitters reach their max number of retransmits and just give up, you'd then get ACKs colliding with retransmits of the second ones; a vicious cycle.

So, this is totally OK for e.g. a network of nodes that occasionally send a short packet; it's not OK once on average, more than ca 15% of time the air needs to be used by packets. (Eg. if the average packet + ACK is 1ms, you must not transmit more than 150 packets per second in the whole network; 150·1ms = 150ms = 15% of 1s).