I'm developing a peripheral with s132 v5.1.0 that supports multiple concurrent connections. I've looked at section 15 of the SoftDevice Spec and I have a couple of questions.
Section 15 of the SoftDevice Spec says "Activity B will be blocked and its timing-event will be rescheduled for a later time". What will this "later time" be? Simply the next time the timing-event would normally fire? For example, if the timing-event for an advertiser-role with an interval of 1s collides with the peripheral-role timing-event that was already scheduled, will there be just 2s between the advertising packets being sent?
Also, is there a way for the application to be notified of such a collision?
Section 15 of the SoftDevice Spec says "Activity B will be blocked and its timing-event will be rescheduled for a later time". What will this "later time" be?
OK, I see your doubt here. When two roles are participating in a scheduling, they normally ask the scheduler for the timeslot. For example if the
scanner with scan window = 10ms , scan interval = 50ms and
an existing connection with connection interval of 500 ms are participating in the scheduling asking for the time at the exact timeslot (collision), then for example the scheduler gives that time slot to the scanner (connection looses that round with the scheduler).Here due to the specifications, the connection will not participate in the next round of scheduling after the scanner is finished after 10ms. This is because the connection event would not like to start at a delay of 10ms. It would rather miss that slot but request a timeslot after 490 ms which it most likely would get. This is ok as there is supervision timeout and slave latency that alows a device to miss few connection events. When the role looses many time in scheduling and then the supervision timeout of the connection is about to expire, then the scheduler gives highest priority to the role so that it does not disconnect.
connection and adv roles if loses in the scheduling , they would be participating for the next interval of this respective role.
scanner if it looses in the scheduling, would be participating for the next available timeslot after the lost round.
And there is no callback or anything for collisions, correct? I'm not sure how we would use them in my application, but it would be "nice to know".