clockvar reporting from generic (DCF77)

[Hal Murray]

>> I suspect the problem is back in ntpd, which is sending bad mode 6.
> Fortunately, that kind of thing is easy to fix once characterized. And I
> know that code *really* well.  Post an issue one you've figured out what's
> going wring, I'll be on it instantly. 

The ntpd side of ntpq -c "cv &<n>" (where n gets the parse refclock) is 
sending uninitialized stuff and/or non-text stuff.

The first message in this thread says:
--8<---------------cut here---------------start------------->8---
associd=30868 status=0000 no events, clk_unspec,
device="RAW DCF77 CODE (Conrad DCF77 receiver module)", name="RAWDCF_CONRAD",
timecodeWDCF_CONRAD"� poll="1, noreply=0,\r\nbadformat=0, baddata=0, fudgetime1=880.500, fudgetime2=27.350,\r\nstratum=0, refid=PCFk, flags=0, refclock_time="<UNDEFINED>",\r\nrefclock_status="", refclock_format="RAW DCF77 Timecode",\r\nrefclock_states="*NOMINAL: 00:00:07 (100.00%); running time: 00:00:07"refclock_driver_version="4.81 2009/05/01 10:15:29""
--8<---------------cut here---------------end--------------->8---

I see similar problems on other refclocks.  In particular the PPS driver.
device="PPS Clock Discipline", name="PPS",
timecodeS"� poll="59,\r\nnoreply=0

Looks like the timecode slot is sending garbage.  Maybe just uninialitized.  Or maybe just the close quote is missing.  Note the \r\n in the above.  Or maybe there is a " in the data text so the quotes get out of sync.

The  CC_TIMECODE slot does:
                ctl_putstr(clock_var[id].text,
                           pcs->p_lastcode,
                           (unsigned)pcs->lencode);
I'd guess the problem is that the p-lastcode and/or lencode slots aren't getting initialized correctly.

For something like the NMEA driver, they hold the last sentence received.



-- 
These are my opinions.  I hate spam.