One of my most precious possessions is a Heathkit GC-1107 clock I assembled as a kid. But it has some shortcomings: it loses the time and alarm setting if the power is interrupted, and adjusting it for Daylight Saving Time is a pain. So I decided to retrofit it with a GPS receiver to get the correct time.

Heathkit sold clocks that received the time from WWV, but I couldn’t afford them. So if the power goes out, I lose the time. If the alarm was set to anything other than midnight, I lose that too. In the spring, when Daylight Saving Time starts, I need to adjust the clock using the fast-forward and slow-forward buttons. In the fall, I need to use the same two buttons to advance the clock 23 hours. If I overshoot the correct time, I need to fast-forward 24 hours and hope not to overshoot again. And the clock is never accurate to the second; it can be as much as 59 seconds off.

I wanted to fix these problems while keeping the vintage electronics in the clock. The clock is little more than a power supply, a display, and a single clock chip, a National Semiconductor MM5316. I figured I would need to add a microcontroller, have it read the currently displayed time by sensing which segments of the display were lit, and have it set the time by twiddling the FAST and SLOW lines on the MM5316.

The first tricky part is that the clock operates at anywhere from 8V to 22V, depending on how bright the display is (the brightness is adjusted by a photoresistor that senses the room’s ambient light). Modern microcontrollers can’t sink or source those voltages. The solution was to use two analog multiplexers that are capable of handling 22V. My microcontroller, a PIC32, sets the address lines on the analog MUXes to select one high voltage input after another. The high voltage output of the MUXes goes through a voltage divider which reduces the 8-22V range to 1.8-5V. That goes into a 5V-tolerant pin on the PIC32.

To send signals to the MM5316, the PIC32’s outputs control analog switches, which can feed 22V into the MM5316’s FAST, SLOW, and DISPLAY ALARM/TIME inputs.

The second tricky part is that this is essentially a multiprocessor configuration, but with no synchronization mechanism. For example, the PIC32 is reading the displayed time, one segment at a time, while the MM5316 can be changing it. And the PIC32 is setting the time while the user can be pushing the FAST and SLOW buttons as well.

My solution was to take the MM5316 out of its socket (thank you, Heathkit, for having all your ICs socketed) and put it on the same board with my μC. Most signals from the socket still go directly to the MM5316, but the FAST, SLOW, and DISPLAY ALARM/TIME buttons don’t. Those signals go to the analog MUX, and the PIC32 decides whether to relay them onto the MM5316, so the user can’t change settings without the PIC32’s permission. As for reading the displayed time, the PIC32 just needs to scan the segments over and over until it detects the same time twice in a row.

Finally, I was worried about heat. I needed to convert 22V into 3.3V. A linear regulator would produce a lot of heat, and the enclosure is small with almost no ventilation. Some folks in eevblog’s forums tipped me off to compact, inexpensive switching regulators from Recom.

The attached diagrams show how the clock was wired before and after my changes.

When the clock is turned on, the PIC32 checks its flash memory to see what time the alarm was last set to. It asserts the DISPLAY ALARM line, then asserts the FAST and SLOW buttons to set the alarm. Because of the way the PIC32 reads the displayed time – by scanning all the segments one by one – it can’t reliably set the time using only the FAST button; the time is changing too fast and the PIC32 doesn’t see every minute. So it uses FAST until it’s within 10 minutes of the target time, then switches to SLOW.

Once the alarm is set, the PIC32 asserts DISPLAY TIME. It waits for the GPS to start reporting the time, which usually takes a...