Re: [time-nuts] ublox NEO-M8T improved by insulated chamber?
On 11/7/17 1:44 PM, MLewis wrote:
Yo Gary!
With a strictly SSE skyview, I still regularly get signals from sats to
my NW. When they're at the right elevation and heading, their signals
pass over me and reflect back at me from a tall building. When running
my M8T with the position unlocked, and those NW sats are getting a
reflection and reporting in, (although the reflecting building is
further away to the SE) my GPS position drifts up to 300' to my south (S
of SSE). (reported position goes for a walk, staggering across the
parking lot, wanders through a park with an occasional loop, across a
road, then sits down for a while, before wandering back)
Is it reasonable to use the 9" ~= 1 ns for:
running with a fixed & correct survey position, and NW sats reflecting a
signal to me, that 300' drift would equate to a (300' x 12") / 9" =
400, for a ballpark 400 ns error?
No.. in free space it's about a foot per nanosecond.. 9" is 0.75
velocity factor, reasonable for coax, for instance, depending on the
dielectric.
Thanks,
Michael
On 07/11/2017 3:40 PM, Gary E. Miller wrote:
Yo Lars!
On Tue, 7 Nov 2017 20:32:19 +0000
Lars Walenius lars.walenius@hotmail.com wrote:
Another question: If You have an error in the surveyed position of
say 3meters and you receive all of the available satellites in all
directions how much will this really affect your timing?
I'll oversimply a bit by repeating Adm. Grace Hoppers famous giveaway.
When asked, she handed out 9 inch long peieces of wire, and said: that
is a nanaosecond.
3m is about 118.11 inches is about 13 ns. So worst case, skipping the
3D math, yoy get about +/13 ns.
Which is small compared to the published GPS time resolution
(IS_GPS_200H,
page 54) of 90 ns.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Gary,
Which is small compared to the published GPS time resolution (IS_GPS_200H,
page 54) of 90 ns.
Correct. GPS performs far better than the original spec. Like the Mars rovers...
As a result we're now all used to ~10 ns level of performance out of GPS, even in a $5 receiver. Closer to ~1 ns is possible when you dig into the bag-of-timing-tricks like zero-D mode, sawtooth correction, antenna calibration, multi-path mitigating antennae, dual-frequency receivers, external frequency references, post-processing, temperature stabilization of antenna, cables, receiver, etc. So the industry big boys are getting sub-cm levels of positioning and sub-ns levels of timing. It's all pretty cool. Some time nuts are not far behind.
Note also that relative timing, such as needed by a GPSDO frequency standard is always much better than absolute timing, such as needed by a UTC time standard. This is because many of the unknown offsets (antenna, cable, receiver RF and f/w) magically cancel when used as a GPSDO. This is why some GPSDO can get down to parts in 10^14th frequency stability over a day.
There's a slide I remember seeing that shows how GPS timing accuracy has improved since the early days. It's page 9 (attached) of:
https://www.gps.gov/cgsic/meetings/2013/matsakis.pdf
/tvb
Yo Tom!
On Tue, 7 Nov 2017 20:16:09 -0800
"Tom Van Baak" tvb@LeapSecond.com wrote:
Which is small compared to the published GPS time resolution
(IS_GPS_200H, page 54) of 90 ns.
Correct. GPS performs far better than the original spec. Like the
Mars rovers...
Of course, but then you are on a wing and a prayer, not engineering.
As a result we're now all used to ~10 ns level of performance out of
GPS, even in a $5 receiver.
I'm sure we are not talking about the same thing here. Your talking
about GPS time? I'm talking about UTC as output from a GPS, after it
converted from GPS time.
I am NOT talking about the 'performance' of GPS. What is performance?
We talking about frequency stability, or position accuracy, or we
talking about absolute offset from USNO UTC time? I'm talking about
the later. I'm talking about the spec about how close the GPS time is
to UTC time. Your GPS converts the GPS time to UTC time depending on an
ephemeris parameter that the GPS owners say is 90 ns (one sigma).
Sure, you may get better, but when you are looking at subtle error sources
that is surely one to look at.
How exactly do you measure offset of your GPS time output to absolute
UTC time?
Closer to ~1 ns is possible when you dig
into the bag-of-timing-tricks like zero-D mode, sawtooth correction,
antenna calibration, multi-path mitigating antennae, dual-frequency
receivers, external frequency references, post-processing,
temperature stabilization of antenna, cables, receiver, etc.
Yes, of course, but NONE of that fixes the GPS to UTC offset problem.
It makes the GPS time much better, but does not solve the problem that
the GPS to UTC offset is only good to 90 ns (one sigma). Is your GPS
getting a better offset correction somewhere else? Otherwis it has NO
way to compute/calculate/devine that offset.
So the
industry big boys are getting sub-cm levels of positioning and sub-ns
levels of timing. It's all pretty cool. Some time nuts are not far
behind.
I have seen cm level precision myself. But that is unrelated to the issue
I bring up. The positioning depends on stable GPS time, and I agree GPS
time is much more stable than 90 ns. I thought the subject was UTC offsets.
Note also that relative timing, such as needed by a GPSDO frequency
standard is always much better than absolute timing, such as needed
by a UTC time standard. This is because many of the unknown offsets
(antenna, cable, receiver RF and f/w) magically cancel when used as a
GPSDO. This is why some GPSDO can get down to parts in 10^14th
frequency stability over a day.
Yes, I 100% agree, and totally unrelated to my point. Frequency stability
is only loosely correlated to absolute time accuracy. Stable !=
accurate.
There's a slide I remember seeing that shows how GPS timing accuracy
has improved since the early days. It's page 9 (attached) of:
I agree, GPS accuracy is great, but I am NOT talking about GPS timing,
I am talking about UTC timing accuracy.
I thought the problem was that the UTC time from the GPS was wandering
on a diurnal time frame. The GPS can be perfect to one hundred 9s,
the GPS position can be perfect to 100 nines, but if the transmitted
GPS time to UTC time offset is said, by the US Military, to be only 90
ns (one sigma), then I'd listen to them when it matters.
Time for us all to actually read the standard and argue what that means.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
On Tue, Nov 7, 2017 at 8:39 PM, Gary E. Miller gem@rellim.com wrote:
Yo Tom!
On Tue, 7 Nov 2017 20:16:09 -0800
"Tom Van Baak" tvb@LeapSecond.com wrote:
Which is small compared to the published GPS time resolution
(IS_GPS_200H, page 54) of 90 ns.
Correct. GPS performs far better than the original spec. Like the
Mars rovers...
Of course, but then you are on a wing and a prayer, not engineering.
As a result we're now all used to ~10 ns level of performance out of
GPS, even in a $5 receiver.
I'm sure we are not talking about the same thing here. Your talking
about GPS time? I'm talking about UTC as output from a GPS, after it
converted from GPS time.
I am NOT talking about the 'performance' of GPS. What is performance?
We talking about frequency stability, or position accuracy, or we
talking about absolute offset from USNO UTC time? I'm talking about
the later. I'm talking about the spec about how close the GPS time is
to UTC time. Your GPS converts the GPS time to UTC time depending on an
ephemeris parameter that the GPS owners say is 90 ns (one sigma).
Sure, you may get better, but when you are looking at subtle error sources
that is surely one to look at.
How exactly do you measure offset of your GPS time output to absolute
UTC time?
That was what Tom's attached plot was showing: the measured difference
from GPS system time distributed through the satellites to UTC realized
at USNO "UTC(USNO)". This is also available (only in arrears) through
the BIPM's Circular T which also give the differences 'UTC-UTC(USNO)'.
With these two sets of offsets and some interpolation (you only get values
every 5 days in the Circular T) you can back-track from GPS time to
"true" UTC but only about 1 month after the observations.
Closer to ~1 ns is possible when you dig
into the bag-of-timing-tricks like zero-D mode, sawtooth correction,
antenna calibration, multi-path mitigating antennae, dual-frequency
receivers, external frequency references, post-processing,
temperature stabilization of antenna, cables, receiver, etc.
Yes, of course, but NONE of that fixes the GPS to UTC offset problem.
It makes the GPS time much better, but does not solve the problem that
the GPS to UTC offset is only good to 90 ns (one sigma). Is your GPS
getting a better offset correction somewhere else? Otherwis it has NO
way to compute/calculate/devine that offset.
I've not read the spec, but presumably there must be a way to get better
accuracy and/or the system is being operated and kept to tighter tolerances
than the original written spec otherwise the quoted measured offsets between
GPS time and UTC(USNO), which are quoted in the Circular T to 0.1ns if
I remember right, would be vast overkill.
So the
industry big boys are getting sub-cm levels of positioning and sub-ns
levels of timing. It's all pretty cool. Some time nuts are not far
behind.
I have seen cm level precision myself. But that is unrelated to the issue
I bring up. The positioning depends on stable GPS time, and I agree GPS
time is much more stable than 90 ns. I thought the subject was UTC offsets.
Note also that relative timing, such as needed by a GPSDO frequency
standard is always much better than absolute timing, such as needed
by a UTC time standard. This is because many of the unknown offsets
(antenna, cable, receiver RF and f/w) magically cancel when used as a
GPSDO. This is why some GPSDO can get down to parts in 10^14th
frequency stability over a day.
Yes, I 100% agree, and totally unrelated to my point. Frequency stability
is only loosely correlated to absolute time accuracy. Stable !=
accurate.
There's a slide I remember seeing that shows how GPS timing accuracy
has improved since the early days. It's page 9 (attached) of:
I agree, GPS accuracy is great, but I am NOT talking about GPS timing,
I am talking about UTC timing accuracy.
I thought the problem was that the UTC time from the GPS was wandering
on a diurnal time frame. The GPS can be perfect to one hundred 9s,
the GPS position can be perfect to 100 nines, but if the transmitted
GPS time to UTC time offset is said, by the US Military, to be only 90
ns (one sigma), then I'd listen to them when it matters.
Time for us all to actually read the standard and argue what that means.
RGDS
GARY
Cheers,
Tim
Hi, Jim!
On Wed, Nov 8, 2017 at 3:12 AM, jimlux jimlux@earthlink.net wrote:
http://www.navipedia.net/index.php/Ionospheric_Delay
has a nice discussion with simple equations to turn TEC into delay, etc.
I've already skimmed this, and it requires a bit more brainpower than I can
muster for what I want to accomplish.. :) BUT! Re-reading it I got to the
page on "Combination of GNSS Measurements" - and the geometry free
combination of L1 and L2 is exactly what I was looking for; some quantity
proportional to TEC that I can correlate with the daily excursions of the
Ublox PPS. So, yeah, thanks! That gave me just what I needed! :) Now to
cobble up a RINEX parser..
You might also look into seeing if you can put your data in a form to be
processed by GIPSY at JPL - they have a service where you can upload your
raw observables and they post process it.
GIPSY solves using PPP, does it not? I already process the data with PPP
from each of the receivers using both the NRCan online service and locally
using gLAB - using one to "sanity check" the results from the other, but
I'll have another look at GIPSY.
Thanks!
On 11/7/17 8:39 PM, Gary E. Miller wrote:
Yo Tom!
On Tue, 7 Nov 2017 20:16:09 -0800
"Tom Van Baak" tvb@LeapSecond.com wrote:
Which is small compared to the published GPS time resolution
(IS_GPS_200H, page 54) of 90 ns.
Correct. GPS performs far better than the original spec. Like the
Mars rovers...
Of course, but then you are on a wing and a prayer, not engineering.
Not really - the original spec for GPS was based on being able to track
to a single chip of the PN code at 1 MHz, or about 300m position error,
and 30m for the precise code at 10MHz.
And that was the limit of the technology back in the late 70s early 80s
A fancy multichannel correlator was literally a rack of equipment, and
things like RAKE receivers to deal with multipath were the subject of
papers in IEEE transactions - hardly a "buy it at the hardware store"
What has changed, and what's sort of amazing, given that the GPS signal
hasn't really changed much is that technology has made substantial
advances, both in terms of silicon and in terms of the algorithms.
It is easy now to have a 64 simultaneous channel correlator that
trivially tracks to a fraction of a chip and also recovers the carrier
phase. Codeless receivers allow tracking of the higher rate code, and
today, a L1 only receiver is sort of a legacy oddity - perhaps because
it has some peculiarity for a particular system, or a "drive every tenth
of a penny out of the system cost" item.
Back in "30 m CEP" days who cared about the fact that the receive
antenna phase center wasn't the same for all look angles. Today, folks
go out and extensively calibrate these things, and build antennas where
the phase center is "stable" to 1 mm or better.
We've got much, much better analytical tools to process the data - folks
regularly process long collections of data from inexpensive receivers
where one has to account for things like solid earth tides, not to
mention continental drift. My house in Southern CA is steadily heading
north a few cm/year. That's actually measureable with equipment you
could reasonably buy for under $1000 (I think.. you might be able to do
it for under $100)
Yo jimlux!
On Wed, 8 Nov 2017 06:33:19 -0800
jimlux jimlux@earthlink.net wrote:
On 11/7/17 8:39 PM, Gary E. Miller wrote:
Yo Tom!
On Tue, 7 Nov 2017 20:16:09 -0800
"Tom Van Baak" tvb@LeapSecond.com wrote:
Which is small compared to the published GPS time resolution
(IS_GPS_200H, page 54) of 90 ns.
Correct. GPS performs far better than the original spec. Like the
Mars rovers...
Of course, but then you are on a wing and a prayer, not
engineering.
Not really - the original spec for GPS was based on being able to
track to a single chip of the PN code at 1 MHz, or about 300m
position error, and 30m for the precise code at 10MHz.
I agree with almost all you ssid. And none of it applies to the point I
made. I'm talking about the current GPS standard (IS-GPS-200H), nothing
dated at all. No one here has yet bothered to address the issues I raise
in Section 3.3.4. What I say about 3.3.4 is perfectly compatible with with
your arguments.
I'll be happy to discuss my interpretation of 3.3.4 and what I think it
means, when someone shows they actually read it.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
How exactly do you measure offset of your GPS time output to absolute UTC time?
Conceptually it's no different from measuring your favorite resister or thermometer: you compare your DUT against a standard REF and the difference is your error, a process called calibration. So the same is true for SI second (time interval, frequency) and UTC (time epoch). As I mentioned earlier, calibrating your SI second is quite simple. Calibrating your UTC is harder.
Here are couple examples:
(1) Years ago fellow time-nut Doug loaned out his and my antenna/receiver to be calibrated. The report will give you an idea of what's involved:
"Absolute Calibration of a Geodetic Time Transfer System"
http://xenon.colorado.edu/paperIrevise2.pdf
(2) Here's classic report from fellow time-nut Rick:
http://www.cnssys.com/files/PTTI/PTTI_2002_CNS_Testbed.pdf
and
http://www.cnssys.com/files/PTTI/Low_cost_GPS-based_time_and_frequency_products.pdf
(3) In both cases above there is transport of equipment involved. But the equipment can come to you instead:
http://www.usno.navy.mil/USNO/time/twstt/calibration-services
see also
http://tycho.usno.navy.mil/twstt.html
and a nice photo of the traveling time van:
http://tycho.usno.navy.mil/gif/2waytruck.jpg
(4) NIST also offers time & frequency calibration services:
https://www.nist.gov/calibrations/calibration-areas/time-and-frequency
"A NIST Disciplined Oscillator: Delivering UTC(NIST) to the Calibration Laboratory"
https://www.nist.gov/sites/default/files/documents/calibrations/NCSLI.pdf
"Remote Time Calibrations via the NIST Time Measurement and Analysis Service"
https://www.nist.gov/sites/default/files/documents/calibrations/Remote-Time-Calibrations.pdf
That's enough reading to keep you busy for a few days.
/tvb
On Wed, November 8, 2017 10:45 am, Gary E. Miller wrote:
No one here has yet bothered to address the issues I raise
in Section 3.3.4.
Sure they did. Why are you referencing the old version instead of the
newer version that Leo Bodner provided the link to?
https://www.gps.gov/technical/icwg/IRN-IS-200H-001+002+003_rollup.pdf
"The NAV data contains the requisite data for relating GPS time to UTC.
The accuracy of this data during the transmission interval shall be such
that it relates GPS time (maintained by the MCS of the CS) to UTC (USNO)
within 20 nanoseconds (one sigma). "
--
Chris Caudle
Yo Chris!
On Wed, 8 Nov 2017 11:47:05 -0600
"Chris Caudle" chris@chriscaudle.org wrote:
On Wed, November 8, 2017 10:45 am, Gary E. Miller wrote:
No one here has yet bothered to address the issues I raise
in Section 3.3.4.
Sure they did. Why are you referencing the old version instead of the
newer version that Leo Bodner provided the link to?
Because that was sent last night after I stopped reading email.
I knew about the errata, I left out that detail to see when someone
actually read my citation. Leo actually did, but not got to his email
yet, I read email in reverse chrono order.
What I said is correct, IS-GPS-200H is STILL the latest version of
the GPS standard. Leo's link, which I found Monday, is to a copy of
IS-GPS-200H with the errata applied. So not technically an update to
IS-GPS-200H.
"The NAV data contains the requisite data for relating GPS time to
UTC. The accuracy of this data during the transmission interval shall
be such that it relates GPS time (maintained by the MCS of the CS) to
UTC (USNO) within 20 nanoseconds (one sigma). "
So yes, UTC from a GPS is now 20 ns (one sigama). What I said about
+/- 13 ns being noise relative to the spec still applies.
Do you now see how measured GPS time/location can be very precise, but
UTC from a GPS less so? Have you read the entire 3.3.4?
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin