gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] refclock 28 gone wacky on me


From: Mike
Subject: Re: [gpsd-dev] refclock 28 gone wacky on me
Date: Sun, 19 Jun 2016 18:45:45 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

On 06/19/2016 06:14 PM, Gary E. Miller wrote:
Yo Mike!

On Sun, 19 Jun 2016 17:46:48 -0400
Mike <address@hidden> wrote:

What do your other chimers in 'ntpq -p show'?  Youu still have not
confirmmed which PPS edge you are on.  The leading or trailing.
I'll likely put an arrow through this module before I'm able to get a
scope hooked up too it!  So leading or trailing is a coin toss at
this point.
Which is why I asked what your other chimers say.  If you have
a chimer without 30 milliSec of you that is usuually good enough to
check your edge.
*SHM(1)          .PPS.            0 l    9   16  377    0.000 0.004   0.004
-SHM(0) .GPS. 0 l 8 16 377 0.000 -414.81 5.999
+199.102.46.75 ( .GPS.            1 u   61   64  377   39.468 6.354   2.236
+fairy.mattnordh 192.5.41.40      2 u   37   64  377   60.559 3.875   0.986
-origin.towfowi. 204.9.54.119     2 u   26   64  377   77.933 1.970   2.503

At that point
NMEA deliver was really late, as in > .940 that I was seeing
earlier.
To disabiguate 'late' I assume you mean the NMEA timestamp fractional
seconds is for later in tthe second, not zero.
Yes, that is what I meant.

  I wasn't real pleased and figured I'd have to reset the
setting to get the NMEA delivery back to top of second.  Left is
alone for several hours, come back and gpsmon shows that I was back
to getting delivery close to the top of second again.
Yes, that is expected.  You need to tetll the Skytrazzq to force the
top of the second, and save to flash.
Did that which is why I didn't understand the delivery coming at near the end of the second. It appears thought that the firmware *slowly* brings the delivery back to where it should be.

At that point PPS looks good, NMEA is way out, where before I had
powered the module down is was looking pretty good.
I'm not sure what you mean by 'way out'.
Saying the NMEA offset was within at least a few milli seconds. Now I'm nearly .5 second off.

  I'll probably
have to pull that info from the statistics if it's really relevant. I
get that I can fudge out the difference shown above.  One shouldn't
have to do that every time something is powered off though.
Your ntpshmmon it misleading you.  It is corrypted by a bug, that is
now fixed.  Rerun with the ntpshmmon which is now in git hear.
Okay, ntpshmmon: version 3.17~dev (revision release-3.16-359-g88190a1)

NTP1 1466375449.102696889 1466375448.999287687 1466375449.000000000 0 -20
NTP0 1466375449.166960015 1466375449.166214014 1466375449.012000083 0  -1
NTP1 1466375449.999668646 1466375449.999316646 1466375450.000000000 0 -20
NTP0 1466375450.172941648 1466375450.172523648 1466375450.012000083 0  -1
NTP1 1466375450.999599615 1466375450.999346615 1466375451.000000000 0 -20
NTP0 1466375451.172908439 1466375451.172217439 1466375451.012000083 0  -1
NTP1 1466375452.000323577 1466375451.999376578 1466375452.000000000 0 -20
NTP0 1466375452.173620228 1466375452.173340228 1466375452.012000083 0  -1
NTP1 1466375452.999660542 1466375452.999405542 1466375453.000000000 0 -20
NTP0 1466375453.174251185 1466375453.173483187 1466375453.012000083 0  -1
NTP1 1466375454.000289499 1466375453.999434501 1466375454.000000000 0 -20
NTP0 1466375454.167078834 1466375454.166856835 1466375454.012000083 0  -1
NTP1 1466375455.000546466 1466375454.999462470 1466375455.000000000 0 -20
NTP0 1466375455.165878798 1466375455.165699798 1466375455.012000083 0  -1
NTP1 1466375455.999726428 1466375455.999489429 1466375456.000000000 0 -20

This just confuses me more...

Mike

RGDS
GARY




reply via email to

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