Re: [gpsd-dev] 'status' field in TPV JSON to include DGPS and RTK solution indicators

[Gary E. Miller]

Yo Max!

On Tue, 14 Jun 2016 23:34:44 +0200 (CEST)
Max Schulze <address@hidden> wrote:

> Hey Gary,
> 
> > Where are you expecting that to be documented?  Point me at the
> > right place and I'll fix it.  
> 
> I would have thought at http://www.catb.org/gpsd/gpsd_json.html

Yeah, I eventually found that.  It is generated from gpsd_json.xml.

I'm just trying to get people to send me more bug with solution and
less just bugs.

I just pushed an update that documents the TPV status key.  It will take
a while before it is live on catb.org.

> Maybe you could re-introduce it and even expand a bit: when feeding
> NMEA data that has been generated by RTKLIB ( RTK DGPS solutions), it
> would be nice to have the status flag passed on that is in the GGA
> message.

Sadly, GGA is not evern very common, or even standardized.  Which is why
gpsd tries to abstract all the variants into something mostly
consistent.

And RTK is essentially identical to DGPS, so I just lumped them in
together.  The data fields are identical.

> So not only to have a status indicating 2=dgps, but the whole range
> ( http://www.gpsinformation.org/dale/nmea.htm#GGA ) :
> 
>      1            Fix quality: 0 = invalid
>                                1 = GPS fix (SPS)
>                                2 = DGPS fix
>                                3 = PPS fix
>                              4 = Real Time Kinematic
>                              5 = Float RTK
>                                6 = estimated (dead reckoning) (2.3
> feature) 7 = Manual input mode
>                              8 = Simulation mode

Yeah, I looked at that, and more, weh adding the DGPS back in. #3, PPS
fix is meaningless.  I see no added value in the #4 and #5.  That is so
special that is someone needs to know the difference is needs to be a
specialized JSON, and I've yet to hear anyone know what to do with the
extra info.

As for #6 and #8, gpsd make the decision a long time ago not to ever
report fake data.  Since no TPV is ever send with no fix there is
no point noting that in a JSON that is never sent.

#7 is a spcial case of GPS or DGPS fix and is mushing two concepts into
an inedible something.

If some client ever makes a case for splitting out things in a more granular
fasion we should think about it long and hard and come up with a new
key:value pair for it.  But no credible use case has presented itself.

> This would be really helpful for processing "down-the-stream", i.e.
> to keep gpsd as the universal daemon in-between.

Sadly that is so firmware specific as to be useless, and makes no
practical difference to the client..  If a client needs that level of
detail they can grab the raw NMEA.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgplp9oMIWNCZ.pgp
Description: OpenPGP digital signature