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.

[DX_HK]

I'll add one more.
Q3
In the sample code (gzll_ack_payload_device/gzll_ack_payload_host), the sending cycle is approximately 166Hz.
According to the code, a new packet is sent immediately after the transmission is completed. Therefore, it seems to be sending at the maximum speed of gazell.
What factors determine this 166Hz transmit cycle?

[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