3
\$\begingroup\$

I'm using a dsPIC 33FJ128GP804 and I'm trying to record data at 200 Hz as accurately as possible. My device also has a GPS and I'm noticing that my timer is drifting compared to the GPS by about 333 ms / hour. I think it should be possible to do better than that. My clock source is a 40 Mhz crystal with a tolerance of 30ppm and stability of 50ppm and aging of 5ppm/year.

I have the Oscillator of the PIC running at 72Mhz. I can't change this, it's required to run the UARTS at 3Mbit.

During my testing to figure out why there is so much drift, I did an experiment. I'm running two timers, one at 200Hz and one at 5Hz. In the interrupt handlers, the 200Hz timer increments a long int by 1 and the 5Hz timer increments a long int by 40. The two long ints should remain the same. However, after 45 minutes, the values differ by 6. (30ms)

Why am I seeing a difference between the two values? And is there anything I can do to increase my timer accuracy other than changing the crystal? Does having a longer period increase accuracy? If so, could I use a slower timer periodically reset my faster timer. Would changing the source of my timer to the external oscillator from the instruction clock make a difference?

I do use the GPS time to correct the timing in post processing, but GPS isn't always available so I don't want to have to rely on it.

\$\endgroup\$
5
\$\begingroup\$

The timers divide the clock down by integer values. The long term average coming out of a timer will be the same as that of the oscillator.

It sounds like your timer period is off by 1. Read the datasheet carefully. You probably didn't put the right value into the period register. Usually these timers work such that the period is the period register value plus 1.

Another possible source of error is how the crystal is driven. The accuracy is specified for a particular load capacitance, which can often be a bit unpredictable since stray capacitance can be a significant part of the total. However, that would not explain why two timers running from the same clock don't agree on elapsed time. Only a firmware bug can cause that.

\$\endgroup\$
  • \$\begingroup\$ I think you are right, it's the + 1 that's the problem. Verifying now. \$\endgroup\$ – FigBug May 23 '12 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.