🚀 go-pugleaf

In article <5502@videovax.tv.Tek.com> bill@videovax.tv.tek.com (William K. McFadden) writes:
>In article <8720@kean.mun.ca> andrew@kean.mun.ca writes:
>>I can't really speak for anyone else on the net, but one of the things that I 
>>really hate is clocks that are "just a little bit off".  

Indeed.  The clock in my car stops running (but remembers the time)
whenever I crank the engine...

>I have built one of these clocks, so I guess that makes me as qualified as the
>next person to talk about it.

I built one about four years ago, too.

>The clock's timebase is a 3.6 MHz 10 ppm crystal oscillator.  It compares the
>drift of this oscillator to the WWV tones and continually trims it with an
>DAC-driven varactor (8 bits).  This makes the oscillator (whose output is
>available on the back panel) very accurate over the long term.  The short term
>accuracy is less, but the documentation does not say how much so.

But obviously the oscillator isn't going to get any more accurate after
the eighth time the clock sets itself.  That can happen within an hour
if you have a good signal.

>The bottom of the clock has dip switches that allow you to select 12/24 hour
>mode, GMT only, timezone selection, channel lockout, propagation time
>compensation (to compensate for the time it takes the signal to reach you),
>UT1 (astronmical time) correction, and automatic daylight savings time
>correction.

I have yet to see any such clock that does the DST correction properly,
i.e.  applies it at 2AM local time.  All of the clocks I have seen
simply apply the bit in the time code when they see it.  At WWV, this
bit is a toggle switch that the operator flips as close to 0000Z on the
prescribed day as is possible.  Sometimes they forget.

>I have only a few complaints about the clock.  First on the list would
>have to be the RS-232 interface, which seems to be more of an
>afterthought than an original design consideration.  For example, the
>time is always 1 second off (they explain this in the manual, but don't
>tell why).

I've found that this one-second delay can be eliminated temporarily by
the proper application of a finger across some CPU pins.  The delay is
missing in my clock due to CPU replacement (see below).

>Also, it is correct only at the beginning of the first character
>transmitted.  Hence, you have to compensate for transmission time,
>which is dependent on baud rate.

It has to be correct somewhere.  The best spot would be a marker after
sending the time, but as it is, you could read your local clock at the
start, collect the data which tells you what time the mark was, reread
your clock for the delta from the mark, add the difference, and reset
your clock.  This assumes that the read-add-reset sequence for your
local clock takes negligible time.

>In addition, the output levels are 0 volts and 5 volts.  Some systems
>(such as our VAX) complain about these levels because they are not valid
>RS-232.

Indeed RS-232 standards are not met, but those aren't the actual output
levels.  Ground (pin 7) is at 5 volts, so that they can swing a 12V TxD
line and it will go negative (relatively) more than 3 volts, so it is
sort of within the realm of RS-232 operability.

>The second problem is a couple of times it has set itself to the wrong
>time.  Apparently the same bit was wrong three times in a row, and the
>other data bits were correct.  Thus, the clock assumed it was receiving
>correct time code.  This has happened rarely and only at powerup,
>however, and the clock has always recovered in a few hours or less. 
>Once it knows the correct time, it stays there.

This is now a known problem, not limited to power-up.  My clock did
that a couple of times, and after some correspondence with Heathkit they
sent me a replacement CPU (with a piggy-back 2716), and the problem has
not recurred.  At the same time, the 1-second delay in the ASCII time
disappeared with this CPU.

>The third problem is there is no way to set the time manually.  I can
>understand this because it would be difficult to do, and there is a DC
>power input that automatically switches in when the AC fails.  However,
>if power is interrupted you can expect it to take anywhere from 5
>minutes to a day to reset itself, depending on signal reception
>conditions.  (The display will be blanked until the clock sets itself.)

There is a way to set the time manually.  Inside the clock there is a
test switch which was used to calibrate the 1000/1200 Hz decoder.  Push
the switch a few more times and you get to read/advance the day of
year, hour, minute, and perhaps second (it's been a while, I don't
remember).  I do not trust my clock after this exercise until the time
agrees with the audio once again, because I think the HI SPEC LED
remains lit if you do this.  Check it out.

>The last problem concerns quality control.  The radio receiver board
>comes pre-assembled and tested.  Unfortunately, two connections were not
>soldered on the board.  This caused it to stop working about a year
>after I built it.  It has worked fine since I soldered these two points,
>however.

After four years of owning this clock, I finally got it to listen to
15MHz yesterday.  It had NEVER set on this freq before, and turning the
volume up after forcing the clock to listen to 15 MHz yielded silence.
So I poked at the receiver board with a scope, and lo and behold that
particular band started working.  Perhaps I reseated a loose crystal or
something.  Subsequently I haven't seen the clock set on anything but
15 MHz, it likes that so much.  We'll see if the shock of an upcoming
move upsets it.

I do have a wish list for clocks of this ilk, including the ability to
ask it things.  There are numerous other design problems with the
Heathkit clock along the lines of the year DIP switches (such as not
knowing for which time-zone the clock is reporting times without
looking at the bottom of the clock--the computer cannot find out).
PSTI (Precision Standard Time Interfaces? (now defunct, I hear))
was a little better in this regard, but still not perfect.
-- 
-- 
Qualify nearly everything.

Jeff Woolsey	woolsey@nsc.NSC.COM	+1 408 721-8162