Well, I can't help myself. I decided to give a try to using a VCOCXO as the frequency standard.
When I left off, I said that I was probably just going to subtract away the error in firmware, but if nothing else my own curiosity got the better of me. My TCXO solution is adequate for the task, but if it's worth doing, it's worth overdoing. :)
I actually went down the road of seeing if I could use a 20 MHz reference clock with a GPS receiver to calibrate a clock module, but I ran into a problem.
To use the 20 MHz clock as a reference, you need to be able to use the Input Capture system of the ATMega328. The problem there is that there's only one input capture pin, but in order to do this, you need to capture both the GPS PPS output and the clock's output. You could OR the two together, but that means that during the PPS pulse, you lose the ability to lock at the clock output. It's just too messy.
So instead, I'm going to set up a testing station with a 2 line LCD and a three pin header that puts out a 1.8 volt supply and takes a signal straight in to the capture pin of the 328. It will be clocked with a VCOCXO with a 20 turn trimpot feeding the control voltage. I'll load firmware in to show the drift of the 1 PPS signal sampled for 10 seconds (a granularity of 5 ppb), and use the trimpot to zero the drift out (after letting it warm up for several hours).
The 3 pin header (1.8v, ground and input) can either connect up to a clock board for testing (1.8 volts is supplied to the board under test to simulate a AA battery so that the conditions will be as similar as possible to real usage - the boost converter will turn the 1.8 volts into 3.0 volts, and in principle it doesn't matter that the input voltage is slightly high), or to a GPS calibration fixture. For that, I'm going to put the same boost converter, an AdaFruit Ultimate GPS module, a battery, a U.FL antenna connector, a FIX led and a couple of three pin headers (the second will be the module's serial port, just in case I need to talk to it). To calibrate the calibrator, I'll hook this board up and load the "1 Hz" firmware for trimming it. To calibrate clocks, I'll hook a clock up instead and load the "16.384 kHz" calibrating firmware.
Another question I had in deciding on this was how to hook the trimpot up to the VCOCXO's control pin. Obviously, the voltage on that pin must be exceedingly stable. The "steering" ratio is around 7 ppm per volt. And the ability to make really accurate voltage isn't nearly as easy as making really accurate frequencies. Conner Winfield (the manufacturer of the oscillators I've been using) has an application note that includes a reference voltage circuit that starts with an SPI D/A converter, which feeds into a chopper op-amp configured for unity gain, and then the CV pin of the oscillator. The amplifier's purpose is to protect the D/A converter from excessive loading, but the input impedance of the oscillator is listed as 100k. I wrote them and asked, and they suspected that simply using a trimpot alone would be fine. I've decided to hedge my bets a bit. I'm leaving the footprint for the amp on the board, but connecting the input and output with a normally closed solder jumper. I'll leave the amp unpopulated to start with, but if adding the amp becomes necessary, I won't need to re-order the board.
It's entirely possible that I could, instead, go with the SPI D/A converter and perform the calibration automatically in firmware, storing a correction factor in EEPROM. I could envision a fully automatic system that switches the ICP pin between the board under test and the GPS receiver. But that's too much overkill even for me. The only thing I regret is not including either a switch or a button on the board to swap the firmware from GPS to 16 kHz mode without reloading the firmware. Oh well.
EDIT: Actually, it turns out it's not overkill even for me. It is, however, a separate project.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.