With the serial rate addressed, here are the ntpq -crv and ntpq -ccv
'
outputs.
godzilla#
godzilla#
godzilla# ntpq -crv
assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.4p5-a (1)", processor="amd64",
system="FreeBSD/9.0-RELEASE", leap=11, stratum=16, precision=-19,
rootdelay=0.000, rootdispersion=3.000, peer=0, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000, poll=6,
clock=d2ecb59b.c4db29d7 Mon, Feb 20 2012 7:05:47.768, state=1,
offset=0.000, frequency=-12.503, jitter=0.002, noise=0.002,
stability=0.000, tai=0
godzilla#
godzilla#
godzilla# ntpq -ccv
assID=0 status=0101 clk_noreply, last_clk_noreply,
device="NMEA GPS Clock", timecode=, poll=13, noreply=11, badformat=0,
baddata=0, fudgetime1=0.000, stratum=0, refid=GPS, flags=0
godzilla#
godzilla#
godzilla#
Its just the strangest thing that I cannot put my finger on. When I
had
Debian's kfreebsd running, data from /dev/cuau0 came through just
fine.
But once I switched over to FreeBSD v9 and patched the kernel for PPS,
I'm stuck in this limbo state of seeing data (note: cu -l /dev/cuau0 -
s 9600) below
on /dev/cuau0, but with NTP running, it just comes back with nothing.
I also have /dev/gps0 linked to /dev/cuau0, so its not a missing link
issue.
Any help is appreciated.
Thanks,
I have some novice-level FreeBSD notes here:
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
I see that the device may need to be either cuaa1 or cuad1 for a
serial port on COM1.
For the default on the Sure board I have set 9600 baud (mode 16) and use
$GPGGA sentences (mode 2) making the net mode=18.
To clarify, though, I use a Garmin GPS 18 LVC on the FreeBSD system, and
both Sure boards are connected to Windows stratum-1 servers, which also
have the PPS over DCD connected and enabled with the serial PPS driver for
Windows. Enquiring remotely of one of these PCs gives:
C:\>ntpq "-c cv &2" alta
associd=9890 status=00f2 15 events, clk_bad_format,
device="NMEA GPS Clock",
timecode="$GPGGA,161311.000,5554.4196,N,00312.0735,W,1,8,0.99,185.5,M,49.6,M,,*4B",
poll=24648, noreply=7842, badformat=2757569, baddata=0, stratum=0,
refid=GPS, flags=0
There is an issue with the serial I/O handling in Windows which is being
worked on at the moment, which (we hope) accounts for the large number of
badformat reports.
Perhaps some of this may help.
Cheers,
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
