Poor clock accuracy of UNO

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

The price of the components is virtually the same, and the difference in complexity is negligible. The accuracy of the resonator is poor (>0.5%), meaning the UNO cannot be used for any kind of timekeeping :|. A crystal of the type used by the USO's own USB interface has an accuracy of ~30ppm, or a few seconds per day -- not brilliant, but enough for a lot of things.

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.

if you take a closer look at the board you can see that around the resonator there are 2 holes and above another 2 spaces for 2 smd capacitors from the looks of it they are 0603 case pretty easy to find so you just need to remove the resonator and the 1M resistor and replace it with a high quality crystal and capacitors

Mmm, but there are 45 components on an UNO board. I don't see that soldering 2 extra capacitors has a significant cost. Replacing the resonator with a crystal would actually reduce the number of different components the pick-and-place machines need to be loaded with.

A crystal would be >100x times more accurate than the resonator, keeping time to within a quarter of an hour over a year. For home automation tasks that's pretty much good enough. After a year my UNO would be out of whack by more than a day.

I noticed that in pictures of the UNO board there are spare solder pads around the resonator, but on the four I have here on my desk those solder pads are not present.

A crystal would be >100x times more accurate than the resonator, keeping time to within a quarter of an hour over a year. For home automation tasks that's pretty much good enough. After a year my UNO would be out of whack by more than a day.

While I certainly agree that a crystal is more accurate then a ceramic resonator, that does not mean the accuracy of the clock frequency will be totally dependent on the crystals stated frequency +/- it's worst case PPM specs. The actual frequency that the crystal will oscillate at is also dependent on the accuracy of the padding capacitors, and several postings have shown long term accuracy of a crystal controlled arduino can be worst then the crystals specification because of that.

The very first release of the Uno board did have a crystal installed on the 328p chip, but seemed to later change to the ceramic resonator. Me, I avoided buying a Uno on first release mostly because of the several bugs in the bootloader and 8u2 firmware, and so far have had no reason to purchase one even though most problems with the Uno have seemed to have been addressed.

Lefty

The accuracy of the resonator is poor (>0.5%), meaning the UNO cannot be used for any kind of timekeeping

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? The great thing about the Arduino is that if I am just flashing LEDs or logging data, I can use it. If the "time keeping" isn't good enough for either, I can add additional circuitry.

A crystal would be >100x times more accurate than the resonator

Do you have any data to back this up?!?! I'd love to show this in some of the work I am doing.

If long term time accuracy is an important part of a specific applications, then it deserves a proper solution, like a RTC. I like this +/-2PPM module: http://www.sparkfun.com/products/10160
Besides who likes having to reset the starting time on their arduino everytime they have to power off or reset to upload, etc.

Lefty

retrolefty:
Me, I avoided buying a Uno on first release [...] and so far have had no reason to purchase one

retrolefty:
If long term time accuracy is an important part of a specific applications, then it deserves a proper solution, like a RTC.

Spoken like a true engineer. Me, I'm just a poor hobbyist and generally happy with improper solutions. :slight_smile:

[quote author=James C4S link=topic=69316.msg513375#msg513375 date=1313296901]
Do you have any data to back this up?!?! I'd love to show this in some of the work I am doing.[/quote]

The UNO board I tested showed a timing error of 1% over 1 minute, and 0.2% over 1 hour. I've ordered a Freetronics "Eleven" board, which is identical to the UNO except for having a crystal oscillator and a few other minor modifications. I'll report here on what I find.

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.