Hi all,

This may be a FAQ or otherwise stupid question, but I have tried finding
an answer myself and failed. So here goes:

I have a Conrad DCF77 receiver board, and I'm looking for the Right Way
of plugging it into ntpd. Easy enough, one would think, but it appears
that people are using radioclk in conjunction with the SHM refclock
driver instead of the Generic Reference Driver (127.127.8.u) which is
the one you come upon first if you start looking.

Why would they do this?

--B

PS - I have tried neither; I first want to establish which choice would
      be my best bet ;-)

When you have any answers please add them to twiki.ntp.org .

H

Bart,
  I have been using the SHM driver as that is what was recommended by
Jonathan Buzzard who posted his design. It works a charm, so I never 
tried another.
Mike

Bart Smit wrote:
> Hi all,
> 
> This may be a FAQ or otherwise stupid question, but I have tried finding
> an answer myself and failed. So here goes:
> 
> I have a Conrad DCF77 receiver board, and I'm looking for the Right Way
> of plugging it into ntpd. Easy enough, one would think, but it appears
> that people are using radioclk in conjunction with the SHM refclock
> driver instead of the Generic Reference Driver (127.127.8.u) which is
> the one you come upon first if you start looking.
> 
> Why would they do this?
> 
> --B
> 
> PS - I have tried neither; I first want to establish which choice would
>      be my best bet ;-)
> 
> 

On Mon, 31 May 2004 22:09:08 +0200, Bart Smit wrote:

> Hi all,
> 
> This may be a FAQ or otherwise stupid question, but I have tried finding
> an answer myself and failed. So here goes:
> 
> I have a Conrad DCF77 receiver board, and I'm looking for the Right Way
> of plugging it into ntpd. Easy enough, one would think, but it appears
> that people are using radioclk in conjunction with the SHM refclock
> driver instead of the Generic Reference Driver (127.127.8.u) which is
> the one you come upon first if you start looking.
> 
> Why would they do this?

Because firstly the extra circuitry required to interface it to the serial
port is much simpler if you use radioclkd. Secondly you get much better
performance if you use radioclkd instead of the parse clock driver.

Of course I am somewhat biased, but I have never seen anyone dispute the
above statements and I have had lots of comments about improved
performance. For my mind the two reasons give above would be enough.

However there is more, with radioclkd you can run more than one clock
from the same serial port. There there is a good chance you can
get MSF in the Netherlands for example. There is also potential
scope with radioclkd for adding in filtering for noisy signals for
improved performance with marginal signals. This last one has
not been done, as I have not had time, but would be very hard to
do with the parse clock driver.

JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Hi Bart,

Bart Smit wrote:
> I have a Conrad DCF77 receiver board, and I'm looking for the Right Way
> of plugging it into ntpd. Easy enough, one would think, but it appears
> that people are using radioclk in conjunction with the SHM refclock
> driver instead of the Generic Reference Driver (127.127.8.u) which is
> the one you come upon first if you start looking.

the parse-driver for raw DCF signals built into NTP has it's weaknesses,
because it does not deal well with errors from the receiver.

Nevertheless I'm sure the built in driver would work well enough for most
people, radioclkd just makes it easy to get improved performance.

        Chris

It appears that radioclkd is pretty much Linux-only, but finally
http://www.jonatkins.com/radioclk2/ did the trick for me.

Thank you for pointing me in the right direction. I especially like
the idea of having both a DCF77 and an MSF receiver for redundancy
and failover. I will add MSF as soon as I can get my hands on a
receiver board.

I'm using your circuit from
http://www.buzzard.org.uk/jonathan/radioclock.html and it works fine.

thanks again,

--B

In one of my infrequent on-line spells, I ventured wayback in
time and noted the following conversation:

> > I have a Conrad DCF77 receiver board, and I'm looking for the Right Way
> > of plugging it into ntpd. Easy enough, one would think, but it appears
> > that people are using radioclk in conjunction with the SHM refclock
> > driver instead of the Generic Reference Driver (127.127.8.u) which is
> > the one you come upon first if you start looking.
> > Why would they do this?

> Because firstly the extra circuitry required to interface it to the serial
> port is much simpler if you use radioclkd. Secondly you get much better
> performance if you use radioclkd instead of the parse clock driver.
> 
> Of course I am somewhat biased, but I have never seen anyone dispute the
> above statements and I have had lots of comments about improved
> performance. For my mind the two reasons give above would be enough.

May I volunteer?

I'm not sure how the circuitry is simpler (other than a jumper from
the serial port DCD pin to the data pin, which I'd hardly even
qualify as `simpler'.  Or perhaps a second transistor to invert
the signal polarity -- if needed, I believe that the module in
question can deliver the opposite polarity rather trivially.
In my case of a home-hacked clock, I needed two transistors
anyway to achieve the required gain from the IC clock data
pin -- one just didn't drive the serial port 100% reliably,
but my particular clocks are the exception and not the rule.

(There is the matter that by default, radioclkd expects the
opposite polarity signal than the parse/pps driver, but long
ago I've posted the hacks needed for radioclkd to grok both,
and with luck, automagically.)

And secondly, concerning performance, this is likely to depend
on your operating system and how you've configured ntpd as
much as anything, but I find that radioclkd gives slightly
worse performance than the parse driver, which itself is
slightly worse than the PPS driver, based on eyeballing the
ntpq billboards.  But my particular data appears to depend
on the quality of the DCF decoder as much as anything, which
affects how radioclkd shows jitter, and most importantly the
hacks I've added to radioclkd as opposed to the stock out-of-
the box software.

(What I mean there is that I pass the data of every start-
second pulse to ntpd to deal with, while I believe that a
normal radioclkd discards a bunch to smooth and average
the data and also passes the data less frequently.  Compare
this with the PPS driver receiving data every second, and a
pps-enabled parse driver getting the same, while a bog-standard
parse driver only gets one update a minute, with added
jitter from the serial port circuitry and the low baud rate
used.  The last is almost certainly the cause of poor
observed performance.)

Concerning OS choice, I'm using FreeBSD, which has the
TIOCDCDTIMESTAMP call that is the reason for needing the
polarity signal inverted from the radioclkd/circuit default.
As the name implies, this requires the signal at the DCD
serial port pin, as opposed to the simplest GENERIC parse
driver configuration of the data input pin.  No big deal,
the jumper I noted between the two pins suffices for this
splendidly, furnishing both (or all three) drivers with
data.

As far as software configuration, I've cranked down the
minpoll interval to the minimum, to get more updates to
work with per minute, and also enabled some unremembered
configfile option to grab several samples at each update,
again to have more data to work with.  This with all the
drivers, and as noted, with radioclkd updating the shared
memory segment at every start-of-second pulse.

These notes are valid for the DCF77 signal that the many
dozens of radio clocks I have receive (I'm too cheap to
buy a proper module for this), and may perhaps not be
valid for MSF and other formats where theoretically the
PPS driver might have problems with the start-of-second
pulse.

Enough talk, here's a random billboard:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+GENERIC(0)      .DCFa.           0 ?    2   16  377    0.000    1.027   1.765
oPPS(1)          .PPS.            0 ?    1   16  377    0.000    0.304   0.842
 LOCAL(2)        LOCAL(2)         9 ?   25   64  377    0.000    0.000   0.015
+SHM(0)          .DCFa.           0 ?    1   16  371    0.000   -1.506   2.031

The criterium by which I define `better performance' is
the jitter figure.  This data is not representative, as the
computer it's from is a ten-year-old thing whose interrupt
lines are being hit with disk activity, but also this particular
clock hardware delivers data with much greater jitter than
other clocks I have.  I've posted the data long ago from the
better clock, where all jitter figures will be about ten times
less.  Anyway, the trend is clear (and remains pretty constant
regardless of my clock hardware):  PPS delivers the highest
quality data, GENERIC is about 2x this value, and radioclkd
is a bit worse.

