[time-nuts] Ublox Neo-6M time error.
michaeljwouters at gmail.com
Wed Jun 1 02:17:10 EDT 2016
The local clock bias value reported by the Res T is the difference between
the receiver's clock and the reference time scale ( GPS or UTC). You need
it to correct the raw pseudo ranges reported by the receiver, which are
with respect to the receiver's clock.
On Wednesday, 1 June 2016, Mark Sims <holrum at hotmail.com> wrote:
> I had two machines running Lady Heather with the singing chime clock mode
> enabled (that plays a chant from the Missa Assumpta on the quarter hours).
> One machine was connected to a Ublox Neo-6M receiver and another to a
> Z3801A. I noticed that the two machines sang their jaunty monk tunes
> offset by around one second. Since a man with two singing GPS clocks never
> knows what time it is, I replaced the Z3801A with a Jupiter-T and the two
> clocks were still out of sync. Finally I tried Motorola M12+ and UT
> receivers and the same thing happened. It looks like the Ublox time is
> ahead by a second compared to all the other receivers. I then specified a
> -1 second "rollover" correction to the Ublox machine and the two clocks
> sang in perfect harmony. Has anybody noticed such behavior with other
> BTW, note that the Ublox binary time message has a "fractional
> nanoseconds of the seconds field" (+/- 500,000 nanoseconds) correction that
> must be applied to the hrs:min:secs values (which I am doing). The
> fractional time offset forms a sawtooth with around a 120 second period.
> Attached is a GIF... white is the nanosecond fractional time offset.
> Magenta is the receiver estimate of its time error (both in nanoseconds).
> The Trimble Resolution-T receivers report a similar "local clock bias"
> value, but they don't seem to document what it actually is...
More information about the time-nuts