Re: gpsd g10de777bb vs Jackson Labs Micro JLT

[Daniel O'Connor]

> On 12 Aug 2021, at 11:34, Gary E. Miller <gem@rellim.com> wrote:
>> 
>> OK, perhaps a FAQ entry about what it means would be useful then.
> 
> Feel free to submit a sample FAQ entry.

Something along these lines under Troubleshooting:
Why isn't GPSd showing the information I expect?
- Check your GPS engine has been configured to emit suitable messages. For 
example to show which satellites are visible a NMEA speaking engine will need 
to emit 'GSV' messages and to show which ones are used it needs to emit 'GSA' 
messages.

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

Given it's a proprietary sentence I don't think it's reasonable to expect it be 
parsed.

> $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?

The protocol is a bit "neither fish-nor-fowl" but given it's primary use case 
is not to be a GPS engine I guess it's not a big surprise.

It mostly emits NMEA sentences (certainly for the ones emitted automatically) 
however you control it via SCPI like messages, it also has some oddball stats 
which aren't NMEA.

For the general case where it's not being talked to the it either emits nothing 
or whatever NMEA sentences have been enabled.

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

I don't have the spec either but FWIW the ublox docs talk about such numbers if 
it's in a particular mode.

For NMEA 2.x-4.0 (extended) it will emit 1-32 for GPS, 33-64 and 152-158 for 
SBAS, 301-336 for Galileo, 401-437 for BeiDou, 173-182 for IMES, 193-197 for 
QZSS and 65-96 for GONASS. (from Appendix A, page 394)

Unfortunately it looks like it could be quite ambiguous given gpsd doesn't know 
what mode it's in.

Given this output:
$GPGSV,4,1,15,05,20,261,40,07,37,99,41,08,15,138,34,09,18,31,40*7F
$GPGSV,4,2,15,13,37,224,43,14,75,269,45,15,9,221,38,17,30,13,41*70
$GPGSV,4,3,15,19,12,359,40,20,16,297,42,21,2,95,0,28,0,0,46*70
$GPGSV,4,4,15,30,66,150,45,41,19,291,37,50,48,340,40*42

$GAGSV,2,1,07,302,32,132,40,307,65,264,44,308,45,9,42,318,42,38,43*5A
$GAGSV,2,2,07,327,32,286,41,330,73,201,44,336,8,109,0*60

I think a reasonable heuristic would be "if GNSS_type is Galileo and SVID > 
300, subtract 300 from it". Although I don't know if that would break any other 
engine :)


> 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

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum