[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] gpsmon vs PPS via USB
From: |
Mick Durkin |
Subject: |
Re: [gpsd-dev] gpsmon vs PPS via USB |
Date: |
Sun, 15 Dec 2013 18:20:06 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 |
Hi Gary and Hal,
I have been following this thread and Hal's latest issue with "invisible
pulses" is similar to something I was seeing.
I am not sure if I have understood the code correctly, but the following
fixed things for me:-
==============================
git diff ppsthread.c
diff --git a/ppsthread.c b/ppsthread.c
index bbadc37..edbef61 100644
--- a/ppsthread.c
+++ b/ppsthread.c
@@ -336,7 +336,6 @@ static /address@hidden@*/ void *gpsd_ppsmonitor(void *arg)
/* mask for monitored lines */
state &= PPS_LINE_TIOC;
edge = (state > state_last) ? 1 : 0;
- state_last = state;
#endif /* TIOCMIWAIT */
/* ok and log used by KPPS and TIOMCWAIT */
@@ -452,6 +451,7 @@ static /address@hidden@*/ void *gpsd_ppsmonitor(void *arg)
}
/* save this edge so we know next cycle time */
pulse[edge] = clock_ts;
+ state_last = state;
gpsd_report(session->context->debug, LOG_PROG,
"PPS edge: %d, cycle: %7d uSec, duration: %7d uSec
@ %lu.%09lu\n",
edge, cycle, duration,
==============================
It seems to me that the original assignment of "state" to "state_last"
at line 339 is too early, because at line 432 they are tested for
equality and because of this assignment, I reckon this test will always
succeed.
I think at line 339, we are merely saving present "state" ready for the
next cycle, so my proposal is to defer the assignment until after the
test at line 432.
Line 455 seems a reasonable place, as that is when we save "clock_ts"
for the next round.
At least, it solved my problem with invisible pulses.
BR
Mick