Timeslot api - how to set an event handler

[eyalasko]

Hi, 

I'm trying to implement timeslot api in my app and have 2 questions:

1. Referring to this article describing timeslot api, in step 8 the text says to add the timeslot's event handler to the system dispatcher.
   As the article is based on SDK11 while my app using SDK15,  I've tried to replace the instruction with the following:
   

   NRF_SDH_SOC_OBSERVER(m_timeslot_observer, 0, nrf_evt_signal_handler, NULL);

   
   at the beginning of timeslot.c
   
   However, it seem that my event handler is not triggered... (I've tried to force it to trigger by returning an invalid return code from the callback)
   
   What is the correct way to 'hook' nrf_evt_signal_handler on current SDK ?
   
   
2. The app moves between two 'modes': active & idle.
   Each time the app enters active mode, I call sd_radio_session_open() to create/re-open a session and 
   once the app moves to idle mode I call sd_radio_session_close().
   
   On first cycle both work fine (err_code=0)
   On next cycle when calling sd_radio_session_open() it generates NRF_ERROR_BUSY error as if the session was not closed properly even though it returned 0.
   
   The documentation mentions that the session is closed only after NRF_EVT_RADIO_SESSION_CLOSED is fired, however per issue 1 above, I can not verify it did close.
   
   My question is - how long it may take a session to close (I'm waiting 100s of ms at least) ? Are there any pre-requisites for closing a session ?
   Are there other reasons for NRF_ERROR_BUSY upon opening a session other than session that was not closed properly ?

Many thanks for any advice

[ovrebekk]

Hi

There is a limited number of timeslot examples available unfortunately. I colleague of mine wrote this one for SDK v14.2.0, which is one of the later ones I can find. 

Please have a look at it, and see if it can provide some guidance. 

1) Your call to the observer macro seems mostly correct, but I am a bit unsure about your reference to the nrf_evt_signal_handler. 

When using the timeslot API you will need two different handlers. One for timeslot signals, and one for system events. 

If you look at the example I linked to above they have the following names and arguments:

static nrf_radio_signal_callback_return_param_t * radio_callback (uint8_t signal_type);

void ts_on_sys_evt(uint32_t sys_evt, void * p_context);

It's the second one you should point to from the observer macro, not the first, and if you mix these up it will surely not work as expected. 

2) The session should be closed as soon as any currently running timeslot is ended, so it should definitely not take hundreds of milliseconds. 

I think we should start by fixing the first issue, and then it should be obvious if there is a problem closing the session. 

Best regards
Torbjørn

[eyalasko]

Thanks Torbjørn, I've managed to get it going

I have several follow up questions:

1. Does the session MUST be closed when current running/pending timeslot ends (on NRF_EVT_RADIO_SESSION_IDLE signal fired after returning NRF_RADIO_SIGNAL_CALLBACK_ACTION_END in the callback) ?
   In other words - Can't a session remain open and sd_radio_request() called sometime in the future without requiring closing-reopening a session ?
   
   
2. I've noticed that timeslot occasionally blocks (NRF_EVT_RADIO_BLOCKED event) after it has been successfully granted using sd_radio_request(). 
   Why is it blocked after being granted - isn't the BLE protocol predictable (given no change in the current BLE activity e.g. advertising or connection)
   Is there a way to tell when is the next available timeslot that won't be blocked ?
   
   
3. Further to 2 above, can timeslot be blocked after it has started ?
   
   
4. On what scenario will NRF_EVT_RADIO_CANCELED be fired. What can cancel (rather than block) an ongoing timeslot. 
   Can this happen after the timeslot has started ?

Thanks again

[ovrebekk]

Hi

1. Sure, you can keep the session running in between timeslots, but you can only have one session running at the time. If you have multiple modules in your system that requires timeslots you need to close the session in one before you can open it in the other. 

2. You don't really know in advance what the device you are connected to will do. If you receive some kind of command or request from the peer device it might trigger additional data processing and radio activity. 

Also, there are various side activities that could happen sporadically, such as accessing flash, calibrating the 32kHz RC oscillator, or generating random numbers for use during an encrypted connection. 

You can't really ask for a timeslot that is guaranteed not to be blocked, but if you ask for a timeslot at the earliest possible moment then it reduces the chance of a block occurring. 

3. No. Once you are in a timeslot you will not be interrupted. 

4. A timeslot is BLOCKED if you try to schedule it at the same time that something else is already scheduled. 

A timeslot is CANCELED if a higher priority event is scheduled after  occurs after your timeslot was scheduled. 

None of these will happen after the timeslot has started, as mentioned in 3. 

For more information on the various timeslot events, please refer to the documentation. 

Best regards
Torbjørn