gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Time to let the code cool down


From: Gary E. Miller
Subject: Re: [gpsd-dev] Time to let the code cool down
Date: Mon, 18 Nov 2013 14:22:52 -0800

Yo Eric!

On Mon, 18 Nov 2013 16:39:56 -0500
"Eric S. Raymond" <address@hidden> wrote:

> Gary E. Miller <address@hidden>:
> > You changed it, but it does not deal with the delay thing.  You can
> > not just add a delay, the code needs to wait for the ACK.  By
> > waiting 4 seconds the output from the GPS is overflowing and the
> > GPS resets.
> 
> Um, but you were adding a 3-second settle, right? Were you getting
> overflow?

No,  30 mSec. BIT difference.  It had been mostly 3mSec which was no where 
near lng enough at 4800.

> OK.  I didn't see an overflow during the init sequence.

I do.

>  And
> shouldn't, as the way it's coded now it spaces the initialization
> writes 5 seconds apart while allowing traffic through.

Yeah, which casues infinite recursion. Oops.

>  Are you
> actually seeing a problem there or is it getting through those first
> 10 sends OK?

Yes I se a problem, and no it never works.

> What sequence of operations is actually causing
> overflow/reset?

Hard to say, but now getting recursion, and that is not good.  Wjile
sending the init, some of the let in messages, causes another init, which
send more control messages, which...

> Note that I'm not unconditionally adding a delay, like you
> were. Rather I'm waiting for 4 seconds *since the last send* - often
> that will be no delay at all.

I see where you are going, it is better than before, just not there yet.

> We could add a semaphore, I suppose.  Increment on each sirf_write(),
> decrement on each ack, return an error if the user tries to trigger a
> sirf_write() while the semaphore is nonzero.  That would never block
> traffic. Some requests might fail.

the SiRF IV doc implies we need somthing like that.  Since it does not work
yet that is the next thing to try.

> What is the actual error pattern you're currently seeing?

All over the map.  Input overflows due to being at 4800 with all the
sat data enabled, GPS resets, etc.

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

Attachment: signature.asc
Description: PGP signature


reply via email to

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