implementing a GPSDO from scratch

[OwO]

It looks like all the off-the-shelf and DIY GPSDO solutions out there use a pulse-per-second output from an existing GPS receiver, use a bulky and expensive OCXO/TCXO (with ppb stability), and lock the OCXO to the PPS signal with a time constant on the order of hours. These can take many hours to achieve lock and don't like to be turned off.

The thinking goes like this: It is easy to recover the carrier of a GPS signal and divide it down to a lower frequency. The satellites also transmit time and precise orbit parameters regularly. From the orbit information and knowing your location it is possible to calculate exactly how much doppler you are getting at any particular time. Then if you apply the doppler correction to the frequency, it should be possible to generate a precise clock.

Is there anything wrong with this in theory? If it all checks out, I can implement this fairly easily. For example: use a carrier recovery loop to acquire the GPS signal, but instead of correcting carrier offset with DSP we will discipline the system clock instead (cheap smd vc-tcxo). Now the system clock is locked to an exact submultiple of the GPS carrier. A DDS sine generator is then fed from this clock, and we regularly correct the frequency parameter of the DDS based on calculated doppler (using the received ephemeris). The DDS should then be outputting a precise frequency?

[hamster_nz]

Yes, in theory. And you also have to allow for the clock correction.polynomial, and changing ionosphere and troposphere conditions.

[cdev]

Carrier phase GPS receivers as you know use the wavelength of the GPS signal... some of them are pretty affordable.

RTKlib works with raw data capable GNSS hardware.
GNSS-SDR, uses Gnuradio compatible HW for GNSS.

RTKlib is pretty amazing for learning GNSS, as it works in real time with all the many constantly shifting variables which all must be compensated for to get progressively more accurate position data.

Some GPSs (Navspark/Skytraq)run on processors like the LEO SPARC core. You could try posing your question to Oliver Huang at Skytraq in Taiwan!

[mark03]

This project may be relevant?    http://www.efos3.com/GPSDO/GPSDO.html

My knowledge in this area is still weak, but I have wondered if there might be a better way than using the PPS signal.  It seems such a shame to have a whole GPS receiver effectively untouchable, in a black box, where by the suboptimal design of the PPS signal we introduce a ton of jitter, then have to average it forever with a stable OCXO to get back what should never have been introduced in the first place.

[rfdave#gmail.com]

Most recent GPS modules will give you a 1PPS signal pretty quickly, doing mostly what you are proposing. Ublox modules that I've looked at will also provide a programmable DDS output frequency pretty quickly (on the order of a few minutes). Are you proposing to develop your own GPS receiver to attempt to make a 10 MHz signal appear faster from turn on? I guess I'm not sure exactly what you're proposing. You might want to think about the design details of current GPSDO's, and figure out why they use slow OCXO's instead of TCXO's. If you're trying to get frequency accuracy to the PPB level, a TCXO is unlikely to support that. they'll drift too much as things are changing in temperature to support PPB levels of accuracy.

[mark03]

No, the problem is that the 1PPS is derived from a clock which is not synchronous with the GPS carrier, so the correct 1PPS is snapped to wherever the nearest processor clock edge happens to be, hence the signal is very jittery.  Using an OCXO is still a good idea, but it would be better to have the OCXO in the GPS receiver's phase-tracking loop.

[hamster_nz]

No, the problem is that the 1PPS is derived from a clock which is not synchronous with the GPS carrier, so the correct 1PPS is snapped to wherever the nearest processor clock edge happens to be, hence the signal is very jittery.  Using an OCXO is still a good idea, but it would be better to have the OCXO in the GPS receiver's phase-tracking loop.

But there is no useful GPS carrier.

Say you lock onto a space vehicle just as it rises above the horizon. Should it then rise to being overhead it will be around 6,400km closer, or about 0.021 light seconds.

That is about 30,000,000 cycles of the carrier that is coming and going as the SV changes elevation in the sky. And also remember when you downcovert the carrier to a few MHz, this becomes a bigger problem, as 1kHz of Doppler at 1.5GHz is still be 1kHz of Doppler at 4 MHz.

On top of that, the PPS signal is only a prediction. It isn't tied back to a particular absolutes other than the local XTAL. It represents 'to the best of their abilities, all GPS modules everywhere will assert this signal at the same time'.

The designed time resolution of GPS is 15 parts per billion, so to the closest cycle of a 48 or 50 MHz clock for a low cost module seems entirely appropriate.

[mark03]

You know this better than me, so I won't argue with your basic point, but what about sawtooth correction?  Clearly the GPS receiver "knows" where the PPS edge should be, better than it is actually able to place that edge.  OTOH my understanding is that the sawtooth correction reduces total PPS jitter by a relatively small amount.

Isn't there a carrier-phase tracking loop in the receiver?  How does that work with the large amount of Doppler?

Also, I was under the impression that the Ublox M8F (?) used the architecture I was trying (poorly no doubt) to describe.  Or so someone told me once.

[OwO]

That is about 30,000,000 cycles of the carrier that is coming and going as the SV changes elevation in the sky. And also remember when you downcovert the carrier to a few MHz, this becomes a bigger problem, as 1kHz of Doppler at 1.5GHz is still be 1kHz of Doppler at 4 MHz.

We aren't downconverting the carrier, but rather locking the local crystal to a submultiple of the carrier through a carrier recovery loop (it can be a costas loop with a low bandwidth). Doppler should be viewed as a frequency scaling rather than a shift (because that's what it is: the signal is being replayed at a faster or slower rate). Then we are correcting for that doppler by using orbit data (and knowing our location already).

The problem I have with a PPS based GPSDO is that you need to lock the local oscillator over a long timeframe on the order of hours, which means you need an expensive OCXO that is stable over hours. For my application (low SNR communications) I don't care about long term stability, only stability over ~10 minutes and absolute frequency error, and most importantly cost. I need about 1ppb of frequency stability over 10 minutes, and the BOM cost should not exceed about $20.

[hamster_nz]

And given that the signal direct synthesis spread spectrum, so there is no carrier? What can you lock on to?

[OwO]

GPS is DSSS over BPSK, which means it is still a signal that can be locked on with a costas loop (if the loop bandwidth is narrow compared to the actual bit rate or information content), even without knowing the code sequence. CDMA signals are not "invisible" to someone with no knowledge of the code, contrary to popular belief.

However in practice the doppler error is large meaning a narrowband loop won't achieve lock, so the fastest way to acquire the carrier offset is to first brute force search all possible offsets while de-spreading the signal (as implemented here: http://www.aholme.co.uk/GPS/Main.htm), then once carrier offset is roughly known we can switch to a low bandwidth costas loop.

[mark03]

Another paper which might be of interest:  https://gra103.aca.ntu.edu.tw/gdoc/93/F88921021a.pdf?origin=publication_detail
"Highly accurate real-time GPS carrier-phase-disciplined oscillator"

@OwO, my interest in this is exactly the same as yours, to find a relatively cheap/simple/low-power means of ~ few ppb frequency synchronization between the ends of a radio link: in my case, the HF ionospheric channel.  The coherence time of this channel varies a lot, but a few seconds is probably optimistic.  So, e.g. a 3 ppb error at 10 MHz yields one cycle slip every 30 seconds, which is probably acceptable for symbol lengths of a few seconds.

