[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
signature.asc
Description: PGP signature
- [gpsd-dev] Time to let the code cool down, Eric S. Raymond, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down, Greg Troxel, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down, Eric S. Raymond, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down, Gary E. Miller, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down, Eric S. Raymond, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down,
Gary E. Miller <=
- Re: [gpsd-dev] Time to let the code cool down, Eric S. Raymond, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down, Gary E. Miller, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down, Eric S. Raymond, 2013/11/18
- Re: [gpsd-dev] Time to let the code cool down, Gary E. Miller, 2013/11/18