Re: [ntp:questions] DCF77 Problem
Hi there Rob wrote: 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Hi there Rob van der Putten wrote: 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Rob van der Putten r...@sput.nl wrote: Hi there Rob van der Putten wrote: 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. 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-S1-4p---81-p12-8--124--4---2--1---p_ 25 Feb 18:50:00 ntpd[4540]: PARSE receiver #0: FAILED TIMECODE: -#-#---###M-S1-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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Hi there Rob wrote: 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. 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 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. 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-S1-4p---81-p12-8--124--4---2--1---p_ 25 Feb 18:50:00 ntpd[4540]: PARSE receiver #0: FAILED TIMECODE: -#-#---###M-S1-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. 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] DCF77 Problem
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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Hi there Rob wrote: 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Rob van der Putten r...@sput.nl wrote: Hi there Rob wrote: 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. 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Hi there Rob wrote: 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. 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 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Rob van der Putten r...@sput.nl wrote: 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. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] DCF77 Problem
Rob van der Putten r...@sput.nl writes: Hi there Rob wrote: 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. 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. Regards, Rob ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
