Here you’ll find a few direct links to important content of this page:

Electronic projects:

A look back

A look back

Just until a few hours ago, the Schatenseite — my main homepage — was running with the Typo3 content management system. I installed it about twelve years ago, and I’m still certain that people can build awesome sites with it. However, Typo3 maintenance takes more engagement than I’m willing to invest. And Typo3 as a CMS was too big for my little page, anyway — which was clear from the start… :-D

I’m running my blog since 2004, and I think most of my content fits better into a blog than into a classic ‘homepage’ format. So old projects are ‘fading out’, instead of me taking them offline. So I moved my blog to the main page. I preserved parts of my old homepage by ordering some articles into the blog. I kept chronoligical order with this, so what I wrote in 2006 will be found in 2006, even if I copied the content in 2015. I put a sticky article onto the front page, so it’s easy to find the main project pages.

Ages ago, I heard a very wise sentence. Unfortunately, I don’t remember who said that:

Important URLs never change.

I tried to honor that with my relaunch. So on one hand, the most important pages of the old Typo3-site should lead to the right articles in this blog. And on the other hand all old blog URLs should lead to the new location, too. So most links and feeds should continue working properly. People with links to my page, especially those who subscribed the feed, should check if they know about the new locations. For the time being, I’ll keep the rewrite rules intact. But who knows what’s coming…

There’s one more thing I introduced to the blog: parts of the old homepage were already translated into — my very broken — english. I want to expand the english part in the future, so from now on this is a bilingual blog. However, not for the whole content. I like how WordPress keeps the page with the Polylang plugin. I don’t have to translate every single article. But rest assured: the main parts will be available in english, too.

I’d really like to hear what you think about the relaunch. Especially of course, if there still are errors to fix. Does the page look OK? Do the feeds still work for you…?

I took this article from my old CMS in 2015, it wasn’t in the blog until then.

Breadboard in action

Breadboard in action

I haven’t done many microcontroller-projects till now, but more than one of the few projects I did involved controlling LEDs by pulse width modulation (PWM). Doing this for one or more LEDs is a stressful task for a little microcontroller, but if you want to do some other more or less complicated things while keeping LEDs at certain brightnesses is likely to ruin the timings that are used in the PWM. Not to talk about the program code, which gets more and more unreadable if you try to do several different things ‘at the same time’.

For my next project I need to fade some LEDs again, so I was looking for an easier way to do it. The plans include reading from memory cards, talking to real time clocks and displaying text on an LCD, so I’m almost sure that I won’t be able to reliably control the five channels I’m going to use.

The first plan was to use a ready-made chip. I looked around and the best thing I could find was one made by Philips (PCA something, I forgot the number) that can be controlled via I2C-bus. That part is able to control eight LEDs, but apart from ‘on’ and ‘off’ you can set the LEDs only to two different brightnesses. Those are variable, nevertheless, but it would be impossible to light one LED at 20%, one at 50% and one at 80%. Another drawback is that it is SMD-only, and my soldering-skills don’t including working with stuff that small.

So the Idea was to set up a separate controller for LED-fading, that can be externally controlled, ideally via I2C-bus since I intend to use several other devices in my next project that can make use of the bus. So I set up an ATtiny2313 on my breadboard, clocked it with an external 20MHz-crystal and we tried to control as many LEDs as possible…

Pulse width modulation

Controlling the brightness of LEDs by PWM is a common technique, I used it myself in several projects.

The old way

Till now I used to switch on all LEDs that should light up at a level greater than zero, waited till the first of the LEDs has to be switched off, switched it off, waited for the next one and so on. After a certain time all LEDs are switched off, and I start again.

I try to visualize that with a little picture:

In this example, a full cycle of the PWM would need 50 units of time. The first LED is switched on the full time (100%), the second for 40 of the 50 units (80%), the third one for ten (20%) and the fifth one for 30 units (60%). The fourth LED is off (0%). We see that after 50 units of time the modulation starts again.

The drawback of this technique is, that it’s slow. And for each additional channel you try to control, it gets even slower. We tried, but we weren’t able to control more than five LEDs in this way without them to start flickering to a visible amount.

