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

[Greg Troxel]

Ellon Paiva <ellonpaiva@gmail.com> writes:

> As a reminder of what this feature is about, what I wrote in the first
> mail of this thread was:
>
>    I'm working in a project where some clients are already configured
>    to get localization data from gpsd. I'm in charge of creating a
>    piece of software that would communicate with gpsd as if it was a
>    GPS device,so these clients would be able to get this information
>    from the same gpsd client interface, and in a frequency slightly
>    higher than 1Hz.
>
>
> I got that "higher than 1Hz is not good", but that's not the problem
> I'm facing. (Nor the source of it... I think).

gpsd may have a 1 Hz cycle baked into it, but I wouldn't assume that.
Higher rates (e.g. 10 Hz) are becoming normal.

> The problem is that although I send track information on a VTG message
> from my software to gpsd, I don't see it in the TPV messages gpsd
> sends to its clients. I checked that the track info is read from the
> VTG messages by gpsd and reported in the debug messages.
>
> I'm currently sending ZDA, GGA, GST, VTG and OHPR messages. You'll
> find attached the NMEA output I send, as well as the gpsd JSON output,
> both recovered using gpspipe. *I'm using gpsd 3.20*.

Stop right there and fix that.   gpsd 3.20 is very old.   The only
acceptable versions to use for debugging and getting help are the master
branch and the most recent formal release -- which today is 3.24.

> I tried to track what was going wrong using debug messages and looking
> at the code, and I think that there's something to do with the logic
> that detects the GGA as "starting a reporting cycle", setting the
> CLEAR_IS flag, at the same time that this same message "ends a
> reporting cycle", setting the REPORT_IS flag. I think this is making
> the gpsd clear the current track information (libgpsd_core.c:1656)
> before merging the new data into gpsdata.fix (libgpsd_core.c:1663)
> before getting reported later to the clients. This happens every time
> a GGA is received, so trach gets systematically reset to NaN, and
> never gets reported. I don't know if this is normal or if I can "work
> around" this behavior to have the track on the TPV messages.

You may be on the path to finding a bug.  If so the right thing to do is
fix it and use the fixed version, not kludge around it.   Fixes go on
master, so build that and then start debugging again.

signature.asc
Description: PGP signature