### Pure TTL Clock

The second half of my circuits and systems lab class this quarter has been an introduction to digital logic.  Unfortunately, over winter break my dad gave me the TTL Cookbook by Lancaster, which I then read a few times, so I've been spending the last four weeks of lecture catching up on my pleasure reading.  The lab projects for the class have been pretty rudimentary (compared to my other projects), so I've had quite a bit of free time in lab to help other groups and work on my own projects.

Flipping through the TTL Cookbook a few weeks ago, I found a schematic for a crystal oscillator (page 170), and it hit me: Once you get a crystal to oscillate, it isn't much more to get it to count time, WITHOUT using a microcontroller!  All of my clocks so far have essentially been a real time clock chip (eg DS1307) connected to a controller (eg ATMega168) which is then connected to a bunch of LEDs of some creative configuration to show time [1] [2] [3] [4].  You do that enough times, and it stops being all that challenging, and easy hobbies are boring hobbies, right?

So what's the challenge?  `7400` series digital logic consists of a couple hundred different integrated circuit chips, starting from `7400` and counting up (highest I've seen in real life is `74595`).  Each chip does a single logical operation, so one may output the logical AND of two inputs (output HIGH if both inputs are HIGH), where another is 4 flip flops chained together to make a divide by 16 counter.  Before the era of the PC, it wasn't uncommon for a hobbyist to buy a bag full of TTL gates and build himself a nice little computer.  Unfortunately, when each individual IC only does one thing, doing anything useful generally takes quite a few ICs, and you'll need a pretty good collection of them before trying to do anything doesn't consist of buying every single part you need (25-70 cents a piece isn't much, but does add up).  Comparing this project to your typical 8 pin RTC chip, I'd say this implements 5% of the functionality (no calendar functionality, no I2C, etc) at the cost of a few orders of magnitude more board space (6 columns vs half an inch), and a few orders of magnitude in power requirements (600mA vs less than 1.5mA).

Reading this clock is relatively easy, compared to most of my other clocks.  It's in 24 hour time, and seconds, minutes, and the 1's of hours are all decoded nicely by 7 segment displays.  Unfortunately, I ran out of breadboard space, so the 10's of hours had to settle for a pair of LEDs: One LED is lit for 10 + n hours past midnight, and both LEDs are lit for 20 + n hours past midnight (The schematic below shows the little bit of cleverness that I did with a pair of diodes to make that happen).  This means the picture above reads 16:36:39 (4:36PM).

Power consumption for the entire clock is relatively high, which is expected for this many TTL gates.  At 5V, it draws somewhere between 550mA and 650mA, depending on how many LED segments are lit, so plan on running it with a pretty stiff power supply.

Click any of the pictures to enlarge.
Video:

Notes:
• I did a surprising good job in the video of rattling off part numbers, with the one exception of the 1's digit of the minutes.  The counter is not a `7493` or the `74120` which I corrected myself with, but is actually the `74160` divide-by-10 counter, which is the same as for the second's 1's place.
• With the button debouncers, the RC response times were calculated for use with `555`s, but when I switched to a `74123` I just used the same values without recalculating it.  I think it's quite a bit faster than a quarter second now.
• I live next to the railroad tracks; I'm sorry.

Working from right to left in the pictures:
On the top right is a 32.768kHz quartz crystal.  This is a convenient frequency because it is a power of 2 (215, for those of you reading at home).  This means that if you divide the output of this crystal by two 15 times, you get down to a relatively stable 1Hz signal (The crystal is spec'd for 20ppm, and the measured drift on it is at least on that order of magnitude).  The amplification of the crystal is done by a `4001` CMOS NOR gate (Not technically TTL, I'm sorry!), which then feeds a chain of three `74161` divide-by-16 gates, and half of a `7493`, which divides it by another eight.

Once divided down to 1Hz, the rest of the clock is simply a matter of counting seconds, minutes, and hours, and displaying them.  The seconds stage consists of nothing more than a `74160` divide-by-10 and a `7493` wired as a divide-by-6, which feed a pair of `7447` BCD to seven segment decoders for display.  The `7493` normally divides by 16, but I used a `7408` AND gate between the 2 and 4 output lines, such that when the counter (which signifies the tens of seconds digit) reaches six, the AND gate goes high, resets the counter, and pulses the carry line to the minutes stage.

The minutes stage is just like the seconds stage, with the singular complication that most clock users have this almost indecent expectation that they can plug in a clock all willy-nilly any time of day, and then expect to have some ability to change the time on the clock to the current time.  What nerve, right? That means we have to like, have buttons and stuff...

Unfortunately, TTL counters and buttons don't mix very well.  You don't realize it, but when you push a button, it will sit there and bounce a couple times before it settles down and looks like a single voltage to the counter.  This is a problem, because instead of advancing the clock one minute every time you press the minute button, it can advance two, eight, twenty, or even forty times.  This is a real drag, and needs to be fixed.  To fix this, I used a `74123` dual monostable multivibrator.  Monostable multivibrators are useful because you can kick it once (or a whole bunch of times, in this case), and it will output a single, clean, square pulse for a defined amount of time (defined by the resistors and capacitors connected to it).  This means it can debounce the messy button presses, and turn them into clean square waves to advance the minutes and hour counters.  The `74123` output is combined with the carry signal from the seconds stage by a `7432` OR gate.  I originally had the debouncing implemented by a pair of `555`s, which probably made more sense than the `74123`, but I had never used a `74123` before, so I decided to have some fun (pretty sick idea of fun, right?).

The hours stage is unfortunately an entirely different bucket of fish.  Not only do we have to use the other half of the `74123` and another `7432` OR gate to let the user advance the hours, and have the first counter carry and reset at 10, but we want both `7493` counters to reset when the clock reaches the end of the day (at 24 hours).  This means another AND gate connected to the 20 and 4 lines, fed to the reset on the 10's counter, and combined with the 1's reset signal through another OR gate.  Pile on top of all of this the fact that I was quickly running out of breadboard space, and you can see my problem.

So there it is.  An entire clock, built from little more than AND & OR gates, flip-flops, and BCD to seven segment decoders.  It was a fun little project, but now that I've proven that I can do it, I think I'm going to go back to my nice little DS1307 RTCs and AVR microcontrollers, thank you very much.