Michael Eder me...@whoi.edu wrote:
We have looked at our GPS on a scope, the PPS it is dead on and the NMEA
(just one sentence) is also reliable with about a 680 ms latency and 10 ms
jitter.
Again, are you using gpsd?
If so, you may want to try removing the (huge) 680ms offset inside gpsd
On Wed, Jul 13, 2011 at 04:49:37PM -0500, Hal Murray wrote:
The problem is that the adjustment takes to large steps, not that it
takes to long time.
ntpd will slew the clock at 500 PPM. You may be willing to wait a while
for a second or two, but it takes a long time if you have to
On Wed, Jul 13, 2011 at 10:51:46PM +0100, David Woolley wrote:
Hal Murray wrote:
OK. I asked since a timewarp of 200ms is a bit surprising for real HW,
but is something to be expected if you were running in a VM.
It's easy to get a time-warp of 200 ms on a DSL link. Just download
a huge
On 2011-07-14, Rob nom...@example.com wrote:
Michael Eder me...@whoi.edu wrote:
We have looked at our GPS on a scope, the PPS it is dead on and the NMEA
(just one sentence) is also reliable with about a 680 ms latency and 10 ms
jitter.
Again, are you using gpsd?
If so, you may want to try
unruh un...@wormhole.physics.ubc.ca wrote:
On 2011-07-14, Rob nom...@example.com wrote:
Michael Eder me...@whoi.edu wrote:
We have looked at our GPS on a scope, the PPS it is dead on and the NMEA
(just one sentence) is also reliable with about a 680 ms latency and 10 ms
jitter.
Again, are
On Thu, Jul 14, 2011 at 7:04 AM, unruh un...@wormhole.physics.ubc.ca wrote:
Why? That native binary will also suffer from large latency (the serial link
is slow no matter what is being sent over it) and probably also fairly
large jitter. And it suffers from the huge downside of your having to
Rob wrote:
The native binary protocol usually has a SPECIFICATION about the time
field in the messages (like: it is the current time at the moment the
beginning of the message is leaving the receiver). The NMEA protocol
has a time of fix, and that tells you nothing about what time it is
now.
$GPZDA ?
I tried it on one unit. It didn't help. If anybody has examples of
it working please let us know what type of GPS receiver you tested.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
On 7/14/2011 9:46 AM, Uwe Klein wrote:
Rob wrote:
The native binary protocol usually has a SPECIFICATION
about the time field in the messages (like: it is the
current time at the moment the beginning of the message
is leaving the receiver). The NMEA protocol has a
time of fix, and that
Not using gpsd, just writing the NMEA time and receive time into SHM (0)
like gpsd does. The pps does the same to SHM (1). Effectively the pps code
just increments the second from the NMEA string and writes it to SHM. We
need certain values from the NMEA string so have not looked into anything
??? Exactly which of the problems he mentioned had anything to do with
setting up ntp server in the ocean?
inability to use a timing GPS receiver and having to use a nav type unit.
This entire problem would go away if he could use one of the more
common timing receivers and a fixed antenna. I
On 2011-07-14, Michael Eder me...@whoi.edu wrote:
Not using gpsd, just writing the NMEA time and receive time into SHM (0)
like gpsd does. The pps does the same to SHM (1). Effectively the pps code
sounds like a bad procedure. You want to make sure that the nmea
actually gets associated with
Bill wrote:
On 2011-07-12, Lars Ericsson laeatw...@gmail.com wrote:
Hi all,
I have been running the ntp client on a Linux platform for some time and
have not seen any problems.
I recently run into a strange behavior where our communication software
failed on some critical timeouts.
The following is an example from ntpd.log
14 Apr 07:22:25 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
14 Apr 07:22:25 ntpd[1048]: time reset +0.231004 s
14 Apr 07:23:35 ntpd[1048]: synchronized to 10.0.0.5, stratum 1
14 Apr 07:39:33 ntpd[1048]: time reset +0.318457 s
14 Apr 07:39:33
14 matches
Mail list logo
