Re: [gpsd-dev] [PATCH 1/1] Initial draft; how to estimate time1 offset

[Greg Troxel]

There are two separate things to estimate:

  delay for the PPS siganl

  delay for the timecode-based signal

As I read your instructions, they seem to be about measuring the
*difference* between the pps signal and the timecode signal.

Also, I would avoid the word "GPS time".   GPS time refers to a
different timescale, and that's not what we are talking about.   I would
describe and use terms "pps-based offset" and "timecode-based offset" to
refer to gpsd obtaining offsets from the system clock to a pps signal
and a timecode.

  +If, for example, your estimate of the offset is 0.32s, your time1 fudge 
  +value will be '-0.32'.  Note the change of sign.

My impression is that fudge1 is added to the offset, and that for
typical timecodes (e.g. ublox binary), a fudge of around 0.110s is
normal, indicating that the timecode arrives 110 ms late, which would
produce an offset of -0.110s.

It would be nice to go through this carefully with the signs, and to
usea value that appears in practice.

It would also be nice to collect typical values.

I use 0.111s for a ublox4 (antaris) with modern i386 hardware.  This is
close enough relative to the wander of some 10s of ms.

I use 0.0025 for a Truetime XL-DC serial timecode received by ntpd on a
Sparc Classic.  Note that this timecode is documented to place a start
bit in a particular place relative to on-time, unlike navigation
timecodes.  But since this is a gpsd HOWTO, that probably should not be
included.

pgpr2Gxht5VSG.pgp
Description: PGP signature