[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 10:19:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0


I'm reviving this thread after almost 3 years because only now I'm facing some problems with the feature I developed at the time.

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

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.

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.

Thanks in advance for any help on this. :-)



On 9/6/19 19:45, Gary E. Miller wrote:
Yo Ellon!

On Fri, 6 Sep 2019 14:56:26 +0200
Ellon Paiva <> wrote:

Field 10, HDOP.  Missing.  
This was in purpose, as I am not really simulating localization
from satellites.  
And yet you include accuracy estimates which are derived from the
DOPs, which are derived from the skyview.  
My accuracy estimates come a covariance matrix from which I extract
the error ellipsoid and standard deviations used to fill the fields
of a GST sentence. I know that these fields are supposed to have
information derived from skyview, but I think skyview doesn't apply
If you are confident in your values, then put them in your data output.
Just be on the watch any unexpected behavior in gpsd dues to their

I think I could find a way to derive HDOP from the same covariance 
matrix... but first I need to understand better the HDOP concept on
Easy "error = xDOP * Uere".

Where Uere is a variable broadcast by the GNSS system to tell the user
about how good the current signals are relative to optimal.

Current Uere is about 9.4.  So right now, on one GNSS, I see

7.80288 m Xerr = 0.8 XDOP * 9.4

But there is no need for you to provide the DOP's if your error
estimates are "good".  Sadly I never see "good" error estimates...

By the way, I tried to understand the "226 degrees east" problem, and
in fact I realized it's not a problem! In the sentence you mentioned


the lon/lat are expressed in "Degrees Decimal Minutes" as I
understood that's the way they should be described. So longitude 
"226.381659556439,E" in fact means "2 degrees and 26.381659556439 
minutes east". The same thing with the latitude:
"4850.432180742773,N" means "48 degrees and 50.432180742773 minutes
Uh, oh.  My mistake, I read that too fast, you are correct.  226.38 is
indeed good.

And gpsd is not the gold standard, you likely want your psuedo NMEA
to work for most NMEA decoders.  
In fact I would like it to work in gpsd because gpsd is already used
in our project. Indeed having it working with most NMEA decoders
would be a bonus, but we're not interested on that (as far as I know).
And to work with gpsd you just need to stay close to the spec and/or
common usage.  Even though you data is clearly uniquely created.

I'm sure with a bit of work we can make the two parts work together.

When you have another set of NMEA output, send it along and we'll
both take a closer look at it.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: JSON_short.txt
Description: Text document

Attachment: NMEA_short.txt
Description: Text document

reply via email to

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