How close can timeslots be scheduled?

RE: How close can timeslots be scheduled?

Bjorn191023 — Mon, 21 Sep 2020 10:22:02 GMT

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

RE: How close can timeslots be scheduled?

Simonr — Mon, 21 Sep 2020 09:14:14 GMT

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

RE: How close can timeslots be scheduled?

Bjorn191023 — Fri, 18 Sep 2020 07:44:55 GMT

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

devzone.nordicsemi.com/.../2072.ble_5F00_app_5F00_beacon_5F00_ts.zip

RE: How close can timeslots be scheduled?

Simonr — Thu, 17 Sep 2020 12:37:07 GMT

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