[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: |
Tue, 17 Aug 2021 10:54:58 -0700 |
Yo Daniel!
On Tue, 17 Aug 2021 16:47:51 +0930
"Daniel O'Connor" <darius@dons.net.au> wrote:
> > 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?
You have no idea how vast and different peoples expectations are.
> - 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.
Way too NMEA specific.
Anyone that knows computers should know:
Garbage In, Garbage out.
That is much more general.
> > 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.
People definition of "reasonable" differs.
And, notice I said "documenet", not "parse". The gpsd doc now
"documents" those sentences.
> > 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.
Not a surprise at all, but very annoying.
> 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.
And takes somme standard NMEA and subtly perverts it.
> For the general case where it's not being talked to the it either
> emits nothing or whatever NMEA sentences have been enabled.
Is the default to emit nothing?
> > 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.
Yes, and JL does not follow the u-blox non-standard spec either.
> 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)
Yes, that is what I used to add the quirks. But it is still a BUG.
> Unfortunately it looks like it could be quite ambiguous given gpsd
> doesn't know what mode it's in.
Nothing to do with "mode". All to do with "firmware version". This is
a firmware bug: using standard NMEA in non-standard way.
> 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 :)
You realize I already patched this? Please pull git head and see if
it works for you.
The quirck addiion was here this commit:
124d46c6fd5b32a0d7ce8572e955b042b034686f
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
pgps3bCTvfE1G.pgp
Description: OpenPGP digital signature