How to avoid data collision in a network of NRF devices where only 2 NRF want to communicate with each other and others dont get this data ?

[Harshal Kadlak]

Hello,

We are using NRF24L01 as a transreceiver. We have a network of NRF devices operating individually and we want one NRF to communicate only with its respective NRF. However the data collision happens during this. The NRFs in the network also receives this data despite keeping the different frequency.

We cant have multiple frequencies for our every product.

So, is there any way to avoid data collision / interference so that only 2 desired NRF will communicate with each other and other NRF devices in the network wpn't get that data ??

Thanks and Regards ,

Harshal

 

[Hung Bui]

Hi Harshal, 

Do you use any protocol with the nRF24L01 ? For example Enhanced Shock Burst ? 
How do you configure the address ? 
Could you show how exactly you configure different channels for each pair of devices ? When the channels are close to each other they can leak but I don't think they would if the channel band a far away from each other. 

[Harshal Kadlak]

Yes, we are using Enhanced Shock Burst.

Also, the channels are close to each other i.e. all the NRF devices in the network are operating very close to each other.

We configure different channels for each pair of devices from the microcontroller side via its firmware. 

[Harshal Kadlak]

Hello,

I haven't checked reading the value of the STATUS and FIFO_STATUS registers in that state, because its the PTX that stops sending the messages.

[ovrebekk]

Hi Harshal

It could be interesting to read these registers on the PTX side also, as they will tell you if the PTX has any pending interrupts, if the TX FIFO is full and so forth. 

Have you checked the communication between the host MCU and the PTX to see if the MCU is trying to send something or not? 

Could there be some issue with the state machine on the host side where it stops trying to send packets under certain conditions? 

Best regards
Torbjørn

[Harshal Kadlak]

Hello ,

ovrebekk said:

t could be interesting to read these registers on the PTX side also, as they will tell you if the PTX has any pending interrupts, if the TX FIFO is full and so forth. 

sure will give it a try.

ovrebekk said:

Have you checked the communication between the host MCU and the PTX to see if the MCU is trying to send something or not?

yes after every particular interval of time the MCU makes the PTX send a packet.

ovrebekk said:

Could there be some issue with the state machine on the host side where it stops trying to send packets under certain conditions? 

By host side, do you mean the MCU connected to te the PTX ? 

[ovrebekk]

Hi 

Harshal Kadlak said:

By host side, do you mean the MCU connected to te the PTX ? 

Yes, I meant the host MCU controlling the nRF24L01+ on the PTX side. 

The nRF24L01+ is a relatively simple device compared to a typical MCU, and if there is some issue with the nRF24L01+ behavior it can usually be spotted by sniffing the SPI communication. 

Best regards
Torbjørn

[Harshal Kadlak]

We have discovered that the PTX is getting affected by other PTXs in the network (since our application has multiple NRFs communicating with each other in a pair on a different RF Channel for each pair.

When the PTX tries to receive something (any acknowledgement, reply from its respective NRF) it gets reseted and we can not increase the power supply to the NRF.

Is there a way to stop happening this ?

[ovrebekk]

Hi Harshal

When one device is transmitting close to another device that is receiving the receiving device can be blocked from receiving other, weaker signals, that is true. Even if the blocking signal is on a different frequency. 

Still, the receiving device should not be reset, it should only lose the packet that it was supposed to receive. 

One way to reduce the impact of this problem is to use the retransmit feature, so that the PTX tries to retransmit the packet when it doesn't receive the ACK. 

Secondly, if you randomize the Automatic Retransmission Delay (ARD) then you reduce the chance that if two PTX's transmit at the same time they will also keep sending the retransmitted packets at the same time. With a different ARD value the retransmitted packets will occur at different times, meaning that they will eventually get the packets through without conflict. 

Best regards
Torbjørn 

[Harshal Kadlak]

Hello,

ovrebekk said:

Still, the receiving device should not be reset, it should only lose the packet that it was supposed to receive. 

Not the receiving device but the transmitting device (The PTX) is getting reseted when it receives the signal of its own or other frequency.

ovrebekk said:

One way to reduce the impact of this problem is to use the retransmit feature, so that the PTX tries to retransmit the packet when it doesn't receive the ACK. 

Yes, we do have this feature implemented.

ovrebekk said:

meaning that they will eventually get the packets through without conflict. 

Yes they do. The problem arises when they receive any acknowledgement or feedback from their own / other NRF for the packet they transmitted. At that time they get reseted.

 

[ovrebekk]

Hi Harshal

Can you elaborate on what you mean by the device getting reset?

Will the device stop responding to commands? 

Will the configuration registers return to default values? 

I would be interesting to see the state of the registers after this reset occurs, if you are able to read them out? 

Best regards
Torbjørn

[Harshal Kadlak]

Hi

ovrebekk said:

Will the configuration registers return to default values?

Yes they return to their default reset value.

ovrebekk said:

Will the device stop responding to commands?

Its the PTX that gets reseted so it doesnt send any data nor it responds to any commands.

[ovrebekk]

Hi Harshal

Which commands does it stop responding to? 

You say that the configuration registers return to reset, so that must mean that you are able to read the configuration registers successfully? 

What happens if you try to write and modify configuration registers, is this not working? 

Could you share the link to where you bought your modules, and a picture of the modules?
There are various clones of the nRF24L01+ device in existence which might behave differently from the original chips, and we should make sure that the devices you have are genuine. 

Best regards
Torbjørn