NTPd with PPS usb dongle troubleshooting



  • 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


  • Netgate Administrator

    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



  • 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


  • Netgate Administrator

    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