gpsd-dev
[Top][All Lists]
Advanced

[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



reply via email to

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