GPS DO, Ver. 2

Most recent update 4-14-2014

GPS-Disciplined Master Oscillator, Version 2:
Dick's build of Bertrand Zauhar's D-FLL Controller

Update, 4-14-2014
It's been 27 months since the last update (immediately below). The EFC voltage dropped to under +2.5V, and the DAC control voltage had again run out of room at the bottom, so I reset the EFC voltage center point. I used MonTrol to force the coarse DAC setting to 511, then adjusted the ten-turn trimmer on the HP oscillator support board by comparing the BertBox's 10MHz output to the ThunderBolt's 10MHz output with no large frequency difference between them. The resulting new EFC voltage turned out to be +3.137. The previous value had been +3.198, so that's a drop of 61mV in 27 months -- very small. Re-enabling the FLL control then resulted in an EFC voltage of +3.135, with the Thunderbolt and the BertBox staying within a few parts in E-10 of each other over 1000 sec count times on an HP 5345 counter.

Update, 9-17-2011
It's been 33 months since the last update (12-5-2008 at the bottom of this long page). The EFC voltage had dropped to +3.198V, and Bert's MonTrol software was showing a coarse DAC value of 295. Because the DAC output is attenuated to get fine control, the DAC output voltage was starting to run out of room at the bottom, so I decided to reset the EFC voltage center point. I used MonTrol to force the coarse DAC setting to 511 -- roughly it's center point -- then adjusted the ten-turn trimmer on the old HP oscillator support board for a reading of +3.198V, giving a scope display comparing the BertBox's 10MHz output to the ThunderBolt's 10MHz output with no large frequency difference between them.

Precision oscillators don't like to be jiggled or rotated or disturbed AT ALL, and the BertBox hadn't been touched in those 33 months. It's output was extremely stable compared to the ThunderBolt -- they moved slightly with respect to one another, with leading edges shifting a few nanoseconds back and forth, but essentially tracking perfectly. So the DAC voltage had gone down 102mV in 33 months. At an EFC sensitivity of 1.62E-6Hz/V, this means a total shift of 1.65E-4Hz or 165uHz. Given a span of about 1000 days, this is about 100uV per day, or an average aging rate of -1.62E-10Hz per day -- very close to my original estimated long-term aging rate of -1.55E-10Hz per day. That's pretty stable. The OFC VC/OCXO is a gem. Now I'll leave it alone for another three years....

Sad to say, the 10X multiplier has become a deviant, putting out strange frequencies when putting out any at all. I'm surprised at the short life -- everything was done to spec, although it probably didn't like the 5V supply -- should have used 3.3V. I miss having that 100MHz output available -- I may have to reinvent this subassembly.

August-September, 2008 -- a new GPSDO

This page is a long narrative that details the rebuild of the GPS-Disciplined Master Oscillator (GPSDO), Version 1, designed by Brooks Shera, also found on this site (please see that page for a fuller description of the unit's various subsystems, which are mostly unchanged in this rebuild). Most construction articles tell you what the designer or builder did right, but they don't tell you about the detours and mistakes made along the way. I learn more from mistakes and so I want to share all the ups and downs, and a web site provides room for such discussion that magazines cannot.

The Shera controller uses a digital phase-locked-loop (D-PLL) to achieve very good control of the output frequency from a voltage-controlled/oven-controlled crystal oscillator -- in my case an HP 10811A 10MHz unit that has been widely used by HP/Agilent as a high-stability time base in high-resolution counter/timers such as my HP 5345A. The 10811A had recently replaced an HP 10544A that I had used in the original unit; I swapped because of the 10811A's better crystal type and its tighter continuous-function temperature control.

I was motivated to retrofit the controller after my friend Mitch Van Ochten sent me an article by Bertrand Zauhar describing his controller system that employs a digital frequency-locked-loop (D-FLL). I went to Bert's site and looked at his description of the board and circuitry. I liked what I saw -- simple and straightforward.

My implementation of Brooks Shera's controller worked well, but had caused me an ongoing irritation that I discovered to be a problem only after using the unit for a while -- any connection I made (or unmade) to the unit caused a loss of phase lock, which it took quite a while to recover from. At first I didn't mind but, like a lump in the mattress, it gradually began to annoy. I had been careful to eliminate ground loops and provide on-board power-supply regulation for each subsystem, and I had also used a section of a fast 74ACT14 hex Schmitt trigger driving an emitter-follower (that was already on the HP oscillator support board that I used) to provide a buffered output for the front-panel 10MHz output, which is the most used. Clearly, I was missing something, but couldn't see what. So I thought I'd just see how well Bert's board would work. The investment to make the conversion was small, and it shouldn't take a lot of time either.

Retrofit
The Shera controller had required a -5V supply for the PCM61P DAC used to provide the control voltage for the 10811A* voltage-controlled/oven-controlled crystal oscillator (VC/OCXO) module. Along the way I discovered that the 10811A only needed a small range of voltage change to its electronic frequency control (EFC) pin over fairly long periods of time. This range could easily be supplied on Bert's board by the specified rail-to-rail LMC6482A dual op-amp chip, running off the single +5V board supply. This pair of op-amps form the 1.6Hz low-pass filters and output for the PWM DAC of the PIC chip, and drive the oscillator's EFC line.

* 11-28-2008 -- I should note that the two 10811 VC/OCXOs I have are not really 10811A units, and that has had major consequences, as you will see if you read on. One is a 10811-60155, and the other is an EG&G Cinox H176B, p/n 6010504-001, rev A.

After receiving Bert's PC board (I call it the BertBoard) along with the pre-programmed 18F2220 PIC controller, and after getting the parts I didn't already have, I opened the GPS oscillator case, removed the rear panel and added a half-wave rectified +10V supply in parallel with the existing -10V supply. This rewiring let me drive all of the +5V circuits in the box from the higher-current 8VAC winding of the toroid power transformer that provides the +/-10V supplies, and which reduced the power draw out of the lower-current winding for the +20V supply that powers the 10811A's heater and oscillator.

I mounted the BertBoard in place of the Shera board, connected the existing Oncore VP GPS Receiver's 1pps output to the BertBoard's 1pps input pad, and connected a 10MHz output from the 74ACT14 hex Schmitt trigger to the 10MHz input. I used two separate LEDs (already in the unit) in parallel but with opposite polarities, one red and one green, in place of the bi-color LED spec'd by Bert which indicates controller locked and alarm states, and connected one of the other existing front-panel LEDs to the output for the second LED on Bert's board that indicates that the 10MHz output is on; for me, it simply serves as an indicator that the CPU is working. I kept the X10 multiplier and LF divider subsystems from the original project -- very useful adjuncts. I was ready to see if anything would go up in smoke.

Modified front panel

Initial tuning of the HP 10811 VC/OCXO
Noting that the center-value output for the PWM DAC on the BertBoard would be +2.5VDC, with a maximum range of 0 to +5V, I removed the 500 ohm extra-fine-tuning pot I had added in series with the 10k fine-tuning pot already on the HP oscillator support board, and reconnected the end of the 10k pot to circuit ground, as it was originally used by HP.

Leaving the DAC output from the BertBoard disconnected, I let the unit warm-up for several hours, then set the 10k fine-tuning pot's wiper for an EFC line voltage as close to +2.5V as I could get, and then adjusted the 10811's frequency control trimmer to get as close to a 10MHz output as I could, waiting for the 5345 counter to average for 10 seconds between tweaks. It only had to be close, and I got within a few parts in E-9, so it all looked good (when the FLL controller's DAC output gets too far to one end or the other of its range, this is the basic way to adjust for the oscillator's aging drift). The oscillator's output should be within 1E-6 (10Hz) or better to ensure that the controller won't try to lock on an incorrect higher or lower frequency in the sampling process. Zero-beating against WWV 10MHz will accomplish this easily. Past experience with Version 1 had shown me that it seems to take leaving the system undisturbed for a day or so for everything to converge on stable operation. I suspect that the 10811A just doesn't like being upset mechanically or thermally, so I knew any real tests would take patience.

There hadn't been any smoke when I had powered up, and all the circuits seemed to be running OK. I left the DAC output to the EFC disconnected, and waited for things to settle out, while watching the LEDs to see if the controller board got anything like a lock..... Nope.

What I didn't realize is that the PIC controller needed to be set up with some initial parameters by me. I had ordered a couple of nifty little TTL Serial-to-USB boards made by DLP, the DLP-TXRX-G, from Mouser, so I space-wired one up to the serial I/O on Bert's board and connected it to one of the USB ports on my laptop PC:

Space-wired Serial-to-USB board

The DLP board gets its +5VDC power from the USB bus, so no power connections are needed from the internal systems of the oscillator box. Using Bert's nice little control program, GPS Standard MonTrol, at first I couldn't find a working comm port via USB. I had to use the WinXP System Device Manager to find which USB port was acting like a serial port and find its comm port number to plug into the MonTrol sw. You PC folks will know all about that, but I'm a Mac guy, and usually that kind of stuff is all automatic with the Mac. I had downloaded the drivers for the FTDI USB interface chip used on the serial>USB adapter, but it turned out that my copy of WinXP SP3 already had them installed. DLP supplies a little app called USBview that shows port assignments, and that could be a big help to some users. The DLP board worked flawlessly, so I decided to mount them both in the box -- one for the BertBoard's monitor and control, and one for the Oncore VP GPS receiver's monitor and control.

Mounting the DLP Serial>USB boards
These nice little boards have pin sockets mounted on one end for the serial connections and have a mini-USB jack on the other end, with an FTDI serial>USB converter chip in the middle. What they don't have is any mounting points. I pondered this for a while then measured one board's width and height at the USB end. It fit nicely in a DB-9 connector shell, and I already had DB-9 connectors on the front panel. DLP in DB9 shell

I removed the connectors, gutted the plastic interior and pins, and then stood them on end on waxed paper with the boards inside, and used hot-melt glue to hold the DLP boards in place. Worked like a charm.

---------------->

The DLP board's pin sockets for the serial connections take 22 ga. solid wire nicely, so that's what I used for the connections to the BertBoard for Tx, Rx, and Gnd.

GPS subsystem
The DLP board for the connections to the Motorola Oncore VP GPS needed to have a serial connection for the 1pps GPS signal, so that the SynTac GPS software that I got from Synergy Systems would work. I had been using the DCD line with RS-232 and fortunately the DCD connection to the FTDI chip on the DLP board (pin 10) was left unconnected to any circuit or ground. I was able to solder to that pin and use it for the 1pps TTL signal from the Oncore VP.

I used SynTac to make sure the GPS was working. By default, the Oncore VP puts out a low-accuracy 1pps signal whether there's a working connection with the satellites or not, so the Raw 1pps LED flashing didn't tell me anything. I found that the WinOncore12 sw (free download from the Synergy Systems site) is a bit easier to use than SynTac is for making setting changes to the Oncore VP. I set the unit to output 1pps only if at least one satellite was linked-up by the Oncore. This means that if the active antenna dies or there's no satellite reception, the Raw 1pps LED will go out, and eventually, the BertBoard will go into Holdover. I also set the Oncore to "timing" mode and "fixed location" for the best overall accuracy of the GPS system.

Setting the PIC controller parameters
The FLL controller can be set-up and monitored using a terminal program like HyperTerminal, but using Bert's MonTrol sw is much easier for me. I set the correct Negative VCXO Tuning Slope for the DAC output, so that an increase of the DAC output causes the required decrease of the 10811's frequency and vice-versa. I enabled the FLL controller, and set some initial parameters based on Bert's description in the BertBoard's manual. To get the fastest convergence I could, I set the Average Sample Size to 1 and used Summing Mode for the control. I left the other things at their default values.

Trouble
I gradually noticed that things weren't working right. Then I realized, after looking everything over, that I had mounted the FLL controller board to the chassis on aluminum standoffs, and the mounting points of the board are all at circuit ground. Perhaps I had ground loops that were making strangenesses among the circuitry in the box. If that was the problem, the fix was easy -- I just used 3 nylon and 1 aluminum standoffs to mount the FLL board, putting the conducting stand-off under the corner with the 7805 regulator. Then I rewired the connections on the HP oscillator support board to use the 74ACT14 hex Schmitt trigger to supply buffered 10MHz signals:
1) To the emitter follower that drives the front panel 10MHz output;
2) To the 74LS90 decade divider that provides a 1MHz signal;
3) To the BertBoard and to the PIC-controlled divider that supplies low-frequency signals, and
4) To the 10X frequency multiplier subassembly.
I also used a section of the 74ACT14 to receive the 1MHz from the 74LS90 and send it to the emitter follower that drives the front-panel 1MHz out. I elected to do all this through the 7414 rather than use the buffer and divider provisions on the BertBoard, in order to reduce power-line and ground-line noise, and to avoid regulator voltage level shifts on the BertBoard due to connecting and disconnecting external gear.

