[ntp:questions] DCF77 Problem

Discussion:

Rob van der Putten

2009-02-24 14:39:37 UTC

Hi there

From the syslog;
Feb 24 15:24:05 sput ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA
- time code only has 3 bits
Feb 24 15:24:05 sput ntpd[28039]: PARSE receiver #0: interval for
following error message class is at least 00:01:00
Feb 24 15:24:05 sput ntpd[28039]: PARSE receiver #0: FAILED TIMECODE:
"--" (check receiver configuration / wiring) Feb 24 15:24:07 sput
ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has
2 bits
Feb 24 15:24:12 sput ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA
- time code only has 2 bits
Feb 24 15:24:18 sput ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA
- time code only has 6 bits

This goes on for hours.
Once this happes I can only fix things by restarting the NTPD.
Any ideas?

Regards,
Rob

Rob

2009-02-24 16:23:04 UTC

Permalink

Post by Rob van der Putten
Hi there
From the syslog;
Feb 24 15:24:05 sput ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA
- time code only has 3 bits
Feb 24 15:24:05 sput ntpd[28039]: PARSE receiver #0: interval for
following error message class is at least 00:01:00
"--" (check receiver configuration / wiring) Feb 24 15:24:07 sput
ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has
2 bits
Feb 24 15:24:12 sput ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA
- time code only has 2 bits
Feb 24 15:24:18 sput ntpd[28039]: parse: convert_rawdcf: INCOMPLETE DATA
- time code only has 6 bits
This goes on for hours.
Once this happes I can only fix things by restarting the NTPD.
Any ideas?

Most likely some stupid program has changed the settings of the COM port.
(especially the baudrate)

For example, in SuSE Linux when you are so unfortunate to click on the
"hardware information" icon in YaST, everything is messed up in the process
of detecting what is attached to your serial ports.

Rob van der Putten

2009-02-24 16:37:13 UTC

Permalink

Hi there

Post by Rob
Most likely some stupid program has changed the settings of the COM port.
(especially the baudrate)
For example, in SuSE Linux when you are so unfortunate to click on the
"hardware information" icon in YaST, everything is messed up in the process
of detecting what is attached to your serial ports.

There is no qui on this box. It's a server.

Regards,
Rob

Rob

2009-02-24 17:31:29 UTC

Permalink

Post by Rob van der Putten
Hi there

There is no qui on this box. It's a server.

So do a "stty -a </dev/refclock-0" the next time it is messed up again.

Then you should get this output:

speed 50 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; min = 1; time = 0;
parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke

If not, something has messed up your port. Your task to find out what
it is.

Rob van der Putten

2009-02-24 17:56:34 UTC

Permalink

Hi there

Post by Rob
So do a "stty -a </dev/refclock-0" the next time it is messed up again.
speed 50 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; min = 1; time = 0;
parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke
If not, something has messed up your port. Your task to find out what
it is.

Assuming of course, that ntpd doesn't reset the tty to the original
values when stopped.
Or should I do this with ntpd running?

Regards,
Rob

Rob

2009-02-24 19:33:28 UTC

Permalink

Post by Rob van der Putten
Assuming of course, that ntpd doesn't reset the tty to the original
values when stopped.
Or should I do this with ntpd running?

Of course. You can do it at any time, I got the above output from my
own DCF77 receiver port.

Rob van der Putten

2009-02-25 11:37:51 UTC

Permalink

Hi there

Post by Rob
Of course. You can do it at any time, I got the above output from my
own DCF77 receiver port.

sput:~# stty -a </dev/refclock-0
speed 50 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof =
<undef>; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt
= <undef>; werase = <undef>; lnext = <undef>;
flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke

Regards,
Rob

Rob van der Putten

2009-02-25 14:32:15 UTC

Permalink

Hi there

Post by Rob van der Putten
sput:~# stty -a </dev/refclock-0
speed 50 baud; rows 0; columns 0; line = 0;

At 50 baud 9 bits (start + 8 data) is 180 ms. The max pulse length is
just under 200 ms, so there is no stopbit. Is this OK? Should I build a
circuit to reduce the max pulse length?

<Cut>

Is it possible that interference confuses NTPD in a way that it can't
recover from? It this a bug?

Regards,
Rob

Rob

2009-02-25 18:07:47 UTC

Permalink

Post by Rob van der Putten
Hi there

Post by Rob van der Putten
sput:~# stty -a </dev/refclock-0
speed 50 baud; rows 0; columns 0; line = 0;

At 50 baud 9 bits (start + 8 data) is 180 ms. The max pulse length is
just under 200 ms, so there is no stopbit. Is this OK? Should I build a
circuit to reduce the max pulse length?

No you should not touch the pulse length, it conveys the time information.
50 baud is the correct setting for the port.

Post by Rob van der Putten
<Cut>
Is it possible that interference confuses NTPD in a way that it can't
recover from? It this a bug?

There have been various problems in the parse driver that cause things
like trash being written to the logfile, ntpd exiting on bad input, etc.
It will depend on the version of ntpd that you use, if you have any
problems like that. For some time, I had to run a "watchdog" process
that restarts ntpd when it has crashed. But lately this has not been
a problem.

It is normal to get things like this in the logfile:
25 Feb 18:50:00 ntpd[4540]: parse: convert_rawdcf: parity check FAILED for "-#-#---##----#----M-S----1-4p---81-p12-8--124--4---2--1---p_"

25 Feb 18:50:00 ntpd[4540]: PARSE receiver #0: FAILED TIMECODE: "-#-#---##----#----M-S----1-4p---81-p12-8--124--4---2--1---p" (check receiver configuration / wiring)

When it happens too often or all the time, you will need to find a better
place for the receiver, or align its direction.

Rob van der Putten

2009-02-25 18:26:25 UTC

Permalink

Hi there

Post by Rob
No you should not touch the pulse length, it conveys the time information.
50 baud is the correct setting for the port.

If missing a stopbit on each '1' is OK.

Post by Rob
There have been various problems in the parse driver that cause things
like trash being written to the logfile, ntpd exiting on bad input, etc.
It will depend on the version of ntpd that you use,

4.2.4

Post by Rob
if you have any
problems like that. For some time, I had to run a "watchdog" process
that restarts ntpd when it has crashed.

It doesn't crash. It keeps processing the other clocks.

Post by Rob
But lately this has not been
a problem.
25 Feb 18:50:00 ntpd[4540]: parse: convert_rawdcf: parity check FAILED for "-#-#---##----#----M-S----1-4p---81-p12-8--124--4---2--1---p_"
25 Feb 18:50:00 ntpd[4540]: PARSE receiver #0: FAILED TIMECODE: "-#-#---##----#----M-S----1-4p---81-p12-8--124--4---2--1---p" (check receiver configuration / wiring)

That's not the problem.
Once I have a line like above, it doesn't go back to normal DCF
processing any more. Unless I restart NTPD.

Post by Rob
When it happens too often or all the time, you will need to find a better
place for the receiver, or align its direction.

If have a scope and a rs232 tester connected. The signal looks fine. The
pulse lengths are OK. It can count from 0 to 58 with the pulses and get
a 2 s interval. The signal is so clean that I get a 1 or 2 ?s jitter on DCF.

Regards,
Rob

Thomas Tornblom

2009-02-24 19:46:57 UTC

Permalink

Post by Rob van der Putten
Hi there

Assuming of course, that ntpd doesn't reset the tty to the original
values when stopped.
Or should I do this with ntpd running?

You should do it with ntpd running, otherwise the port will most
likely be reset to the default values by the OS when the port is
closed.

Post by Rob van der Putten
Regards,
Rob