CMOS OXCO - input capacitance?

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to create what amounts to as accurate a frequency counter as I can possibly build. At the moment, I am considering a 3.3v CMOS output 20 MHz OXCO.

 

The application notes for the oscillator have all sorts of caveats in order to achieve the specified tolerance. One of them is output loading. They want a 15 pF load. They talk about buffering the output, but given that the output is going straight into the input of the ATMega328P and nowhere else, I am inclined to skip that.

 

The question at the moment is, if you fuse the atmega for an external oscillator, how much capacitance should I assume for the pin? 0? Should I just use a 15 pF cap in parallel (to ground) between the OXCO and the ATMega? Anybody else have any advice?

 

My real issue is that I have no other means to calibrate or check the calibration of this system once it's done (none of my other tools have a design tolerance as tight as what I want to achieve here - which is around 10 ppb). I'm going to just sort of have to ride on a wing and a prayer, so I want to get the design as close to ideal as possible. Moreover, this OXCO is super expensive, so I want to get my money's worth out of it. I know for sure one thing is that I need to design a beefy power supply for it, as it needs nearly an amp at 3.3 volts, but that's a whole 'nother story. 

Last Edited: Mon. Jul 13, 2015 - 02:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would help to tell more about the aims of your project.  In particular, the frequency range needed to be measured.

 

If I think about it, I wouldn't necessarily be concerned about the absolute accuracy of the reference clock source, but rather its stability--absolute accuracy can be calibrated (but then the reference must be accurate).   Maybe the cooked oscillators are indeed the only way to go.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm measuring a 16.384 kHz square wave and wish to determine it's accuracy with a resolution down to 0.1 ppm. To do so, it takes a bit longer than 10 minutes for 0.1 ppm to represent +/- 1 cycle. What I need is a hyper-accurate reference to count than ~10 minute interval.

 

I've been using GPS, but the issue I'm running into is that while GPS is well disciplined long-term, I appear to be seeing some non-trivial jitter in the short term.

The new plan is to clock the controller with the 20 MHz 10 ppb OXCO, then use timer1 with a pre-scale of 64 and CTC counting to 3125 to represent a 100 Hz interrupt source. I count the number of rising edges of the test frequency that occur between 61,100 OC1A interrupts and do the math.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm--this article is flogging GPS time...

http://www.sitime.com/support2/d...

 

This app note may be of interest:

http://www.ni.com/white-paper/36...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've already got a measurement methodology that's working. It's effectively option 2 from the white paper you've linked - count the rising edges over a fixed time. In my case, I compare expected to actual to determine the error and report it. The problem is that the GPS PPS output that I have available seems to have poor short-term stability, which is evidenced by the fact that repeated measurements of the same signal are all over the place (generally two discrete values separated by ~10 ppm). I could get a Rubidium standard off eBay, but I don't have any means to confidently prove that its output is any more accurate than an OXCO from DigiKey (which is accurate enough for my purposes in any event), or even that it actually *is* what it purports to be.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A CMOS logic input is typically 4-7pf, depending on the package and the CMOS feature size. For a 328P, I'd guess it to be toward the lower end of that range. 

 

Don't forget that a trace will add a few pf, especially if over a ground-plane. 

 

I doubt that the load capacitance will change the frequency of a TXCO significantly. It will have much more to do with overshoot and ringing.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thanks. I'll try a 10 pF NP0 cap.

 

I'm being extra paranoid because the OXCO manufacturer had a big red warning on their datasheet saying that it was sensitive to loading. I imagine, though, that if it's +/- 5 pF it's *probably* close enough, but I don't really *know*, and I'm afraid I won't be able to tell the difference in the final result - it'll just be *wrong* and I'll be none the wiser.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

I'm measuring a 16.384 kHz square wave and wish to determine it's accuracy with a resolution down to 0.1 ppm. To do so, it takes a bit longer than 10 minutes for 0.1 ppm to represent +/- 1 cycle. What I need is a hyper-accurate reference to count than ~10 minute interval.

You are not using a Reciprocal Counter Design ?

 

nsayer wrote:

