[Xastir] xastir/gpsd - losing it in gps.c

[Tapio Sokura]

Curt, WE7U wrote:
> Comparing the two, I see that the longitude is missing a digit, the
> number after the E/W is a 3, whereas I have listed only 0-2 as
> possible.  In the decode_gps_gga() function we specifically check
> for 1 or 2 for a GPS fix quality.  Perhaps the WAAS changes to the
> GPS's are where the '3' comes from and we should accept that?  That
> one's new to me.  Since I don't have any WAAS-enabled GPS'es I
> haven't seen that one.

In Xastir context, to me a reasonable interpretation for that field 
would be to consider the fix valid, if the field contains a positive 
integer. If the field is empty, zero or anything else than a positive 
integer, consider the fix invalid. With Xastir context I mean 
specifically that a failure in detecting a bad position from the GPS 
should not cause loss of life or property. If this were a safety 
critical system, I'd probably err for the other side, only accepting 
those numbers as valid that specifically are valid. And pay a couple of 
hundred bucks for the NMEA spec..

My Garmin GPS-16 manual lists possible values for that field as being 0, 
1, 2 and 6, six meaning an estimated position (lost the sats for a while 
and estimating based on previous course/speed probably). I think I have 
seen somewhere 3 being listed as an SBAS augmented position.

> later, w.r.t. looking for a '.' character in the lat/long strings
> during validation.  This could certaily cause problems for us later
> if GPS'es send strings of varying length for some of these fields.
> Everything I've seen to date just changes the number of digits after
> the decimal point, the digits before the decimal point are always
> zero-filled.

Me too, for the latitude and longitude. Directions, speeds and altitudes 
can vary in the amount of digits before and after the period, but there 
should be no problem in just parsing them as floats as they are single 
numbers instead of combinations of degrees and minutes like lat/lon.

   Tapio