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 build log #5 - calendar module

One thing I've come to realise throughout this project is that describing the build is reasonably uneventful - it's really just a repetition of place components and do a load of soldering. It makes for much less of an interesting read.

Certainly on a personal level I have found the troubleshooting process to be much more interesting - discovering an issue and trying to figure out how to fix it in as few changes or additional components as possible. Some of my boards are quite dense with little room for more logic, especially if a fix needed a large block of logic to implement. And as you've seen the "rats nest" of wiring on the rear of the boards actually poses quite an accessibility problem getting to solder joints, even with the reasonably fine 1.5mm soldering iron tip that I have used.

Luckily, however, problems requiring fixes have been reasonably uncommon, with maybe a transistor or two added here and there. And I've been quite thankful for that.

So having said all of that, I'll skip most of the details of the build of this board, and fast forward to the troubleshooting stages.

Like in previous builds involving ripple counters, I built each stage one by one so that I could test that they all worked before burying them under a lot of wires. And like all of the counter stages that came before, I didn't encounter any significant issues. In fact, if I encountered anything that could be considered significant, it was generally that a floating reset input would generally cause that stage to not function until I pulled it low (otherwise it was in constant reset). One of the disadvantages of using MOSFETs over other types of transistors is that their gates are capacitive, which means that when they are floating their state is somewhat non-deterministic - that is to say they could be high, low, or somewhere "kind of in between" - so pulling up or down is essential.

This is often very easy to fix. Using a pair of tweezers I can create a short between the gate pin and the negative power supply rail, and that was usually enough to sort out that gate long enough that I was able to test the functionality of the n-bit counter that had been built up. Some gates were a little more stubborn than others and needed a tiny piece of wire soldered in to hold the pin low. The primary reason that was an issue at all was due to the way I built up the counter logic. I would typically start with the counter stages and then move to the surrounding reset logic, so to begin with the reset inputs of each counter stage were not connected.

By far the most significant issue that I came across with this build was to do with the preset input which was supposed to ensure that when the month counter resets (i.e. when the calendar moves between months) the day of month counter would reset to 1 instead of 0 (since there is no day 0 in any calendar I know of). As you'd see from the design log for the calendar module, I did breadboard the circuitry to determine whether or not using a small capacitor at the appropriate point in the circuit would hold the preset input low for a short period of time which would enable a corresponding reset input to assert itself high prior to the preset input going high. This sequence is required in order for the preset to work, and certainly it worked on my breadboard. Hence I designed in what was to be the original design of the circuit. But it turned out that this still didn't work quite right once the circuit had been fully built up, and it only became apparent when I showed off my clock to some friends and this little gremlin surfaced. So it was back to the drawing board to find a solution.

I started by scoping out the various reset signals to find out what was happening, and unfortunately I forgot to capture an image of the signals on my scope, but the basic problem that I discovered was that the reset signal that is generated by the large block of reset circuitry below the units counter would be so brief that combined with the capacitor loading the preset input I think it just never actually had a chance to go high. I believe I did notice the tiniest of bumps in the trace for the preset input where that signal had started to rise, but by that stage the counters had reset, and the resulting reset signal was no longer asserted, so the preset signal was dragged back down to ground.

My solution involved adding in some more gates to form another SR latch, one input would come from the original inverter that was connected to the preset input, with the capacitor removed. The other input would come from the AC_CLK/ signal to reset the SR latch once the preset input was no longer going to be needed. The capacitor was then moved down to the appropriate output of the SR latch and then fed in to the preset input. I did also breadboard this solution to ensure I wasn't going to be wasting more time, and that also proved to work, only this time in-circuit.

I really do wish I captured a screenshot from my scope so I could visualise all of what I just said above, but you'll just have to believe me (and I hope it all made sense). And yes, you're seeing the finished clock there, before I've gotten around to writing any blog material for the calendar decoder module. Oops? :-)

So while the day of month counter was now resetting correctly upon the month rolling over, the next problem I found was when pressing the reset button at the back of the clock, the day of month would reset to 0 instead of 1. I had a solution to this pretty much already worked out, and it used a typical combination of logic that I have used elsewhere to "suppress" a certain signal when another signal is asserted. This involves inverting the AC_CLK/ signal and feeding it in to a dual input NOR gate, with the other input of that NOR gate connected to MCLR. When ever MCLR happens to be asserted, the AC_CLK/ signal will not propagate to the SR latch to reset it, and thus the preset signal will be able to have some effect.

The result looks a bit more complicated than the original, and I guess it is, but hopefully is easy enough to follow:

Before

After

I was fairly confident this would now work properly, so I went straight ahead and built it up - a total of 7 transistors making 4 new gates (146-149). And afterwards when testing it out, it all worked perfectly. Day of month was now resetting correctly upon month rollover and when the reset button was pressed.

Calendar module done! Here are the results:

Since there were some modifications to the circuitry which occurred after the design log was published, I've uploaded revised schematics along with this blog. They are in the same location as before.

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

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.