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?