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

[Gary E. Miller]

Yo Ellon!

On Thu, 5 Sep 2019 11:02:02 +0200
Ellon Paiva <address@hidden> wrote:

> On 9/4/19 8:37 PM, Gary E. Miller wrote:
> > Easy, except the "slightly higher than 1Hz" part.  
> 
> I thought that if the gps device would send data in let's say 5Hz or 
> 10Hz it would be passed by gpsd clients at this rate... Isn't it the
> case?

Yes, gpsd passes on whatever it gets.  But the non-1Hz path is not as
well tested.  5Hz and 10Hz are used by some, assuming their serial
path and CPU are fast enough.  But there are places where odd
timing can mess things up.

Check out the ac12 NMEA samples:

$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

Note how the time jumps around?  That messes up a lot of code!

People keep assuming the time from a GNSS is, generally, only increasing.
But there is jumps forward 2 seconds, back 1.  Few clients handle that
well.

So, while perfectly leagl, not a good idea.

> >> Based on gpsd manual pages, it was decided my "GPS device" would
> >> communicate to gpsd through UDP or TCP feed using NMEA sentences.  
> > Those work.  You may want to verify how well things work on a
> > network interruption.  Did you look at gps2udp and gpsfake?  
> 
> I took a quick look on gpsfake, but when I saw it was in python I've
> put it away as my code has to be in C++. I'll take a look at gps2udp,
> thanks!

Don't worry about the language, try to understand the algorithm.
Also look for the many other solutions doing the same thing.  Even
a "nc" can be made to work.

> My code is handling network interruption, but apparently gpsd is not,

gpsd is getting better.  Patches welcome.

> at least for TCP as I need to restart gpsd when the tcp feed device 
> disconnects.

Yup.  Makes NTRIP that much harder...

> In UDP it works fine.

If it works, use it.

> >>    * OHPR for attitude, acceleration and angular speed  
> > Proprietary, not well tested.  
> 
> Ah... :-/

If you have actual samples then I can add to the regressions.

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

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

> > That is old.  If you ever need a fix you need to be on 3.19 or git
> > head.  
> 
> All right. I'll check how my code interacts with gpsd 3.19!

And fixes will be to git head.  Just as easy to use as the 3.19 tar ball.

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

When you find palces that gpsd needs data you do not supply then we'll
work on it with you.

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


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

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

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

> #ifdef OCEANSERVER_ENABLE
>  ______ {"OHPR", 18, false, processOHPR},
> #endif /* OCEANSERVER_ENABLE */
> 
> can be found in the code, no?

Yes in the code.  But not in the standard.  And notice it is quarded by
#ifdef to show its special nature.

Things not in the standard tend to mutate in the marketplace.

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

> > Also, I see you are hitting a known TSIP bug in 3.17.  You need to
> > get off 3.17.  
> 
> Ah, okay!

The code is layered a bit odd because it has to deal with a lot of
weirdness that is not obvious.

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

pgpazyzwjqkN_.pgp
Description: OpenPGP digital signature