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-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. > 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
