Hello,
previously I was using the nRF Connect SDK v2.3.0. I have an application that is using the MPSL library where I am requesting a new earliest timeslot (with a duration of 3 ms) about every 250 ms. As the used BLE connection interval is 20 ms I typically never had any issues getting and executing the timeslot. Inside the timeslot I am using the radio, but it is still not critical when exactly the timeslot is executed. For this reason I was using the priority MPSL_TIMESLOT_PRIORITY_NORMAL. So, I typically got the timeslot every time, just sometimes scheduled a little bit later after a finished BLE interval. The main reason for the used priority is that I want to still ensure that the normal BLE traffic via the SoftDevice is prioritized over my timeslot. However, since the upgrade to nRF Connect SDK v2.4.2 I am constantly getting most of my requested timeslots cancelled. They seems that they always get scheduled but then cancelled due to a BLE event from the SoftDevice. In the old SDK version I always got the timeslot, just probably a little bit later after a BLE event.
In general it seems that changing the priority of my timeslot to MPSL_TIMESLOT_PRIORITY_HIGH solves the problem by still not interfering with the SoftDevice. I also did some tests with lowering down the connection interval and also requesting timeslots more often (even several times inside a BLE connection interval) which seemed to be working without leaving out BLE transmissions (at least as long as I did not make the timeslot duration longer than the BLE connection interval).
Even though using the high priority timeslot seems to fix my problem, I still want to ask whether there has been an (intentional) change to the functionality of the MPSL that causes the described behavior? (I at least did not find something in the release notes.)
And whether it is correct as derived from my experiments that the SoftDevice still has a higher priority over my high priority timeslot?
