GPS Disciplined xCXO

A DIY GPS disciplined 10 MHz reference clock

Similar projects worth following
In working on my Crazy Clock project ( ), one of the things I needed to do was make a very, very accurate frequency counter. That problem effectively reduces to the problem of making a very, very accurate square wave generator (the rest is relatively easy).

To make a long story short, it occurred to me the other day that having a separate generator of a very, very accurate and long-term disciplined 10 MHz square wave would be a handy thing in and of itself, so I decided to design one as a separate standalone project.

There are commercial GPSDOs available, and they're easily half an order of magnitude more stable than mine, but they're also much, much more expensive. My design is close to an ADEV of 1E-10 for the TCXO version, or 1E-11 for the OCXO version (which costs $100 more).

My first cuts at the crazy clock calibrator were using TCXOs with two different firmware loads. One load would test the clocks, the other load would accept a GPS PPS signal and would display the oscillator's drift relative to GPS. I could then subtract that drift out of the measurements of the clocks.

I tried to think of ways to allow the controller to do both at once. After all, a PPS signal (in principle) shouldn't distract the controller too terribly much. The problem is that the ATMega328P controller I like to use has only one input capture pin. Recall that the input capture pin allows you to use a non-prescaled timer (running at the system clock speed) to time things at maximum resolution, while the clock's value will be "frozen" by a rising edge on the ICP pin.

Since you can't watch two events at once with a single ATMega, it briefly occurred to me in a humorous way to simply use two. But in a "ha ha only serious" moment, it immediately occurred to me to simply separate the two problems - resulting in a frequency counter with a separate clock source, and a hyper-accurate disciplined clock generator.

The basic design of the project centers around either a VCTCXO - a Voltage Controlled Temperature Compensated Crystal Oscillator or a VCOCXO - a Voltage Controlled Oven Controlled Crystal Oscillator. At first, that nomenclature seems contradictory. Which is controlling the oscillator? A voltage or the temperature compensation? In fact, what a VCTCXO is is a normal TCXO (a crystal oscillator which is "steered" by a temperature compensation circuit) with a voltage input that allows the output frequency to be trimmed over a relatively narrow range. The specification of the oscillator says that a voltage ranging from 0.3 to 3.0 volts will push or pull the TCXO ±10 ppm or the OCXO ±400 ppb. A VCOCXO is like a VCTCXO, except that the crystal is housed in an oven that tightly controls the temperature of the crystal. OCXOs are much more stable than TCXOs, but the oven requires a great deal of current.

The microcontroller is going to need to be able to manage the control voltage to trim the frequency from the GPS feedback. I briefly considered using the traditional Arduino method of PWM duty cycle manipulation to effect a D/A converter, but quickly rejected that. The TCXO has a basic short-term stability of 1 ppb. If we want to try and keep it in trim, we need to be able to have at least that level of granularity of control, preferably much less. We're already using the 16 bit timer for measuring the frequency. If you do the math, a one volt change in the reference is 7 ppm (or so), meaning that dividing our 2.7 volt tuning range into 256 levels results in a granularity of ~70 ppb per step. That's not nearly good enough. Using a 16 bit D/A converter, by contrast, gives us a granularity of just under 0.4 ppb. We can do better than that, however, because the outer 0.3v of the DAC range is "dead space" to the oscillator. Also, the long term accuracy specification of the oscillator lists < 5 ppm of total, lifetime drift. That means we can throw away half of the DAC tuning range (the outer 25% on the top and bottom) and still be able to steer the oscillator more than its lifetime expected error range. That doubles our granularity to around 0.2 ppb.

Connor Winfield has an application note that actually includes a schematic for a D/A trimmed oscillator. We started with that design, but a lot of the things they recommend have gone by the wayside. Their design included a buffer OP amp. Along the way, we turned that into a compression amp, but the design now is simply a voltage divider consisting of just 3 resistors. The aim of the voltage divider is to reduce the range of the DAC to the useful portion of the oscillator's control voltage input. For the TCXO, we reduce the swing to 50% of the 3.3v DAC output range, and for the OCXO, we reduce the swing by around 25%....

Read more »

GPS Disciplined VCxCXO v3_2_1.pdf

Schematic of the OCXO variant

Adobe Portable Document Format - 90.67 kB - 02/19/2017 at 03:43

Preview Download

GPS Disciplined VCxCXO v3_2_1.sch

EAGLE schematic for the OCXO variant

sch - 395.13 kB - 02/19/2017 at 03:49

See BOM Download

GPS Disciplined VCxCXO v3_2_1.brd

EAGLE board file for the OCXO variant

brd - 160.15 kB - 02/19/2017 at 03:49


GPS Disciplined VCxCXO v3_3.pdf

Schematic of the TCXO variant

Adobe Portable Document Format - 87.75 kB - 02/19/2017 at 03:44

Preview Download

GPS Disciplined VCxCXO v3_3.sch

EAGLE schematic for the TCXO variant

sch - 382.16 kB - 02/19/2017 at 03:49

See BOM Download

GPS Disciplined VCxCXO v3_3.brd

EAGLE board file for the TCXO variant

brd - 156.69 kB - 02/19/2017 at 03:49


GPSDO front bezel v2_2.brd

EAGLE board file for the front panel

brd - 14.14 kB - 07/15/2016 at 02:58


GPSDO back bezel v2_3.brd

EAGLE board file for the back panel

brd - 12.78 kB - 09/03/2016 at 19:53


GPS Disciplined FE5680 v2_0_1.pdf

Schematic of the FE-5680A variant

Adobe Portable Document Format - 112.78 kB - 02/19/2017 at 03:43

Preview Download

GPS Disciplined FE5680 v2_0_1.sch

EAGLE schematic for the FE-5680A variant

sch - 520.12 kB - 02/19/2017 at 03:49

See BOM Download

