Improved Gazell performance and stability

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.

Parents
  • 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?

Reply
  • 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?

Children
No Data
Related