TickTimer Accuracy

[JayPRab]

Hi,

• We are using SD110 with SDK 7.2.0 in our application
• Our application needs to be quite accurate in timing
• We set out to determine what the accuracy of the TickTimer was, which is provided by the SD (110 in our case)
• Our hardwaresetup is shown in the attached file, "nRF51TimerTickAccuracyTestSetup.pdf"
  • What you see is a 1MHz oscillator (accurate to a few PPM)
    
  • it is connected to a 12-stage counter (hardware, so NO time lost due to freq. division)
    
  • I take the 12th stage output (which is 1MHz / 2^12 => 244 Hz) and connect it to P0.0 on the nRF
• The code (shown in file "nRF51TimerTickAccuracyTest.pdf") does the following:
  
  • Set up GPIOTE for my input pin (P0.0)
    
  • Init Timer2 to be a counter in 16 bit mode
  • Configure the PPI channel 0 to get Events in from P0.0 (NRF_PPI->CH[0].EEP)
  • Configure the PPI channel 0 to count up on T2 (NRF_PPI->CH[0].TEP)
• All this works very nicely, thanks to your previous help!!
• I run the nRF without ANY BLE activity at all
  • This should mean that the SD is quite undisturbed by asynchronous events like BLE traffic, etc.
• I expect to see CC[0] get a value close to 14,604:
  • every sec is 1,000,000 / 2^12 = 244 counts / second
  • 244 * 60 seconds = 14,604 counts / minute
• HOWEVER, what I actually see in the CC[0] register (using the Keil debugger) is 14,751 counts
  • This is the equivalent of 420,000 counts difference between expected and actual
  • this is 0.42 seconds gained every minute!
• Adding BLE doesn't change this number at all
• My question is:
  • What is causing this 420mSec per minute increase?
  • BTW, this is constant across many boards...
  • Is there a way to fine-tune the timer such that it is more accurate than this?

Files attached

Thanks for your help!

nRF51TimerTickAccuracyTestSetup.pdf

nRFTimerTickAccuracyTest.pdf

[AmbystomaLabs]

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.