Without pps-futzing the parse driver, its performance is
indeed several times worse (higher jitter) than radioclkd.
If I recall (and I freely admit ignorance), this requires
ppskit or something for Linux; most BSDen support this by
default.  I don't know about other OSen.


In summary:  I take exception to your claim that radioclkd
always will give better performance than the parse driver.
However, with the caveat that you need to properly configure
things (which in my case isn't difficult).

The biggest caveat is that I'm not comparing the radioclkd
which pre-processes the data before passing it to ntpd by
doing its own smoothing, because I simply have been too
lazy to build that source and run it side-by-side with the
other three drivers.  Such processing (as opposed to the
way I have ntpd doing filtering itself) may well tip the
scales the other way.  As the raw timestamps used by the
three drivers should be identical, I can only imagine that
the PPS driver has the most refined processing within ntpd.
(If the other drivers only grab a burst of data at each
poll interval, that could explain some of the difference
if the pps driver uses every bit of data it sees.)

Nonetheless, when I see jitter figures of under 100 usec,
the performance difference between radioclkd and the others
is not important, and is overshadowed by the variance of the
jitter seen over time.

Anyway, I just couldn't let those statements go unchallenged.
Shoot me if you please.



> However there is more, with radioclkd you can run more than one clock
> from the same serial port.

This is very true.  Also, the parse driver will sometimes
decode false data from marginal signals, and radioclkd does
not need a full minute of data to decode the time -- important
for speeding my boot where I set the system clock from 1980
to the present time based on DCF data.

On the other hand, on my old machines, there will infrequently
be times when delayed interrupts cause radioclkd to think a
pulse is out of the tolerance value, while the parse driver is
able to decode the same data.  This may also be a lack of
the Linux ioctl TIOCMIWAIT which could help to more accurately
determine pulse width, or it could be a problem in the OS
interrupt handling code.

Anyway, there's no reason to have to choose one (radioclkd/
shm vs parse and/or pps) over the other for DCF77 signals
(with OS qualifications), so I happily use both -- circuitry
and software hacks as noted earlier.  If forced at gunpoint
to only use one, I'd use radioclkd.

(or not.  hmm, just remembered the ntpd software limitation I
had to hack around in order to get shm data to set my system
time at boot -- no cmos battery, I won't bore you to tears
by explaining why -- so for large time steps (>4 hours)
you'll need GENERIC.  Okay, they both have advantages and
disadvantages out-of-the-box but worksrounds are possible)


note that I'm probably biased too, somehow.  probably shows.

barry bouwsma

On Tue, 08 Jun 2004 08:43:20 +0000, Barry Bouwsma wrote:

> 
> In one of my infrequent on-line spells, I ventured wayback in
> time and noted the following conversation:
> 
>> > I have a Conrad DCF77 receiver board, and I'm looking for the Right Way
>> > of plugging it into ntpd. Easy enough, one would think, but it appears
>> > that people are using radioclk in conjunction with the SHM refclock
>> > driver instead of the Generic Reference Driver (127.127.8.u) which is
>> > the one you come upon first if you start looking.
>> > Why would they do this?
> 
>> Because firstly the extra circuitry required to interface it to the serial
>> port is much simpler if you use radioclkd. Secondly you get much better
>> performance if you use radioclkd instead of the parse clock driver.
>> 
>> Of course I am somewhat biased, but I have never seen anyone dispute the
>> above statements and I have had lots of comments about improved
>> performance. For my mind the two reasons give above would be enough.
> 
> May I volunteer?
> 
> I'm not sure how the circuitry is simpler (other than a jumper from
> the serial port DCD pin to the data pin, which I'd hardly even
> qualify as `simpler'.  Or perhaps a second transistor to invert
> the signal polarity -- if needed, I believe that the module in
> question can deliver the opposite polarity rather trivially.
> In my case of a home-hacked clock, I needed two transistors
> anyway to achieve the required gain from the IC clock data
> pin -- one just didn't drive the serial port 100% reliably,
> but my particular clocks are the exception and not the rule.

Because to the best of my knowledge to drive the TxD line
of a serial port requires an op-amp. You cannot do it reliably
using a transistor in either open collector or emitter follower
mode.

> (There is the matter that by default, radioclkd expects the
> opposite polarity signal than the parse/pps driver, but long
> ago I've posted the hacks needed for radioclkd to grok both,
> and with luck, automagically.)

Note that radioclkd expects the pulse to follow the transmitted
signal. Not my fault that lots of DCF stuff inverts the transmitted
pulse.

> And secondly, concerning performance, this is likely to depend
> on your operating system and how you've configured ntpd as
> much as anything, but I find that radioclkd gives slightly
> worse performance than the parse driver, which itself is
> slightly worse than the PPS driver, based on eyeballing the
> ntpq billboards.  But my particular data appears to depend
> on the quality of the DCF decoder as much as anything, which
> affects how radioclkd shows jitter, and most importantly the
> hacks I've added to radioclkd as opposed to the stock out-of-
> the box software.

The stock radioclkd, surpasses the performance of the parse
clock drivers by a significant factor. Early versions where
similar, but the current version is significantly improved.

> (What I mean there is that I pass the data of every start-
> second pulse to ntpd to deal with, while I believe that a
> normal radioclkd discards a bunch to smooth and average
> the data and also passes the data less frequently.  Compare
> this with the PPS driver receiving data every second, and a
> pps-enabled parse driver getting the same, while a bog-standard
> parse driver only gets one update a minute, with added
> jitter from the serial port circuitry and the low baud rate
> used.  The last is almost certainly the cause of poor
> observed performance.)
> 
> Concerning OS choice, I'm using FreeBSD, which has the
> TIOCDCDTIMESTAMP call that is the reason for needing the
> polarity signal inverted from the radioclkd/circuit default.
> As the name implies, this requires the signal at the DCD
> serial port pin, as opposed to the simplest GENERIC parse
> driver configuration of the data input pin.  No big deal,
> the jumper I noted between the two pins suffices for this
> splendidly, furnishing both (or all three) drivers with
> data.
> 
> 
> The criterium by which I define `better performance' is
> the jitter figure.  This data is not representative, as the
> computer it's from is a ten-year-old thing whose interrupt
> lines are being hit with disk activity, but also this particular
> clock hardware delivers data with much greater jitter than
> other clocks I have.  I've posted the data long ago from the
> better clock, where all jitter figures will be about ten times
> less.  Anyway, the trend is clear (and remains pretty constant
> regardless of my clock hardware):  PPS delivers the highest
> quality data, GENERIC is about 2x this value, and radioclkd
> is a bit worse.

This data is miss-leading, because you are using old radioclkd
software.
 
