Extremely accurate frequency counter

[rossmoffett]

I'm enrolled in a nano-scientific instrumentation program, one of the first of its kind.  The instructor decided that a good project for us would be to build a thermal evaporator, a device that evaporates metal in a vacuum in order to plate some other surface with a thin layer.

The instrumentation portion is to monitor a quartz-crystal-microbalance.  This is just a crystal with a known surface area and resonant frequency.  We will place it nearby the surface that is getting plated.  Its frequency changes as it accumulates mass, but only minutely.  By modeling the deposition as a crystal structure, using the known mass and surface area and fudging the numbers a bit we can determine the thickness of the deposition to +/- an Angstrom (ten billionths of a meter).

The trick here is to get very small changes in the frequency of the crystal.

My plan is to use a Pierce Oscillator to drive the quartz crystal.  I obtained a very accurate clock crystal (+/- 1 cycle per 10 million cycles) to compare it with.  I will use the Quartz Crystal Microbalance to clock a binary counter while the reference clocks another binary counter.  When the Quartz Crystal Microbalance counter reaches some pre-determined bit, I will shift the reference count into a register and read it with an Arduino.  I will know how many counts this equals, so I can determine a frequency that is (hopefully) extremely accurate with this method.

Here's the problem though... The reference can be assumed to be 1/20,000,000 of a second (because it's a 20 MHz clock).  I might know that I'm counting, for example, 8,192 pulses (13th bit) of the Quartz Microbalance, and it took 16,384 reference cycles for that to happen.  I then know that I have 10 MHz resonance on the Quartz Microbalance.  Drop the reference by only one though, and I now have 610 Hz difference!  The precision sucks.

So, I'm forced to use a longer sampling period to increase the accuracy.  I chose to simply add another counter clocked by the already much divided Quartz Microbalance frequency (simple way to carry over and make huge binary counters).  I think a sample every 500 ms is decent.  I'll make an assumption that my Quartz Microbalance will clock at about 10 MHz, this means I will need to count about 5 million cycles of the Quartz Microbalance before I shift my reference count.  2^22 is just below this at 4,194,304 so I'll use a 22 bit counter.  When the 22nd bit goes high, I shift my reference count into a register.

To get my precision, I'll again see how much the calculated value shifts when my reference clock changes by one count.  I know that my Quartz Count/Quartz Frequency = Ref count/Ref frequency.  Re-arranging, I get:

(Ref Frequency[Quartz Count]) / (Ref Count) = Quartz Frequency

(20,000,000 Hz * 4,194,304) / (10,000,000) = 8,388,608.000
(20,000,000 Hz * 4,194,304) / (10,000,001) = 8,388,607.161
(20,000,000 Hz * 4,194,304) / (10,000,002) = 8,388,606.322
(20,000,000 Hz * 4,194,304) / (10,000,003) = 8,388,605.483

So I have a precision of about 1 Hz, with accuracy of +/- 1 Hz due to my reference crystal inaccuracy.  Get this - it translates to a final precision of about 50 nanograms on the crystal though!  It gets better as the surface area of the crystal increases.  I think this is a really great example of how some simple electronics can give you insight onto some very, very tiny things.  The only thing I'm worried about now is how the big numbers will work out inside the Arduino platform.. I worry about how much time it will take to calculate my final derived value with all of the large numbers.  I'm thinking about just using integer values for frequency because of the +/- 1 Hz uncertainty that is there anyway.

Anyone else designed a frequency counter before?  I'd love insight!

[EEVblog]

For low frequency measurement you really want's called a "period mode" frequency counter.
Instead of using the master clock as the reference, it works the other way around and uses the input signal as the reference clock and then it counts the numbers of high frequency cycles. It gives a result in time which you invert to get frequency.  Any good frequency counter will have such a period mode. It gives you much greater resolution on low frequency signals.

That reminds me I've got a rather interesting story about crystal clock drift I've been meaning to blog about from day 1.

Dave.

[alm]

I've never designed a frequency counter, but I'll try to give some helpful information, feel free to correct me if I'm wrong.

I wouldn't worry about performance, you have about 500ms to do the conversions (minus communication overhead). Even an Arduino should be able to multiply two multiply two 32-bit integers (or floats) within 10⁷ clock cycles (assuming 20MHz clock).

The good news is that accurate frequency measurements are relatively easy. Try to obtain a voltage source with 0.1 ppm error!

What you're doing is reciprocal counting (counting the number of reference counts during one period of the signal, or 2^22 periods in your case). This is normally used if the signal frequency is much lower than the reference frequency, so you don't need very long gate times for low frequencies, but it also helps in this case. This Agilent appnote might be a helpful resource (linked from Wikipedia). The advantage of using reciprocal counting when the reference frequency is higher than the signal is that the +/- 1 count uncertainty on the 'counted' signal is smaller. After 2²² counts of your signal, were there exactly 2²¹ counts of the reference clock, or 2²¹+0.9? This is described in the Agilent appnote under 'Sources of Measurement Error'. The faster the signal with this +/- 1 count uncertainty, the smaller the effect on the final result. So a +/- 1 count uncertainty on 10MHz is twice as significant as on a 20MHz signal. A longer gate time also reduces this error. The error of your timebase is +/- 0.1 ppm (assuming you count at least 10⁷ reference cycles, which is true at 500ms/20MHz), the +/- count error of a 20MHz signal is +/- 0.1 ppm at 500ms, the total error would be +/- 0.2 ppm. At a 1s gate time, the error would be reduced to 0.1 ppm + 0.05 ppm = 0.15 ppm. Add to this possible rounding errors.

I would probably use floats for this calculation. Your calculation would be 20*10⁶/counted value*2²², and I don't really see how to do this without 64-bit integers (you either get a value around 2, or around 10¹⁴.

Alson

[jahonen]

Reciprocal counting (period) is the way to do it. Agilent frequency counters use this technique, and get sub-Hz resolution in considerably less than one second integration time. I have been also going to start designing a frequency counter using a FPGA/CPLD as a counter, possibly followed by some MCU for display, UI and PC interface.

It really comes down whether you want accuracy or resolution. These things get often somewhat mixed 1 Hz drift on 10 MHz signal is 0.1 ppm absolute accuracy! Normal good quality TCXOs are usually 1 ppm, ten times worse. Standard oscillators and crystals are specified at 50 ppm.

In case of absolute accuracy, you'll need a very accurate timebase oscillator for sub-ppm absolute accuracy. Better crystal oscillator ones are usually OCXOs. Then comes temperature stability, aging drift etc. If you really want it good, forget crystal oscillators, get a rubidium or a cesium frequency reference. A good thing about cesium frequency standard is that it is the primary standard, you don't need to calibrate them. Of course the accuracy comes with a price.

One should be careful when using floats, single precision floating point is accurate only up to 10^-7, double precision up to 10^-15 or something like that.

Regards,
Janne

[jimmc]

At present you are measuring the period of 4,194,304 cycles of the microbalance in 50nS steps (1/20MHz).
If you could use a simple frequency doubler (or even quadrupler) on microbalance output then a straight counter will give you exactly 1Hz resolution with a 500mS (or 250mS) gate time.

The hardware for this is relatively simple, Google Terry Weeder and 'Frequency Counter' for a plethora of designs, some having RS232 outputs (look for 16F628) eg http://www.piclist.com/techref/piclist/weedfreq/4bitlcdusart.htm
(All written in PIC assembler  {  Dave}, seriously it has to be assembler as the timing is done by the number of instructions executed)

If you want extreme accuracy (10^-10)with no drift and can see the sky, look at a GPS disciplined frequency standard eg Trimble Thunderbolt these are common on eBay and relatively cheap second hand. (Their output is 10MHz.)

[alm]

If you want extreme accuracy (10^-10)with no drift and can see the sky, look at a GPS disciplined frequency standard eg Trimble Thunderbolt these are common on eBay and relatively cheap second hand. (Their output is 10MHz.)

I wonder how well this would work. GPS disciplined standards have good long-term stability, but the short-term stability is usually only provided by something like a standard crystal oscillator (maybe TXCO). If you measure the frequency only over one gate time, it's about the accuracy of the frequency during that 500ms.

From what I gathered from rossmoffett's post, he already has a standard with 0.1ppm accuracy, if that's the case, he won't get anything better without spending big bucks. And he's already using the reciprocal method (if I understand his post correctly).

Alson

[jimmc]

I wonder how well this would work. GPS disciplined standards have good long-term stability, but the short-term stability is usually only provided by something like a standard crystal oscillator (maybe TXCO).

Alson

I was being pessimistic! I quoted the Trimble figures for the TCXO version (10^-10 in one second), the OCXO version on the surplus market is much better (2 x 10^-12 in one second).

See here http://www.leapsecond.com/tbolt-faq.htm
and here http://www.leapsecond.com/pages/gpsdo/

The problem with OCXOs is long term drift, without frequent recalibration the drift can be much more than the quoted stability; even worse, unless the unit is continuously powered, other effects may dominate.
see http://www.vectron.com/products/ocxo/ocxos.htm fig6

Jim

[rossmoffett]

Wow, thanks for the strong response!  A lot of good advice here, and links I didn't find when I was searching for them.  Thanks a lot, everyone!  Because this is a school project, I'm on a budget, and I've already got these parts on hand so I think I'll stick with them.  What I was wondering is given what I have, is this the best way to go about it and I guess the answer is yes.  I saw the atomic clocks when I was first researching this and immediately dismissed them as too expensive for this project.  The whole reason I had to design it was because a commercial QCM cost several thousand dollars and I thought I could do the same thing for $100 USD.  I'm actually considerably below that, as the most expensive part was the accurate clock at $35 USD.

From what I gathered from rossmoffett's post, he already has a standard with 0.1ppm accuracy, if that's the case, he won't get anything better without spending big bucks. And he's already using the reciprocal method (if I understand his post correctly).

Alson

Yes, I think I am, but I'm doing more math than a simple reciprocal.  My reasoning was that I can use integer math and not lose any accuracy, plus perform the calculation faster.  Also, I'm sort of used to trying to do everything with integers because of all of the low end programmable logic controllers I've used.  Otherwise, yes, I'm using the signal as the reference and then counting the higher frequency (20MHz) accurate clock.

For low frequency measurement you really want's called a "period mode" frequency counter.
Instead of using the master clock as the reference, it works the other way around and uses the input signal as the reference clock and then it counts the numbers of high frequency cycles. It gives a result in time which you invert to get frequency.  Any good frequency counter will have such a period mode. It gives you much greater resolution on low frequency signals.

That reminds me I've got a rather interesting story about crystal clock drift I've been meaning to blog about from day 1.

Dave.

I think I was maybe a bit unclear in my description, I'm not really going to school with a bunch of electronics engineers so I don't get to talk shop often.  Sorry about that!  As described, I believe I am doing as you suggest as the input signal is going to be counted to some set number and then the reference clock count shifted into a register.  I neglected to invert the absolute time so that I wouldn't need to use floating point math, which I've heard is pretty slow in an Arduino.

I'd love to hear your clock drift story, these industry-centric blogs are my favorite.  What makes the engineer is all of the things that have gone wrong, as you described in, "I hope your next project doesn't work."  Stuff comes out in these stories that I never would have even considered and I can't get enough of it!

[Andrew]

I don't trust your 0.1 ppm crystal. It might say that on the tin, but I doubt it, because bog-standard crystals don't come with that stability. 0.1 ppm is in the domain of OCXOs, not simple crystals. Even 1 ppm would be in the domain of at least an TCXOs and not just a crystal.

Also, there is not only crystal stability, but crystals are temperature dependent and do age, too. You would for sure have to drive your 0.1 ppm crystal within very restricted environment boundaries.

