Bug 224173 - serial driver from 10.4 onwards doesn't correctly work in ntpd/DCF77 "parse" clock mode
Summary: serial driver from 10.4 onwards doesn't correctly work in ntpd/DCF77 "parse" ...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.1-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2017-12-08 11:20 UTC by Pierre Beyssac
Modified: 2019-10-29 23:27 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Beyssac 2017-12-08 11:20:31 UTC
I'm running a DCF77 (German radio time code) receiver in "raw pulse" mode in ntpd.

The receiver emits 100 ms ("0") or 200 ms ("1") pulses on the RX and/or CTS/DCD line of the serial port.

There are 59 pulses per minute, one per second except on second 59. See https://en.wikipedia.org/wiki/DCF77

On FreeBSD 11.1 with ntpd, there are 2 modes in which the receiver can be used:
- "parse" mode, where the timecode is decoded bit by bit. In this mode the serial port is configured at 50 bauds. A 100 ms pulse yields a character, a 200 ms pulse yields a framing error.
- "PPS" mode, where the uart driver timestamps a transition on DCD.

PPS mode works flawlessly.

On the other hand, the parse timecode mode (50 bauds) doesn't. Bits are lost (I haven't yet investigated whether only 1-bits or 0-bits are lost, or if the pattern is more complex).

On FreeBSD 10.4 this doesn't work either (same serial driver as in 11.1).

On the other hand, on FreeBSD 9.3 the receiver works (older serial driver).

Where this gets very interesting is that the above mentioned FreeBSD 9.3 runs as a guest in a VirtualBox on the very same FreeBSD 11.1 host, with the host serial port configured in VirtualBox to point to /dev/cuau0, and seen as a 16550 UART by FreeBSD 9.3.

It doesn't work on a FreeBSD 11.1 under VirtualBox, which is less surprising.


Relevant bits of my ntp.conf for the non-working timecode mode:

# Configuration for "timecode mode"
# DCF77 module on /dev/refclock-1 (link to /dev/cuau0)
server 127.127.8.1 mode 5
fudge 127.127.8.1 time1 1.843

Excerpt from failed parsing logs.

Dec  7 22:10:31 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:10:41 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 4 bits
Dec  7 22:10:49 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:10:59 freebsd11-1 last message repeated 2 times
Dec  7 22:11:01 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits
Dec  7 22:11:08 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits
Dec  7 22:11:10 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:11:32 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 16 bits
Dec  7 22:11:34 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:11:51 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 11 bits
Dec  7 22:11:53 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:12:00 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 5 bits
Dec  7 22:12:17 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 12 bits
Dec  7 22:12:19 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:12:40 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 15 bits
Dec  7 22:12:42 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:12:51 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 3 bits
Dec  7 22:12:53 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:13:07 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 7 bits
Dec  7 22:13:09 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:13:20 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 5 bits
Dec  7 22:13:22 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:13:29 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits
Dec  7 22:13:31 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:13:39 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits
Dec  7 22:13:41 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:13:49 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits
Dec  7 22:13:51 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:14:00 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits
Dec  7 22:14:08 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:14:10 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits
Dec  7 22:14:18 freebsd11-1 ntpd[701]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits
Comment 1 pvoigt 2019-10-29 23:27:09 UTC
Well, this issue is rather old and still has status "new". I reply because I have just obviuosly run into the same situation: I have an USB DCF77 receiver which can never pass a full correct signal to ntpd. It is a GUDE Expert Mouse Clock 0107 which is correctly recognized by FreeBSD 11.3-RELEASE-p4. I have built net/ntp from ports with enabled RAWDCF option. However, ntp log is full of "INCOMPLETE DATA" and "start bit / parity check FAILED" messages. The same receiver works immediately when connected to a Debian Buster machine.

Is there currently any work in progress on this issue? Is there an issue in ucom/uftdi kernel modules or in the RAWDCF driver of ntp?