[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: Thu, 26 May 2022 18:46:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

Hi Greg,

Thanks for your reply.

You were right: I just used gpsfake + gpspipe on 3.24 and I can see the track is reported there. That was probably a bug. Thanks for the heads up!



On 5/26/22 13:43, Greg Troxel wrote:
Ellon Paiva <> 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.

reply via email to

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