[ntp:questions] Re: convert_rawdcf: parity check FAILED on my embedded Linux system

Uwe Klein uwe_klein_habertwedt at t-online.de
Sat Oct 14 17:18:38 UTC 2006

David Woolley wrote:
> In article <BEEJJJBHFJKBIOKDKFJLEEHNCBAA.Torsten.Krieger at krieger-mis.de>,
> Torsten.Krieger at krieger-mis.de (Torsten Krieger) wrote:
>>it seems to receive the DFC signal from Mainflingen correctly. I do not know
>>much of the receiver Hardware since it is proprietary and not well
>>documented, I only know that it receives the raw serial signal with 50 baud.
> If it is interfacing at 50 bits per second through a UART (the actual
> signal is 1 baud), the receiver's baseband processing is trivial and
> you are processing the raw baseband signal with only low pass filtering
> applied.  The internals may not be published, but there are not exactly
> any trade secrets in such a receiver.
> The 50 baud serial interface is a hack in ntpd which makes use of the
> error behaviour of UARTs when presented with the raw DCF signal.
> The signal is not being processed as a proper aynchronous serial signal
> and things like UART parity and framing errors do not have their standard
> meanings, so would not be presented as such in error messages.
You still pretend that the pulse is a StartBit, Some LowBits, after that
Some HighBits,... and try to receive it with 50 (or 25 Baud) 8Bits/char ..
With 50 Baud there is a chance you get a framing error instead of 0x00
for the long pulse.

I tried that ~8/9years ago, but the UART processor on the MVME167 Board did
not support Baudrates below 100 Baud ;-(. in the end this inability was
beneficial. I put the DCF Signal Status in the housekeeping area of my
10ms Dataframes. better timing information than pushing it through software


More information about the questions mailing list