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%. But in both cases, we want the center of the range to remain at 3.3/2, or...

Read more »

GPS Disciplined FE5680 v2_1.pdf

PDF schematic for the FE-5680A variant

Adobe Portable Document Format - 117.70 kB - 02/10/2018 at 16:47


GPS Disciplined FE5680 v2_1_1.sch

EAGLE schematic for the FE-5680A variant

sch - 533.04 kB - 02/10/2018 at 16:47


GPS Disciplined FE5680 v2_1_1.brd

EAGLE board file for the FE-5680A variant

brd - 212.79 kB - 02/10/2018 at 16:47


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


GPS Disciplined VCxCXO v3_2_1.sch

EAGLE schematic for the OCXO variant

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


View all 14 files

  • 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.

  • Another diagnostic port option

    Nick Sayer11/28/2017 at 17:52 0 comments

    If you need to connect the diagnostic port up to RS-232, there's an adapter board design you can use. You can select whether the transmit pin is the diagnostic output or the GPS NMEA output. Received data is connected to GPS. The PPS output is connected to DCD and is configured so that DCD asserts on-time.

  • Another OCXO option

    Nick Sayer11/27/2017 at 21:43 0 comments

    I've been a pretty loyal user of the Connor Winfield OH300, but it's always a good idea to look for other options.

    And, sure enough, there is another option that looks compelling: the ECS ECOC-2522-10.000-3-F-C.

    The form factor is remarkably similar. The only real difference is on the OH300 the bottom center pin is NC and on the 2522 it's a Vref pin. Using that would save us the need to add a separate regulator for the DAC reference voltage. There are two more pins on the top edge of the OH300, but they're NC.

    Electrically, they're quite similar, but the 2522's pullability is ±700 ppb instead of ±400 ppb, and the lifetime aging spec is ±500 ppb instead of ±300 ppb. But on the flip side, the low frequency phase noise is 5 dB lower through 100 Hz on the 2522. They don't list a short term Allan deviation spec (the OH300 claims 1E-11 @ 𝜏 1s, but in my testing I actually see more like 8E-12). Additionally, the OH300 has a "dead band" for the control voltage of the outer 0.3V. The spec for the 2522 is rail-to-rail.

    The pullability specs for both suggest that with the 2522 the 18 bit tuning steps would be a bit coarser. What that winds up meaning when the rubber hits the road is, however, an open question.

    Lastly, the 2522 is $40 more (Q:1). Whether it's worth $40 more...? We'll have to build one to find out.

  • SkyTraq GPS module firmware issue

    Nick Sayer09/27/2017 at 12:38 0 comments

    Word has come to me via the TimeNuts mailing list that certain models of SkyTraq GPS receiver may have firmware issues that prevent them from getting a fix due to recent changes in the GPS almanac. This same note said that modules in survey-and-position-hold mode do not suffer from this problem. All of the SkyTraq modules I have obtained are in this latter category and (so far as I can tell) are continuing to operate normally. I have inquired of SkyTraq if there is any field remediation that should be taken, and I'll update here with anything I get back.

    Any GPSDO with a 6 pin diagnostic port can be connected to a TTL level serial interface. Presumably any remediation software that might come from SkyTraq would operate over this interface (if a field remediation is possible at all). A GPSDO with a 4 pin diagnostic port can also be similarly connected, as long as the microcontroller on the board is held in RESET (tie pin 5 of the ISP header to ground).

  • Changing the FE board from one oscillator to another

    Nick Sayer09/12/2017 at 16:12 0 comments

    The FE-5680A board can support the 5680A, the variant of the 5660A with firmware modified by Skip Withrow, and the FE-405B. It just requires different firmware for the FE-405B (and for the 5680A, it requires some adjustment to the solder jumpers).

    Replacing the firmware is a bit tricky, though, since sending garbage to an FEI oscillator over its serial port can brick it if you're not lucky. But you can't program the ATMel controller without a clock source, so you can't disconnect the oscillator, load the new firmware, and then connect the new oscillator.

    The solution is to erase the firmware while it's connected to the old oscillator (avrdude -c [programmer] -p m328pb -U flash:w:0:m), then move the board to the new oscillator and load the new firmware.

    While the flash is erased, the controller won't even configure, much less transmit on the serial ports, so there's no chance it will send garbage. In actual fact, there's little chance it would anyway, since when you switch from the 56x0A to the 405B you change from 10 MHz to 15 MHz, and the serial port clock generator will have the wrong constants, meaning it won't be able to properly parse the data from the GPS receiver. Without detecting a GPS lock, it shouldn't want to talk to the oscillator at all. But to be extra sure, I recommend following this procedure if you want to switch between the 56x0A and 405B.

  • Changing the buck converter

    Nick Sayer05/27/2017 at 03:54 0 comments

    When I last ordered a pile of Crazy Clocks to be manufactured, I screwed up and ordered a reel of PAM2305 buck converters (they're used in the GPS clock and the Pi clock projects) by mistake instead of XC9140 boost converters. Since they were ordered as DigiReels, they're not returnable, so I'm sort of stuck with a lifetime supply of them.

    Well, they're good chips... could they replace the SC189Z that I've been using in the GPSDO?

    Turns out that the answer appears to be yes. I built a board with one (it's pin compatible with the SC189Z) using the part values I've been using for the GPS clock. It seems to have nice low noise and ripple. It's going to take a few days run time for the oscillator to stabilize to get a good picture, but it looks good right at the start.

  • 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).

View all 109 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?



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 is

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


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