ntpsec: reference driver 38/hopf 6021

[Martin Kotzan]

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 
not
connected to an antenna (normal for our test systems), so the output 
status
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
operation:


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

=> Ok [1].

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


=> No sync, "reach" is zero. I added the fudge values time2 and flag1 to 
make
the driver accept unconfirmed time values [2], but as documented they 
probably
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_status="TIME CODE NOT CONFIRMED; UTC DISPLAY; TIME CODE",
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 
work,
do you want me to test that? I should be able to find a test system for 
that
sometime next week.

1)
Documentation of flag parameter:
http://doc.ntp.org/4.2.6/drivers/driver38.html
flag1 0 | 1
     When set to 1, driver sync's even if only crystal driven.

2)
https://docs.ntpsec.org/latest/driver_generic.html
"time2 time
     If flag1 is 0, time2 specifies the offset of the PPS signal from the 
actual
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 
synchronisation"