I have a test setup with a RaspberryPi and a SiRF/gpsd module. All
working quite well, but one thing bugs me. Looking at the ntpq -p output
the serial port readings seem to drift away slowly but steadily from the
PPS, see http://detha.co.za/ntp/ntpmon.20130828.jpg.
Done the 'let it run for 24
detha de...@foad.co.za wrote:
I have a test setup with a RaspberryPi and a SiRF/gpsd module. All
working quite well, but one thing bugs me. Looking at the ntpq -p output
the serial port readings seem to drift away slowly but steadily from the
PPS, see http://detha.co.za/ntp/ntpmon.20130828.jpg
On 27/08/2013 20:05, Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
What I meant is the usage of CreateFileMapping() and MapViewOfFile() for
shared memory segments, as it is done in ntpd's refclock_shm.c.
We are using this in the Windows driver package for our PCI cards, but
://detha.co.za/ntp/ntpmon.20130828.jpg.
It is normal. The offset between serial data and PPS changes all the time.
It is often a bit better when you put the GPS in binary mode instead
of NMEA.
Indeed, or use a very high baud rate for the NMEA.
I would be more worried about the 11 ms step in the PPS
, see http://detha.co.za/ntp/ntpmon.20130828.jpg.
It is normal. The offset between serial data and PPS changes all the time.
It is often a bit better when you put the GPS in binary mode instead
of NMEA.
You havee adjusted the nmea offset. It is actually probably something
like 100 ms off from
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 27/08/2013 20:05, Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
What I meant is the usage of CreateFileMapping() and MapViewOfFile() for
shared memory segments, as it is done in ntpd's refclock_shm.c.
We are using
On 2013-08-28, David Taylor david-tay...@blueyonder.co.uk wrote:
detha de...@foad.co.za wrote:
http://detha.co.za/ntp/ntpmon.20130828.jpg
I would be more worried about the 11 ms step in the PPS at about -155
hours...
The PPS signal is plotted in green and does not diverge visibly from 0
On 2013-08-28, detha de...@foad.co.za wrote:
Done the 'let it run for 24 hours, take average offset between PPS and
serial reading, and use that as time1 for the gpsd line in ntp.conf.'
Where did you find that bad advice?
A timing GPS provides two pieces of information:
1. The PPS signal
On Wed, 28 Aug 2013 12:19:38 +, Steve Kostecke wrote:
On 2013-08-28, David Taylor david-tay...@blueyonder.co.uk wrote:
detha de...@foad.co.za wrote:
http://detha.co.za/ntp/ntpmon.20130828.jpg
I would be more worried about the 11 ms step in the PPS at about -155
hours...
The PPS
readings seem to drift away slowly but steadily from the
PPS, see http://detha.co.za/ntp/ntpmon.20130828.jpg.
It is normal. The offset between serial data and PPS changes all the time.
It is often a bit better when you put the GPS in binary mode instead
of NMEA.
Indeed, or use a very high
Hello Thomas,
I have installed the DEVEL port from the ports collection. I am not
building from the ntp source. This is my rc.conf:
[root@jupiter /etc]# cat /etc/rc.conf
# -- sysinstall generated deltas -- # Fri Oct 19 20:10:17 2012
# Created: Fri Oct 19 20:10:17 2012
# Enable network
Hi Charles,
I have disabled the OnCore support in the ntp.conf. This is what I am
seeing now.
[root@jupiter /etc/mail]# ntpdate -q ntp0.nl.uu.net
server 193.67.79.202, stratum 1, offset -0.001815, delay 0.05353
28 Aug 20:29:23 ntpdate[23788]: adjust time server 193.67.79.202 offset
12 matches
Mail list logo
