[ntp:questions] convert_rawdcf: parity check FAILED on Olinuxino Maxi (iMX233)

Rob nomail at example.com
Tue Oct 8 08:31:33 UTC 2013


Rob van der Putten <rob at 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.



More information about the questions mailing list