NTPd with PPS usb dongle troubleshooting
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: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid Sep 27 19:59:50 p ntpd: proto: precision = 0.054 usec (-24) Sep 27 19:59:50 p ntpd: Listen and drop on 0 v6wildcard [::]:123 Sep 27 19:59:50 p ntpd: Listen and drop on 1 v4wildcard 0.0.0.0:123 Sep 27 19:59:50 p ntpd: Listen normally on 2 igb0 [x.x.x.x]:123 Sep 27 19:59:50 p ntpd: Listen normally on 3 igb1 192.168.110.254:123 Sep 27 19:59:50 p ntpd: Listen normally on 5 lo0 [::1]:123 Sep 27 19:59:50 p ntpd: Listen normally on 6 lo0 [fe80::1%6]:123 Sep 27 19:59:50 p ntpd: Listen normally on 7 lo0 127.0.0.1:123 Sep 27 19:59:50 p ntpd: Listening on routing socket on fd #33 for interface updates Sep 27 19:59:51 p ntpd: Soliciting pool server 188.8.131.52 Sep 27 19:59:52 p ntpd: Soliciting pool server 184.108.40.206 Sep 27 19:59:52 p ntpd: Soliciting pool server 220.127.116.11
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:
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!
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.
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.
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:
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.