|
From: | Nick Taylor |
Subject: | Re: NTP via tcp NMEA feed |
Date: | Tue, 18 Oct 2022 10:40:59 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 |
Yo Gary
We tried this but think it's SOURCE_TCP that we need to comment out - when we tried this Bingo - the ntp feed leapt into action :DThanks. The side-by-side let me track it down to ntpshm_link_activate() gpsd/timehint.c Here is the code: /* don't talk to NTP when we're: * reading from a file * reading from a pipe * reading from a remote gpsd * running inside the test harness (PTY) * over TCP or UDP */ if (SOURCE_BLOCKDEV == session->sourcetype || SOURCE_GPSD == session->sourcetype || SOURCE_PIPE == session->sourcetype || SOURCE_PTY == session->sourcetype || SOURCE_TCP == session->sourcetype || SOURCE_UDP == session->sourcetype) { return; } I'll need to think about it, but I think if I remove the SOURCE_GPSD line, that may do the trick. Any gpsd feed should be sorta real-time, and if the NTP is setup correctly, bad time should be ignored. You can try removing that line to see if it works for you.
{"class":"SKY","device":"tcp://192.168.2.53:2948","gdop":2.19,"hdop":0.82,"pdop":1.13,"tdop":0.97,"xdop":0.77,"ydop":0.94,"vdop":0.81} {"class":"SKY","device":"tcp://192.168.2.53:2948","gdop":2.19,"hdop":0.82,"pdop":1.16,"tdop":0.97,"xdop":0.77,"ydop":0.94,"vdop":0.82} {"class":"TPV","device":"tcp://192.168.2.53:2948","mode":3,"time":"2022-10-18T09:34:57.000Z","ept":0.005,"lat":51.615445000,"lon":-0.185200000,"a ltHAE":134.4000,"altMSL":87.4000,"alt":87.4000,"epx":11.529,"epy":14.115,"epv":18.630,"track":269.9500,"magtrack":269.7552,"magvar":-0.2,"speed": 0.000,"climb":-0.300,"eps":28.23,"epc":37.26,"geoidSep":47.000,"eph":15.580,"sep":21.470} {"class":"TPV","device":"tcp://192.168.2.53:2948","mode":3,"time":"2022-10-18T09:34:57.000Z","ept":0.005,"lat":51.615445000,"lon":-0.185200000,"a ltHAE":134.4000,"altMSL":87.4000,"alt":87.4000,"epx":11.529,"epy":14.115,"epv":18.630,"track":269.9500,"magtrack":269.7552,"magvar":-0.2,"speed": 0.000,"climb":-0.300,"eps":28.23,"epc":37.26,"geoidSep":47.000,"eph":15.580,"sep":21.470} {"class":"GST","device":"tcp://192.168.2.53:2948","time":"2022-10-18T09:34:57.000Z","rms":6.000,"major":6.600,"minor":4.900,"orient":8.100,"lat":
root@TSB-318:~# 0,"alt":19.000} root@TSB-318:~# ntpshmmon ntpshmmon: version 3.24.1~dev# Name Seen@ Clock Real L Prc sample NTP0 1666085700.560731338 1666085700.282002871 1666085700.000000000 0 -1 sample NTP0 1666085701.279284035 1666085701.279007496 1666085701.000000000 0 -1 sample NTP0 1666085702.295479156 1666085702.295104035 1666085702.000000000 0 -1
Many thanks Gary - I look forward to progress on the tcp feed resilience issue - in the meantime we have implemented a gps watchdog to restart feed if nothing seen using gpspipe -r, but it feels like a bit of a cludge.
Nick
[Prev in Thread] | Current Thread | [Next in Thread] |