Hi Simon !
On 07/21/13 16:47, Simon Burge wrote:
Frank Kardel wrote:
The NMEA driver has a section that checks the relation between
the time code and the PPS time stamps (refclock_ppsrelate).
This code attempts to determine if the last PPS time stamp matches
the received timecode within bounds. This code is sensible to
time1 (pps offset) and time2 (end of line offset).
If the end of line offset (default 0) is far from the true end of line
offset
this code may come to the wrong conclusions.
Maybe a short debugging session can help there - without more
information analysis is a bit elaborate here.
ntpd -d -d should shed some light on the actual
receive time stamps. These should be compensated by time2.
I have not checked whether refclock_ppsrelate is correct.
I'm not convinced that toying with time2 is the answer, as the offset
past the second is relatively random. Eg, 0.650 one time, 0.640 another
and 0.625 another. But I'll change my mind by the end of this email. :)
....
Going back to time2 - is it just a case of "get it close enough that the
PPS is valid and we'll use the PPS anyway"? I'm still concerned that
I don't see the same offset all the time so any value for time2 isn't
going to be entirely accurate.
The time stamp needs to be in a reasonable range. GPS NMEA sentences are
known to be
not terribly accurately timed (communication being the task with the
lowest priority in a GPS engine).
That's why synchronizing on NMEA sentences only is usually a futile
mission. So it just needs to be close enough,
With "fudge time2 -0.650" I get:
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.20.0 .PPS. 0 l 11 16 377 0.000 -1000.0 0.017
+192.168.0.1 27.50.90.253 3 u 30 64 177 0.491 -1.617 0.059
192.168.0.42 192.168.0.1 4 u 28 64 177 0.463 -4.895 0.096
128.184.218.53 169.254.0.1 3 u 28 64 177 22.199 -2.344 2.684
*116.66.160.39 130.234.255.83 2 u 32 64 177 18.926 -0.821 33.310
202.127.210.37 118.143.17.82 2 u 32 64 177 20.045 -0.473 30.881
so we went the wrong way, but with "fudge time2 0.650" I get:
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.20.0 .PPS. 0 l 7 16 377 0.000 -0.033 0.009
-192.168.0.1 27.50.90.253 3 u 7 64 377 0.452 -1.649 0.072
-192.168.0.42 192.168.0.1 4 u 9 64 377 0.461 -4.633 0.145
+202.191.108.73 47.187.174.51 2 u 12 64 377 26.623 -2.724 5.725
+202.60.94.15 116.66.160.39 3 u 4 64 377 40.921 -4.530 22.255
*27.54.95.11 218.100.43.70 2 u 5 64 377 53.308 -4.057 25.255
Aha - we at last seem to be on a winner!
I'll let it run overnight, but things are finally looking sane.
Cheers,
Simon.
--
...
Hope it remains stable - so far it behaves as expected (from
documentation and code) :-)
Frank
