https://devzone.nordicsemi.com/f/nordic-q-a/7841/timeslot-api-accuracyI 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, take note of the current time when START is called: case NRF_RADIO_CALLBACK_SIGNAL_TYPE_STARTen-USTelligent Community 13Sat, 11 Jul 2015 00:38:43 GMThttps://devzone.nordicsemi.com/thread/27939?ContentTypeID=1Sat, 11 Jul 2015 00:38:43 GMT137ad170-7792-4731-bb38-c0d22fbe4515:0313a829-ef11-4020-b932-96190b84b413Jerod<p>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&#39;ll comment that at least this is working as desired -- and not an issue. (Closing)</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/27938?ContentTypeID=1Mon, 29 Jun 2015 09:20:10 GMT137ad170-7792-4731-bb38-c0d22fbe4515:574038d5-8753-413f-97ec-93f2d791f01cHung Bui<p>@Jerod: How is your setting on the softdevice, which advertising/connection interval did you use ?</p> <p>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.</p> <p>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.</p> <p>It may not be very accurate counting on the main loop to sample time, because it has least priority.</p><div style="clear:both;"></div>