Clock project debrief

And this is really it, after a bit of a break!

I hope this has been an interesting journey to follow along, and with this post I want to give a "debrief" on the project - what worked and went well, what didn't work or didn't go so well, things like that.

Concept

The concept was certainly interesting - build a clock (not too interesting in and of itself), but build it out of a single type of logic, and build it using discrete components. It seemed like a big task when I initially set out to do it, and I guess my hunch was right. I just didn't realise how big it would end up being.

The goal was first and foremost a working clock. A secondary goal was to create something of interest, or certainly something attention grabbing. I think it will be - in the right company anyway. Some people will probably think I was just crazy. So far, those who have seen it in person are suitably impressed.

Functionality wise it has everything that I need and want. I guess thats the advantage of designing and building something yourself. But there were also technical constraints to consider, like the number of transistors I could fit per board which would also limit the amount of functionality I could have. In the end I'm quite pleased that I managed to fit everything I wanted in, and managed to keep each functional block contained on a single board.

Design

It might just be a case of Stockholm syndrome, but I've quite enjoyed the simplicity of building everything using NOR logic. In a way it is kind of strange to imagine building anything any other way now. Being a universal gate, you can form any kind of logic you need with the right combination of NOR gates. But certainly, for a large scale project, utilising all of the available types of logic would probably result in a more compact design. For example, a two input AND gate implemented with NOR requires 3 gates - 2 to invert the inputs, and 1 for the output - at a minimum that is 2 transistors per input to the "AND" gate. An AND gate implemented directly only requires 1 transistor per input. But the goal of this project was to only use NOR, so that is beside the point.

In the very early stages of the project I had some ideas about how I would make this all fit together, and I think some of those ideas very rightly were replaced with others. One such iteration involved running a lot of wires between the boards as I hadn't yet figured out how I would use headers and sockets to link all of the boards together. Luckily I would find the right parts to allow me to avoid having to use that "wired" method, and I feel better off for it - taking it apart is certainly MUCH easier, and the clock is nice and tidy and well contained as a result.

CAD tools

Logicly, as I discovered early on in the process, did prove to be a very valuable tool. It helped me to prototype logic very quickly to develop and debunk ideas, and to hone in specific design details. It wasn't free in the end as I ran out of the free trial period, but it was worth it. It does have a few performance issues when you scroll out far enough, but if you want to play around with logic for learning purposes it't certainly a good tool to have. If you just need an ability to test something and don't need to keep it afterwards, the trial web interface certainly does a good job. I'll continue to use it to test out ideas in the future.

EAGLE is a PCB CAD tool that I have been using for some years now. It can be had for free with some limitations around useable board area, but schematics can still hold a significant amount of circuitry (limited to two sheets in the free version). For my needs, EAGLE worked just fine, although if I weren't stuck with the free version right now I might have been able to release a single schematic file instead of one per board. I'm in two minds about how to handle the new subscription model now that Autodesk has taken it over. On one hand it looks nice and flexible - pay for what you need for as long as you need it - on the other hand I kind of feel I would just prefer to pay once and get it over and done with...

Physical tools

The tools you have to work with make an untold contribution to your productivity and ability to actually do what it is you are trying to do. I am certainly over the "buy cheap tools just to get the job done" phase of my life, and I am starting to "invest" in better quality tools, and more specialised tools for particular jobs. One tool I want to call out specifically which helped to no end was a wire stripping tool:

http://uk.rs-online.com/web/p/cable-strippers/8640776/

Now, this wasnt an expensive tool at all (counter to the theme), but along side a two pairs of Knipex side cutters (one with the lead catcher and one without) and a soldering iron, this tool completed the essential trio. It is adjustable, and once dialled in just right, stripping the Kynar insulation of the wire I used was so much easier. Without this tool I'd have been doomed to using something like a knife, or my side cutters to try and strip the insulation, and I don't want to think how much extra effort this would have created. Perhaps rather ironically, this particular tool worked a lot better than the original wire stripping tool I used which was almost 3 times the price...

Acquiring an oscilloscope is also worthy of a mention. Without it, I would have had a very hard time seeing just what was going on with some signals, and and even harder time figuring out how to go about correcting some things. In the tradition of buying quality tools, I ended up buying a Keysight MSOX2024A. It was plenty more expensive than a Rigol for example, especially for a first-time scope owner, but I am loving every minute working with this thing. I bought it from Keysight's "premium used" store via ebay, and that ended up costing me about 50% retail of a new unit. In fact, it was even cheaper than a brand new 70MHz unit that I was originally looking at. It even came with 5 years of Keysight warranty, so I think in-all thats a big win.

During the project my original soldering iron died - to quote Photonicinduction: it popped (quite literally). To replace that I, once again, "splashed out" and bought a Hakko FX-888D. The difference using this iron over my previous one is incredible. The iron itself is so light that you barely even notice that you're using it, and came with a really nice holder that has a wet sponge and a brass sponge, although these days I tend to only use a brass sponge which does a much better job I think. Also much more conveniently, the transformer unit can sit closer to the iron itself, so I gained some freedom of movement with the iron through a bit of additional cable length. As a bonus, it is also an ESD safe iron, as were a lot of the tools that I ended up acquiring over the course of this project. Probably not a bad thing given I was working with MOSFETs.

And if I can make one more recommendation without sounding like an advert: MG Chemicals Desoldering Braid. Don't think about it, just buy it! (have some IPA wipes ready to clean up afterwards)

Construction

I don't believe that I will undertake another project in this way again - that's not to say I won't do another project, but I won't build it quite this discrete - next time I will likely use pre-packaged logic, and/or a microcontroller.

Using discrete componentry in this way is a huge task, especially when all of the wiring between logic elements is taken in to account. There's a lot of it, and its VERY fiddly, and although I did find a method to help make this part of the process a little easier (I would strip a length of insulation off the end of my jumper wire, solder it to the first pin in the circuit, and then strip subsequent appropriate lengths of insulation towards the previous solder joint before making the next solder joint and so on - I hope that makes sense...), and over time I got better and better at doing it, it was still a very tedious piece of work and I did make mistakes along the way.

I suppose a project like this might be easier and perhaps achieveable by more people if you could purchase circuit boards with all of the circuitry taken care of, and just needing you to solder everything in to place. You still get a clock made entirely of transistors, but you could probably manage to keep a couple of months of your life for something else.

The physical construction of the NOR gates worked extremely well. Little did I know when I started that it would be so perfectly suited. Certainly, building other types of gates would be much more difficult if not impossible due to the way they need to be wired together. The NOR gate layout was very well suited to this as the source pin of the transistors could be connected to a common ground rail, and the drain pin commoned via a resistor to the positive voltage rail allowing them to all maintain the same orientation on the board, and avoiding any complicated or tricky wiring.

If I do decide to build some discrete logic in this way again, I do think that NOR would probably be my go-to logic gate for such a task - it's really easy and convenient to build!

Conclusion

I'm glad its over, and now I can move on to something else. Maybe a break doing nothing will actually be a good thing.

There is still one board to build to dim the display, but I'll work on that some other time and post here when it's done.

Other than this, a Bill of Materials and a run down of costs might also be worth while, so here goes: https://docs.google.com/spreadsheets/d/1-uWIQYHm8d-aZ7Yp9LqevuUCRR0vtjQFpsaY1evqYjc/edit#gid=0

Quick facts:

• ~2450 components in total
• ~£272 worth of components, excluding parts sourced from ebay which were primarily headers/sockets, nuts/screws/spacers, and prototype boards, and which will probably total somewhere around £50

Theres a good chance the total cost of components is higher than it needs to be. If I bought more stuff off ebay it would likely be a lot cheaper, but RS is my favorite supplier, and they offer free, next day delivery on almost everything. You do tend to have to buy in bulk, which means you end up with surplus components, but they can go towards future projects so its not all bad.

And finally, some photos of the fully assembled unit (the empty board will eventually become the display dimmer).

Clock design and build log #6 - calendar decoders

I'm going to do another combo post here, simply because the design portion is quite straight forward.

And if I'm honest, this was probably the most stressful module to build in the entire clock, namely because the month name decoder is such a monster - if there was something wrong with the design, or some issue with my translation from logicly to EAGLE which then made its way in to the physical build, then it was going to likely be quite painful to fix.

The design work for this board is mostly covered in prior posts about 7 and 16 segment decoders, namely these ones:

• Clock design notes #2 - 7 segment decoders
• Clock design notes #3 - 16 segment decoders

Most of the additional design work was to take the logicly circuits and re-build them as EAGLE schematics, since all of my builds have been guided by such schematics (logicly was just for simulation and verification).

As you'll see when you look at the schematics linked below, theres quite a lot going on in the month name decoder. It has a lot of gates which are connected together and was going to make for a challenging build.

The day of week decoder is quite tame in comparison, and the decoders for day of month have been built before on the time decoder module and so are tried and tested, and actually were very simple to put together.

So, the build. As I was expecting a fairly dense board for this build I decided to give myself as much room as possible and started laying out my transistors right up against the bus connectors at the bottom of the board. This made things a little interesting when connecting the various output gates to the bus, but overall it wasn't too difficult.

The first decoder to be built was the day of week, which would display something like MO, TU, WE etc. This build, as anticipated, went very smooth, and there were no issues encountered - it just worked. Phew - one down, two to go.

With the partially built decoder board in the clock I cycled through each of the 7 days of the week using the day of week set button on the calendar module and was pleasantly surprised to see all of the short names reading out as I had designed them. Here's a small selection:

Next were the day of month decoders. I'd already built these kinds of decoders before, and I didn't expect to hit any snags with these either, and nor did I. Two down, one to go, and so far everything was running fine giving me this:

Once again I cycled through all possibilities to ensure the correct numbers and sequence were displayed, and I also cycled through the various months to ensure that the counters would reset and count the correct number of days per month, this also proved to work perfectly.

I was feeling slightly more confident now that I was about to head in to what I felt would be the most difficult part of the build, the month name decoder. I figured the best way to go about it was just start doing it, and deal with the issues as they came up. To help, I would build the decoder "letter by letter", and use the logic analyser of my scope to check the outputs (8 at a time) were in the correct states for each month of the year. Heres a glimpse of how I went through that process:

Power and inputs to the decoder board in this case were supplied by a battery and some wires off a breadboard. I thought it would be easier if I had to make corrections, and didn't have to keep building up and tearing down the stack of boards.

Through this process I did happen to come across some mixed up connections which had occurred during my translation from locigly to an EAGLE schematic. It was a matter of buzzing out the suspect signal wires with my multimeter, working out what had gone wrong, correcting the schematic and then re-soldering wires to the correct topology.

I kept at it and eventually I got to the point where I soldered (what should have been) the final 10 transistors!

And after wiring it all together and testing the outputs with my logic analyser I was at a point where I wanted to plug it in and test it with the display board instead of looking at high and low signals on a scope!

And, after plugging it in I was greeted with a most welcome sight (after first closing my eyes and psyching myself up to open them, hoping to see the right output)!

Or so I thought, until I moved the month along to February.....

Hmm, that's not right! This turned out to be a very simple fix, however. After verifying that the calendar module was indeed outputting the correct signals to the correct pins, I tracked down and corrected two crossed wires on the display board. That fixed it right up, and cycling through all of the months I got a perfect readout for all of the names - just as designed in a spreadsheet all those months ago!

AMAZING I'm thinking - it's pretty well DONE.

It was at this point that I showed the clock to a friend, and after attempting to demonstrate the month rollover where the day should reset to 01 instead of 00 that I discovered the issue where it actually rolled over to 00. That was then corrected (or so I thought) with a little additional circuitry.

But I have since discovered another issue. On July 29 when the date should have incremented to July 30 it actually rolled over to August 00. Ahhhhh crap. So I'm currently pondering the solution to this, and I think I know why it is happening, and what the fix will be. Stay tuned for a later update about that (I really hope this isn't going to become a recurring theme.......) 😔

Anyway, it's actually very useable as a clock and calendar at this point, despite some niggling issues which I will hopefully resolve in time.

