[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gpsd never updates ntpd shm due device->fixcnt == 0

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!

Attachment: gpsd.log.gz
Description: GNU Zip compressed data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]