gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] git head broken


From: Eric S. Raymond
Subject: Re: [gpsd-dev] git head broken
Date: Tue, 5 Nov 2013 16:40:06 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Gary E. Miller <address@hidden>:
> Yo Eric!
> 
> On Tue, 5 Nov 2013 15:48:16 -0500
> "Eric S. Raymond" <address@hidden> wrote:
> 
> > Please remove the conjuct "&& session->packet.state==0" and tell me
> > if SiRF-III and GR601-W start being reliable again.
> 
> I can't get my GR-601W took even when I preset the speed.
> So maybe not speed, but some other port issue.  Here are my port settings:
> 
> kong gpsd # stty < /dev/ttyUSB0
> speed 38400 baud; line = 0;
> -brkint -imaxbel

I'm about to push a change that may affect this.  Here's the comment:

static bool hunt_failure(struct gps_device_t *session)
/* after a bad packet, what should cue us to go to next autobaud setting? */
{
    /*
     * We have tried three different tests here.
     *
     * The first was session->badcount++>1.  This worked very well on
     * ttys for years and years, but caused failure to sync on TCP/IP
     * sources, which have I/O boundaries in mid-packet more often
     * than RS232 ones.  There's a test for this at
     * test/daemon/tcp-torture.log.
     *
     * The second was session->badcount++>1 && session->packet.state==0.
     * Fail hunt only if we get a second consecutive bad packet
     * and the lexer is in ground state.  We don't want to fail on
     * a first bad packet because the source might have a burst of
     * leading garbage after open.  We don't want to fail if the
     * lexer is not in ground state, because that means the read
     * might have picked up a valid partial packet - better to go
     * back around the loop and pick up more data.
     *
     * The "&& session->packet.state==0" guard causes an intermittent
     * hang while autobauding on SiRF IIIs (but not on SiRF-IIs, oddly
     * enough).  Removing this conjunct resurrected the failure
     * of test/daemon/tcp-torture.log.
     *
     * Our third attempt, isatty(session->gpsdata.gps_fd) != 0 
     * && session->badcount++>1, reverts to the old test that worked
     * well on ttys for ttys and prevents non-tty devices from *ever*
     * having hunt failures. This has the cost that non-tty devices
     * will never get kicked off for presenting bad packets.
     *
     * This test may need further revision.
     */
    return isatty(session->gpsdata.gps_fd) != 0 && session->badcount++>1;
}

If this doesn't restore goodness on the SiRF-III and GR601-W, then you
probably have a local issue of some sort.  You could test for this by
checking out release 3.9 and trying that on the port.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

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