Here is the end result for this board:

As always, schematics are linked here:

• GitHub repo
• calendar-decoders.sch EAGLE schematic file
• calendar-decoders.pdf

And with that, it's basically done now. I plan to write a "debrief" post and talk about things that went well, what didn't, and my general thoughts of the project. Stay tuned for that in the near future.

As for the fix for the rollover issue, I will get to it in time. After such a massive project I want to take some time to do a lot of stuff that I didn't do while I was doing this, and basically do anything but this for a while! The display dimming board will also come at some stage in the future as a result.

Clock design log #5 - calendar module

I think circuitry wise the calendar module is my favorite - not only does it contain a bunch of ripple counters, but it also includes a good deal of combinational logic to determine (essentially) which month it is and how many days should be counted in each month, and then generate reset pulses using even more logic. As far as circuitry goes, it kind of seems more interesting than the other modules, perhaps because its not just a bunch of counters. There's a bit of circular dependency going on as well, with the day of month counter taking inputs from the month counter, and a reset of the day of month counter advancing the month counter. To be honest I was surprised it even worked at all - having done plenty of programming in my time and knowing how circular dependencies can cause great headaches...

It also has some nifty circuitry to ensure that when the day of month counter resets it doesn't reset to 0, but 1. This ensures that when the months roll over, they will always start from day 1. That is achieved with an additional input to the first stage of the units counter for the day of month (the only such instance of a preset input in any of my ripple counters), and a small capacitor which continues to hold the preset input low for a period of time brief enough that it will only go high after the reset input has had a chance to go high first. This ensures that the counter will be reset, and then the preset value will be loaded in.

I tested out this theory to make sure that my design was correct using a 2 bit ripple counter implemented on a breadboard.

The yellow trace shows the reset signal generated when the counter represents a value of 3, and the green trace shows the preset signal that feeds the preset input of the first counter stage, which has a delayed rise time caused by a small capacitor (100nF in the photo, but my design uses a smaller value). At the botton you see some digital signals, D0 and D1 which have been formed in to a bus, and which show the value of the ripple counter before, during and after the reset event. So that all seemed to work.

During the build of this module (as usual, this post is coming some time after the actual build) I discovered some flaws in my original design, so as you look over the schematic you'll find some gates towards the beginning of the schematic with numbers that look a bit out of place. This is due to the fact that I didn't want to spend the time to go through the schematic and re-number them all to fit in nicely after determining the fix and then implementing it. Laziness, or time better spent - you decide. In the end I decided to upload the fixed schematics with this post, rather than uploading a revised version with the build log as I have done in the past.

Prior to the fix I had connected the preset input to the output of the reset circuitry for that counter, but I quickly discovered that was simply incorrect, becuase as the counter would advance from 9 to what should have been 10, it would actually go one further to 11. Maybe it was trying to suggest something, or maybe I just stuffed up. So an additional gate connected to the right reset signals was in order, and that became gate 143 on the schematic such that only the correct reset signals would result in the initial preset value being loaded.

There is also another fix that I had to wedge in, and that was to do with the reset circuitry for the day of month counter. You'll see gates 144 and 145 hanging off gate 68 in the large block of gates which point to the left. This was some reset signal surpression that was necessary to ensure that everything worked correctly when manually setting the day of month. Technically you dont need gates 68 and 144 as they simply form a buffer, but I left them in the schematic because that is exactly how my circuit ended up being built (it would have been very fiddly to remove the components so I left them in). Basically, these gates prevent the reset signal from reaching the rest of the circuitry until the month set button is released. Prior to this I found that when the reset signal was asserted, the counter would end up with a value of 2. When I discovered that I started to wonder whether I needed the capacitor at all..? Anyhow..

