Like many electronics hobbyists, [Pete] found that he had an overwhelming desire to build a clock for himself. He didn’t want to stick a discrete real time clock IC into a box and call it a day, so he opted to construct his own around a microcontroller instead.
After researching the specs on a few RTC ICs, he defined some accuracy requirements for his clock, and got to building. He started out using a 32,768 Hz watch crystal, but found that the accuracy was off by about 46 ppm after only 24 hours of use. That fell well beyond his self-imposed +/- 3 ppm tolerance goal, so he purchased an oscillator with about 500 times the resolution of his previous crystal.
After writing a handful of code to ensure that the clock remains stable, he calculated that his accuracy should be about 0.18 ppm – well within his acceptable tolerance range.
[Pete] says that this is just the first part of his clock construction, and that future revisions should include plenty of additional functionality, so keep an eye out for updates.
I think the most eye catching thing of his setup is his board. I LOVE how the ?acrylic? edges glow.
I think something like that would do very well as an arduino bed, and I am extra interested in that with the new chipkits.
I cant help my self, many Uc have built in RTCC. So you can avoid the extra IC AND have a really serious RTCC that you dont have to debug quite so much, built in tuning circuitry , and tried and true registers, alarms etc etc.
Though I totally support any one who openly chooses the hard way to learn first. Thats the way I learn too.
Dugg for “I’m not sure why it is but, electronic hobbyists like to make clocks. We seem to be thrust towards them like electrons to a phosphor coated screen in a cathode ray tube. ”
Oh wait, wrong website.
Like the edge-lit plastic as well and agree with you addidis, doing is just about the best way to learn.
Wouldn’t the stability of the AVR crystal alone be outside the +/- 3ppm output spec? A typical crystal/oscillator data sheet has a base stability number at 25C, a voltage variation stability number, a temperature variation stability number and a number associated with the ageing of the crystal. These typically add up to several tens parts per million. This to me means that if the input voltage or temperature changes, the stability of this clock will change as well. Also, crystal ageing is around +/-5ppm per year typically.
The DS3231 and similar RTCs use temperature sensors to switch a capacitor bank that tunes an internal crystal to the right frequency. It also has an aging trim register if calibration is ever needed. Works out to about 2ppm, or a minute per year. The DS3234 is a MEMs oscillator that is more resistant to aging and shock/vibration, but is slightly less accurate at 3.5ppm.
Sorry, the DS3234 is also a crystal, just SPI instead of I2C like the DS3231. The DS3231M is the MEMs option.
he owns a koenigsegg?
I love him
I managed to get <3 seconds per day from a 32kHz crystal and a 4060. I think it was more luck than anything else, just happened to get the right resistor and capacitor values first time.
To prevent long term drift I have the clock re-sync periodically with the MSF low frequency time signal. The only problem I found with that signal is that reception is terrible during the day, so the clock has to re-sync at 3AM. I also made sure that if re-sync fails after one hour it gives up so that it won't mess my morning alarm up!
On an embedded system I have used a GPS PPS to adjust the timer in an embedded CPU to improve the accuracy of a 1ms system interrupt. This accounted for slight variations in the crystal temp and other tolerances in the crystal.
You can use the PPS of a GPS (make sure you have a good quality GPS module and a strong GPS signal) to characterise the oscillator and maybe even attach a temperature sensor so that you can make slight adjustments based the temp. That way once it’s free running you can be sure it’ll keep it’s accuracy as much as possible
You really have to consider the accuracy of the clock over a particular temperature range, since temperature is the primary influence over crystal frequency in most RTC circuits. You could probably make the clock quite accurate at one specific temperature by choosing exactly the right component values (loading capacitors), but to make it accurate over a real-world temperature range, not just at 20 °C, is a different story.
I want to make my own RTC because I am driven crazy by the Y/M/D H:M:S format of most RTCs… my requirements for any good timekeeping device are:
+ At least millisecond precision
+ Time stored as a monotonic number (e.g., milliseconds since an epoch time) and in UTC; all computations take place in UTC, converted to local time only for input/output — no adjustments for DST needed!
I have not found an off-the-shelf RTC that satisfies these goals.
Ctrl+F “Arduino”… WHAT? NO ARDUINO?! Finally, some _real_ work :P
/flamebait
@ColinB
Most probably because the most common demand for a RTC is the ability to either keep real time or count at 1Hz or 0.1Hz accurately. I have yet to see an application of counting milliseconds since epoch time in a uC which in general also adds complexities on account of it being a 32bit number. Y M D H M S are used because they are easy to assign quickly to registers and do math on.
@Garbz: For high performance data logging applications as well as other more general purpose embedded computing systems, it is useful to have subsecond timekeeping precision. By having milliseconds RTC precision, the real time clock can be used for event scheduling of low-level real-time events internally as well (e.g., sampling a sensor every 10 ms). Sure, you could settle for 0.1 Hz precision, but why? Millisecond or better precision will be much more useful for a variety of purposes.
@Garbz:
“I have yet to see an application of counting milliseconds since epoch time in a uC which in general also adds complexities on account of it being a 32bit number.”
Well, I use ARM Cortex-M3 which is a 32-bit core and so this is not an issue! Also, addition, subtraction, and comparison of 32-bit integers even on an 8-bit AVR quite fast, and these are the common operations that are performed on a time value.
Rarely do you have to multiply or divide a time value.
“Y M D H M S are used because they are easy to assign quickly to registers and do math on.”
That depends — what kind of math do you want to do on Y M D H M S values? You can add a day or a month, but you still have to worry about special cases like varying month length, leap day, etc. I find that keeping a monotonic second or millisecond counter is a much simpler and more uniform way of keeping time, and it lets you handle multiple time zones as well (including handling DST cleanly, or at least as cleanly as possible for that evil beast, the Devil’s Sinful Time).
“Real Time Clock?” As opposed to what? A fake time clock? What good would THAT be?
ColinB: yeah. those RTCs suck. The first thing to do is convert to unix time and move it back to UTC. From there, continue with a timer. Occasionally read RTC again if RTC is more accurate than CPU timing.
@Farkanoid LOL
@MoJo I used a 32k crystal and a 4060 in my senior project and i didn’t see any loss(down to the second) over several days. I used a Attiny85 and found that using interrupts to detect the pulse from the 4060 was much more accurate then polling. It was an audio sampling controller for biologist. I’m basing the no time loss on the windows file properties of the files recorded.
I really like the linked ‘NFT’ hack he used to calibrate the oscillator, it’s rather clever indeed, and useful for many things.
Though I agree, the temperature stability of his oscillator will probably swamp all other factors. I’m wondering if it would have been better for him to keep his 32Khz crystal and instead of adding or subtracting 1 ms from his time value, adjusting the next timer interrupt to be one cycle early or late. Those 32K crystals should have both better ppm and better temperature stability, and due to the lower frequency the error will take longer to appear.
Thats what Peter Danegger does here (the tick adjustment)
http://translate.google.com/translate?hl=en&ie=UTF8&prev=_t&sl=de&tl=en&u=http://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC
/Bingo
@error404:
Glad you like it.
Look at an XY cut (32kHz) crystal again, and this time look at the frequency vs. temperature graph.
The f/T stability is far better for AT cut crystals than for XY cut. If you do not need the low current consumption for on-battery timekeeping, skip XY, they are horrible. And what the nominal frequency is does not matter, 1ppm is 1ppm.