Radio events scheduling problem

Hello

In our application (NRF52840, softdevice S140 v7.3.0, master device with multiple connections) we are experiencing some strange behaviour related to scheduling of radio events (sending packets to slaves, scanning) leading to loss of packets. According to this specification:

https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/central_connection_timing.html

SoftDevice should take care of queueing radio events by itself, in a way to fill empty radio space with connection events related to another slave devices.

Central link timing-events are added relative to already running central link timing-events. Central link timing-events are offset from each other by tevent depending on the configuration of the connection.

To point it out more clearly, we expect a situation presented in a picture below. We checked and it works like that in example applications (Multilink Central connected with BlinkyLed devices)

Meanwhile, the situation we observe in our application looks like shown on a second graphic:

It looks like softdevice takes the highest interval from connected devices and make a queue, where during one period (lasting this interval) there could be radio events related to only one device. It looks the same with more connections, or without scanning. For example if we have one connection with interval 400ms, and one with 50ms, we observe one radio event in 400ms, and then 8 radio events (400ms/50ms = 8) for next 400ms. With many connections it leads to high loss of packets.

Code is quite complex to share, so we are wondering - what could be the reason for that behaviour? Is there any setting on a SoftDevice side, which can have an impact on it?

Some additional info:
1. For both example app and our app connections parameters are exactly the same (and they are the same for all connections in one app)
2. Loss of packets is verified with Sniffer
3. Inspecting of radio events is made with Radio Notification interrupt - same code for our application and example application so doesn't look like a reason

Parents Reply Children
No Data
Related