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

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

[Harshal Kadlak]

Hi,

Actually what happening exactly is, PTX and PRX are being powered in a different way. The PRX is mounted on the motherboard of the machine and its getting its supply from the motherboard whereas the PTX is powered by an arm which is physically connected to the machine and that arm transfers the power to the PCB of the PTX side and its MCU via a magnetically coupled coil.

Now the scenario :-

The MCU powered ON -> it makes the PTX send data to its respective NRF(PRX) -> when any other nearby PTX sends data to its own respective PRX (operating on a different frequency channel), it is received by the arm's PTX NRF and during this i.e. while receiving its drawing more power than it does furing the IDLE and transmitting states. -> Due to more power drawn the MCU gets less power than power required to be ON and thus the MCU resets (and so does the PTX) and the MCU starts its code execution from the beginning.

We can not increase the power being provided to the MCU of PTX by the arm.     

[ovrebekk]

Hi 

Thanks for sharing this additional information, now the issue is more clear. 

So basically the mere act of receiving data will cause the device to reset? 

Will receiving the ACK from the correct PRX not cause this to happen? 

Are all the PTX's in the area using the same RF address? 
If not then they should not be able to send packets to each other. 

Regarding the supply voltage, it is critical to check that the device gets a sufficient supply to perform its tasks successfully. If the device is operating outside the legal range it might appear to work in the lab, but once you start deploying units in the field you will have reliability issues. 
Have you done some measurements with a scope to verify how high the supply voltage is, and how much RF activity you are able to sustain before the voltage drops too low? 
Does the MCU have some kind of low voltage warning that would allow you to prepare for such a situation? 

Best regards
Torbjørbn

[Harshal Kadlak]

Hi,

ovrebekk said:

So basically the mere act of receiving data will cause the device to reset?

Yes.

ovrebekk said:

Will receiving the ACK from the correct PRX not cause this to happen?

Whether from correct PRX or any other PRX, when the PTX receives a payload of ACK/Response its reseted.

ovrebekk said:

Have you done some measurements with a scope to verify how high the supply voltage is, and how much RF activity you are able to sustain before the voltage drops too low? 
Does the MCU have some kind of low voltage warning that would allow you to prepare for such a situation? 

okay, that's a great suggestion, Need to check with this.

ovrebekk said:

Are all the PTX's in the area using the same RF addres

No, every pair is having the unique addressing.

[ovrebekk]

Hi

Harshal Kadlak said:

Whether from correct PRX or any other PRX, when the PTX receives a payload of ACK/Response its reseted.

Then it sounds like you need to make some improvements to the supply architecture, in order to ensure you have the energy available to perform a successful radio transmission. 

How much decoupling capacitance do you have on the supply lines? 
Possibly you can improve the situation by using larger caps, in order to store up more energy before you start a radio transmission. 

Also, if you are using 1M on air bitrate today you could reduce energy consumption by switching to the 2M mode, at the cost of slightly reduced range. 

Using one of our latest nRF devices like the nRF52810 would also help reduce energy consumption considerably, but then you would need to completely redesign your software, so this is not an easy migration. The nRF52810 has less than half the peak current in TX/RX, and also includes an MCU so you don't need to have a separate host MCU. 

Best regards
Torbjørn

[Harshal Kadlak]

Hi,

ovrebekk said:

Also, if you are using 1M on air bitrate today you could reduce energy consumption by switching to the 2M mode, at the cost of slightly reduced range

We are using 250kbps data rate. Range is not a constraint as the PTX and PRX operate closer to each other in a pair.

In fact it'd be great if we get a reduced range this will stop the signals from PTX to reach to any other PRX.