Does this look sane to you for a Raspberry Pi with a
Sure Electronics board and PPS enabled? It looks fine to me,
I just want to confirm that people more experienced than me
see it the same way.
remote refid st t when poll reach delay offset jitter
Ralph,
On Tue, Feb 12, 2013 at 6:04 AM, Ralph Aichinger ra...@pangea.at wrote:
Does this look sane to you for a Raspberry Pi with a
Sure Electronics board and PPS enabled? It looks fine to me,
I just want to confirm that people more experienced than me
see it the same way.
remote
On 2013-02-12, james machado hvgeekwt...@gmail.com wrote:
On Tue, Feb 12, 2013 at 6:04 AM, Ralph Aichinger ra...@pangea.at
wrote:
Does this look sane to you for a Raspberry Pi with a Sure Electronics
board and PPS enabled? It looks fine to me, I just want to confirm
that people more
james machado hvgeekwt...@gmail.com wrote:
I would expect to see a PPS line if you have PPS up and working
correctly, this is what I see on my RPi.
I am using the built-in PPS support of the NMEA driver (flag1).
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version=ntpd
Steve Kostecke koste...@ntp.org wrote:
you that your GPS is the PPS peer. Plus the offset and jitter are
appropriate for a PPS ref-clock.
Thanks that helps a lot. The tally codes are well documented, of course,
but I was not quite sure if the offsets against known working
NTP servers were
On Tue, Feb 12, 2013 at 11:03 AM, Ralph Aichinger ra...@pangea.at wrote:
snip
You use the driver 20 (NMEA) without PPS (flag1 0) I (hopefully)
use it with (flag1 1).
and i learn something new - thanks :)
Thanks! The values from your setup are very helpful, as they
are quite close to