A few other little issues
I discovered that the DAC output needed to have some resistance in series from the output amp to the EFC line for stability. I tried 1kohm, and it worked fine, so I left it in; I may adjust this value to get an appropriate control range for the EFC line -- note that halving the total EFC control range through the divider action of the series output resistance is equivalent to adding one bit of resolution to the DAC, at the expense of reducing the DAC's total control range by two. Given the stability of the 10811, I won't worry about that if I make the change.

Then I discovered that the EFC line, via the front-panel DAC output jack, seemed to need isolation from any connected gear, which included the digital panel meter I had added to the box to monitor the DAC level. I tried 50kohms, and that worked too. That value is quite arbitrary -- the 10Mohm or greater input Z of the DPM and of the external meters I use mean that loading won't affect the EFC line readings significantly. Probably 10kohm would work as well.

Firmware problem
Once things were mostly back together, I ran the unit for 24 hours to see what would happen. The FLL locked OK and all the settings were functioning. The loop seemed to be stable. After the first day, I noticed a steady ramping-up of the DAC output which seemed contrary to expectations -- much faster than the aging rate of the 10811. Mitch Van Ochten noticed the same effect and Mitch entered into conversation with Bert about it. Then I got a notice on Bert's mailing list that the PIC I had gotten from him had a firmware error that caused the ramp effect that Mitch and I had noticed. I downloaded the V. 2 firmware update and burned the new code into the PIC chip.

After putting things back together, the unit was much more stable, with an order of magnitude less average frequency offset -- now down in the parts per E-9 range. Following Bert's recs, I left the board in Voting Mode, but I began to experiment with various settings for the Avg. Sample Size, the Coarse/Fine Threshold, and the Negation Threshold. I immediately noticed that a Negation Threshold of 1 worked best for me, and, after doing some simple calculations, I realized that I might need Fine (14-bit) control instead of forcing the Coarse (10-bit) frequency adjustment, which I had done by setting the Coarse/Fine Threshold to 1. Here's why:

10811 tuning
As I noted above, it's important at the outset to get the controller and the oscillator working together, and the control range over the oscillator is important. I checked the EFC tuning range by disabling the FLL, which makes it possible to enter values into the DAC Value (Coarse) box of the MonTrol sw, and then forcing the DAC Coarse level, which is 10 bits resolution, by setting it first to 0 and then to 1022 using the MonTrol software (for some reason, it wouldn't hold the expected maximum value of 1023). Here are the results, measured with my HP 5345A:

DAC level    EFC level, V       10811 Frequency, MHz
    0          +0.5             10.000,001,08    (+1.080E-7 re 10MHz)
 1022          +4.48             9.999,999,366   (-0.634E-7 re 10MHz)
               -------------------------------
Total range     4                0.000,001,7        (1.7E-7 re 10MHz)
                1                0.000,000,4        (4.0E-8 re 10MHz)
So, approximately: 
one Coarse 10-bit LSB =   4mV    0.000,000,001,7   (1.7E-10 re 10MHz)
one Fine 14-bit LSB   = 245uV    0.000,000,000,1   (1.0E-11 re 10MHz)

The total frequency change of about 1.7Hz over the 4V range was more than I expected by a factor of 4, based on HP specs of 1Hz/10V (1E-7) = 0.1Hz/V (1E-8). Note that the DAC tuning range is less than the expected 0 to +5V because of the combined effects of the current sourced by the oscillator support board's 10k fine tuning pot -- 2.5V behind a few kohms -- and the the 1kohm series resistor at the DAC amp's output.

So, as configured, the minimum Coarse change may hold the 10811 to a few parts per E-10, but the minimum Fine change definitely should, and more.

I set the Coarse/Fine Threshold to 24, meaning that the BertBoard would make 14-bit Fine adjustments until the change calculated during the Averaging Cycle needed to be 24 or more 14-bit steps, at which point Coarse 10-bit changes would be made until the Average Frequency Offset value returns to less than 24 LSB of the ideal Sample Frequency value (0x6800 hex, 26624 decimal*). I set the FLL Sampling Mode to Voting (see Bert's online description or download the manual from his site for an explanation), based on Bert's recommendation that this mode provides better stability for large Avg. Sample Sizes. I set the Avg. Sample Size to 225 (1 hour). My results were Average Frequency Offsets over the 225-sample Cycle in the low E-9 to high E-10 area. This was good, but I had hoped for even better performance.

* The 16-bit counter for the 10MHz samples rolls over during the 16-sec acquisition time, and gives a value of 160,000,000 / 65536 = 2441.40625. The 0.40625 remainder is used to set the DAC value, while the 2441 rollovers are discarded. The 16-bit delta frequency register gets 0.40625 * 65536 = 26624 decimal, 0x6800 hex, for a perfect 10MHz input. Ideally, the maximum resolution of the system for one 16-sec Cycle is one count out of 160,000,000 = 6.25E-9. Very roughly, using an Average Sample Size of 10 would yield 6.25E-10 and 100 would yield 6.25E-11, neglecting any counter bobble and the jitter in the 1pps GPS signal. In practice, it takes 5 to 10 times more samples to get to those levels of statistical results with a "timing" grade GPS; probably even more with a consumer-grade unit.

Is there a limit to improvement by averaging?
(Added 11-22-2008 -- I've added this section because I got an email from a recent visitor to the site who asked me what the averaged frequency offset values have to do with the DAC's operation. I had a Homer Simpson "D'oh" moment, and realized I had left this important topic out of this discussion.)
It's important to recognize that the combined granularity of the DAC/oscillator system limits the tuning resolution of the system -- it sets the lower bound on the possible improvement from averaging the samples. As shown in the table above, this particular HP 10811 and the 14-bit DAC together have a resolution floor of 1.0E-11, and averaging can't get below this. It is possible to divide the EFC output, reducing granularity to drop this lower bound, but that limits the output range, and realistically, if you want a system with any chance of long-term operation without continual tweaking, that's only good for a factor of four or so, and only with a very stable oscillator, given the 0 to +5V range of this configuration for the DAC's output.

All of this means that averaging for more than about 3-4 hours will not improve overall accuracy of the 10MHz output frequency. An hour's worth of sampling will ideally result in a resolution of 2.77E-11, 2.77 times the granularity of the combined DAC and oscillator system, which really is the floor -- we just want to be sure that the averaging takes us all the way to the floor, so we go a bit under the 1.0E-11 floor, which is reached with an Average Sample Size of 600 or more, and that will be the best that can be done. Four hours averaging will yield about 7E-12, a bit more than half the granularity of the DAC/oscillator system, which takes us to the DAC/oscillator floor, and longer sampling won't materially help. Using a separate 16-bit DAC for output instead of the PIC's 14-bit PWM DAC, and then dividing the DAC output by four, together would really help, by increasing the DAC resolution by 4 bits, resulting in 18-bits effective resolution. This would reduce the DAC/oscillator floor to 6.25E-13, and enable longer averaging to improve the accuracy of the 10MHz output into the E-12 area.

Summing Mode
I decided to set the Coarse/Fine Threshold to 16 and try the Summing Mode. I ran it for a Sample Size of 100, and the results were slightly better than with the Voting Mode. I upped the Avg. Sample Size to 225 (1 hour's worth of 16-second samples), and the statistics were much better, in the low E-10 range. I then moved the Sample Size to 450, and after about 6 hours, the Average Frequency Offset values were in the mid E-11 range. After 6535 total samples with these settings, the cumulative frequency offset was 2.77E-11. I'd say that's pretty good, and it may get better. I'm not sure why the Summing Mode gives better results here -- possibly it's because with my parameters, the system never needs a Coarse change and it's pretty stable anyway, making the two Modes somewhat equivalent. But it's still kind of a mystery, to me at least.

Accuracy?
Bert has reminded me that I'm discussing the statistics here and not necessarily the actual stability of the system. Only comparison of the 10MHz output with a much more accurate standard can tell you how good the actual control is. I'm not in close proximity to WWV's transmitter, so at this level of accuracy, their 10MHz carrier is useless for comparison due to atmospheric transmission effects. I don't own a cesium-beam frequency standard or know anyone who does. How do I know whether the system has the accuracy that the MonTrol statistics suggest? Answer -- I don't.

What I can do is connect both the 10MHz output signal and the raw 1pps signal from the GPS to my 5345's inputs and use Ratio B/A mode to let the counter compute the ratio. With a 10MHz B input, the 5345 actually averages 50X longer than the front-panel time setting to get a result. This means that for the 1000 sec setting, the counter is working for about 13.9 hours to get a result. This is long enough to average out most of the variation in the 1pps signal, and the division ratio is completely independent of the 5345's internal reference oscillator (another 10811A -- a real one). The data I've gotten this way tell me that the statistics are good and that the result is close enough (within one or two orders of magnitude, depending on a variety of factors) to the cesium standards in the birds, giving me confidence in the system.

Tradeoffs
There is obviously a trade-off between, on the one hand, the stability from running large Average Sample Sizes, and on the other hand, the ability of the system to track changes in the variances of the 1pps GPS signal and/or the HP10811's 10MHz signal. I tried a Sample Size of 900, and that did not work well for me, although forcing Coarse changes might make it work better, as Bert suggests.

Here's the basic problem with all GPS-controlled oscillators, at least ones that have good VC/OCXO oscillators -- over the short term (say up to a couple of hours or maybe a lot more) the oscillator output is much more stable than the 1pps GPS signal. So how do you get good control over long-term drifts in the oscillator from a jittery 1pps GPS signal? By averaging the 1pps signals, which is what the BertBoard and other controllers do. But that leaves the question open of how long is long enough? I assume that the system is working correctly when:
1) The Sample Frequency reported by MonTrol is hunting in a small value range around the ideal Sample Frequency -- say +/- 5 counts, and
2) The changes are all Fine and swing through +, = , and -, over many Cycles.

