Best way to know when timeslot is about to start?

[a_87]

Hi all,

We are currently working on an application that uses the timeslot API, and requests timeslots spaced 20ms apart.  

In our application we need to trigger some functions right before the next timeslot starts (while softdevice operations are still available, e.g. stopping advertising).

Right now we do this through a timer that fires some N ms before the next timeslot (assuming the timeslot request is accepted), but is there a better way? 

Thank you!

[Jared]

HI,

In our application we need to trigger some functions right before the next timeslot starts (while softdevice operations are still available, e.g. stopping advertising).

I'm not sure I understand your intention of using timeslots, could you elaborate a bit more?

Right now we do this through a timer that fires some N ms before the next timeslot (assuming the timeslot request is accepted), but is there a better way? 

 I actually think a timer in combination with a flag that signalizes if the next timeslot is granted or not is a good method. The Softdevice signalizes if the next time slot is granted or not in the end of the current timeslot. 

regards

Jared 

[a_87]

Hey Jared,

Thank you for the reply!

Our application acts as a sort of BLE gateway to a network of ESB devices. It uses timeslots to switch over to ESB and sample the ESB network for 5ms (timeslot length) and then sends this information out through BLE notifications. This happens approximately every 20ms (normal timeslot request interval).

We'd prefer that this "sampling" timeslot runs as close to every 20ms as possible, but we've noticed that continuous advertising causes timeslot requests to occasionally be rejected.

However, we've found that if we start advertising after the end of the previous timeslot, and stop advertising before the start of the next timeslot, the timeslot requests seem to be accepted without issue. Thus the question about an event that fires right before the start of the next timeslot. 

[Jared]

Hi,

Thank your for a good explanation :) From Softdevice specification : "Advertiser is started as early as possible, after a random delay in the range of 3 - 13 ms, asynchronously to any other role timing-events. If no roles are running, advertiser timing-events are able to start and run without any collision."

My guess is that this random delay is causing your timeslots to be rejected sometimes. 

a_87 said:

However, we've found that if we start advertising after the end of the previous timeslot, and stop advertising before the start of the next timeslot, the timeslot requests seem to be accepted without issue.

Ok, so you're planning to advertise in between timeslots? My initial guess is that 20 ms is a too small interval for the Softdevice to start advertising before it needs to stop it. The Softdevice needs to queue the operation before it executes it, which means that you have the queueing delay + the random delay which makes it very difficult to schedule something in between the timeslots.