High Accuracy Quartz Clock - DIY - Part 1

[@erlendse]

Keep in mind, a wristwatch is technically a oven occilator (ocxo). Basically the crystal is kept close to 37C, or something F. If you want to match them, a oven occilator would be the way, possibly disiplined by a GPS/GNSS reciever. Also, as others have mentioned, that microcontroller clock isn't worthy a go. You would ideally want a clock of discrete logic, BCD counters e.t.c. Otherwise, a alarm-clock that use mains frequency could be a starting point for some modifications. They take 50 or 60 Hz on a pin, and use hardware dividers in a application spesific integrated circuit.

[@erikderuiter7475]

I presume you know Brett Oliver already?! He makes THE beste electronic clocks... His work is unsurpassed. If not you will be utterly amazed.

[@windward2818]

The reasonable target for overall drift of an oven controlled quartz oscillator is basically what you have shown, being somewhat close to the 127 ppb total drift, or a timing error maximum of +/- 4 seconds per year. In order to get the 127 ppb the OCXO (TCXO) has to have an ultra stable supply, have a buffer to keep output current constant (very low) and then keep the clock at around room temperature, and then pray the TCXO aging is as per advertised in the data sheet. There is really no need to subdivide the clock as an input to control a clock, just use a TCXO that has a good base frequency to run the uC clock input, then through a timer unit clock chain to provide the timing pulses you require, it is assumed that you can eliminate clock jitter and timing errors by understanding how the clock chains and uC subunits work and making the appropriate modification is firmware, you may need to add a little glue logic. If you use an ARM uC from ST (and many others) the uC will power up on an internal RC oscillator, so you can then check if the TCXO is stable, and then switch over to the TCXO and start running your application. The base error problem is very interesting, however with the newer low cost GPS receiver ICs + antennae (that seem to be dropping in price all the time), you can certainly scan for satellites during the day and if you can find enough, which should not be a problem if you check once an hour (you are fighting the line of sight meteorological challenges), you can correct the very accurate base timing TCXO clock by using the GPS time. If you don't want to use GPS, then use the Internet, or the Cell tower or the Radio Time signals, or you can use a combination if you want, to adjust for daylight saving time if used in your area.

[@davidv1289]

I believe you will find that the jitter (and possibly some of the drift) you are seeing is caused by the algorithm used by the mpu to divide the 12 MHz down to one. I would suggest using a 12.8 MHz OCXO and write your own algorithm (divide by 10 five times then divide by 2 seven times) to get exactly 1 pps or dump the mpu and use decade counters and flip-flops - there are "HC" series logic chips currently available that go to 35 MHz (old guy solution). A classic example of the algorithm problem can be seen by programming a Ublox NEO-7, which uses a 48 MHz internal clock, to output 10 MHz. The output looks "jittery" but in fact it is not random jitter, it is a repeating string of different width pulses. You might look at your 1 pps output and measure the pulse widths to see if you get a repeating pattern of different pulse widths.

[@erlendse]

If I recall right, that chip can't output a 1 pulse per secound by hardware. Basically there is a software component in blinking the LED's, and there are not totally deterministic timing on microcontroller software. (may be some exotic exceptions)

[@davidv1289]

@@erlendse You are correct, I was speaking of programming it for 10 MHz output, an example of jittery output caused by an algorithm used to divide the 48 MHz internal OCXO

[@cmuller1441]

I received a casio waveceptor as a gift 10 year ago and it has 0 seconds drift! Because it syncs on a radio signal from an atomic clock... (DCF77) And it has a solar cell so no need to recharge or change a battery. The price is the same has a smart watch but it gives time reliably... I tried some Fitbit stuff but what a pain to recharge it every few days. Not counting the fact that you have to get a new (crappy and expensive) bracelet every year because it breaks...

[@ChrisSmith-tc4df]

Given the length of coaxial cable run from the function generator, I would suggest putting a ~50ohm terminating resistor to ground on the xtal input, and then clipping on to that with the function generator configured for 50ohm output operation. This would ensure crisp, relatively ring-free edges arriving at the microcontroller.

[@cannesahs]

19:34 No way that oscilloscope internal oscillator is reason for your measurement. it doesn't cumulate over time to what you see on oscilloscope screen. If it would be cause to all you see, then a 56ms pulse length one measured yesterday would show as a about 140ms long pulse today.

[@willishendley8924]

Hello Martin, i’m enjoying your voyage of discovery in this series. A couple of things, since you are comparing two “in phase” signals I believe the stability of your oscilloscope is more than adequate for the task. Secondly if you haven’t discovered the “time nuts” community online then I highly recommend subscribing as they will really take you down the rabbit hole on the subject of accurate time measurement.

[@erlendse]

Your observation about the scope seems right, I don't know any scope with "10 MHz ref in" on the back for the accurate stuff. But the scope is NOT telling the whole story.

[@willishendley8924]

Agreed, but it’s going to be interesting watching Martin gradually discovering all the contributing factors.

[@erlendse]

@@willishendley8924 Totally. Been there done that.. but for a different use, and higher requirements.

[@djb22]

Definitely not the scope.

[@Pawel5837]

But, but, but, I just thought I reached the end of the science, almost seeing electron falling apart, and ,..?! Part two is coming???!

[@ebenv1]

Hi Martin, could you please let me know what the model is of the Casio watch is you mentioned on here?

[@electronic7979]

Super 👍

[@mariushmedias]

Why waste your time with that micro. You don't have the source code so you have no idea how it calculates time (does it use internal timers, interrupts etc) and you don't know the quality of the microcontroller (maybe it was a reject) and even if you calculate everything, most likely the frequency will drift significantly with the temperature in your room. Digikey > Integrated Circuits (ICs) > Clock/Timing - Real Time Clocks ... you have hundreds of various real time clock / calendar chips that use a 32768 Hz crystal to keep time. You could go overboard and use 2 or 3 from different manufacturers at the same time and determine the drift over 1-2 days and a few times a day, calculate the actual time based on how much all two-three clocks drifted.

[@erlendse]

Maybe.. any that allow inputing a external clock there? Like 10 MHz from the lab?

[@mariushmedias]

@@erlendse why would you? they each have their own 32768 Hz oscillators and you can calibrate them and even after calibration, and you know how much they drift even with calibration after a certain period of time, so knowing the drift of all clocks, you can get a more accurate actual time.

[@erlendse]

@@mariushmedias Sure.. but I expect mjlorton to end up with a OCXO (oven crystal occilator), and the ones you mentioned would be less accurate. They are even temprature sensitive. Like 10 MHz referance to the whole house, based on OCXO and GPS/GNSS time.

[@cmuller1441]

I don't understand why you spend so much time on that bad Chinese clock. You could have make your own one with a cheap mcu and your own code in it. Just using a auto reload (edit: I meant hardware) counter that makes an interrupt every second in which you toggle an digital output for minimum jitter. You take care of the main HhMmSs display in the main() code after a wait for the return of the interrupt.

[@CDN_Torsten]

I was thinking the same thing. The FW in the inexpensive clock may not have it's code optimized to run as accurately as Martin wants...

[@cmuller1441]

@@CDN_Torsten if it's supposed to work on a 12MHz clock, why does it need 11.9... ? I bet the developers have messed up and one second needs a little bit less that 12 000 000 clock ticks. They are probably counting cycles "by hand" in a loop. The problem is that depending on the path taken in the code (in "if then else" statements for example) the duration is slightly different... So if you want to adjust the clock you need to check the duration of a whole day. The whole story is to compensate for a crappy firmware?

[@CDN_Torsten]

@@cmuller1441 I think the whole FW needs to re-written from the ground up using the MCU's HW timers to count clock cycles. I too suspect they either used hard-coded loops and/or may be missing some counts due to housekeeping activities in the code...

[@cmuller1441]

@@CDN_Torsten that's exactly what I meant in my first post

[@NiHaoMike64]

Easiest option would probably be to reprogram it.

[@coldfinger459sub0]

Warning ⚠️ mjlorton may jibber jabber a lot of tech stuff lol 😂. It’s the learning process that is important. Not that it is a cheap Chinese clock with probably reject chip set, faulty code, vary low tolerance components. It’s the cool fun factor of upgrade tinkering, modifications even though 40+ man hours and even one high quality component will cost more then the entire kit. And yes factor in the 20K to 30K in test equipment used to do all this. It stimulates the learning mind.

[@erlendse]

Yep, totally. There is no limit for how high price you can go. Just look for "time nuts" using one of the web-search places.

[@jdmccorful]

WOW!!!!!