User Tools

Site Tools


Bodge Clock


What do you get when you combine a 7-segment bubble LED display from an old calculator, a battery holder, a microcontroller, a handful of assorted components, bare wire, and hold everything together through the liberal application of super glue? Answer:

An earlier version of the Bodge Clock, perched proudly atop a monitor at work.

Oh, and blu-tack. No engineering project would be complete without blu-tack.

As the name suggests, this clock isn't exactly one of those polished projects - instead, it's my playground for solving problems that don't exist using methods that are questionable at best. This project has its origin in an (quickly scrapped) attempt to make a wristwatch using a LED display, but it has since morphed - or shall I say, organically grown? - into a somewhat useful conversation piece.


I don't think it can get any simpler than this: It's a clock. Telling the time is all it does. It is powered through USB, and uses a pair of AAA batteries to keep time when there is no power from the USB. The USB connection is made by a FTDI TTL-232RG, which provides a UART interface, as well as a regulated 3.3V supply.

Circuit and Components

At the heart (or buried inside, physically speaking) of the Bodge Clock is an ATmega48 microcontroller, which directly drives the display. This is a 6-digit, 7-segment (plus decimal point) “bubble” LED, which must have come from an old calculator. The microcontroller runs off its internal RC oscillator, but uses an asynchronous timer running off a 32kHz watch crystal to keep the time.

A surprisingly tricky part was switching between the supply voltages (battery or USB). In an ideal world, the battery supply could simply go through a diode, which would prevent the battery from being charged from the 3.3V supply, and would power the circuit when the USB supply voltage drops. However, there are two issues with this approach:

  • The microcontroller needs to sense the USB voltage, and turn off the display and go into low power mode when there is no supply from the USB. A one-diode solution would not provide an independent node for measuring he USB supply
  • It is conceivable that parts of the USB-UART bridge would be powered from the battery, which would likely result in the battery draining quickly.

Simple solution, no good.

The obvious solution then is to pass both the 3.3V supply from the FTDI adapter and the batteries through diodes. This way, the USB supply can be measured independently before the diode, and there is no way of the batteries feeding back into the USB circuitry. Unfortunately, this is where the problem with picking parts from the drawer comes in: The ATmega48 only has a nominal operating voltage of above 2.7V, whereas the supply through silicon diodes might well be less than that (e.g. 2.6V from 3.3V, or even less with run-down batteries). Incidentally, Schottky diodes are of no help here either, due to their large reverse leakage current.

Playing with the clock showed that the processor will run quite happily down to 1.8V or so, but that would mean there wouldn't be a good excuse to come up with an overengineered solution!

Less simple solution, but not exciting enough!

I then spent quite a bit of time trying to come up with a circuit that would fulfil the following requirements:

  • No appreciable voltage drop between the source and the supply rail
  • Sensing of USB supply voltage possible
  • Switching between sources in hardware
  • Arbitrary switching between sources (i.e. no latching to one source)
  • No additional current draw when running off batteries
  • Supply circuit off USB when USB voltage connected
  • Supply circuit off batteries when USB supply between grounded and open (but not powered)

Over time, I converged on the circuit below.

Completely overengineered, works like a treat!

The most obviously unconventional items you might spot are switching the batteries on the low side, and the optocoupler. It was most straightforward to switch the batteries on the low side, as the body diode of a high side MOSFET would not have prevented charging of the batteries. Similarly, a high-side PNP transistor (on low-side NPN) would have required base current to turn on. One nasty side effect is that when the MOSFET is off, there is still a current path through the body diode of the MOSFET, and the circuit will be powered with about 2.4V. However, this situation should not occur because when the MOSFET is off, the circuit will be powered from the 3.3V supply.

Unfortunately, many approaches for switching the USB supply are very susceptible to this “parasitic” power source, which can set up enough leakage current to e.g. turn on the pass transistor for the USB supply even if it is disconnected. One reasonably robust way around this was to use an optocoupler: The forward voltage of the LED, combined with the poor current transfer characteristics at low currents mean that leakage currents can't turn on the pass transistor unless a proper supply is connected.


The firmware for the ATmega48 (AVR Studio project) is available here:

The time on the clock is set through the UART: 6 plain ASCII numbers representing the time are read, and sending a x sets them as the time. Sending b resets the number input. For example, b121500x sets the time to 12:15:00.

Be careful, the entire code is a bit hacky, so don't assume it will handle unexpected inputs or unforeseen conditions gracefully.


Here are some pictures that show the Bodge Clock in its current state in all its glory.

Well, that doesn't look too shabby.

I suppose I could have done a neater job.

Proof that flux fumes are unhealthy

There, that's better.

projects/bodge-clock.txt · Last modified: 2016-01-26 21:10 by robert