Suitable GPS for GPSDO OCXO

[cdev]

I really had never looked into this much until recently and it appears to me now that there really is no silver bullet that allows you to turn a piece of cheap silicon (a cheap DDS, for example) into a stable dial in your frequency VFO or frequency standard, yet.

[edpalmer42]

Here are a few links that talk about input signal conditioning, amongst other things.

http://www.wenzel.com/library1.htm and http://www.techlib.com/ .  Wenzel makes some of the lowest phase noise oscillators available.  Charles Wenzel likes to tinker with stuff and actually tell you about it!  techlib.com is his personal tinkerer site.  He even has a GPSDO.  No performance data, unfortunately.

http://www.ko4bb.com/getsimple/index.php?id=timing .  On a good day I can understand maybe 30% of the stuff Bruce Griffiths shares on Time-Nuts.     while going downhill     with a tailwind.   

http://www.ham-radio.com/sbms/LPRO-101.pdf .  This document includes a section on interfacing the LPRO-101 Rb Standard sine wave output to digital systems.  They include schematics and phase noise test results.

Ed

[pigrew]

Do the cheap Trimble units have any signals, such as 10 KHz, 1 MHz, etc. that might be useful for a GPSDO (besides the timing pulse)?

I was playing with the Trimble Lassen LP this afternoon and managed to implement reasonable sawtooth correction! The trick is to figure out its oscillator bias (ppm). The value can be calculated from the clock bias rate returned by the 0x56 or 0x54 packets. Dividing that value by the speed of light (defined as 299792458) will get the oscillator frequency bias away from 12.504 MHz.

Knowing that, I reverse-engineered the quantization algorithm and was able to remove the sawtoothness (it'll probably eventually have a tooth, but I've not seen one in half an hour of data). Another interesting thing was that it outputs only on every fourth clock cycle (quantized to around 320ns periods).

The board can be run in over-determined/stationary mode, though I'm not sure if that'll help so much.

I was able to hand-discipline my Racal 1992 counter (with 4E oven) using the Lassen LP module (and a signal generator doing clock division) to be about +1ppb above 10 MHz. Too bad the oscillator's tempco is 0.6ppb/C, so it will drift.

I'm using one of the GPS-TMG-26N antennas from eBay (the manual suggested about +26 dB gain) from the upstairs of my house. It has a lock on 5-6 satellites.

But, I'm not sure that I'll end up making a GPSDO with it. Currently, I have no need for better than 0.5 ppm frequency accuracy (to tune BlueTooth transceivers). Also, for the few dollars more that a timing-quality board costs, the timing board would be worth it.

Another caveat for these boards is that the header is 2mm pitch (not 0.1in), so I'm having to get new jumper cables for it. I'm using the "Trimble VTS 2.3.12" software to configure the board.

[metrologist]

Thanks for sharing. Hopefully I can eventually understand some of that. I got my boards today and have tested three of them for basic communication and a lock.

I am interfacing with a ch340G serial-USB (3.3v) and could not get PuTTy to decipher the data. I launched Lady Heather and it recognized a TSIP receiver, with is listed as a Trimble, but it too does not decipher any of the data.

I noticed the serial data is inverted so I guess I need to invert that, but it's puzzling how Lady Heather identified the receiver type but does not detect serial stream.

I finally found Trimble VTS and that is communicating, tracking 3 SVs.

[pigrew]

Thanks for sharing. Hopefully I can eventually understand some of that. I got my boards today and have tested three of them for basic communication and a lock.

I am interfacing with a ch340G serial-USB (3.3v) and could not get PuTTy to decipher the data. I launched Lady Heather and it recognized a TSIP receiver, with is listed as a Trimble, but it too does not decipher any of the data.

I noticed the serial data is inverted so I guess I need to invert that, but it's puzzling how Lady Heather identified the receiver type but does not detect serial stream.

I finally found Trimble VTS and that is communicating, tracking 3 SVs.

I've only tested one of the boards I got. It doesn't make sense for me to have multiple boards in operation (as I want different instruments frequency locked to eachother), and the cost of extra GPS antennae or splitters/LNA. I bought five boards, but it only came with three MCX->SMA pigtails.

I'm using a "FT232RL" (probably a counterfeit) USB serial converter from Amazon, using its default EEPROM configuration (and setting 9600-8N1). By default, the board outputs in binary TSIP, so you putty won't help you unless you change its output format to ASCII or NMEA. I also found that Lady Heather could detect that it was TSIP, but wouldn't display anything on the screen. It looks like one can apply to be able to download Trimble's SDK, but instead of that I implemented a parser in C# (and used that for my sawtooth correction).

After a few days, my counterSDG2042X is about 5 ppb offset. I'm attaching some figures. The sawtooth correction works for at least three hours without creating any teeth. (I did set a maximum offset for the correction, so that the corrected value can't drift too far from reality). EDIT: Ooops, my SDG2042X had defaulted to its internal reference, so the reference clock is the TCXO in it, instead of the counter's OCXO.

[metrologist]

I was fortunate to find a 12 pin dual line to single header connector cable. I will probably cut it in half so I can wire up two units. I just used wire stuck into the other end to attach to my breadboard. I did not get the satellite data to show like yours. Will try to post a pic later tonight.

5 boards one pigtail   

[cdev]

Not GPSDO related.. but interesting..   the longer it churns in one place, the tighter the circle of dots gets..  This is not my expensive GPS, this is my $6 GPS.

It's got a stable fix and its circle of uncertainty is only a few centimeters. This is not RTK, its regular GPS with the benefit of two sats from Beidou.

Using a passive antenna.

[cdev]

Most GPSs have different presets that go all the way from what timing GPSs do, position pinning, all the way to what you want on an RTK GPS, which is no pinning at all. This GPS is currently in "auto" mode which means that once the circle of solutions gets very small it seems to pick one location and stay there. But if I move the gps an inch or two it registers the change. For example, I had the GPS sitting in front of my monitor with its plank that I have it and my el-cheapo USB logic analyzer and a small USB hub taped to. So in order to have some room I moved it to the bench near the window. Roughly a meter away, and my arm described an arc with the GPS as I was moving it. The track faithfully captured that arc and accurately estimated the difference between the two points. How much did the track say I moved it away? 140 cm actually, looking back at the log. Measuring it thats what the distance is. This is indoors with no special equipment, using its default settings, (except that I turned off power saving mode) There is an old CD taped to the board under the GPS antenna to act as a ground plane.

[cdev]

The PPS also has to be emitted on a clock cycle. In the case of Skytraq its the Leon 3  CPU clock cycle.  But its internal clock is much higher than, say an Arduino. Its I think 80 or 100 MHz.

By discipling a Raspberry Pi computers clock thats running NTP it also gives the computer an accurate enough idea of time to make an accurate frequency generator possible with its GPIO pins.

[pigrew]

I ran the Lassen LP PPS input versus a Racal 4E OCXO for 7 hours, and have tried to plot the results.

The deviation of the sawtooth-corrected signal and the raw data is less than 20 ns after 7 hours, so I have to say that sawtooth correction is very doable, even with non-"timing grade" ancient GPS units.

I was playing around with the TimeLab software to look at the results. As sawtooth-ness is kinda-Gaussian, I think it'd make sense to look at the modified Allan deviations. I think that this implies you need to average over perhaps 6000 seconds to get rid of the sawtooth-ness without doing proper correction? Or should I look at the modified plot to get the averaging constant needed?

I don't really know if this is a good or a bad result. It's at least not too-bad, especially for a non-temperature controlled residential room with air conditioning. ADDENDUM: The measured time intervals are only 1ns resolution, so that might cause the plots to look bad. Perhaps averaging data could help (but would remove the higher-frequency analysis)? Also, I expect the GPS PPS is what's causing the deviation, not so much the OCXO.

Another aspect to building a GPSDO is temperature-correction. Especially during holdover, but I guess always, there should be some sort of temperature input, which can correct the oscillator before the GPS detects the change? Or not? I know that temperature-correction is often done during holdover, but personally I'm not so interested in accuracy during holdover, or maintaining time..

How does it "know" that it should refine the fix to a tighter estimated position due to being stationary?  Because you put it in "stationary" / timing mode?  Or it is just smart enough to realize that it probably hasn't been moving so that it should lend more weight to the longer term averaged static central position being accurate and the variables being the timing and propagation rather than motion?

I suppose DGPS data could also help it do that though I'm not clear on why that would "take a while" (more than the first 20 minutes to warm up and download the almanac etc.) to kick in to full effect.

The Lassen LP has a static filter, that engages when it's not moving much.

From the manual:

The Position-Velocity (PV) Filter is the main filter and is used to “soften” the effect of
constellation switches on position fixes. The filter has no effect on velocity output and
there is no lag due to vehicle dynamics. There may be a small increase in accuracy
however.
A feature of the PV filter is the “Static Filter” which engages when the receiver is moving
very slowly. This feature improves accuracy in the urban environment. The static filter
should be turned off for the following applications:
• Slow-moving environments such as walking or drifting with the current
• When rooftop testing of receivers for moving applications

The altitude filter is a simple averaging filter with a time constant of a few seconds. It
should be left on in marine and land applications.

[metrologist]

I'm going to need a better antenna and put it outside as it keeps loosing lock. It does OK for a few minutes, then corrects. The trace persists for 20 samples.

[metrologist]

I haven't been able to configure Timing Receiver Mode (Failed to execute: Mode 0, State 5). I've had it set to auto 2D/3D, but setting to O-D Clk Timing Mode doesn't seem to matter much.

Lassen is top trace, bottom is loose OCXO, middle is another GPS reference. Is that +/-100ns jitter or looks like hunting to me.

[pigrew]

I haven't been able to configure Timing Receiver Mode (Failed to execute: Mode 0, State 5). I've had it set to auto 2D/3D, but setting to O-D Clk Timing Mode doesn't seem to matter much.

The timing mode is only available on the timing receivers (such as the Resolution T/SMT). It adds two main things, the first is an auto-survey mode where it averages a few thousand position fixes, and then puts the GPS in a special fixed-position mode. But, I think that this can be emulated by a micro with the non-timing receivers. The second is that it can output the quantization error of the PPS edge.

I've been thinking about the uncertainty of the PPS signal. There's the +/- offset due to quantization, but the manual seems to say that there's still a ?=15 ns accuracy, which seems to be a similar level to the quantization of the timing receivers (Resolution T/SMT/uBlox). (Although, uBlox published data on their LEA-6T which indicated that they were able to measure with a  ?=6.7 ns. )

Building a GPSDO, I'm anticipating using a microcontroller's counter unit for timing. Perhaps the Tiva TM4C123GXL or a Cypress PSoC 5 would do well. Both have 80 MHz clock frequencies, so they should be able to measure timing with ~15ns resolution. Perhaps this is good enough, since the PPS signal is likely about as accurate. The other option is to use a CPLD/FPGA, with the advantage that it could run ~250 MHz, for ~4 ns resolution. Yes, this is better, but I'm not sure it is really worth it due to the accuracy of the GPS timing itself.

I think that it would be a big advantage to use uBlox GPS modules, do to their ability to output higher frequencies, which would allow quantization noise to be averaged out. I'm not sure exactly what the proper math is, but wanting an output accurate to approx 10^-13 (reasonable based on published Allan deviation plots?), we'd need to have (1.5e-9 / 10^-13 = 15000 sec = 4.2 hour) time constants?  This seems too long (as I'd expect environmental factors to vary on the order of minutes). However, extrapolating the uBlox data, we'd only expect an Allan deviation of around 2*10^-12 at 15000 seconds.

So, is this why we need a GPS-disciplined rubidium-disciplined crystal-oscillator?