View all 14 files

  • Auxiliary clock display board

    Nick Sayer02/18/2017 at 22:27 0 comments

    I took the basic design from my GPS clock board and replaced the GPS module and its infrastructure with a mini-DIN-6 jack to pull the GPS NMEA sentences and PPS from the GPSDO output. When I tried this with the xCXO variant, there was some impact on the output stability, but I had a brainstorm today... The FE-5660A's output stability shouldn't be impacted at all by the 5 volt supply on the discipline board. The new prototype of the FE discipline board has the new mini-DIN 6 diagnostic jack, of course, so it can power and provide data for the clock board easily enough.

    The result is quite nice. It's the same as the existing GPS clock, but as an accessory for the FE GPSDO instead of a standalone device.

    I think it's a keeper. :)

  • Updating the FE-5680A variant

    Nick Sayer02/18/2017 at 20:34 0 comments

    I'd been putting off updating the FE-5680A discipline board because I ran into a series of catch-22 constraints in the design.

    The ATTiny841 is out of flash space, so there's no room to add the code to handle sawtooth compensation messages from the SkyTraq GPS module. For the xCXO variant, I upgraded to the ATMega328PB, but the 328PB lacks one feature the 841 has - the ability to change clock sources programmatically. The problem was that startup of the FE board was troublesome when the controller was clocked directly from the oscillator. I also saw some evidence of stability issues after startup (some watchdog resets) that I assumed were caused by the stability of the oscillator not being good enough to clock the controller. So waiting until the !OSC_RDY pin went low before switching from the internal RC clock to the external clock was good enough.

    I finally broke this logjam by adding an RC+Schmidt trigger !RESET bootstrap circuit to the design with an ATMega328PB. The controller datasheet says that if you hold !RESET low until the clock stabilizes that that is ok. The time constant for the RC results in about 100 ms of startup delay, which for the prototype seems to result in stable, repeatable startup without difficulty. The controller's stability post-startup in the past did seem to have been properly managed with the watchdog, and I haven't seen any evidence of the watchdog firing with the prototype of the new version anyway. This variant of the board also has the SkyTraq module that adds sawtooth correction and the antenna power solder jumper to select between 3.3v and 5v antenna power (with 5v default). There's also enough flash space left to add a frequently requested feature - the ability to write the current trim value to the oscillator's EEPROM as a startup default. Variants in production will include a push button to allow you to write the current offset on demand (doing it this way rather than automatically will preserve the EEPROM's lifespan and allow the user to perform the update when conditions are optimal).

    Look for this version after the current inventory is used up. That said, there's no real reason to wait - the old version does just as good a job as the new one (from an ADEV perspective).

  • 3 cornered hat

    Nick Sayer02/18/2017 at 18:04 0 comments

    When your measurement reference is not at least a couple of orders of magnitude better than the device you're trying to test, it's difficult to tease out how much of the result is the responsibility of each device. Fortunately, there's a way you can try to tease this out... by adding a third device.

    With three devices, you make a triangle of three test runs with each combination of two devices. You then ask TimeLab to give the n cornered hat plot.

    With the n cornered hat, TimeLab will attempt to isolate the ADEV of each device given the performance impact it had on the other two.

    It's imperfect, of course, because the runs won't be simultaneous, but if you're trying to measure things that are in the 10^-12 neighborhood and you don't have a Cesium reference, it's the best you can do.

    OH is an OH300 based GPSDO, FE is an FE-5660A with a GPS discipline board and TB is a Thunderbolt GPSDO.

    The samples aren't terribly long, so the right side should be taken with a healthy grain of salt, but really the interesting portions are up to around 10^2. The thunderbolt shows an ADEV somewhat better than expected results, but that's probably (at least somewhat) because I've lengthened the PLL time constant on mine to 3x10^2.

    The short tau results for the FE are consistent with manufacturer expectations. The OH300 results are consistent with previous results and are better than the manufacturer's spec at 10^0 (there isn't much guidance other than that).

    It does sort of confirm the results I've gotten all along - up to around 5 seconds, the OH300 is more stable, but past that, the Rubidium oscillators are better.

  • So... This happened...

    Nick Sayer01/31/2017 at 02:53 0 comments

    I made a little adapter board to take the NMEA output, PPS and 5 volt power from the 6 pin mini-DIN diagnostic connector and connect it up to a Raspberry Pi GPIO connector. That done, I've now made a Pi Zero Stratum 1 NTP server "accessory" for the GPSDO.

    So the two share the GPS receiver, and because of that they just have one antenna connection - a nice way to dual-purpose the connection.

    The circuit is simplicity itself - just a diode level shifter (to 3.3V) on the NMEA data and PPS line. The Pi serial out line goes through one of the two DIP switches and then to the GPS receive pin of the diagnostic connector. The other DIP switch is a disconnect for the 5 volt power. You can use it as a power switch (so you don't have to disconnect the oscillator or turn it off to power cycle the Pi), or disconnect power entirely and power your Pi separately (this probably would have a positive impact on the short term stability of the oscillator output - how much remains to be seen).

  • Another improvement idea

    Nick Sayer01/03/2017 at 22:29 0 comments

      There are a couple of birds I'd like to kill with one stone.

      Up to now, the TX pin from the controller has been connected to the GPS module's RX line. This was originally done to facilitate having the controller send commands to the GPS receiver, but this has never proven necessary. Instead, that line has been used solely for diagnostic output, but when it's doing that, there's no way to independently talk to the GPS receiver.

      At the same time, there have been a couple of times I've wanted to be able to plug subsidiary items into the diagnostic port without having to power them separately, but there's been no way to do that.

      So I'm contemplating updating the boards to change the Mini-DIN-4 to a Mini-DIN-6. One of the extra pins would be connected to the controller's transmit pin, and the linkage between that pin and the GPS receiver's receive channel would be broken (with a solder jumper to allow it to be reconnected if this turns out badly). The other extra pin would be connected to the Vcc (+5V) rail. This means that the diagnostic connector would have 3 serial pins - two for the GPS and one output from the controller. It would also have the buffered PPS output and would now also have 5 volt power.

      I can foresee using this to make a small daughterboard that would display the time and would parse the diagnostic output to glean performance information to display. I could also foresee a different board - a modified version of my LED GPS clock that would take power and GPS from the diagnostic connector.

      The GPS receive pin would have a diode+pull-up level shifter to protect it from higher voltage inputs. I am as yet undecided whether or not to buffer the GPS serial output. It means changing the board layout (and buying a new stencil), but it would result in 5v TTL levels instead of 3.3v, and would protect the GPS-controller link from external interference.

      The old MD-4:

      1. PPS
      2. TXD
      3. RXD
      4. GND

      The new MD-6:

      1. PPS
      2. GPS TXD
      3. GPS RXD
      4. Diagnostic TXD
      5. +5V
      6. GND

  • More bits! More bits!

    Nick Sayer10/01/2016 at 21:30 0 comments

    The design is becoming fairly mature, and as the results get better, more little things appear that are possible avenues for improvement.

    The original Connor Winfield application note had an 18 bit DAC, but we went down to a 16 bit DAC instead. One reason for that was that the 18 bit DAC was interpolated, which was a technique I didn't fully trust.

    But in the most recent results, I could see in some of the frequency graphs what appeared to me to be a stepwise behavior. The oscillator would dither between two frequencies, clearly wishing it were somewhere between. That led to a higher ADEV, of course.

    So I decided to see if reverting back to the AD5680 from the AD5061 would make a difference.

    Since the 5680 is interpolated, it requires a low-pass filter on the output so that the 10 kHz interpolation doesn't wind up frequency-modulating the output. This winds up being slightly complicated by the fact that we have the compression resistor network in place as well. The DAC datasheet limits the amount of capacitance on the output, so the RC filter can't have more than about a 0.01µF cap. But in order for the RC filter to work, the roll-off frequency has to be lower than 10 kHz (otherwise why bother?). To achieve a 1.5 kHz roll-off (recall that the roll-off frequency is 1/[2πRC]), that means we need to have a 10kΩ resistor. But the impedance of the compression network is more like 5kΩ - much too low, causing the DAC to basically be ignored. The solution was to multiply all of the resistors in the compression network by 10. The end result is 10kΩ in series with the DAC output, then a 0.01µF cap in parallel, then another 10kΩ in series, followed by two 100kΩ resistors in parallel to ground and Vref, and then finally the oscillator control voltage input. There's probably a better way to achieve this. It's conceivable that the second 10kΩ resistor could be replaced with 0Ω - that the resistor for the LPF can also serve as the resistance for the compression network.

    The firmware needed a slight adjustment as well to reflect the slightly different data format of the new DAC. That's just a #define in the code. The plan going forward is for the DOT050V variant to retain the AD5061, since it is unlikely that it will benefit from the added resolution.

  • Enter the ATMega328PB

    Nick Sayer09/04/2016 at 20:39 0 comments

    ATmel really wants you to switch to the new B variant of the venerable ATMega328p. They're basically charging a 25% premium for the older part on DigiKey (T&R pricing, Q:2000).

    To that end, this weekend I've updated my AVR toolchain to a variant that can support the 328pb and added support to the v4 firmware for it.

    The current board should accept a 328pb with the updated firmware. Two of the otherwise unused port E bits are tied to either Vcc or GND because on the older part they were added supply pins. That should be harmless - the default configuration will make those pins inputs anyway. The next board will disconnect those pins, but there's no rush. First thing to do is buy a few 328PBs and try them out with the new code to make sure they work.

    I'm still struggling with what to do about the FE5680A variant. I don't have a design for an upgraded version that takes the SkyTraq GPS module. The current design uses an ATTiny841, which has the ability to switch clock sources on the fly. This is necessary because before the 5680 obtains a physics lock, it's jittery enough that it upsets the 841 when it's used as a clock source. Neither the 328P nor 328PB have the ability to change clock sources other than with fuse changes. The 328PB has two serial ports, which is necessary for that variant, but it's unclear how it's going to work with the wonky pre-lock clock.

    I could make a variant that keeps the ATTiny841 and simply replaces the GPS module, but there's no room in the flash for the code to perform the quantization error correction that we can get from that module.

    EDIT: I got some 328PBs from DigiKey and they do work as a drop-in replacement for the 328P on the current versions of the boards. You can use the same firmware and fuse settings - all you have to do is add support to avrdude for the 328PB (it has a different device signature).

  • On balancing time constants

    Nick Sayer09/03/2016 at 16:23 0 comments

    After working on the FE-5680A discipline board, I came away with the presumption that longer time constants were universally better. After all, the tighter reign you keep on phase, the more you're going to have to horse around the frequency to do it.

    To that end, the OH300 firmware of late has had three time constants - 100, 400 and 800 seconds.

    I gathered some stats on the most recent unit I've built, and (alas I didn't save a screenshot), what I found was that its ADEV at low tau was better, but to make up for that, there was a giant "lump of suck" at around tau 2000s or so - up to 3E-11. Formerly, the results were more like a very rounded peak at 2E-11 from around 80s to 800s.

    As an experiment, I changed the time constants to 100, 200 and 400 and ran it overnight again, and now it seems to have the best of both worlds - the low tau ADEV has a negative peak of around 6E-12 at tau 3s and rises up to that plateau of 2E-11 from roughly tau 100-1000, then starts the GPS dominated downward angle towards 3E-12 at tau 10,000s and onwards from there.

    In comparing it to previous results taken some time ago, the low tau ADEV negative peak is lower now, but the medium tau hump is a touch higher and longer than before. It appears that that's the tradeoff - do you want lower ADEV at around 3s or lower ADEV and quicker dovetailing with GPS? It's a judgement call, but I think I'll go with this tuning. Perhaps in the future there might be a way to allow this tuning to be adjusted without uploading new firmware. I'll have to think about that some more.

    I'm going to check that change in, as well as check in the new 'v4' firmware for the new design with the SkyTraq modules with sawtooth compensation message parsing.

  • Venus838 and backup power

    Nick Sayer08/27/2016 at 05:38 0 comments

    I've created a variant of the breakout board that has a super capacitor (100 mF) to provide about an hour of battery backup. This allows the module to warm-start very quickly across brief power outages.

    And, sure enough, it warm-starts almost immediately when backup power is available.

    But the module I'm using is the timing variant. While the backup power does preserve the time and almanac so the first-fix is quite fast, the module does not preserve the surveyed position. That is, the module will immediately restart the 2000 second position survey.

    That's not as bad as it sounds. The module does provide good PPS fidelity while it's performing the survey (as long as it has good reception), but for the duration of the survey it won't provide the advantages that come from static mode - the ability to give good timing solutions with as few as a single satellite.

    What that tells me is that for a GPSDO, the backup power provisioning is unnecessary. Even when completely cold-starting, the module can get a fix in around 30 seconds or so. For an OCXO based GPSDO, the oscillator is going to spend perhaps the first hour retracing anyway, so that extra 30 seconds really doesn't matter.

    That said, if you want fast startup times, the supercap will do it (as long as the power outages are an hour-ish or less).

  • Sawtooth correction

    Nick Sayer08/22/2016 at 16:02 0 comments

    I've got back the prototype boards for the version of the OCXO variant with the ATMega328p and the SkyTraq module. I've been able to achieve sawtooth correction with the firmware:

    The blue line is the raw phase detection value and the red line is the post-correction value. It turns out that you have to scale up the sawtooth correction value given by the module 1.5x to apply it to the phase ADC values. There's a constant in the firmware code that represents the scaling factor, should that need to be tuned going forward. It's not completely clear why the scaling is so large.

    Because the ATMega328p lacks a 4.096v ADC reference, I went with the 1.1v one. That allows for a more linear phase discriminator response (even if it may be slightly noisier). For that to work, the charging resistor changed to 3kΩ and the cap to 1000pF. The nominal time constant of that is 3µs, which seems way too long, but when you look at it on the scope, it's a little bit higher than 1.1v when the phase is off by the maximum value of nearly 1µs. What that should mean is that each ADC count should be very close to a nanosecond, since there are 1024 counts. Instead, if the scale factor is to be believed, it's more like 666 ps. Either way, it does seem to work.

