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.

[Dave_couling]

Thanks for the comment. I have an RTC version as well, but I went with HFCLK due to the higher accuracy. Power Consumption is less important then accuracy for me.

I guess a question for Nordic would be, I know the SAADC ISR callback could be delayed due to BLE activity, but the value it contains (triggered from PPI/GPIOTE) should be from the correct time period right? Meaning for example, since PPI/GPIOTE triggers every 10msec, even if BLE activity delays a given sample by 4msec, the value contain should still be the ADC value taken at the correct time (4msec ago). Is this assumption valid?

[AmbystomaLabs]

Higher accuracy isn't necessarily true, depends on your xtal choices. Many of the specified 32MHz xtals are 10-20ppm same as the RTC. Plus higher accuracy RTC crystals are normally cheaper compared to 32MHz xtals. But if you don't care about the power consumption of the HF CLK then by all means do it that way.

Yes the sample sitting in the SAADC buffer assuming it is running single shot mode is the last sample you wanted.

You should double check that it is running single shot, single sample in buffer (not averaging) and that you actually turned on HF_CLK. The SD will always turn off HF_CLK during power manage and when it returns from power mange it is actually on HF_RC. Just search in the devzone on how to make sure it is on continuously. As I recall the trick is to start it before starting the SD and the SD will leave it on.

[Dave_couling]

Thanks for the reply. Burst mode is disabled so I believe that means Single-Shot. I also disabled OVERSAMPLING in my config setup. I should note that I have 3 channels configured in my ADC setup.

I wasn't aware of the requirement for turning on the HF_CLK. Using the nrf_drv_saadc driver should take care of this. However if the SD is shutting it off, then there will be start-up delay to turn on TIMER0 again to obtain the SAADC sample.

[Dave_couling]

I suppose I could try and play around with enabling Constant Latency Mode. I just haven't it mentioned on here, and I've seen posts with people requiring far faster data acquisition that 100-150Hz on the ADC. So I figure I must be missing something thats causing this time drift.