We tried to create an array with all states of the process, so the PWM only would have to loop through the array and set the outputs accordingly. But that didn’t work either, because the used microcontroller doesn’t have enough RAM to store the array.

Thomas’ idea

After some tests that didn’t work out too well, Thomas had a great idea how to implement the PWM. It also works with an array for all states, but the states of the modulation are not displayed for the same time. The first state is displayed for one time-unit, the second one for two time-units, the third one for four and so on. In this way the LEDs are turned on and off more than once per cycle of the PWM, but that doesn’t hurt.

Let’s try to paint a picture again:

So here we see a PWM with eight channels that are able to display up to 64 different brightnesses. Channel one is switched on for one unit of time, channel two for two units and so on. The most interesting thing is on channel five: the LED is switched on for one unit of time, switched off, and switched on again for four units of time.

Lets try a more complicated example — with brighter LEDs, too:

The channels 1 to 8 have the brightnesses 33, 18, 23, 32, 21, 63, 64 and 24.

Brightness 75 on the oscilloscope

Brightness 75 on the oscilloscope

The advantage of this technique is that on the one hand you have to save a limited number of states (six states in the example), and the looping through the states is very simple: state n is sent to the output pins, then we wait for 2^(n-1) time units, then the next state is sent.

Each state represents the bit-pattern that has to be sent during one step. In other words: one column out of the above picture at the start of a new time period. So in this example, we have six states: 01010101, 01100110, 01110100, 11100000, 11110110 and 01101001. The first one is displayed for one unit of time, the second one for two units, the third one for four units and so on…

Using this technique has the advantage that adding more channels does almost nothing in terms of system load. The only time that the algorithm has to do actual calculations is when a new value has been delivered and has to be converted into the states. So using this algorithm, it is possible to show different brightnesses on all free pins of the controller. With an ATtiny2313 that means that you can fade 13 different LEDs while still talking I2C to communicate with other devices!

I2C communication

Speaking I2C is no rocket science, but since one has to do a lot of bit-shifting when implementing it, I took a ready-made library.

The one I used is written by Donald R. Blake, he was so kind to put it under GPL and post it to You can find the original post in a thread called ‘8 bit communication between AVR using TWI‘, and some additions in the thread ‘I2C Slave on an ATtiny45‘.

Thanks for the great work, Donald! And for putting it under a free license.

Since his package seems to be only available as a forum-attachment, and I’m not sure for how long that will be, I included it into the tarball of this project.


You should be able to use this device in the same way you would use any other I2C-slave:

Connecting it

The controller needs to have the following pins connected in the circuit:

  • Pin 1 – Reset – should be connected to VCC with a 10k-resistor
  • Pin 4 and 5 – XTAL1 and XTAL2 – connected to a 20MHz-crystal, using 22p-capacitors against GND
  • Pin 10 – GND – Ground
  • Pin 17 – SDA – I2C-data
  • Pin 19 – SCL – I2C-clock
  • Pin 20 – VCC – 5V

Your I2C-data and -clock lines should be terminated by 4,7k-resistors to pull up the lines. All the other pins can be used to connect LEDs. They are arranged in this way:

  • Pin 2 – PD0 – Channel 0
  • Pin 3 – PD1 – Channel 1
  • Pin 6 – PD2 – Channel 2
  • Pin 7 – PD3 – Channel 3
  • Pin 8 – PD4 – Channel 4
  • Pin 9 – PD5 – Channel 5
  • Pin 11 – PD6 – Channel 6
  • Pin 12 – PB0 – Channel 7
  • Pin 13 – PB1 – Channel 8
  • Pin 14 – PB2 – Channel 9
  • Pin 15 – PB3 – Channel 10
  • Pin 16 – PB4 – Channel 11
  • Pin 18 – PB6 – Channel 12
Talking to it

For my tests I used an ATmega8 as I2C-master with the library written by Peter Fleury. You can find it on Thanks to him for putting it online!

The typical send function looks like this:


I2C-Fader on testboard

Here, you see all LEDs fading at different speeds.

The code running on the I2C-master to generate this pattern looked like this:

Visible PWM

Here you see the signal of one LED fading from 0 to 127. Unfortunately, my oldtimer-oscilloscope doesn’t trigger correctly in the middle part.

This is the code that ran on the I2C-master:


