Rob van der Putten <r...@sput.nl> wrote: > Using 8 bits + parity prevents framing errors but introduces parity > errors instead; > > -----+ +---+---+---+---+---+---+---+---+---+--------- > | S | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | P | S > +---+---+---+---+---+---+---+---+---+---+ > > -----+ +----------------------------- > | 100 ms | > +-------------------+ > > -----+ +--------- > | 200 ms | > +---------------------------------------+ > > With a 100 ms pulse there are 5 ones; Odd > With a 200 ms pulse there are 0 ones: Even. > > So parity errors are perfectly normal.
This is not what the error message means. ntpd sets the interface to 50 baud, 8 bits, even parity, 1 stopbit, no parity checking. This is only done to differentiate between the 100ms and 200ms pulses as you describe above. The 0xf0 value means a 100ms pulse, the 0x00 value a 200ms pulse. Framing and parity are ignored. Those pulses are collected over one minute, and assembled into a DCF77 datagram. This datagram has a couple of parity bits for different fields. A parity error in the ntpd message is referring to THOSE parity errors, not to the parity errors on the serial interface (which are ignored). When the system operates correctly, you can occasionally get error messages like this: parse: convert_rawdcf: parity check FAILED for "-#-#---#-#--##---DM-s1-----4p1----2p1---1---4-----124--2--p__" or: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 53 bits those mean that it is missing correct data pulses occasionally. I think what the OP sees means that the decoder detects a 1 bit for each and every pulse (there are no - signs) and this means the timing of the serial receiver is incorrect. It probably means it is not running at 50 baud. It would be nice to diagnose it by using: stty -a </dev/serialdevice But even if it says "50" there, it could still be that the actual hardware is not able to do it. I think I would check if the hardware+driver supports the TIOCMIWAIT ioctl as I mentioned before, and if it does connect the receiver to a status line (DCD for example) and write a program to read that data. That way, there is no polling and the process uses only very little CPU, at least until the receiver goes haywire in a thunderstorm and starts sending noise instead of nice pulses (one of my receivers does that occasionally; the LED is not flashing but dimly lit). I used the TIOCMIWAIT technique in gpsd to receive the PPS pulses from a GPS receiver, and it works surprisingly well. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions