Timeslot API accuracy

[Jerod]

I have take the basic ble_app_hrs_with_timeslot and modified it to calculate the timing of subsequent calls to the timeslot START event.

Specifically,

1. take note of the current time when START is called:

   case NRF_RADIO_CALLBACK_SIGNAL_TYPE_START: app_timer_cnt_get(&EVENT_TICKS);

2. near the end of the event (TIMER expiry) set the interrupt to allow the main task to run:

   NVIC_SetPendingIRQ(SWI3_IRQn); //Set this interrupt if you want code execution to proceed in the main thread after timeslot execution.

3. and within main task, use UART to print out the difference in time between successive START calls.

The result are successive times that are not terribly accurate; setting a 1000ms "distance_us", I get the following times:

997, 1004, 1024, 991, 999, 1024, 1024, 1003.

From other posts here, I understand the timing of the API to be quite accurate (order of uSec). That said, given I'm calculating the difference between successive STARTs, I'm not sure what assumptions I've made that cause this to show inaccuracy.

Q: Is it actually more accurate than the example is showing (due to other latencies)?

or

Q: Are there ways to make it more accurate?

Note: I am using the evaluation kit (PCA10001) and SoftDevice 7.1

Appreciate any insight you might have.

Thanks

[Hung Bui]

@Jerod: How is your setting on the softdevice, which advertising/connection interval did you use ?

There could be a chance that the timeslot is blocked by the softdevice for a period. Your result of the period that less than the distance is pretty strange. My test here if the timeslot is not blocked, the distance is accurate at few us.

I would suggest you instead of using the internal timer and the SWI3, to use a logic analyzer, and then you can try to toggle a GPIO pin when you have NRF_RADIO_CALLBACK_SIGNAL_TYPE_START , and measure the distance.

It may not be very accurate counting on the main loop to sample time, because it has least priority.

[Jerod]

I have re-written and used simple_uart -- and found that this problem has disappeared. Without much troubleshooting to figure out why it was occurring, I'll comment that at least this is working as desired -- and not an issue. (Closing)