Accurate Time Capture

RE: Accurate Time Capture

Dave_couling — Mon, 16 Sep 2019 20:14:47 GMT

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

RE: Accurate Time Capture

Cy — Wed, 04 Sep 2019 16:28:36 GMT

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

RE: Accurate Time Capture

ovrebekk — Mon, 18 Dec 2017 11:59:50 GMT

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

RE: Accurate Time Capture

Dave_couling — Sun, 17 Dec 2017 19:54:30 GMT

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.

RE: Accurate Time Capture

Dave_couling — Sun, 17 Dec 2017 19:09:49 GMT

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.

RE: Accurate Time Capture

AmbystomaLabs — Sun, 17 Dec 2017 18:30:56 GMT

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.

RE: Accurate Time Capture

Dave_couling — Sun, 17 Dec 2017 17:57:06 GMT

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?

RE: Accurate Time Capture

AmbystomaLabs — Sun, 17 Dec 2017 17:01:35 GMT

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.