Improved Gazell performance and stability

RE: Improved Gazell performance and stability

Asbjørn — Tue, 19 Nov 2024 13:20:28 GMT

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

RE: Improved Gazell performance and stability

DX_HK — Tue, 19 Nov 2024 02:41:30 GMT

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

RE: Improved Gazell performance and stability

Asbjørn — Mon, 18 Nov 2024 15:11:15 GMT

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

RE: Improved Gazell performance and stability

DX_HK — Mon, 18 Nov 2024 02:08:05 GMT

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.

RE: Improved Gazell performance and stability

Asbjørn — Fri, 15 Nov 2024 15:36:06 GMT

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

RE: Improved Gazell performance and stability

DX_HK — Fri, 15 Nov 2024 05:03:36 GMT

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?