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

[Gary E. Miller]

Yo Hal!

On Sun, 19 Jun 2016 17:24:56 -0700
Hal Murray  wrote:

> g...@rellim.com said:
> > Yes, that is expected.  You need to tetll the Skytrazzq to force
> > the top of the second, and save to flash.   
> 
> What does that mean?

The Skytraq GPS, and some others, have two modes they can report
the GPS mode.

The first way, the way we expect, is the GPS computes a new PVT
solution at the top of every second, and then sends a message
that that new fix.

So a fix report would look like this:

{"class":"TPV","device":"/dev/ttyS0","mode":3,"time":"2016-06-20T02:14:34.000Z","ept":0.005,"lat":44.068348315,"lon":-121.313259926,"alt":1176.971,"epx":15.315,"epy":18.206,"epv":43.081,"track":121.0306,"speed":1.582,"climb":0.303,"eps":36.41,"epc":86.16}

Notice the fractional seconds of the fix is .000

The second way is for the GPS to report the fix when it is most convenient
for the GPS cpu to report it.  The GPS will emit the fix with fractional
seconds to note the exact time the fix was valid.

{"class":"TPV","device":"/dev/ttyS0","mode":3,"time":"2016-06-20T02:14:34.940Z","ept":0.005,"lat":44.068348315,"lon":-121.313259926,"alt":1176.971,"epx":15.315,"epy":18.206,"epv":43.081,"track":121.0306,"speed":1.582,"climb":0.303,"eps":36.41,"epc":86.16}

Noteice the fix time has the fractional seconds of .940

The problem comes in that gpsd never expected the PVT solution to 
come that late in the second.  The full sentence may actually be decoded
after the start of the next second, and after the PPS for the next
second is received.

There is likely a not too bad solution, but it is not currently implmented
in the gpsd code.


> bellyac...@gmail.com said:
> > 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.   
> 
> I've lost track of the details of this discussion.

It happesn, too many similar discussions at the same time.  Which is
why I encourage people to recap all the details in each message.

> Many GPS chips seem to have a 100 ms timer that drifts slowly so the
> offset within the second when the NMEA strings come out will slowly
> drift then jump back and start over.

I doubt it is not an intentional timer.  It seems to correlate with the
number of sats in the solution.  The more sats, the more math to do
before the solution is fully computed.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpcU0aHSGNPT.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Hal Murray]

g...@rellim.com said:
> Yes, that is expected.  You need to tetll the Skytrazzq to force the top of
> the second, and save to flash. 

What does that mean?


bellyac...@gmail.com said:
> 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. 

I've lost track of the details of this discussion.

Many GPS chips seem to have a 100 ms timer that drifts slowly so the offset 
within the second when the NMEA strings come out will slowly drift then jump 
back and start over.

-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Gary E. Miller]

Yo Mike!

On Sun, 19 Jun 2016 18:45:45 -0400
Mike  wrote:

> > Which is why I asked what your other chimers say.  

> +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

You are without all of those to better than 6 milliSec.  If you have the
wrong edge you would be off 20 milliSec or more.  So that is reall good.


> >>   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.

And only one cycle of NMEA per second?  If it takes time to get back to
the top of the second I would report that to Skytraq as a bug.

> >> 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.

Odd.  The NMEA offset will not stay closer than +/- 100 milliSec over
time.  But 500 milliSec is too much.  Even if the NMEA wanders around in
the second, the offset of the fix from the time of fix should be

Try setting the serial speed to 38400 and see if it persists.

> Okay, ntpshmmon: version 3.17~dev (revision release-3.16-359-g88190a1)

That looks good to me.  The NMEA delay and offset not bad.  Look good to you?

> This just confuses me more...

Looks very good to me.  What looks off to you?

NTP1 is offset under 1 millSec, NTP0 offset about 150 milliSec.  Fine
numbers.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpJdHdpBikXk.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Gary E. Miller]

Yo Mike!

On Sun, 19 Jun 2016 17:46:48 -0400
Mike  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.

> 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.

>  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.

> 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'.

>  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.

You should be within +/- 150 milliSec if you start with the right
fudge.  The NMEA not being at the top of the second should not
affect that at all.

> I believe that the ntpshmmon output was showing that PPS is picking
> up the first seen and NMEA is picking up the second.

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.


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgprzpxBudwLr.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Mike]

On 06/19/2016 04:23 PM, Gary E. Miller wrote:

Yo Mike!

