Even the most punctual among us are content to synchronize their clocks to external time sources like navigation satellite constellations, network time servers, frequency-controlled AC mains, or signals broadcast by radio stations such as WWV, CHU, and DFC77 — but not [zaphod]. After building a couple of more traditional clocks over the years, he set his sights on making a completely isolated digital clock that doesn’t rely on external synchronization (well, except to initialize the time at first power-up).
The accuracy goal he set for himself was that of a Casio F-91W wristwatch, which is specified to maintain +/- 30 seconds per month (about 12 ppm). At the heart of the design is an oven-controlled crystal oscillator whose stability is in the single-digits parts-per-billion.
The counter chain that accumulates the time is implemented in an FPGA — admittedly overkill, but [zaphod] wanted to learn FPGA programming for this project as well. An ATmega328 drives the display and does other bookkeeping tasks. The whole design is partitioned into three PCBs which fit inside a custom 3D-printed case.
[zaphod] does a thorough job documenting his build, including the bugs and failures along the way. We like the honest summary he wrote at the project’s conclusion, noting things that could be improved or should have been done differently. Be sure to check out the GitHub repository, where all the source code and PCB design files are posted. How accurate is your wristwatch, if you even wear one anymore?
I hope to see many more FPGA projects
Seiko Kinetic self winding quartz watch: 5.2 seconds per month. Bought from Goodwill auction not working for US$42. Replaced rechargeable cell for $20. Would have been US$350 new and saved it from the trash. Fun, too!
Goodwill is a fantastic place to find stuff. Often simple to repair, ro a low cost source of otherwise expensive parts.
@[zaphod], So this FPGA clock has what looks like a commercial OCXO in it (Where is the BOM?), and the best it can do is +/- 30 s/mo or 11.57ppm for a 30 day month? If that’s true you either have a problem with the OCXO, and/or the bitstream is bad. After all, an FPGA is deterministic. Are you sure it doesn’t have an unadjusted VCOCXO in it instead of an OCXO? How many pins are there on the can? Usually an OCXO has four pins, a VCOCXO has five. Even if it was an unadjusted VCOCXO, 12ppm seems high. EFC range on a typical 10MHz VCOCXO is around +/- 7ppm. A typical affordable 10MHz VCOCXO [1] has around +/- 5ppb (yes that’s +/- five parts per BILLION) stability over the whole 0-50 degree Celsius range. With a calibrated oscillator, constant temperature, and being fed by a constant low-noise voltage, this FPGA clock’s stability should be so good it would be hard to measure.
* References:
1. Abracon AOCJY3-30603 5PPB 5V CMOS Squarewave VCOCXO Qty.-1 $130.38
https://www.mouser.com/ProductDetail/ABRACON/AOCJY3A-10000MHZ?qs=E5sDuDyvt8TCnu4WKn79lg%3D%3D
Datasheet:
https://www.mouser.com/datasheet/2/3/AOCJY3-30603.pdf
@[zaphod] Might want to look up NCO (numerically-controlled oscillator). It is pretty simple implementation for FPGA. I implement mine as a 24-bit NCO in firmware in 3-4 lines of code. It gives a very fine control for generating a low frequency IRQ for my digital clock firmware. With calibrations, I managed a +/- 1 second per month out of a regular +/- 100ppm regular clock crystal.
I got way as room temperature is usually a few degrees variation. I could have done much better with a TCXO on temperature stability.
tl;dr A clock is only as accurate as its calibrated source. I use time.is for calibrate – (manually) binary search for the phase increment for my NCO.
Stability =/= accuracy. The clock can be very high precision, but consistently inaccurate. :P
The accuracy can be improved by calibration, but few HaD level projects deal with that.
It does much better than +/- 30 seconds a month! I picked “the accuracy of a casio wristwatch” as my baseline for a usablely accurate clock before I’d started the project at all. The intent was always to exceed that by as much as I could. As it stands the clock’s accuracy is beyond what I can easily measure, but it far exceeds the minimum requirement of +/- 30 sec/mo.
the BOM is embedded in the kicad project which is actually in a different repo than the one linked in the article above: https://github.com/ZakSN/z_1_rtc_pcb/tree/2000hc-version (the repo above is just the verilog/firmware/software), the part number for the OCXO is: OX4150A-D3-1-20.000-3.3-7 ds: https://www.raltron.com/webproducts/specs/OCXO/OX4150A-D3-1-20.000-3.3-7.pdf
It looks like they had a goal of 12ppm, but at the end of the wrap up post, they mention that measuring the accuracy of the clock is its own project.
I really like stuff like this. Learning by doing is like walking the path of all the great minds of the past. Take what you know, gamble that you might be able to get from where you are to where you want to be, gather up what you can get your hands on, discover ways to move around obstacles, and enjoy the results!
The discipline to document the work is a vastly under-rated characteristic as well. Great project!
please make solid wood enclosure (meybe with cnc metal element)
and make croudfunding working device
I need this and I like reprograming/ localisation options etc.
One small idea. I need ethernet to for my own ntp server but meybe in 2.0 ;)
Another article write up idea. The grid no longer trims up on down the number of cycles to make line powered clocks very accurate and since 2018 has let this go by the way. They assume that those clocks have to be reset twice a year and that’s good enough.
We have an old synchronous motor clock that has to be started in the right direction when the power goes out. It now stops at random since the last year or so. I’ve cleaned and lubed it but still it stops. Coincidence? Cruder grid switching perhaps?
Oh really??? Do you have any source on that? That’s really surprising.