​​Getting Up-To-Speed

A project log for Clock Clock

My attempt to put together a digital clock made of analog clocks, as originally created by Humans since 1982 and David Cox

Matt FinchMatt Finch 02/11/2015 at 21:093 Comments


( Disclaimer: I'm no writer. I apologize in advance. )

I'm going to try and post a log around weekly, if for no other reason than to ensure I attempt to make some progress each week between posts. This first entry will (edit: begin to) summarize what I've done to date.

I am software developer with no prior electronics experience. Tooling around with these things is something I have wanted to get involved with for some time. When I saw the Clock Clock in action, I immediately thought "I have to make one of those". So, here I am. I understand that this project is ambitious for a neophyte, but I intend to take my time and see it through. Much of the time I have spent so far has been developing a basic level of understanding of the tools I intend to work with. (What is Ohm's law? How does this Arduino thing work? etc...)

Then, it was time to think about the specific technical details of the project. I browsed around the web for ideas and I ran across Hackaday for the first time through the page that I've linked to this project, which was (lucky for me) a discussion about how to do exactly the thing I wanted to do.

The Approach

There are 24 clocks in the piece and two hands on each clock. My first concern was how to make the hands go around. I decided to use 48 small stepper motors ( the little 28BYJ-48 ) to drive them. My reasoning:

After some quick proof-of-concept sketches, I went ahead and ordered 50 of the little steppers from China for less that $2 each with the drivers, partly because of the long lead time on delivery, and partly as a commitment device to encourage myself to get cracking on the project.

I'll be controlling things with an Arduino Mega. I initially thought that I'd need the Mega to help handle all of the IO, but the extra pins may be moot.

I'm still green and unsure about best practices for communicating with a large number of devices (unsure of everything, really). With that said, my current plan is to use a bunch of chained SIPO shift registers (74HC595). Since each of the 48 motors requires 4 pins to drive and each shift register has 8 outputs, I'll need 24 of the registers to drive all of the motors. Somewhat conveniently, each register can drive the two hands of one clock, so I'll probably put the registers inside the clocks with the motors. The whole chain will only use 3 pins on the 'duino.

I have the software side of that sorted. I modified the AccelStepper library so that it would manage a collection of steppers and communicate with them through the shift registers. It will send the output values to all of the steppers at the same time, only once for each iteration of the arduino's loop() (or each time I want 1 or more of the steppers to take a step). The drawback to this shifting approach is that driving N steppers through the shift registers in this way requires ~3N digitalWrite() calls for each step. When I tested a sketch to tell the arduino to pretend that I had 48 steppers running it was initially very slow. However, including the DigitalIOPerformance library to improve the speed of each write has been a big improvement. I am confident that things are moving fast enough now, but I still have plans to integrate 48 inputs (which I will detail later). That may push the system over the edge back into tediously slow territory. In fact, my next bit of work is to test exactly that. If someone with more knowledge than I recognizes that shift registers are simply the wrong approach to take here, please let me know. I still have time to reverse course.

This is running long, so I'll bore you with the rest of the technical details of my tentative approach in the next post.


Matt Finch wrote 02/12/2015 at 15:05 point

Thanks, Dave.  I'm going to take your advice and put together a single clock module this week. 

The motors were packaged with a little controller that is basically just a Darlington array (ULN2003) and a power connector.  So, the motor doesn't have to draw its power from the 74HC595. 

The controller also has 4 LEDs to show the phases in action, which is useful in testing but may be visible in the final product and draw extra power.  So, I was thinking that I might take the ULN2003 out (it just sits in a DIP socket) and wire it up directly in the final product.  This would also allow me to put all of the workings of an individual clock module on a single piece of perf board.  However, there are a couple of caps on the controller whose purpose I want to understand before I potentially eliminate them.

  Are you sure? yes | no

davedarko wrote 02/12/2015 at 22:13 point

That's how I do it, look for the smaller projects in your project :) Otherwise you would have to trouble shoot a lot more later. Those caps will probably be for filtering and de-coupling - this is something I have to tackle for my R8-D8 project next. If you're not sure about the LEDs, just solder them out - no LED - no flow. This clock clock held me up until 2am yesterday - I thought about the 3*8 matrix and tried if a 1:4 or 1:2 gear set could work, too. I might program a little something to check my theories. I'm looking forward to your updates!

  Are you sure? yes | no

davedarko wrote 02/11/2015 at 23:27 point

I'd say start with testing and building one module as a proof of concept, than try out daisy chaining the shift registers and test your prototype on the next port. What motor controller will you use, since they will probably need more than the max 35mA per pin / 70mA total that the 74HC595 can give? 

  Are you sure? yes | no