Re: NTP via tcp NMEA feed

[Nick Taylor]

Yo Gary
> Thanks.  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.
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 :D

{"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