[time-nuts] Lady Heather V2.00

[Magnus Danielson]

On 01/18/2011 03:08 AM, Tom Van Baak wrote:
>> Come to think of it... it would be fun to see if there is a time-error
>> correlation on location on sky. It would help to indicate multi-path
>> errors and possibly be instructive to identify and mitigate multi-path
>> sources. Could potentially also show the difference of antenna
>> multi-path handling capabilities.
>
> Magnus,
>
> If you look at the recent plots for the cheap GPS receiver
> http://www.leapsecond.com/pages/MG1613S/
> you can see some correlation between position error and
> nsv (number of sats) or hdop (which I just added). Or if
> nothing else you see dramatic periodicity in receiver
> operation over 24 hours, as one would expect with GPS.

Actually, just sitting and watching the time-offset of my thunderbolt 
jump around using the less than optimum antenna location during position 
average prooves the point all too well to me. I have a fair idea of how 
it works out anyways.

> Most of the GPSDO we've been talking about over the years
> use a fixed time constant and the excitement and effort goes
> into characterizing what TC to select -- based on the GPS
> engine, the ADEV of the OCXO, the resolution of the phase
> comparator, the ambient temperature range, antenna quality,
> sky view quality, or other environmental factors, etc.
>
> But it seems to me this is sub-optimal. You can pick a nice
> TC for the best case to be sure. And when you loose GPS
> lock the GPSDO goes into holdover mode. The TC is at the
> heart of how much the 10 MHz output is influenced by the
> GPS receiver vs. the OCXO. In theory you slide the TC to
> 0 and all you get is a rough GPS 1PPS; you slide the TC
> to infinity and you get a fine free-running OCXO. In this
> view holdover mode is really nothing more than a temporary
> pushing of TC to a large (infinity) value.
>
> So how about running a GPSDO (e.g., TBolt) for many days
> and building up a profile of SVN, Az/El, S/N, NSV, HDOP,
> etc. and correlating any of that to timing error? You measure
> the timing error with accuracy by comparing with external
> (cesium) ref or get measure it approximately by monitoring
> the internal TIC value. Either way you get a profile of good
> times vs. bad times, good sats vs. better sats, good Az/El
> vs. poor Az/El.

Dynamically changing the TC according to the situation is indeed one of 
the tricks you can play.

Another is to learn which Az/El should be avoided and filter out 
satellites in "bad" spots (which Tbolt and many other GPSes allows) such 
that bad multipath spots is avoided... even if the signal strength is good.

If one where able to "hack-in" biases for multipath of sats according to 
their Az/El the multipath could possibly be mitigated and the sat would 
still contribute to reduction of HDOP and friends. If the receiver 
accepts DGPS corrections this would be possible to try. Hmm...

With a good recording of pseudo-ranges, orbits etc. for a sufficiently 
long time multipath, location and time error should separate right out.

You need to combat the systematic effects of multipath first, and best 
way is to do that on the pseudo-range. You need to separate the 
multipath error from the location error in order to reduce effects being 
played as individual sats acceptance and removal plays around with the 
time error outcome. I think that it could be a more fruitful solution. 
Trouble is... the T-bolt doesn't take DGPS corrections.

> You can go one step further and based on packet 0x8F-A7,
> recompute the timing residuals and thus change the weight
> of certain SVN or Az/El combinations (multipath).
>
> Then, and here's the trick -- you dynamically change the TC
> according to your profile. The TC would be shorter during those
> minutes when you had a high quality GPS fix and the TC would
> be longer during those periods of lesser quality. But the TC is
> no longer a hardcoded constant, it's completely based on past
> history or current indicators. It will vary from rather short to
> very long depending on actual live conditions.

You can achieve better performance by adapting filters, if you have an 
adequate model.

This is all heading towards Kalman filters it seems...

> Holdover would then not be a special case, it would simply be
> when the TC was made large.

Holdover is a special-case in how you recover from it.

> Furthermore, if the default TC was selected for an ideal room
> temperature but the learned/learning profile discovered that
> the temp is changing more rapidly than expected, it simply
> reduces the TC to accommodate this.

It would be one solution... another would be to trim up the D term of a 
PID style compensation. The source of that frequency error is the 
temperature input and not the GPS position/frequency error which the TC 
battles with. TC reduction due to sizeable temperature derivative would 
be possible but really the wrong medicine.

> Thus the GPSDO adapts itself to current conditions, whether
> they are SV related, or sky-view related, or environmental,
> or changes in the OCXO, or OCXO oven, etc.
>
> This is a general case of those FTS cesium standards fitted
> with accelerometers; as I understand it, when they sensed
> sudden acceleration (shock) they simply shortened the PLL
> TC so the OCXO would remain locked to the Cs signal. When
> all was settled, the TC went long again. Much better than the
> old STC/LTC (short/long time constant) switch on older 5061A.
>
> Anyway, it seems this would work on a TBolt. I'm not sure how
> many dB of stability you'd gain when all was said and done.

Tbolt has many nice twists to it, but it also lacks some features I 
really would like to see. But there is only one way to learn... hack it 
up and see what kind of performance you get.

Cheers,
Magnus