`

On Sun, 19 Jun 2016 15:59:16 -0400
Mike  wrote:


On 06/10/2016 03:17 PM, Gary E. Miller wrote:

Yo Eric!

On Fri, 10 Jun 2016 03:49:22 -0400
"Eric S. Raymond"  wrote:
  

That's... very weird.  I've never seen it happen.

But it would explain some old complaints.

Now that we know which Skytraq option it is, I recall always
selecting the workaround.
  

It sounds as though for some crazy reason the GPS is delivering the
PPS pulse late.

Not late, as such.  Late in the second, but the time stamp of the
fix (xxX.940) is pretty close to when actually sent.
  

I'm hard put to imagine how gpsmon could screw this up.

Or Hal with his O-scope.

RGDS
GARY

I'm seeing this happen now, PPS is good NMEA is off nearly half a
sec...  NMEA delivery viewed in gpsmon is 0.011 after top of second.

*SHM(1)  .PPS.0 l   10   16  3770.000 -0.002   0.004
-SHM(0)  .GPS.0 l9   16 3770.000 -496.59 6.661

Looking good.  Now add a 0.500 fudge to your ntp.conf.  Like this:

 server 127.127.28.0
 fudge 127.127.28.0 time1 0.500  refid GPS

What do your other chimers in 'ntpq -p show'?  Youu still have not confirmmed
which PPS edge you are on.  The leading or trailing.

RGDS
GARY

Gary,

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.


I should have elaborated more I guess.  I had everything sailing along 
nicely.  Went off on a tangent with the rpi and left the module 
unpowered for a few days.  Its battery was still plugged in and came 
backup as expected when I powered it all on again.  At that point NMEA 
deliver was really late, as in > .940 that I was seeing earlier.  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.


At that point PPS looks good, NMEA is way out, where before I had 
powered the module down is was looking pretty good.  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.


I believe that the ntpshmmon output was showing that PPS is picking up 
the first seen and NMEA is picking up the second.  There is 4 per second 
in the output that I posted.  And the time is off by approximately the 
offset above.  Or am I mis-reading the output that bad?


Mike
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Gary E. Miller]

Yo Mike!

`

On Sun, 19 Jun 2016 15:59:16 -0400
Mike  wrote:

> On 06/10/2016 03:17 PM, Gary E. Miller wrote:
> > Yo Eric!
> >
> > On Fri, 10 Jun 2016 03:49:22 -0400
> > "Eric S. Raymond"  wrote:
> >  
> >> That's... very weird.  I've never seen it happen.  
> > But it would explain some old complaints.
> >
> > Now that we know which Skytraq option it is, I recall always
> > selecting the workaround.
> >  
> >> It sounds as though for some crazy reason the GPS is delivering the
> >> PPS pulse late.  
> > Not late, as such.  Late in the second, but the time stamp of the
> > fix (xxX.940) is pretty close to when actually sent.
> >  
> >> I'm hard put to imagine how gpsmon could screw this up.  
> > Or Hal with his O-scope.
> >
> > RGDS
> > GARY  
> I'm seeing this happen now, PPS is good NMEA is off nearly half a 
> sec...  NMEA delivery viewed in gpsmon is 0.011 after top of second.
> 
> *SHM(1)  .PPS.0 l   10   16  3770.000 -0.002   0.004 
> -SHM(0)  .GPS.0 l9   16 3770.000 -496.59 6.661

Looking good.  Now add a 0.500 fudge to your ntp.conf.  Like this:

server 127.127.28.0
fudge 127.127.28.0 time1 0.500  refid GPS

What do your other chimers in 'ntpq -p show'?  Youu still have not confirmmed
which PPS edge you are on.  The leading or trailing.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpX5PvN9vzuV.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Mike]

On 06/10/2016 03:17 PM, Gary E. Miller wrote:

Yo Eric!

On Fri, 10 Jun 2016 03:49:22 -0400
"Eric S. Raymond"  wrote:


That's... very weird.  I've never seen it happen.

But it would explain some old complaints.

Now that we know which Skytraq option it is, I recall always selecting
the workaround.


It sounds as though for some crazy reason the GPS is delivering the
PPS pulse late.

Not late, as such.  Late in the second, but the time stamp of the
fix (xxX.940) is pretty close to when actually sent.


I'm hard put to imagine how gpsmon could screw this up.

Or Hal with his O-scope.

RGDS
GARY
I'm seeing this happen now, PPS is good NMEA is off nearly half a 
sec...  NMEA delivery viewed in gpsmon is 0.011 after top of second.


*SHM(1)  .PPS.0 l   10   16  3770.000 -0.002   0.004
-SHM(0)  .GPS.0 l9   16  3770.000 -496.59   
6.661


sample NTP0 1466365999.284354339 1466365999.212852562 
1466365999.01283 0  -1
sample NTP1 1466365999.286413275 1466365999.01179 
1466365999.0 0 -20
sample NTP0 1466365999.785199770 1466365999.595461668 
1466365999.01283 0  -1
sample NTP1 1466365999.786913717 1466365999.01179 
1466365999.0 0 -20
sample NTP0 1466366000.286105199 1466366000.203742759 
1466366000.01283 0  -1
sample NTP1 1466366000.287910142 1466366000.05092 
1466366000.0 0 -20
sample NTP0 1466366000.786555642 1466366000.588773790 
1466366000.01283 0  -1
sample NTP1 1466366000.788280588 1466366000.05092 
1466366000.0 0 -20
sample NTP0 1466366001.287075083 1466366001.194299967 
1466366001.01283 0  -1
sample NTP1 1466366001.288849027 1466366001.05006 
1466366001.0 0 -20
sample NTP0 1466366001.787245534 1466366001.579234001 
1466366001.01283 0  -1
sample NTP1 1466366001.788960481 1466366001.05006 
1466366001.0 0 -20


___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Mike]

On 06/09/2016 11:38 PM, Gary E. Miller wrote:

Yo Mike!

On Thu, 9 Jun 2016 22:25:54 -0400
Mike  wrote:


What I fail to understand is why this just seems to have
appeared out of thin air.  It's not like I just hooked this up
yesterday.  I have toyed with this thing for probably three years off
and on, never had anything like the offset I'm seeing.  Of course
there is no saved data from times when it was running well.

My guess is it depends on the initial conditions.  Jiggle the system
clock 1/2 second forward and back, restart gpsd a few times and
you may see it come and go.

