|
From: | Aaron W. LaFramboise |
Subject: | gpsd never updates ntpd shm due device->fixcnt == 0 |
Date: | Thu, 12 Jan 2023 04:04:09 -0800 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 |
Operationally, the problem I'm having is that while I see reasonable data in /dev/ttyS0, ppscheck, and gpsmon, it never makes it to ntpshmmon and ntpd. Despite shm apparently being set up correctly according to the docs, nothing ever gets printed in ntpshmmon.
I'm new to this, but it looks like to me that both cgps and gpsmon are reporting a "3D FIX" with 8 or more satellites, so I feel like we should be good to go. But the problem is there's a check, associated with --badtime, that looks like this:
} else if (NTP_MIN_FIXES >= device->fixcnt &&
false == context.batteryRTC) {
In my case, fixcnt always seems to be 0, because LATLON_SET is
never getting set anywhere.
My setup is a Garmin 18 LVC wired to a real RS-232 port, on Linux, using KPPS. I haven't (knowingly) changed the Garmin from its default configuration. So I spent a little time staring at the NMEA driver code. It isn't totally obvious what could be going wrong here, but maybe this is a clue:
gpsd:PROG: NMEA0183: GPGSA is just after a cycle ender. ({MODE|DOP|USED})
At the default 4800 baud, on the scope it looks like it spends
the majority of its time receiving NMEA; out of every 1 second
period, there's only a ~170ms period when RS-232 receiving isn't
happening. And the PPS pulse (on CD) fires during the middle of
all of that receiving. I mean, that seems like it should
theoretically be fine, but obviously something isn't working
here. The other thing that's a bit odd is that cgps flickers
between two states: one where all most of the lines between Status
are filled in normally, and where most of them are "n/a."
Basically the values alternate from reasonable numbers to "n/a,"
maybe about once a second.
I have no idea how much of this is normal, but my suspicion so far is the problem is somewhere in this area. It seems like gpsd should be able to handle this fine, and I think the setup I'm using should be one of the more common ones (although I really don't know). Before I debug any deeper, I felt like it might be a good time to ask for help. Two thoughts that came to mind were either reducing the number of sentences being sent, or increasing the baud rate. But it really doesn't seem like I should have to do that.
I've attached the debug logs from gpsd; let me know if there's anything I can provide that's helpful. I've got gpsd loaded up in GDB in debug symbols etc.
Thanks in advance; I could really use a hand!
gpsd.log.gz
Description: GNU Zip compressed data
[Prev in Thread] | Current Thread | [Next in Thread] |