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

[Gary E. Miller]

Yo Aaron!

On Thu, 12 Jan 2023 04:04:09 -0800
"Aaron W. LaFramboise" <aaronaccurate2@aaronwl.com> wrote:

> 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.

That is not what your previous log showed.  It showed nothing coming
in on /dev/pps0.

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

Yes.  The GNSS receiver manufacturers tell us to do that.  It takes
a while after 3D fix for the PPS to meet specs.

> In my case, fixcnt always seems to be 0, because LATLON_SET is never 
> getting set anywhere.

That is easy to fix.  Adjst your data stream.

> My setup is a Garmin 18 LVC wired to a real RS-232 port, on Linux,
> using KPPS.

My condolences.  That is a really old receiver that never worked well.

> I haven't (knowingly) changed the Garmin from its
> default configuration.

You should.  Garmin Binary works better than Garmin NMEA.

>  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})

That is somewhat normal.  GSA has no time stamp, so impossible to know
which cycle it belongs.

> 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, 

Yes, 4,800 was always too slow for the GPS-18.  But it up to at least
9,600, or more.

> there's only a ~170ms period when RS-232 receiving isn't happening.

Yup.  That is bad.  You need to fix that.

> And the PPS pulse (on CD) fires during the middle of all of that
> receiving.

Yes, normal.  The PPS is the first thing to come from almost all
receivers at the start of an epoch.


> I mean, that seems like it should theoretically be fine,
> but obviously something isn't working here. 

Working as Garmin designed it.

> 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.

That is normal.  At that speed the receiver is just dribbling data to
gpsd, and gpsd has not choice but to dribble it out to the clients.

> I have no idea how much of this is normal, but my suspicion so far is 
> the problem is somewhere in this area.

Perfectly normal, for that dinosaur.

> It seems like gpsd should be 
> able to handle this fine,

So far, you show it does.

> and I think the setup I'm using should be
> one of the more common ones (although I really don't know).

No longer common at all.  You can buy a lot better GNSS receivers for $6.

> 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.

The Garmin sentences are alreeady minimal, you need to increase the
baud rate.

> 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.

A few things:

gpsd:INFO: launching (Version 3.24, revision 3.24)

Version 3.25 is out.  Please try that, or git head.

gpsd:WARN: WARNING: WKRO bug: leap second 18 inconsistent with 1054206052, 
corrected to 1673521252 (2023-01-12T11:00:52.000Z)

Your firmware has a GPS WEEK rollover bug.  Not good for timekeeping.

Bump the speed up, try Garmin Binary, try the newer gpsd.  Better yet,
mount that on the wall as an historical relic.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpFHojPnZlvj.pgp
Description: OpenPGP digital signature