I also designed in the ability for the clock to handle leap years, I think that was a nice touch even if I'll only use it once every 4 years. Pressing the leap year button inverts the state of a D type flip flop, and both of the outputs of that flip flop are used within the reset circuitry of the day of month counter along with outputs from the month counter which indicates what (kind of) month it is, and that causes the day of month counter to reset appropriately after 28 or 29, 30 or 31 days as appropriate. Whether the clock is in leap mode or not will be indicated on the display board using the dot point of the units display of the day of month. If it's on, it's a leap year and the day of month will reset after 29 days. Otherwise it's a matter of resetting after 30 or 31 days. Leap year mode is automatically cleared when the month counter resets from December to January, so the following year advances normally.

And finally, there is day of the week. This is a 3 bit counter which will translate to a 2 letter day of week readout on the display board, such as MO, TU, WE etc.

As with the time module, each of the buttons is associated with a debounce circuit to prevent multiple advances on a single press due to contact bounce. The little circuit I am using is working really well.

And that about does it for the design of the calendar module. Schematics are linked below as usual!

• GitHub repo
• calendar-module.sch EAGLE schematic file
• calendar-module.pdf

Clock design and build log #4 - display board

There's been a little bit of delay since my last post. We had some of the hottest weather this year which caused me to avoid slaving over a soldering iron, and I had some other personal commitments going on otherwise which ate up some time.

Design

What will be the last board in the clock (but not the last in the build) is the display board, which makes all of the internal workings of the clock visible to us simple humans.

It consists of a handful of 7 and 16 segment LED displays to provide the visual representation of the state of the counters within the clock.

As I mentioned in my previous post, I thought I had bought common cathode displays, but it turns out I bought common anode instead. The difference is as follows.

In a common cathode configuration, all of the "negative" pins of the LEDs are commoned together such that you supply positive voltage to the anode ("positive") pin of the LED to make it light up.

In a common anode configuration, the "positive" pins are commoned together, and to make an LED light up you ground the "negative" pin.

In either case you still need (ideally) a current limiting resistor per LED. You can in theory use a single resistor for an entire display, but the brightness of the segments will vary depending on how many of them are lit at a time.

How this affects my build means I just need a "few" more transistors on the display board than originally planned. "Few" as in 102 to be precise. The way I use them is as a switch to connect the cathode of each LED segment to ground. This enables current to flow from the positive rail, through the LED segment, then through its current limiting resistor and finally down to ground.

The decoders were originally planned to output a positive signal, that is that the output is high when the LED segment should be on, and originally it was planned to have the 2.2K resistors in the final driving gates of the decoders. But now, I use my standard issue 100K resistor, and the output of the gates in the decoder feeds to an associated transistor on the display board to switch a segment (or two in some cases) on or off.

So most of the circuitry on this board is resistors and transistors used to switch segments on and off.

Other than that, I'm doing something a little different with this post and combining both the design and build log in to one. The display board is reasonably simple, it holds no state like the decoder boards, and construction was quite straight forward and was completed some weeks ago. So ...

Build

I started off by laying out the displays on a board to determine an arrangement and spacing that I liked. I'm not going to worry about any kind of separator between the digit groups in the clock portion, I'm hoping the physical separation of the digit groups will be sufficient to make it easy enough to read. The digits/alpha groups in the calendar portion I think will be obviously different enough to make that readable, so separators shouldn't be necessary there either.

And then proceeded to solder everything in to place.

Due to the way I had laid out my bus pins I had to leave a reasonable amount of slack on each of the wires leading up to the top row of displays so that I could shuffle them around in order to get the bottom row of displays etc in. A little bit more thought in that area could have gone a long way to making construction a lot less fiddly, e.g. by placing some of the calendar signals on the top connector instead.

After completing this much work, it was time to try it out and much to my delight, when I plugged it in I got an error free readout. I manually cycled through all of the hours and minutes to ensure they all displayed the correct digits, and only had to fix a couple of segments that had been swapped around due to an inconsistency with how I wired some of the transistors up.

That last photo isn't the greatest, but I was actually able to use it as a clock at that point in time! Yay!!!

And after achieving this I decided to take a break from this project, plus the hot weather we've had around this time of year, plus other personal commitments that I had going on.... So that explains the rather long gap since my last post.

And at this point I noticed that my linear regulator was starting to generate quite a lot of heat due to the increased current from all of the LEDs. So I decided to up rate the heatsink a bit:

