[ntp:questions] Meinberg DCF77 C51 with Linux 2.6
martin.burnicki at meinberg.de
Mon Feb 12 09:47:35 UTC 2007
sorry for the late reply, I've been offline for a couple of days. However,
I've read the posts in this thread and would like to give you some general
Rune Magnussen wrote:
> I am trying to to get my Meinberg DCF77 C51 unit to work. The problem is
> that ntpd does not see any timecodes even though thr unit is synchronised
> to the radiosignal.
> The clock is connected via a modem cable with a null-modem
> adapter. I tried with a serial printer cable as well, but not for long.
1.) NTP's parse driver uses default serial port baud rate and framing which
match the factory settings of the C51: 9600, 7E2, time string per second.
2.) You need a straight RS-232 cable with 25-to-9 adapter to connect the
device, _not_ a null modem cable. As already mentioned in some other post
here, you may _not_ compare the pin numbers of a 9 pin connector to those
of a 25 pin connector to find out whether to use a cross over cable or a
straight cable. The clock basically only requires a 2 wire connection, i.e.
the clock's TxD connected to the PC's RxD, and the signal ground connected.
3.) Under Linux, /dev/ttyS0 should work fine. No handshake signals are
4.) You can use the cu program which is part of the uucp package to check
the communication. Of course ntpd must not run while you use cu since it
would keep the the serial port open and prevent cu from being able to
receive anything. Try this command to run cu on ttyS0 with 9600/7E2:
~/> cu -s 9600 -e -l /dev/ttyS0
This should print something similar to:
Type ~. to let cu close the connection.
Please note that in order to use cu the user must me member of the uucp
group. E.g. under recent versions of SuSE Linux you get a "Permisssion
denied" and "Line in use" if you run cu as root.
5.) The clock's serial communication works regardless of whether it is
synchronized, or not. If the device is not synchronized. this is indicated
by some status characters, i.e. the "#*" characters in the example above.
In this case ntpd will receive the time string, but "reach" will stay at 0:
# ntpq -p
remote refid st t when poll reach delay offset jitter
GENERIC(1) .DCFa. 0 l - 64 0 0.000 0.000 0.004
However, the latest time string is reported by the clockvars:
First retriecve the assID of the device:
# ntpq -c as
ind assID status conf reach auth condition last_event cnt
1 60011 8025 yes yes none reject clock expt 2
Then use the assID (60011 in this case) to display the clock vars:
# ntpq -c "cv 60011"
assID=60011 status=0303 clk_fault, last_clk_fault,
device="Meinberg DCF77 C51 or compatible",
timecode="\x02D:12.02.07;T:1;U:10.40.04;#* \x03", poll=7, noreply=1,
badformat=0, baddata=0, fudgetime1=5.100, stratum=0, refid=DCFa,
refclock_time="c97ab474.00000000 Mon, Feb 12 2007 9:40:04.000",
refclock_status="NOT SYNCHRONIZED; TIME CODE NOT CONFIRMED; TIME CODE; (LEAP
refclock_states="NOMINAL: 00:01:08 (16.50%); NO RESPONSE: 00:00:35 (8.49%);
*FAULT: 00:05:09 (75.00%); running time: 00:06:52"
Please see the line with "timecode=" which displays the last time string
received from the clock, including the status chars "#*" in this case which
say the device is not synchronized.
After the device has been synchronized there are 2 ASCII spaces displayed
instead of the "#*" characters, and ntpd should start to increase the reach
value in the output of "ntpq -p" after the next polling interval.
> The serial port is detected by the kernel. As described in the docs I made
> a symlink /dev/refclock-0 to /dev/ttyS0. I guess that /dev/ttyS0 is the
> right one. as the PC only has one serial port on the outside.
> The DCF77 C51 shows up as GENERIC(0) with refid DCFa but the clock is
> never "reached". I have activated clockstats in ntpd, but nothing shows
The above looks OK. I think your problems are just due to a wrong serial
More information about the questions