ntpsec: reference driver 38/hopf 6021

Martin Kotzan m-ntp at kotzan.net
Tue Jul 5 20:22:14 UTC 2016

On 2016-07-05 11:32, Eric S. Raymond wrote:
> Looking over old email, I find I may have made a mistake.  A few weeks 
> ago I
> discovered that the generic driver supports the Hopf 6021 - it's 
> subtype 12.
> Accordingly, forgetting that I had received this request, I deleted the
> dedicated Hopf 6021 driver.
> The dedicated 6021 driver can be restored, but I would prefer not to do 
> it
> if generic subtype 12 works.  Parse drivers are smaller and better 
> factored
> than the standalone ones - the right direction is to move code into the
> generic driver, not out.
> Martin, would you please test that generic mode 12 on a 6021?

I tested a Hopf 6855 with ntp classic (4.2.4p3), but the test clock was 
connected to an antenna (normal for our test systems), so the output 
byte contains a few bits marking the clock source as "crystal operation"
(the Hopf clock guarantees high accuracy during reception outages).

The Hopf driver can be configured to ignore this, the PARSE driver has a
more advanced method for this feature that doesn't work for crystal-only

Relevant snippet of ntp.conf with the HOPF driver:
fudge   flag1 1"

=> Ok [1].

Same for the PARSE driver:
"server     mode 12
fudge     time2 1000000000 flag1 1"

=> No sync, "reach" is zero. I added the fudge values time2 and flag1 to 
the driver accept unconfirmed time values [2], but as documented they 
only work if sync is lost during runtime.
The parameters are parsed successfully (log message
"PARSE receiver #1: new trust time 11574d+01:46:40"), but there is no 
effect on sync.

The serial connection is working fine:

     ntpq -c clocklist

assID=0 status=0404 clk_badsignal, last_clk_badsignal,
device="HOPF 6021", timecode="\x024A125340050716\x0a\x0d\x03", poll=12,
noreply=0, badformat=0, baddata=1, fudgetime1=0.000, stratum=0,
refid=DCF, flags=0,
refclock_time="db262c54.00000000  Tue, Jul  5 2016 12:53:40.000",
refclock_format="hopf Funkuhr 6021",
refclock_states="*PROPAGATION DELAY: 00:12:08 (99.86%); ILLEGAL DATE: 
00:00:01 (0.13%); running time: 00:12:09"

I assume the normal case with the clock attached to an antenna will 
do you want me to test that? I should be able to find a test system for 
sometime next week.

Documentation of flag parameter:
flag1 0 | 1
     When set to 1, driver sync's even if only crystal driven.

"time2 time
     If flag1 is 0, time2 specifies the offset of the PPS signal from the 
time (PPS fine tuning). If flag1 is 1, time2 specifies the number of 
seconds a
receiver with a premium local oscillator can be trusted after losing 

More information about the devel mailing list