On 20/03/2018 21:16, Andreas Mattheiss wrote:
Hello,
I'm monkeying around with raw DCF again ...
I have slightly modified a DCF77 alarm clock so that it constantly
receives the DCF77 signal and tapped into the 100/200ms pulses. Receiption
must be good, since when I pipe this into an Arduino board I get good
results from the decode. For the PC, I first inverted the 100/200ms pulses
with a transistor, then feed the inverted signal into a MAX232 level
converter - inverting is necessary since the MAX232 inverts the CMOS level
signal itself. The MAX232 has a LED at the output that now duly shows
100 and 200ms flashes - i.e. it is out most of the time. Hook up to ttyS2.
So far, so good. Alas I only get crap:
20 Mar 20:59:53 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 20:59:53 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 20:59:54 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 20:59:54 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 20:59:54 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 20:59:54 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 21:00:00 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P124812124124811248----"
20 Mar 21:00:03 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"#--############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 21:00:03 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 21:00:03 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
20 Mar 21:00:03 ntpd[15775]: parse: convert_rawdcf: start bit / parity check FAILED for
"###############RADMLS1248124P124812P1248121241248112481248P??"
... ad nauseam. Look at the time stamps - rather lots of action for 50
baud, isn't it? It looks very strange to me when I do a cat /dev/ttyS2 |
xxd -b:
00001d4: 00000000 00000000 00000000 00000000 00000000 00000000 ......
00001da: 00000000 00000000 00000000 00000000 00000000 00000000 ......
00001e0: 00000000 00000000 00000000 00000000 00000000 00000000 ......
00001e6: 00000000 00000000 00000000 00000000 00000000 00000000 ......
00001ec: 00000000 00000000 00000000 00000000 00000000 00000000 ......
00001f2: 00000000 00000000 00000000 00000000 00000000 00000000 ......
00001f8: 00000000 00000000 00000000 00000000 00000000 00000000 ......
00001fe: 00000000 00000000 00000000 00000000 00000000 00000000 ......
0000204: 11110000 11110000 11110000 11110000 10000000 00000000 ......
000020a: 00000000 00000000 00000000 00000000 00000000 00000000 ......
0000210: 00000000 00000000 00000000 00000000 00000000 00000000 ......
0000216: 00000000 00000000 00000000 00000000 00000000 00000000 ......
000021c: 00000000 00000000 00000000 00000000 00000000 00000000 ......
0000222: 00000000 00000000 00000000 00000000 00000000 00000000 ......
0000228: 00000000 00000000 00000000 00000000 00000000 00000000 ......
000022e: 00000000 00000000 00000000 00000000 00000000 00000000 ......
0000234: 00000000 00000000 00000000 00000000 00000000 00000000 ......
This is being churned out at a surprisingly high speed. The 11110000
groups are 100ms pulses, and 00000000 is supposed to be 200ms. But why the
heck am I getting so much more 0x00 than 0xf0?
http://comp.protocols.time.ntp.narkive.com/oQhF2g2W/aw-convert-rawdcf-parity-check-failed-on-my-embedded-linux-system
mentions
---quote---
you should receive 1 byte ( or a framing error/break ) every second for 59
seconds
every 60 seconds.
100ms --> 5 Bit times -> 1 stop and 4 LSbit low, rest high -> 0xf0
200ms --> 10 bit Times -> 1 stop and 9 LSbit low, the high -> either 0x00 or
framing error
only jitter between leading and trailing edge is relevant.
The distance between acceptable low and high indicating chars is always big
enough.
---unquote---
I have a dark feeling of foreboding that I'm chasing a RS-232 issue here.
Alas my knowledge in this realm is very limited; I do understand that ntpd
is doing something very smart by setting the port to 50 baud, but I am all
at sea to decide whether the strange bit pattern I get from tapping into
the serial port is correct or not. Presumably it isn't; it probably gets
gobs of 0x00's, very quickly (explains the rapid procession of error posts
in the ntpd log), and since it's 0x00's, the parity in the DCF telegram
will probably be crap - that's why it throws parity errors in the log.
Please, any ideas what's amiss here? ntpd is 4.2.8p10 (or 11, no
difference), with kernel 3.12.73.
Besides what others have said, make sure ttyS1 has been set to 1 stop
bit, no parity mode, as otherwise extra errors will happen.
Also make sure the tty hardware used can actually run at 50 bps, as not
all embedded UARTs can be set to that bit rate.
Since this is an embedded system, you should also look at interrupt
triggering GPIO pins as an alternative.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