[rfdave#gmail.com]

(I did some calculations in a google spreadsheet here https://docs.google.com/spreadsheets/d/1tvwPaO3myi9LmIDogYbf3oNIBolyRflw2EgOXPQyZds/edit?usp=sharing)

I pulled a ASTX-H12 TCXO out of Digikey, it's a +/- 2.5ppm TCXO over -30 to +75C part at $3.35 per, in the ballpark for a $20 BOM cost. Just from temperature alone, you have to keep the TCXO stable to within 0.02 C to achieve 1PPB. You've got quite a challenge doing this.

[OwO]

(I did some calculations in a google spreadsheet here https://docs.google.com/spreadsheets/d/1tvwPaO3myi9LmIDogYbf3oNIBolyRflw2EgOXPQyZds/edit?usp=sharing)

I pulled a ASTX-H12 TCXO out of Digikey, it's a +/- 2.5ppm TCXO over -30 to +75C part at $3.35 per, in the ballpark for a $20 BOM cost. Just from temperature alone, you have to keep the TCXO stable to within 0.02 C to achieve 1PPB. You've got quite a challenge doing this.

That is why we are tracking the GPS carrier in realtime (and correcting for doppler). The whole point is to avoid needing a stable (and expensive) oscillator.

[hamster_nz]

(I did some calculations in a google spreadsheet here https://docs.google.com/spreadsheets/d/1tvwPaO3myi9LmIDogYbf3oNIBolyRflw2EgOXPQyZds/edit?usp=sharing)

I pulled a ASTX-H12 TCXO out of Digikey, it's a +/- 2.5ppm TCXO over -30 to +75C part at $3.35 per, in the ballpark for a $20 BOM cost. Just from temperature alone, you have to keep the TCXO stable to within 0.02 C to achieve 1PPB. You've got quite a challenge doing this.

That is why we are tracking the GPS carrier in realtime (and correcting for doppler). The whole point is to avoid needing a stable (and expensive) oscillator.

Still interested in hearing how you can track the non-existant spread spectrum carrier, or remove the spreading code....

[Gerhard_dk4xp]

You can reconstruct the carrier with a Costas- or squaring loop.

Once you have locked to the carrier, you can demodulate the data.
You get a bit stream that looks arbitrary. But since you know the
polynomial, you can generate a local copy and correlate it to
the received stream. Timeshift the local copy until it fits.

regards,
Gerhard

[hamster_nz]

You can reconstruct the carrier with a Costas- or squaring loop.

Once you have locked to the carrier, you can demodulate the data.
You get a bit stream that looks arbitrary. But since you know the
polynomial, you can generate a local copy and correlate it to
the received stream. Timeshift the local copy until it fits.

regards,
Gerhard

You've got that a bit back to front.  There is no carrier to initially lock onto - the spreading code (pseudo-random noise) has smeared all signal out over +/- 2MHz of bandwidth (actually a bit more).

You have to first remove the spreading code to recover the carrier, and only then you can lock on the carrier with a Costas loop or similar. I would think that removing the spreading code from an analogue 1.5GHz signal without sampling or down-converting first would be challenging, esp for a <$100 project.

I've written a 'raw 1-bit ADC sample to position fix' GPS receiver so am quite familiar with the techniques - http://hackaday.io/project/20965-full-stack-gps-receiver is my project.

[mark03]

You've got that a bit back to front.  There is no carrier to initially lock onto - the spreading code (pseudo-random noise) has smeared all signal out over +/- 2MHz of bandwidth (actually a bit more).
You have to first remove the spreading code to recover the carrier, and only then you can lock on the carrier with a Costas loop or similar.

I believe the point being made above is that the DSSS signal *is* a BPSK signal.  That's all DSSS is:  a very high-data-rate BPSK signal.  The difference between the spread and despread signal is a difference in degree, not in kind.  We cannot say that one has a carrier to lock onto and the other doesn't.

Now, is it feasible for a Costas-like loop to bootstrap itself on a signal that is near or below the noise floor?  I have no idea.

The original question would really be more suitable for the time-nuts mailing list.  I would like to know the answer, though, so if you ask there, please come back here and summarize.

[hamster_nz]

You've got that a bit back to front.  There is no carrier to initially lock onto - the spreading code (pseudo-random noise) has smeared all signal out over +/- 2MHz of bandwidth (actually a bit more).
You have to first remove the spreading code to recover the carrier, and only then you can lock on the carrier with a Costas loop or similar.

I believe the point being made above is that the DSSS signal *is* a BPSK signal.  That's all DSSS is:  a very high-data-rate BPSK signal.  The difference between the spread and despread signal is a difference in degree, not in kind.  We cannot say that one has a carrier to lock onto and the other doesn't.

Now, is it feasible for a Costas-like loop to bootstrap itself on a signal that is near or below the noise floor?  I have no idea.

The original question would really be more suitable for the time-nuts mailing list.  I would like to know the answer, though, so if you ask there, please come back here and summarize.

Fully agree that the signal is BPSK at 1.023Mb/s, but that signal is about 20db below the noise floor, making it undetectable over time spans less a large fraction of a millisecond - after all, it is a 25W to cover the entire planet. As I understand it, it is only through the processing gain achieved during despreading that makes it detectable at all.

This is also the way that the whole CDMA thing allows tracking of multiple signals from the different space vehicles - if you were able to track the raw carrier, their would be maybe 12 or more signals all in the same 10kHz of bandwidth, all moving around and fighting over your attention.

[tkamiya]

What existing problem are you proposing to fix though?  GPDSO does not take hours to get a lock and start producing PPS.  Price of Oven Xtal Oscillators start from far less than 100 dollars NEW, and they are relatively small.  My understanding is, GPS signal is a wide band frequency hopping type.  It's not like you can lock on to a single frequency.

I was just playing with GPSDO.  It got 10^9 to 10^10 accuracy.  Used, I paid 50 dollars. 

We already have it SO good.  Researching something is one thing, but I think you are starting from a false statement and trying to achieve something we already have.

[Mr Simpleton]

http://lea.hamradio.si/~s53mv/navsats/theory.html
This may be handy

[thinkfat]

A couple of years back I implemented a GPS based on some TI WiLink device. The particular receiver is probably not worth considering, but I remember that among the diagnostics this engine could spit out was information about its reference clock. The receiver was able to detect the reference clock offset and stability while tracking the SVs. We used this to debug the reference oscillator, trying to decide if we could cheap out on the crystal temperature stability (not a good idea, as it turned out). I'd say, if there were receivers that are able to output similar diagnostic data, it could be used to trim the GPS reference clock and generate a 10MHz reference from that.

[awallin]

if you want to directly lock to a strong carrier then maybe try LF signals like DCF77 or similar - preferably via ground-wave (not sky-wave) - which means maybe <500km (?) or so distance to the transmitter.
https://en.wikipedia.org/wiki/Radio_clock#List_of_radio_time_signal_stations

[Gerhard_dk4xp]

You've got that a bit back to front.  There is no carrier to initially lock onto - the spreading code (pseudo-random noise) has smeared all signal out over +/- 2MHz of bandwidth (actually a bit more).

You have to first remove the spreading code to recover the carrier, and only then you can lock on the carrier with a Costas loop or similar. I would think that removing the spreading code from an analogue 1.5GHz signal without sampling or down-converting first would be challenging, esp for a <$100 project.

I've written a 'raw 1-bit ADC sample to position fix' GPS receiver so am quite familiar with the techniques - http://hackaday.io/project/20965-full-stack-gps-receiver is my project.

No, I did not get that front to back.

You can reconstruct the carrier from a BPSK signal, and you need the entire signal bandwidth to do that.
Illguided filtering only worsens the SNR. You do not need any information on the modulation, only that it is BPSK or QPSK. Don't forget that for a clean BPSK signal, there is a notch in the spectrum where you would expect the carrier.  (ed. for 50% 1/0 bits closely interspersed)

A Costas or a squaring loop can handle that. (ed. Remember that it averages over many many RF cycles.)

And no, you cannot remove the spreading code until you know the frequency where it is transmitted,
where the bit cells are and what the bits are.

BTDT, for the navigation of some European TV and some phone sats, and for the hardware for a very early combined Glonass/GPS receiver, based on the ancient Plessey 1010/1020/2010? chip set from the early monolithicum.

For a starter, get "Jack K. Holmes: Coherent Spread Spectrum Systems,  J.Wiley pub."
and / or  "Robert C. Dixon: Spread Spectrum Systems With Commercial Applications, also Wiley"