Re: [gpsd-users] PPS MID 52 (0x34) working?

[Alexander Carver]

On 6/5/2012 12:13, Gary E. Miller wrote:
> Yo Alexander!
>
> On Tue, 05 Jun 2012 10:48:42 -0700
> Alexander Carver<address@hidden>  wrote:
>
> > On 6/5/2012 00:52, Gary E. Miller wrote:
> > > Yo Tomalak!
> > >
> > > On Tue, 05 Jun 2012 04:20:44 +0100
> > > "Tomalak Geret'kal"<address@hidden>   wrote:
> > >
> > > > On 04/06/2012 23:33, Gary E. Miller wrote:
> > > > > > With MID 52 on, my offset wanders +/-40ms.  With MID 52 off, the
> > > > > > wander is reduced to about +/-10ms.
> > > > > Big deal.  Your PPS should be just a few micro Sec jitter, thus
> > > > > the uselessness of the MID 52.
> > > > >
> > > > > Just be sure your NMEA is running faster than 4800, preferably
> > > > > 38,400 or better.
> > > > "Big deal"? For serious, industrial applications, 10ms is a
> > > > HUGE deal.
> > >
> > > EXACTLY my point!  He should be using real PPS and then getting
> > > a few micro Sec of jitter.  Since the guy said he HAS real PPS
> > > this is what he should focus on.  MID 52 is a red herring.
> >
> > I _DO_ have real PPS working but not through gpsd, only through the
> > PPS/ATOM driver in ntpd.  The sparc serial driver does not permit
> > double access to the serial port (one to read the TX/RX data and the
> > second to read DCD).  Anything that requires double access (gpsd,
> > ntpd's NMEA driver, etc.) will fail to see the PPS.  The current
> > setup brings the single GPS receiver to two serial ports.  Serial
> > port A provides TX/RX access to get to the GPS data.  Serial port B
> > allows the use of the PPS via DCD.  The system has ntpd configured to
> > read the GPS time via gpsd on SHM(0) and reads the PPS ticks via the
> > ATOM driver attached to serial port B.  SHM(1) is ignored because it
> > isn't populated by gpsd (no PPS via DCD).
>
> Yes, you explained all that before.  Not sure I believe your thoughts
> on 'double access', but if that is really the case then gpsd is
> not going to be a lot of help to you.  gpsd time will suck.

Yes, I understand this which is why ntpd is running with PPS and using 
gpsd as the seconds marker and not the final source of time.

> What you have not said is the larger context.  Do you have other
> ntpd time sources?  How good are they?  Are they always connected?
> These are very important pieces of your puzzle.

Yes, I have other sources always connected.  I think we're talking past 
each other.  My *system* jitter is fine, I am only speaking of the 
jitter on the single gpsd source (SHM) and it's behavior with and 
without MID 52.

> > I can NOT get gpsd to see the PPS signal on the same serial port as
> > its data because the serial driver just doesn't allow it.
>
> I have a real hard time believing that.  Have you tried?  Have you
> enabled kernel PPS?

Already have kernel PPS enabled, that's what ntpd is using via the 
PPS/ATOM refclock.  That part works.  But a process in general is not 
able to open the serial port and monitor DCD separately the way gpsd or 
ntpd normally tries because the sparc driver just doesn't function that 
way.  PPS has to come in from a second serial port so that ntpd can find 
it.  If I bring it in with the receiver data on a single port it doesn't 
work.

> > Because of that, MID 52 isn't a red herring.
>
> You are conflating 2 issues.  MID 52 is on NMEA, thus unrelated to
> reall PPS except by a bad choice of names by the vendor.  As you
> have seen, enabling MID 52 yields worse results than without it, so
> turn it off!

I never asked about real PPS.  I was only asking why MID 52 is causing 
so much more instability in the offset of only gpsd's SHM (again not the 
system offset, just the SHM offset) when it is supposedly trying to 
improve that data.

> >   As far as gpsd is concerned, the
> > serial driver issue means I have no PPS signal via DCD (ntpd has it
> > as I mentioned above and that's a separate thing) so therefore MID 52
> > technically applies by your earlier statement.  The reality, however,
> > is that it makes things worse for the data present in SHM(0) though I
> > don't understand why.
>
> MID 52 makes things worse because it is badly implemented by the GPS
> vendor.  Even if properly implemented the results would be in the
> tens of milliSec of jitter.  Since it does not work, don't use it!
>
> > With MID 52 enabled, the jitter in SHM(0) is 15-20ms as reported by
> > ntpd.  With MID 52 disabled, the jitter is less than 10 ms and
> > typically less than 5ms (this increases if the satellite
> > constellation configuration is suboptimal or I lose signal).
>
> Yup, as expected.  And your jitter over the course of a day will be up
> to 10x that.  If that is unacceptable then you need to get PPS to work,
> either by way of gpsd or directly to ntpd.
>
> Once PPS is working you need to get ntpd to NOT use the gpsd time as
> the wander will totally confuse ntpd with MID 52 on or off!  Which is
> why I tell you to ignore the MID 52, that is NOT your basic problem.
> NMEA time, with or without MID 52, is the problem.
>
> One way I work around the problem is to tell ntpd to 'prefer' the PPS
> time and then add a fudge to the SHM(0) time so that ntpd thinks SHM(0)
> is wacko and will not use it, or just turn it off if you can.

PPS is working, has been for a while.  All of my questions relate only 
to the offset and jitter of gpsd's SHM not to the system as a whole. 
The system as a whole is fine and stable.