gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] 3.10 is nearly ready; feature freeze time


From: Eric S. Raymond
Subject: Re: [gpsd-dev] 3.10 is nearly ready; feature freeze time
Date: Mon, 11 Nov 2013 16:37:00 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Gary E. Miller <address@hidden>:
> > I was able to gpsctl -s a SiRF-II device to a couple of other speeds,
> > but gpsctl -s 38400 wedged it hard enough that only a gpsctl reset
> > could wake it up again - gpsmon was mute.
> 
> Ouch.
> 
> > I'll poke at this a bit more.  But it doesn't look like a release
> > blocker.
> 
> Well, it seems pretty important to me.  Any PS stuck at a slo speed is
> not going to wok very well.

I think I've found the problem, or at least a problem.

gpsctl mode changes to high baud rates actually work on a SiRF
II. They look like they don't, because gpsctl itself samples only a
relatively few packets before announcing that the sync attempt has
timed out.  But I can kick a SiRF-II up to 38400 using gpsctl, then
try to ID it with gpsctl and get a packet recognition timeout, then
sic gpsd on it *and watch gpsd sync at 38400*.

I guess I'm going to have to lose the timeout in gpsctl and just let
it run until either sync or final hunt failure, the same way gpsd
does. It is possible there are other problems - I'm going to redo
these tests with the GR601-W to see - but the short timeout may be the
whole bug, and if not it leads to results that are way too confusing.

One thing this implies is that baud rate changes done from within
gpsd with ?DEVICE won't fail.
-- 
                <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]