ble configuration for low latency applications?

[David Chan]

Hey, I'm working on a real-time body motion capture project and using nRF52832 as BLE MCU. In the system I have 3 IMU sensors to transmit sensor data to an Android device (central device), each sensor packet is 20 Bytes long.

My goal is to achieve >= 30Hz overall pose refresh rate, i.e. transmission of 3 packets from the 3 IMU sensors should be completed within 33ms. Theoretically this is possible since the connection interval can be as low as 7.5ms. But I'm wondering is there a way to guarantee the 30Hz rate? I'm asking this because there multiple connections to the central device, while Android does not always schedule notification events in the same order. 

Another related question, in the multilink scenario how does the central device handle multiple notifications received at the same time slot from different peripherals? If 3 peripherals sending notify to the central simultaneously, only the one whose connection interval is active will be correctly received. Is this understanding correct? 

Instead of notify I'm also thinking about using read, using which the Android device can send read request every 7.5ms to each of the sensors. But in this case the read response from sensor may not always be in time according to https://devzone.nordicsemi.com/f/nordic-q-a/25036/why-a-ble-read-takes-significantly-longer-than-the-connection-interval

I'm quite new to BLE and would highly appreciate if anyone could share some tips to lower latency in multiple-connection scenario.

[Susheel Nuguru]

Hi David,

Theoretically this is possible since the connection interval can be as low as 7.5ms. But I'm wondering is there a way to guarantee the 30Hz rate?

Like you already mentioned it is possible to use 7.5ms of connection interval and hence you can theoretically get more than 30Hz of data. We cannot guarantee this from the BLE stack or solution end because you application is responsible to make sure that the data is being sent out at the maximum application priority with pre and post processing of data kept to a level that allows your application to send data faster. The BLE stack can guarantee that when the data is queued to the TX buffer, then it sends the data/acknowledge/nacking according to the specification.

Another related question, in the multilink scenario how does the central device handle multiple notifications received at the same time slot from different peripherals? If 3 peripherals sending notify to the central simultaneously, only the one whose connection interval is active will be correctly received. Is this understanding correct? 

Three peripherals cannot possibly send the notification to same peer in the same timeslot. The anchor points for the three different connection events will be different at the time of connection establishment. If there are connection with different connection interval and at one instance there is point where more than one event collide over each other, then only one event will be handled and the other connection data is just considered not received. The peer's link layer will then resend the data again in the next connection event. In short, the once the application queues it to the TX buffer, the multilink transfer is handled by link layer and the application do not need to worry about the timeslots of sent notifications being same or not.

Instead of notify I'm also thinking about using read, using which the Android device can send read request every 7.5ms to each of the sensors. But in this case the read response from sensor may not always be in time according to https://devzone.nordicsemi.com/f/nordic-q-a/25036/why-a-ble-read-takes-significantly-longer-than-the-connection-interval

there are fewer time critical work in the BLE stack layers above the link layer. So yes, the reads can be slower in this case than using notifications.

[David Chan]

Thanks a lot for quick response.

I have tuned CI to 11.25ms (min value allowable on my Android device) with two peripheral devices. The avg packet rate matches my expectation. However often times there are multiple (2~4) packets sent within one CI, leading to long latency between two CI events for the same peripheral. As mentioned before latency is key in my project.

Wondering if possible to force timely transmission of packets? 

[Susheel Nuguru]

You need to set the event length within a connection interval is fits only one packet in the connection event.

If your event length is big enough to fit multiple packets in the same connection event, then the BLE stack will try to fit multiple packets into the same event. 

You can check for example this thread to see how to set the connection event length for a single connection (Assuming you are using nRF5 SDK and a Softdevice BLE stack).