View all 101 project logs

  • 1

    Paste, place and reflow all of the components on the board.

    It may seem a bit harsh for that to be one instruction step, but there's really nothing particularly special about the process for this board. As always, make sure the polarized components are placed the correct way 'round.

  • 2

    Install 2 JST XH headers in the output port positions.

    If desired, install a mini-DIN 4 connector in the diagnostic port. One pin is ground, one is a copy of the PPS signal from the GPS module, one is the transmit data pin of the GPS module (and receive pin of the controller), and the other is the transmit pin of the controller (and receive pin of the GPS module). You also should not drive the GPS RX pin unless you've loaded non-debug firmware into the controller. With debug firmware, it's being driven by the controller and is diagnostic output instead.

    For the FE-5680A board, add a DB9 female connector with PC board pins. It mounts on the edge of the board with the 5 top pins soldered on top and the 4 bottom pins soldered on the bottom. Bend the pins together slightly to make the mechanical fit better. Solder one pin and then examine the jack from the side to make sure it's straight before soldering the rest of the pins.

  • 3

    Using a pogo pin adapter, fuse and program the controller. If your programmer has a target power mode, it's best (and for the OCXO variant, it's mandatory) to power the board with its built-in power supply and let that power the programmer.

    For the FE-5680A variant, the LFUSE value to use is 0xE2. For the other variants, 0xE0 is correct. For all variants, the HFUSE value is 0xD4 and the EFUSE is 0xFF.

View all 6 instructions

Enjoy this project?



Joost Breed wrote 11/27/2016 at 20:53 point


I noticed that you are using a switching regulator in your FE5680 design. Doesn't that add more phase noise to your signal compared to linear regulators? I'm currently using low noise LT1764A for all of my voltages, but they are a bit expensive, I need three of them. I'm wondering if you it is possible to make a low noise switching regulator.


  Are you sure? yes | no

Nick Sayer wrote 11/27/2016 at 21:11 point

The FE5680A datasheet has a spec for maximum noise and ripple on the power inputs. I sort of assume that if the power supply is better than that (and it is) that there's no benefit to be had in the output by improving the supply.

Using a linear design for the FE5680A is going to be a challenge because of the high current requirement.

  Are you sure? yes | no

Joost Breed wrote 07/29/2016 at 06:28 point

I could not reply to your last post. So I'm writing it here.

You have the wrong datasheet. That's the one of the P and L version. The T version has a 10MHz output on pin 12.

I'll have a look at averaging out the jitter you wrote about and do some experiments. But what do you mean with 'the averaging window for the phase to the PI time constant divided by 4'? How does that work?


  Are you sure? yes | no

Nick Sayer wrote 07/29/2016 at 15:05 point

I wrote back to them and there's been some confusion.

There is a v4 datasheet for the timing module and the nav module. You are looking at v2 of the timing module, and I was looking at v4 of the nav module.

The actual correct datasheet is

  Are you sure? yes | no

Joost Breed wrote 07/29/2016 at 19:54 point

That version also has a 10MHz output on pin 12.

  Are you sure? yes | no

Nick Sayer wrote 07/29/2016 at 22:41 point

That's true. As before, however, I'm not at all confident that it's stability is comparable to what you can get from an OCXO.

  Are you sure? yes | no

Joost Breed wrote 07/28/2016 at 18:34 point

Hi Nick,

I came across this project after googling my own project. I'm  just finished the first version of my reference ( I actually like your idea of using a PLL with a current source. Do you mind if I use that part in my project?

  Are you sure? yes | no

Nick Sayer wrote 07/28/2016 at 18:51 point

That's absolutely fine. It's only fair, since I got the idea from someone else (Jim Harman), and he got it from someone else... So it's definitely tribal knowledge at this point.

You'll find that adding the phase discriminator will make initial lock-up *MUCH* faster and you'll see far tighter phase control. What you'll want to do is balance phase coercion against the resulting frequency (in)stability. In other words, the harder you try to keep the phase lined up, the more you have to horse around the frequency to do it. Finding a good balance (which really means finding the best PI loop time constant) is the task at hand.

I've taken a look at a your article, and have a couple of ideas for you. One is that to convert sine to square you might try using a self-biased inverter instead of a high-speed comparator. You can check out the FE-5680A variant of the GPSDO to see an example. It's perfectly suitable for the job and likely is a lot cheaper.

Also, I've been using the PA6H all this time, like you, but it's a navigation module rather than a timing module. Navigation modules can serve the purpose, but for adequate timing results you have to give them *really good* reception. Timing modules can survey their location and then run with only one or two satellites with the assumption that their position is fixed. Additionally timing modules can give quantization error correction data for their PPS pulses. That allows you to factor away the PPS jitter, obtaining PPS timing that's as good as is possible with GPS at all (maybe down to ±1 ns or so). I'm taking a look at the Venus838LPx-T timing module. It's an LGA69 device, so soldering it isn't trivial. I hope to make a breakout board for it available on Tindie soon.

Another thing you can do is trade out your 32 bit hardware counter for one of the timers in the Atmel controller. To do that, you need to trade out your controller break-out board for a bare controller and fuse it for an external oscillator and clock it directly from the OCXO. If you do that, you can use the input capture facility to directly count the number of cycles of the OCXO that happen between PPS pulses. Even with the phase discriminator, you need to be able to track that, because if the frequency isn't close enough to the correct number of cycles per second, then the phase will wrap (that is, the ADC value will go from high to low or from low to high as the phase angle crosses 0) and be very difficult to track.

Of course, all of that basically converts your design into my design, so maybe I should just shut up. :D

  Are you sure? yes | no

Joost Breed wrote 07/28/2016 at 22:09 point


Thanks you for the tips. I can use those. Some of them I already implemented. I actually threw out the comparator last week and added a non buffered inverter with feedback resistor instead.

I also like the PA6H. Until now I was not able to find a GPS with less jitter. I measured the jitter and it is about 10ns. Do you use the average of multiple pll measurements to cope with that? The jitter must influence the pll output as well I guess.

I did not know about the Venus timing module. The module actually contains a 10MHz phase locked reference as well. I like it, but its a bit expensive, $50 or so. I like to keep it cheap. That's one of my goals. It will also be a problem for most people to solder the package. Although I own a home build smd oven. 

I was also thinking about using the internal counter instead of the external one. I used the external counter in this version because I was not able to check if the internal counter actually was counting correctly because of some latency. With the external counter I was sure it worked and also could measure that. Didn't you have any problems with any latency between the interrupt from the 1pps and storing the counter value? Or isnt't there any because it is not handled by the cpu?

Why did you swap the Atmega328p for the Attiny4313?

If I would use all your tips both our projects will look more or less the same I agree. But I don't mind, and I hope you don't. I'm having a lot of fun building it and figuring things out.

Best regards,

  Are you sure? yes | no

Nick Sayer wrote 07/28/2016 at 22:41 point

The way you can use the internal timer without latency is with the "input capture" feature. One of the pins on the controller (assuming you're using one that has the feature) will copy the current timer value into a holding register "instantly" and trigger an input capture interrupt. That facility allows me to accurately count the exact number of cycles of the system clock between rising edges of PPS. Since the timer value is captured in the capture register, the latency in reading it is immaterial (as long as you don't allow the value to be overwritten by the next capture).

I went with the ATTiny4313 originally to lower the cost. I may be going back to the 328 (actually the ATMega328PB) to get more flash space. I'm using the ATTiny841 now (to gain a 2nd USART and ADC), but I'm running out of flash.

My code sets the averaging window for the phase to the PI time constant divided by 4. This averages out the PPS jitter, but some GPS modules have a phenomenon called a "hanging bridge." See for an example. A hanging bridge can cause the averaging to be incorrect. Virtually all modules have PPS jitter because the microcontroller clock doesn't stay in phase with UTC, but it's only when the phase rate-of-change changes sign and the phase angle remains constant second-to-second for some period of time that there's trouble. Some GPS module select fractional controller clock frequencies to make *sure* that the phase rate of change never approaches zero for this reason. They don't have a problem because if you average the phase errors, they'll center around the actual value.

Timing modules will often provide you with a quantization error correction message. You take the observed PPS phase error and adjust it by the value of the quantization error. That gives you the actual phase error to the true UTC second. Hanging bridges and averaging are completely mooted by that.

I am not sure the Venus module's reference output is good enough to directly use for anything. I don't expect that its short term stability will come close to what an OCXO can deliver. It's certainly possible that it's better than I expect. I don't know. Also, I'm not sure that feature exists in recent versions. If you look at the latest version of the datasheet - - none of the pins are any sort of secondary frequency output.

  Are you sure? yes | no

Blecky wrote 04/07/2016 at 05:27 point

Hi Nick,

Are you looking to get these in stock again on your tindie store in the future?

  Are you sure? yes | no

Nick Sayer wrote 04/07/2016 at 05:41 point

Yes. Boards are being fabbed as we speak by OSHPark. They're due around tax day.

  Are you sure? yes | no

Blecky wrote 04/07/2016 at 06:15 point

Groovy, I've added myself to the wait list.

  Are you sure? yes | no

Blecky wrote 08/03/2015 at 05:23 point

±50ppb. Love that little VCTCXO.

  Are you sure? yes | no

Nick Sayer wrote 08/03/2015 at 05:26 point

It's actually much better than that. The ±50 ppb is its long term stability. The short term stability is ONE ppb. The long term stability is uninteresting in this case because of the feedback loop with GPS.

  Are you sure? yes | no

Blecky wrote 08/03/2015 at 05:50 point

Nice, you wouldn't happen to have the Allan deviation plot for this (I can't seem to find it)?

  Are you sure? yes | no

Nick Sayer wrote 08/03/2015 at 05:53 point

I don't have anything from Connor Winfield. I hope to be able to come up with something with the prototype of my design when the first boards arrive.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates