The beginnings of my GPSDO project...

[alank2]

Hi Everyone,

I finally decided to try to cram it all into a Hammond 1598J enclosure, so here is a picture of what I'm planning on doing.

I've had a another couple of threads with some info:
https://www.eevblog.com/forum/projects/chassis-recommendation/msg786191/#msg786191
https://www.eevblog.com/forum/projects/what-would-you-use-relay-ssr-etc/msg784297/#msg784297

What I've done is taken the RFTG apart and shed its outer metal case - I finally gave up on trying to cool it using a secondary box or outside fan and just want a single GPSDO box with everything inside.  Most of the heat from the rubidium module is generated in its base plate so I flipped the LPRO-101 and the RFTG pcb over and am going to mount them upside down.  I found some standoffs to facilitate this for the RFTG pcb.

The LPRO-101 base plate had 6 nice threaded holes in it already so I mounted some heat sinks to it and I'm going to position the fan to pull air across them.  I'm using a TC74 i2c temperature sensor to detect the base plate temperature and plan to vary the fan RPM to attempt to keep the temperature decently consistent - I'll probably try to implement a slow changing PID loop on it that changes the fan RPM very little - I don't want to notice/hear it changing speeds all the time.  This case is a split style so I plan on getting the bottom half on my CNC and am going to cut enough 1/4" diameter holes in a grid on the underside for incoming air.

I've been managing the RFTG (you can see its status, rubidium lock state, time and frequency corrections, etc.) using really old Windows 3.1 software on a notebook, but my goal is to create a UI with the Noritake display sample I have (24x6 characters) and some input buttons in the front panel.  I will have to emulate the software, but I've had my Saleae 16 on it to decode most of how it works.  The goal is to be able to do almost everything the windows software can do, but again inside this box with its own UI.

I'm using the ublox GPS board from iteadstudio and already have an AVR program that converts its output to the motorola oncore GPS data stream that the RFTG expects.  I still need to design a new main control board to run the fan pid, control the RFTG/GPS power, and run the UI.  I am thinking of using a dedicated tiny841 AVR for the GPS data conversion and an atmega324 for the main AVR.  There are two mounting points on the upside down RFTG pcb towards the front and I'm going to mount the custom PCB to them and then plug the GPS shield on top of that.  The custom board will also generate 5V (control board, gps board, and display 1A) and 12V (fan, 500mA) using some CUI dc dc converters from the 24V DC input voltage.

Is there any good reason to have a 15 MHz or 1PPS output?  The only one that has really been important to me is the 10 MHz reference, but the RFTG board does have these other two outputs.

Any other ideas or thoughts?  I'm tired of having this project in pieces hanging over itself, my goal is to get it in one box where I can just flip it on and let it discipline itself with the GPS.

[AF6LJ]

I would bring out the 1PPS signal to a connector, it may come in handy in the future.
The 15MHZ signal I don't see much of a need for.

[Vgkid]

I was under the impression that the lpro wasnt actually disciplined by the gps module.

[alank2]

I was under the impression that the lpro wasnt actually disciplined by the gps module.

That is where the RFTG comes in.  The LPRO-101 itself just has a control voltage that can be applied to it.  The RFTG listens to the GPSDO and disciplines the LPRO by adjusting the control voltage.  In my picture, the RFTG is the green large board connected to the LPRO.

[bingo600]

+1 for 1PPS out

/Bingo

[alank2]

Let me ask you guys a question - how difficult would it be to eliminate the RFTG and make an AVR based board that disciplines the LPRO directly?  I've built an AVR frequency counter that counts every cycle before so I am familiar with how to do that.  I'd have to get a DAC to produce the control voltage for the LPRO.  I'd love to eliminate the complexity of the RFTG if I could do the job with something simplier...

[awallin]

Let me ask you guys a question - how difficult would it be to eliminate the RFTG and make an AVR based board that disciplines the LPRO directly?  I've built an AVR frequency counter that counts every cycle before so I am familiar with how to do that.  I'd have to get a DAC to produce the control voltage for the LPRO.  I'd love to eliminate the complexity of the RFTG if I could do the job with something simplier...

SRS has a graph comparing their Rb clock to GPS:
http://www.thinksrs.com/products/PRS10.htm

It makes sense to steer the Rb clock with a time-constant of about one day, and you'd want better than 1e-12 resolution for both frequency counting and the DAC that tunes the output frequency.
The PRS-10 is considered quite a good Rb clock, so the LPRO might be a bit worse, i.e. you'd have a time-constant of a few hours.

If you have naive frequency counter that just totalizes the number of rising edges at 10 MHz (1e7 edges per second) then the 'off-by-one' error is below 1e-12 for a gate time of 1e5 seconds or 1.2 days. So it looks like you'd need some better frequency-counting technique than a plain counter.
If you could run the counter at 10x of the Rb-output, i.e. 100MHz then a simple frequency counter that counts the number of edges at 100MHz you get during 1e4 edges of the GPS 1-PPS output might work...

