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

[Greg Troxel]

Sanjeev Gupta <address@hidden> writes:

> On Wed, Nov 6, 2013 at 8:20 PM, Greg Troxel <address@hidden> wrote:
>
>> As I read your instructions, they seem to be about measuring the
>> *difference* between the pps signal and the timecode signal.
>>
>
> Yes, please.  I believe we have to assume the 1PPS is on-time.  We need to
> measure the offset from _somewhere_.  I am not clear how we would measure,
> absent scopes, the delay in the 1PPS.

You may have to make assumptions.   But the document should not silently
make them, and should be clear.

> There are some corrections we can do for the length of the cable, but this
> will be on the nS scale.

True; it's more about interrupt latency.

> I started off using the term "message-decoded time" from the gpsd web page
> (see: http://gpsd.berlios.de/gpsd.html ).  How would I refer to the NMEA or
> similarly reported GPS solution?

message-decoded time is ok.  The point is that the measurement is the
value of the system clock when some aspect of a navigation solution
message arrives, with a fudge.

>>    +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.
>>
>
> On my system, I see, using Andy's script, a value close to the 0.32 I
> used.  But in my case, there is a rather long cable between the GPS (at the
> window), and the server (in the Data Centre).  I estimate about 9m.

9m of antenna does not account for much in the millisecond world.

So are you saying that the timecode-based signal is ahead of the pps?  I
wonder if it should be 0.680s instead of -0.320s.

> If we include typical values, people (like me) would start using them,
> irrespectiove of the fact that my firmware might be different to yours,
> etc.

That's bad logic.  A table of typical values is a clue to people that if
their values are wildly off, they may have made a blunder.  It's not
reasonable to avoid giving typicals because of fear that someone else
will do something silly.

> Different question, after the last month's activity on the list: Is there a
> use case for gpsd apart from NTP?

The other use case is for doing studies on software engineering
sociology, and what happens to projects when the rate of breaking the
code is so high that everyone else gives up :-)

pgpJsz9oFHltA.pgp
Description: PGP signature