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

[Richard Polivka]

--- "Curt, WE7U" <archer at eskimo.com> wrote:
> 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]
> 
> 
Missing a leading zero "should" be of no issue. But
then again, I am so stale at programming that I could
very well be wrong. 
> 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.
If I am correct, the chipset in this unit (Pharos
i360-GPS) is WAAS-enabled.
> 
> 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.
> 
I will patch the appropriate part and open the
offering up to include "3". I believe I know the
section of code to diddle with.
> The decode_gps_rmc() function doesn't have a similar
> problem as the
> fix quality is just 'A' or 'V' there.
I will check out this section when I can find the
time. 
> 
> 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.
I would hope that the parsing would line up on the
decimal point. But then of course, screwy things can
happen. 

As an aside, the decode routine does not hit all the
time. I see a load of sentences fly by before the
decode routine triggers and the trigger appears to be
intermittent, even with update set to 1.

Back to work......

Richard Polivka, N6NKO