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 Mr. Hung,

After the transmission of one packet we check the status register to know whats the status of the packet transmitted and the status register shows MAX Retransmit count exceeded for the transmitted message.

This is how we come to know that the messages get lost from the PTX side !!

[Hung Bui]

Hi Harshal, 

Okey, that mean the packet has been transmitted from the PTX but not ACKed from the PRX. 
So it's either the PRX didn't receive the packet or the ACK packet from the PRX not reach the PTX. 

So have you checked if the packages are received on the PRX's side ? You can just make a test and store all the packages you receive on PRX and check if any missing manually on the PRX. (you need to increase a counter in the data payload for each packet)

How often do you see the MAX_RT hit ? 

[Harshal Kadlak]

Hung Bui said:

So have you checked if the packages are received on the PRX's side ?

Yes, At the PRX side, it shows RX FIFO Empty. and RX_DR is 0.

Hung Bui said:

How often do you see the MAX_RT hit ? 

After power on and successful initialization of NRF the CHECK COMMUNICATION command is sent from the PTX to the PRX and in that we found that the MAX_RT exceeds every time.

[Hung Bui]

Hi again, 

Earlier you mentioned that: "It was happening with one or two out of every 15-16; but managed and fixed it." 

But now you say "we found that the MAX_RT exceeds every time." so what have changed ? 

Are you saying that you don't receive anything at PRX at all ? 

If you transfer 20 bytes or lower do you receive anything ? 

If you increase the payload size , at which exact point you don't receive any packet ? 

[Harshal Kadlak]

Hello Mr. Hung,

The above issue had been fixed as we had error in the code. Now we have been having a smooth communication between the PTX and PRX without any messages getting lost.

However, is there a way to reset the NRF module by the microcontroller (any command or configuring any register since we dont have any reset pin directly between them). Because the PTX sometimes seems to stop sending the data so can it be reseted by the MCU so that it can start sending again.

[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