Hello there,
Since we use the lower level modules from Nordic's SDK for Mesh 4.2.0 - namely timeslot.c, bearer_handler.c and some additional modules to make them work properly - I have stumbled upon an implementation detail in these modules, that I struggle to get my head around:
In bearer_handler.c, line 219, you'll find the following code:
if (p_action && (p_action->duration_us + BEARER_ACTION_POST_PROCESS_TIME_US) > total_time)
{
/* The current timeslot doesn't have space for this action, restart the timeslot to get a longer one. */
timeslot_restart(TIMESLOT_PRIORITY_HIGH);
}
This essentially results in populating the nrf_radio_request_t structure with these values:
m_radio_request_earliest.params.earliest.priority = NRF_RADIO_PRIORITY_HIGH; m_radio_request_earliest.params.earliest.length_us = NRF_RADIO_LENGTH_MAX_US; m_radio_request_earliest.params.earliest.timeout_us = NRF_RADIO_EARLIEST_TIMEOUT_MAX_US;
and ending the current timeslot prematurely by setting the corresponding return values for the radio signal handler:
p_timeslot->signal_ret_param.callback_action = NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END; p_timeslot->signal_ret_param.params.request.p_next = &m_radio_request_earliest;
From the comment in bearer_handler.c, I gather that the intention is to try and get a timeslot that has enough time for the requested action faster than normal.
What I noticed is that when this line of code is invoked with our application running as a BLE peripheral on Softdevice 7.2.0, having an active connection to a central, it actually takes longer until the next timeslot is started than without this line!
See the following trace:
I do not observe these ~50ms to ~80ms timeslot "outages" when I remove the invocation of timeslot_restart() at this point.
So my questions are:
- Do you have an explanation for this behaviour?
- Is this the indended behaviour?
- Do I break something if I remove this line of code and if yes, what?
- EDIT: I think I can imagine that removing this line can lead to crashes if actions are enqueued with a duration greater than e.g. the current connection interval or something like that. Is that possible?
Thanks for your advice & regards,
-mike
