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

[Curt, WE7U]

On Wed, 18 May 2005, Richard Polivka wrote:

> I resorted to the old, old trick of inserting prints
> into the code to track progress. In working with the
> GPGGA section in gps.c, I found that the following
> sentence fails parsing:
> $GPGGA,115219,4301.1477,N,8803.0382,W,3,06,1.80,237.2,M,-34.460,M,,*77.

This is what I have listed for GPGGA:

GPGGA,hhmmss,ddmm.mmm[m],{N|S},dddmm.mmm[m],{E|W},{0|1|2},nsat,hdop,mmm.m,M,mm.m,M,,[*CHK]


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.

W.r.t. the longitude string, I think we're handling that ok at
present.

I'm tweaking the GPGGA parsing to allow a '3' for the fix quality.
I'd like to know if that means a good fix and whether other numbers
are possible.  I'll check that into CVS shortly.

The decode_gps_rmc() function doesn't have a similar problem as the
fix quality is just 'A' or 'V' there.

I did see what might be other problems that we might come across
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.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"