Let’s take a then-and-now look at how generations of S-COM controllers kept time.
The term for what we’re talking about is Real-Time Clock, or RTC. It refers to timekeeping in human terms (time and date) rather than the cyclical clock signal used to synchronize logic. RTC can be implemented in software or with an integrated circuit that tracks time and date independently of microprocessor intervention.
Software Clocks
S-COM’s first wirewrapped controller was built in 1980 and used an MC6802 processor. It featured a software RTC that sent the hour and minute in CW upon command.
A connection was made to the low-voltage secondary of the power supply transformer, which brought 60 Hz sine waves of accurate frequency (courtesy of the power company) to the board. The sine waves were squared by a 555 timer IC, and the resulting pulses were counted in a software routine. The pulses were used as “ticks” of the clock and occurred every 16.667 ms. When 60 ticks were counted, the seconds were incremented; additional counting handled the minutes and hours. It worked as long as power was maintained.
The controllers that followed – the Big Board, the MRC-100, and version 1 of the 5K and 6K – also had simple software clock/calendars. But they were powered by 12 V DC from the site supply and thus didn’t have access to the 60 Hz power line frequency. Instead, hardware counters generated 10 ms ticks by dividing down the 1 MHz system clock. Once the clock was set, the time and/or date could be sent in CW upon DTMF command or event-triggered macro.
The time included only the hour and minute. Since the seconds weren’t sent, a timekeeping error of less than 1 minute wasn’t noticeable. When the error reached one minute over a known number of days, the owner entered a correction command to automatically add or subtract a programmable number of seconds each day at midnight. Once this correction was made, the clock was reasonably accurate because it then took a much longer time to accumulate a one-minute error.
A power failure would stop the processor and thus freeze the time and date in a software RTC. The data was available because it was stored in battery-backed RAM, but when power returned, the data was useless as there was no way to know how long the clock had been stopped. We didn’t want the clock to simply pick up where it left off, so a step was added to the power-up sequence invalidating the time and date. (The assumption was that no clock was better than an erroneous clock.) We didn’t offer a scheduler because power interruptions would move the execution times of the setpoints, creating confusion.
The upshot was that if you heard “not set” instead of the time, it was up to someone to enter the command to fix it.
We hoped the weakness could be forgiven given that sending the date and time was the sole purpose of the clock.
7K RTC
The 7K, designed in 1989, was our biggest model to date. We implemented an RTC IC (Intersil ICM7170) to avoid the shortcomings of the previous software clock and get an accurate talking clock and scheduler. The circuit included a crystal, a trimmer capacitor for tweaking the oscillator frequency, and a 3 V lithium coin cell for backup power. (The backup battery connections for the RAM and the RTC didn’t share a common reference, so separate coin cells were used. That’s why you’ll find two cells on a version 1 7K.)
When applying an RTC IC, you learn some things about crystals.
A 32.768 kHz tuning fork (“watch”) crystal is commonly used. It’s made in large quantities and is relatively cheap. An oscillator running at such a low frequency draws little battery current. And the frequency, a power of 2 (215), yields 1 pulse per second when divided by a simple 15-stage binary counter.
Clock accuracy is controlled by various crystal parameters.
There’s calibration tolerance, perhaps 20 ppm (53 seconds/month). The trimmer cap can be used to adjust it out.
Aging adds about 3 ppm of error initially, then improves over time.
The big problem is temperature. The frequency falls parabolically either side of 25°C (room temperature) at about 0.04 ppm/°C2. It’s degrees Celsius squared, so while a ±1°C change equates to an error of 0.04 ppm or 1.26 seconds/year, a ±10°C change is 100 times worse: 4 ppm or 126 seconds/year. For accurate timekeeping, the crystal needs to be kept at a constant temperature, such as on your wrist – not something every repeater site offers.
The crystal must see the correct capacitive load. High capacitance means the oscillator runs slow and vice versa. The PCB layout must minimize stray capacitance.
The crystal inputs of RTC ICs are very high impedance. It’s easy to couple noise into them from nearby components and fast signal traces, resulting in rapid time gain. Again, proper PCB layout is critical.
We were careful to follow the design rules, and got trustworthy time and date data in return.
The IC had built-in automatic leap year correction. To that we added such features as message run-time variables, a 100-setpoint scheduler, and daylight savings time adjustment.
7Ks fitted with Speech Synthesis Modules showed up on many systems, announcing the time on the hour or with identifications, time-stamping autopatch calls, and calling nets to order.
Timekeeping Modules
When nonvolatile timekeeping RAM modules became available from Dallas Semiconductor, we added them to the 5K (DS1643) and 6K (DS1644) as part of a version 2 upgrade. The modules were very handy because they contained a nonvolatile RAM, RTC IC, crystal, power fail control, and lithium coin cell, and plugged into the existing RAM socket with just a few board modifications (the old RAM controller IC had to be removed and some socket pins jumpered to bring power and chip enable lines to the Dallas part). To maintain software compatibility throughout the product line, we swapped the 7K’s original RTC with a DS1644.
The modules were guaranteed to keep time to within ±1 minute per month at 25°C and run for at least 10 years. Because the crystal wasn’t temperature compensated, the accuracy wandered a bit more than keen clock-watchers wanted.
Still, for 5K and 6K owners it was a big leap over the original software clock. The controllers gained a scheduler, run time variables, daylight savings time adjustment, and day-of-week programming (for the scheduler). This allowed announcements to be triggered on the first Thursday of each month at 7:00 PM, for example.
And we were confidently able to report that the clock was immune from the highly anticipated Y2K (Year 2000) bug issue.
TCXO
Customers eventually wanted more accurate timekeeping than the DS modules provided, so we made a big improvement in the 7330.
Its system controller IC, a DS1670, provides nonvolatile RAM control, processor monitoring, an A/D converter, and a RTC. It has inputs for a 32.768 kHz crystal, but for the reasons previously mentioned, we didn’t use a crystal. Instead, we drove it with a DS32KHZ TCXO (Temperature Compensated Crystal Oscillator) IC.
The 32.768 kHz crystal and its oscillator are on the IC. The output signal is buffered, and the low output impedance minimizes noise pickup by the RTC’s crystal input pins. Additional isolation is provided by the internal power and ground planes of the 7330 main board.
While powered, the TCXO measures the temperature every 64 seconds and adjusts the load on the crystal to compensate the frequency. It’s accurate to ±1 minute per year over the temperature range of 0°C to +40°C. Years of production have shown that the part works as advertised.
Other Methods
In the past, a club that owned multiple repeaters with 7Ks used a central transmitter to automatically send daily time updates in DTMF to keep the clocks accurate on all controllers. The same thing could be done today with RoIP technology.
In the future, Ethernet-equipped controllers may get updates from a network time server and GPS-equipped controllers may get their updates from the GPS satellite system. But standalone controllers will likely use TCXOs for some time to come.