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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
