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

[Alexander Carver]

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

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.  Because of that, 
MID 52 isn't a red herring.  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.

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