Yo Gary et al.,
My environment:
Raspberry Pi with latest Debian 13 OS trixie
ZED-F9P with FWVER=HPG 1.51, PROTVER=27.50
gpsd: 3.27.6~dev (revision release-3.27.3-9-g5f2d26a7a)
compiled without any options
ntpd ntpsec-1.2.4+54-g4c44e9293
The relevant ntpsec configuration:
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS time1 0.001203
fudge 127.127.22.0 flag3 1 flag4 1
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 refid NMEA
fudge 127.127.28.0 time1 .103511 flag4 1
About 4 days ago I add a ntrip source to the gpsd configuration. It's
running with
/usr/local/sbin/gpsd -G -n /dev/serial0 /dev/pps0
ntrip://my.usr:[email protected]:2101/TRF200AUT0
So far so good, I get RTK fix and didn't realise any site effects.
Today I see that the offset for SHM(0) / 127.127.28.0 became extremely
poor.
In the graph below you can see for SHM(0) the offset from 0h till about
1 PM without ntrip source
At around 1 PM I add a ntrip source.
It seems that the offset jumps back and forth between 2 ranges.
A look into the jitter for SHM(0) commits this.
The jitter values jump extremely up after 1 PM when I restarted gpsd
with ntrip source.
A the beginning of the day
mayer# head -120 /var/log/ntpstats/peerstats.20260114 | grep SHM | tail -10
61054 641.610 SHM(0) 941a -0.011545579 0.000000000 0.001501458 0.003056104
61054 657.610 SHM(0) 941a -0.013511712 0.000000000 0.001743558 0.003724718
61054 673.610 SHM(0) 941a -0.011463872 0.000000000 0.001872205 0.003046383
61054 689.609 SHM(0) 941a -0.012226920 0.000000000 0.001798682 0.002725481
61054 705.610 SHM(0) 941a -0.008334208 0.000000000 0.001876954 0.004220414
61054 721.610 SHM(0) 941a -0.009856451 0.000000000 0.001728806 0.003053011
61054 737.610 SHM(0) 941a -0.007290513 0.000000000 0.001636157 0.004026178
61054 753.609 SHM(0) 941a -0.014884748 0.000000000 0.001745639 0.004745938
61054 769.610 SHM(0) 941a -0.007455159 0.000000000 0.001960796 0.004428579
61054 785.610 SHM(0) 941a -0.010240581 0.000000000 0.001966306 0.002598174
At the end of the day
mayer# tail -120 /var/log/ntpstats/peerstats.20260114 | grep SHM | tail -10
61054 86241.610 SHM(0) 9414 -0.028921943 0.000000000 0.003396134 0.050148898
61054 86257.610 SHM(0) 9414 -0.028880467 0.000000000 0.002904710 0.050095580
61054 86273.610 SHM(0) 9414 -0.027661564 0.000000000 0.002576037 0.050979705
61054 86289.610 SHM(0) 9414 -0.095117619 0.000000000 0.003592998 0.050446985
61054 86305.610 SHM(0) 9414 -0.064663906 0.000000000 0.007275287 0.033842818
61054 86321.610 SHM(0) 9414 -0.093703986 0.000000000 0.005531026 0.050575686
61054 86337.609 SHM(0) 9414 -0.095680190 0.000000000 0.004272198 0.052174930
61054 86353.610 SHM(0) 9414 -0.030236024 0.000000000 0.002925653 0.044265778
61054 86369.610 SHM(0) 9414 -0.026674082 0.000000000 0.002576460 0.046905873
61054 86385.610 SHM(0) 9414 -0.027856035 0.000000000 0.002239636 0.046015693
And I am wondering, a ntrip stream should only send satellite correction
data.
So I am surprised about this effect. And of course it's not a good sign
as an time source.
part of "ntpq -pn"
remote refid st t when poll reach delay offset jitter
=======================================================================================================
oPPS(0) .PPS. 0 l 9 16
377 0.0000 0.0003 0.0007
+SHM(0) .NMEA. 0 l 6 16
377 0.0000 -64.0778 38.0202
Is there a way to avoid this and make the SHM interface stable inclusive
ntrip ?
If you need ( and probably you will need ) any additional information
then I am happy to supply it.
Kind regards
Hans
--
