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

LEDE Bugs lede-bugs at lists.infradead.org
Wed Jan 31 11:32:48 PST 2018


A new Flyspray task has been opened.  Details are below. 

User who did this - WRTHacker (WRTHacker) 

Attached to Project - OpenWrt/LEDE Project
Summary - kernel, serial line, pl2303 changes breaks ntpd with RAWDCF clock in V15 an V17 (works in V12)
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - 

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 at 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 at 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

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=1316



More information about the lede-bugs mailing list