The problem is that the GPS PPS output that I have available seems to have poor short-term stability, which is evidenced by the fact that repeated measurements of the same signal are all over the place (generally two discrete values separated by ~10 ppm).

Sounds maybe faulty ?  Or they took some short cuts ?

If you do have two peaks, check the relative density and I wonder is one is 'wrong' or if they are rate-multiplier modulating to fix some division issue, and the average is correct.  Some RTCs also do this.

 

Another design approach is to use the GPS to discipline a VCTXCO, which should be stable << 0.1ppm but with some offset.

A wobbling GPS is a pain, but it could be tolerated.

 

 

nsayer wrote:

I'm being extra paranoid because the OXCO manufacturer had a big red warning on their datasheet saying that it was sensitive to loading.

Surprising, but they should spec a ppb/pf if that is the case, so you should know what the impact of the xx pF is.

If that ppb/pF is large, you could use a trimmer and check over a very long time frame using the wobbly GPS

Is this a clipped sine out, or CMOS out ?

Last Edited: Mon. Jul 13, 2015 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

 

nsayer wrote:

 

I'm measuring a 16.384 kHz square wave and wish to determine it's accuracy with a resolution down to 0.1 ppm. To do so, it takes a bit longer than 10 minutes for 0.1 ppm to represent +/- 1 cycle. What I need is a hyper-accurate reference to count than ~10 minute interval.

 

 

You are not using a Reciprocal Counter Design ?

 

 

 

Oh, I don't know what it's called. I know that in a certain number of seconds I expect to see a certain number of cycles, and the difference between expected and actual is the error. It's not rocket science.

Quote:

 

nsayer wrote:

 

The problem is that the GPS PPS output that I have available seems to have poor short-term stability, which is evidenced by the fact that repeated measurements of the same signal are all over the place (generally two discrete values separated by ~10 ppm).

 

 

Sounds maybe faulty ?  Or they took some short cuts ?

If you do have two peaks, check the relative density and I wonder is one is 'wrong' or if they are rate-multiplier modulating to fix some division issue, and the average is correct.  Some RTCs also do this.

 

Another design approach is to use the GPS to discipline a VCTXCO, which should be stable << 0.1ppm but with some offset.

A wobbling GPS is a pain, but it could be tolerated.

 

I am choosing to untie the gordian knot with an axe instead.

Quote:

 

 

 

nsayer wrote:

 

I'm being extra paranoid because the OXCO manufacturer had a big red warning on their datasheet saying that it was sensitive to loading.

 

 

Surprising, but they should spec a ppb/pf if that is the case, so you should know what the impact of the xx pF is.

If that ppb/pF is large, you could use a trimmer and check over a very long time frame using the wobbly GPS

Is this a clipped sine out, or CMOS out ?

It is CMOS out: http://www.digikey.com/product-d...

 

My concerns are from their application note: http://www.conwin.com/pdfs/AN209...

 

"

  1. Always adhere to stated loading specifications}

    for OCXO RF output. OCXOs are load sensitive and require an equivalent load capacitor with a flat capacitance vs. temperature curve to achieve stated frequency stability specifications. Consider NPO/COG capacitors when practical for optimal temperature characteristics. See FIGURE 13-01 Frequency Response to various equivalent capacitive loads. "

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

I am choosing to untie the gordian knot with an axe instead.

Hehe, sometimes that approach has merit !

 

 

nsayer wrote:

Who-me wrote:

You are not using a Reciprocal Counter Design ?

Oh, I don't know what it's called. I know that in a certain number of seconds I expect to see a certain number of cycles, and the difference between expected and actual is the error. It's not rocket science.

A Reciprocal Frequency Counter extracts two numbers, FiCycles &  XtalCycles and it snaps a measurement to the Fi edges.

Taking your examples of 20MHz and 16384 Hz and say an appx 5 second measurement interval.

You calculate Fi = FiCycles * XtalMHz/XtalCycles

The LSB of that 5s measure is

1-((16384*5)*20M/(-1+20M*5))/16384  = ~10 ppb

- ie you can resolve to 10ppb LSB in 5 seconds with a Reciprocal Frequency Counter

 

nsayer wrote:

My concerns are from their application note: http://www.conwin.com/pdfs/AN209...

"

  1. Always adhere to stated loading specifications}

    for OCXO RF output. OCXOs are load sensitive and require an equivalent load capacitor with a flat capacitance vs. temperature curve to achieve stated frequency stability specifications. Consider NPO/COG capacitors when practical for optimal temperature characteristics. See FIGURE 13-01 Frequency Response to various equivalent capacitive loads. "

Hmm, seems very high for a CMOS out ?  Perhaps a typo ?  You could ask the vendor for a ppb/pF value ?

If those values really are correct @ some-ppm, I would use a very close buffer design of a NPO Cap, series R 220~1K into a 1G14, and then another 220~1k to the MCU

 

As a reality check Google finds this

www.rakon.com/products/families/...load/file?fid=39.129

The Rakon RFPO50 specs 10ppb for 5pf or ~2ppb/pF

It also seems to be cheaper than that Digikey part ~ $79

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem is that you don't get to use the whole 20 MHz because it's the CPU execution clock as well. That is, during the time it takes for the ISR foreplay to happen, the counter will have moved on significantly.

I chose 100 Hz specifically so I wouldn't have to be so careful about counting the number of instructions and how many cycles each takes and on and on.

Now the next thing you're going to suggest is a separate and faster instruction clock, to which my answer is that I'm using the tools I am most comfortable with and that it doesn't need to be done faster as long as it's done accurately.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

The problem is that you don't get to use the whole 20 MHz because it's the CPU execution clock as well. That is, during the time it takes for the ISR foreplay to happen, the counter will have moved on significantly.

I chose 100 Hz specifically so I wouldn't have to be so careful about counting the number of instructions and how many cycles each takes and on and on.

Now the next thing you're going to suggest is a separate and faster instruction clock, to which my answer is that I'm using the tools I am most comfortable with and that it doesn't need to be done faster as long as it's done accurately.

No, I'm going to suggest Hardware capture(XtalCycles), and external clocked timer (fiCycles).

HW capture gives you a leisurely 1220 cycles to read the capture value.

An easy to use 2^16 FiCycles measurement rate gives 12.5ppb LSB in a 4 second reading.

 

Actually, given your special test case, life can get simpler, as you find 20M*4 MOD 2^16 is an offset of 13312, which means you can resolve a single 16b capture to an 820ppm window.

As you chase sub-ppm, you already know where in that 820ppm window you will be, so a simple 16b reading is enough.

 

Last Edited: Mon. Jul 13, 2015 - 09:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Who-me wrote:

 

nsayer wrote:

 

The problem is that you don't get to use the whole 20 MHz because it's the CPU execution clock as well. That is, during the time it takes for the ISR foreplay to happen, the counter will have moved on significantly.

I chose 100 Hz specifically so I wouldn't have to be so careful about counting the number of instructions and how many cycles each takes and on and on.

Now the next thing you're going to suggest is a separate and faster instruction clock, to which my answer is that I'm using the tools I am most comfortable with and that it doesn't need to be done faster as long as it's done accurately.

 

 

No, I'm going to suggest Hardware capture(XtalCycles), and external clocked timer (fiCycles).

HW capture gives you a leisurely 1220 cycles to read the capture value.

An easy to use 2^16 FiCycles measurement rate gives 12.5ppb LSB in a 4 second reading.

 

 

 

I guess I'm not getting it then. I don't see how you're achieving this with just an ATMega328P and a 20 MHz oscillator, keeping in mind that you can't externally clock a timer faster than the system clock, you can't prescale an external timer clock source, and the maximum (supported) clock speed for an ATMega328P is 20 MHz.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

I guess I'm not getting it then. I don't see how you're achieving this with just an ATMega328P and a 20 MHz oscillator, keeping in mind that you can't externally clock a timer faster than the system clock, you can't prescale an external timer clock source, and the maximum (supported) clock speed for an ATMega328P is 20 MHz.

Search for Input Capture (of a timer running at SysCLK), and the external clock needs only make 16384 Hz.

Two pins may need to be connected, an External CLK on one timer, and Capture pin on another.

 

Every edge of 16384 Hz captures a timestamp, but you only need to read that once every 2^16 edges (4 seconds)

A perfect signal 16384.0000 will advance that 16b capture by 13312 cycles. LSB is ~16384.0002

Last Edited: Mon. Jul 13, 2015 - 09:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I found input capture. That does appear to be an excellent way to use the full 20 MHz, as the edge will lock the value in.

 

It appears to me that the thing to do is use an ISR for the input capture to grab the immediate delta and add it to an accumulator. The 16 kHz signal doesn't really need to be on a timer, as it's slow enough it can simply be counted with INT0 set for rising edges. After 16384 rising edges, the accumulator should be equal to 20,000,000, and the delta from that is in units of .05 ppm, which is double the required resolution (0.1 ppm).

 

Me gusta. Thanks!

Last Edited: Mon. Jul 13, 2015 - 11:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

... After 16384 rising edges, the accumulator should be equal to 20,000,000, and the delta from that is in units of .05 ppm, which is double the required resolution (0.1 ppm).

 

The rising edges between readings is fully controllable, easily up to 65536, and I prefer my measurement LSB to be well under the target resolution. 2:1 margin is a little low. 8:1 is better.

You can also run longer time base checks, if you stream the numbers and never miss edges, eg you can average over 100 x 4s readings for even better precision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

 The problem is that the GPS PPS output that I have available seems to have poor short-term stability, which is evidenced by the fact that repeated measurements of the same signal are all over the place (generally two discrete values separated by ~10 ppm).

This info was interesting.

Can you give the GPS Module Part Number, Chip set used, and more details on the two discrete values seen ?

Was one slightly High, and one slightly low, and the average is designed to be 1.00pps ?

 

I can think of some design cases where SW+HW is combined on an after-thought 1pps signal...

eg Suppose the chip has only a 16b timer, and a binary prescaler, and let's take a 26MHz xtal.

That gives ~ 5ppm fast or ~15ppm slow, and a modulation frame of 3 of one and 1 of the other gives

something like (50781*256*2/26M)*3+(50782*256*2/26M)*1 = 4.00000 0ppm error  ie this example is precise over 4s multiples.

 

If you can find the repeat frame of that modulation, that could give a jump in precision.

(It may not be as simple as the example above)

Alternatively, if it wanders not averaging to 1.0s, then maybe the GPS module is simply losing lock ?

 

Using another Timer capture channel, you should be able to easily check and report every 1pps ?

0 ppm will give a 16b capture advance of  11520, +5ppm will be 11620 and -5ppm will be 11420 deltas

 

Last Edited: Tue. Jul 14, 2015 - 01:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

Ok, I found input capture. That does appear to be an excellent way to use the full 20 MHz, as the edge will lock the value in.

 

It appears to me that the thing to do is use an ISR for the input capture to grab the immediate delta and add it to an accumulator. The 16 kHz signal doesn't really need to be on a timer, as it's slow enough it can simply be counted with INT0 set for rising edges. After 16384 rising edges, the accumulator should be equal to 20,000,000, and the delta from that is in units of .05 ppm, which is double the required resolution (0.1 ppm).

 

Me gusta. Thanks!

 

This worked out very nicely. I quickly threw together a breadboarded version clocked from an ordinary 20 MHz crystal and within a second of it starting, when connected to one of the boards under test, it displayed a stable value within two seconds, and that value stayed rock steady (occasionally flickering by 0.05 ppm - one count's worth) as long as I watched it.

 

Now, of course, that value disagrees by an order of magnitude with the GPS circuit, but that's because it's a completely ordinary crystal with whatever load caps I happened to have handy, so there's no telling how far away from 20 MHz it is, but that's not really the point right now.

 

Now I have sufficient confidence in the setup that I can proceed with the relatively huge oscillator investment. When it arrives, I've got half a mind to run an analysis of the GPS PPS output to see if I can quantify the jitter I'm witnessing.

It's an Adafruit Ultimate GPS module, FWIW. I've got one serving as a public stratum 1 NTP server with a Raspberry Pi, but Internet NTP service delivers accuracy at least 3 orders of magnitude worse than GPS, so whatever this jitter is, it's well and truly lost in the noise.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

It's an Adafruit Ultimate GPS module, FWIW.

 

This one ? (model 3 ?)

http://www.adafruit.com/products...

 

I was going to order a couple of those, so am very interested in what you find re jitter.

 

nsayer wrote:

.... and that value stayed rock steady (occasionally flickering by 0.05 ppm - one count's worth) as long as I watched it.

 

Now, of course, that value disagrees by an order of magnitude with the GPS circuit, but that's because it's a completely ordinary crystal with whatever load caps I happened to have handy, so there's no telling how far away from 20 MHz it is, but that's not really the point right now.

Before you spend $$$, you now have a stable enough system to check the 1pps - if you saw ~10ppm deviations, the dual references you have now will be << that.

Absolute CAL is an issue, but you are looking for a pattern in the 1pps changes, or to decide if they are outliers, or maybe losing lock ?

 

You can save quite a lot on OCXO /VCTCXO by relaxing the absolute calibration & maybe that GPS can be good enough to do that ?

 

Addit: Also check each edge on the 1pps, from memory some spec on a certain edge.

 

Datasheet for the PA6H (MTK3339) GPS module itself - used in version 3 of this module says

["A pulse per second (1 PPS) is an electrical signal that very precisely indicates the start of a second.
Depending on the source, properly operating PPS signals have typical accuracy ranging 10ns.
1 PPS signals are used for precise timekeeping and time measurement. One increasingly common
use is in computer timekeeping, including the NTP protocol. A common use for the PPS signal is to
connect it to a PC using a low-latency, low-jitter wire connection and allow a program to synchronize
to it:
PA6H supply the high accurate 1PPS timing to synchronize to GPS time after 3D-Fix.
A power-on output 1pps is also available for customization firmware settings.

 

Timing Accuracy    (1PPS Output)       10 ns(Typical )   "]

 

["The Vcc ripple must be controlled under 50mV pp "]

 

Last Edited: Tue. Jul 14, 2015 - 06:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

 

nsayer wrote:

 

It's an Adafruit Ultimate GPS module, FWIW.

 

 

 

This one ? (model 3 ?)

http://www.adafruit.com/products...

 

I was going to order a couple of those, so am very interested in what you find re jitter.

 

 

nsayer wrote:

 

.... and that value stayed rock steady (occasionally flickering by 0.05 ppm - one count's worth) as long as I watched it.

 

Now, of course, that value disagrees by an order of magnitude with the GPS circuit, but that's because it's a completely ordinary crystal with whatever load caps I happened to have handy, so there's no telling how far away from 20 MHz it is, but that's not really the point right now.

 

 

Before you spend $$$, you now have a stable enough system to check the 1pps - if you saw ~10ppm deviations, the dual references you have now will be << that.

Absolute CAL is an issue, but you are looking for a pattern in the 1pps changes, or to decide if they are outliers, or maybe losing lock ?

 

You can save quite a lot on OCXO /VCTCXO by relaxing the absolute calibration & maybe that GPS can be good enough to do that ?

 

Addit: Also check each edge on the 1pps, from memory some spec on a certain edge.

 

The use case here is calibrating timepieces, so absolute precision of the frequency measurement really is the whole point. And if nothing else, a 20 MHz reference is capable of making the measurements way, way faster than a 1 Hz one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

The use case here is calibrating timepieces, so absolute precision of the frequency measurement really is the whole point. And if nothing else, a 20 MHz reference is capable of making the measurements way, way faster than a 1 Hz one.

 

? Err yes, of course.

The point is, the 20MHz can be Auto-calibrated using the 1pps. (assumes a good 1pps, but the specs I checked claim 10ns jitter, which is 10ppb and << the 50ns sample uncertainty of 20MHz)

 

If you measure the 16384Hz and 1pps at the same time, and use nearest-fi-edge to each 1s pulse, then the 1pps capture gives you a correction figure, to apply to the 16384, which is the Xtal average (largely, ~99.98779% coverage) over the measurement time.

It does not have to be a single 1pps window, it could be 4,5 or 10s

 

That large common overlap, means (eg) 400ppm oscillator drift, drops to 50ppb.

Of course even a cheap Xtal will be way better than 400pm, over 1s - more likely under 1ppm. 

400ppm is almost in the realm of On Chip RC oscillators :)

Last Edited: Tue. Jul 14, 2015 - 06:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you calibrate your OXCO regularly, you can adjust in software. You should be able to reject the 'unusual' GPS readings. It does not matter if the calibration check takes minutes or hours. It can take place in the background while the product is in use with timepieces.
The OXCO should have an excellent short term stability.
As suggested by others, the AVR input capacitance will be trivial but the pcb trace layout and ground plane need to be considered. I doubt if the load will be significant.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, this morning I saw something quite odd that has shifted around my perspective a bit.

 

We're now drifting well and truly off-topic (as if we weren't already)... but I'll at least finish up the train of thought.

 

This morning when I came out to the workbench, I had left one of my test units powered up and on the 20 MHz crystal measuring jig and its drift was oscillating over a +/- 5 ppm window. Alternate seconds, it would give one drift value, and then the next second it would be 10 ppm higher, and then back to the original value.

I briefly put my thumb over the crystal on the test unit, which thoroughly detuned it momentarily and then released it at let it settle, and it came back to a stable frequency, which was the lower of the two oscillation points.

 

I suppose I have no right to complain, because the tolerance of the test unit crystals are 10 ppm, meaning that it *is* staying within its tolerance band. I just didn't expect to see a measurable short-term instability like that. I now obviously doubt my earlier theory about the GPS PPS jitter.

I am going to go ahead with an oscillator based calibrator, but have decided to go with a TXCO rather than an OXCO. I've found one rated for 50 ppb that's a third the cost and draws 1/100th the current and have decided that that's good enough. When the boards come back and I get it built, I'll check its calibration against GPS just to make sure it's behaving itself. I'll just extend my input capture code with a TIMER1_OVF ISR to add more high-order bits to the counter so I can basically insure that over 10 PPS pulses I see 200,000,000 timer counts. I can run that for a couple days to really burn it in. :)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All sounding good, and not off topic at all.

I think you were 'lucky' enough to bump into a known crystal effect called mode hopping

one example

http://www.4timing.com/techcryst...

If you adjust the caps to give a more correct Osc freq, you should change that.

 

I'd suggest capture both GPS and Fi at the same measurement frame, and nominally pace your measurement to GPS if present

(you have to snap to the nearest 16384 edge, but 16382 edges will be inside the calibrate window.)

 

Such a design would even tolerate a hopping Xtal  ;)  (but need permanent GPS connection) !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIW, this project has morphed into a separate, standalone project to make a GPS disciplined OCXO.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very nice!

 

Keep this thread posted with updates if you like ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nsayer wrote:

FWIW, this project has morphed into a separate, standalone project to make a GPS disciplined OCXO.

 

Looks good, - why use a separate DAC instead of choosing a AVR with DAC inbuilt ?.

XMega8E5 looks a good fit ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

 

nsayer wrote:

 

FWIW, this project has morphed into a separate, standalone project to make a GPS disciplined OCXO.

 

 

 

Looks good, - why use a separate DAC instead of choosing a AVR with DAC inbuilt ?.

XMega8E5 looks a good fit ?

 

Mostly inertia. I've worked with the 328 a lot before. And in this case, the two big-ticket parts add up to around $80, so I don't want to do too much back-and-forth. The separate DAC and chopper amp are also what are in Connor Winfield's application note. I'm just swapping a very slightly different DAC (5v 18 bits -> 3.3v 16 bits) from the same family.

 

I may wind up downgrading to the ATTiny4313, since it has hardware serial and input capture - the two basic facilities I need for this. But I want to get at least a prototype working first.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, this is going to wind up being a thing on my Tindie store. $200 will buy you a 10 MHz reference clock generator that will maintain ±1 ppb versus GPS. The final production boards should arrive towards the middle of next week, and then it will go live on Tindie.