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

[Ellon Paiva]

Yo Gary!

Thanks for your replies. You'll find my comments inline below.

On 9/5/19 9:18 PM, Gary E. Miller wrote:
> > > >     * OHPR for attitude, acceleration and angular speed
> > > Proprietary, not well tested.
> > Ah... :-/
> 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. But I'm now aware it may not be fully supported since 
it's proprietary.


> > > You prolly also want GSV so gpsd can compute some more error
> > > estimates.
> > Well, even if I my code is sending data as if it was a GPS, it is
> > _not_ a GPS (localization comes from other sources than satellites,
> > e.g. cameras, lidars, etc).
> Which may work, but certainly not tested well.  There are lots of
> hidden assumptions about the data from a GPS that will be hard to
> model and may byte you.

Right.

> > So didn't think GSV was important and I
> > don't see how I could fake it properly in this case.
> Yeah, if your data is not from sats, then not useful.  BUT, there are
> places in the code that double check data against the skyview, those
> may fail in unintended and unexpected ways.

Right.

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

> > > >    1. The time in the GST reports seems to be off and floating with
> > > >       relation to the time in the TPV reports,
> > > Normal.
> > Really?
> Really.  The time stamp is NOT current time.  It is the time that
> the data being reported is measured.  So not rare that some data is
> reported late.
>
> Note this perfectly valid data from an old Ashtech ac12:
>
> $GPRMC,193221.00,A,2037.7279,N,08704.0848,W,00.1,201.8,231207,01,W,A*2D
> $GPZDA,193223.00,23,12,2007,00,00*69
> $GPGGA,193222.00,2037.72832,N,08704.08469,W,1,04,1.7,-30.00,M,-13.9,M,,*7F
> [...]
> $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. Maybe gpsd 
expects such messages _not to_ have the same time stamp (and thus 
compensate for it somehow)? Maybe could it be related to the end of 
cycle detection? 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...

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). On my side I'll continue sending the same UTC on all sentences 
that represent the same localization data.

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

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

> > > > 2. It seems that OHPR is not being properly parsed as a
> > > > NMEA sentence by gpsd (there is no ATT output for gpsd clients).
> > > That is because it is NOT and NMEA sentence.
> > It's not NMEA sentence, but gpsd "considers it as NMEA" as
> > processOHPR and
> 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.

> > >     Ignore packet.c for now. Look at the function processOHPR() in
> > > driver_nmea0183.c
> > I thought that processOHPR() would only be called if the sentence was
> > detected as OHPR,
> Correct.
>
> > 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?

Best,

Ellon