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

[Gary E. Miller]

Yo Alexander!

On Tue, 05 Jun 2012 13:02:33 -0700
Alexander Carver <address@hidden> wrote:

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

Odd, you mentioned in a previous post that you were having problems 
with ntpd sometimes locking onto SHM(0) time instead of PPS time.
If that is no longer the case, what was your solution?

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

If the system jitter is fine, that what's the problem?  NMEA time, with
and without MID 52, will suck.  All you need it for is to get 
within 499 milli Sec of real time so the PPS can pull in the rest.

Since that is working, what is the problem?

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

You keep saying that, but I keep disbelieving you.  So merely restating
your proposition over and over yields no progress. If what you say is
true then even a trivial terminal emulator could never work.  What is
the name of your kernel driver so I can check the kernel source?

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

Asked, and answered.  As previously stated: MID 52 is badly implemented
in the GPS.  Nothing we can do about it. If you want it fixed you have
to get your GPS vendor to fix it. Just turn it off and ignore it, or
not.  Either way you are getting close to the actual second so PPS can
do the rest.  So in the end there is no problem.

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

So what is the problem?  If the goal is stable system jitter you got it.
What you see is 100% normal and the results of design decisions made in
the GPS.  NMEA based time just sucks and only the GPS vendor can fix it.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

signature.asc
Description: PGP signature