Need Help with Timeslot Extensions

RE: Need Help with Timeslot Extensions

ovrebekk — Fri, 27 Apr 2018 12:17:23 GMT

Hi Mason

I am a bit unsure why your code isn't working, so I made a small example on my own to get timeslot extension working in a BLE example.

You can find the code here.

It will compile under SDK v15. Just copy the content of the zip into one of the example folders (for instance \nRF5_SDK_15.0.0_a53641a\examples\ble_peripheral\ble_app_uart_max_timeslot\)

Could you have a look at this example and see if you can spot the difference?

All the timeslot related code is available in max_timeslot.c/h.

Best regards
Torbjørn

RE: Need Help with Timeslot Extensions

Mason — Wed, 25 Apr 2018 16:32:52 GMT

NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_FAILED and NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END both evaluate to a value of 3, so I had to replace NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_FAILED with NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END in order to compile the switch statement.

In effect, absolutely nothing changes from before. The total timeslot length sits at about 19000us with roughly 21 successful extensions.

RE: Need Help with Timeslot Extensions

ovrebekk — Wed, 25 Apr 2018 11:30:07 GMT

Hi Mason

What happens if you try to request a new timeslot as early as possible, using the NRF_RADIO_SIGNAL_CALLBACK_ACTION_REQUEST_AND_END callback action?

In theory that should give you a new timeslot as soon as there is some available time.

Best regards
Torbjørn

RE: Need Help with Timeslot Extensions

Mason — Mon, 23 Apr 2018 17:43:01 GMT

I'm not able to get a new timeslot after the first one is unable to be extended yes.

I've changed the extension request failed case to the following:

        case NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_FAILED:
            fail_count++;

            configure_next_event_earliest();
            signal_callback_return_param.params.request.p_next = &m_timeslot_request;
            signal_callback_return_param.callback_action = NRF_RADIO_SIGNAL_CALLBACK_ACTION_END;
            break;

However I'm seeing the same extension performance results (just one extension, ending early).

I don't believe I can change the connection interval without breaking iOS compatibility.

ADC sampling frequency is once per millisecond, with every sixth millisecond saved into ram to be transferred over BLE later. I am employing an interpolation strategy, but I'd like to reduce the amount of times I have to interpolate by using timeslot extensions if possible.

RE: Need Help with Timeslot Extensions

ovrebekk — Thu, 19 Apr 2018 14:55:50 GMT

What is your ADC sampling frequency?

Is there any way you could cover the missing samples by interpolating from surrounding samples?

I don't know how much using timeslots will help compared to radio_notifications. In either case the Bluetooth stack will take precedence when a connection event is coming up (unless you are in slave latency sleep, and don't have any data in the buffers). Any chance you could increase the connection interval further?
It is possible to change the connection parameters dynamically, but issuing a connection parameter update request, but whether or not it is granted depends on the central device.

Are you saying that you are not able to get a new timeslot after the first one is unable to be extended?
If you want to be in the timeslot as much as possible it is common practice to ask for the earliest possible timeslot after the extension fails.

Best regards
Torbjørn Øvrebekk