Bidirectional Gazell/ESB communication when sometimes only one of the two units is sending packets

[Vince C]

Hi, 

I'm working on a project where I want two units to be able to wirelessly send packets to each other whenever they need to. Sometimes only one of the two units may be sending packets.

Looking at the documentation for bidirectional communication with Gazell, it seems that in a host/device configuration the host uses the ACK packet to send it's payload. So if the unit configured as device is not sending any packets, then the host cannot send packets.

I've also looked at the ESB protocol and the behavior seems to be the same (primary receiver attaches its payload to the ACK packet).

Is there a way to have both units be able to send packets whenever they need to, no matter if the other unit is sending packets?

I'm using with the nRF54L15-DK with nRF Connect SDK v2.8.0 if that helps with anything.

Thanks!

[Håkon Alseth]

Hi,

 

ESB can send bi-directional packets with the help of ACK payloads, as you mention.

Is there a way to have both units be able to send packets whenever they need to, no matter if the other unit is sending packets?

This will require application specific ESB protocol changes, to manually switch from PRX -> PTX and vice-versa.

 

One common way of implementing bi-directional communication is to send periodic "polling payloads", but this heavily depends on what your timing requirements and throughput requirements are.

 

Kind regards,

Håkon

[Vince C]

Hi Håkon, thanks for your answer.

I would prefer not to send periodic "polling payloads" as this is a battery operated device so I would like to minimize unnecessary communication.

I will try the solution of manually switching between PRX and PTX.

I found another discussion online suggesting to put both units in PRX and to switch a unit to PTX only when it needs to transmit something, and then switch it back to PRX.
Do you think that this is a solution that could work?

[Håkon Alseth]

Hi,

 

Vince C said:

I found another discussion online suggesting to put both units in PRX and to switch a unit to PTX only when it needs to transmit something, and then switch it back to PRX.
Do you think that this is a solution that could work?

Yes, this is one solution, by manually switching modes. 

Keeping the device(s) in the default PRX state is not low power. If your battery powered device switches to "PRX" for a longer period, it will cause quite a high overall current consumption.

How often do you normally send, and how much data do you need to transfer in this "reverted" scenario?

 

Kind regards,

Håkon

[Vince C]

I'm expecting the units to be in PRX and PTX state for about an equal amount of time, so 50% of the time in PTX and 50% in PRX.

The units will send packets of about 20 bytes of data. I'm still trying to see what is possible, but hopefully I can get the units to send a packet about every 1ms, and faster if possible.

[Håkon Alseth]

Hi,

 

Thank you for elaborating on your use-case.

If you plan to send a payload every 1 ms, why not use ACK payload for bidirectional communication? 

Especially if you have strict timing requirements in under 1 ms, switching the devices manually (ie. not using auto-ACKing) to TX->RX (and vice-versa) for communication will highly likely exceed your timing requirements.

Is there anything I am misunderstanding related to your scenario?

  

Kind regards,

Håkon