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

[Ellon Paiva]

Yo Gary!

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?

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!

My code is handling network interruption, but apparently gpsd is not, at least for TCP as I need to restart gpsd when the tcp feed device disconnects. I found an old thread on the mailing list about the "tcp:://feed failure strategy" (https://lists.nongnu.org/archive/html/gpsd-users/2016-04/msg00034.html), but I didn't consider recover strategies yet other than relaunching gpsd. In UDP it works fine.

  * OHPR for attitude, acceleration and angular speed

Proprietary, not well tested.

Ah... :-/

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). So didn't think GSV was important and I don't see how I could fake it properly in this case.

I have a first implementation of this idea, but I'm facing some
problems which I would like to discuss. For information, I'm using
gpsd-3.17 installed from Fedora 29 default repositories. I'm
attaching some log files to help understand the problems.

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!

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

 1. The time in the GST reports seems to be off and floating with
    relation to the time in the TPV reports,

Normal.

Really?

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

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

#ifdef OCEANSERVER_ENABLE
    {"OHPR", 18, false, processOHPR},
#endif /* OCEANSERVER_ENABLE */

can be found in the code, no?

I
tried to follow logic used by the state machine decode the sentence
but it proved to be very hard...

Then you looked in the wrong place.  dirver_nmea0183.c does not
contain a state machine.  You were likely looking at packet.c.

Yes, I was indeed looking at nextstate(lexer,c) on packet.c, I should had made this more clear.

  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, and the debug logs of gpsd let me think that it was not able to detect the sentence was a "NMEA" OHPR.

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

Ah, okay!

Getting off 3.17 is your first step.

Okay! Thanks for the help, I'll try with 3.19 and let you know.

Best regards,

Ellon

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