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

[Ellon Paiva]

    Yo!
    
    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. :-) 
    
    Best,
    
    Ellon

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

> Yo Ellon!
>
> On Fri, 6 Sep 2019 14:56:26 +0200
> Ellon Paiva <ellonpaiva@gmail.com> 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
> > here.
> >       
> 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
> lack.
>
> > 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
> > GNSS.
> >       
> 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
>
> https://www.e-education.psu.edu/natureofgeoinfo/c5_p20.html
> https://www.e-education.psu.edu/geog862/node/1713
> https://www.gpsworld.com/gps-accuracy-lies-damn-lies-and-statistics/
>
> 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
> >
> > $GPGGA,103642.879013,4850.432180742773,N,226.381659556439,E,7,08,,0,M,0,M,,*73
> >
> > 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
> > north".
> >       
> 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.
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> 	gem@rellim.com  Tel:+1 541 382 8588
>
> 	    Veritas liberabit vos. -- Quid est veritas?
>     "If you can't measure it, you can't improve it." - Lord Kelvin
>

JSON_short.txt
Description: Text document

NMEA_short.txt
Description: Text document