You said you had used the HOWTO, I assume you updated gpsd from git.
Maybe it is recently broken in git.

Let me ponder this a while, and see if I can come up with a patch.  I'll
need to study the code taking into account this new, and unexpected,
data.



RGDS
GARY
I'll experiment with that later and see what I can see.  Yes, gpsd is a 
very recent git pull,  Sat. (4/6/16) if memory serves.


Right now I finally got it hooked to a Windows machine, used the POS 
software that is reportedly for this specific module.  I found a setting 
that sets the NMEA messages to be sent at the top of the second.  This 
gets me back closer to what I seen in the past.


*127.127.28.1.PPS.0 l   15   16  3770.000 0.088   0.008
-127.127.28.0.GPS.0 l   14   16  3770.000 116.808   
0.035


I know they will both settle in better, experience tells me leave it be 
for at least a few hours.  Ultimately I can now log statistics and fine 
tune the fudge factor on NMEA to be much better.


Thanks

Mike
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Eric S. Raymond]

Frank Nicholas :
> It’s been a while (years), and at the time it was pure NTP (no gpsd 
> involved).  Whatever the sentences were that were pushing it over didn’t 
> happen very close together.  I seem to remember that one was reporting if it 
> was using the external vs. internal antenna and that would probably have been 
> a $PMTK sentence.  I was using an external antenna.  When I use it with gpsd, 
> is gpsd “aware” of that chipset and turning some sentences off ($PMTK)?

Checking...yes, in fact gpsd does thin the MTK sentence mix, to emit
only RMC, GGA, GSV, GSV, GRS, GST, ZDA.  So yes, it's one of the
$PMTK sentences pushing you over.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Hal Murray]

e...@thyrsus.com said:
>> Mail crossing in the night.  The burst is starting one sentence before the 
>> PPS not starting in the middle and overflowing into the following second.
> That's... very weird.  I've never seen it happen.
> It sounds as though for some crazy reason the GPS is delivering the PPS
> pulse late.  I'm hard put to imagine how gpsmon could screw this up. 

The PPS pulse is right on.  (I had a scope out.)

It's a Venus chip.  There probably aren't many of them in use with gpsd+ntpd.

There is venus634lp in the test collection, but that only tests the parser, 
not timing.  And even if the test package did check timing, the data might 
have come from a time when it was working.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Eric S. Raymond]

Hal Murray :
> 
> e...@thyrsus.com said:
> > What you should see is the PPS bar, followed by a sentence burst, followed
> > by a pause.  If the burst is wrapping into the next second, it will be
> > instantly obvious because the burst won't finish (no pause) before the next
> > PPS bar. 
> 
> Mail crossing in the night.  The burst is starting one sentence before the 
> PPS not starting in the middle and overflowing into the following second.

That's... very weird.  I've never seen it happen.

It sounds as though for some crazy reason the GPS is delivering the PPS pulse
late.  I'm hard put to imagine how gpsmon could screw this up.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Eric S. Raymond]

Hal Murray :
> 
> e...@thyrsus.com said:
> > That's odd.  The normal semtence budget including GPGSV should fit inside a
> > second.  Are you getting some kind of $PMTK thing that pushes it over? 
> 
> I'm using gpsmon to watch the output.  There is a pause every second.  That's 
> measuring by eyeball.
> 
> Here is a typical second:
> 
> - PPS 
> -
> (49) $GPGSA,A,3,25,05,29,21,202.7,1.6,2.2*38
> (70) $GPGSV,3,1,12,20,78,095,26,29,72,090,28,21,51,288,20,04,41,290,20*7F
> (68) $GPGSV,3,2,12,18,36,210,,05,32,047,26,25,28,190,14,26,28,306,07*7B
> (64) $GPGSV,3,3,12,15,24,131,,13,19,093,,16,08,326,,31,00,258,22*7E
> (72) $GPRMC,034045.787,A,3726.0553,N,12212.2633,W,004.3,175.6,100616,,,A*75
> (40) $GPVTG,175.6,T,,M,004.3,N,008.0,K,A*07
> 
> That's running direct.  If I go through gpsd the PPS line has a time but the 
> pause is always there.
> 
> There is a GPGGA listed up high in the Sentences block but I haven't seen one.

OK, the pause is expected.  That's the quiet time after the sentence burst
has been shipped.

What you should see is the PPS bar, followed by a sentence burst, followed
by a pause.  If the burst is wrapping into the next second, it will be instantly
obvious because the burst won't finish (no pause) before the next PPS bar.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Hal Murray]

> There is a GPGGA listed up high in the Sentences block but I haven't seen one.

Blush.  It was right in front of me.  See below.


g...@rellim.com said:
> gpsd assumes that the fix data for each second starts to arrive just after
> the beginning of the second.  But yours starts so close to the end of the
> second that data will still be spilling into the next second, before
> anything is computed. 

I can confirm that stuff starts just before the PPS.  

Here is an updated version of a 1 second clump:

(78) $GPGGA,035325.788,3726.0641,N,12212.2600,W,6,00,58.8,32.3,M,-32.2,M,,
*60
- PPS 
-
(42) $GPGSA,A,2,19.1,58.8,03.6*0A
(70) $GPGSV,3,1,12,20,75,073,20,29,68,105,23,21,54,295,32,04,42,282,29*72
(66) $GPGSV,3,2,12,18,41,212,,26,31,300,13,15,28,126,,05,27,046,10*79
(66) $GPGSV,3,3,12,25,22,189,13,13,21,088,,16,12,323,,31,00,254,22*79
(72) $GPRMC,035325.788,V,3726.0641,N,12212.2600,W,004.5,008.7,100616,,,E*61
(40) $GPVTG,008.7,T,,M,004.5,N,008.3,K,E*0C



Here are a few seconds with time stamps:
57549 14110.989577 $GPGGA,035510.788,3726.0854,N,12212.2601,W,1,03,1.7,37.1,M,
-32.2,M,,*5B
57549 14111.041549 $GPGSA,A,2,05,21,25,,1.8,1.7,0.7*3A
57549 14111.119555 $GPGSV,3,1,12,20,74,070,02,29,67,107,03,21,55,297,34,18,42,
212,*75
57549 14111.198574 $GPGSV,3,2,12,04,42,281,30,26,31,299,01,15,28,125,,05,26,04
6,22*7F
57549 14111.276568 $GPGSV,3,3,12,13,22,087,19,25,21,189,15,16,13,322,,31,00,25
3,22*7F
57549 14111.359572 $GPRMC,035510.788,A,3726.0854,N,12212.2601,W,000.0,350.7,10
0616,,,A*76
57549 14111.405559 $GPVTG,350.7,T,,M,000.0,N,000.0,K,A*0C

57549 14111.992615 $GPGGA,035511.788,3726.0855,N,12212.2603,W,1,03,1.7,37.2,M,
-32.2,M,,*5A
57549 14112.046597 $GPGSA,A,2,05,21,25,,1.8,1.7,0.7*3A
57549 14112.124603 $GPGSV,3,1,12,20,74,070,01,29,67,107,03,21,55,297,34,18,42,
212,*76
57549 14112.203627 $GPGSV,3,2,12,04,42,281,30,26,31,299,00,15,28,125,,05,26,04
6,22*7E
57549 14112.280608 $GPGSV,3,3,12,13,22,087,19,25,21,189,16,16,13,322,,31,00,25
3,22*7C
57549 14112.364614 $GPRMC,035511.788,A,3726.0855,N,12212.2603,W,000.0,350.7,10
0616,,,A*74
57549 14112.411610 $GPVTG,350.7,T,,M,000.0,N,000.0,K,A*0C


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Gary E. Miller]

Yo Hal!

On Thu, 09 Jun 2016 20:46:58 -0700
Hal Murray  wrote:

> e...@thyrsus.com said:
> > That's odd.  The normal semtence budget including GPGSV should fit
> > inside a second.  Are you getting some kind of $PMTK thing that
> > pushes it over?   
> 
> I'm using gpsmon to watch the output.  There is a pause every
> second.  That's measuring by eyeball.
> 
> Here is a typical second:
> 
> - PPS
>  -
> (49) $GPGSA,A,3,25,05,29,21,202.7,1.6,2.2*38
> (70)
> $GPGSV,3,1,12,20,78,095,26,29,72,090,28,21,51,288,20,04,41,290,20*7F
> (68)
> $GPGSV,3,2,12,18,36,210,,05,32,047,26,25,28,190,14,26,28,306,07*7B
> (64) $GPGSV,3,3,12,15,24,131,,13,19,093,,16,08,326,,31,00,258,22*7E
> (72)
> $GPRMC,034045.787,A,3726.0553,N,12212.2633,W,004.3,175.6,100616,,,A*75
> (40) $GPVTG,175.6,T,,M,004.3,N,008.0,K,A*07

Interesting.  Thanks!  Data we can use.

Your fractional time is .787.  Mike's was 0.940.

I can see that 0.787 should work, and 0.940 problematic.

If yours shifted to 0.940 I bet you would also see failures.

Computation time in the GPS?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpnAnqDeYGt7.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Hal Murray]

e...@thyrsus.com said:
> That's odd.  The normal semtence budget including GPGSV should fit inside a
> second.  Are you getting some kind of $PMTK thing that pushes it over? 

I'm using gpsmon to watch the output.  There is a pause every second.  That's 
measuring by eyeball.

Here is a typical second:

- PPS 
-
(49) $GPGSA,A,3,25,05,29,21,202.7,1.6,2.2*38
(70) $GPGSV,3,1,12,20,78,095,26,29,72,090,28,21,51,288,20,04,41,290,20*7F
(68) $GPGSV,3,2,12,18,36,210,,05,32,047,26,25,28,190,14,26,28,306,07*7B
(64) $GPGSV,3,3,12,15,24,131,,13,19,093,,16,08,326,,31,00,258,22*7E
(72) $GPRMC,034045.787,A,3726.0553,N,12212.2633,W,004.3,175.6,100616,,,A*75
(40) $GPVTG,175.6,T,,M,004.3,N,008.0,K,A*07

That's running direct.  If I go through gpsd the PPS line has a time but the 
pause is always there.

There is a GPGGA listed up high in the Sentences block but I haven't seen one.



-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Gary E. Miller]

Yo Mike!

On Thu, 9 Jun 2016 22:25:54 -0400
Mike  wrote:

> What I fail to understand is why this just seems to have
> appeared out of thin air.  It's not like I just hooked this up
> yesterday.  I have toyed with this thing for probably three years off
> and on, never had anything like the offset I'm seeing.  Of course
> there is no saved data from times when it was running well.

My guess is it depends on the initial conditions.  Jiggle the system 
clock 1/2 second forward and back, restart gpsd a few times and
you may see it come and go.

