[time-nuts] Ublox Neo-6M time error.

Michael Wouters 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
> receivers?
> 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 mailing list