The trick is to determine controller settings that accomplish these goals.

Here's a screen shot of the MonTrol sw with settings and results (sorry about the blurry quality):

GPS Standard MonTrol screen capture

This is clearly working well. I rate this project a big success. The system is very tolerant of connecting and disconnecting, and I keep the unused outputs (except for the LF divider output) terminated in 50 ohms. Time will tell if any annoyances are going to pop up, but so far, so very good. Kudos to Bert for a terrific design and sound engineering.

Update, 9-16-2008 -- We got trouble
For some reason completely unknown to me, the DAC value took a big dive. As it sank lower and lower, I forced the unit to Coarse changes. Over half a day, the DAC value leveled out and started to rise again, and has, for now, leveled out at 7768 decimal. Given the intrinsic stability of the 10811, I can't imagine why this happened, and given the accuracy of the GPS system, there's no answer there either. Nothing changed environmentally or in the basic operation of power supplies or loadings. I really don't know what this was about, unless the varactor in the 10811 that tunes the oscillator from the EFC voltage was acting up; or perhaps the 723 regulator on the oscillator support board that supplies the +13V to the oscillator system had burped. The oscillator oven heater runs from the LM317-regulated +20V supply, and that hasn't changed at all; plus the 10811 is relatively insensitive to heater supply changes anyway.

Over a bit more than a day, the DAC output level plot has shown some ramps lasting a couple of hours, then longer plateau periods. I've set the Coarse/Fine Threshold to 8 for now, which appears to handle the ramps well, while maintaining stability during plateau periods, and I've kept to an Avg. Sample Size of 450 (2 hours). The Average Frequency Offsets are in the E-11 range, and that is more than acceptable.

Big Update, 9-22 thru 9-26-2008
Looking over the data I'd collected, I kept seeing consistent, fairly large standard deviations reported by MonTrol -- 1.3 to 1.4E-8 -- and I wondered if it might not be better to make the basic sample acquisition period of 16 seconds longer (which is controlled by the jittery raw 1pps signal from the GPS) and then adjust the Average Sample Size, and maybe get a bit more responsive system overall.

Bert has made it easy for hacks like me to try things out by providing the source code for the controller sw. After looking at Bert's .asm code, and emailing both Mitch and Bert, and after trying a couple of different sample acquisition periods (40 seconds and 96 seconds), I eventually modded the code for a 120-second sample acquisition period. The 120-second period was attractive to me due to having a value near 0.5 for good "freeboard," and the 2-minute time is mentally easier to deal with than any of the others I tried. The mod only needed four small changes to values in the code and no new instructions. I compiled the .asm file with MPLAB (free from Microchip) and then shut the unit down, pulled the 18F2220 and burned the modded code. It burned fine on my DIY-K149 PIC programmer from Carl's Electronics, and I put it back in the unit. It quickly settled in and began working solidly.

Voting Mode
After a few hours with Summing Mode (which had worked well with 16-sec sample periods), and using a short Average Sample Size of 5, and seeing no problems, I set the Avg. Sample Size to 30, resulting in a total time of 60 minutes for a Cycle -- shorter than the 2 hours I had been using. MonTrol tracked the controller data OK, even though it was still counting 16-second sample periods and then waiting for the balance of the 120 seconds, but of course its statistics calculations were completely incorrect.

