# Almost Binary Clock

All,

I created what I'm calling an "Almost Binary Clock" - It measures time in 5-minute increments using LED's, marbles, and it's all mounted in an old oak door header.

Technically speaking, of course binary clocks aren't anything new, and certainly the coding was a piece of cake, but I was going more for aesthetics on this project.

Joe

I was going more for aesthetics on this project.

Well, you definitely got where you were going for: it looks very nice.

It's an interesting look. It kinda suggests Jules Verne, a Victorian vision of nuclear reactors with brass-plated gauges and filigreed containment vessels.

It's looking nice.

I was just wondering though, why you've made the choice for the minutes to use 5, 10, 15, 30.

If you'd have used 5, 10, 20, 40 it would have been in (binary value) * 5. Like: off, off, off, on = 0001 = 1, 1 * 5 = 5 0010 = 2, 2 * 5 = 10 0011 = 3, 3 * 5 = 15 0100 = 4, 4 * 5 = 20 0101 = 25 0110 = 30 0111 = 35 1000 = 40 1001 = 45 1010 = 50 1011 = 55 1100 = 60

Thanks! And good point - I actually gave this some thought, and I should probably add something the writeup to explain my logic here.

I thought :15 and :30 deserved their own LEDs since those are (in my opinion) the more significant ways in which we normally divide time up (in quarters). For example, TV shows usually start on half-hour increments. If I used the 5-10-20-40 approach then that’s like dividing the hours up in thirds…it might be better from a mathematical perspective but it’s not how most people think of dividing up an hour.

And since the 5-10-20-40 approach doesn’t get you any more efficiency (less LEDs), there was not a significant advantage to doing it that way.

it might be better from a mathematical perspective but it's not how most people think of dividing up an hour

That's very good thinking: too many products and systems are difficult to use because they're designed around the engineer's worldview, rather than that of the non-engineers who have a very different mental model of the environment in which the system operates, and/or a very different pattern of use. E.g., the engineer concentrates on making it easy to do X, but the end users only do X once a month, and wind up griping about the fact that it's hard to do Y, which happens 10 times per day.