> Without pps-futzing the parse driver, its performance is
> indeed several times worse (higher jitter) than radioclkd.
> If I recall (and I freely admit ignorance), this requires
> ppskit or something for Linux; most BSDen support this by
> default.  I don't know about other OSen.
> 
> 
> In summary:  I take exception to your claim that radioclkd
> always will give better performance than the parse driver.
> However, with the caveat that you need to properly configure
> things (which in my case isn't difficult).

I take massive exception to you using old versions of the software
in making comparisons. 

> The biggest caveat is that I'm not comparing the radioclkd
> which pre-processes the data before passing it to ntpd by
> doing its own smoothing, because I simply have been too
> lazy to build that source and run it side-by-side with the
> other three drivers.  Such processing (as opposed to the
> way I have ntpd doing filtering itself) may well tip the
> scales the other way.

It most certainly does.

  As the raw timestamps used by the
> three drivers should be identical, I can only imagine that
> the PPS driver has the most refined processing within ntpd.
> (If the other drivers only grab a burst of data at each
> poll interval, that could explain some of the difference
> if the pps driver uses every bit of data it sees.)

The pps driver should give the best performance because the time
stamps for the pulses are taken by the OS.

> Nonetheless, when I see jitter figures of under 100 usec,
> the performance difference between radioclkd and the others
> is not important, and is overshadowed by the variance of the
> jitter seen over time.
> 
> Anyway, I just couldn't let those statements go unchallenged.
> Shoot me if you please.

Consider yourself shot then. The software has changed significantly
in the way it passed the time to ntpd which made for a jump in improvement
of the jitter figure. Now radioclkd easily surpasses the performance of
the parse driver and approaches the performance of the pps driver.
I suspect that on a preemptive Linux kernel the performance would be
very close, though I have not had the time to test.

> 
> 
>> However there is more, with radioclkd you can run more than one clock
>> from the same serial port.
> 
> This is very true.  Also, the parse driver will sometimes
> decode false data from marginal signals, and radioclkd does
> not need a full minute of data to decode the time -- important
> for speeding my boot where I set the system clock from 1980
> to the present time based on DCF data.

In addition radioclkd will also decode MSF, and WWVB signals,
something that the parse clock driver does not.

JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Good evening Jonathan,

Jonathan Buzzard wrote:
> Because to the best of my knowledge to drive the TxD line
> of a serial port requires an op-amp. You cannot do it reliably
> using a transistor in either open collector or emitter follower
> mode.

EIA/TIA-232-E defines the receiver to identify the high-level with a voltage
between +3V and +15V on the input, low between -15V and -3V. But
fortunuately most rs232-receivers used in computers choose a conveniently
ttl-compatible (about 2V) threshold instead of the more straigtforward
symmetric one (0V).

And yes, I have successfully run two of the 'Conrad' receiver modules (which
use an open-collector NPN-transistor) with a pullup on several computers'
serial ports' DCD and RxD inputs.

        Chris

On Fri, 11 Jun 2004 21:44:27 +0200, Christian Vogel wrote:

> Good evening Jonathan,
> 
> Jonathan Buzzard wrote:
>> Because to the best of my knowledge to drive the TxD line
>> of a serial port requires an op-amp. You cannot do it reliably
>> using a transistor in either open collector or emitter follower
>> mode.
> 
> EIA/TIA-232-E defines the receiver to identify the high-level with a voltage
> between +3V and +15V on the input, low between -15V and -3V. But
> fortunuately most rs232-receivers used in computers choose a conveniently
> ttl-compatible (about 2V) threshold instead of the more straigtforward
> symmetric one (0V).

Well a proper RS232 port, does not do anything at 0V you have to pull
it all the way down to -3V or up to +3V for it to register a change.
So for example if you are at 5V drop to -1V and then go back to 5V
the port will not register a change.

> And yes, I have successfully run two of the 'Conrad' receiver modules (which
> use an open-collector NPN-transistor) with a pullup on several computers'
> serial ports' DCD and RxD inputs.

Well all I can say is that it does not work with the 5 Toshiba laptops
that I tried it with.

JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Jonathan Buzzard wrote:
> On Fri, 11 Jun 2004 21:44:27 +0200, Christian Vogel wrote:
> Well all I can say is that it does not work with the 5 Toshiba laptops
> that I tried it with.

I always had bad experiences putting anything port-powered on
notebooks/laptops. (parallel dongles, serial clocks, serial
optoisolated "whatever"...; on old Compaq, Toshiba and halfway current IBM
notebooks)

        Chris

In article <pan.2004.06.12.09.09.30.425907@uk.me.buzzard>,
Jonathan Buzzard <jonathan@uk.me.buzzard> wrote:

> 
> EIA/TIA-232-E defines the receiver to identify the high-level with a voltage
> between +3V and +15V on the input, low between -15V and -3V. But

Actually, it doesn't.  The 3V is a constraint on a powered up transmitter.
A receiver is allowed to transition anywhere within the range -3 to +3V,
with or without hysteresis.  For certain modem control circuits (see
section 2.5 of the specification), and therefore effectively for all
IC implementations, it is also required to register off when grounded
through 300 ohms (or greater, including open circuit, and strictly only
defined for voltages above 2V).  The effect of this constraint is that
real receivers have both positive and negative transitions at small
positive voltages.

The transmitter is required to drive monotonically between the -3 and +3V
levels and not to drive beyond the -15 and +15V levels.

> Well a proper RS232 port, does not do anything at 0V you have to pull
> it all the way down to -3V or up to +3V for it to register a change.

Not a requirement.  In fact, there is an explicit statement that
hysterisis is optional.

> So for example if you are at 5V drop to -1V and then go back to 5V
> the port will not register a change.

This is out of specification for a driver, but a receiver more or less 
has to transition both ways if it is going to be compliant with the power
off driver requirements.

(To be completely accurate, one would have to allow for a receiver being
permitted to have an open circuit input voltage of up to 2V.)

On Sun, 13 Jun 2004 17:09:03 +0100, David Woolley wrote:

> In article <pan.2004.06.12.09.09.30.425907@uk.me.buzzard>,
> Jonathan Buzzard <jonathan@uk.me.buzzard> wrote:
> 
>> 
>> EIA/TIA-232-E defines the receiver to identify the high-level with a voltage
>> between +3V and +15V on the input, low between -15V and -3V. But
> 
> Actually, it doesn't.  The 3V is a constraint on a powered up transmitter.
> A receiver is allowed to transition anywhere within the range -3 to +3V,
> with or without hysteresis.  For certain modem control circuits (see
> section 2.5 of the specification), and therefore effectively for all
> IC implementations, it is also required to register off when grounded
> through 300 ohms (or greater, including open circuit, and strictly only
> defined for voltages above 2V).  The effect of this constraint is that
> real receivers have both positive and negative transitions at small
> positive voltages.
> 
> The transmitter is required to drive monotonically between the -3 and +3V
> levels and not to drive beyond the -15 and +15V levels.
> 
>> Well a proper RS232 port, does not do anything at 0V you have to pull
>> it all the way down to -3V or up to +3V for it to register a change.
> 
> Not a requirement.  In fact, there is an explicit statement that
> hysterisis is optional.

Oh well, I was under the distinct impression it was not optional but
that nobody bothered with it. Perhaps it was in the very first RS232
specifications (which predate EIA/TIA-232-E) but was then latter made
optional.

>> So for example if you are at 5V drop to -1V and then go back to 5V
>> the port will not register a change.
> 
> This is out of specification for a driver, but a receiver more or less 
> has to transition both ways if it is going to be compliant with the power
> off driver requirements.

I never said it was in specification for a driver. The idea of the
hysteresis is that it introduces a significant level of noise immunity.

JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Apologies for the excessive delay in this followup, as usual.  My life sucks.
And if there were any related followups during the time I was offline and
missed them, sorry for missing them.  I hope this is still relevant after
over a month.

Jonathan Buzzard <jonathan@uk.me.buzzard> wrote on Fri, 11 Jun 2004 to wit:

> On Tue, 08 Jun 2004 08:43:20 +0000, Barry Bouwsma wrote:
> >> > I have a Conrad DCF77 receiver board, and I'm looking for the Right Way
> >> > of plugging it into ntpd. Easy enough, one would think, but it appears
> >> > that people are using radioclk in conjunction with the SHM refclock
> >> > driver instead of the Generic Reference Driver (127.127.8.u) which is
> >> > the one you come upon first if you start looking.
> >> > Why would they do this?

> >> Because firstly the extra circuitry required to interface it to the serial
> >> port is much simpler if you use radioclkd. Secondly you get much better
> >> performance if you use radioclkd instead of the parse clock driver.

> > I'm not sure how the circuitry is simpler (other than a jumper from

> Because to the best of my knowledge to drive the TxD line
> of a serial port requires an op-amp. You cannot do it reliably
> using a transistor in either open collector or emitter follower
> mode.

Well, I've been doing it all wrong, then, from back in the days of
110 baud acoustic couplers when I built myself a modem (for direct
connection to the phone line, in violation of the then-applicable
rules about connection of customer equipment to the monopoly phone
company lines) out of discrete components, to my own design, which
drove the serial port of a dumb terminal.  Ever since that time
(when I probably actually looked at the data sheets for the 1488 or
1489 or whatever was in the terminal), I've never given a second
thought to driving a serial port from a voltage swinging from close
to 0V up to a few volts positive.

And that is indeed what I'm doing to this day, with several ancient
machines (but newer than my long-deceased Bell 103-like modem-thingy)
with never a problem.  Specs be damned, I say.

Until I have problems, at which time I'd consult the specs and slap
myself around a bit.  Like I always say, Do First; Troubleshoot Later.

In any case, Works For Me[tm]...  YkmMV, Beware of Dog, and all that.



> > And secondly, concerning performance, this is likely to depend

> > other clocks I have.  I've posted the data long ago from the
> > better clock, where all jitter figures will be about ten times
> > less.  Anyway, the trend is clear (and remains pretty constant

> This data is miss-leading, because you are using old radioclkd
> software.
 
> I take massive exception to you using old versions of the software
> in making comparisons. 

The reason I've used old versions of the software is because I've
incorporated a goodly amount of portability patches as well as
performance improvements to match my requirements, and I haven't
felt like throwing that away, while I've obtained what I feel is
satisfactory performance from the based-on-old-version software
I've been using happily.

And when reviewing the newer software, I've only seen one part
of it which would make a significant impact on `quality', which
is the averaging of each minute's worth of data to smooth it and
deliver a more polished time sample to ntpd, which in fact runs
directly counter to the hacks I introduced, so that radioclkd
(my version) would deliver a continuous stream of data to ntpd,
to match what both the PPS and GENERIC PARSE drivers (can) do.

Nonetheless, I took this as another challenge.  First I attempted
to build the newer software, and got even less into the build than
with the older software (the newer Makefile, unlike the old, is
incompatible with my Berkeley `make'), before discovering that
the new software was no more portable to my OS than the old.

So then I added the portability patches to get it to compile,
and then spent more time than I wished trying (unsuccessfully)
to make it work with my hardware -- there's probably something
blindingly simple in my polarity-flippin' code I'm overlooking,
but there have been rather significant changes since the old
version I hacked that require me to study further in order to
do it right.

So instead I decided to try an alternative approach, merging in
the averaging code from the new version into the old already-
hacked-and-running version I've used.  There should be no
difference in quality of performance between the new and old
in such a case, as ideally I'd hack the new version to use the
same method to collect timestamps as the old, and I saw nothing
else in the newer code that would affect performance.

That worked, but the hack is so ugly and specific to my particular
software that I have no intention of revealing it, while if I
ever get around to making the new version properly portable to
my OS/hardware like the old, I might consider sharing those hacks.

(My hack also seems to choke and die after several hours upon
receiving bad data, but I'm obviously missing something; anyway
I meant this hack more of a proof of concept than anything, for
which it suffices admirably.)



> > The biggest caveat is that I'm not comparing the radioclkd
> > which pre-processes the data before passing it to ntpd by
> > doing its own smoothing, because I simply have been too
> > lazy to build that source and run it side-by-side with the
> > other three drivers.  Such processing (as opposed to the
> > way I have ntpd doing filtering itself) may well tip the
> > scales the other way.

> It most certainly does.

But it comes with considerable tradeoffs in responsiveness and
apparently also in utility, in comparison with my old version.
I'm running all four together (GENERIC, PPS, old-hacked-
radioclkd, and newly-hacked-radioclkd) now with the same DCF77
data, and while the jitter figure is comparable to the PPS
figure or lower in initial observation, there are drawbacks
that seem to make me hesitant to use this data as primary or
sole source.


> The pps driver should give the best performance because the time
> stamps for the pulses are taken by the OS.

Erm, in all four cases for my active reference clocks, the OS
is taking the timestamp.  This goes for both my instances of
radioclkd, and as I've noted earlier, this is due to the hacks
I've added to match my use of BSD as OSen and their ioctls.

This is why the performance of the PPS and PARSE drivers and my
old hacked radioclkd should have shown only the difference in
how ntpd itself processes the data it receives, regardless over
what interface (shm or however) it arrives.

That is why I felt reasonably confident comparing the performance
of the three, as it seemed like comparing apples with pineapples.
Now, with the very different way the new radioclkd processes the
data and the much less frequent rate at which it passes that to
ntpd, I have the feeling that my present configuration compares
apples with Erdapfelsalat or something.  Mahlzeit.



> > Shoot me if you please.

> Consider yourself shot then. The software has changed significantly
> in the way it passed the time to ntpd which made for a jump in improvement
> of the jitter figure. Now radioclkd easily surpasses the performance of
> the parse driver and approaches the performance of the pps driver.

Okay, with one (noticeably jittery) reference clock, I see new-
radioclkd jitter figures that sometimes are several times lower
than the PPS jitter figures, and sometimes comparable or slightly
worse, so indeed, the raw jitter figures can be improved from the
data of my old radioclkd+hacks by a factor of 3 to 10, or so.

Of course, I also need to check in a different less-radio-noisy
location with a more stable clock.  On a slightly newer machine with
a bit more stable performance regarding interrupts.  (See below)

But to address the tradeoffs/drawbacks.  This `stability' comes, as
I noted, at the cost of responsiveness (meaning, sending new data to
ntpd).  As a result, the new radioclkd has just started to deliver
data to ntpd long after the other three reference clocks driven by
the same signal have stabilized and delivered a usable peer.  Most
of the time, the first clock to deliver data and appear on the
peer list is my old-hacked radioclkd.

In my particular case, where I use the data from radioclkd at boot
to set my OS clock, I suspect that I would see an increase in my
boot time by several minutes.  One of these days I'll verify this.
(Actually, I may be wrong, but it appears I can't use it -- at least
in the few tests I made, it looks like `ntpd -q' as a substitute
for `ntpdate' needs to make use of a source that updates its data
far more frequently than once per minute.  At least, I was never
patient enough to let `ntpd -q' step the time after several minutes
of getting valid data, then losing it soon after.  Admittedly, my
ntpd source is rather old too, but it seems that as soon as I give
the `-q' option, I get notices every second that there's stale SHM
data.)

The `reach' column of the `ntpq' peerlist reflects the infrequent
updates, when minpoll is set low for responsiveness from a reference
clock, obviously.  Of course, with infrequent updates, the wisdom
of keeping minpoll at 16sec intervals is dubious, though it does
guarantee fresh data gets snarfed more quickly and that none goes
missing -- it's also the reason for the far better responsiveness
of the other reference clocks.

Oh, here's a billboard, with the updated radioclkd at bottom (SHM1):
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+GENERIC(0)      .DCFa.           0 ?    -   16  377    0.000    0.049   0.589
oPPS(1)          .PPS.            0 ?    -   16  277    0.000   -0.315   0.410
 LOCAL(2)        LOCAL(2)         9 ?   61   64  377    0.000    0.000   0.015
+SHM(0)          .DCFa.           0 ?    7   16  377    0.000   -0.261   1.180
 SHM(1)          .DCFa.           0 ?   30   16   42    0.000   -0.373   0.103

As noted, the jitter figures vary wildly, so this sample is no more
or less representative than any other I've seen with this clock and
hardware combination -- though this is on a busy old machine, and
the offset still hasn't stabilized, and as noted, this particular
clock delivers inherently more unstable pulses.  I'll compare later
on another machine in an RF-quieter location and I've summarized
hat data below in this message.  I have a feeling that the presence
of several-hundred-microsecond jumps in the start-of-second data
affects the GENERIC PARSE and update-every-second-without-any-
smoothing drivers far more than the PPS driver, and that the smoothing
of the later radioclkd when fed such unstable data makes a bigger
difference than I'd see with the better clock in a quieter location.
That made no sense, right?


And just to be clear, this updated radioclkd is *not* built from the
new source (because it wouldn't without more work than I put into it)
but is only with the averaging code hacked into the old radioclkd I've
used (immediately above as SMH0).  There should be no performance
difference between the latest code and the updated hacked code.
In the event that there is, please disregard the entirety of this
message.

There is the possibility to increase responsiveness by updating the
shared memory segment with every pulse, and still delivering a smooth
averaged signal, by averaging out the last N pieces of clock data,
choosing N as appropriate.  If I get motivated, I may think about
coding this into my hacks.  In fact, it almost seems to be worth the
effort, though I can't code to save my life.


> In addition radioclkd will also decode MSF, and WWVB signals,
> something that the parse clock driver does not.

Not relevant to the original question, which was why one would choose
one driver over another with a DCF77 signal.  Naturally, where these
other signals are concerned, one has little choice.


Oh bugger, my hack wasn't good enough to withstand an extended
problem signal, but I think I know why.  Anyway, during this time
(problem induced by machine activity), both radioclkds lost the
ability to decode the data for a few minutes while the PPS and
GENERIC drivers still came through for the most part.



What does this all mean?

1)  I can't code worth a darn.
2)  My hacking skills are suspect too.
3)  There is a difference between the newer radioclkd, the older
    radioclkd, and my hacked version based on the older one
4)  No kidding.  Really.
5)  Whether this difference is an improvement, depends on how
    one gives priority to the things that are different.  There
    is no difference in responsiveness between the old and new
    original radioclkd sources; there is a significant reduction
    in the jitter figure.
6)  My hacked version of the old radioclkd gives much increased
    responsiveness and allows one to successfully use the lowest
    minpoll value, but this at the moment is incompatible with
    the averaging code.
7)  As far as I can see, while my hacked version of the old
    radioclkd works with `ntpd -q' (ntpdate-like) for an initial
    time step, the unhacked versions (all of 'em) don't work,
    though this may depend on what version of ntpd itself.
8)  For my needs, if I had to choose the lower jitter figure or
    the higher responsiveness, I'd take the latter.
9)  I don't have to pick one or the other, or choose between
    radioclkd or GENERIC; I can have all of 'em from the same
    clock, even if I'm not strictly adhering to the spec sheets.
    If it seems to work, ship it, is my motto.  Watch my `ntpq -p'.



Anyway, I've spent some days watching my hacked version with the
smoothing code deliver data, in both an RF-noisy environment with
a known-not-so-high-quality clock, and a quieter environment with
a much-better-but-still-cheap clock.  In the latter case, the new
hacked version can deliver data with a jitter figure of a few tens
of usec, followed by the PPS data with typically twice that.  Then
are the GENERIC driver and the old-hacked (per-second updates) SHM
radioclk, somewhat worse than PPS.  At times, the PPS data and the
newly-hacked radioclkd jitter figures will be comparable.  If ntpd
is still in the process of stabilizing (slewing to reduce the offset
as much as possible), the newly-hacked radioclkd data will be much
worse than the others -- obviously, since it's taking data from the
last minute whose offset will not be on a straight line as it tries
to approach 0.

In the case of the noisy RF signal (and poorer clock), the difference
is far more signicant.  The newly-hacked-radioclkd jitter can be
more than twice as low as the PPS data.  Which makes sense, as the
worst data is being discarded.  But this machine hasn't been watched
after stabilizing yet.  Nonetheless, as one would expect, a noisy
signal sees far more benefit from this smoothing than a cleaner
signal, though the latter at my distance from the transmitter does
still see some improvement.

Nonetheless, when fed with the PPS signal, ntpd chooses to latch
onto that as expected.  But given a fairly clean signal, I doubt
one would see terribly significant differences in how ntpd performs
regardless of which of the three non-PPS sources I let it select --
my suspicion is that the difference between the once-per-minute
updates of the averaging radioclkd and the every-second updates of
my hacked older version negate the advantages of the smoothing of
the data, provided one uses a low minpoll and proper burst modes
on the update-every-second sources.  The averaged numbers are nice,
but not so easy to take advantage of, is my gut feeling.

Of course, as I note, I believe that you'd have a winner by adding
the averaging for the last N seconds of data to my hacks to update
the shared memory every second, so that you could continuously send
smoothed but changing data to ntpd.  I'll probably try this sometime.


Anyway, I still don't see any stunning improvement.  Like I say,
I see both some improvement combined with some disadvantages so
there's no clear winner.

(Measuring the actual offset of several machines tracking the same
DCF77 data with the different refclock drivers over time, against
some GPS or comparable higher-precision reference is beyond my
capabilities, but would be interesting to see how the polling
differences *really* affect things.  Sorry.)


barry bouwsma
will hack bugs into good code for beer and/or a paycheck

On Mon, 19 Jul 2004 15:43:10 +0000, Barry Bouwsma wrote:

[SNIP]

> 
> Of course, as I note, I believe that you'd have a winner by adding
> the averaging for the last N seconds of data to my hacks to update
> the shared memory every second, so that you could continuously send
> smoothed but changing data to ntpd.  I'll probably try this sometime.

Dually noted, and when I get around to adding in some improved noise
tolerance features, I will look to add this as well.
 
> Anyway, I still don't see any stunning improvement.  Like I say, I see
> both some improvement combined with some disadvantages so there's no
> clear winner.

Er, the sample you showed seemed to show an order of magnitude improvement
in the jitter i.e. roughly ten times smaller or a shift the decimal place.
By my reckoning that is a fairly stunning improvement.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195

Just for clarification:

> > Anyway, I still don't see any stunning improvement.  Like I say, I see

