Poor clock accuracy of UNO

Strange, my Uno (purchased 3 weeks ago from Farnell in the UK) does use a crystal.

Yes but they probably bought one of the first batches and still have them in stock. My UNO also has a crystal and I dislike resonators for the same reason. However I usually end up making the arduino on strip board for most of my finished projects and I always use crystals.

dc42:
Strange, my Uno (purchased 3 weeks ago from Farnell in the UK) does use a crystal.

Yes, the present board PCB layout allows them to install either. It might depend on what their parts inventory situation is at any specific time, or perhaps you got a older revision board even though bought recently?
The board rev number should be printed somewhere on it.

Lefty

Bobnova:
One part with three pads is significantly simpler than three parts each with two pads.
It seems to me that there aren't that many applications that are going to run for long enough for +/- 0.25% to be a problem but not long enough for the crystal's error to be a problem. That's what RTC modules are for, after all.

I, of course, am simply guessing.
They do sell a lot of boards though, if they can save $0.50 per board that adds up over the course of 10,000 boards.

I can think of various applications where an RTC isn't useful but accurate timekeeping is (frequency meter for one, time-muliplexed wireless mesh nodes, electronic tuning-fork or guitar tuner, strobe light trigger and most obviously electronic stop-watch...).

The irony with the Uno is that the 16MHz crystal on the 8U2 could drive the 328 or vice versa - which would be even fewer components.

The board rev number should be printed somewhere on it.

It says "Board model UNO R2".

Mine says R2 also, which I got from a workshop a few weeks ago. It has a 3-pin resonator and a 105 resistor between the two far pins.
I've heard of a term "crystal oven" to stabilize crystal oscillation frequency by stabilizing temperature. If you really want long-term accuracy on crystals, you should have that. Plus, suspending the crystal inside of vacuum may be a good idea too, to prevent it from catching any dust that reduces frequency :wink:

BTW, I don't have need for UNO either but it was from the workshop I paid for. It uploads faster than Duemilanove. I wonder if I can use their boot loader on a Duemilanove. :roll_eyes:

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

Yes you can. You will however have to remember to select Uno as the board type after you do that. That is how the IDE knows what baudrate to use to talk to the bootloader for a upload operation.

Lefty

Thanks Lefty. I'll give it a try.

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! :smiley:

![](http://timgiles.free.fr/forumpics/ceramic resonator.png)[/list]

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 :wink: Someone should update this number.

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

Thanks 8) ...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.

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.

...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.

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.

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%.

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

http://jorisvr.nl/arduino_frequency.html

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.

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.

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. :wink:

Lefty

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.

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.