How to Accurately Measure External Oscillator

[jpanhalt]

Here is the external watch-crystal oscillator I am using:


It is built on strip board (3 holes per pad) for plugging into my breadboard. The circuit is here: https://microchip.wikidot.com/8bit:t1secosc
Frequency was a little high with 8.2 pF load capacitors, so I increased them to 10.4 pF each. With my scope and counter (Racal-Dana #1992), the frequency is now about right. When I use it to clock TMR1 and capture known frequencies, namely 60 Hz and 1 kHz, the 2 or 3 significant figure results are right on, but the crystal is supposedly accurate to 20 ppm or so.

If you put any load on the crystal, such as with the scope, you change its frequency. Is there an accepted and relatively easy way to determine its frequency more precisely in the MCU circuit?

John

 

[Les Jones]

Hi John,
I think the best way would be to use one of the counter/timer modules in the MCU to divide the clock crystal down to 1 HZ. Then phase compare it with the output of a GPS receiver module. Another possible solution would be to add CMOS buffer (eg 74HC04 or CD4050) to the board as a buffer between the crystal and the test point where you connected the scope. The buffer input would have to remain connected to the crystal oscillator all the time. When the BBC Droitwich transmitter was on 200 KHZ I built a 1 MHZ crystal oscillator that was phase locked to it. When it's frequency was changed to 198 KHZ I never got round to making a more complex divider chain.

Les.

 

[JimB]

If this were an oscillator built in hardware separate from an MCU, I would measure the frequency at the output of a buffer stage which isolates the "load" from the crystal circuit.

However in this case you probably do not have access to such a point.

If frequency measurement and accuracy are important to you, consider building a separate buffer stage, a single CMOS inverter would be a good start, or maybe a simple source follower using a simple JFET.

JimB

 

[jpanhalt]

Thanks for the reply. As so often happens with me, once I write and post a question, the solution comes to mind.

Roman Black and Ken Moffett have both presented accurate 1-second pulse generators. Roman's is MCU and software, Ken's is based on a cheap wall clock.
Since it is getting dangerous in the US to possess wall clocks , I will try Roman's solution first. On ETO, he only gave the C code, but on his site, he gives the Assembly code: https://www.romanblack.com/one_sec.asm That code seems easily enough to adapt to a 12F5xx (no interrupt) or the 12F6xx. I have 4 MHz resonators on hand.

Since TMR1 is 16 bit, if the one-second pulse is accurate, I should be able to confirm the accuracy of the TMR1 clock.

If I am allowed to change my question: Does anyone here have experience with RB's error-corrected clock?

John

Edit: I didn't mean to ignore your comment. A few years back, I did exactly as you describe using a crystal-stabilized inverter oscillator. I was impressed with how stable and accurate I could make it using the Racal-Dana counter. But, as you note, I don't have that access with the MCU; moreover, stray capacitance in the MCU is not insignificant, according to the Microchip forums..

 

[ericgibbs]

hi John,
Ref the RB 1Hz accurate clock, it is only accurate if the crystal stays on frequency.
The claimed 1hZ accuracy is only in the software counter timing.

E

BTW: I use the DS3231 RTC, it is VERY accurate

 

[jpanhalt]

That is an interesting chip and as your say, quite inexpensive. Probably worth getting a couple just to have around.

John

 

[ericgibbs]

That is an interesting chip and as your say, quite inexpensive. Probably worth getting a couple just to have around.

John

hi John,
This is the Amazon part I buy, ready made PCB, complete with Coin battery
http://www.amazon.co.uk/SODIAL-DS32...cp_7_B7HM?ie=UTF8&refRID=074DRWJ7G3Y1MNK1JW2V

E

 

[Nigel Goodwin]

Bit expensive from there Ian?.

https://www.banggood.com/DS3231-AT2...al-Time-Clock-Module-For-Arduino-p-81066.html

There are some really great cheap modules out there, often labelled 'Arduino' as this one is.

 

[jpanhalt]

Yep, really too much, so I got an additional $0.10 discount each and bought three.

John

 

[MikeMl]

I would listen to Harmonics of the oscillator (or the cpu) on my general-coverage short-wave receiver between about 100kHz and 1Mhz. Then I would use my RF signal generator to zero-beat the harmonic. The generator can be connected to my freq counter, so I can measure the harmonic frequency to about 1 part to 10exp-9...

This way, the extra capacitive loading of the oscillator due to the measurement hardware is about 0.00001pF

 

[JimB]

An excellent idea Mike.

Why didn't I suggest that?
Probably because it is only us radio amateur weirdos who have suitable general coverage receivers to be able to do that sort of thing.

JimB

 

[MrAl]

Hi,

There is one solid way to check clock frequencies that doesnt cost anything, maybe as your final test.

But first, let me reply a little here...

Eric:
Yes good point (about frequency drift even with static calibration) and i had offered that insight a year or more ago but it was not well received so i did not push it. Anyone here will note that the good oscillators have a dynamic drift compensation, it's never a one time thing and then forget about it.

John and Others:
One way to check your clock frequency is to create a long chain of counters, either with pure logic (like TTL or CMOS) or in the uC program code itself. You set it up so that it counts up (or down) to the number of microseconds in one 24 hour day (or whatever units are convenient for your project) and then have it emit a single LED flash, then start over again. You then synchronize the flash with a wall clock or desk clock or wrist clock, known to keep good time over the years. An atomic based clock would be good here.
When the time for the flash grows near, watch both the clock and the second hand or digits. If the oscillator is true to it's frequency, then the flash will occur exactly at the moment the second hand reaches the same number as it did the day before.
If the oscillator is off more than we like for good time keeping, the error will be at least 1 second off. That's equivalent to about 6 minutes per year, which is considered marginally good for timekeeping.
For a better accuracy check, let it run for another full day, then check again. If it is off now by a full second, that means only 3 minutes per year.
After another 2 days of run time if it is off by only 1 second, that's 1.5 minutes per year.
So the longer you let it run, the more accurate your test will be.
If you let it run for a whole month (which you'll have to do anyway if it ends up being a wall clock) and it is only off by 1 second, then it's only off by 12 seconds per year.

But anyway, those modules being talked about are pretty interesting. They rely on a chip that has internal compensation for temperature which helps keep it accurate. The frequency might vary up and down a little that's mostly it, but they should be checked anyway. There is probably a long term stability spec too.

 

[large_ghostman]

How accurate is the above in the real world? I am thinking specifically about UC code here, it would tie a timer up and you would need to be careful with interrupts.
Depending on what the code actually did wouldnt it get thrown off by the code having to branch and take care of other interrupts?
What I mean is all but the simplest of programs could affect the timing of an interrupt, and would certainly need a timer to themselves, or am I misunderstanding?
6 seconds a year is more than I thought, so based on that even the internal timers are not too shabby! thats good to know for the future, I read elsewhere on here a while back about syncing to the mains frequency. No idea how practical that would be for this

 

[MrAl]

Hi,

uC branch timing:
Yes any branch of any kind needs to be carefully timed and applied in order to keep the timing accurate. A typical way to achieve this is to add stuffing bytes to keep the routine the same cycle length no matter what branch it takes, which then makes calculating the total time easier. So if the difference between a jump and non jump is 4 clock cycles then you add an instruction that takes 4 clock cycles when it does not jump. Thus, if it jumps or not it takes the same amount of time to execute.

Line frequency based clock timing:
Back in the 1980's that's how we did wall clocks, by sync'ing to the line frequency. That made sure that the clock was accurate for a very very long time if not forever. But that worked because the power company was constantly adjusting the line frequency to keep the total cycle count correct for that time. So for example if the frequency went down to 59Hz for 1 minute, then they would raise it up to 61 Hz for 1 minute (collectively) later. This kept the average frequency extremely close to 60 Hz. Any wall clock that based it's timing on this would stay accurate for years if not for as long as it was plugged in.
But today that standard may not be the same. I read several years back that they were changing this standard of adjusting the line frequency. What i dont remember however is what they were planning to change it into. They might still be keeping the average frequency constant, but i would try to find more info on this before i built another clock based on the line frequency. Study the effects of the change first, then build or dont build that way depending on the projected accuracy of the clock based on the new practice. Of course you also have to check other countries standards if applicable.

Modern clocks:
For a modern clock that operates on batteries, a real time clock (RTC) chip is the only way to go unless you want to sync to the atomic clock signals available these days. That requires a receiver of some type. You might still want the RTC chip too though.

 

[Nigel Goodwin]

Modern clocks:
For a modern clock that operates on batteries, a real time clock (RTC) chip is the only way to go unless you want to sync to the atomic clock signals available these days.

Not at all, a great many PIC's have the capability of using the same 32KHz clock crystal as the RTC chips on one of the timer modules, creating a very low power and highly accurate clock signal. It's easy to write a program to wake the PIC from sleep every second via a timer interrupt, and the few microseconds it's awake don't cause any battery consumption problems.

 

[jpanhalt]

MrAl
This project used TMR1 running continuously in capture mode. Only two events were involved, but they were up to 1 second apart and always several milliseconds between them. There were no interrupts, but of course, sloppy coding can screw up anything. Capture can also be done using an interrupt, but again, there is little need to adjust for those interrupt latencies, because one is subtracting, say T1 from T2, and they cancel out.

My question was how to measure the 32 KHz crystal without affecting its frequency for the purpose of finding the correct load capacitors for an undocumented device. Mike's suggestion (post#10) was the most direct way, but I do not have the equipment needed to do that. So, I dug out my Wavetek frequency standard (160 MHz to 0.1 Hz, 9 digit) and compared its reading to my Racal-Dana counter with similar precision. They agreed well enough for me, i.e., to ±1 ppm or less. They could be both wrong, of course. Then I used that to check my 1 Hz source (6 places), which was very close to the calculated loop time. Finally, I used that source to clock the TMR1 capture running at 32 KHz and got a very steady 7FFF result after adjusting the load capacitors on that crystal. I am awaiting the stable frequency source mentioned above from Banggood.

John

 

[Nigel Goodwin]

An obvious way would be to adjust it as you do a normal clock - set it to display a normal clock display and synchronise it with a known accurate clock, and compare the times after a couple of days - tweak accordingly.

Interestingly I repaired a 'watch adjuster' many years ago, it was an American device using valves (or tubes seeing as it was American ), it detected the 'tick' of the watch and compared it to an internal crystal oscillator. The 'display' was a line drawn on a paper roll, a straight line for accurate, and a gradually curving line (either way) for slow or fast. You simply adjusted the watch for a straight line - the watch went in a clamp, and could be positioned at various angles for checking accuracy in various positions.

It was a beautifully made piece of kit, I don't know how old it was, but it seemed a fairly 'modern' piece of valve construction.

 

[MrAl]

Not at all, a great many PIC's have the capability of using the same 32KHz clock crystal as the RTC chips on one of the timer modules, creating a very low power and highly accurate clock signal. It's easy to write a program to wake the PIC from sleep every second via a timer interrupt, and the few microseconds it's awake don't cause any battery consumption problems.

Hello Nigel,

I can not see how a single, solitary stand alone crystal can perform as well as a dynamically temperature compensated crystal circuit, which is how the good RTC clock chips are made. Also, i would question what load capacitors to use and what type of capacitors would be used. They also have to be temperature stable. But even with the right caps, i cant not see it performing as well as the well engineered RTC clock chips. The idea of the crystal oven had to come from some problem that came up

 

[MrAl]

MrAl
This project used TMR1 running continuously in capture mode. Only two events were involved, but they were up to 1 second apart and always several milliseconds between them. There were no interrupts, but of course, sloppy coding can screw up anything. Capture can also be done using an interrupt, but again, there is little need to adjust for those interrupt latencies, because one is subtracting, say T1 from T2, and they cancel out.

My question was how to measure the 32 KHz crystal without affecting its frequency for the purpose of finding the correct load capacitors for an undocumented device. Mike's suggestion (post#10) was the most direct way, but I do not have the equipment needed to do that. So, I dug out my Wavetek frequency standard (160 MHz to 0.1 Hz, 9 digit) and compared its reading to my Racal-Dana counter with similar precision. They agreed well enough for me, i.e., to ±1 ppm or less. They could be both wrong, of course. Then I used that to check my 1 Hz source (6 places), which was very close to the calculated loop time. Finally, I used that source to clock the TMR1 capture running at 32 KHz and got a very steady 7FFF result after adjusting the load capacitors on that crystal. I am awaiting the stable frequency source mentioned above from Banggood.

John

Hi John,

That sounds very good so far. Keep in mind though that to fully test an oscillator of any kind means to test it over time and temperature. A week for starters, and the temperature range has to match the expected environment temperature change for which it will be used in.

 

[Nigel Goodwin]

I can not see how a single, solitary stand alone crystal can perform as well as a dynamically temperature compensated crystal circuit, which is how the good RTC clock chips are made. Also, i would question what load capacitors to use and what type of capacitors would be used. They also have to be temperature stable. But even with the right caps, i cant not see it performing as well as the well engineered RTC clock chips. The idea of the crystal oven had to come from some problem that came up

I think you're over-imagining what the cheap RTC clock modules are

Assuming they do use special capacitors, then using the same capacitors on a PIC would give a similar result - the RTC's are just a chip with an external crystal and capacitor, just like TMR1 on a PIC.

Why do you imagine they are 'well engineered', and what do you mean by that?.