After looking at the log file, I realized that the DAC variations were larger than I had expected. I tried setting the FLL Sampling Mode to Voting and watched a bit longer. Things immediately improved. I let the system run for several hours, then exported the log file to a spreadsheet and did my own statistics. During my earlier trial of a 96-second sample acquisition period, I had been happy to see a standard deviation 1/6th the values I had been getting, thanks to the 6X-longer sample acquisition period. The Average Frequency Offset was in the low E-11 range for a total Sample Size of only 217; it had previously taken 450 samples at best, and sometimes over 1000, to get near that area.

Bert is amazingly helpful, and he very kindly amended MonTrol to use the 120-sec sample acquisition period, and sent me the program to try. Note that with 120-sec samples, the maximum resolution for one sample period is 1 count out of 1,200,000,000 = 8.33E-10, so Min and Max values in the Cycle data shown by MonTrol will be integer multiples of this value. Here's a screen shot of the current output:

GPS Std MonTrol screen capture of data gathered using 120-sec. samples

I suspect this mod is only practical for a system using a very stable oscillator like the HP 10811A, but it's possible it might help with consumer-grade GPS receivers not designed for "timing" use. The PIC counter that processes the sample acquisition time in the .asm code (CCP1_INT_CTR) can use counts up to 255 (255 seconds). For those who might want to do what I've done, I made a spreadsheet to compute good candidates for longer sample acquisition times. You can read it in a new web page or download it as a PDF.

But is the 120-second sample acquisition time better?
I'm not sure there's a real benefit here. I like the reduced variances in the sample parameters that the longer sample acquisition period gives. But it looks like "averaging is averaging." If the longer acquisition period helps with more jittery GPS receivers, then that would be a real benefit, but it's not a possibility I can test since I don't have such a GPS receiver. My sense is that it's probably good to stick with the original controller software as described by Bert and play with the parameters to get to where you are satisfied with the results. But for the time being, I'm going to use the 120-second version.

BIG Roll-Back, 10-4-2008
Over a few days, things got very iffy, with the controller ramping the DAC output down steadily and never seeming to catch up. I'd been here before, but this time it kept going, never levelling out. I wondered about power supply issues -- I hadn't been happy with the level of ripple on those 1/2-wave rectified supplies for a while. So, I took everything apart and re-wired the two supplies for full-wave rectification. I separated the two windings of the toroid transformer, eliminated the unused negative rectifier, and paralleled the filter caps from the +10V and -10V supplies to get a single +10V supply with double the filtering and much better performance. But this reduced the AC voltage supplying the +20V regulator from 23VAC to 15VAC, which caused a drop in the input to the +20V supply from about 23VDC (1/2-wave) to about 18.5VDC (full-wave). The LM317 has a minimum input-to-output drop of about 1.75V, so I allowed for a minimum of 2V and adjusted the 317 for an output of 16.5V. This keeps the heater in the 10811 happy enough, and assures that the +13V regulator on the oscillator support board is happy, too. I also changed the DPM from a 3.5-digit unit to a 4.5-digit model so I could see finer changes in the DAC output:

4.5-digit DPM

Then I started everything back up. After some settling in, the DAC output continued to sink -- it looked like an inverted repeat of the firmware error that caused Bert to issue the V.2 update. Now I was really concerned -- what was going on? GPS receiver dying? Controller failing? Programming error by my PIC programmer? Too many possibilities and too few answers.

This is when the long, 120-second sample time of the modded controller firmware became a real irritation, just as Bert had predicted it might in an email. I shut down, pulled the PIC and reprogrammed it with Bert's V.2 (16-second) firmware, and reinstalled the original MonTrol sw on my PC. I let things warm up a while, then disabled the controller thru MonTrol, and forced the DAC output to full-on and full-off while reading the 10MHz output frequency, just to be sure everything was working. Then I forced the DAC output to 511 and saw that the 10MHz was low. So, I forced the DAC down, in steps, until the 5345 showed that the 10MHz output was on the money to better than 1 part in E-9. Then I enabled the controller and sat back to watch. All was good, and all stayed good. I set the Avg. Sample Size to 100 and went to bed. The next day, everything was still right as rain.

So, the GPS was/is OK, the PIC hadn't failed, and the DAC amps were/are working. That leaves a PIC programming malfunction as the likeliest possibility for the problems. So, take heart all of you who have the official versions of the BertBoard and MonTrol -- they work great. I'm done fooling around for now; but it has been a LOT of fun!

More Ifs, Ands, & Buts -- 10-27-2008
Well, my "right as rain" optimism was premature. After several days of stable operation, the output began to vary and I have continued to have significant variations in the stability of the system as reflected in the statistics from MonTrol.

I decided to install my spare HP VC/OCXO to reduce the field of potential error sources. My spare was, I thought, a 10544A made by EG&G Cinox. I installed it and discovered the output frequency was way high, and it didn't come down. I pulled it out and, thinking there was a circuit problem, opened it up. That's when I realized that it is a 10811, although with a different internal construction from the HP -- it has a much smaller, isolated internal oven case for the oscillator and crystal, which has much smaller thermal mass than the HP original. Nevertheless, I could find no bad or problematic components. I decided to bench test it, and discovered that it needs a bit over +19V for the oven supply in order for the oven to turn on. That presented a problem due to my +16.5V oven supply, and the recently-rebuilt supply wasn't going to give me the +20V I would need for assured operation with low ripple and noise.

