Clock variables for DCF77

Achim Gratz Stromeko at nexgo.de
Sat Mar 9 21:10:28 UTC 2019


I have reported that quite some time ago already, but some recent
changes to how the system and clock variables are displayed make it much
more prominent and clearly that there's still some bug to squash:

--8<---------------cut here---------------start------------->8---
associd=12326 status=0000 no events, clk_unspec,
name="RAWDCF_CONRAD",
timecode="---#--####-#-##---M-S1-4----p-2---2p1--8---2412---1--81---P",
poll=50s, noreply=0, badformat=0, baddata=0, fudgetime1=880.500ms,
fudgetime2=30.350ms, stratum=0, refid=DCFa, flags=0,
device="RAW DCF77 CODE (Conrad DCF77 receiver module)",
clock_var_list="name,timecode,poll,noreply,badformat,baddata,fudgetime1,fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_ppsskew,refclock_ppstime,refclock_time,ref
clock_status,refclock_format,refclock_states,,\x0c\x0c\x01,\x01",
refclock_ppsskew=883.980368,
refclock_ppstime="e02ea90c.ffbaa7b9 2019-03-09T21:05:16.998Z",
refclock_time="e02ea90d.00000000 2019-03-09T21:05:17.000Z",
refclock_status="TIME CODE; PPS; (LEAP INDICATION; PPS SIGNAL; CALLBIT)",
refclock_format="RAW DCF77 Timecode",
refclock_states="*NOMINAL: 00:13:18 (100.00%); running time: 00:13:18"refclock_driver_version="4.81 2009/05/01 10:15:29",
="", ^=""
--8<---------------cut here---------------end--------------->8---

Note the trailing binary garbage in the clock_var_list and the failed
attempts at printing something useful with them, which maims the output
for refclock_states (and I have no idea where refclock_driver_version
comes from, as it's not in clock_var_list).  The binary garbage and
resulting output changes with each read of the clock, so it must somehow
be related to the data it receives.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada



More information about the devel mailing list