gpsd-dev
[Top][All Lists]
Advanced

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

Re: gpsd g10de777bb vs Jackson Labs Micro JLT


From: Gary E. Miller
Subject: Re: gpsd g10de777bb vs Jackson Labs Micro JLT
Date: Wed, 11 Aug 2021 19:04:36 -0700

Yo Daniel!

On Thu, 12 Aug 2021 11:06:12 +0930
"Daniel O'Connor" <darius@dons.net.au> wrote:

> > Cool.  What version gpsd?  From where?  
> 
> As per the subject, g10de777bb (I cloned it fresh yesterday)

I did not recognize that as a partial version number.

> >> Mostly it seems to work, however I was getting log messages like
> >> so: gpsd:WARN: cycle-start detector failed.
> >> gpsd:INFO: Sats used (0):  
> > 
> > Yes, normal.
> >   
> >> .. until I enabled GSA messages.  
> > 
> > Yes, normal.  
> 
> OK, perhaps a FAQ entry about what it means would be useful then.

Feel free to submit a sample FAQ entry.

> >> $PJLTS,0.28,1.48,68218,6,2.5828650,86.0955,1.1E-12,0,16,0x0*5E  
> > 
> > Got any doc you can share on that one?  
> 
> It's documented in the MicroJLT user manual:
> http://www.jackson-labs.com/assets/uploads/main/Micro-JLT_User_Manual_v1.2.pdf

Perfect.  Thanks!

> It is head line stats about the clock management/health.

Some people get annoyed that gpsd does not document every possible NMEA...

$PGLVT might interst some poepl too.

> > No idea on that.  To debug I need the output of:
> > 
> >        gpspipe -R -x 20 > raw.log  
> 
> OK attached.

Looks good, but odd.  gpsd force u-blox into binary mode, but that is
only NMEA?

When I run it past gpsdecode I can see the bad JSON:

$ gpsdecode < raw.log
[...]
{"class":"SKY","device":"stdin","vdop":0.00,"hdop":0.00,"pdop":0.00,"nSat":8,"uSat":3,"satellites":[{"PRN":501,"el":26.0,"az":315.0,"ss":40.0,"used":false,"gnssid":2,"svid":201},{"PRN":504,"el":9.0,"az":225.0,"ss":37.0,"used":false,"gnssid":2,"svid":204},{"PRN":507,"el":12.0,"az":45.0,"ss":33.0,"used":false,"gnssid":2,"svid":207},{"PRN":518,"el":23.0,"az":75.0,"ss":41.0,"used":false,"gnssid":2,"svid":218},{"PRN":319,"el":66.0,"az":223.0,"ss":39.0,"used":true,"gnssid":2,"svid":19},{"PRN":320,"el":0.0,"az":0.0,"ss":35.0,"used":false,"gnssid":2,"svid":20},{"PRN":321,"el":78.0,"az":312.0,"ss":43.0,"used":true,"gnssid":2,"svid":21},{"PRN":327,"el":46.0,"az":137.0,"ss":40.0,"used":true,"gnssid":2,"svid":27}]}

An svid of 201 is very illegal.  So should be easy to find.

It came from this:

$GAGSV,2,1,08,301,26,315,40,304,9,225,37,307,12,45,33,318,23,75,41*53
$GAGSV,2,2,08,319,66,223,39,320,0,0,35,321,78,312,43,327,46,137,40*58

Which is a usage of GAGSV that gpsd have never seen and is not compliant
with wgat I think I know about NMEA 4.10.  But, of course, I do not
have the actual standard.

Since it so clearly conflicts with how other vendors use it, it should be
not hard to code it as a quirk.

You may wish to report to JL their non-standard message construction.

IMHO, it is a bug.

But I'm chasing an annoying u-blox 7 bug today.

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

Attachment: pgpNQihPbZYQy.pgp
Description: OpenPGP digital signature


reply via email to

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