[time-nuts] Re: Using aliasing of reference clock to PPS to determine phase offset.

[Erik Kaashoek]

David,

With tools like Octave it is doable to create a correct simulation of a 
GPSDO that includes PPS jitter, oscillator instability , DAC resolution, 
PPS time measurement resolution, PIÂ  parameters and other system 
limitations.
This allows you to very quickly test different HW designs.
For a GPSDO I build I measured the oscillator instability and the PPS 
jitter during a 6 hours period and used that for the simulation.
Attached the output of this simulated GPSDO including Kalman filter

You can also find a complete implementation of such a simulation at 
http://www.leapsecond.com/pages/gpsdo-sim/
The page includes actual measured PPS and oscillator data so you don't 
even have to measure something to start with your HW design.

Some practical data
Without sawtooth correction and a cheap GPS module you can expect around 
20 ns jitter on the PPS.
Modern MCU with 200 MHz internal clock and fast timers allow measuring 
the PPS event with 5 ns resolution.
In practice, adding an interpolator (TDC or Lars analog variant) when 
using a cheap GPS without sawtooth correction won't make any difference.
Erik.

On 25-7-2024 13:36, Magnus Danielson via time-nuts wrote:
> Hi David,
>
> On 2024-07-25 06:29, David Cureton via time-nuts wrote:
>> Hi Time-nuts
>>
>> I have been considering building a GPS-DSO by running a 
>> microprocessor off a 10Mhz OCXO and using the GPS PPS from capture 
>> the timer counter running at 10Mhz.
>>
>> In a perfectly timed world each counter capture would have 10e6 
>> counts on each capture of the timer which gives me frequency lock by 
>> I have no idea about phase of the reference clock with respect to the 
>> PPS.
>>
>> So I would have ambiguity of synchronisation of around 1uS based on a 
>> 10Mhz reference.
>
> With 10 MHz you get 100 ns steps. 10e6 is really 1e7, so you get 1e-7 
> for period, thus 100 ns.
>
> The trouble you will have is that if you have an 10 MHz oscillator of 
> say +/- 10 ppm, then you have +/- 100 Hz and you will not know which 
> of those 1 Hz bins you ended up with just sampling it like that. 
> However, there is a fairly simple remedy for this. By dividing the 10 
> MHz by say 200, the +/- 10 ppm on that now 50 kHz ends up having a +/- 
> 0.5 Hz which is within the propper capture range of the PPS. As 
> side-consequence of phase-locking those, the 50 kHz is now PPS aligned.
>
> If you then chooses to revert to the 10 MHz for further locking, 
> that's fine as you coarse-tuned it, but I don't think you will need to 
> do that as you get the same edge-sensitivity in practice.
>
>>
>> Two options I can see are:
>>
>> 1) increase the counter clock to 100Mhz to reduce the ambiguity by 10
> You could use TIC-chips or other interpolation solutions to get even 
> higher time-stamp accuracies. See TAPR TICC for instance.
>> 2) Discipline the reference clock to be a non-integer multiple of the 
>> PPS and use aliasing to determine the phase of the reference clock 
>> with respect to the phase of the GPS pps signal .
>>
>> i.e if I discipline the reference clock to be 10.0000005Mhz (10Mhz 
>> plus 0.5Hz) then the count of each clock should alternate
>>
>>
>> 10,000,000
>> 10,000,001
>>
>> if I discipline my reference clock to 10.0000001 (10Mhz plus 0.1hz) 
>> then the sample counts should be
>>
>> 10,000,000
>> 10,000,000
>> 10,000,000
>> 10,000,000
>> 10,000,000
>> 10,000,000
>> 10,000,000
>> 10,000,000
>> 10,000,000
>> 10,000,001
>>
>> Therefore on the 10th sample that has a solitary extra 1 pulse I know 
>> that the phase of the reference clock and the PPS signal are very 
>> close to each other conveying a10 times increate in the knowledge of 
>> the relative phase of each signal.
>>
>> The software disciplining can ensure that the system remain phase 
>> locked by expecting every 10th sample to have an extra count and 
>> accumulating and gently slew the reference to maintain this.
>>
>> On other GPSDO projects they go to some length to have a phase 
>> comparator to do this work, however I think this achieves the same 
>> provided the application can handle a clock that is not exactly 10Mhz
>>
>> Maybe this approach would all be swamped by phase noise of the 
>> reference oscillator and/or PPS signal.
>>
>> Any thoughts on this before I commit to testing this in hardware?
>
> You can do interpolation using frequency offset, sure you can. 
> However, that interpolation method, which actually get somewhat better 
> by the other noise and systematic effects, get's even better when 
> using an interpolator for time, that is TIC. Noise and existing 
> systematics help that solution too. You can look at the simple 
> interpolator solution of Lars that have been used by several, or that 
> of TIC chips or similar.
>
> Also consider using the correction of "saw tooth error", which is the 
> GPS/GNSS modules output of the truncation error of where it wanted to 
> put the PPS and where it could put the PPS. Within a GNSS module, you 
> have a PPS generator operating in a core clock, but even when the 
> solution has higher resolution than the clock period, the PPS is 
> output on a selected edge of the core clock. So, there will be a 
> truncation error, and many receivers output that. This allows you to 
> correct for that error on each pulse, and your time-interval measure 
> get's corrected to remove that systematic mechanism (driven by 
> systematic errors and noise).
>
> Lars made a very minimalistic interpolator for his GPSDOs. It achieved 
> about 1 ns resolution for essentially no exclusive components at all.
>
> I hope you have received some useful hints and tricks that you may not 
> have considered. Do not feel like you should not attempt what you feel 
> like and learn from, but hopefully you learn a few more things to 
> think about.
>
> Cheers,
> Magnus
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.PNG
Type: image/png
Size: 24462 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20240725/4b94b1a3/attachment.png>