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. 

[ovrebekk]

Hi Harshal

I agreed to help Hung out with this case, since I have more experience with the nRF24L01+. 

Unfortunately this device doesn't have a reset feature available, neither as a hardware pin or as an SPI instruction. 

The only way to properly reset it would be to power it off completely by disconnecting the supply for a short period. 

Best regards
Torbjørn

[Harshal Kadlak]

Hello Mr. Torbjørn,

Can we use PWR_UP bit in the CONFIG register for reset by clearing it and setting it again to 1 ?

Would it work a little bit similar way as a reset; because it seems to work that way as explained in the datasheet.

Because powering OFF the NRF for a while is not convenient for our application.

[ovrebekk]

Hi

You can try to disable PWR_UP for a bit and see if this solves the issue, but I don't think clearing PWR_UP will clear all the FIFO's and registers of the device.

Are you able to read out the value of the STATUS and FIFO_STATUS registers when you are in this state? 
Possibly there is something in these registers that can point us to the source of the problem. 

Best regards
Torbjørn

[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.