[time-nuts] Common-View GPS Network

Magnus Danielson magnus at rubidium.dyndns.org
Tue Apr 16 18:44:29 EDT 2013


Hi Tom,

On 04/16/2013 09:42 AM, Tom Van Baak wrote:
>> I wonder if one should only measure the PPS thought. Looking directly at
>> the clock could help to separate the clock drift and the time, even if
>> you get sufficient clues from the PPS and sawtooth correction.
>>
>> Cheers,
>> Magnus
>
> I've never tried that.

Tom, you scare me some times, this is one of them... or the time actually.

> Start with checking the ADEV of the LO. I always assumed the 1PPS was
> pre-compensated for instantaneous LO offset and rate, as calculated
> during the previous second(s).

Well, it is... but it also solves the position-time each second and that 
takes over. If you loose signal, that's when the predicted PPSes will 
shine through.

> If so and ADEV(1 s) is less than 1e-9 then the 1PPS + sawtooth will
> have sufficient accuracy for your needs. Message @@Ha contains the
> oscillator and clock parameters.

True. That get's you far. Just looking at that and bring it into your 
model is also something you can do. It's interesting to notice that the 
@@Ha message has a time (to nanosecond), and then clock bias and 
oscillator offset and on top of that a delta correction in the @@Hn 
message. Would be nice to know exactly how them all fitted together.

BTW. I hooked up my M12M-T to a Novatel 700 pinwheel just to check it 
out again.

> As you know professional receivers bypass this issue because they take an external LO (e.g., Rb, Cs, HM).

Oh yes.

The TCXO sitting there looks like a RAKON thing, I haven't looked at the 
details, but maybe it can be steered? It's interesting that the TCXO 
temperature can be read out.

> When you look at the actual clock solutions (which are in the @@Hn
> message) you will be surprised at the variance. At the per-SV
> per-second level it is not uncommon to see errors of many ns, even
> tens of ns. But when you average up to 12 SV together every second
> for 600 seconds then you start to see something trustable. You can
> see first hand why GPSDO need long time-constants.
>
> Here's a one second sample of a single Hn message:
>
> @@Hn: sigma 36 sawtooth 10 0 0 00000000 mean frac 861564.000 (0.000)
> ch  0 sv  6 frac 0.000861576 s = mean +   12 ns
> ch  1 sv  5 frac 0.000861586 s = mean +   22 ns
> ch  2 sv 10 frac 0.000861581 s = mean +   17 ns
> ch  3 sv 19 frac 0.000861573 s = mean +    9 ns
> ch  5 sv 13 frac 0.000861571 s = mean +    7 ns
> ch  6 sv 26 frac 0.000019831
> ch  7 sv 28 frac 0.000861555 s = mean +   -8 ns
> ch  8 sv  7 frac 0.000861548 s = mean +  -15 ns
> ch  9 sv  3 frac 0.000861571 s = mean +    7 ns
> ch 10 sv  8 frac 0.000861546 s = mean +  -17 ns

The urge to get into the dirty details got higher by that. Curious at 
seeing a log of data.

Let's see if my M12M-T locks up in the current quick-hack setup.

Cheers,
Magnus


More information about the time-nuts mailing list