You said you had used the HOWTO, I assume you updated gpsd from git.
Maybe it is recently broken in git.

Let me ponder this a while, and see if I can come up with a patch.  I'll
need to study the code taking into account this new, and unexpected,
data.



RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpp843uWQgKx.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Mike]

On 06/09/2016 10:04 PM, Gary E. Miller wrote:

Yo Mike!

Back on list since I think I see a real problem here.

On Thu, 9 Jun 2016 21:41:32 -0400
Mike  wrote:


On 06/09/2016 09:26 PM, Gary E. Miller wrote:

Yo Mike!

On Thu, 9 Jun 2016 21:22:29 -0400
Mike  wrote:
  


Yes, one GPGGA and one GPRMC each second, but they are both for the
same fix, one fix per second, always ending in 0.940.

That is bad.

gpsd assumes that the fix data for each second starts to arrive just
after the beginning of the second.  But yours starts so close to the end
of the second that data will still be spilling into the next second, before
anything is computed.

Some of your lines are 78 chars long.  At 9600 each char takes 0.001
seconds.  78 chars is 0.078 seconds.  So even if the GPGGA is started
at exactly 0.940 into the second, the sentence can not be received, and
checksum checked, before the next second starts.  0.940 + 0.078 is 1.018
seconds.

gpsd may then pair the PPS with the wrong second.  Which is the sypmtom
you see.

Groan...  I'm gonna have to sleep on this one...

RGDS
GARY
Okay so I can understand that explanation.  Thank you for the detail.  
What I fail to understand is why this just seems to have appeared out of 
thin air.  It's not like I just hooked this up yesterday.  I have toyed 
with this thing for probably three years off and on, never had anything 
like the offset I'm seeing.  Of course there is no saved data from times 
when it was running well.


Mike
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Gary E. Miller]

Yo Mike!

Back on list since I think I see a real problem here.

On Thu, 9 Jun 2016 21:41:32 -0400
Mike  wrote:

> On 06/09/2016 09:26 PM, Gary E. Miller wrote:
> > Yo Mike!
> >
> > On Thu, 9 Jun 2016 21:22:29 -0400
> > Mike  wrote:
> >  
> >> On 06/09/2016 09:03 PM, Gary E. Miller wrote:
> >> Hmm.  And do you see two timestamps a second or just one?
> >>
> >> How about you just send me 10 sconds of output?  
> If I'm reading this output right I see two timestamps each second.
> GPGGA and GPRMC
> 
> root@rpi-ticker:/home/mike# cat /dev/gpsd0
> $GPGGA,013525.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*6E
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,05,19,26,127,21,29,23,312,19,09,19,053,*77
> $GPGSV,3,3,12,20,12,223,19,23,03,031,,17,02,131,,13,00,167,*75
> $GPRMC,013525.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*73
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013526.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*6D
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,05,19,26,127,21,29,23,312,19,09,19,053,*77
> $GPGSV,3,3,12,20,12,223,20,23,03,031,,17,02,131,,13,00,167,*7F
> $GPRMC,013526.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*70
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013527.940,4053.2374,N,08231.2681,W,1,06,1.3,409.2,M,-33.9,M,,*6B
> $GPGSA,A,3,25,19,05,02,06,12,,,2.9,1.3,2.6*32
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,10,19,26,127,21,29,23,312,19,09,19,053,*73
> $GPGSV,3,3,12,20,12,223,20,23,03,031,,17,02,131,,13,00,167,*7F
> $GPRMC,013527.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*71
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013528.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*63
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,09,19,26,127,20,29,23,312,19,09,19,053,*7A
> $GPGSV,3,3,12,20,12,223,20,23,03,031,,17,02,131,,13,00,167,*7F
> $GPRMC,013528.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*7E
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013529.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*62
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,08,19,26,127,21,29,23,312,19,09,19,053,*7A
> $GPGSV,3,3,12,20,12,223,21,23,03,031,,17,02,131,,13,00,167,*7E
> $GPRMC,013529.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*7F
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013530.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*6A
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,12,19,26,127,21,29,23,312,20,09,19,053,*7B
> $GPGSV,3,3,12,20,12,223,21,23,03,031,,17,02,131,,13,00,167,*7E
> $GPRMC,013530.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*77
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013531.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*6B
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,11,19,26,127,20,29,23,312,20,09,19,053,00*79
> $GPGSV,3,3,12,20,12,223,21,23,03,031,,17,02,131,,13,00,167,*7E
> $GPRMC,013531.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*76
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013532.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*68
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,22*71
> $GPGSV,3,2,12,06,34,071,09,19,26,127,20,29,23,312,19,09,19,053,00*7A
> $GPGSV,3,3,12,20,12,223,20,23,03,031,,17,02,131,,13,00,167,*7F
> $GPRMC,013532.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*75
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A
> $GPGGA,013533.940,4053.2374,N,08231.2681,W,1,05,1.7,409.2,M,-33.9,M,,*69
> $GPGSA,A,3,25,19,05,02,123.2,1.7,2.7*3B
> $GPGSV,3,1,12,02,72,009,22,05,57,208,30,12,42,237,25,25,36,285,21*72
> $GPGSV,3,2,12,06,34,071,08,19,26,127,20,29,23,312,19,09,19,053,00*7B
> $GPGSV,3,3,12,20,12,223,20,23,03,031,,17,02,131,,13,00,167,*7F
> $GPRMC,013533.940,A,4053.2374,N,08231.2681,W,000.0,231.7,100616,,,A*74
> $GPVTG,231.7,T,,M,000.0,N,000.0,K,A*0A

Yes, one GPGGA and one GPRMC each second, but they are both for the
same fix, one fix per second, always ending in 0.940.

That is bad.

gpsd assumes that the fix data for each second starts to arrive just
after the beginning of the second.  But yours starts so close to the end
of the second that data will still be spilling into the next second, before
anything 

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

[Gary E. Miller]

Yo Hal!

On Thu, 09 Jun 2016 17:29:19 -0700
Hal Murray  wrote:

> > Can you send me the output of this when it fails:  
> 
> Not anytime soon.  It's working correctly and I can't predict when it
> will fail.

Luckily we have a hard test case to work on.

But, I have found a way to predict some of these buffer bloats things.
The GPS sends moer data when it sees a lot of sats.  So when gpsd
fails, just run cgps and see if that correlates for you.

> g...@rellim.com said:
> > Well, then not the case at hand.  the current problem is two edges
> > per second, 500 milliSec apart.   
> 
> How would an extra pulse at 500 ms turn into a 1 second error?

Beats me.  If I already knew I would have coded a way to prevent it.

That is why I'm asking for debug data.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgp7QG6QvhG9H.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Mike]

On 06/09/2016 08:37 PM, Gary E. Miller wrote:

Yo Mike!

On Thu, 9 Jun 2016 20:26:01 -0400
Mike  wrote:

Skytraq ships varying firmware, so that is not definitive.

Worse that says this:

 "The 1PPS pin is multiplexed with some debug mode function whose
 mode is to be determined at end of power on reset cycle. To avoid
 incorrect function do not pull-up or pull- down this signal."

What could possibly go wrong there?
Okay, that looks really suspect to me.  I'll try and get this thing 
connected to a Windows box and see if their utility will show me any 
useful info.

And the serial is connected directly to a RasPi?

Yes, it's directly connected to the Pi.

If I hook it up to a PC, or with a serial to USB adapter will I be
able to see more about the edge being seen?

Depends how good you are.  I leave that to you.


Okay, a learning challenge!

No double pulse there.  Looks good.

Hmm, it just occured to me, it is your SHM0 that is sending 2 updates
a second?  Was it the SHM0?  If so, that is not a problem, as long
as the time stamps look right, it just means the NMEA is reporting 2x
a second.  The only thing we care about is the SHM1.

Yes, it was SHM0

I still need the debug output.  Send me the result of this:
# gpsd -nND 9 /dev/ttyXX |# fgrep PPS > gpsd.log

Sent

Mike
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Gary E. Miller]

Yo Mike!

On Thu, 9 Jun 2016 20:26:01 -0400
Mike  wrote:

> >> Is seeing NTP0 twice like this typical?  
> > Nope, should be impossible.  Looks to be exactly 500 milliSec apart.
> > Do you have a square wave output?  Or a 2Hz output?
> >
> > How about you put ppstest on it to see.  Except on the Pi you only
> > see one edge, so can not tell square wave from 2 Hz.  Got a scope?
> > What is the GPS again?  
> GPS module is a ST22, SkyTraq Venus 6 chipset.
> 
> http://www.perthold.de/BINARY/gps-st22.pdf Datasheet is here.

Skytraq ships varying firmware, so that is not definitive.

Worse that says this:

"The 1PPS pin is multiplexed with some debug mode function whose
mode is to be determined at end of power on reset cycle. To avoid
incorrect function do not pull-up or pull- down this signal."

What could possibly go wrong there?

And the serial is connected directly to a RasPi?

> It's an oddball corner case I'm sure...

Yes, and the Skytraq are chatty, making 9600 suspect, but unrelated to
the PPS issue.

> If I hook it up to a PC, or with a serial to USB adapter will I be
> able to see more about the edge being seen?

Depends how good you are.  I leave that to you.

> mike@rpi-ticker:~ $ sudo ppstest /dev/pps0
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1465518012.001419932, sequence: 12052 - clear 
> 0.0, sequence: 0
> source 0 - assert 1465518013.001419316, sequence: 12053 - clear 
> 0.0, sequence: 0
> source 0 - assert 1465518014.001418700, sequence: 12054 - clear 
> 0.0, sequence: 0
> source 0 - assert 1465518015.001418086, sequence: 12055 - clear 
> 0.0, sequence: 0
> source 0 - assert 1465518016.001416472, sequence: 12056 - clear 
> 0.0, sequence: 0
> source 0 - assert 1465518017.001417858, sequence: 12057 - clear 
> 0.0, sequence: 0

No double pulse there.  Looks good.

Hmm, it just occured to me, it is your SHM0 that is sending 2 updates
a second?  Was it the SHM0?  If so, that is not a problem, as long
as the time stamps look right, it just means the NMEA is reporting 2x
a second.  The only thing we care about is the SHM1.

I still need the debug output.  Send me the result of this:
# gpsd -nND 9 /dev/ttyXX |# fgrep PPS > gpsd.log

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpREyL8Ng_Fs.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Frank Nicholas]

> On Jun 9, 2016, at 8:27 PM, Gary E. Miller  wrote:
> 
> Clockmaker is not even released, much less widely tested.  9600 baud
> is the default speed for the Adafruit and Uputronics HATs and as
> we are still characterizing those we can not yet know if that is a good
> speed for those yet.

I can tell you from experience, that with the Adafruit hat, and the default 
sentences, 9600 baud is not fast enough.  Some periodic sentences (period > few 
seconds) will push a cycle past one (1) second.  Even when used with PPS, 
eventually it will eventually be marked as a false ticker.

When this was my main NTP server on a Pi, I turned off all the sentences, 
except the ones I wanted, to avoid this issue.

Thanks,
Frank___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Mike]

On 06/09/2016 07:08 PM, Gary E. Miller wrote:

Yo Mike!

On Thu, 9 Jun 2016 18:21:32 -0400
Mike  wrote:


Forgot this in the original post...

ntpshmmon version 1
#  Name   Seen@Clock Real   L Prec
sample NTP0 1465510765.147894340 1465510765.120560175  1465510764.938999891 0  
-1
sample NTP0 1465510765.648664035 1465510765.468806532  1465510764.938999891 0  
-1



Is seeing NTP0 twice like this typical?

Nope, should be impossible.  Looks to be exactly 500 milliSec apart.
Do you have a square wave output?  Or a 2Hz output?

How about you put ppstest on it to see.  Except on the Pi you only
see one edge, so can not tell square wave from 2 Hz.  Got a scope?
What is the GPS again?

GPS module is a ST22, SkyTraq Venus 6 chipset.

http://www.perthold.de/BINARY/gps-st22.pdf Datasheet is here.

It's an oddball corner case I'm sure...
No scope easily available right now.
If I hook it up to a PC, or with a serial to USB adapter will I be able 
to see more about the edge being seen?


mike@rpi-ticker:~ $ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1465518012.001419932, sequence: 12052 - clear 
0.0, sequence: 0
source 0 - assert 1465518013.001419316, sequence: 12053 - clear 
0.0, sequence: 0
source 0 - assert 1465518014.001418700, sequence: 12054 - clear 
0.0, sequence: 0
source 0 - assert 1465518015.001418086, sequence: 12055 - clear 
0.0, sequence: 0
source 0 - assert 1465518016.001416472, sequence: 12056 - clear 
0.0, sequence: 0
source 0 - assert 1465518017.001417858, sequence: 12057 - clear 
0.0, sequence: 0


Mike
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Mike]

On 06/09/2016 07:20 PM, Gary E. Miller wrote:

Yo Mike!

On Thu, 9 Jun 2016 18:21:32 -0400
Mike  wrote:


Is seeing NTP0 twice like this typical?

I'm looking at the code, maybe a couple of things to double check.

Can you send me, off list, the output of this command, about
60 seconds worth should do it.  As long as is captures a few good
PPS pulses.

# gpsd -nND 9 /dev/ttyXX |& fgrep PPS > text.log
I'll send it if you still want after this reply.  After I posted seeing 
NTP0 twice, stopped everything, issued ipcrm -a, restarted gpsd and now 
the output is normal again.  PPS is still off 1sec...


As to the baud rate, I built this using clockmaker --build, which sets 
the baud to 9600 by default.


Mike
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

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

[Gary E. Miller]

Yo Hal!

On Thu, 09 Jun 2016 17:04:08 -0700
Hal Murray  wrote:

> > GPS module is a ST22, SkyTraq Venus 6 chipset.  
> [ntpq -p shows PPS link off by a second.]
> 
> It's a gpsd bug/quirk.  I've seen the same thing on a PC with a Venus
> chip connected via USB.
> 
> I mentioned it a month or two ago but it fell through the cracks.

Can you send me the output of this when it fails:

# gpsd -nND 9 /dev/ttyXXX |& fgrep PPS > gpsd.log

That tells me which path I need to check for errors.

> g...@rellim.com said:
> > I suggest 38400 or higher.  9600 or less would cause this exact
> > symptom.   
> 
> I thought gpsd was supposed to do the right thing.

gpsd does not know how backedup the OS serial buffer is.  Just like
another buffer bloat problem.

> g...@rellim.com said:
> > Got a scope?   
> 
> I have one.  I'm seeing a 10 microsecond pulse.  One per second.

Well, then not the case at hand.  the current problem is two edges
per second, 500 milliSec apart.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpgZkkQojoaA.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Hal Murray]

> GPS module is a ST22, SkyTraq Venus 6 chipset.
[ntpq -p shows PPS link off by a second.]

It's a gpsd bug/quirk.  I've seen the same thing on a PC with a Venus chip 
connected via USB.

I mentioned it a month or two ago but it fell through the cracks.

My case occasionally flips from one mode to the other.  Occasionally is 
ballpark of a day.



g...@rellim.com said:
> I suggest 38400 or higher.  9600 or less would cause this exact symptom. 

I thought gpsd was supposed to do the right thing.


g...@rellim.com said:
> Got a scope? 

I have one.  I'm seeing a 10 microsecond pulse.  One per second.

That's from a Venus chip on a Sparkfun breakout board from 4 years ago.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Gary E. Miller]

Yo Mike!

On Thu, 9 Jun 2016 18:18:33 -0400
Mike  wrote:

> 9600, which is where it's always been...

I find 9600 marginal.  It works for most, but not all.  Check the
serial stream to be sure it totally completes the cycle every 
second.  

If you are in 2Hzz or 5Hz mode, or have extra NMEA turned on then
9600 is not good enough.

> The NMEA will settle out much better, it's the PPS that is really 
> throwing me off.

Your NMEA looked off to me.

> I'll have to see if I can get one of the Windows laptops here and try 
> and set the baud rate higher.  I've been completely unsuccessful
> trying to set it with Linux.

gpsd works fine for some GPS, and not for others.  Please file a bug
report if you can not get it to work in gpsd.  Try in both gpsd mode
and gpsctl standalone mode.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpluXQz89Zkq.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Gary E. Miller]

Yo Mike!

On Thu, 9 Jun 2016 18:21:32 -0400
Mike  wrote:

> Forgot this in the original post...
> 
> ntpshmmon version 1
> #  Name   Seen@Clock Real   L Prec
> sample NTP0 1465510765.147894340 1465510765.120560175  1465510764.938999891 0 
>  -1
> sample NTP0 1465510765.648664035 1465510765.468806532  1465510764.938999891 0 
>  -1


> Is seeing NTP0 twice like this typical?

Nope, should be impossible.  Looks to be exactly 500 milliSec apart.
Do you have a square wave output?  Or a 2Hz output?

How about you put ppstest on it to see.  Except on the Pi you only
see one edge, so can not tell square wave from 2 Hz.  Got a scope?
What is the GPS again?

> I can't ever recall seeing it that way.

square wave is uncommon, but I have seen it.

What I have not seen is the gpsd edge detection circuitry output
2x in the same second.  There is supposed to be logic to prevent it, and
it used to work.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpKeg5fqyIX9.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Mike]

On 06/09/2016 05:47 PM, Gary E. Miller wrote:

Yo Mike!

On Thu, 9 Jun 2016 17:21:16 -0400
Mike  wrote:


The output from ntpq -p that is relevant here.

xSHM(1)  .PPS.0 l8   16  3770.000 -1001.1 0.009
-SHM(0)  .GPS.0 l7   16  3770.000 -363.77 9.805

That is not wacky, that is off by exactly one second. gpsd is not
getting the right sentence for the PPS.  What is the speed on your NMEA?
I suggest 38400 or higher.  9600 or less would cause this exact symptom.

And your NMEA fudge is way off.

RGDS
GARY
---

Forgot this in the original post...

ntpshmmon version 1
#  Name   Seen@Clock Real   L Prec
sample NTP0 1465510764.647583630 1465510764.464160236 
1465510763.938999891 0  -1
sample NTP1 1465510765.004051736 1465510765.003485754 
1465510764.0 0 -20
sample NTP0 1465510765.147894340 1465510765.120560175 
1465510764.938999891 0  -1
sample NTP0 1465510765.648664035 1465510765.468806532 
1465510764.938999891 0  -1
sample NTP1 1465510766.004524158 1465510766.003486190 
1465510765.0 0 -20
sample NTP0 1465510766.149659722 1465510766.117558703 
1465510765.938999891 0  -1
sample NTP0 1465510766.650198423 1465510766.465998053 
1465510765.938999891 0  -1
sample NTP1 1465510767.003765616 1465510767.003486625 
1465510766.0 0 -20


Is seeing NTP0 twice like this typical?  I can't ever recall seeing it 
that way.


Mike
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: refclock 28 gone wacky on me

[Gary E. Miller]

Yo Mike!

On Thu, 9 Jun 2016 17:21:16 -0400
Mike  wrote:

> The output from ntpq -p that is relevant here.
> 
> xSHM(1)  .PPS.0 l8   16  3770.000 -1001.1 0.009
> -SHM(0)  .GPS.0 l7   16  3770.000 -363.77 9.805

That is not wacky, that is off by exactly one second. gpsd is not
getting the right sentence for the PPS.  What is the speed on your NMEA?
I suggest 38400 or higher.  9600 or less would cause this exact symptom.

And your NMEA fudge is way off.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


pgpAj9J6amaKd.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

refclock 28 gone wacky on me

[Mike]

I'm at a loss here as to why my offset on 28.1 is so far off. Typically 
the offset settles in around 0.008 and jitter around 0.004.  This has 
been setup from the microserver HOWTO nearly verbatim using clockmaker 
etc. etc. etc.  Certainly not placing any blame there, as previous 
setups following those steps haven't shown results this wacky.  I've 
checked everything I can think of.  Last run was around 24 hours with no 
change.  This afternoon, shut it all down, pulled battery on module, let 
go an hour restarted it all back up with same results right off.  I'd be 
grateful for any input, or suggestions at this point.


GPS module is a ST22, SkyTraq Venus 6 chipset.

http://www.perthold.de/BINARY/gps-st22.pdf  Datasheet is here.

Raspberry Model B Revision 2.0, configured for the Uputronics HAT.

Linux rpi-ticker 4.4.11+ #888 Mon May 23 20:02:58 BST 2016 armv6l GNU/Linux
gpsd: 3.17~dev (revision release-3.16-346-g24cdae0)
ntpd 0.9.4-44652aa Jun  5 2016 02:25:36

352 ?S/dev/gpsd0
354 ?SLs0:03 /usr/local/sbin/ntpd -p /var/run/ntpd.pid -N -g 
-u 105:110


ntpd is running as ntp:ntp

The output from ntpq -p that is relevant here.

xSHM(1)  .PPS.0 l8   16  3770.000 -1001.1   
0.009
-SHM(0)  .GPS.0 l7   16  3770.000 -363.77   
9.805


/etc/ntp.conf contents

statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 127.127.28.1 prefer minpoll 4 maxpoll 4
fudge 127.127.28.1 refid PPS
server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.210 refid GPS
driftfile /var/log/ntpstats/ntp.drift

Mike

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel