TickTimer Accuracy

RE: TickTimer Accuracy

JayPRab — Fri, 02 Feb 2018 13:25:00 GMT

I did not know that. I thought it used the HF clock...

Yes, I do have a crystal.

Thanks for all the help!

RE: TickTimer Accuracy

Hein — Fri, 02 Feb 2018 00:31:59 GMT

So, the app timer runs from the 32.768kHz clock, I assume you have a crystal for this? Either way, you cannot get a 1ms interrupt because 32.768kHz does not divide cleanly into 1ms. You will probably get much more reasonable results if you set a repeating app timer to expire after 1 second and then check your counter value. But as stated by Ambystomalabs, it still takes time to service events, so there will always be some jitter in your measurements.

RE: TickTimer Accuracy

JayPRab — Thu, 01 Feb 2018 23:05:59 GMT

I will check.

Thanks for that!

RE: TickTimer Accuracy

JayPRab — Thu, 01 Feb 2018 23:04:14 GMT

Hi,

Thanks for the FAST response!

Yes. 1mSec rep rate. That is the basis for ALL my timing in my application.

In the ISR, I up a counter ever time the ISR is hit (for this test)

So every count represents 1 mSec

I start the counter.

In 60,000 visits to the ISR (1 minute), I should have 14,604 counts in CC[0] because my Counter input is 244Hz

APP_TIMER_PRESCALER is 0

The inaccuracy is DEFINITELY from the App Timer...

Hence, my question... How can I get rid of this inaccuracy?

Thanks!

RE: TickTimer Accuracy

AmbystomaLabs — Thu, 01 Feb 2018 22:51:20 GMT

The accuracy of any system is fundamentally driven by it's clock accuracy. The external RTC is generally a 40ppm clock on most designs. If you happen to have designed out the external RTC then the BLE stack keeps the internal RC based RTC at 250ppm. Any of the main timers on the HF clock are normally 10 or 20 ppm.

But of course none of this explains why you see such a large error. The answer of course lies in the fact that you coded something using ISR's to accomplish a timing task and that will never work. The way your tick timer works is to set an RTC for an event and when the event comes through run some code to set future events. The app timer is similar but actually has more code and more latency since it handles more events.

The very nature of ISR's means that your clear events will always be late some random amount depending on what the SD was doing and what your code was doing. Also just servicing the ISR alone takes quite a few clocks as there is a lot of work for the processor to do.

The only way to get an accurate clock is to keep the whole thing in PPI and only use interrupts to keep track of time but never to drive the clock.

So basically the thing has to wrap around in PPI where when a CC event happens it triggers a clear via PPI but keeps going. You can use the event to trigger an ISR to add to a count but NEVER to actually manipulate the timer. If you want to be really cool about it you can further use PPI to drive a second counter such that you can count for all eternity in hardware but just capture the value of the count register in code whenever you want to know what time it is.

Just search in the blog for answers/code on this question. It comes up a lot.

Also if you are just counting out seconds better to use the RTC timers. As RK pointed out you have to request the external HF clock. Otherwise the SD will just run your code on HF int which has a few percent accuracy. Also if you use the RTC you can put the device to sleep and it will still count.

RE: TickTimer Accuracy

RK — Thu, 01 Feb 2018 22:32:07 GMT

Have you explicitly started the HFCLOCK in your code? If you haven't you're running by default on the internal RC oscillator and that's going to be very inaccurate.

RE: TickTimer Accuracy

Hein — Thu, 01 Feb 2018 22:13:38 GMT

You are using an app timer to run a 1ms counter to get the 60 seconds ? What is the app timer prescaler ? It seems likely that the inaccuracy is from the app timer, not from your hardware clocking system ?