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 debug log #1 - month rollover issue

Here I'm going to talk about a month rollover bug that my clock had been experiencing.

In a previous post I spoke about an issue that came about when I showed the clock to a friend. When the clock advanced onwards from 23:59:59 on, say, the 31st day of a month to what should have been 00:00:00 on the 1st day of the following month, it actually advanced to day 0 - which is something that wasn't supposed to be able to happen.

I'd designed in a preset input to the first stage of the day-of-month units counter such that when ever certain reset signals were asserted to reset the counter back to the start of the month, the units counter should have been pre-loaded with a 1.

But I've already discussed and fixed that issue. This post pertains to a different rollover bug that I encountered after I had debugged and fixed the one above.

And the story behind this one is that when the clock is on day 29 of a month, and it needs to advance to day 30, it would actually advance to the next month and again to day 0, instead of the 30th.

My suspicions about why this was happening surrounds the use of ripple counters in my clock. I suspected that because of the way ripple counters work, in that it can take "some time" for a change starting at the least significant bit to make its way through all of the stages of the counter. What this means is that for a very brief period of time the counter can represent a number of different values in quick succession as the flip flops transition between different states.

And because of this, I figured that the block of combinational logic that determines what day of the month it is, and based on the "length-of-month" input (30 day, 31 day or February), at some point in time the state of the counters was such that the reset logic figured that the date actually needed to advance to the next month instead of letting the counters advance to the next day.

To test this theory I needed to probe around the reset circuitry in the clock to see what it was doing. Specifically I was looking at the output of GATE68 in the calendar module. The output of this gate will be high when the day of month counter should reset and advance to the next month.

I set up my oscilloscope to trigger on a high going edge of the output of this gate, set the clock to 23:59 on Jan 29 and then let it run. The sequence of events is as illustrated below.

As you can see (although the scope probe wasn't connected in these photos) that once the clock advances past 23:59:59 (to what would technically be 24:00:00) the reset logic generates a pulse which causes the day of month counter to reset to 00 and the month counter to advance to the next month.

So I thought about it for some time, and I reckoned all that might be needed would be to add a small capacitor to this reset signal, such that while the ripple counters are sorting out their final state, if the reset logic should happen to generate a pulse during this period, the initial bulk of that pulse should be absorbed by the capacitor such that only once the ripple counters settle down, and if their state represents something which should cause a reset, then the reset signal will remain high for a significantly longer period of time - long enough to fully charge the capacitor and thus allow the reset signal to actually cause a reset.

So I tried this out:

In this photo you see a little grey probe sticking out the left hand side of the clock. This is connected to the output of GATE145 in fact. The orange wire connects to a 1nF capacitor, the brown wire connects to VSS (ground), and the green wire connects to my scope.

As you can see on the face of the clock, this did indeed seem to do the trick, as the calendar had advanced correctly from the 29th to the 30th and remained within the same month, instead of moving to the next month.

I do still see a small rise in the reset signal, I guess 1nF is only just enough to cover this, but at about 1.5V its not high enough to drive any MOSFETs and cause a reset.

For completeness, heres a photo of the newest addition to the clock (the little orange blob), tucked away all nice and cozy in there:

The schematic for the calendar module has also been updated to reflect this recent addition. And with that, I am no longer working on any issues - the clock works and functions as it should. Only time will tell if anything else pops its head up.

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

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 build log #3 - time decoders

This has to have been the easiest build of the project so far. I'm not quite sure why, but I was able to build this board from start to finish in about 3 evenings. It was certainly refreshing not having to spend weeks on it, and satisfying as the results were very rapid (rather unlike the timeliness of this post...)

The build starts as usual with the bus connectors. The time decoder board is going to be very much toward the front of the clock, in fact it'll likely interface directly with the display board, so it has all of the bus connectors on it, even if most of the pins within lay un-used by this board - it still has to carry all of the signals from the rest of the clock through to the display board.

I tried something a little different this time, however. In prior builds I had added supply (9V DC) and ground "busses" across the board as I went along, but it became a bit painful constantly modding new ones in as the build progressed, so this time I laid them all out in one go.

Then I start to solder in all of the transistors and resistors that will make up the gates. If you happen to be wondering how I get large numbers of them in at a time without a load of hassle, blu tack is your friend:

I borrowed the blu tack technique from Julian Ilett, a YouTuber that I follow (although I'm sure he wasn't the first to do it either, though he's certainly the first that I've seen do it...)

Then it's a process of wiring everything together on a decoder by decoder basis, and test each one as I go along so that I can catch faults progressively and early.

Testing was achieved with a "jig" that I rigged up on a breadboard. Although I had originally planned to, and thought that I had bought common cathode displays, it turns out I bought common anode displays instead. Using common cathode I had planned to have the final "driving" gates of the decoders control the flow of current to the LED segments, but now with common anode displays I'll be sticking resistors and transistors on the display board along side the displays they will control. The transistors will connect the cathode of each segment down to ground when its decoder output is high, so it'll achieve the same result but use a few more transistors and resistors (not like I'm short of them...)

In the right hand picture above you see what is the units seconds decoder connected to the time module and then onwards to the test jig. I even managed to create an animated GIF showing it counting through all of the digits.

I worked my way through all 6 of the decoders very quickly and they all worked without a hitch so unfortunately there's no troubleshooting to speak of, but here's the end product including a bonus photo of how the stack is coming along now (and it's starting to feel kind of weighty!):

On to the next one I guess!

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 build log #2 - time module

Build

Build for the time module started with the bus connectors that would connect to the analogue board and further in to the stack. The connector for the analogue board is a small 8 way pin header, while the connector for the rest of the stack is a 40 pin socket - but not one with extended pins. Positioning of this board within the stack is somewhat limited, as it connects to the analogue board and in doing so it bridges power and the MCLR, AC_CLK/ and 1PPS_CLK/ signals through to the larger bus. That means this board pretty much has to sit adjacent to the analogue board for the bus connectors to line up properly between the two. It all started off looking so simple:

Then I started what would become a (part time) month and a half long process of soldering in transistors, resistors and jumper wires to create the gates that would form the logic.

While putting the seconds counters together I had an idea - what if I was to use the 1PPM clock signal that it creates to collect some statistics about how much the AC frequency drifts? I thought it would be kind of interesting to see just how wild the AC frequency was, and how often and for how long it drifts around. As part of this I thought it would give a nice insight in to how quickly things might degrade and how long it takes to recover.

So after soldering in the first 56 gates worth of transistors that make up the seconds counters and their reset logic (which generates the 1PPM_CLK/ signal) I branched off in to a small software project.

I had a Raspberry Pi sitting idle that I thought would be perfect for the task, since it has GPIO pins that I could interface to my clock. I knocked together a small program in C that, upon start, takes the current UNIX timestamp when the first 1PPM clock pulse occurrs, and for every subsequent 1PPM clock pulse it records the UNIX timestamp again, substracts the difference, and outputs the timestamp and difference. I piped that information in to a file and then left it to run for about 2 weeks until something started going funny and it started missing pulses and producing erroneous results.

I tried applying some manual fixes to some of the data, and restarted the script a couple of times before it started getting too out of hand and I gave up, sticking with about 11 days worth of solid data, or about 15,700 records. From that I was able to produce the following graph by loading all of the data in to a spreadsheet:

Since I don't know when "zero" is for the AC mains frequency, "zero" for me and my exercise was at UNIX timestamp of 1491865936, which for the non-techies means April 10th 2017 at 23:12:16 UTC (basically it's the number of seconds since January 1st 1970 00:00:00).

This answered two questions:

1. How much the clock may end up drifting - over my sample of data as much as +22 and -35 seconds
2. How quickly or slowly it drifts and recovers - could be as quick as a single day to a couple of days

Re #2, April 17th was a "bad day" where it slowed right down to the slowest it ever got, while we see that over the 13th and 14th we caught up 20 seconds and went 10 seconds faster still.

The most important thing I learned from this was that the clock would probably eventually come back to zero offset. So some of my worries about how reliable the AC frequency was going to be ended up being addressed through that little exercise. At least it wasnt going to be constantly getting slower and slower or faster and faster and never return, though long term results are yet to be seen...

Here are a couple of photos/images showing the setup I used to collect the data for the above graph, and also the schematic for what's happening on the breadboard (a MOSFET level translator, since the Raspberry Pi GPIOs are 3.3V and my clock is 9V):

Funnily enough, this is the first time I have ever used a Raspberry Pi for the thing that I guess it was intended to be used for - tinkering with electronics. My other Raspberry Pi's are running FreeBSD or Linux and acting as servers more or less. :-)

Back to the task at hand... it pretty much just sounds like a broken record from here. Solder, test, repeat. So theres not really much more to say about the build. And it seems I didn't take many more photos during the construction process, so theres a distinct lack of more things to say or show right now. So perhaps the more interesting and juicy bits are in the testing of what I have built.

Testing

Learning from the build of the analogue board, I built each counter stage individually and tested that it worked as expected before moving on to building the next. This meant that solder joints weren't buried under so many wires and hard to get at. It also gave confidence that as I was going along and things were working, if anything happened to stop working further on during the build it might likely be what I was just working on rather than something earlier on. At least then it would be a process of test the most recently built circuit and then start moving backwards if that was checking out OK.

With the seconds counters working just fine, the first major problem I came across was with the minutes counter. When I started building it one of the first things I did was to hook up the button with its debounce circuit so that I could advance that counter manually, instead of having to wait for the 1PPM_CLK/ signal to fire, although testing that the counter advanced on that clock pulse was also important.

Advancing of the units counter was fine, but I noticed an issue when it came to the reset event. The counter would advance, and at 10 count the output of the gate hooked up to the outputs of the 2nd and 4th stages would go high, inverting an SR latch to reset the counter back to 0. But after doing that, the SR latch wouldn't release that reset, so the counter could no longer advance (well, it would have if I had actually hooked up the reset inputs of the counter stages, but I hadn't at that point in time). I traced out all of the wiring I had soldered and realised the issue was not with the design or build of the time module circuitry, but with how the AC_CLK/ signal was handled back on the analogue board.

On the analogue board is a switch that allows you to isolate AC_CLK/ from the clock to stop it advancing the mains frequency prescaler, thus allowing you to reset the clock to all zeros and then set it manually without it carrying on, then set it running once you were ready. But that switch isolated the AC_CLK/ signal from the entire clock, and while it did what I had originally intended it to do, it was breaking another piece of functionality - when an SR latch it set by a connected "AND" gate to cause a reset, it needs the AC_CLK/ signal to release that reset! Ooops. So a quick re-design of the AC_CLK/ circuitry such that the switch only isolates AC_CLK/ from the input of the first counter stage mains frequency prescaler was in order, and luckily that was pretty simple, and required minimal re-work. The revised schematic will be linked below.

Here are some scope traces that show the incorrect (left) vs correct (right) behaviour:

Some explanation of what you're seeing ... the yellow trace is the inverted output of the SR latch on the minutes units counter (i.e. the one that would generate the 1PPH_CLK/ signal in this case). That output clocks the input to the minutes tens counter, hence it has gone from high to low in the left hand image. But you see that, while D4 has gone high (being the first stage of the minutes tens counter), D1 and D3 have not gone low, and the yellow trace remained low.

At the time I took that trace, the switch isolating the AC_CLK/ signal from the clock was set to the "stop" position. If I had set that to "run" things would reset correctly. But it's a bit silly to need the clock to be in "run" mode for this to work correctly, its kind of the complete opposite of what I was aiming for.

After modifying the circuitry around that switch, I took a second capture which is the right hand image you see above. As you can see things are a bit different here. As D1 goes high towards the right hand side of the trace, it remains high only for a very brief period of time, hence you just see a "glitch" in the trace for that signal. When it does go high, and with D1 and D3 representing 2+8, that generates the reset condition for that counter, so D4 goes high. You also see a very brief glitch in the yellow trace - thats the SR latch being set by the "AND" gate of the minutes unit counter and then being reset by the AC_CLK/ signal, and all with the switch being set to "stop". So that was now sorted and working correctly.

For interest sake, here's an even closer look at whats happening when the reset of the minutes unit counter occurrs, which pretty well matches the description that I gave in design notes #5 - it's nice to know that my theory turned in to reality 😎 :

At the bottom you see that I have grouped the digital channels in to some busses, B0 (D0-D3) and B1 (D4-D6), and they are displaying what you'd see on the display if the decoders were built. As we lead in from the left, we're at 09, and at the next button press D0 goes low (and for a very brief period of time we go backwards to 08) until D1 goes high and we get to a value of "A" in base 16 (aka hexadecimal) which equals 10 in our every day base 10/decimal system. At that point the reset condition is created and after 20 odd uS D1 and D3 go low while D4 goes high, and now we see that the value on the display would be 10.

Fortunately there were no more surprises that needed fixing in the build from here on, and things went smoothly. All counters worked as expected, and all clock pulses were generated fine and dandy. Somewhat boring, but also somewhat relieveing since ...

End result

... heres what I ended up with!

That was quite a bit of work!

But most importantly it works, much much much to my relief. Along with producing the 1PPD_CLK/ signal when rolling over from 23:59:59 to 00:00:00, it also produces 1PPM_CLK/ and 1PPH_CLK/ signals, although at the moment there is nothing planned that uses these, except perhaps 1PPH_CLK/ which might be used by another module to do display dimming/blanking.

Luckily I think this will be one of, if not the busiest board in the clock - it's certainly going to be one of the most densely populated. I anticipate that the calendar decoder board might be pretty complex/dense too, but we'll have to wait and see what that one brings (designs still pending at this stage...)

In closing, along with the revised analogue board schematic, I've uploaded the C source for the program I wrote to capture data for the graph, and I have also uploaded an updated schematic for the analogue board with the fix for the AC_CLK/ generator. C is not my every day programming language, so please be gentle (and you'll need wiringPi to make it work).

• offset.c C program to collect data when 1PPM clocks
• analogue-board.sch EAGLE schematic file
• analogue-board.pdf