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]

Thank you Mr. Hung,

I'd like to bring something in notice.

Hung Bui said:

As of now, how do you disconnect the PTX from the current PRX so that it can talk to the new PRX ? 

Well, currently, we don't have the provision to disconnect the PTX from the current PRX. We just simply disconnect the connecting device (since the PTX is mounted on it) physically and connect it physically to the other arm to talk to a new PRX.

What we can do is, we can assign an unique number for every PTX which will be used as their sending and receiving address. By this, every PTX will have an unique number to which their sending and receiving address will be configured.

However, the PTX can't be provided the unqiue number from display or keypad. (since its mounted on a connecting device separately.)

So is there a way we can change the configured address (sending and receiving address) of a PTX ? Like by any app or something ? 

Does it have any default sending and receiving address ? which we can keep as it is during the development phase and change during the production ?

Or can we just not configure its addresses from its MCU so that we will be able to configure or change it anytime later ?   

      

   

[Hung Bui]

Hi Harshal, 

I don't really understand your idea of having unique PTX address would do any help here. 
It's the PRX address which is the important. 

If the distance between the PTX and PRX is close enough, you can think of using the same address on all PRX devices but reduce the TX Power of the PTX (-18dBm) so that if it's detached from the Machine Arm and plug to a new Machine Arm the package from the PTX will not reach the previous PRX. 
This only works if there is a large distance between the Machine ARM. So that when you bring PTX from one Machine Arm to another Machine Arm it will not in the range any more. 

Another option is to do "pairing mode" only when the device just booting up. For example if the PTX in the close proximity of the PRX in the first 5 seconds after it power up, it will follow the address of the PRX. This require you configure the same "pairing address" on all PRX (pipe 2 for example) and then do transmitting on this pairing address in the PTX in the first 5 seconds after booting up. 

[Harshal Kadlak]

Thanks Mr. Hung,

We'll give a try to this and see how it goes for our application.

[Harshal Kadlak]

Hello Mr. Hung,

Can we set the payload length to 30 bytes?

Because with that length sometimes the packets are getting lost !!

[Hung Bui]

Hi Harshal, 
The maximum payload for ESB is 32 bytes. So I don't see a problem increase the payload length to 30 bytes. 
Of course there could be higher chance of interference when you transmit longer payload package. But that shouldn't be significant. 
How often do you see the packet getting lost ? Do you use dynamic payload length or not ? 

[Harshal Kadlak]

Hello Mr. Hung,

Hung Bui said:

How often do you see the packet getting lost ?

It was happening with one or two out of every 15-16; but managed and fixed it.

Hung Bui said:

Do you use dynamic payload length or not ? 

No we don't use dynamic payload length.

[Harshal Kadlak]

Hello Mr. Hung,

Why do the messages get lost from the PTX side?

What could be the possible reason ?

We managed this at the receiver side but still we face the issue of losing the messages when transmitted.

[Hung Bui]

Hy Harshal, 
Could you explain what you meant by " messages get lost from the PTX side" ? 
How do you find that ? Please give more detail, for both PTX and PRX. 

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