Close
0%
0%

GPS Disciplined xCXO

A DIY GPS disciplined 10 MHz reference clock

Similar projects worth following
In working on my Crazy Clock project ( https://hackaday.io/project/5880-crazy-clock ), 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%. But in both cases, we want the center of the range to remain at...

Read more »

Adobe Portable Document Format - 90.44 kB - 03/22/2018 at 16:23

Preview
Download

sch - 405.58 kB - 03/22/2018 at 16:21

See BOM
Download

brd - 166.45 kB - 03/22/2018 at 16:21

Download

Adobe Portable Document Format - 111.92 kB - 03/22/2018 at 16:23

Preview
Download

sch - 513.10 kB - 03/22/2018 at 16:21

See BOM
Download

View all 11 files

  • Load sensitivity

    Nick Sayer06/11/2018 at 15:54 0 comments

    From my experiments this morning with the new 5 pole sine filter I've discovered that there is some degree of load sensitivity on the output. I've seen this in the past when disconnecting loads - sometimes the mode will drop one notch while the PLL compensates. But somewhat more disturbing is that if you put a 50 Ω load on both outputs at the same time, you'll see a small glitch in the sine wave at the rising edge of the square wave (the two aren't perfectly in phase because the sine filter adds some delay).

    Fixing this means either lowering the power supply impedance to the output buffer chip or adding more bypass capacitance for it. I'll have to play with it some more, but for now my best advice is  to use one output or the other.

  • Sine output part 2

    Nick Sayer06/10/2018 at 22:00 0 comments

    I finally had an opportunity to build the GPSDO with the 5 pole output filter for the sine output instead of the 3 pole. It was also an excuse to dig out my old spectrum analyzer.

    Here's the old circuit:

    You can see that the first harmonic is only about 35 dB down from the fundamental and the third is not quite 50 dB down.

    Here's the new circuit:

    Now that second harmonic is knocked right down under 50 dB. I'm not sure what's up with the higher harmonics starting to drift up, but I did have to compromise a little on one of the capacitor values. I'm going to buy a reel of a better fit and maybe that will help a little bit. But even that I think is an improvement. I believe the higher order harmonics are less distressing than the low ones for a 10 MHz reference output.

    Of course, on my scope it looks like a sine wave, but the old circuit did too since my scope only has 50 MHz bandwidth.

  • On the sine output

    Nick Sayer05/14/2018 at 00:03 0 comments

    I've had some feedback from someone who bought a GPSDO that the sine output isn't as clean as I thought, and it turns out that the reason why it seemed cleaner to me was that I neglected to take into account that I have only a 50 MHz scope. Well, 50 MHz is only the 5th overtone of 10 MHz, so my view on the output is a bit myopic.

    So I'm going to order a set of boards to try with footprints for a 5 pole filter instead of a 3 pole filter. That ought to improve the filter's performance a bit (hopefully enough).

  • Grand firmware unification

    Nick Sayer03/22/2018 at 17:03 0 comments

    I've built and tested a prototype of the XMega32E5 controlled OH300, and it works fine. This has allowed me to return to a single firmware source for both boards. In the source code, you include an oscillator include file that has a bunch of macro definitions to tailor the source for that oscillator. In particular, the two board types are differentiated by the SPI_DAC macro. The FEI boards do not define that macro, and the OCXO and TCXO variants (not sure if I will go to the trouble of designing one of those - they don't really sell) do. In addition, if SPI_DAC is defined, you can choose between the AD5680 and AD5061 DACs depending on whether you need 16 or 18 bits of resolution (16 bits is for the TCXO variant). Next, the oscillator control file is where you define the EFC GAIN and (for the FEI board) any BIT_REDUCE value required to bring the gain down to a useful range. Lastly, the file defines the two or three time constants to be used by the modes. Longer time constants trade phase control for frequency stability.

    If your oscillator has an inverse EFC slope (higher EFC means lower frequency), then you can change the DAC_SIGN value from 1 to -1. Other than that, there should be nothing in the actual source code to change.

    The source repository includes support for the FE-56x0A, FE-405B (using the FEI board), and the OH300, ECOC-2522 (using the OCXO board) and the DOT050V (using a TCXO board, but I may not bother designing one).

  • XMega FE-5680A board build report

    Nick Sayer03/19/2018 at 14:29 0 comments

    The XMega board variant arrived and the prototype built. Converting the firmware over to the XMega architecture was a tedious exercise, but the result seems to work pretty well. At boot the board sets itself up to clock from the 32 MHz RC oscillator brought down to 30 MHz. The DFLL uses the internal 32 kHz RC oscillator to tune it. Once the FE lock pin is asserted, the PLL is set up to triple the 10 MHz input and switch over to using that. This neatly avoids the whole problem of the clock instability causing controller lock-ups and malfunctions prior to physics lock.

    A side effect of this is that programming now no longer strictly requires the external oscillator be fed. PDI programming can take place regardless. Of course, that means having to use a PDI programmer, which is marginally less convenient for me than SPI programming.

    If there's a real downside it's that I've discovered the chink in the XMega's armor: the ADC is terrible. I've had to configure it for differential mode with the negative pin connected to ground internally. The result is effectively an 11 bit ADC instead of 12 bits, and even then it's so noisy that throwing away another bit to make the output compatible with the ATMega ADC doesn't matter - it still jumps around 2-3 bits worth even then. For our purposes, it isn't too harmful, though, as the phase discriminator output gets averaged over the course of many seconds. It's bad enough, though, that I may wind up adding another conversion to the capture ISR to get a two-sample average each second.

    I designed an OH300/ECS2522 board variant with the XMega too. It's not strictly necessary to convert that design, but the benefit would be the possibility of unifying the firmware across both platforms. The only real difference between them would be changing the serial oscillator interface into an SPI interface to drive the external DAC (the XMega has a 12 bit DAC, but that's not nearly enough granularity). Other than that, all that changes are some constant values relating to the EFC slope.

  • More ECOC-2522 results

    Nick Sayer03/05/2018 at 18:04 0 comments

    The first unit I built with the ECOC-2522 did not work very well. The low-tau ADEV was above 10^-11, but it's supposed to be down in the low -12s. I found a lot of noise on the reference voltage output line. I'm not sure what's going on there.

    I built a second one with the same circuit that I use for the OH300. For that one, the resulting ADEV is much better - in the mid -12s. It's not as good as ECS' test data says it should be, but it's possible that either my test set up or the circuit is contributing enough noise to take the result from the low to the mid -12s.

    It's somewhat concerning that the reference output from this oscillator seems to have too much noise to use. Of course, the sample size is 1, so it may just be that I got a dud.

    In the end, however, the ECS isn't so much better than the Connor Winfield unit that I'm going to switch to it. And while the ADEV curve is slightly better at tau 2-10 seconds or so, I'm not convinced it's better enough to justify the extra cost.

  • I've had it

    Nick Sayer02/25/2018 at 22:44 0 comments

    Back when the controller for the 5680/5660 board variant was the ATTiny841 the fact that the oscillator output could glitch when the !READY output wasn't on was not a problem - the ATTiny841 can alter its clock source programmatically, so you can run it from the 8 MHz internal oscillator until the oscillator comes ready, then switch.

    The ATMega328PB can't do that. And I've tried a bunch of things to try and prevent glitching from affecting the controller, but it's just not working out to my satisfaction.

    The next step forward is to try a variant with the ATXmega32E5. This has some positive ramifications, but some negative ones.

    One big change is that the controller needs 3.3 volt power instead of 5 volt. To some extent, this makes interfacing with the GPS receiver a little easier, since it's 3.3 volts too. The 3.3 volt LDO powering the GPS receiver has plenty of capacity to power the controller as well.

    One big benefit we gain is that there's no longer a need to share the programming pins with any other functional pins. This means we can get rid of the NAND gates that would disconnect the oscillator from its serial pins when !RESET was low (during programming). This is because both of the serial ports (the port C one has GPS input and diagnostic output, and the port D one has the oscillator I/O) can be dedicated to their sole task.

    The downside is that two of the inputs into the controller need to be level shifted down from 5 volts. The oscillator TX output from the MAX232 can be level shifted with a simple diode+pull-up circuit, but the other signal that needs to be shifted is the 10 MHz clock from the NB3N551. Down-shifting a 10 MHz clock requires a bit more care. I'm going to try using a low value resistor divider (1kΩ/500Ω) or a low value resistor and zener pair (not yet sure which).

    Another benefit we gain from this arrangement is that the XMega can run at a faster internal clock rate. We still want to clock it from the oscillator, but there's an internal PLL that we can use to triple that to 30 MHz. We can also run the internal 32 MHz oscillator instead at 30 MHz so that we can run at a consistent clock speed both before and after we switch to the external oscillator.

    We also get a 12 bit ADC instead of a 10 bit one, so in principle the granularity of the phase discriminator can be 250 ps instead of 1 ns (whether it's going to be that accurate or not is questionable). For the first cut of the firmware, however, it's likely we'll just throw away the extra two bits to try and get everything running properly. There's a DAC as well, but it doesn't do us any good since the FE oscillators are serial-controlled. It won't do us any good on the OCXO/TCXO variants because 12 bits isn't enough for them.

    Lastly, we no longer have to insist that programming only take place with the oscillator connected. Unfortunately, we need to use PDI to do the programming, but at least we can do that whether the oscillator is connected or not (and PDI is very fast).

    The last downside, of course, is that the XMega is double the price ($2.80 vs $1.40 Q:1), but we do get to say goodbye to a couple of ICs (we do gain a couple of inexpensive diodes), which softens the blow a little. At least it's the same package as the 328PB we were using before.

    Rewriting the firmware is going to be a painful operation, but I said that before doing the same thing for the GPS clock, so yeah.

  • 5680A watchdog redux

    Nick Sayer02/10/2018 at 16:54 0 comments

    Well, I'm glad I checked... It turns out the new watchdog chip was permanently wired disabled.

    Fortunately, it has an internal pull-down, so you can leave the enable pin floating and it will be forced-enabled. With that, I verified that it wasn't actually working properly.

    One issue is that the default Lfuse value of 0xe0 delays startup for 65 ms, which is way too long. That's been changed to 0xc0, which essentially has no delay. But if startup gets wedged, that's ok, because the watchdog circuit is there to force it to try again. :)

    The other issue is that the watchdog seems to impede programming. On AVRs, programming mode is entered by bringing !RESET low, but apparently the start of actual programming has some timing constraints, as it would seem that the watchdog occasionally yanking on the !RESET line during programming is no good. So I'm going to have to spin new boards with a solder jumper to disable the watchdog. You close the jumper for programming and then open it again once programming is complete. It's not ideal, but it will do. The alternative is to not install the chip until programming is complete, but that complicates field firmware updates.

  • Watchdog for 5680A boards

    Nick Sayer02/03/2018 at 17:22 0 comments

    I've found sometimes when cold-starting the frequency of a 5680A is unstable enough to sometimes result in the controller locking up.

    This was worked-around on the ATTiny841 variant by clocking the controller internally until the oscillator indicated a lock and then switching to external clocking, but when we moved to the ATMega328PB (because of running out of flash) that wasn't an option.

    I tried first to delay startup by holding RESET low with a Schmidt trigger buffer on an RC circuit, thinking that was the issue, but it didn't fix things all the way, so I've decided to replace that with a hardware watchdog.

    The STWD100NPWY3F is a good choice. It's has an open drain output that it will bring low to reset the controller. It expects to see rising edges at least every 3 ms or so on its input or it will trigger a reset. An unused line on the controller will be configured as an output and every time we used to call wdt_reset(), we'll call a method that does that and toggles that output line. As long as we do that at least once every ms or so, that should be enough. If the controller gets wedged, then the watchdog will reset it. Fortunately, I've not seen a board lock up so hard that briefly shorting RESET to ground on the ISP header doesn't unstick it. The issue in the past has been sometimes it's hard to tell the difference between mode 0 and a locked up controller, so this will make that unnecessary.

    As a happy coincidence, when programming the controller, RESET is held low anyway, so the fact that the watchdog won't be being petted during programming won't be an issue.

    EDIT: It took a while, but I finally got around to building one of these, and I paired it with a cold 5680A. I was able to observe the controller go bonkers for a moment and - unlike in the past - it got reset and started right back up. Overnight, it made it to mode 3 and all indications are that it works perfectly.

  • First ECS results

    Nick Sayer12/18/2017 at 22:17 0 comments

    I've built the first unit with the ECS ECOC-2522-10.000-3-F-C. It made it to mode 3 overnight, which is much faster than "first light" for an OH300. At not quite 24 hours in, the average phase error reported by the diagnostic log output is hovering in the low single digits, and the DAC is dancing in a corridor of around 3 units width, perhaps aging upwards fairly slowly.

    Interestingly enough, the reference voltage output of this unit was measured at around 2.8V rather than 3.3. That said, the current DAC setting is 0x27A13, which when you scale it is around 1.733 volts. So the reference voltage is lower than expected, but the actual center point is just over the actual Vcc/2 midpoint.

    ADEV testing for this variant is pending. I want to wear it in a few days and then run it against my Thunderbolt. In principle, the ADEV claimed by ECS is around what the Thunderbolt itself claims, so I may not really be able to work out the actual quality of this one myself. Not sure where I'll go from there. I rather suspect sending it out to be tested by a proper lab would be more than I could afford.

    If it turns out that this unit is equal to the TB, then I will probably retire my TB and start actually eating my own proverbial dog food.

View all 116 project logs

  • 1
    Step 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
    Step 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
    Step 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?

Share

Discussions

project.director wrote 05/05/2017 at 04:52 point

Hello Nick..?

Ok Sir, I do not really know how to use this site, and I dont really plan on becoming a regular member. However, I have been working on a project for some time that is a timing and scoring application for off-road Rally Racing events....website is www.ohprg.com

I think that you have a couple of items, GPS Clock and GPS Time Server that will save me and my team hords of development time and effort on...not to mention money as we are all volunteers and dont get paid for any of this........

Im down in South Orange County, CA and VERY much look forward to speaking with you.....
I signed up on this site specifically to make contact with you.....

  Are you sure? yes | no

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

Nick,

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.

Joost

  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. 
http://navspark.mybigcommerce.com/content/Venus838LPx-T_DS_v2.pdf

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?

Joost

  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 http://navspark.mybigcommerce.com/content/Venus838LPx-T_DS_v4.pdf

  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 (https://www.elektormagazine.com/labs/gps-assisted-10-mhz-frequency-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

Nick,

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,
Joost

  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 http://www.leapsecond.com/pages/m12/sawtooth.htm 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 - http://www.skytraq.com.tw/datasheet/Venus838LPx_DS_v4.pdf - 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