It does still get a bit warm, but the new heatsink has much more surface area to dissipate heat from and it seems to be doing a good job so far.

The next step was to place all of the displays for the calendar readout. And after doing so, I ended up with the following mass of wires. And the stack is building up quite nicely, too:

The squiggly bit of wire you see weaving between all of the pins on the rear side of the board is just pulling all of those pins high to turn on the associated segments so I could see what everything was wired and working, and thus would be able to turn on all of the required segments for each character that needs to be displayed for the various readouts. It remains to be seen if they are all in the right order though...

So now there are only 2-3 boards left to build: the calendar module and its decoder board, and having left the clock on overnight it really does add significant amounts of light to my bed room, so I will definitely be building a module which is able to dim the display between certain hours. I'm still toying with ideas of how best to do that.

And of course, below are links to the design files for this board.

• GitHub schematics repo
• display-board.sch EAGLE schematic file
• display-board.pdf

Clock design log #3 - time decoders

With the time module built and tested, I need a way to display that time in a more human friendly format, or at least the intermediary step towards that. Interfacing between the binary coded decimal (BCD) values that the time module puts out and the 7 segment displays requires a series of decoders that I covered in one of my very first posts, since what the time module outputs is not directly useable to drive a display - unless I wanted to build a clock that reads in binary.

This is where all of the earlier work with k-maps comes in to play. The decoders are not much more than combinational logic, taking the binary values as inputs, and turning the right outputs on to light up individual segments to produce the required display. There are no counters or SR latches or reset circuits as the decoders are completely stateless.

The time decoder board will have 6 decoders on it, one for each 7 segment display required to show the time in 24 hour format: HH MM SS

One of these decoders, the tens decoder for the hours (left hand most display) is a 2 bit decoder since it only needs to display values 0, 1 and 2. It will still decode a value of 3, because I'll re-use the same design in the day of month decoder when it comes time to build the decoders for the calendar module, but the time module never outputs a value of 3, so that should never appear on the display.

The tens decoders for minutes and seconds are both 3 bit decoders able to show values from 0 to 5, permitting the display of numbers up in to the 50's.

And the units decoders for hours, minutes and seconds are all 4 bit decoders which can show values from 0 to 9.

Put them all together and that gives the decoders the ability to display any combination of hours, minutes and seconds from 00:00:00 through to 23:59:59.

Rev B decoders

During the course of posting on my blog I've been conversing with one particular person on a reasonably regular basis, I believe his name is Matthias. In response to my post about designing 7 segment decoders he posted that he was able to reduce the gate/transistor count of some of them by not decoding digits 6 and 7 for the 3 bit counter. I'd kind of deliberately not bothered to do that, but it did get me thinking that perhaps I should. And having built the time module and realising how complicated and time consuming the construction process can be, reducing the number of gates and transistors is probably a good thing for my sanity. So I decided to use a re-designed version of the 2 and 3 bit decoders to reduce their part count. I was quite happy with the 4 bit decoder design so I havent touched that.

The new k-maps I came up with are available in this spreadsheet, and at the end of the post you'll find a link to revised logicly files and images which I used to verify their operation. These are the final designs I used to build my decoders.

I could have likely made them even more compact if I made them more (what I call) "loose", i.e. some values would match, and would produce some strange looking output on the 7 segment display, but you're not likely to encounter those values due to the preceeding logic in the clock. This can help to simplify some of the minterms, which requires fewer components to implement. But I decided not to do that, opting to strictly decode only the values that I want, and out of range inputs will result in a blank display.

The result of the revision of these two decoders is a reduction in transistor/gate count per the following:

• 2 bit decoder: originally 18 transistors and 14 gates, now 13 transistors and 10 gates
• 3 bit decoder: originally 56 transistors and 26 gates, now 35 transistors and 22 gates

Quite a large saving on the 3 bit decoder.

The good stuff

So here are the design files for the time decoders. Usual formats include EAGLE schematic files and a PDF export, plus the logicly designs for the revised decoders.

