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?

[AmbystomaLabs]

Everything you said is correct. If you want accurate samples independent of the BLE stack the best way is PPI/GPIOTE. You could use RTC1 to count out intervals and fire the SAADC event in single shot mode. Then the sample shows up in the handler and can be processed at your leisure within your sample period. The ISR for the handler will trigger when the BLE stack isn't active. So latency can be up to a millisecond.

It would be better to use LFCLK (ie, RTC) instead of HF_CLK as you intended. The reason being is HF CLK uses gobs of power. Whereas the RTC uses very little and is running anyway since the BLE stack needs it. The RTC has a minimum resolution of 1/32768 of a sec or 0.0305 msec. Since RTC's are always designed around base 2 you might want to rethink your time interval a bit to come with something base 2 savvy.

Anyway, that does work. If it's not working for you then something is wrong with your code. You will need to post your code for anyone to provide meaningful comments.