You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
WRTHacker:
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
The text was updated successfully, but these errors were encountered: