Re: [gpsd-users] Communicating NMEA to gpsd as if my software was a GPS device

[Gary E. Miller]

Yo Ellon!

On Fri, 6 Sep 2019 14:33:00 +0200
Ellon Paiva <address@hidden> wrote:

> > If you have actual samples then I can add to the regressions.  
> 
> I don't have samples, sorry. I chose OHPR because I saw I could send 
> attitude, acceleration and angular speed with it, and that it was 
> supported by gpsd.

It is.

> But I'm now aware it may not be fully supported
> since it's proprietary.

No.  It is not fully supported because you are not sending the OHPR
flavor that gpsd understands.  Being non-standard it is implemented
different ways by different vendors.  Just implement what gpsd
understands.

> >>> Your logs are "interesting".  Rt first glance your GST and GGA are
> >>> not even close to standard NMEA.  If such simple things are wrong
> >>> the bit rot must go very deep.  
> >> I was not trying to mimic a gps device "at all costs", so I let
> >> some fields that does not make sense for me to supply (like
> >> satellite info) empty, with the hope gpsd would be able to work
> >> with whatever was supplied. :-)  
> > Except, that is NOT what you always did.  In, for exxample, the
> > geoid separation where you invented a value (0).  NMEA is clear, if
> > you do not have the data, do not fake it.  
> 
> I thought that if I didn't supply the geoid separation gpsd would not 
> consider my the altitude value, but I just tested with it left blank
> and I get the altitude values, so thanks for the warning. :-)

Yes.  gpsd tries to compute issing data if it can.  gpsd knows how
to approximate the geoid separation from the lat/lon.

> > $GPRMC,193222.00,A,2037.7283,N,08704.0847,W,00.0,201.8,231207,01,W,A*25
> > $GPZDA,193224.00,23,12,2007,00,00*6E
> > $GPGGA,193223.00,2037.72880,N,08704.08455,W,1,04,1.7,-29.55,M,-13.9,M,,*70
> >
> > A GNSS may fast path the PVT, then do the skyview when CPU
> > resources allow.  
> 
> OK, I understood that the time stamps in the messages are not
> guaranteed to be monotonically increasing. Still, I don't get how a
> set of messages__ (GGA, ZDA, GST, VTG) that have the same stamp are
> translated on TPV and GST reports that have different time fields.

The TPV time feild is from the messages that have the TPV data.
The GST time feild is from the messages that have the GST data.

Sort of.  YMMV.

> Maybe gpsd expects such messages _not to_ have the same time stamp
> (and thus compensate for it somehow)?

Sort of.  It's complicated.  Since you are creating your own NMEA, just
use consistent time stamps.

> Maybe could it be related to
> the end of cycle detection?

Yes, and much more.  Very yucky heuristics...

> I see some debug messages mentioning the
> end of cycle, but I don't get what it means. Or could it be the
> message order? From what you wrote it doesn't seem so...

Don't worry about how gpsd handle junky NMEA.  Just send nice
NMEA.

> In any case, I would just like to understand why they are different 
> (potentially to explain it to the people responsible for the gpsd 
> clients).

Not all of the data in each sentence is computed at the exact same
time.  The timestamp is the time of the data in that sentence, not
the current time.  The GNSS may prioritize some data, like TPV, over
other, like SKY.  So they get out of order in the serial stream.

> On my side I'll continue sending the same UTC on all
> sentences that represent the same localization data.

UTC is NEVER localized.  It is always UTC.

The timestamps are the moment the data was valid, not current time.

The difference may seem insignificant, but at high precision or
high speed it is important.

> >>>> which seems to be
> >>>> according with the data sent. Does anyone know why I have this
> >>>> behavior?  
> >>> Crappy GNSS receiver firmware.  Well, maybe not crappy, as the
> >>> standard does not say that the times must be monotonic and
> >>> increasing.  
> >> But in this case the firmware is my code... no?  
> > If you say so.  Not seen your code.  
> 
> What I wanted to say is that in my case what is generating the
> messages is my code, the code that is replacing what would be a GPS
> device firmware in an usual setting.

And, to rerpeat what I said:  "If you say so.  Not seen your code."

Words are cheap, code is gold.

> 
> >> You mean that gpsd
> >> tries to compensate for the crappy firmware, so I have to make a
> >> "crappy code" to be able to have the GST timestamps right?  
> > "crappy" is in the eyes of the beholder.  Different people read the
> > (hard to get) spec differently.  gpsd tries to compensate.  So
> > stick close to the spec and you should be good.  Or we'll fix it.  
> 
> OK, I'll try to be close to the spec as possible (apart from the OHPR 
> message because I didn't find/don't know an alternative in the NMEA
> spec to pass such data).

Because there is no OHPR, or similar in NMEA spec.  So try to conform
to the OHPR that gpsd already decodes.  As documented in driver_nmea0183.c

> > There is NMEA, the standard, and NMEA, anything that starts with a
> > $ and has fields, ends in CR LF.
> >
> > The first is sorta well documented and the sorta consistent, the
> > latter is anything goes.  You are venturing outside the standard,
> > so beware.  
> 
> I believe I'm on the latter case, as some data I would like to supply 
> are not supported by the NMEA standard.

That is OK, as long as you can find some existing NMEA look-alike that
can work.  Such as the OHPR that gpsd already supports.

Any other data point you need beyond the standard and OHPR?

> >> and the debug logs of gpsd let me think that it was
> >> not able to detect the sentence was a "NMEA" OHPR.  
> > Yes, as I mentioned before, you hit a bug in the packet.c related to
> > TSIP decoding.  So the message did not get detected as "NMEA" and
> > thus the NMEA driver could not dispatch to processOHPR().  
> 
> Is this bug fixed on the current git master branch?

Yes.  And the last release.  Maybe longer.

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

pgpLOlUPQfSYS.pgp
Description: OpenPGP digital signature