The Bug Hunt

A few years ago, someone’s project came up on my Twitter Feed (or elsewhere — it’s been a while, and I don’t remember with certainty) that caught my interest. This happens with an alarming frequency, but most of the time I can stifle the interest sufficiently to avoid ordering all the parts. Our house is littered with projects that I have bought the parts for, but never completed. Projects that are born of my own fevered brain, especially those whose inspiration is a really nifty part or gizmo I’ve come across, are especially susceptible to this fate. And the Classroom Clock started out like many — I purchased the necessary parts, and then they sat there for a couple of years.

But unlike so many others, this one did eventually come together. Probably at least in part because it was given as a Christmas gift to my wife, Susan, a middle school science teacher. It took some work to get it all together, but then the problem was that the kind of schedule it was originally programmed for didn’t really mesh well with the schedule at Susan’s school. Once I began to get familiar with the code, I realized I didn’t like it very well, so I rewrote most of it from scratch, in a somewhat more generalized way. This past year, I made some more minor updates to it, basically to make it easier to update the schedule and calendar from year to year. The official school clock seems to drift more than the Chronodot that’s at the heart of the Classroom Clock, so periodically I have to re-program the time. The original project didn’t have any means for user input, so there is no way to manually change the time on the clock. In fact, the only way to change the time is to reprogram the clock, and the only way to “synchronize” the time is to calculate exactly how long it takes to upload the code to the clock, and hard-code an appropriate time in the program. Argh!

My contribution in this area was to write a completely separate program that can be uploaded to the clock, with which you can interactively set the time. Then, you reload the normal clock firmware which no longer attempts to set the clock at all, and everything is good.

So one time in the fall, Susan’s students apparently wanted the clock to display in 24 hour time. This is of course an easy change. The Chronodot tracks time in 24 hour mode, so it was just a matter of not subtracting 12 from the hours.

Recently, the delta between the official school clock and the Classroom Clock got to be large enough to be annoying, so Susan asked me to come adjust it. We ended up bringing the clock home, and it was approaching 9 p.m. when I got around to looking at it. I wasn’t paying attention to the actual time, but when I powered up the clock, it said something like 10:43! It had always been completely reliable, so I was mystified as to why it would display a completely random time like that. After a few minutes, I realized that the minutes were correct, but why were the hours off by 2? That was a bizarre mystery.

A little while later, it finally dawned on me what the problem was. The clock might have read 10:43, but that’s only because it was in fact not designed for 24 hour time. The digit for tens of hours was not a full seven segment digit, but rather just the two rightmost vertical segments — an engineering shortcut if ever there was one! The code in the clock, when deciding what to display there, would turn both segments OFF if the hours were less than 10, and both segments ON otherwise. So, it was doing its darnedest to display 20:43, but couldn’t. And of course I was not thinking about the fact that it ought to be in 24 hour mode — I just saw 10:43 and eventually decided it was off by 2 hours somehow.

I asked Susan if she’d ever noticed it being wrong like that before, and she recalled that perhaps she had. When pressed, she remember that it was during parent-teacher conferences, in the evening. One of the only other times anyone would have been looking at the clock after 19:59.

It’s easy to see how a bug like this could cause lots of head scratching, because it would be easy to report the problem as “sometimes the clock is off by 2 hours” and leave it at that. And you’d be left poring over the code, trying to figure out how a simple math error could occur occasionally and seemingly randomly.

In the end, we decided to set the clock back to 12 hour mode.

I’ve long had a Version 2 of the clock in my brain. I’ve constructed it so that the “brains” of the clock can be transplanted while leaving the display parts intact. The brains for V2 will run on a chip that provides WiFi connectivity and runs microPython. It will therefore be able to:

  • query a timeserver on the internet for the actual time
  • periodically download a configuration file, which can have the calendar, schedule, and an offset to apply to the real time, so the clock can match the official school clocks

The hope is to write the code in a flexible enough manner that the config file can provide lots of different ways of arranging schedules and using the “extra” digit to denote the period, or day, or whatever.

And now I realize there ought to be a V2 of the display hardware as well, which would have a full digit for tens-of-hours to allow for 24 hour time, and also some form of explict PM indicator for 12 hour mode.

Some day…


On Thursday (2 days ago) I ordered an electronics prototyping kit based around an Atmel ATmega8U2 microcontroller. The kit is called an Arduino, and I ordered it from Adafruit Industries (funny name, I know), and paid for UPS ground shipping. I’m glad I didn’t pay for 2-day or 3-day “Priority” shipping, because it arrived Friday, the very next day.

The hardware is “open source” and there are many freely available open source tools for programming it. Tyler and I played around a little with it last night, and made it blink an LED. I played a little more after he went to bed and made it light up a series of LEDs in various patterns. Cute. The programming environment is C-based, so it is pretty familiar to an old programmer like me. Today (Saturday), I spend a couple of hours (chopped up into 5, 15 or 30 minute increments) and was able to make something, well, useful. It also uses a separate LCD display that I also purchased (seemed like it could be a fun add-on), and a temperature sensor that came with the kit. Using the display meant also using my nice new soldering station to solder 21 connections! Here it is:

It is a thermometer that displays the temperature when you press a button. It displays for 5 seconds, then the display turns off to conserve the battery.

I was partly inspired by a friend who also bought a kit and has been enjoying it. I had heard of Arduino starting a few years ago from the Make: blog and magazine. It is very popular among hobbyists and artists of a certain bent. It has lots of useful means of interacting with the real world, and a bevy of enthusiasts who have contributed lots of code and made add-on hardware for the platform. We have plans for a much more involved project, but for now, these little steps are still exciting.