Accurate Time Capture

[Dave_couling]

Hi guys, I'm using a HFCLK TIMER to time ADC sample capturing via PPI. This eliminates CPU+BLE usage from affecting my time keeping. I assume that each ADC sample arrives in my callback within usec variance from my timing.

I'm trying to get 10msec timing resolution for my time-stamping on the ADC samples. When a sample hits the callback I increment my timestamp by 10msec. This data is then transmitted to a Central.

Over time I see two capture devices have their samples drift seconds apart, when comparing the data received on the Central side. They both are measuring the same source, but the timing is as much as 4-5seconds difference after 90seconds of overall duration. The HFCLK should be highly accurate and since I'm using PPI, BLE activity can't explain these timing drifts. Any ideas what could cause timing drifts like this?

[ovrebekk]

Hi Dave

Most likely the issue is that you need to request the external high frequency clock to have it run all the time. You are correct that modules that need it will enable it implicitly, but they will only enable it just before they need it, and disable it again when the operation is complete (be it an ADC sample operation or a some radio activity).

Try calling nrf_drv_clock_hfclk_request(..) and see if it improves the situation.

Best regards
Torbjørn

[Cy]

Hey Dave, How did Torbjorn's suggestion work out for you?

[Dave_couling]

Requesting the HFCLK before running sampling eliminated the jitter causes by the Crystal ramp-up time and thus more accurate data.   ISRs still execute with some jitter due to BLE events.  However the time the data was captured at was accurate