NTPd with PPS usb dongle troubleshooting

[pbosgraaf]

Hi!,

I got this DCF77 usb dongle from a friend and thought let's try to use this as a timesource for my ntp server.
This have proven more difficult than expected :-)

The usb dongle is a Gude Expert Mouse Clock 0107

When looking at "Status > NTP" the dongle keeps reporting:

Network Time Protocol Status
Unreach/Pending 127.127.22.0 .1. 0 l - 16 0 0.000 0.000 0.000

So i've started troubleshooting but can't seem to find the issue, any help would be greatly appreciated!
First is checked the dongle with Windows software on the same spot to check DCF77 reception, this worked as expected.

I've added the dongle to "Services > NTP > PPS" and selected the cuaU0 device.
Restarted the NTP service after saving the config.
The strange thing is that when i look at the ntpd.log it does not show that it's actually using the cuaU0 device

clog /var/log/ntpd.log
Sep 27 19:59:50 p ntpd[26725]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Sep 27 19:59:50 p ntpd[27021]: proto: precision = 0.054 usec (-24)
Sep 27 19:59:50 p ntpd[27021]: Listen and drop on 0 v6wildcard [::]:123
Sep 27 19:59:50 p ntpd[27021]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Sep 27 19:59:50 p ntpd[27021]: Listen normally on 2 igb0 [x.x.x.x]:123
Sep 27 19:59:50 p ntpd[27021]: Listen normally on 3 igb1 192.168.110.254:123
Sep 27 19:59:50 p ntpd[27021]: Listen normally on 5 lo0 [::1]:123
Sep 27 19:59:50 p ntpd[27021]: Listen normally on 6 lo0 [fe80::1%6]:123
Sep 27 19:59:50 p ntpd[27021]: Listen normally on 7 lo0 127.0.0.1:123
Sep 27 19:59:50 p ntpd[27021]: Listening on routing socket on fd #33 for interface updates
Sep 27 19:59:51 p ntpd[27021]: Soliciting pool server 83.98.201.134
Sep 27 19:59:52 p ntpd[27021]: Soliciting pool server 95.211.212.5
Sep 27 19:59:52 p ntpd[27021]: Soliciting pool server 129.250.35.251

As i've never worked with a PPS dongle before i have no idea what the output of the log is supposed to look like.
But i can only assume it would list the source somewhere in the log on starting.

dmesg:
ugen0.3: <GUDEADS Expert mouseCLOCK USB II> at usbus0
uftdi0 on uhub0
uftdi0: <Expert mouseCLOCK USB II> on usbus0

usbconfig list
ugen0.3: <GUDEADS Expert mouseCLOCK USB II> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

ls -al /dev/cuaU*
crw-rw----  1 uucp  dialer  0x52 Sep 27 19:27 /dev/cuaU0
crw-rw----  1 uucp  dialer  0x53 Sep 27 19:27 /dev/cuaU0.init
crw-rw----  1 uucp  dialer  0x54 Sep 27 19:27 /dev/cuaU0.lock

cat /var/etc/ntpd.conf
#
# pfSense ntp configuration file
#

tinker panic 0
# Orphan mode stratum
tos orphan 12

# PPS Setup
server 127.127.22.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.22.0 flag3 0 refid 1


# Upstream Servers
pool 0.nl.pool.ntp.org iburst maxpoll 9
pool 1.nl.pool.ntp.org iburst maxpoll 9
pool 2.nl.pool.ntp.org iburst maxpoll 9


statsdir /var/log/ntp
logconfig =syncall +clockall
driftfile /var/db/ntpd.drift
restrict default kod limited nomodify nopeer notrap
restrict -6 default kod limited nomodify nopeer notrap
restrict source kod limited nomodify notrap

I found this gem:
http://wiki.gude.info/FreeBSD_ntpd

Which lists a patch for FreeBSD, which seems to have made it to the master
That ntpd config is completely different from my, i tried changing the server line in pfsense but this did not work.
The patch talks about:
ucom0: GUDEADS Expert mouseCLOCK USB II, rev 2.00/6.00, addr 2
While my dmesg outputs:
ugen0.3: <GUDEADS Expert mouseCLOCK USB II> at usbus0

I have no idea is this can be the root cause the issue.
I've you made it this far thanks for reading ;-), any help or insights would be greatly appreciated!

-peter

[stephenw10]

Hmm, interesting.

You have a virtual com port showing that is detected and created so I don't think you need any additonal driver modules. And that patch is alreday in FreeBSD as you say.

You might try opening a terminal to cuaU0 to check it's actually sending anything. And what it's sending.

The issue there appears to be ntpd compiled with "--enable-RAWDCF" set.

Do you see a /dev/refclock device?

I've only ever GPS receivers like this and they are generally terrible as clock references when connected via USB. Real NTP GPS receivers use another serial line for the PPS signal that isn't passed by USB which introduces timing issues on the lines it does carry anyway.

Steve

[pbosgraaf]

Hi!,

Thanks for the help!

Not seeing the /dev/refclock device at all.
Not with the stock pfsense settings but also not after adding the line described in that freebsd page to /etc/devfs.conf

cat /etc/devfs.conf | grep refclock
link    cuaU0   refclock-0

The device does output something when trying to view

cu -s 9600 -l /dev/cuaU0
Connected
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒

But no matter what speed/setting i try the output is always gibberish.

Thanks,
Peter

[stephenw10]

It may not output in ascii. Does it appear to be incrementing at 1s intervals?

I'm seeing some references to it being at 50bps so you might try that.

You could probably cat the device to a file to examine the actual data but it probably won't tell us much anyway.

There is a utility to check the output but I don't think it's compiled by default:
https://github.com/pfsense/FreeBSD-src/tree/devel/contrib/ntp/parseutil

I suspect you may need to compile either that or ntpd with the rawdcf option enabled in FreeBSD 11.2 and copy it across. Or at least test it there first.

Steve