gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] NMEA0183 Problems with frames mit checksum errors


From: Gary E. Miller
Subject: Re: [gpsd-dev] NMEA0183 Problems with frames mit checksum errors
Date: Mon, 5 Sep 2016 14:11:15 -0700

Yo Fred!

On Mon, 5 Sep 2016 13:54:21 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> On Mon, 5 Sep 2016, Gary E. Miller wrote:
> > On Mon, 5 Sep 2016 12:18:21 +0200 (MEST)
> > "address@hidden" <address@hidden> wrote:
> >  
> > > i have reported a problem, that gpsd,
> > > after getting a number of packets with checksum errors,
> > > is trapped in an endless loop testing for other baudrates,
> > > and then exit with a segmentation fault after a while.  
> >
> > Until you fix your checksum errors you'll have troubles.  If
> > you are getting a lot of checksum errors then a lot of bad data is
> > geting through and passing the check sum.  
> 
> That may well be true, given how lame the NMEA0183 checksum scheme is
> (and some of the binary formats aren't much better), but expecting
> 100% reliability isn't always realistic.

Hard to tell 99.7 from 100%, but I find any observable serial errors to
be unacceptable.  Bad cable, bad power supply voltages, bad data line
voltages, something is clearly wrong.  No telling when it may get just
a tiny bit worse and be 100% dead.  Best to fix it or replaec it.

> > So focus on your serial port problem.  You should have zero
> > checksum errors in normal operation.  
> 
> It sounds like there are at least two gpsd bugs that can't be
> reproduced with the normal test suite:

Likely dozens, but you can't expect your car to keep working when it is
filled with bad gas or a drunk driver.  Same applies here, only so much can
be done to compensate for bad inputs.

> 1) Being too trigger-happy in switching baud rates after establishing
> a valid setting (and thereby garbling valid data as well).

Patches welcome.  I can not duplicate that.

> 2) Segfaulting in the process.  A segfault isn't a valid response to
> *any* input.

I think I fixed that one in git head.  No confrimation.  There were
potential overflows in the debug output code.  The real bug was the input
buffer was overflowing for still unknown reasons.

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

Attachment: pgpu8T96uvA9a.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]