Sending Packet latency over BLE

[jawadk]

Hi,

The system has an nRF52840 as a BLE USB Dongle plugged to a PC, and connected by BLE to another device (another nRF52840).

I measure the latency time between the time the dongle sends a BLE packet until it arrives to the connected device.

The BLE connection Interval is 7.5 ms. ( I configured the max and min connection interval to 7.5 ms and the two devices managed to set the connection interval to 7.5 ms successfully)

I ran the latency test 10 times, then turned off the connected device, and turned it on again and ran the test another 10 times.

The latency measure by a scope connected to two pins, one on the dongle raised before sending a packet, and the other pin is on the connected device raised when a packet received, the latency also measured and verified by the BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event from the Dongle.

The results for the latency between the time the dongle sends a packet until it arrives to the connected device is as following:

1. 13.5 ms
2. 34.8 ms
3. 56 ms
4. 49 ms
5. 5 ms
6. 51.4 ms
7. 17.8 ms
8. 9 ms
9. 8.2 ms
10. 9 ms

Turned the connected device  off and on

1. 5 ms
2. 44.4 ms
3. 7 ms
4. 6 ms
5. 22.4 ms
6. 2.8 ms
7. 47.6 ms
8. 9.2 ms
9. 65 ms
10. 47 ms

So we expect to have latency up to 7.5 ms or maybe 15 ms max, please correct me if I am wrong.

We want to know why we got a latency greater than the expected latency, and how can we improve it to be the minimal latency.

Best Regards

JK

[Karl Ylvisaker]

Hello JK,

The BLE connection Interval is 7.5 ms. ( I configured the max and min connection interval to 7.5 ms and the two devices managed to set the connection interval to 7.5 ms successfully)

Did you use the slave latency in your tests?
Slave latency will let the peripheral device ignore upcoming connection events for a number of times, if it has no new data to send.

So we expect to have latency up to 7.5 ms or maybe 15 ms max, please correct me if I am wrong.

Yes, I would expect values in the 1 - 7.5 ms range - since you might queue a packet for sending immediately after the previous connection event ( 7.5 ms ), or immediately before the next ( < 1 ms ).
I therefore suspect that something might be wrong with the test setup, rather than the BLE transmissions.
Are you familiar with the nRF Sniffer tool? It is a powerful tool for BLE Development, which lets you monitor on-air traffic and packet exchanges.
Could you provide a sniffer trace of the communication during the test? This will lay out the exact times that the packets are sent and received.

The latency measure by a scope connected to two pins, one on the dongle raised before sending a packet, and the other pin is on the connected device raised when a packet received,

What was the priority used for your pin-setting callback?
This will not provide accurate results of the packet sending and reception, since this will only happen once that particular callback gets to execute. This is not representative of when a packet actually arrived, since the SoftDevice takes priority over any application-layer tasks for timing critical operations, so the application will not be given back access to the CPU before the SoftDevice has finished all its timing-critical tasks.
The SoftDevice's timing critical tasks are however not longer than 1 ms ( unless you are dealing with multiple connections ), and could therefore not alone be the reason for the very long delays you are seeing in pin-toggling.

It would be very helpful to get a sniffer trace of the communication during the test, so we may see what is actually being sent on air, and at which intervals it is sent.

Best regards,
Karl