• GitHub schematics repo
• time-decoders.sch EAGLE schematic file
• time-decoders.pdf
• GitHub 7 segment decoders repo (includes .png images of below decoders)
• 2 bit decoder logicly file
• 3 bit decoder logicly file

Clock design log #2 - time module

The next board in the stack will be what I call the "time module". I call it this because it uses the 1PPS_CLK/ signal from the analogue board as its input, and using that it keeps track of the time time - and thats all it does. At what would be 24:00:00 it resets to 00:00:00 and generates the 1PPD_CLK/ signal which is used by what will probably be known as the "calendar module".

If you haven't already read my post about operating theory, it would be worth it before going much further with this post, it should help you understand whats going on in the schematics better. I'll re-cover a little bit of the theory here, but not in too much detail.

The basic premise of the time module is to implement 6 ripple counters, each of which has its own reset circuit that resets the counter at the appropriate value and clocks the next counter, and whos BCD values will be fed in to a set of decoders, each of which will drive a particular display at the front of the clock.

If you recall back to an earlier post, I mentioned that I had really wanted to implement these as 3 larger counters, but the decoders to drive the displays were getting very complicated, so I had to settle for 6 smaller counters. The idea behind this is that each portion of the display (that is, seconds, minutes, and hours) contains a "units" counter and a "tens" counter. A units counter will count 0-9 while a tens counter will count 0-5 (or 0-2 for hours). As each counter resets it clocks the next counter, so when the seconds unit counter "rolls over" from 9-0 it will clock the tens counter which will increment by 1. When the seconds tens counter "rolls over" from 5-0 it clocks the units counter for minutes, and so on and so forth. I guess its similar to how odometers in older cars work in a way.

As you're looking through the schematics for the time module, you'll see a lot of repeated circuitry which are D type flip flops that make up the individual stages of the ripple counters, and you will also see some other regular circuitry to the left of the ripple counters which is the reset logic for that counter. Above each counter will be a NOR gate facing in the opposite direction to all of the others, and this acts as an "AND" gate which feeds in to an SR latch. When the inputs to the "AND" gate are at appropriate values (in this case, all low because it uses inverted logic being a NOR gate) its output goes high and inverts the SR latch. When the SR latch inverts it causes the ripple counter to reset to 0 and generates a clock pulse to the next counter. The AC_CLK/ signal then inverts the SR latch again a short while later, and the counter can then start counting from 0 again.

Other gates just ensure that, for example, when MCLR is asserted (e.g. by pressing the reset button), if the input to the first stage of each counter was high it will actually be able to reset, and some other multiplexing such that either the SR latch or the MCLR signal is able to reset the counter. You will also notice that the minutes and hours units counters also include an input which allows those counters to be incremented manually by pressing a button. This is so that a value can be loaded in to those counters in order to set the time (e.g. after power on or user reset).

The hours counters are really the only "tricky" exception. Seconds and minutes reset at a decade boundary, but hours counts to 24 before resetting. So while there are still two gates which feed in to SR latches to initiate the reset, you'll notice that one of them actually causes not only the tens counter to reset but also the units counter, and in order to do that it takes input from the units and tens counters - that's unlike any of the others, which only take their inputs from the counter they are resetting.

And with that, the only thing left to do is to link you to the schematics:

• GitHub repo
• time-module.sch EAGLE schematic file
• time-module.pdf

Enjoy!

Clock design log #1 - analogue board

Finally, some real meat! Construction-ish posts. I'll be breaking things up in to two posts from here on. First will be a "design log" where I will talk about the immediate design task and run through its constituent parts, and also provide design files like schematics and what not. Second will be a "build log" where I will build what I just wrote about, and post photos and discuss any troubleshooting etc that I had to do to make it work.

The first board that I'll be building is what I am referring to as the "analogue board". I call it that because it has the most amount of "analogue" electronics on it.

So lets get stuck in to it.

Power supply

I'm designing my clock to work off 9V DC, and the power supply is pretty basic really - it's your bog standard linear regulator circuit, and is mostly a kludge of what ever reference design(s) I could find on-line plus a few suggestions that I've seen thrown around at times. It uses a 7809 linear voltage regulator, a smoothing capacitor for the input side, and a full bridge rectifier - because just like an amp that doesn't go to 11, anything less than a full bridge just isn't worth it.

The power source will be 12V AC from a wall adapter, and it is important to note that a power adapter that outputs AC is essential, as the AC is used to create the most fundamental timing signal within the clock since I'm not using any form of local oscillator.

AC_CLK/ generator

This is a circuit used to generate a clock signal which I call AC_CLK/. This is the most fundamental clock signal, as it is not only used to advance the time of the clock itself, but it is also used to reset various SR latches which generate other signals.

In a nutshell, instead of feeding the AC waveform directly in to my circuit, I first feed it through this circuit which uses three MOSFETs formed as a chain of inverters, and such that its output voltage is the system voltage of 9V DC. As the AC waveform goes high, the output is shunted down to ground. As the AC waveform goes low, the output signal goes high. This produces a roughly square wave output to the tune of the input AC signal.

Other circuits might use something like a schmitt trigger which will produce a "pure" square wave from a sine wave, and can also help to produce a clean square wave from an otherwise noisy signal. I don't expect the input AC waveform to be particularly noisy, so a schmitt trigger is not necessary and this simple circuit should work just fine for my needs. If you're interested in learning some more about how schmitt triggers work, check out this video and this video.

Power on reset delay

This is a "RC" (Resistor Capacitor) circuit. A pair of resistors create a voltage divider of which the high side resistor also limits the amount of current that the capacitor can draw to charge up. As the capacitor is charging it starves the gate of a MOSFET until such a time that it is sufficiently charged that the MOSFET is able to turn on. The MOSFET is actually acting as an inverter or NOT gate. When the MOSFET is off, current is allowed to flow from the output of the gate in to the reset mux, and a high input to the reset mux will assert a reset state within the clock. When the MOSFET eventually turns on, it shunts its output down to ground and the reset state is removed until power cycled.

I don't technically need this, as I could simply reset the clock manually once it is powered on, but I thought it was a nice little addition to ensure it powers up as "all zeros".

Reset mux

The reset mux is just an OR gate. It has two inputs, one of which comes from the power on reset delay circuit as described above, and the other from a button that the user can press to reset the clock at any time. Both signals combine through this circuit to produce a single "master clear" signal (called MCLR in my schematics) which is distributed throughout the clock. When asserted, this signal causes all counters and SR latches that produce the various clock signals to reset to default states (mostly all zeroes).

MCLR is also OR'ed with the output of the AC_CLK/ generator (a signal which starts its life as AC_CLK_GEN/) to produce the final AC_CLK/ signal. When MCLR is asserted by either the power on delay or reset button the AC_CLK/ signal is held high. Basically it ensures that all counters and latches within the clock will reset and be held stable.

Mains frequency prescaler

The mains frequency prescaler is implemented as a 6 bit ripple counter. It is combined with some additional gates which form a reset circuit. Without repeating myself too much (I covered a lot of the operating theory in design notes #5), when the prescaler reaches a certain value, an SR latch is set via an AND gate. When the SR latch is set, it resets the prescaler to zero, and the inverted output generates a new clock signal called 1PPS_CLK/.

I encourage you to read through the post I linked to above because it explains the operating theory in much more detail, including a timing diagram to demonstrate how all of the different signals are produced.

But the basic idea of the prescaler is to produce a clock pulse each second in order to advance the time module of the clock.

Schematics

And that about covers it for the circuits that are on the analogue board, so now lets look at the schematics for it. Full schematics are available within the GitHub repository as usual, and you'll need EAGLE to view them. I also provide them in PDF format if you don't have EAGLE. The schematics for this board are spread across two sheets/pages, one for the "analogue" side and the other for the "digital" side. The two files specific to this blog post are linked directly below.

I've included some notes within the schematics to try and explain briefly what each portion is for and what it does.

• GitHub repository
• analogue-board.sch EAGLE schematic file
• analogue-board.pdf

And with that, the first design log post is about done I think. The next post will cover the construction of the analogue board, and some details of testing/verification.