RE: Sending Packet latency over BLE

Karl Ylvisaker — Wed, 02 Dec 2020 09:30:40 GMT

Hello JK,

[quote user=""]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)[/quote]

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.

[quote user=""]So we expect to have latency up to 7.5 ms or maybe 15 ms max, please correct me if I am wrong.[/quote]

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.

[quote user=""]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,[/quote]

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