Maybe you should read to the end of these threads before posting.
On Mon, Dec 15, 2014 at 10:34 PM, E-Mail Sent to this address will be added
to the BlackLists Null@blacklist.anitech-systems.invalid wrote:
Increase TOS MinDist
___
questions mailing
On 10/12/2014 12:39, Miroslav Lichvar wrote:
On Wed, Dec 10, 2014 at 11:50:22AM +, David Taylor wrote:
With -D 4 I get a list of devices ending with PPS, but presumably that is
not the same as KPPS?
In gpsd the PPS without K is the userspace timestamping. With kernel
timestamping the log
On Sat, Dec 13, 2014 at 2:52 AM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
For some reason, gpsd seems to be stuck at a lower release for the
Raspberry Pi version of Debian, so I will have a go at recompiling it once
I can find the right instructions! That's if there's no
On 09/12/2014 20:51, Paul wrote:
[]
As I mentioned previously it's still possible to use refclock 1 (LOCAL).
The driver is claimed to be deprecated but it's still present in 4.2.7 so
presumably will be in 4.2.8.
server 127.127.22.0 minpoll 3 maxpoll 3
fudge 127.127.22.0 stratum 0
server
On Tue, Dec 09, 2014 at 03:29:45PM +0100, Sander Smeenk wrote:
I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
The GPS provides a PPS signal via serial and i use gpsd to provide the
NMEA sentences and pulse data in shared memory to NTP.
This partly works. NTP
On 10/12/2014 10:24, Miroslav Lichvar wrote:
[]
If it's a recent version of gpsd which uses kernel timestamps (check
for KPPS messages in gpsd -D 4 output), you may already have a true
PPS sync. The PPS and NMEA timestamps are paired in gpsd, so it's not
necessary to add the NMEA source to ntpd.
On Wed, Dec 10, 2014 at 11:50:22AM +, David Taylor wrote:
With -D 4 I get a list of devices ending with PPS, but presumably that is
not the same as KPPS?
In gpsd the PPS without K is the userspace timestamping. With kernel
timestamping the log looks like this:
gpsd:PROG: PPS edge: 1,
Hi,
I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
The GPS provides a PPS signal via serial and i use gpsd to provide the
NMEA sentences and pulse data in shared memory to NTP.
This partly works. NTP syncs against the PPS signal but the NMEA signal
is always marked
On Tue, Dec 9, 2014 at 9:29 AM, Sander Smeenk ssme...@freshdot.net wrote:
1) Can i get a 'true PPS sync' with this setup?
Yes.
Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ?
What do you mean by Eliminating?
2) What could i possibly do to get NTP to sync/accept the
On 09/12/2014 16:49, Paul wrote:
[]
Unless someone needs to share position and velocity data
I don't understand why gpsd is used to proxy NMEA data. The NMEA (or ATOM)
driver is sufficient.
Paul, does the NMEA (or ATOM) driver solve the problem of having perhaps
a couple of hundred
On 2014-12-09, Sander Smeenk ssme...@freshdot.net wrote:
Hi,
I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
The GPS provides a PPS signal via serial and i use gpsd to provide the
NMEA sentences and pulse data in shared memory to NTP.
This partly works. NTP syncs
On 2014-12-09, David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 09/12/2014 16:49, Paul wrote:
[]
Unless someone needs to share position and velocity data
I don't understand why gpsd is used to proxy NMEA data. The NMEA (or ATOM)
driver is sufficient.
Paul, does the NMEA (or
On 12/09/2014 03:29 PM, Sander Smeenk wrote:
Hi,
I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
The GPS provides a PPS signal via serial and i use gpsd to provide the
NMEA sentences and pulse data in shared memory to NTP.
This partly works. NTP syncs against the
Quoting William Unruh (un...@invalid.ca):
This partly works. NTP syncs against the PPS signal but the NMEA signal
is always marked as falseticker even though i managed to bring down the
offset to -1.5??sec average by fudging the time a bit. The NMEA signal
offset fluctuates a lot. From ~
Quoting juergen perlinger (juergen.perlin...@t-online.de):
This is a known weakness of the GPS18x series. The puck tries to center
the serial output between the PPS pulses, and that's a pain in the back,
pardon my French. But to be fair, some SIRF based modules do it even worse.
It appeared
Sander Smeenk wrote:
Hi,
I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
The GPS provides a PPS signal via serial and i use gpsd to provide the
NMEA sentences and pulse data in shared memory to NTP.
This partly works. NTP syncs against the PPS signal but the NMEA
On 09/12/2014 17:48, William Unruh wrote:
On 2014-12-09, David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 09/12/2014 16:49, Paul wrote:
[]
Unless someone needs to share position and velocity data
I don't understand why gpsd is used to proxy NMEA data. The NMEA (or ATOM)
driver is
William Unruh un...@invalid.ca wrote:
On 2014-12-09, Sander Smeenk ssme...@freshdot.net wrote:
Hi,
I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
The GPS provides a PPS signal via serial and i use gpsd to provide the
NMEA sentences and pulse data in shared
On Tue, Dec 9, 2014 at 12:24 PM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
Paul, does the NMEA (or ATOM) driver solve the problem of having perhaps a
couple of hundred milliseconds peak-to-peak jitter in the GPS serial data,
thereby preventing NTP using the PPS source?
As I
On Tue, Dec 9, 2014 at 3:17 PM, Nomen Nescio nob...@dizum.com wrote:
The PPS pulses and NMEA sentences need to be close enough before
ntpd will accept them. Usually that means the the NMEA sentence needs to
arrive during the bounds of the second it is naming.
If that's not happening your GPS
20 matches
Mail list logo
