Re: clockvar reporting from generic (DCF77)

>> 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 &"

Re: clockvar reporting from generic (DCF77)

Eric S. Raymond writes: > Achim, can I get a merge request from you for the DCF77 fix? I've sent a formatted patch to the list. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld:

Re: DCF77 driver seems to be broken

Yo Achim! On Mon, 20 Feb 2017 21:23:48 +0100 Achim Gratz wrote: > Subject: [PATCH] Fix parse and DCF77 refclock > > include/timespecops: Remove misleading definitions of the result > coding of the ternary comparison macros (the comments in that file are > still wrong).

Re: [Bug] 1361811cb botches unused macro

Gary E. Miller writes: > Clearly you understand this better than I. Patch please? Out of round tuits. May need to wait until the weekend. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ:

Re: DCF77 driver seems to be broken

Eric S. Raymond writes: > Achim Gratz : >> It wasn't a timeout, but a reversed application of an offset and a wrong >> conversion of the resulting delta value as an absolute timestamp… sigh. >> Here's the full patch that restores the DCF77 driver to function. > > I'll apply this

Re: clockvar reporting from generic (DCF77)

Gary E. Miller : > 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. Achim,

Re: clockvar reporting from generic (DCF77)

Yo Achim! On Mon, 20 Feb 2017 19:43:39 +0100 Achim Gratz wrote: > Gary E. Miller writes: > > Can you provide a few more details? Like how your refclock is > > setup in your ntp.conf and where the output you showed comes from? > > The refclock is configured in the usual

Re: Generic doesn't log into clockstat

Gary E. Miller writes: > Each refclock writes a different style clockstats. So tell us what you > would like logged. Like the NMEA clock: day, time of day, clock ID, timecode (optionally maybe the decoded time and flags from the timecode). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron

Re: [Bug] 1361811cb botches unused macro

Yo Achim! On Mon, 20 Feb 2017 19:38:52 +0100 Achim Gratz wrote: > Gary E. Miller writes: > > I am unclear which macro you are referring to? I thought were you > > talking about REFIDLEN, that is used a lot. > > The patch inadvertently removed the continuation line from >

Re: clockvar reporting from generic (DCF77)

Gary E. Miller writes: > Can you provide a few more details? Like how your refclock is setup in > your ntp.conf and where the output you showed comes from? The refclock is configured in the usual way and I'm talking about the output of 'ntpq -c "cv &1"'. The first problem is that ntpq seems to

Re: [Bug] 1361811cb botches unused macro

Gary E. Miller writes: > I am unclear which macro you are referring to? I thought were you talking > about REFIDLEN, that is used a lot. The patch inadvertently removed the continuation line from LEN_CRYPTO_TO_ZERO, which makes the macro define an incomplete expression. I'm not sure how that