Connection event trigger and Timeslot API

RE: Connection event trigger and Timeslot API

CheMax — Thu, 04 Jun 2020 10:29:53 GMT

Hi, Ok.

Thank you for your time.

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/253227"]You mentioned that you're able to access the radio and exchange data with this method. I'm not sure how, as the trigger event will be generated 40 µs before a connection event, which leaves no room for a timeslot to fit.[/quote]

No, I use this trigger to start RTC. RTC will give an event 2 milliseconds before next connection event started. for one connection, by the way, this is the best solution).

I suggest closing this topic as a topic with a solution found. I will mark key answers.

Thanks again for your time.

RE: Connection event trigger and Timeslot API

Jared — Thu, 04 Jun 2020 09:55:39 GMT

Hi,

Using Radio notifications with Timeslot is apparently not a feature which is supported by the radio scheduler in the Softdevice. This is a limitation of the Softdevice. It was my mistake of suggesting this solution when it's not a feature that we support in the first place. I'm sorry for that. 🙂

Regarding the "trigger method" of using sd_ble_gap_conn_evt_trigger_start() to signalize the start of a connection event. You mentioned that you're able to access the radio and exchange data with this method. I'm not sure how, as the trigger event will be generated 40 µs before a connection event, which leaves no room for a timeslot to fit. This method was explicitly not recommended from our developers of the Softdevice.

regards

Jared

RE: Connection event trigger and Timeslot API

CheMax — Thu, 28 May 2020 16:12:00 GMT

Hi,

I'm afraid to seem annoying with this question, but I just want to better understand the tool that I use.

Well, I understood about the overlap, But

Let's see to this diagram,

I always have free time to open the slot: t_free = t_ndist - t_prep.

Using my timer trigger method, I can successfully access the radio and exchange data. At the same time, it is enough for me 2 ms before the start of the connection event to activate the radio on 800 μs. This can be seen in the diagrams that I applied above.

This means that setting distance values of more than 2 ms should lead to successful activation of the slot without overlapping t_prep. However, this does not happen.

RE: Connection event trigger and Timeslot API

Jared — Thu, 28 May 2020 13:59:12 GMT

Hi,

So I discussed this with the developers and they concluded that the Softdevice will not allow any timeslots right before a connection event, even by using Radio notifications. This is likely due to the timeslot overlapping with t_prep

regards

Jared

RE: Connection event trigger and Timeslot API

CheMax — Tue, 26 May 2020 16:13:45 GMT

Hi,

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/251733"]What if you request the HFCLK before the radio notification and only open a timeslot in the radio notification event handler?[/quote]

No, it's not work.

I noticed another feature. if I just allow radionotifications, then my chart is offset. Pay attention to the marker for the duration of the radio session (brown, channel 1). It is biased and overlaps the connection event (white, channel 0). I try all NRF_RADIO_NOTIFICATION_DISTANCES, but result but the result is always the same.

without using this function, the picture is different.

my suspicion is that allowing radioactivity tracking somehow blocks access to it programmatically. can you consult the developers of the stack about this behavior?

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/251733"]The goal is to minimize time used in the event handler before you request a timeslot.[/quote]

Yes. And it seems that I have reached this minimum. I really wanted to be as close to the connection event as possible so as not to reduce the channel bandwidth. But this is apparently not solvable in the current performance.

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/251733"]My guess is that the Softdevice is implemented such that it allocates time for the crystal to ramp up even though you've already enabled the HFCLK if you use NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED.[/quote]

truth can be found only from the author of the code :)

if it is easier, then I can attach the project here. It is built on the basis of a standard example of a heart rate monitor (sdk 16.0.0). only the main.c file has been changed and added my file for working with time slots.

RE: Connection event trigger and Timeslot API

Jared — Tue, 26 May 2020 13:46:55 GMT

Hi,

Sorry for the misunderstanding in the previous reply. I was indeed thinking that you could use sd_radio_notification_cfg_set() to notify your application of a radio start event instead of using your previous method. I see that you tried this with the a 5 ms distance and that the Timeslot was canceled. What if you request the HFCLK before the radio notification and only open a timeslot in the radio notification event handler? The goal is to minimize time used in the event handler before you request a timeslot.

Regarding the difference between NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED and NRF_RADIO_HFCLK_CFG_NO_GUARANTEE. My guess is that the Softdevice is implemented such that it allocates time for the crystal to ramp up even though you've already enabled the HFCLK if you use NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED.

RE: Connection event trigger and Timeslot API

CheMax — Mon, 25 May 2020 10:23:29 GMT

Hi Jared,

Did not quite understand.

If I started the clock in advance, then the soft device does not need to start and wait for the clock to stabilize.

It is enough just to check the corresponding flag on the readiness of the source. Even the corresponding function is:

/**@brief Checks if the high frequency crystal oscillator is running.
 *
 * @see sd_clock_hfclk_request
 * @see sd_clock_hfclk_release
 *
 * @param[out] p_is_running 1 if the external crystal oscillator is running, 0 if not.
 *
 * @retval ::NRF_SUCCESS
 */
SVCALL(SD_CLOCK_HFCLK_IS_RUNNING, uint32_t, sd_clock_hfclk_is_running(uint32_t * p_is_running));

If I started timing in advance, then I should not see the difference by requesting a slot with a NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED or with NRF_RADIO_HFCLK_CFG_NO_GUARANTEE.

However, it is not. I saw a difference of about 1.5ms at startup.ms at startup.

delay: 282.32us

delay: 1.77 ms

On figures:

Yellow Label 1:

if(sd_radio_session_open(radio_callback) != NRF_SUCCESS)
    return;

if(sd_radio_request(&m_timeslot_req_earliest) != NRF_SUCCESS) 
    return;

Yellow Label 2: After receive event: NRF_RADIO_CALLBACK_SIGNAL_TYPE_START.

I can assume that a strict time delay is always used.

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/251430"]Radio notifications are used to inform the application of radio activity but will not give the application directly access to the radio peripheral.[/quote]

I thought, based on the description, that if I ask you to tell me that activity will start in time X, then you can try to open the slot.

and it seemed strange to me that when using the radio notification of activity, I can’t open the slot at these moments. I wrote about this above, if necessary, I can describe the full scheme of the experiment and attach the code and results.

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/251430"]Do you have the option of synchronizing by using a GPIO, or does your project require that it's wireless?[/quote]

here I just want to refuse extra wires. At the moment, I get acceptable accuracy using the algorithm described (partially) here.

Best regards,

Max

RE: Connection event trigger and Timeslot API

Jared — Mon, 25 May 2020 09:26:51 GMT

Hi,

So in short:

Radio notifications are used to inform the application of radio activity but will not give the application directly access to the radio peripheral.
Radio timeslots are used when you want access to the radio when the Softdevice is in use. The Softdevice will allocate a timeslot which gives the application directly access to the radio peripheral.

The issue with using radio timeslots in this case is that a timeslot won't fit in between the event generated from sd_ble_gap_conn_evt_trigger_start() and the start of the connection interval.

[quote user="CheMax"]If HFCLK always enable in my projects (I call sd_clock_hfclk_request() after stack init), does it mean that I can request an early timeslot interval with NRF_RADIO_HFCLK_CFG_NO_GUARANTEE option without lost accuracy? In this case, I act as a guarantor that the exact clock source is already running.[/quote]

Yes, this will make sure that the Softdevice leave the HFCLK running and is ready when the timeslot starts. However, this may affect the possibility of getting an earlier timeslot as the Softdevice must start the HFCLK if it's not already running.

Do you have the option of synchronizing by using a GPIO, or does your project require that it's wireless?

regards

Jared

RE: Connection event trigger and Timeslot API

CheMax — Fri, 22 May 2020 11:48:22 GMT

Please, give me a answer on this questions about timeslots:

If HFCLK always enable in my projects (I call sd_clock_hfclk_request() after stack init), does it mean that I can request an early timeslot interval with NRF_RADIO_HFCLK_CFG_NO_GUARANTEE option without lost accuracy? In this case, I act as a guarantor that the exact clock source is already running.

RE: Connection event trigger and Timeslot API

CheMax — Wed, 20 May 2020 10:25:22 GMT

additional information:

I conducted a test and returned to starting time slots using the method described earlier (using a timer to start before the connection interval) without using NRF_RADIO_NOTIFICATION and got the following results

As you can see in the figure marked 1, time slots open successfully (red track, p1.02).
But if I just call a function

APP_ERROR_CHECK(radio_notification_init(5, NRF_RADIO_NOTIFICATION_TYPE_INT_ON_ACTIVE, NRF_RADIO_NOTIFICATION_DISTANCE_5500US));

whose handler does nothing but control the pin, then timeslots cease to be available.

RE: Connection event trigger and Timeslot API

CheMax — Wed, 20 May 2020 08:48:26 GMT

two days later ....

Hello,

I’ve got a little insight into the idea of radionifications, but so far I can’t say whether this tool suits me or not.

I changed my code a bit to start the radio exchange through the time-slot api through the radio notification. Notifications were configured as follows:

APP_ERROR_CHECK(radio_notification_init(5, NRF_RADIO_NOTIFICATION_TYPE_INT_ON_ACTIVE, NRF_RADIO_NOTIFICATION_DISTANCE_5500US));

but I did not see anyone on the radio. For debugging, I assigned several pins to indicate certain events and made a recording with a logic analyzer.

annotation:

So, I see event from radio-notification 5500 us before the radio is activated (as planned).

Next, I call the following functions:

if(runtimeslot_)
{   // event received
  runtimeslot_ = false;
  if(connected_)
  { // connect established
    err = sd_power_mode_set(NRF_POWER_MODE_CONSTLAT);
    if(err != NRF_SUCCESS)
      NRF_LOG_INFO("sd_power_mode_set %d", err);

    err = sd_clock_hfclk_request();
    if(err != NRF_SUCCESS)
      NRF_LOG_INFO("sd_clock_hfclk_request %d", err);

    NRF_P1->OUTSET = 1 << 2;
    err = sd_radio_session_open(radio_callback);
    if(err != NRF_SUCCESS)
      NRF_LOG_INFO("sd_radio_session_open %d", err);

    err = sd_radio_request(&m_timeslot_req_earliest);
    if(err != NRF_SUCCESS)
      NRF_LOG_INFO("sd_radio_request %d", err);;
  }
}

And timeslot is not activated, because in the event handler i get: NRF_EVT_RADIO_CANCELED.

If i try reopened timeslot on it event, I see timeslot activity, but after connection event:

So far, I'm at a loss. Is it possible to open a timeslot for transmitting proprietary data (ESB protocol) when using radio-notifications?

how can I filter events? after all, everything falls under activity, including the “my” use of the radio.

So far, my initial approach has more pluses, using only functions: sd_ble_gap_conn_evt_trigger_start();.

Best regards.

Max

RE: Connection event trigger and Timeslot API

CheMax — Mon, 18 May 2020 11:25:06 GMT

Hi,

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/250398"]Sorry for the late reply.[/quote]

Do not worry about it, during this time I only plunged deeper into this topic)

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/250398"]What exactly is your goal of using radio timeslots?[/quote]

We want use it for time synchronization (based on it). It is also necessary to ensure maximum energy efficiency of the device.

Therefore, we decided to use the following scheme:

time slots are activated before the event "connection interval".

After a short exchange of tags, the radio switches to normal mode for data exchange already on the BLE channels.

I have not yet come up with a better way to activate slots before this event occurs, as a countdown from the last interval.

[quote userid="73165" url="~/f/nordic-q-a/61403/connection-event-trigger-and-timeslot-api/250398"]If not, then maybe Radio notifications is the right approach.[/quote]

I already read about it before, but why at the moment I could not remember. Thanks, I think it will take me a couple of days to comprehend the new information.

RE: Connection event trigger and Timeslot API

Jared — Mon, 18 May 2020 09:53:02 GMT

Hi,

Sorry for the late reply.

I see that you have a couple questions that you want answered regarding time slots, and I'll try to answer the them :). But first I would like you to elaborate a bit more on this:

[quote user=""]Using the timer that starts on this trigger, I want to use timeslots before the connection event. At the moment, I have received the following diagram:[/quote]

From our developers:

The event trigger task is triggered when the radio starts ramping up before the first reception or transmission in a connection event. That is, 40 us before the first radio activity. It is not possible to fit a timeslot in this period of time.

What exactly is your goal of using radio timeslots? Did you want to use the Radio in the timeslot? If not, then maybe Radio notifications is the right approach.

The answer to Q3, and Q4 is yes :)

regards

Jared

RE: Connection event trigger and Timeslot API

CheMax — Fri, 15 May 2020 15:34:15 GMT

Hello,

during the wait, I made some progress in this matter, so the questions and additions below are considered more relevant.

I didn’t notice that I uploaded the same image twice. According to this diagram:

Q1. Does a trigger for a connection event occur at the time of the "radio start"?
Q2. If I try to get timeslots up to this point, will I get a busy error because the stack is already busy with the radio?

The description of the NRF_RADIO_HFCLK_CFG_XTAL_GUARANTEED has note:

@note The SoftDevice will automatically turn on and off the external crystal,
at the beginning and end of the timeslot, respectively. The crystal may also
intentionally be left running after the timeslot, in cases where it is needed
by the SoftDevice shortly after the end of the timeslot.

Q3. does this mean that I do not need to make a request: sd_clock_hfclk_request(); before starting sd_radio_session_open() ?

Q4. About function: sd_ble_gap_conn_evt_trigger_start(conn_handle, params). Since I plan to use this event on the client side, I have to use it for every new connection. As a parameter, this function transfers the PPI channel number and the connection handle.

Q4.1. It turns out that if there will be many connections, for example 10, then I need 10 PPI channels?

Q4.2. Or is it possible to use only one channel for all any number of connections?

Q5. I realized that in vain I was requesting an extension of the time slot and because of this the session time was stretching. After correction, the diagram began to look like this:

Time between radio-session opened and timeslot started is 1.782553 ms. I correctly understood that this time includes the launch and stabilization of HFCLK(~ 1.5ms according to the first figure) and it will not work to reduce it?

Q6. Running a time slot now looks like this:

ble_gap_conn_evt_trigger launches RTC timer to measure the interval. The interval is defined as follows:

RTC->CC = CONN_INTERVAL - TIMESLOT_LENGTH - 2*1500,

where: CONN_INTERVAL - setted connection interval in microseconds. [e.g. 30000];

TIMESLOT_LENGTH - length of timeslot, [e.g 1000];

1500 - total preparation time for launch (Preprossesing, Crystal Ramp-up, standby, ...).

By this time I came empirically. This method works, but does not look reliable. Maybe I'm trying to invent a wheel? Is it possible to obtain time data more accurately without using magic numbers?

Best regards,

Max