Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#1316 - kernel, serial line, pl2303 changes breaks ntpd with RAWDCF clock in V15 an V17 (works in V12) #6252

Open
openwrt-bot opened this issue Jan 31, 2018 · 0 comments
Labels

Comments

@openwrt-bot
Copy link

WRTHacker:

kernel time, pl2303, serial line kenel module

Device and Software:
TP-Link 4300v1
OpenWRT 17.01.4, r3560-79f57e422d
Component: kernel, serial line, pl2303

Setup:
ntpd V4.2.6p5 and V4.2.8p10(cross compiled with clock RAWDCF)
reference clock
server 127.127.8.0-3 mode 5
RAW DCF77 100/200ms pulses
pl2303 usb to serial adapter (/dev/ttyUSB0)
=> set to 50 Baud by ntpd when opening
DCF77 reciever connected per serial line to pl2303
=> No problem with V12.09 with Attitude Adjustment
Time decode with dcfd and ntpd works absolutely reliable.

The 100ms/200ms pulses send from the DCF77 reciever code bits "0" and "1".
The length of the signal on the serial RX line is decoded by the ntpd.
One bit per second is send. After 60 seconds the telegram is decoded to the actual time and date.
=> The puls length hat to be acurately "send" through the pl2303 to the kernel serial line driver into ntpd.

Problem:
Since V15, and also on the latest V17.01.4 the dcfd and ntpd could not decode the dcf telegram.
There always "1" decoded, or the transmission is invalid, due to inconsitency "flapping" bits

Suggestions:
Suspect some changes in the Linux kernel which effects the timne measurement
or inside the pl2303 driver, so the bits are not corretly decoded (100ms/200ms).

Reproduce/Debug:
I'm able to test new kernel and driver modules on my test environmet
perhaps "setserial" (can't fint it anywhere) can set some serial line parameters

Working well on TP-Link 4300, V12.09:

root@funk:~# ntpq -p
remote refid st t when poll reach delay offset jitter

*GENERIC(0) .DCFa. 0 l 24 64 377 0.000 -0.236 0.430
funk.koelle.... .INIT. 16 u - 1024 0 0.000 0.000 0.000
+ntps1-0.eecsit. .PPS. 1 u 52 64 177 28.454 -0.638 2.367
+ptbtime2.ptb.de .PTB. 1 u 20 64 377 19.201 -0.495 2.739
+rustime01.rus.u .PZF. 1 u 26 64 377 18.828 -1.042 2.059
+ntp2.rrze.uni-e .GPS. 1 u 32 64 377 19.264 -0.737 2.068
-ntp2.belwue.de .PZF. 1 u 43 64 377 21.406 -1.818 1.428
-ts-1.rz.rwth-aa .GPS. 1 u 13 64 377 18.941 -1.521 0.810
LOCAL(0) .LOCL. 10 l 4d 64 0 0.000 0.000 0.000

root@funk:~# ntpq -c clockv
associd=0 status=00e0 , 14 events, clk_unspec,
device="RAW DCF77 CODE (Conrad DCF77 receiver module)",
timecode="-####--#-#-###----M-S1-4-1--P-----2P1---1212-1-------81---p",
poll=5549, noreply=0, badformat=0, baddata=7, fudgetime1=191.700,
stratum=0, refid=DCFa, flags=0,
refclock_time="de1c9459.00000000 Wed, Jan 31 2018 19:15:37.000",
refclock_status="TIME CODE; (LEAP INDICATION; ANTENNA)",
refclock_format="RAW DCF77 Timecode",
refclock_states="*NOMINAL: 4d+02:30:16 (99.85%); ILLEGAL DATE: 00:08:37 (0.14%); running time: 4d+02:38:53"

It would be verry nice if someone could have an insight into this problem.

Many thanks

Lars

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant