[Top][All Lists]

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

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

From: Ellon Paiva
Subject: Re: [gpsd-users] Communicating NMEA to gpsd as if my software was a GPS device
Date: Fri, 6 Sep 2019 14:33:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

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


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.


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,
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:


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
Crappy GNSS receiver firmware.  Well, maybe not crappy, as the
standard does not say that the times must be monotonic and
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
I thought that processOHPR() would only be called if the sentence was
detected as 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?



reply via email to

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