Till now, the device worked in all situations I tested it in. So far everything is fine.

I guess that, compared to the ready-made off-the-hook-parts that controls LEDs via I2C, this module is a bit slow. I can’t see any flickering in the LEDs since they are still switched very fast (about every 6ms, which would result in a 166Hz flickering — too fast for me).


Once again, special credits go to Thomas Stegemann. He had the great idea for the PWM-algorithm, and I am always astonished by the patience he has to show me how to do anything complicated in a sick language like C…

About the license

My work is licensed under the GNU General Public License (GPL). A copy of the GPL is included in License.txt.


To prevent misunderstandings: this says that it's not a mediaeval toilet.

To prevent misunderstandings: this says that it’s not a mediaeval toilet.

This article wasn’t on the blog in 2011. I took it from my old CMS in 2015.

I built this photo booth for our wedding in summer 2010.

I can’t remember where I got the idea, I guess I saw something similar somewhere on the net. After everything else for the ceremony was set I had some time to spend. And this idea…




I had most of the needed material at home. Enough wood, a cloth for the curtain, an unused notebook. And a test circuit I built for my USB-projects. I just had to acquire a webcam, a push button like it’s used in moist rooms (how do you call that in english?) and two fluorescent tubes.

Unfortunately, I forgot to take a picture of the entire booth. It was basically a large box made of oriented strand board, about 2.20m high, 1.20m wide and 1m deep. On one side was the entrance, closed by a thick brown curtain. Inside there was a bank, opposed to it the technology.

Visible there were two simple tubes for the light, a rectangular section with a screen, a small round hole with a lens and said moisture-proof switch.

Hidden behind the wall were an IBM Thinkpad T43 along with a power supply, a Logitech Webcam Pro 9000 and some electronics.

I built this circuit since I didn’t want to make the same USB-interface over and over again on breadboard. It is essentially the same circuit as in my USB LED fader, the USB servo or my Dulcimer Keyboards. An ATmega8 microcontroller and some bird seed for the USB interface, at the other end a pin header to interface all unused pins of the controller on the breadboard.

The box was not built to last forever, so I just had two of the pins connected to terminal cables to the push button.


The circuit is the same as the USB-Servo

The circuit is the same as the USB-Servo

In this project there are two important software components: the photo booth program on the laptop and the firmware on the controller.

The notebook was easy to equip. First I wanted to write a program myself, but after a short search I found something that does exactly what I wanted: Cheese. This is basically a photo booth. You press the space bar, then the program takes four images, at intervals of a few seconds. Simple and perfect.

The microcontroller was not quite as trivial to program, but I already had the solution in the drawer. With a slightly adapted Dulcimer firmware, the circuit behaves just like a simple USB keyboard. I just had to see in the schematic which pins I had to connect to create a space key.

:arrow: In combination with the moisture-proof push button I probably had the only wet room space bar in the world! ;-)

The combination worked perfectly: you go into the box and see the large display. After pressing the button, there were four consecutive pics taken, each with a short countdown.

The pictures end up in a directory and each has the recording time in the file name. That allows to rearrange the pics with a nice one-liner, so the result is a big picture with the full series of four images:


Box of Fools

Box of Fools

I had assured that I would not put the images into the net, so there is only one unrecognizable example. The names of people and the original contents of the bottle are withheld. :-)

The quality has really surprised me. The camera makes really sharp and detailed images, and the fluorescent lights illuminated everything pretty evenly.

The box was used at the wedding-eve party and at the actual wedding. From the eve we’ve got more than 500 images, from the wedding even more than 800. Almost all the guests have found their way into the box, most of them repeatedly. And in packs: on some pictures we see at least seven people at once…

The curtain has proven to be a terrific feature. On many of the pictures you can see that the people did not expect that we can see the pictures lateron… ;-)

We are happy about each image. By means of that box, and above all the spontaneity of our guests, we have truly unique memories of one of the best days of our lives. Thanks again to all who joined us!

I didn’t have this article on my blog in 2009, it came over from my old CMS in 2015.

Test circuit on breadboard

Test circuit on breadboard

This project turns an AVR ATmega8 microcontroller into a LED controller for a matrix of 8×8 LEDs. The controller is acting as I2C-slave, so you can control the patterns to display via this bus (also known as TWI, Two Wire Interface).


For my next project, I need to display number values on seven-segment-displays. I bought a bunch of 4-digit-displays a while ago, now I’m going to put them to a use. They are built with four digits in one case, and 12 pins on the underside. Eight of them are the cathodes of the segments (seven segments plus dot), four are the anodes. One for each digit.

You can imagine these modules as a matrix of four times eight LEDs, as can be seen in the included circuit. I use two of these, so I have a matrix of eight times eight LEDs.

The rows and columns of this matrix are connected to the microcontroller, so it can power them row by row. This has two advantages: at first a maximum of eight LEDs is powered at a time, so power consumption is lowered. And at second you need only 16 pins of the controller to address a total of 64 LEDs.

Driving the LEDs in this way makes them flicker a bit, but the controller is fast enough to keep the flickering way above the level you would be able to recognize.

I could have connected my display modules directly to the main controller of my next project, but I don’t have enough free pins on that. As a further benefit, multiplexing the LEDs on a second controller makes the main program easier to write, since I don’t have to mind the timing. So the solution is to use a cheap ATmega8 as LED driver and use the I2C-bus to tell it what to display.

I2C communication

The ATmega8 has a built-in hardware I2C-interface, so it doesn’t take very much code to use it. Nevertheless, I used a little library that Uwe Grosse-Wortmann (uwegw) published on I only reformatted it a bit to make the code resemble my style. It is well commented, but the comments are in german. Since only one global array, one init-function and an interrupt service routine are used, it shouldn’t be too hard for english-speaking people to figure out how it is used.


On the other end of the communication, I used the excellent Procyon AVRlib written by Pascal Stang. You can find it here.

The Circuit

The Circuit

Note: the buffer doesn’t contain any numbers that should be displayed on 7segment-displays. At least not in this example. It only holds bit-patterns.

Displaying numbers

If you solder 7segment displays to the unit and intend to display numbers or characters on it, you need to define them on the master-side of the bus. I didn’t include the definitions in this library because I want the master to have the full flexibility of displaying whatever it wants to, even if it are no numbers.

However, if you are going to use 7segment displays, definition of the numbers still depends on how you soldered them to the controller. I don’t know if the pin-outs are commonly standardized.

To give an example of how you would implement this, here is a fragment of code that defines hexadecimal numbers for usage on my displays:


Till now, the device worked in all situations I tested it in. So far everything is fine.


I’d like to thank the authors of the libraries I used: Uwe Grosse-Wortmann (uwegw) for the I2C-slave and Pascal Stang for the Procyon AVRlib.

About the license

My work is licensed under the GNU General Public License (GPL). A copy of the GPL is included in License.txt.


This text wasn’t part of the blog in 2009, I copied it from my old CMS in 2015.

My etching tank

My etching tank

Somehow I resisted to etch my own printed circuit boards for years. As I now know, I had no reason: it’s not as hard as I thought it would be. Having the right equipment helps with many things, so it does in this case. After having evaluated the whole process, one of the hardest things is to take off the rubber gloves after handling the chemicals…

Preparing the layout

One of my first own layouts

One of my first own layouts

Before creating the board, one has to create a proper layout from the circuit.

Many people use Eagle CAD for this job. It’s a great tool, but the free (as in beer) version has the handicap that it can only do layouts for half euro cards (that’s 8x10cm). You can do a lot of things on that amount of space, but at least for my Dulcimer project I needed more.

Meanwhile, I got used to KiCad. The usability is even worse than Eagle’s, but if you take your time and if you are kind to the program, it gives nice circuits and board layouts to you in return. And the killer advantage: it’s free software.


Exposing the photo sensitive material is a bit tricky. I tried several methods, and I think I reached what I consider to be the optimum.

First the layout has to be printed. I made my first tries with simple paper, printing with my Laserjet 5. After not seeing any results on the boards, I tried coating the paper with oil to make it more transparent. Using a nitraphote lamp it would probably work with an exposure time of 50 minutes or so, but that seemed to be too long in my opinion. I got really good and quick results with overhead slides. With my first tries, I put two prints on top of each other, later I found that to be unnecessary, one layer is enough.

There’s even more choice with the source of light. What didn’t work at all was a 500W halogen lamp. Other people had more luck with that, but I guess that mine has a safety glass that blocks UV light.

A better solution would be the 250W nitraphote bulb that I acquired just for this reason. It’s a standard bulb with an E27 thread, but it delivers more UV than a normal lamp would. Unfortunately, 250W tend to be very hot after a while, and I almost ruined my kitchen lamp trying to expose through a layout printed on paper. After all, using the overhead sheet made really good results after an exposure time of 10 minutes in a distance of 15cm.

The best solution seems to be a facial tanner that I bought for 1,50 Euros — about a quarter of what I paid for the nitraphote lamp. It’s a Philips HB170, it has four tubes with 15W each. I turn it on for a few minutes, so the tubes are pre-heated. Then I put it face-down on two pieces of wood that are 3cm thick. Beneath it the stack consisting of the photo sensitive board, the printed layout and a glass plate. I turn the tanner on for two minutes and get great results — without risking to set the room on fire.


My first PCB

My first PCB

Surely, you can etch your boards in a simple lab dish, it shouldn’t affect the results much. But I didn’t like that method already on my first tries. Especially since it is everything but easy to maintain the temperature in the etching solution to be arount 50 degrees Celsius.

So I built my own etching tank. It was the cheapest solution since I already had some of the parts from my fish tank hobby. The etching tank consists of:

  • some sheets of glass
  • silicone
  • aquarium heater
  • aquarium glass thermometer
  • aquarium air pump
  • aqua-curtain air diffusor
  • air hose
  • parts of a cable channel (?) that hold the air diffusor and the board in place
  • a plastic container to put underneath the whole thing, since this is the first time I ever glued glass…

The tank holds about one liter of etching solution (natrium persulfate). The size fits quite exactly for one full euro card (16x10cm), the process takes about 10 to 15 minutes.

I am more than happy with the results. I didn’t make any detailed tests yet, but till now I found all the fine structures on my boards that I wanted to be there.

I didn’t have this project on the blog in 2008, I copied it from the old CMS in 2015.

Looks like the day it was made -- except for the cable

Looks like the day it was made — except for the cable

A ‘hammered dulcimer’ is a musical instrument, its german name is ‘Hackbrett’. But you also can loosely translate ‘Hackbrett’ to ‘hackboard’, which I think is a great name for this kind of keyboard. A funny fact on the side is, that the name ‘Dulcimer’ originates from the latin ‘dulce melos’, which means ‘sweet sound’. If you ever heard someone type away on a Model M, you know why I chose this name… ;-)

A computer keyboard can be a very personal utensil. Especially if it is an extraordinary well built one, like for example the IBM Model M. The Model M design dates back to 1984, but it still has many fans even nowadays. It came with the usual keyboard connectors. First the old 5-pin one, later a PS/2 plug. Unfortunately is that, at least to my knowledge, they never released a version with USB.

A friend of mine knew that I already had built other USB-devices, and one of them even acted as a keyboard (it isn’t really a keyboard, but that’s a different story… ;-) ). He is a big fan of the Model M, so he asked if I could put new life in one of his old keyboards, which had a broken circuit inside. And this is the result…

Hard- and Software

A first prototype

A first prototype

The main part of a computer keyboard circuit is the key matrix. You can imagine it as a number of keys, placed on a raster of horizontal (rows) and vertical (columns) wires. In the case of a Model M keyboard, we have a matrix of 8×16 lines. Eight columns in 16 rows, or the other way around, depending on how you look at it. Each key is connected to one column and one row. If you press the key, it will connect the column and the row on it’s crossing of the lines.

Connected to this matrix is a keyboard controller. That’s a chip with a number of I/O-lines to detect the state of the matrix, and on the other side an interface that enables it to talk to the computer. Oh, and not to forget: it also has three output lines to drive the LEDs for Num-, Caps- and Scroll-lock.

What I did in this project is, that I dumped the keyboard controller chip and its circuit, and replaced it by an ATmega32 and my own circuit. The ATmega scans the matrix for keyboard activity, controls the LEDs and talks to the computer.

For further convenience, I added a boot-loader. With that, it is possible to update the keyboard’s firmware without disassembling it, and without the need for a dedicated programmer.

Other Hardware?



As mentioned, the controller in this project is just connected to an ordinary keyboard matrix. You can find this kind of matrix in all kinds of keyboards, from key-telephones over good old hardware like the Commodore C=64 or the Schneider CPC, keyboards with non-PC-connectors like those made by Sun, to modern hardware that could need a few more features.

Till now, I just made a PCB layout for the IBM Model M, but I intend to modify at least a Sun keyboard. In order to do that, I expect having to refactor the key-scanning, since the key-matrix is not 16×8. The positions of the keys on the matrix will be different, I’ll have to re-engineer that. And of course, I’ll have to make another PCB.


Powered by Kicad

Powered by Kicad

At the moment, the keyboard should be able to do everything that the average off-the-shelf-keyboard can do. But there are many features that are possible, regarding the fact that the ATmega32 is absolutely bored till now. You can think of ‘magic keystrokes’ that turn some hidden features on or off, like for example:

  • send complete phrases on one keystroke
  • ‘autofire’ feature on keys that don’t repeat normally, for example Alt+F4
  • change keyboard layout without reconfiguring the computer
  • turn bouncing keys on or off, to annoy other people using your computer
  • random caps lock function
  • use arrow keys as mouse, without having to include a special driver in the OS.

With a little tweaking on the hardware side, there should be even more possibilities:

  • turn the oldtimer-keyboard into a supermodern wireless bluetooth one
  • implement keylogger-funktionality, using for example an SD-card
  • include an USB-hub into the keyboard

If you are just a little like me, it won’t take you much brainstorming to come up with own useful — or even better: useless — ideas. ;-)


Connect the keyboard to the USB-port. All LED should flash up to indicate that the device is initialized.

Then you can use the keyboard as always. If additional features get implemented, you will be able to use them in their respective ways.


I don’t know if and how keyboard manufacturers face the problem of ghost keys, I didn’t take special measurements for this. I hope that the engineers at IBM distributed the keys on the matrix in a way that minimizes this problem. Don’t misunderstand: I haven’t experienced that on this keyboard, but I know that it’s a common problem on key-matrixes.


Modern oldtimer

Modern oldtimer

I’d like to thank Objective Development for the possibility to use their driver for my project. In fact, this project wouldn’t exist without the driver.

I took great inspiration from Spaceman Spiff’s c64key, this software is based on his ideas.

Further credits go to xleave, who etched the PCB for me, and also answered many stupid questions about electronics I had during the last few years.

And of course I’d like to thank FaUl of the Chaostreff Dortmund who gave me the idea for this project.

About the license

My work – all contents except for the USB driver – is licensed under the GNU General Public License (GPL). A copy of the GPL is included in License.txt. The driver itself is licensed under a special license by Objective Development. See firmware/usbdrv/License.txt for further info.


See also…

  • – dedicated to IBM Model M
  • RUMP – practically the same project, a parallel development
  • Geekhack – protoboard version, based on Dulcimer

The module

The module

Well, the name is a bit too big for a project as little as this, but I couldn’t think of anything better at that moment.

It is a little circuit you can use on your bread-board. Most microcontroller-projects run at 5V, but cheap power supplies lack this setting. So the first step in building a circuit on a bread-board is building the power supply. Over and over again.

This is not much fun, so I built this circuit to use it ‘en bloc’. After building it, I thought of inserting another diode to prevent wrong connection to the power supply. Too late for me, but you should put one in if you build one of these.

I created the label using Eagle, even if it is not derived from the circuit I used. Anyway: It’s in the downloadable package.


The circuit

The circuit

At first I didn’t want to release this to the public. But after finding a link to a similar project in the Make Magazine — it’s on Instructable, and a detailed step-by-step guide to a circuit like this at SparkFun I did.

I just can say: I did it before I saw the other articles. :-)

I suppose the idea is simple enough for anybody to have it…


See also…

  • SparkFun – detailed description of a similar project
  • Instructables – step-by-step-description of a similar project

This article hasn’t been in the blog until 2015, I took it from my old CMS.

The new adapter

The new adapter

The common programmer-adapters for AVR-controllers come with a ten-pin connector that is connected to the target circuit. Why the thing has to have ten pins, I don’t understand. Four of them are connected to the ground, and one isn’t connected at all. So effectively there stay six pins that are really solving a purpose.

The problem

When developing a prototype on a breadboard, it is not really possible to connect the ten-pin connector on it. I built myself some kind of an adapter cable to connect every pin onto the board.

As you can see, it’s really ugly and not quite stable. Plastic parts are getting weak during the soldering-process, and they are not really stable.

The solution

The adapter at work

The adapter at work

To make it a bit more elegant, I made this little tool. I printed the pin configuration using Eagle CAD. You can find the required file in the end of this page. So I just have to consider the controller’s documentation for the pin-settings, not for connecting the ISP-adapter to it.

Beneath the printed cardboard, there is a simple circuit board. Otherwise there is a ten-pin connector for connecting the ISP-adapter, and a six-pin connector that is attached to the breadboard. I pressed the pins until they are almost fully beneath the board, so it fits tighter to the breadboard.

Oh, and the wires on the board’s lower side are painted. And not soldered really niceliy, but the mainthing is: it works!


The assembled clock

The assembled clock

In Germany, the official time is transmitted in a signal called DCF-77. You can find many descriptions of the signal format on the internet.

The Binary DCF-77 Clock is a simple device to receive and decode the signal and display the current date and time in binary form. The signal is received in a stock DCF-77 receiver module, decoded with an ATmega8 microcontroller and displayed in binary form on an array of LEDs. This array consists of for lines with eight LEDs each. The ATmega8 is not able to control 32 LEDs at once, so an SAA1064 module is used which is connected via I2C-bus.

The time should be displayed in several different binary formats, the format can be selected with a simple button. The formats will be described later.

The distribution contains the firmware for the controller, the schematics, the documentation and a copy of the GPL license.

Building and installing

The circuit is not too complicated

The circuit is not too complicated

The installation is described in the documentation.


Connect the device to a DC power source with 9V. As long as no time has been decoded, a running light is shown on the output LED array. The single DCF indicator LED should start flashing to indicate that a signal is received. It is set to on when the input signal is high, and switched off if the signal is low. So you should see it flashing with one flash per second, each flash being 100ms or 200ms long.

If the signal is received correctly, after about two minutes the clock should be able to tell the correct time.

Reading the time

The different modes

The different modes

The time and date are displayed in seven different styles. You can select the style by pressing the button for a while. A pattern of lights indicate which mode is selected, you can read it as a binary value.

Mode 1: Time as binary

This simply displays the hours, minutes and seconds as bytes, one after each other. The fourth line of the display stays blank.

Mode 2: Date as binary

This is like the previous, with the difference that it displays the day of the month, the month and the year in the first three lines. The last line shows the day of the week, monday being a 1, tuesday a 2 and so on.

Mode 3: Time as BCD

This shows the time as binary coded digits (BCD). The first line displays the hours. The left four LEDs indicate the 10-hours, the right four LEDs indicate the 1-hours.

In the same way, the second and third line display the minutes and the seconds.

Mode 4: Date as BCD

This is like the previous mode, but the date is displayed.

Mode 5: Time as BCD (vertically)

This shows the time in a BCD-form as described in mode 3, but the BCD-values are put vertically next to each other. So in the first two colums you can read the hours, the third column is empty, the fourth and fifth columns show the minutes, the sixth is empty and the seventh and eighths indicate the seconds.

Mode 6: Date as BCD (vertically)

This is like mode 5, but it displays the date.

Mode 7: Unix timestamp

This is probably the least human readable format. It shows a 32-bit value of the seconds since january 1st, 1970. :-)

Demo mode

If you connect the clock in a place with a poor DCF-reception, but want to demonstrate the functions, you can use the demo mode. To toggle this, you can touch and hold the button for about five seconds. Afterwards, you can switch through the different display modes. The time displayed will stand still, so this can be used to explain the display modes without a hurry.

Switching to demo mode is indicated by all LEDs flashing for a short moment. Leaving demo mode shows an empty rectangle for a short moment.


I didn’t expect the DCF-signal to be so easily disturbed. In my case sometimes there is no usable signal left when I put my notebook with WLAN next to the clock. Fortunately, the time will be counted further until the next ‘correct minute’ is received.


I’d like to thank Michael Meier, who developed and published a much more sophisticated clock on his site. The SAA1064-stuff and the routine to calculate the Unix timestamp are based on his project. You can find it on his page.

And once again I’d like to give special credits to Thomas Stegemann for help with the C language.


This project is licensed under the GNU General Public License (GPL). A copy of the GPL is included in License.txt.


This text hasn’t been in the blog in 2006, I copied it from my old CMS in 2015.

... and you'll never have to search for your cursor again!

… and you’ll never have to search for your cursor again!

The USB-Servo is a device to control a servo via USB. A servo is a motorized device that is commonly used in remote controlled cars and planes. I built this device to activate a toy puppet. The puppet has a button on its bottom, if you press the button the puppet collapses. When the computer is able to press the button, I can use the puppet to signal information like someone’s online-state in the Jabber-network: when my friend goes online, the puppet stands up, when he logs off it collapses.

Servos are connected with three-wire-cables. A red and a black one for the power, and a yellow one for the signal. Power has to be between 4.8 and 6 volts, so the 5 volts from the USB-port is in the range. The signal doesn’t take much current, so you can connect it directly to the controller. The angle of the servo is controlled with pulse width modulation (PWM). It gets a signal of about 50Hz (one pulse every 20ms), the length of the pulse tells the servo the angle to adjust.

A problem that I didn’t really solve is the power consumption: I don’t know the current that runs through the motor. It seems to be low enough not to cause any problems, but I don’t know how high it will get when the servo is blocked. YOU HAVE BEEN WARNED, I don’t feel responsible for USB-ports catching fire… :-/

The circuit contains only a few standard components. There's no special USB-chip involved.

The circuit contains only a few standard components. There’s no special USB-chip involved.

There are three parts included in the distribution: The firmware for an ATmega8 microcontroller, a commandline-client that can be run under Linux, and the circuits needed to build the device.

This project is based on my USB-LED-Fader, which itself is based on the PowerSwitch example application by Objective Development. Like those, it uses Objective Development’s firmware-only USB driver for Atmel’s AVR microcontrollers.

Objective Development’s USB driver is a firmware-only implementation of the USB 1.1 standard (low speed device) on cheap single chip microcomputers of Atmel’s AVR series, such as the ATtiny2313 or even some of the small 8 pin devices. It implements the standard to the point where useful applications can be implemented. See the file “firmware/usbdrv/usbdrv.h” for features and limitations.

Building and installing

The installation is described in the documentation.


Connect the device to the USB-port. If it isn’t already, the servo will move to the 0-position.

Then use the commandline-client as follows:


  • angle: The angle you want to set the servo to. 0 is full left, 255 is full right.


Get the status of the servo

This will tell you the angle the servo is currently put to.

Set a new angle

This sets the servo to the angle 23. 0 is full left, 255 is full right, so with 23 the servo will be almost on the left side.

Test the device

This function sends many random numbers to the device. The device returns the packages, and the client looks for differences in the sent and the received numbers.

Demo application xservopointer

Behind the scenes

Behind the scenes

This is a pure fun thing, nobody will need it. That was reason enough to write it…

To use it, you have to position the servo centered above the screen (with a little tweaking in the source, you can change that position). Then, you attach a pointer to the servo and start the application.

You’ll never ever have to search for your mouse cursor in the future. The pointer on the servo will always show you where to search.


The main drawback is the mentioned power consumption. I tested it with my servo on my notebook, it is not sure to work on other systems. THIS MAY BE HARMFUL FOR YOUR COMPUTER, and nobody but yourself will be responsible for any damages.

Another, not so big problem is the crude implementation of the PWM. I got the timing-values by trial and error, and they might not fit on your servo. On the other hand, I think that servos should be interchangeable. But this is my first and only one, so I can’t say anything about that.


I’d like to thank Objective Development for the possibility to use their driver for my project. In fact, this project wouldn’t exist without the driver.

About the license

My work – all contents except for the USB driver – is licensed under the GNU General Public License (GPL). A copy of the GPL is included in License.txt. The driver itself is licensed under a special license by Objective Development. See firmware/usbdrv/License.txt for further info.