> Er, the sample you showed seemed to show an order of magnitude improvement
> in the jitter i.e. roughly ten times smaller or a shift the decimal place.
> By my reckoning that is a fairly stunning improvement.

That sample was based on a known jittery source.  I've had some
time to observe a better clock, and will attempt to summarize the
performance of each driver observed over a period of time.

This clock, while still a cheap EUR5 consumer clock, delivers
cleaner signals with less jitter in the same location as the
one I gave the sample from.  However, I've observed it in a much
RF-quieter location, also about 500-odd km away from the DCF77
transmitter.  I can probably see still better performance if I
would close the case to my computer, and especially move the
monitor as far from the clock as possible, perhaps also moving
the clock itself further from the computer.

ntpd itself syncs to the PPS driver fed by this clock, which
may very slightly skew the relative jitter as it tries to
track that.  As I say, I'd need to lock my machine to some
higher-accuracy GPS or something.  The machine is not idle.

After operating for some time to stabilize the offset close to
zero, I'll typically see jitter figures for the latest radioclkd
of 50-100 usec, but sometimes 200 or so.  Occasionally they'll
be as low as 30 usec.

The PPS driver jitter figures will typically be in the range of
75-150 usec.  Again, sometimes higher.

The GENERIC PARSE driver jitter figures will typically be 100-200
usec.

And the old radioclkd jitter (updating SHM every second) ranges
from 150 to 300, on average.  As usual, sometimes it will be a
bit worse too.

So typically the new radioclkd algorithm, with a fairly clean
signal to start with, gives lower jitter figures by a factor of
2 to 4 than the radioclkd without this algorithm.  The factor
of 10 you saw that I pasted seems to be an artifact of the noisier
clock signals.  Sorry I haven't grabbed any data to paste from
the other clock.

And typically the improvement in jitter of the new algorithm
compared with the jitter of my clock as GENERIC is a factor of
1.5 to 3, sometimes less (when the new radioclkd jitter figure
jumps for a while well over 100 usec, which would happen if it
chews on some particularly gnarly data, perhaps due to my hardware).

If I bothered to get a Real Antenna, instead of the 8cm or so
one in that clock, and tune it to match the DCF77 frequency, I
could probably quote better numbers, but this EUR5 off-the-shelf
consumer clock is plenty good for my present needs (to keep my
machine from drifting in time and within some small fraction of
a second of reality, no need for even millisecond accuracy).
Likewise if I were closer to the transmitter.


So, I wish to apologize for my earlier statements.  And I would
like to offer a correction to your earlier claims:

| Now radioclkd easily surpasses the performance of
| the parse driver and approaches the performance of the pps driver.

On my FreeBSD machines, the algorithms in the latest radioclkd
give several times lower jitter figures than the PARSE driver,
and typically are even somewhat better than those of the PPS
driver fed by the same signal.