And a crystal just plugged into a crystal oscillator circuitry in no way guarantees that the oscillator oscillates at the nominal crystal frequency +/- the specified stability ppm. Crystals are "pullable", their frequency depends on the load capacity. When designing and building a circuit you only have cosar control over the actual load capacitance (you have stray capacitance and you won't find highly accurate ceramic caps). I remember ranges of +/- 150 ppm over which crystals can be pulled. And your circuit will accidentally pull the crystal, so you will have to have adjustable load capacitance.

That means, if we continue to assume you have that magic 0.1 ppm crystal, and you drive it in a very stable environment you will still need to calibrate your circuit, and you will need to re-calibrate from time to time, depending on the aging of the crystal and all other components. Your calibration source then needs to be better than 0.1 ppm, so either a high-end OCXO or you are about to enter rubidium oscillator territory.

I must say I see a typical mistake in the approach discussed here. People quickly dismiss the analog part and jump to the digital part, discussing trivial things like a counter, multiplying a few integers and doing fractional arithmetic, and acting as if these are the real problems. No, the analog part, your oscillator, your sensing of the crystal changes, your power supply etc. is the hard part. Running a few numbers through a f*cking MCU is child's play.

[rossmoffett]

I don't trust your 0.1 ppm crystal. It might say that on the tin, but I doubt it, because bog-standard crystals don't come with that stability. 0.1 ppm is in the domain of OCXOs, not simple crystals. Even 1 ppm would be in the domain of at least an TCXOs and not just a crystal.

Also, there is not only crystal stability, but crystals are temperature dependent and do age, too. You would for sure have to drive your 0.1 ppm crystal within very restricted environment boundaries. 

It's a VCTCXO, with a trim.  I guess I should have specified that instead of just calling it a crystal.  It does require regular calibration.  I just checked the datasheet and it has a drift of 1 ppm per year.  I was mistaken in the accuracy also, I shouldn't have quoted from memory, there is a .3 ppm accuracy in the spec.  Here is the part if you are interested.

And a crystal just plugged into a crystal oscillator circuitry in no way guarantees that the oscillator oscillates at the nominal crystal frequency +/- the specified stability ppm. Crystals are "pullable", their frequency depends on the load capacity. When designing and building a circuit you only have cosar control over the actual load capacitance (you have stray capacitance and you won't find highly accurate ceramic caps). I remember ranges of +/- 150 ppm over which crystals can be pulled. And your circuit will accidentally pull the crystal, so you will have to have adjustable load capacitance.

That means, if we continue to assume you have that magic 0.1 ppm crystal, and you drive it in a very stable environment you will still need to calibrate your circuit, and you will need to re-calibrate from time to time, depending on the aging of the crystal and all other components. Your calibration source then needs to be better than 0.1 ppm, so either a high-end OCXO or you are about to enter rubidium oscillator territory.

I was planning to use a digital sampling oscilloscope to check the exact clock, but now that I think about it in the context of what you're saying the o-scope itself may not be accurate enough to do that.  I'll have to look into doing some manual frequency checks using filters, see what kind of accuracy I can get that way with the instrumentation we have.  If you already know, I'd love to hear your advice!  I can almost guarantee that I won't have access to an atomic clock, and I won't have time to skip class to visit a lab that does in other cities.  That is, unless our watchmaking department has one around as a novelty, LOL.

As for what you're saying about the Quartz Crystal Microbalance sensor.. as long as the 150 ppm offset is consistently 150 ppm off, it's actually fine.  I just need to know the change in frequency from the start of my deposition to the end of the deposition, which won't last ten minutes. Am I correctly understanding you that the 150 ppm is an offset, and not a noise/fluctuation issue?  If it's not a consistent offset over small sample periods, you're right, I'm going to have to look at that very carefully.  In that case I may be able to do some statistical analysis to get a good measurement.

In the end, it will be awesome if I can get an accurate machine, but it's the journey that counts here.. if it doesn't work out, I thoroughly document the issues and why they arose and I still pass.  I will try hard to iron out these kinks though, thanks for your help.  I need all of the criticism I can get.  I think given what you've said, my precision will be dropped from 1 Angstrom to about 1 micrometer thickness, to be conservative, which is still pretty good.

I must say I see a typical mistake in the approach discussed here. People quickly dismiss the analog part and jump to the digital part, discussing trivial things like a counter, multiplying a few integers and doing fractional arithmetic, and acting as if these are the real problems. No, the analog part, your oscillator, your sensing of the crystal changes, your power supply etc. is the hard part. Running a few numbers through a f*cking MCU is child's play.

I wouldn't say it's a mistake, I think everyone probably just commented on their area of expertise.  Analog gurus are not common in the digital age, thanks for sharing.  There aren't many people like you that have had clock applications where a few ppm variation were a problem.

[jimmc]

OK, I think I understand what you're trying to do now.
I don't think you will have any trouble with the reference oscillator, the short term stability of quartz is very good. For intermittent use a TCXO was a good choice, it doesn't suffer the temperature cycling of an OCXO every time the power is cycled.
Hence it tends to have lower ageing under these circumstances.
The device you have chosen has a clipped sine wave output of 1v pk-pk, you will need an amplifier (biased gate?) to drive CMOS logic.

I think that the main source of frequency error is going to be the oscillator circuit associated with the microbalance.
Pierce oscillators using gates can be quite sensitive to IC temperature and supply voltage variations, so this is an area to keep an eye on.

Good luck

Jim

[jahonen]

I must say I see a typical mistake in the approach discussed here. People quickly dismiss the analog part and jump to the digital part, discussing trivial things like a counter, multiplying a few integers and doing fractional arithmetic, and acting as if these are the real problems. No, the analog part, your oscillator, your sensing of the crystal changes, your power supply etc. is the hard part. Running a few numbers through a f*cking MCU is child's play.

I tend to think that in real world, digital circuit is just non-linear high-bandwidth analog circuit which should be designed like RF

Regards,
Janne

[rossmoffett]

I think that the main source of frequency error is going to be the oscillator circuit associated with the microbalance.
Pierce oscillators using gates can be quite sensitive to IC temperature and supply voltage variations, so this is an area to keep an eye on.

Good luck

Jim

Is there a better choice than a pierce oscillator?  I mainly chose it because it looked very elegant and I didn't know what else to do.  There are crystal drivers on the market, but they're the size of gnats so I didn't want to deal with them.

[jahonen]

Maybe you could roll your own oven around the oscillator circuit, to improve the stability and make it less sensitive to changes in the ambient. Voltage regulation is also critical thing (line rejection and output noise is also relevant). But maybe not an issue if you oven your oscillator circuit. Another thing, don't overdrive the measured crystal, that will affect the results.

Also, maybe it doesn't affect much, but noise in oscillator signal will create small amount of phase noise (jitter) in the frequency measurement what will affect the measurement somewhat. That effect is notable when you start to measure something like 1/100's of Hz with 10 MHz signal. My friend's Agilent 53132 frequency counter shows the effect quite clearly.

Finnish radio amateur OH2AUE used a vector network analyzer to compare frequencies of two frequency sources. Maybe if you have access to one, this method may also be viable alternative.

Regards,
Janne

[jimmc]

Sorry if I confused you, I was trying to make the point that the frequency stability of your reference oscillator is likely to be better than the microbalance itself.
I know nothing about quartz microbalances so what I say applies to quartz crystal oscillators in general.

There is nothing wrong with the Pierce oscillator as such, but using a gate as the maintaining amplifier is not the most stable configuration; discrete transistors (or FETs) tend to give much better performance.

I don't know if this application note will help you... http://www.euroquartz.co.uk/Portals/0/pdf/tech-notes.pdf see page 6.

The Colpitts oscillator shown has larger capacitors than a typical gate oscillator which gives better stability against parasitic capacity changes. It also has the bonus that one side of the crystal can be earthed.

Jim

[rossmoffett]

Those app notes are fantastic, thanks!  Quartz microbalances are in fact just another quartz crystal oscillator.  There's nothing special about it, other than its mass changing because metal is being deposited on one side so I think your comments are spot on.

Another major pain to my Crystal Microbalance stability is the fact that it's getting pummeled by vaporized metal in a vacuum, heating it up significantly.  Often these devices will have a liquid cooled crystal with a temperature sensor for that reason, but that's a commercial requirement for semiconductor manufacture and I'm only doing this for instrumentation application  in a lab.

I think the best way to go about this is just to build circuit components separately so that I can test different crystal drivers and observe their effects.  There are all kinds of other problems unrelated to the electronics that will have huge consequences on the accuracy and precision of my QCM too, I might just have to cut my losses on the electronic side when I start running into time crunches on my vacuum system.

[larryp7639]

I wonder how well this would work. GPS disciplined standards have good long-term stability, but the short-term stability is usually only provided by something like a standard crystal oscillator (maybe TXCO).

Alson

I was being pessimistic! I quoted the Trimble figures for the TCXO version (10^-10 in one second), the OCXO version on the surplus market is much better (2 x 10^-12 in one second).

See here http://www.leapsecond.com/tbolt-faq.htm
and here http://www.leapsecond.com/pages/gpsdo/

The problem with OCXOs is long term drift, without frequent recalibration the drift can be much more than the quoted stability; even worse, unless the unit is continuously powered, other effects may dominate.
see http://www.vectron.com/products/ocxo/ocxos.htm fig6

Jim

Thanks you for the post.

__________________
Watch Eclipse Online For Free

[NiHaoMike]

Can you use a GPS receiver to provide a reference?