So, I rummaged around under the bench and found the Condor 80W switching supply I had bought for this project several years ago and then not used, preferring the (presumed) overall quieter operation of the toroid transformer-based linear supply. The Condor was too big to fit in the back part of the case, where the toroid supply was, but there was plenty of room underneath the shelf that holds the controller parts, so that's where I put it. The Condor puts out +24, +12, +5, and -12, with lots of current, so no matter what might come next, I would be ready.

Once that was all done (the Condor switcher works very well and actually is nice and quiet), the Cinox oscillator started right up and quickly converged on 10MHz to better than 1ppm. I gave it a few hours, then started the controller. The Cinox oscillator has an EFC control range much closer to the HP spec than my 10811 does. I measured the results of tuning voltage changes and here's how it looks:

DAC level    EFC level, V       Cinox OCXO Frequency, MHz
    0          +0.5            10.000,001,030     (+3.0E-8 re 10MHz)
 1022          +4.48            9.999,999,979     (-2.1E-8 re 10MHz)
               -------------------------------
Total range     4               0.000,000,51       (5.1E-8 re 10MHz)
                1               0.000,000,13       (1.3E-8 re 10MHz)
So, approximately: 
one Coarse 10-bit LSB =   4mV   0.000,000,000,5   (5.0E-11 re 10MHz)
one Fine 14-bit LSB   = 245uV   0.000,000,000,031 (3.1E-12 re 10MHz)

Practically, what this means is that I might be able to force only Coarse DAC steps and still keep very good tracking and stability. And if the Cinox really settles down, I can enable Fine control and get offsets into the E-12 range.

Trouble was, the Cinox was not settling down. Again, doubts about components and controller arose. I had put a 10kohm thermistor against the internal oven case, inside the foam thermal insulation, so I could look at oven temperature. The oven reached correct operating temperature (within its small hysteresis bounds) within a few hours, but the oscillator continued to show changes, with the controller drifting in and out of lock. Each day, I checked the DAC output and when it was close to a volt high or low I retuned the oscillator. It wobbled around, then started ramping down steadily, meaning the output was going down in frequency and the EFC voltage was going down to raise the frequency back up. Then it bottomed out and started to rise, and all the while, the controller kept adjusting and stayed in lock; but the system was not stable.

Now, after days, the DAC output is falling again, at first slowly, and now more rapidly -- but at least the rate is slow enough so the controller can maintain longish periods of relative stability, with output offsets in the E-10 area. It's hard to see where this is heading, but it seems that it may take a lot longer for the VC/OCXOs to reach real stability than I would have thought possible. Does this system have some long-period control oscillation, and if so, why? Stay tuned . . .

Another biggish update, 11-19-2008 --
Good news, and bad news, and good VC/OCXO performance at last
After the erratic performance described above, I needed to know if this was a controller issue, a GPS issue, or an OCXO issue. I ordered an OFC OSC092/Isotemp 134-10 OCXO through eBay from fluke.l in China. I also ordered a second known-good Controller PIC from Bert. The OFC 092 OCXO arrived and I built an adapter board that plugs into the HP oscillator support board to hold it and a little 78L05-based +8.0V supply that it needs. The main supply is +12V (spec is +13V, +/- 2V) for the heater and oscillator; apparently the 8V supply is for the oscillator's control circuitry, giving an EFC range of 0 to +8VDC. The oscillator is in a completely sealed case, with no externally-accessible mechanical adjustment for oscillator tuning.

I bench-tested the oscillator before installing it and discovered that it is stable, that it's case runs barely warm, that it reaches stable operation quickly, and that it's 10-point-whole-bunch-of-zeros-MHz operating point is at about +3.3V on the EFC pin. This was good news -- the BertBoard DAC output would work OK to drive this unit. I also discovered that the frequency-vs-tuning voltage slope is pretty non-linear, with a steep rise from 0V, then arching over to a slower rise at +5V and beyond. Happily, the area around the 3.3V nominal center point was pretty straight, so in a small range the slope is constant. Not so good was its EFC sensitivity of 1.62E-6Hz/V at 10MHz out. Would the DAC granularity allow precise tuning?

I installed it, and ran the BertBoard for a day. The good news is that I discovered that the system was stable, with only small DAC level changes, and that an hour's worth of sample time (225 samples) produced good performance, in the low E-10 to middle E-11 range as reported by the MonTrol statistics. Further operation over a few days confirmed that the PIC controller and GPS were OK and had always been OK, and so far, I haven't needed to use the second BertBoard PIC. The bad news was that this meant both of my HP 10811s are flaky.

Thanks to a post on the time-nuts mailing list, I got a PDF copy of an HP 10811A manual that shows the various part numbers and I discovered that my HP version, bought as new-old-stock on eBay, was one that had never been tested to HP specs -- it could have any kind of problem. The Cinox version was bought used from eBay as well, and may have been surplused due to poor performance. There is a real possibility that these two 10811s might only need to be re-calibrated for thermal operating point -- both have good ovens and low-noise outputs of about the right amplitudes. Doing the thermal cal is quite a project, but may be a good thing to try -- see Z3801A Turning Point.

