Poor clock accuracy of UNO

[liuzengqiang]

Thanks Lefty. I'll give it a try.

[tim7]

Here's data from a 20 hour run with a ceramic resonator:

• The average frequency is off by 2021ppm (too slow)


• The frequency varies by ~10ppm per degree-C (hotter = slower)


• for a fixed temperature the frequency stability is +/-8ppm or better (here measurement accuracy was limited by the timing and temperature resolution of the data acquisition)

The temperature variation is only about 5x worse than typical datasheet specifications for a crystal.  So as long as the average frequency is calibrated some reasonable timekeeping is possible.

PS. Can anybody suggest a way to timestamp data with greater than 10ms resolution?  I discovered that Windows checks the serial port "only" every 10ms.  Tsk, so slow! 

[/list]

[liuzengqiang]

Very impressive presentation! What data acquisition system did you use to produce this data?

I think the hotter the crystal/ceramic, the softer they become (or the less bound the atoms are to their sites), so a softer spring should have lower frequency. It makes sense.

For windows question, is it possible that the 10ms was set on the TTL USB adapter? FTDI adapter for example, can adjust timeout and other parameters. The adapter doesn't really send serial data immediately after receiving them, but rather do the following two:
1)wait until the receive buffer is full (60? bytes+USB overhead).
2)wait until timed out (adjustable on your PC via the device driver).

To get more immediate response you can reduce the timeout but PCs don't have accurate RTC either, more or less like 1/17 second accurate if I recall correctly but that was from 8086 Someone should update this number.

[tim7]

Very impressive presentation! What data acquisition system did you use to produce this data?

Thanks ...though it wasn't awfully sophisticated.

The Uno board's timers were programmed to trigger an interrupt every 16 million clock cycles, and the interrupt routine sends a "tick" byte over the serial port.  In between ticks it also reports temperature info over the same port.  A short Perl script running on a Win7 PC recorded timing info every time it caught a byte on the COM port.  Perl's timing appears to be very precise, but it only sees new serial data at 10ms intervals and a quick web-search seemed to imply that this is a Windows limitation.

Another option was to send pulses to the line-in connection of the PC's sound card, but I don't know if the sound-card's sampling is synced with the real-time clock.  Although now I think of it, I could use another Perl script running on the PC to generate accurate reference audio ticks and feed those into the second line-in channel.

For the plot I made a running average of the tick interval over 10 minutes: 10ms / 600s = 16.7ppm, which is why the data points line up at 16.7ppm intervals.  A longer averaging period would cover too much temperature variation: the gaps between the lines would shrink, but the overall data scatter would grow.

[liuzengqiang]

Sound card can only take 1V maximum so you will need a voltage divider. I don't think the sound card is synchronized with PC clock. In rare occasions the sound could even be off since the sound card crystal is no the same as the RTC crystal. I had this problem on one computer I used. The recording and playback time are different, especially when you record a long lecture of 50 minutes. The recording is per the sound card crystal but playback was somehow per the PC clock. I used every recording and playback software on that computer and other computers and came to the conclusion that the computer has a problem with sound card.

[tim7]

...and here's the same test with a crystal-clocked Arduino-clone.  I used a Freetronics "Eleven" board, which is very similar to the Uno I used in the previous test.

The results are within tolerances quoted for typical crystals.  Compared to the resonator-clock:

• the average error is 43ppm, 47x better


• the temperature stability is approximately 0.28ppm/C, 35x better



For context 1 minute per year is about 2ppm.

The average frequency stability over 25 hours was better than the measurement error, which was 0.6ppm.  This implies that, unless the temperature is controlled to within about +/-1C, long-term stability is determined by temperature variations.

[/list]

[mantoui]

In the crystals.txt file in the git link below you will find some frequency measurements of crystals, resonators, and RC oscillators showing OSCCAL values over several chips and at different voltage levels.

   https://github.com/manitou48/crystals

[Coding Badly]

Thank you for the very detailed analysis.

The RC circuit is precalibrated at the factory (1%), but you can adjust the RC oscillaor by changing in the OSCCAL value.

...is not correct for the typical Arduino processors.  The internal oscillator is "precalibrated at the factory" to ±10% not ±1%.

[mantoui]

Here is another nice study of affect of temperature on crystal and resonator using GPS pps, fyi

  http://jorisvr.nl/arduino_frequency.html

[dhenry]

Anybody know why the UNO board uses a ceramic resonator rather than a "proper" crystal?

You may have to ask Team Arduino.

To me, that's a bone-head mistake. For a few cents more per board, they can get something far more accurate than those resonators.

[retrolefty]

Anybody know why the UNO board uses a ceramic resonator rather than a "proper" crystal?

You may have to ask Team Arduino.

To me, that's a bone-head mistake. For a few cents more per board, they can get something far more accurate than those resonators.

I agree, and to put salt in the wound you might notice that they do use a real crystal resonator for the USB serial converter chip, yet feel our applications don't require the better frequency accuracy that a crystal would allow.
Of well LOL I shouldn't complain, I never did end up buying a Uno board as I have more 328p based boards then I need when they first released it. And then I just started burning the Uno bootloader into my older 328p based boards so I get all the advantages (smaller bootloader, faster uploads) with none of the negatives. 

Lefty

[dhenry]

the average error is 43ppm,

That surprised me a little bit. Most crystals are 1ppm/c, and 20ppm initial so unless yours was exposed to 20c+/- variations it is hard to produce that kind of drift.

I have some Epson (regular, non TCXO) oscillators that are rated 50ppm. I tested about 10 of them and their initial accuracy is within 5ppm and practically 0ppm/c.

[oric_dan]

Disagree.  The Arduino appeals to a HUGE variety of applications.  If you need pinpoint accuracy for timekeeping, wouldn't you tend to use external circuitry anyway?

Hate to have to say this but .... what a rip-off. You can buy smt crystals for less than
resonators being used, and get light-years better timing accuracy. Not everyone wants
their timing to be off by 432 sec every day.

http://www.mouser.com/ProductDetail/ECS/ECS-160-20-5PX-TR/?qs=sGAEpiMZZMtHyRFzBQ9JV7lHCd3Ac%2fuF

http://www.mouser.com/ProductDetail/Murata/CSTCE16M0V53-R0/?qs=sGAEpiMZZMtJvlLX7mFQSMq7sq2y9lFR

[tim7]

the average error is 43ppm,

That surprised me a little bit. Most crystals are 1ppm/c, and 20ppm initial so unless yours was exposed to 20c+/- variations it is hard to produce that kind of drift.

Hi Dhenry,
I think you're mixing up frequency stability and average error.  I measured a variation of approximately 0.28ppm/C, which is well within spec.  Average tolerances of +/-50ppm are common, so an average error of 43ppm is reasonable.

[retrolefty]

I wonder if I can use their boot loader on a Duemilanove.

Sure, I've burned Uno bootloaders into most all my 328p based boards and modules. You just have to remember to then always select Uno as the board type when uploading to the ex-Duenilanove board.

Lefty