0

I have a Raspberry Pi Model B Rev 2 (BCM2835 rev 000e). Connected to it is a USB G-Mouse GPS receiver - which is really just a u-blox 7 GPS receiver. I've had it running for about 15 hours now and it still reports time that is significantly off from public NTP sources. As far as I can tell, I will have to do some soldering to get PPS source working correctly, but my understanding is that GPS is what provides the time source even with PPS working - so I'm not sure what is going wrong with my setup. Currently, the GPS offset is -49.017 with public time sources being 16.591 - so there is a large gap between them.

GPSD Settings:

# /etc/default/gpsd

START_DAEMON="true"
USBAUTO="true"
DEVICES="/dev/ttyACM0"
GPSD_OPTIONS="-n"

NTP settings:

# GPS Serial data reference (NTP0)
server 127.127.28.0
fudge 127.127.28.0 time1 0.0 refid GPS

# GPS PPS reference (NTP1)
server 127.127.28.1 prefer
fudge 127.127.28.1 refid PPS

Running gpsmon - everything looks good to me. With 9 satellites at the moment.

gpsmon output

Output from ntpq -c rv -pn

associd=0 status=0418 leap_none, sync_uhf_radio, 1 event, no_sys_peer,
version="ntpd 4.2.8p12@1.3728-o (1)", processor="armv6l",
system="Linux/4.19.75+", leap=00, stratum=1, precision=-19,
rootdelay=0.000, rootdisp=3.489, refid=GPS,
reftime=e1b9c988.b348e9c2  Fri, Jan  3 2020 14:09:12.700,
clock=e1b9c9c3.22ea8839  Fri, Jan  3 2020 14:10:11.136, peer=57008, tc=6,
mintc=3, offset=-1.475171, frequency=-27.690, sys_jitter=0.000000,
clk_jitter=1.693, clk_wander=0.107, tai=37, leapsec=201701010000,
expire=202006280000

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.28.0    .GPS.            0 l   59   64  377    0.000   -1.475   1.836
 127.127.28.1    .PPS.            0 l    -   64    0    0.000    0.000   0.000

On a second device, which I have setup as an NTP client - it shows that the time is off (ntpq -c rv -pn) (192.168.4.30 is the pi with GPS):

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p10@1.3728-o Sat Mar 10 18:03:33 UTC 2018 (1)",
processor="armv7l", system="Linux/4.19.66-v7+", leap=00, stratum=3,
precision=-21, rootdelay=55.738, rootdisp=37.157, refid=107.155.79.108,
reftime=e1b9c9ab.6602a854  Fri, Jan  3 2020  9:09:47.398,
clock=e1b9ca29.2de7f8c7  Fri, Jan  3 2020  9:11:53.179, peer=19769,
tc=10, mintc=3, offset=17.376459, frequency=-1.665, sys_jitter=3.848777,
clk_jitter=28.916, clk_wander=0.076
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+192.168.4.1     69.89.207.99     2 u  140 1024  377    0.546   16.713   6.773
-192.168.4.30    .GPS.            1 u  915 1024  377    0.848  -49.017   4.665
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 0.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.pool.ntp.org  .POOL.          16 p    -   64    0    0.000    0.000   0.000
+108.61.56.35    198.30.92.2      2 u  182 1024  377   36.456   19.257   7.304
*107.155.79.108  129.7.1.66       2 u  126 1024  377   48.246   16.591   6.812
+23.31.21.163    252.74.143.178   2 u  148 1024  377   44.590   17.076   6.954
-104.236.116.147 128.59.0.245     2 u   56 1024  377   35.528   21.247   6.805
0

I'm unable to determine why the offset is so large. I'm also unsure why the PPS feature is not being exposed through the USB. After opening up the receiver, it appears to have a wire for it, but I can't read it. Also, I'm not great with electrical, so perhaps I'm also wrong.

GPS internals back

GPS internals front

Anyways, I do have a solution of sorts. After close monitoring of my GPS offset vs. several different public Stratum 1 servers, I was able to determine a consistent time1 offset value to line up my GPS time with public sources:

server 127.127.28.0 minpoll 3 maxpoll 4 prefer iburst
fudge 127.127.28.0 time1 0.070 refid GPS

I came up with the value 0.070 after a lot of monitoring. First, I ran ntpq -c rv -pn often to view the offset over several hours. You can also run watch -n 30 ntpq -c rv -pn to automatically run it every 30 seconds. This gave me nice feedback and I was able to get a close offset quickly - however, I ended up with 0.080 using this method.

For the more accurate 0.070 value, I needed more a in-depth view of the offset over the course of an entire day. I enabled stats logging by uncommenting this line (debian buster default config already has stats configured correctly, it just needs this one line to be enable to go into effect):

statsdir /var/log/ntpstats/

That will cause two types of stats to be logged, loopstats and peerstats. I let it run for an entire day without modification or rebooting. After the day was complete, I exported the logs to a windows machine and downloaded a tool called NTP Plotter. With NTP plotter, I was able to generate graphs of my GPS offset vs. the public stratum 1 servers. In the graphs, I noticed I was consistently off and changed the time1 value to 0.070. After another full day of stats I repeated the process and was pleased with the offsets:

stratum 1 vs GPS offsets

As you can see in the graph above, my GPS offset stays roughly in the center now compared with the public stratum 1 servers I was using for testing.

Again, I do not understand why I need this offset, perhaps it has to do with delays with the USB and raspberry pi. But setting the time1 value solved it and I'm pleased that I was able to use statistics over a full day to be able to make an educated decision about the time1 value instead of just trial and error. I'm marking this as the solution for now, but if anyone comes up with a better method then I would be happy to change the solution.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.