Re: [gpsd-users] Garmin 18X LVC and upcoming week rollover

[Gary E. Miller]

Yo Rich!

On Wed, 4 Dec 2019 23:59:08 -0800
Rich Wales <address@hidden> wrote:

> I enabled PGRMF (./gpsctl -x '$PGRMO,PGRMF,1' /dev/gps0); see below
> for my ./gpspipe output (including PGRMF sentences now).

Good.  And the result was?

> I'm having a difficult time forcing this GPS into binary mode, btw,
> despite several ./gpsctl -b commands and a few restarts of gpsd.

You realize every time you restart that you lose the effects of
"gpsctl -b"?

>  Is
> it truly essential here for me to use binary mode in order for gpsd to
> properly grab the leap second count that is now available via PGRMF --

Think about it a moment.  $PGRMF is not binary.  PGRMF is one way to
get the leap second.  You only need one way to get the leap second.
So you do not nee binary mode.

There are other good reasons for binary mode, but since you don't
care about them you don't need binary mode.

> i.e., am I wasting my time and everyone else's by running experiments
> in NMEA mode?

I think from the start I said that using a Garmin 18x was a waste of time.

>  Or is it simply a matter of "no need to use the clunky
> NMEA mode, binary is better"?

Not so simple, but sorta correct.

> Right now, gpsd is still ignoring the leap second count and is still
> reporting timestamps in the year 2000, even after I've enabled PGRMF.

The code to use leap secods to disambiguate GPS epoch is now.  With
your output below I can make sure it works.

> If I can be of any assistance in getting the WNRO bug well and truly
> fixed, I'm certainly happy to help

The only place the bug can be fixed is in the Garmin.  All gpsd can
do is detect the bug, with the leap second, and work around it.

> -- but if not, then I'll happily
> continue using gpsd "as is" and compensating for the problem by
> fudging the timestamp in ntpsec.

The log output is all that is needed to work on a workaround.  The
fudge works for you now.

>  You may feel I'm being unreasonably
> stubborn, but I simply and flatly refuse to throw away this GPS as
> long as I can get it to work in that manner.

We like stubborn.  It takes a while to find these nasty edge cases.

> $PGRMF,34,373447,200400,074349,18,3728.0463,N,12212.4429,W,A,2,0,0,3,2*3A

The decodes to:
34       GPS week
373447   Time of Week
200400   20 April 2000
074349   7:43:49
18       Leap seconds.

That is what gpsd needs to set the proper date.  I just need to get the
workaround code to use the $PGRMF data.


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

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

pgpgaGfer4Dgz.pgp
Description: OpenPGP digital signature