(I shy away from using `performance' because for me there's
more than just instantaneous values of jitter to consider.)


Now that I see FreeBSD-current has placed TIOCDCDTIMESTAMP
on the choppin' block, I would probably have better success
with the latest code if I were to adapt it to the PPS-API
instead.  Another project...


my apologies,
barry bouwsma
will post misleading data for food

"Barry Bouwsma" <ntp-200203@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> wrote in message
> I've had some
> time to observe a better clock, and will attempt to summarize the
> performance of each driver observed over a period of time.
>
> This clock, while still a cheap EUR5 consumer clock, delivers
> cleaner signals with less jitter in the same location as the
> one I gave the sample from.

Barry,
I checked backed in the thread  and I see this seems to be the first mention of this
"better clock". Can you provide more information? I like the idea of hacking something
from one of those EUR5 consumer clocks...
John

-- 
John and Catherine Allen
Bofferdange, Luxembourg
allen{AT}vo{DOT}lu
http://www.homepages.lu/allen

> > This clock, while still a cheap EUR5 consumer clock, delivers
> > cleaner signals with less jitter in the same location as the
> > one I gave the sample from.

> Barry,
> I checked backed in the thread  and I see this seems to be the first mention of
> this "better clock".

Probably because I've made reference in different (DCF77/radioclkd)
threads to this clock.  It's nothing more than rating all the radio
clocks I've applied a soldering iron to, by the amount of jitter they
are observed to have, often corresponding to the offset needed to be
applied to correct the time to start-of-second.  Some of them are
better than the others, while some are not quite as good as the
others.


> Can you provide more information? I like the idea of hacking something
> from one of those EUR5 consumer clocks...

Usual disclaimer; what follows is not advised!  You will VOID your
WARRANTY!  (not that everyone's going to be concerned with losing
a few Euro for the sake of science)  I take no responsibility for
what happens as a result of following my misguided advice.  If
reading the following makes you queasy or squeamish, you probably
should purchase a module intended for experimentation rather than
dissect a consumer electronics item.  If you value your time too,
it will probably be more cost-effective to purchase said module
rather than read to the end of this message.

Still there?  First, take apart your clock.  The cheaper it is,
the more likely it has just been snapped together.  Else there
may be screws.  Observe the resulting carnage.  You'll see the
antenna ferrite rod, a circuit board, and the display.  The
circuit board will probably have two ICs epoxied to the board;
one of them is the general clock chip, while the other would be
the radio receiver chip, to which the rod antenna is wired.

If you are lucky, there will even be markings on the circuit
board as to where you can find the various desired signal lines.
If you're not quite so lucky, there will probably be several
pads where the signals can be found.  If you're even less lucky,
you'll have to poke the discrete components to find your signals.

A consumer radio clock only makes the receiver active once an
hour or per day in order to correct the time, as well as when
first powered on.  Luckily, some clocks allow you to easily
hold the receiver in powered state; others let you force it
on (though not so easily).

In order to find the desired circuit traces, you'll need a
'scope or suitably sensitive multimeter (the clock pulse
is 100/200msec per second).  Or you can wire up a transistor
and LED to give a visual indication of 0V/1,5V (many such
clocks are powered only by a 1,5V cell; some with fancy
electroluminescent displays use two) if you're halfway good
with electronics -- I find this easier to see the pulse
from the corner of my eye while concentrating my attention
on shorting out traces on the circuit board, rather than
inadvertently shorting out the board while concentrating on
the meter.

Anyway, what you want to do first is to measure the voltage
all around the radio IC on the circuit board after your clock
has received a signal and is displaying the time, to use as
a reference.  You won't see the pulses as the receiver chip
is no longer active, but note all the voltages so you can see
any differences later.

Then remove the battery from the clock, and re-insert it, so
that your clock starts searching for the signal.  Once again,
poke around with your test instrument of choice.  There should
be two differences:  First, one of the lines should display
the pulses of the radio signal, and second, a different line
should have toggled state (switching on the receiver).

I should note at this point that I've seen all possible
polarities in the various consumer clocks I've purchased
over the years.  Most common is a decoded signal line that
goes high for the 100/200msec DCF77 pulse, but a few clocks
have a line that drops low for each pulse.

The line whose state has toggled is -- hopefully -- your
line that switches the receiver on or off.  The easiest case
seems to be when this line is high for receiver off, and drops
to 0V when the receiver is active.  This is usually a low-
current line that you can easily short to ground to cause the
receiver to remain active, even after the clock IC decides it
has a good signal and can power off the radio IC.

If, however, you find a line that gets voltage during radio
reception and then drops to 0V after the time is set, then
you're going to need to supply current to this to keep the
radio receiver powered on.  Unfortunately, some clocks where
this is the case seem to require a fair amount of current to
toggle the receiver back on, resulting in fairly high battery
drain.

I can't make any generalizations about what signals you will
see on a random clock.  If you're lucky, you'll have signals
that are easy to work with.  So far, I have not failed to find
these signals on any of a dozen or so clocks that have met my
scalpel, so you should expect to have a good chance of being
able to use a random off-the-shelf clock.

Anyway, you will need three lines from the clock to some
external interface circuitry -- the signal ground, for which
the battery negative pole usually suffices; the decoded radio
signal from the clock (the trace you found with the pulses);
and the line to switch the receiver on.  For more complex
circuitry, you may want the battery positive pole as well,
if you need to power the receiver chip high, or do silly
things like charge the battery (rechargeables only please!)
from your computer, like I do.

At this point, I can't give concrete advice, but you should
be able to figure out what to do from the general ideas.
The receiver-on line will either need to be grounded, or
provided battery power, depending on what you observed while
probing around while your clock was setting itself.  In the
case of grounding it to activate reception, a simple short
to ground should be enough (this is usually a low-current
line pulled high by a high-value resistor).  You can verify
this is the case by watching the radio signal line after the
clock has set itself and observing it becoming active again
when you manually short the receiver-on line to ground.

Or you can go a bit further, and add a switching transistor
which grounds this line when voltage (from your computer
serial port) is applied to its base, so the receiver isn't
always active unless you're actually needing it to be.

I've never had a problem with the clocks by tying the line
to ground or power through a suitable resistor as needed.
Perhaps I've been lucky.  As you know, your warranty has
long gone far away if you've done any of this.

The actual signal line out of the clock needs to be interfaced
to the serial port, and possibly the signal polarity inverted.
For this, you will need one, or two, or perhaps three transistors
with suitable resistors powered by the serial port power.
Typically a 1M resistor to the clock signal is sensitive enough
and doesn't load the clock, for my case of three transistors.

The use of power from the serial port and transistors alone is
enough for my machines to work.  My serial ports deliver enough
voltage that I've added a LED in series to give a visual indication
of signal to verify that everything is in order.  This LED also
protects in case of the serial port power going negative.

As the transistors are simply switching, the precise values for
the resistors and transistors isn't critical.  I use 1M from the
receiver, 150k to the second transistor, 10k into the third
emitter-follower transistor, and 220 Ohms from this transistor
into the serial port DCD and data lines.  If your hardware is
different, you may need to use a different interface between
your clock and serial port.  There are simple programs out there
that can indicate whether your serial port is receiving a signal,
including in the ntpd parseutil directory.

I won't try to ASCII-art a schematic here, trusting that you
can get something to work if you're able to get the signal from
your clock.  As there are too many possibilities abounding for
me to give specific instructions, a project like this should not
be undertaken by anyone uncomfortable poking around inside of a
clock or unfamiliar with cobbling together a trivial circuit
without a diagram, from a handful of transistors and resistors.

If you need a diagram, then you would be better off buying a
receiver module (not a consumer clock) and using the instructions
on Jonathan Buzzard's page where the source code can be found.
On the other hand, if I can build an interface without any hints
or diagrams, it shouldn't be beyond reach of, oh, 95% of the
world's population, I suspect.

I take power from one of the pins on the serial port for the
external circuit (can't remember which one), and feed the output
of this circuit into both the data pin (for the PARSE GENERIC
driver) and DCD (for the PPS driver and for radioclkd), using
a circuit which delivers a positive signal during the 100/200msec
radio pulse.  Note that this positive signal, while compatible
with PARSE and PPS, requires changes to radioclkd to be used.

I can't give any recommendations as to which clocks are best to
use, as for these handful-of-Euro prices, there's too wide a
variety of generic items out there.  If you're unable to use it
with your computer, it will happily sit on your desk spewing out
the time at you the way it was intended to, before you voided
the warranty on the thing.  Unless you broke it irreparably,
which I haven't done so far.  And if you can use it with your
computer, it will also continue to spew time at you as usual.




Whee, 19 microseconds radioclkd jitter on a machine sitting idle.
Too bad I then had to start using it.

barry bouwsma
will void warranties for a good time

"Barry Bouwsma" <ntp-200203@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> wrote
> > Can you provide more information? I like the idea of hacking something
> > from one of those EUR5 consumer clocks...
>
> Usual disclaimer; what follows is not advised!  You will VOID your
> WARRANTY!  (not that everyone's going to be concerned with losing
> a few Euro for the sake of science)  I take no responsibility for
> what happens as a result of following my misguided advice.  If
> reading the following makes you queasy or squeamish, you probably
> should purchase a module intended for experimentation rather than
> dissect a consumer electronics item.  If you value your time too,
> it will probably be more cost-effective to purchase said module
> rather than read to the end of this message.


Barry,
Very many thanks for this detailed info. I'm tempted, although I'm not really sure if I
can handle the serial interface part. I should at least try....
John


-- 
John and Catherine Allen
Bofferdange, Luxembourg
allen{AT}vo{DOT}lu
http://www.homepages.lu/allen

(rest of your message quoted below)

>
> Still there?  First, take apart your clock.  The cheaper it is,
> the more likely it has just been snapped together.  Else there
> may be screws.  Observe the resulting carnage.  You'll see the
> antenna ferrite rod, a circuit board, and the display.  The
> circuit board will probably have two ICs epoxied to the board;
> one of them is the general clock chip, while the other would be
> the radio receiver chip, to which the rod antenna is wired.
>
> If you are lucky, there will even be markings on the circuit
> board as to where you can find the various desired signal lines.
> If you're not quite so lucky, there will probably be several
> pads where the signals can be found.  If you're even less lucky,
> you'll have to poke the discrete components to find your signals.
>
> A consumer radio clock only makes the receiver active once an
> hour or per day in order to correct the time, as well as when
> first powered on.  Luckily, some clocks allow you to easily
> hold the receiver in powered state; others let you force it
> on (though not so easily).
>
> In order to find the desired circuit traces, you'll need a
> 'scope or suitably sensitive multimeter (the clock pulse
> is 100/200msec per second).  Or you can wire up a transistor
> and LED to give a visual indication of 0V/1,5V (many such
> clocks are powered only by a 1,5V cell; some with fancy
> electroluminescent displays use two) if you're halfway good
> with electronics -- I find this easier to see the pulse
> from the corner of my eye while concentrating my attention
> on shorting out traces on the circuit board, rather than
> inadvertently shorting out the board while concentrating on
> the meter.
>
> Anyway, what you want to do first is to measure the voltage
> all around the radio IC on the circuit board after your clock
> has received a signal and is displaying the time, to use as
> a reference.  You won't see the pulses as the receiver chip
> is no longer active, but note all the voltages so you can see
> any differences later.
>
> Then remove the battery from the clock, and re-insert it, so
> that your clock starts searching for the signal.  Once again,
> poke around with your test instrument of choice.  There should
> be two differences:  First, one of the lines should display
> the pulses of the radio signal, and second, a different line
> should have toggled state (switching on the receiver).
>
> I should note at this point that I've seen all possible
> polarities in the various consumer clocks I've purchased
> over the years.  Most common is a decoded signal line that
> goes high for the 100/200msec DCF77 pulse, but a few clocks
> have a line that drops low for each pulse.
>
> The line whose state has toggled is -- hopefully -- your
> line that switches the receiver on or off.  The easiest case
> seems to be when this line is high for receiver off, and drops
> to 0V when the receiver is active.  This is usually a low-
> current line that you can easily short to ground to cause the
> receiver to remain active, even after the clock IC decides it
> has a good signal and can power off the radio IC.
>
> If, however, you find a line that gets voltage during radio
> reception and then drops to 0V after the time is set, then
> you're going to need to supply current to this to keep the
> radio receiver powered on.  Unfortunately, some clocks where
> this is the case seem to require a fair amount of current to
> toggle the receiver back on, resulting in fairly high battery
> drain.
>
> I can't make any generalizations about what signals you will
> see on a random clock.  If you're lucky, you'll have signals
> that are easy to work with.  So far, I have not failed to find
> these signals on any of a dozen or so clocks that have met my
> scalpel, so you should expect to have a good chance of being
> able to use a random off-the-shelf clock.
>
> Anyway, you will need three lines from the clock to some
> external interface circuitry -- the signal ground, for which
> the battery negative pole usually suffices; the decoded radio
> signal from the clock (the trace you found with the pulses);
> and the line to switch the receiver on.  For more complex
> circuitry, you may want the battery positive pole as well,
> if you need to power the receiver chip high, or do silly
> things like charge the battery (rechargeables only please!)
> from your computer, like I do.
>
> At this point, I can't give concrete advice, but you should
> be able to figure out what to do from the general ideas.
> The receiver-on line will either need to be grounded, or
> provided battery power, depending on what you observed while
> probing around while your clock was setting itself.  In the
> case of grounding it to activate reception, a simple short
> to ground should be enough (this is usually a low-current
> line pulled high by a high-value resistor).  You can verify
> this is the case by watching the radio signal line after the
> clock has set itself and observing it becoming active again
> when you manually short the receiver-on line to ground.
>
> Or you can go a bit further, and add a switching transistor
> which grounds this line when voltage (from your computer
> serial port) is applied to its base, so the receiver isn't
> always active unless you're actually needing it to be.
>
> I've never had a problem with the clocks by tying the line
> to ground or power through a suitable resistor as needed.
> Perhaps I've been lucky.  As you know, your warranty has
> long gone far away if you've done any of this.
>
> The actual signal line out of the clock needs to be interfaced
> to the serial port, and possibly the signal polarity inverted.
> For this, you will need one, or two, or perhaps three transistors
> with suitable resistors powered by the serial port power.
> Typically a 1M resistor to the clock signal is sensitive enough
> and doesn't load the clock, for my case of three transistors.
>
> The use of power from the serial port and transistors alone is
> enough for my machines to work.  My serial ports deliver enough
> voltage that I've added a LED in series to give a visual indication
> of signal to verify that everything is in order.  This LED also
> protects in case of the serial port power going negative.
>
> As the transistors are simply switching, the precise values for
> the resistors and transistors isn't critical.  I use 1M from the
> receiver, 150k to the second transistor, 10k into the third
> emitter-follower transistor, and 220 Ohms from this transistor
> into the serial port DCD and data lines.  If your hardware is
> different, you may need to use a different interface between
> your clock and serial port.  There are simple programs out there
> that can indicate whether your serial port is receiving a signal,
> including in the ntpd parseutil directory.
>
> I won't try to ASCII-art a schematic here, trusting that you
> can get something to work if you're able to get the signal from
> your clock.  As there are too many possibilities abounding for
> me to give specific instructions, a project like this should not
> be undertaken by anyone uncomfortable poking around inside of a
> clock or unfamiliar with cobbling together a trivial circuit
> without a diagram, from a handful of transistors and resistors.
>
> If you need a diagram, then you would be better off buying a
> receiver module (not a consumer clock) and using the instructions
> on Jonathan Buzzard's page where the source code can be found.
> On the other hand, if I can build an interface without any hints
> or diagrams, it shouldn't be beyond reach of, oh, 95% of the
> world's population, I suspect.
>
> I take power from one of the pins on the serial port for the
> external circuit (can't remember which one), and feed the output
> of this circuit into both the data pin (for the PARSE GENERIC
> driver) and DCD (for the PPS driver and for radioclkd), using
> a circuit which delivers a positive signal during the 100/200msec
> radio pulse.  Note that this positive signal, while compatible
> with PARSE and PPS, requires changes to radioclkd to be used.
>
> I can't give any recommendations as to which clocks are best to
> use, as for these handful-of-Euro prices, there's too wide a
> variety of generic items out there.  If you're unable to use it
> with your computer, it will happily sit on your desk spewing out
> the time at you the way it was intended to, before you voided
> the warranty on the thing.  Unless you broke it irreparably,
> which I haven't done so far.  And if you can use it with your
> computer, it will also continue to spew time at you as usual.
>

> > Usual disclaimer; what follows is not advised!  You will VOID your
> > WARRANTY!

> Very many thanks for this detailed info.
> I'm tempted, although I'm not really sure if I
> can handle the serial interface part. I should at least try....

It's not that bad.  Anyway, you and a handful of dark beers have
convinced me to try my hand at ASCII art using `cat' so try this
out for size (drawn from memory).  This is meant to take a typical
0->1,5V signal and level-shift it to roughly 0->the-level-supplied-
by-your-serial-port (+12V in my case except for the one serial port
which seemed to self-immolate a few days ago and now only delivers
5V which isn't enough for this circuit).

As I note, the values for the resistors aren't at all critical.
Nor are the transistors.  I had a bag of something like 100 for a
couple Euro (or CHF) with typical gains of 200-ish, allowing a
margin of error of several times the value I give for the resistors.
Simple generic switching NPN transistors are fine.  I confess that
after 20-some years not doing anything electronic, I've forgotten
how to draw a proper transistor...  A variable-width font will put
this all in proper perspective anyway.


                                                      LED
                      _________________________________|/|___  +V
                      |             |              |   |\|
                      |             < 10k-ish      |               to serial
                      < 100k-ish    >             /                  port
 to radio             >             |___________|/
 clock                |             |           |\    220-ish Ohm
                      |            /              \___/\/\/\__> data/DCD
                      |__________|/
                      |          |\
  decoded   1M-ish   /             \
 clock <___/\/\/\__|/               |
  signal           |\               |
                     \              |
 GND _________________|_____________|_______________________________  GND



I can't remember if radioclkd powers up the particular serial port
line from which I take power, or if I've set ntpd's GENERIC driver
to do that -- I suspect the latter as that came first.  My config
file line for that looks like
server 127.127.8.0 mode 144 minpoll 4 maxpoll 8 burst iburst
but I would have to consult the docs to be able to say what supplies
power to the port -- I suspect `mode' (set and forget, it is, and
I've long since forgotten).



As noted, this circuit works with my ancient machines.  It's possible
that for a more modern machine, you'll need to tweak values or lose
the LED or come up with a completely different design.  And the
polarity tracks that of the input signal, which you may or may not
want.

Do check Jonathan Buzzard's page for a different circuit and possibly
other details on interfacing to your serial port, although that is
written specifically for one particular module that is different
from most consumer clocks.

As usual, I can't guarantee that the above circuit matches what I'm
using in the last five or so clocks I interfaced to a serial port
as I'm going from memory, so if you explode an electrolytic cap
don't blame me.



> (rest of your message quoted below)

Aieee, no need to do that.  Nobody needs to suffer through that
a second time...


barry bouwsma
(snip)