[time-nuts] Trimble Mini-T Timing Glitches

[jimlux]

On 11/30/17 1:31 PM, Leo Bodnar wrote:
> Bob, this is quite an unorthodox description of how GPS works.
> You probably want to rephrase that before it gets ripped to shreds.
> Leo
> 
> From: Bob kb8tq <kb8tq at n1k.org>
>> GPS extracts time and location by locking on to various codes in the transmissions.
> One of them happens to run at about a 1 KHz clock rate. A slip on that part of the
> process gives you a (modulo) 1 ms clock jump. Certain types of interference may
> “help” the receiver make these sorts of mistakes.

I thought it was fairly accurate - the primary thing from which you get 
your time reference is the C/A code epoch, which is a 1 millisecond sort 
of thing.  The Nav message is on top of that at 50 bps, but "GPS time" 
is reckoned in "weeks and milliseconds of week"  (e.g. that's what you 
get out of a variety of small Novatel single board receivers).

So a lot of receivers have a basic "cycle" that runs at the epoch rate.
To generate a 1pps, you take your current nav solution to figure out how 
far from the "epoch time for spacecraft #N" the "top of the second" is 
at, and then jam that into a counter of some sort that delays the epoch 
timing signal some number of clock ticks until the 1pps gets generated.

I suppose you could have some fancy system that takes the 1kHz ticks 
from ALL currently tracked satellites, and forms some sort of average to 
generate the 1pps signal.

But it's easier to take the "PN epoch sync" line, delay it by some 
number of processor clocks, and generate the 1pps.  Pick the strongest 
signal, since the epoch sync is probably "best".

It's also likely that the "epoch sync" is latched by the processor clock 
- hence hanging bridges, etc.

And all sorts of implementation idiosyncracies could confuse the "1pps 
logic" into putting the wrong delay count in.

BTW, it could well be a multimillisecond delay from "epoch sync" to 
"1pps"   For the purposes of illustration, let's say the range to the SV 
can vary by +/- 10,000km  - that's 30 milliseconds light time.

So I could be tracking SV1 at the horizon, calculate my delay, and then 
hiccup and now track SV2, directly overhead, but use the delay from SV1 
(until the next 1pps cycle comes around).