On 3/7/2012 4:25 AM, David J Taylor wrote:
"Ron Frazier (NTP)" <timekeepingntpl...@c3energy.com> wrote in message
news:4f567490.1030...@c3energy.com...
[]
David and others,
I do appreciate the help and advice you've given me to this point. I
read all the replies up to this point on the ESR thread and this
thread. That includes David's mention of NMEA variances on the Garmin
and Chris's mention that NMEA "within the second" is within spec. I
still think something is wrong with the NTP subsystem in my opinion.
I'm not going to lose a lot of sleep over it. I report it here just
in case someone who knows how wants to investigate it.
All reports are appreciated.
Just because PPS and RS-232 work better, doesn't mean the NMEA driver
and / or the Meinberg monitor shouldn't work properly. I will NEVER
be able to use RS-232 on this computer without a USB - serial adapter
(which I intend to try). It doesn't exist.
The box I tried (a Sitecom USB hub) actually carried the DCD signal
over USB, and allowed a much lower jitter than Internet servers alone.
I have an adapter based on the Prolific chipset which is supposed to
pass the handshaking signals. It's the Trendnet TU-S9. I'm going to
try that, but I'll certainly keep the one you mentioned in mind.
The capabilities of a USB GPS are perfectly adequate for my
application. + / - 6 ms is just fine. There are, by the way, many
other applications where 6 ms would be acceptable.
Yes, I completely agree. The problem is that we don't know how much
jitter may be present on the NMEA output of your particular GPS. If
it's like the GPS 18x LVC, then using the serial output alone may not
be much better than using Internet servers, as the jitter from sending
over USB may well be insignificant compared to the GPS NMEA jitter.
That is the $ 20,000 question. From our prior discussion, it looks like
you're saying the Garmin has a jitter in the start time of the NMEA
sentence of about 170 ms. I appear to be observing a similar phenomenon
here, but I'm not totally convinced it's real. I think the monitor
program may be lying to me about the offsets of the internet servers.
If it is real, the variation is very slow, and it takes a day or two to
swing from about + 80 ms from NIST to - 80 ms from NIST. I have nothing
to explain that 900 ms jump I mentioned. Is this "wobble" effect
something that has been observed with other GPS units?
For comparison, the best I can get on Windows polling exclusively
from the internet, with any kind of reasonable polling interval and
not pounding the internet servers all the time, is about + / - 80
ms. So, using the USB GPS is about a 12 fold improvement. Also,
there are many many computers where there is no RS-232 port. ESR's
application is an example. So, the question is not is NMEA great,
the question is - is it good enough for me? I will be pursuing PPS
with the Sure board for intellectual reasons, but there is no reason
that I have to do that.
There is a question about the Windows port of NTP which I don't have
the answer to. Dave Hart has put a lot of work into the Windows port,
both in the serial data handling, and the serial port driver itself.
What I don't know is whether his enhancement to the serial port
time-stamping also apply to the virtual COM port drivers such as would
be used for NMEA over USB. I expect they would, though. I would
recommend using at least ntp 4.2.7p258 with Windows for the best
results, and also setting the system environment variable
NTPD_USE_SYSTEM_CLOCK to any value when using Windows Vista or Windows 7.
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#environment
Are you using that version or later?
On Windows, I'm running 4.2.7p259. On Ubuntu Linux, when I boot into
it, I'm running the version from the Ubuntu repositories which is about
2 years old. I did a manual upgrade to try to troubleshoot some abrupt
jumps in the reported offsets, but that didn't solve the problem. I
retrograded back to the one that's in the repositories as doing a manual
install breaks several things. It's better to use the package manager.
There is no way in the world I should have an offset from internet
servers of 950 ms one minute and then show an offset from internet
servers of 50 ms thirty seconds later after I restart NTPD, when I'm
locked to my GPS time in both cases.
Agreed, but it suggests that the NMEA data may be timed so that it is
ambiguous as to which second it means. I did also wonder whether your
GPS might have lost lock, and not indicated that to NTP. I don't
recall whether all sentences include a "lock" or "valid" indicator,
and whether NTP looks at all such indicators. Could someone check or
confirm this, pr provide a pointer to the Web page with this information?
I can tell when my GPS is working consistently and when it's not.
Something is wonky here and I don't think it's the GPS. I'm trying
to figure out if the GPS is "drifting" or if NTP is reporting
internet server offsets wrong or if there is a problem with the
Meinberg monitor. If everything is running properly, I should be able
to maintain that + / - 6 ms all day, every day, and the variance
between my clock and at least one NIST clock should be minimal and
consistent. I don't expect great results from NMEA. But I do expect
acceptable results, and consistent results. My GPS should be more
than capable of outputting NMEA sentences consistently. I've seen it
maintain that + / - 6 ms performance for days.
.. suggesting that it may be a loss of GPS lock which is the issue, as
that may not happen very often.
It's only outputting the GPZDA sentence, and that only has time in it.
.. and it doesn't carry any indicator of whether that time is valid or
not, according to:
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
May I suggest using the $GPGGA sentence instead even if it is a little
longer? The $GPZDG sentence appears to be the only other one with a
"valid" indicator.
I think the satellite lock was good at the time but cannot prove it. It
looks to me like the Meinberg monitor is reporting the server offsets
wrong. I'm presuming it uses the ntpq command internally to get that
data but I don't know. I'm currently experimenting with all internet
servers noselected to see what happens. I have a variation from my GPS
time going from 11 of 12 internet servers within 9.99 ms (single digit
before the decimal point) to 4 of 12 internet servers within 9.99 ms. I
have not observed any more 950 ms offsets to the internet servers. I
just checked while typing this and 8 of 12 internet servers are within
9.99 ms.
Based on the document you linked to, I can see only 2-3 ways to check
for a valid signal. One is the POS_STAT variable. One is the V
variable. And one is the AA.BB (signal strength) variable, maybe.
As far as I can tell, only GPRMC and GPGLL have the POS_STAT variable.
As you mentioned, only GPZDG has the V variable. It also has the signal
strength variable.
It doesn't look like GPGGA has any validation in it.
I do realize that the timing of the NMEA sentence is much less important
if you have PPS, but this is what I have to work with at the moment. It
would be good to know if NMEA can be used for at least a somewhat
reliable time signature. Of course, as you said, if there is a 170 ms
wobble in the NMEA data, the few ms of jitter in USB is irrelevant and
NMEA only is largely useless. One thing I'm trying to figure out is if
the NMEA data really has this wobble in the start times of the sentences
or if there is some kind of false reporting from the NTP subsystem. If
the wobble does exist, I'm wondering if it is intrinsic to all GPS's.
I am reluctant to switch to another sentence for a few reasons, assuming
NMEA only is ultimately usable at all for a few reasons:
A) The Trimble Resolution T manual specifically recommends GPZDA for
timekeeping.
B) I was using GPGGA before, and was getting about + / - 12 ms accuracy
as I recall. Going to GPZDA improved it to + / - 6 ms.
C) I don't know if NTP even looks at the validity flags in the data.
D) Any NMEA sentence which reports position will be varying in length,
which will probably add more jitter to the communications path.
The unit has nothing better to do than to tell me the time. It
should not be "drifting". But, SOMETHING is drifting, and I'd just
like to know what it is. I REALLY think there is a problem with NTP
or Meinberg, but I could be wrong. It would be nice to know if I
have to avoid all SIRF GPS's for this purpose. I think NTP should be
able to work just fine, within the limits of the equipment, on NMEA
only.
No offense is intended in any way by anything I've said. As I said
before, I do appreciate all the help. 8-)
Sincerely,
Ron
I agree with you, Ron, that providing a serial output is steady, NTP
should work perfectly with it. By using a very high baud rate, and a
single sentence, you are making the best attempt to reduce the
ambiguity between the beginning and the end of the NMEA data.
I recall that there is a way of monitoring one source against another.
Someone will correct me, but it's something like using NOSELECT
against that source. Use the Internet servers as a reference, and
monitor peerstats. Then look for all the lines with 127.127.20.1 (or
whatever for the NMEA ref clock), and plot their offsets.
The amount of time I have comes and goes. It may have to go, to a
point, since I have to do some things other than email like paying bills
and other household stuff.
This is the part of my ntp.conf file in windows related to stats. Do I
need to add anything else? I think all the stats are already on in Linux.
enable stats
statsdir "C:\NTP Service\NTP\etc\"
statistics loopstats
Thanks for the help.
Sincerely,
Ron
May be worth doing if you have the time.
Cheers,
David
--
(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)
Ron Frazier
timekeepingdude AT c3energy.com
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