As mentioned previously, it's easy to forget that the combined granularity of the DAC/oscillator system limits the tuning resolution of the system. The OFC/Isotemp oscillator is not so good a choice in this respect, because it has about a four-times larger frequency change for a Fine step in the DAC output than does the HP 10811A, and averaging can't get past this. The DAC and OFC oscillator combined resolution for a DAC Fine step = 4.87E-11 re 10MHz, which means that averaging for more than an hour with this combination will not improve overall accuracy of the 10MHz output frequency. Regardless of the sample duration, be it 16 seconds as in Bert's original system, or 120 seconds as in my modded system, an hour's worth of sampling will result in a resolution of 2.77E-11, about half the granularity of the combined DAC and OFC/Isotemp oscillator system -- 4.87E-11 is the floor and sampling longer than an hour won't help.

If I can get one of the 10811s working, it will be a better choice. Now, with the OFC OCXO working well, I've gone back to the 120-second version of the firmware and MonTrol software. Using an Average Sample Size of 30 gives me an hour of sampling, and the current statistical results are in the low E-10 to mid E-11 area, which is the best, long-term, this oscillator will allow without another major modification to install a separate DAC, or dividing down the PWM DAC's output.

Also, today I received a used Trimble Thunderbolt GPSDO from China, and it's going to be interesting to see what it can do. It certainly is more space-efficient than my BertBox, since the OCXO, GPS receiver, and controller are all on a single small circuit board, totally enclosed in a small aluminum box. It offers 1 pps and 10MHz outputs, and has an RS-232 port for the monitoring and control software from Trimble. These units have the reputation of having very high performance, with stabilities down in the E-13 area. We'll see.

Final update? 12-5-2008
I reviewed all of the options for increasing the EFC resolution of the DAC and OCXO system. Looking fairly dispassionately at the OFC/Isotemp OCXO, the unit is about 20 years old, perhaps more. The specs for the very similar Isotemp 134-10 indicate that the "zero" point for the EFC to give an accurate 10MHz output was set at the factory to +4.0V. That point is now approximately +3.3V. So, that's a change of -0.7V in two+ decades of use, for an aging frequency change of about -1.13E-6Hz/20 years = 1.55E-10/day -- this is almost 8X better than the Isotemp 134-10 specs for a 10-year rate, and that rate of change could now be slowed down considerably and flattening out. What this means to me is that, for all practical purposes, this unit does not need a large range of EFC adjustment in order to work well in a GPSDO.

So, the easiest way to get higher resolution with reasonable stability, as I mentioned earlier, is to divide the BertBox DAC output. And the easiest way for me to do that was to reconnect the 10kohm "fine" pot on the old HP oscillator support board, set its output to +3.3V, add more series resistance to the DAC output line, and connect that line to the EFC input at the fine pot's wiper. At the higher voltage setting of the fine pot, the load would be around 4-5kohms, so I would need around 50kohms in series to get a 10X division ratio.

How much division would I need? The resolution was, as noted above, 4.87E-11 with a 5V DAC output range to the OCXO's EFC pin. I figured that I could safely divide that by around 10 and still have 0.5V of DAC range and get a Fine step resolution of about 5E-12, which should make stable operation in the low E-11 to high E-12 area possible. This would also make longer averaging times possible; perhaps up to 5 hours would be practical.

I replaced the 1kohm resistor in series with the DAC output with a 30.1kohm fixed resistor and a 20kohm, 10-turn pot, in rheostat connection. I set the pot to full resistance and hooked everything up. I also went back to Bert's original 16-second sample time, using the new PIC I had ordered from him, while keeping the 120-sec unit in reserve. I forced the DAC Coarse output to 511, and re-adjusted the "fine" pot on the HP oscillator support board to give the nominal +3.3V on the EFC line. Then I forced the DAC to 0 and to 1022, and noted the range, which turned out to be about +/- 0.45V, which should be enough for 10 years, at least. The division ratio was 10.94 -- plenty good enough, so I just left it there.

The result was a measured Coarse step value of 439uV, with a resolution of 7.13E-11, and a Fine step value of 27.4uV, giving a resolution of 4.48E-12. I don't know if this system will have low enough noise and high enough stability to make these settings work, but I feel like I've done what I can to get a good working GPSDO.

So, I've set the system to Summing, Avg. Sample Size to 450 (7200sec = 2 hours), and set the Coarse/Fine Threshold to 12.

In the meantime, I got the Thunderbolt module into a box with a power supply, and it's been running without a visible hiccup for long enough to see that it is very good. Right now, the BertBox's output frequency is slightly lower than the Tbolt -- a stopwatch timing the creep on the scope display, triggered by the Tbolt, indicates the difference at about 1.7mHz, or 1.7E-10, and that is roughly what the MonTrol statistics indicate as well. At that level, if the Tbolt is as good as the Time Nuts who own them indicate and the MonTrol stats are anywhere close, then most of that error is indeed from the BertBox. A Coarse step should resolve most of that, and Fine steps should hold it until the next system burp, whenever and however that occurs.

back to top

to Home -- article index