[gpsd-dev] refclock 28 gone wacky on me

[Mike]

On 06/19/2016 06:14 PM, Gary E. Miller wrote:
> Yo Mike!
>
> On Sun, 19 Jun 2016 17:46:48 -0400
> Mike <bellyacres at gmail.com> 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