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. 

[Hung Bui]

Hi again Harshal, 

Please explain what you meant by "connected" in this sentence: "If a connecting device is connected to the machine's arm," 
Do you bring the connecting device and plug it in the machine arm ? When plugging like that is there any connection like UART/SPI/I2C ? 

Or do you mean "connected" here is the radio connection ? 

If it's the radio connection, there must be something you need to do to tell the PTX to connect to a particular PRX, for example by bringing them very close together or use a keyboard/display to type a serial number or something. 

[Harshal Kadlak]

Hello,

Yes, we do bring the connecting device and plug it in the machine arm to have a physical connection. There is no communication like UART/SPI/I2C interface and nor does the "connected" mean the radio connection. Its just a mechanism to have a physical connection between the machine's arm and the connecting device in order to form a pair of the machine's PRX and the connected device's PTX.  

   

[Hung Bui]

Hi Harshal, 

If you have no electrical connection between the Connecting Device" and the Machine Arm you would need to find a way so that the PTX and the PRX can detect each other when they are in close proximity. 

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

Do you have a button on the PTX ? If you do I'm thinking of you can press the button so that it will remove the current PRX address and start a "pairing mode". In this pairing mode it will only transmit with very low TX power. The lowest the L01+ can do is -18dBm, see section 6.5 PA control in the spec. 

By doing -18dBm the packet from the PTX can only be received by near by PRX.

On the PRX, you can setup a pipe, for example pipe 2 that has the same address on all PRX. It's the common "pairing " address. So when a PTX in pairing mode is close by, the PRX can receive this packet from the PTX looking for a new PRX to pair with, the PRX then can send it unique address to the PTX (in the ack payload). 
From that the PTX will turn off pairing mode and start communicating with the new PRX. 

Note that you also have the RPD bit (Received Power Detector) on the PRX that can detect when a PTX is near by. So that you can limit it to only close by PTXs. But this doesn't work if the PTX transmit with high power. 

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