How close can timeslots be scheduled?

[Bjorn191023]

Hi,

I want to schedule timeslots back-to-back, or as close as possible. Question is how close to eachother timeslots can be scheduled?

I read the following about sd_radio_request() at https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s140.api.v7.2.0%2Fgroup___n_r_f___s_o_c___f_u_n_c_t_i_o_n_s.html&anchor=ga3fbd3ade121c15745cc19b900ce8154b:

"A too small p_request->distance_us will lead to a NRF_EVT_RADIO_BLOCKED event."
1) What is the minimum distance?

"Timeslots scheduled too close will lead to a NRF_EVT_RADIO_BLOCKED event."
2) What is "too close" meaning what is the required minimum time from calling sd_radio_request() until the timeslot is due?
3) What is the required minimum time from returning NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END from the signal handler until the timeslot is due? Same as question 2 above?

I have done some measurements, where I request a new timeslot from the signal handler as close as possible to the current:

With NRF_RADIO_HFCLK_CFG_NO_GUARANTEE:
175 us until next timeslot is due => WORKS
165 us until next timeslot is due => DOESNT WORK

With NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED:
295 us until next timeslot is due => WORKS
285 us until next timeslot is due => DOESNT WORK

So my measurements suggest the response to question 3 above is:
a) 170 us with NRF_RADIO_HFCLK_CFG_NO_GUARANTEE
b) 290 us with NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED

This is longer than I would expect.

Please provide official specifications!

I'm running on a nRF52840 DK.

SDK ver 16.0.0

S140_nrf52_7.0.1

BR / Björn

[Simonr]

Hi Björn

Would you mind explaining a bit more about your application? What would be the advantage in closing and opening a timeslot again and again over just extending one single timeslot when/if you need more time? Could you also explain how your scheduler is set up? I suggest taking a look at our Timeslot API set-up guide here for some more details on timeslots and timeslot usage.

As for the numbers between timeslots, I haven't been able to track them down yet, but I'll keep digging and come back to you when I find something.

Best regards,

Simon

[Bjorn191023]

Hi Simon,

I'm glad to explain if that helps you help me ;-)

We have a number of sequential TX events, T_IFS apart, so very close to eachother. Envision a BIG, consisting of a number of BIS events, each in turn consisting of a number of sub-events. This shall co-exist with the nRF BLE stack in the SoftDevice. We want to minimze the number of lost TX events due to scheduling conflicts.

There are three strategies to handle this with your timeslot mechanism (please let me know if there are more):

1) One long timeslot containing all events
Pros: simple and full control over timing
Cons: Sched conflicts more likely and all events lost in case of conflict

2) An initial short timeslot that is extended for each TX event (what you propose)
Pros: Sched conflicts less likely and not all events are lost in case of conflict
Cons: In case of conflict all sub-sequent events are lost

3) One short timeslot per TX event (what I'm trying to do)
Pros: Sched conflicts less likely and not all events are lost in case of conflict. The advantage over 2 is that since each TX event has it's own timeslot sub-sequent events can be scheduled even in case of a conflict. So in my mind, this approach gives maximum probability that I can schedule a TX event.

I attach the example project containing my scheduler setup. You find it ts_sample_b2b.c. It toggles all LEDs. By tuning the following constants you can make it work or fail.

//#define HFCLK_CONFIG NRF_RADIO_HFCLK_CFG_NO_GUARANTEE
//#define TIMER_LENGTH_US (320)

#define HFCLK_CONFIG NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED
#define TIMER_LENGTH_US (200)

Hope this helps understanding my need. I'm awaiting your response.

BR / Björn

2072.ble_app_beacon_ts.zip

[Simonr]

Hi again Björn

I discussed this with one of our "timeslot experts", and in order to get the next timeslot event as close as possible to the last one, we suggest using the nrf_radio_request_earliest call to get the next timeslot as early as possible. Unfortunately, it doesn't seem like we have any definition on how short this is, and we can't guarantee any shorter intervals than what you are already seeing for NRF_RADIO_HFCLK_CFG_NO_GUARANTEE or NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED.

Our expert also suggest using a combination of this "earliest" call between timeslots and extending them for the best behavior. I don't see why the separately requested timeslots would "give TX its own timeslot sub-sequent events", as I think the SoftDevice won't stop in the middle of an extended timeslot to get the radio back once requested either way.

Best regards,

Simon

[Bjorn191023]

Hi Simon,

Sorry, we cant use earliest since we need exact timing on micro-sec level between BIS-events. So normal is required.

I understand your response so that it's not possible to schedule separate timeslots with 150 us between. Thanks, then I know, even if I was hoping for another answer ;-)

BR / Björn