Yo Alexander!
On Tue, 05 Jun 2012 14:01:34 -0700
Alexander Carver<address@hidden> wrote:
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?
Once in a while it does lock back onto SHM(0) for about one minute
and then switches back to PPS/ATOM. This usually happens when the
dispersion is great enough to cause ntpd to disbelieve the PPS tick.
I usually only see it when the constellation is really bad or I've
lost nearly all the satellites (for reasons yet unknown).
I see this happen when randomly the NMEA time and the PPS time line up
exactly due to random chance. ntpd flips a coin on which to believe and
picks the NMEA time. then the NMEA time wanders off and ntpd follows it
instead of PPS time, until it realizes how bad the NMEA time is.
My solution is to add a 400 milliSec fudge to NEMA time so that ntpd
will never pick it unless all else fails.
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?
It's not a "problem" is a curiosity about why a particular feature
(turned on by default) is actually making things worse. I have it
turned off now because it's obviously bad, I just want to understand
why. As far as I can tell, MID 52 is being emitted exactly with the
PPS pulse according to the desired SiRF spec.
You have never told us what speed you are using. Assuming 4800, you
get about 500 chars per sec. That is 2 milli Sec a char! NMEA is
a variable length string, so when the sentence varies by 5 chars in
length the time as seen by gpsd varies by 10 milli Sec! Add to that
all the other random delays in processing in the GPS and you quickly
get up to +/- 100milliSec, or more. If you work very hard you
might be able to squeeze a little better accuracy from your GPS, but
at the same time you'll prolly make someone else's GPS that much worse.
If you have a lot of time to spend on it see if you can improve it,
but many have already tried.
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?
However a terminal program opens the serial port seems to be
different from the way gpsd and ntpd open the serial port because
neither of them are able to read the DCD line.
One, I don't believe that gpsd opens a serial port any differently
than a terminal program. Two, if DCD does not work for you then
try another input pin. gpsd does not care which pin you use, it
autodetects.
Operation with a modem requiers the DCD pin to work, so only broken
hardware would prevent you from reading it.
The sparc driver is the Zilog Z8530 using sz8530tty.c
Odd. I have linux 3.4.0, and that is not present:
# find /usr/src/linux -name sz8530tty.c
#