[alank2]

The frequency counter project I had feeds the clock directly into a timer and then uses a different timer's input capture unit to timestamp it.  In this case, I could have a secondary AVR whose job it is to count the rubidium cycles vs the 1pps signal using the same technique.  It would be clocked directly with the LPRO 10 MHz output and then use its input capture unit and timer input to give the number of cycles that occurred during that second.  I've already got code that does this back to back with no signals lost, so if there is GPS jitter, I would get 10000001 followed by 9999999 the next second.  Maybe there is an IC that can do something like this more easily, I am not sure.

What I ask myself is, ok, once I have an accurate count of Rb cycles vs. GPS pps, I can determine the difference between them over time.  The question is, when is that difference worth acting upon?  How do you know if the difference is the result of some current jitter or long term difference?  I haven't put a lot of thought into it yet, but I appreciate ideas.  I remember another forum member doing something with linear regression, but I have no idea what that is or how it could help.  My thoughts were keep two clocks and when the one falls ahead or behind the other for a period of time, decide when it is enough to adjust the time of the one clock.  Time stamp that event.  Then when it happens again, you have the number of seconds between them along with the amount of the change to use to calculate a frequency adjustment.  The RFTG seemed to do something like this.

[lincoln]

If you have naive frequency counter that just totalizes the number of rising edges at 10 MHz (1e7 edges per second) then the 'off-by-one' error is below 1e-12 for a gate time of 1e5 seconds or 1.2 days. So it looks like you'd need some better frequency-counting technique than a plain counter.

Depends, Old architecture sure but there are interpolating and time stamping counters that do significantly better.

[@rt]

Since the Ublox has PPS output it might be useful for comparison with a dual channel scope (after some time)
to check the Rb based thing is actually synced with the GPS. You could probably make an alarm circuit if the two signals were ever apart.

here’s mine

[alank2]

So, I've been thinking some about how the RFTG does it and it calculates the phase error between the two signals and then takes an average of it, and when that average exceeds a threshold it will adjust the clock and make a note of when and how much the clock was altered.  Then it looks at the table of clock changes and calculates the error in frequency based on how much time was adjusted and the length of time between adjustments.  I hope all that made sense...

Let me try to detail this:

I will keep a clock for the Rb and the GPS.  Every 1PPS GPS second the Rb clock will be incremented by the number of Rb cycles that occurred.  The GPS clock always increased by 10000000, but the Rb clock might increase by 9999999, 10000000, or 10000001 depending on how many cycles were counted.

So now, each second we calculate the phase error between these two clocks by subtracting them.  To keep the GPS jitter from being a problem, we keep a ring buffer of these phase error values and calculate an average phase error from the buffer.  If the average phase error exceeds a threshold such as 100ns, then we note in a log the time this occurred.  Then make an adjustment to the Rb clock (and also the ring buffer of phase errors) for the 100ns to bring the clocks closer to each other.  When there is another entry in the table, we know how many seconds apart the two entries are and that it took that long for a 100ns difference in frequencies.  We then can adjust the frequency by 100e-9/seconds.  A 100nS difference found in 24 hours for example would be a frequency change of 1.15e-12.

Does this sound workable or does anyone see flaws in the idea?

[awallin]

Simple counting at 1s gate-time (from the GPS) would give you roughly 1e-7 frequency error for each reading. It takes a long time (and a big ring-buffer) for that to average down to 1e-12 or less (which is the resolution required for steering the Rb clock).

Here are a few links on counters, for inspiration:
https://www.febo.com/pipermail/time-nuts/attachments/20071201/e7833af5/attachment.pdf
http://www.leapsecond.com/pdf/an200.pdf
http://www.ko4bb.com/dokuwiki/doku.php?id=precision_timing:pictic

This GPSDO uses a 16s gate time and a simple counter:
http://ve2zaz.net/GPS_Std/Downloads/VE2ZAZ_GPS_Derived_Std_QEX_09_10_2006.pdf

If you have a GPS-receiver with a 10kHz output you can instead divide down the 10MHz OCXO also to 10kHz and use a PLL-chip to phase lock the two signals:
http://gpsdo.i2phd.com/

Here's one that (I think) divides down the VCO/OCXO to 1-PPS and then digitally phase-locks the 1-PPSs from VCO and GPS to eachother:
http://www.g4jnt.com/GPSLKSRC.pdf

Seems there are endless possibilities Remember to build two or preferably three identical ones so that you can do three-cornered-hat performance measurements!

[bingo600]

Here are a few links on counters, for inspiration:
https://www.febo.com/pipermail/time-nuts/attachments/20071201/e7833af5/attachment.pdf

Thanx for this one Anders

Do you have the corresponding tnut list-mail url ?

/Bingo