[ntp:questions] FreeBSD and Sure Electronics

David J Taylor david-taylor at blueyonder.co.uk.invalid
Mon Feb 20 16:35:53 UTC 2012

> 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:


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",
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.


More information about the questions mailing list