Improved Gazell performance and stability

[DX_HK]

I am an embedded software engineer and have experience developing BLE devices with nRF5SDK, but this is my first time using Zephyr/NCS.

I am developing a USB dongle (nRF52840) for computers and a controller (nRF52840).

As a basic configuration, multiple controllers need to be connected to one dongle.

Data from each controller is sent at about 100Hz (60Hz at worst, the faster the better). The maximum number of controllers is 8 (the upper limit of gazell). Latency must also be sufficiently small.

About power consumption: The dongle is unlimited. The controller is battery-powered, but it is not required to operate for long periods of time, so there is no need to think about power saving.

About hardware: I am sure that better results can be obtained by choosing a larger antenna, but improving the communication quality from a hardware perspective is not on the agenda at the moment.

Question 1:

Gazell has semi-synchronous and asynchronous modes. Based on the documentation, it seems that the asynchronous mode is better for my use case.

However, in asynchronous mode, it seems to be random whether the listen timing of the dongle (host) and the transmission timing of the device match. Also, if there are multiple transmitting devices, the host should fail to communicate if the transmission timing of two or more devices match.

Semi-synchronous mode solves these problems, so I think it will provide higher quality communication.

Which mode should I use?

Question 2:

 Is it possible to identify which controller sent the data based on the Gazell protocol?

Currently, I plan to adopt the gazell protocol, but other options (BLE, ESB) are not lost. Please let me know if other protocols are more appropriate.

[Asbjørn]

Dear Kanai,

Q1:  Since you have power available and more dependent on reliability, the semi-synchronous mode would be your way to go. Unfortunately the clock drift will send multiple synchronous devices towards the same and start interfering with each other, so in general we recommend to stick with one device having a synchronous pipe/channel defined and rest set up with asynchronous. There might be some overlap and collisions, but with your update requirement, there should be time for all to get through.

Q2: Yes, you can keep track of the addresses used by the controllers. The ACK from the dongle will use that address and you can extract that information on the dongle side and hence know who the source was. Just configure the controls to use different addresses in their configuration.

Q3: The factor is the round time for a packet to be sent, switch to RX mode and receive the ACK, then switch back to TX and send next one. So with a full payload at 1Mbit/s it's about 560us to send, switch, receive ACK and switch to TX. With a bit extra overhead it results in about 166Hz.

Best regards

Asbjørn

[DX_HK]

Dear Asbjørn,
Thank you for your answer.

Is it practical to use asynchronous mode and have the application control the transmission timing to prevent packet collisions?

Example: If there are 4 controllers,
Controller 1 → Controller 2 → Controller 3 → Controller 4 → Controller 1....
The data is sent to the dongle in order, and the dongle sends the timing discrepancy to the controller to adjust it.

[Asbjørn]

Dear Kanai,

The short answers is yes, trying to avoid collision is a good strategy, but it can become complicated to maintain as the devices drift a bit in time and they'll start overlapping. That's why we have the recommendation to only have one semi-synchronous device connected and the rest as asynchronous. You can of course try with define more as semi.synchronous, but the protocol isn't built to handle clock drift, so at some point they will become a problem for each other. It's a trade of between protocol complexity and acceptable package loss and retransmits. I'd suggest you try to define some time slots and try the semi-synchronous mode and compare the performance if you have them all as asynchronous or all but one as asychnronous. 

Best regards

Asbjørn

[DX_HK]

Dear Asbjørn,
Okay, I'll implement the application and evaluate it.
Thank you for answering my question.

[Asbjørn]

Dear Kanai,

happy to help and I hope you find some result you are ok with. Let us know if you have any further questions.

Best regards

Asbjørn