Softdevice BLE internal buffering

RE: Softdevice BLE internal buffering

tvik81 — Thu, 28 Aug 2025 13:53:42 GMT

OK, clear. Thanks for the explanation!

RE: Softdevice BLE internal buffering

Hung Bui — Thu, 28 Aug 2025 08:08:32 GMT

Hi Viktor,
I would need to have some more info about your central to tell what exactly going on here. What are you using the radio notification on the central for ?

[quote user="Viktor Timkov"]In general - is there a way to make sure that the data is sent each connection interval. In my case, even though the data is pushed once each connection interval, occasionally (each 10-15 seconds) the connection interval is skipped and two data packets are sent the next connection interval[/quote]

I don't think there is an option for that. I was thinking of limiting the size of the buffer to only one packet. So that you have control over the queue and only one packet to be sent per connection event. But that feature is not available on nRF5 SDK. It's available on nRF Connect SDK.
What you can do is to queue only one packet at a time and immediately queue the next packet when you receive the event that notification has been sent.

RE: Softdevice BLE internal buffering

tvik81 — Wed, 27 Aug 2025 13:27:17 GMT

Controversially, it turns out that cause was that T_ndist in the central was set to 2680us. When I decreased it to 800 us the data is sent the nearest connection interval. Thanks for the hint, you give me the right direction to dig in!

In general - is there a way to make sure that the data is sent each connection interval. In my case, even though the data is pushed once each connection interval, occasionally (each 10-15 seconds) the connection interval is skipped and two data packets are sent the next connection interval

RE: Softdevice BLE internal buffering

Hung Bui — Wed, 27 Aug 2025 09:00:53 GMT

Hi Viktor,
I think there can be a race condition here. If you trigger a radio notification at the exact time when the stack planning to wake up and handle the connection interval, there could be not enough time for the CPU to queue the data to the stack and then the stack schedule the packet into the connection event.
The scheduling to send a packet in a connection would need to happen before the actual radio activity occurs.
Have you used the T_ndist to set a distance before the connection event occurs to queue the data ?

(Chapter 11 in S140 softdevice specification)