Results tagged “Personal”

Oh wow...

Who would have thought, that there will ever be another posting at this blog after such a long time of silence. Well, now the silence is broken again, at least for this post and hopefully some more in the future again.

So what was the main reason for the long silence? To make it short: the Repair Café in Graz. After the initial successes it really took of like no one of us expected. By end of Jan 2017 we held our 22nd Repair Café event in Graz. I'm pretty that our location organizes the biggest events in Austria with 145 repair attempts during the last event alone. While this keeps being exciting all the time it also takes quite a lot of time to organize one event and do all the behind-the-scenes stuff in between. And that's mainly the reason for my reduced online presence. We also helped several other locations in Styria to start their own Repair Café events and I'm always trying to be present at as many as my tight schedule permits. Furthermore we got in contact with officials and many other initiatives working on social and environmental topics.

Were there any other major changes apart from the Repair Café? Sure, too many to count. But for a glimpse and completely unsorted:

  • focus changed from computer/programming to repairing and hardware tinkering.
  • blog webserver has been migrated to new hardware and hosting platform, backend engine updated and upgraded to HTTPS
  • home heating system upgraded to include a proper buffer tank and access to the underlying control logic (squeezing out another ~30% efficiency compared to the state when the plumbers considered it finished)
  • at daily job: changed positions and project assignments at my employer a few times, always trying to not let loose on quality and security issues on each assignment

Well, that's it for now again. I hope I find the time to post more regularly in the future. Some interesting topics are already circling in the back of my head.

Update: I just realized that the last activity on this blog had been EXACTLY 3 years ago, almost to the hour. This was not planned but is a nice coincidence :)


One of my personal guidelines with computers and IT is that if I accidentally receive credentials or access possibilities to other people's accounts I do not take advantage of it without consent of the owner.

Usually I get access to such information because I'm fixing computer and software problems for friends, relatives and acquaintances. But from time to time I receive account information which I didn't subscribe or enter. In the past few years it started slowly but became more over time and shown a very specific pattern: it all involves one of my mail-accounts and it seems that there is somebody out there who has a very similar mail account with only a single letter difference. And this person seems to regularly create accounts and get its own mail-address wrong. Several attempts to notify this person or get into contact were unsuccessful. At one point I even got my hands on a phone number but I never reached anyone with it.

There are still too many services and websites out there which do not require a confirmation click via email but just create an account without checking if provided mail-addresses are correct. I wouldn't mind a single mail which I don't respond to and be through with it but life isn't that easy.

I'm now pretty much fed up with the constant notifications, reminders ("...please come back to XYZ...") and mails involving such erronous subscriptions to services and websites. Especially Facebook seems to be pretty stubborn and manages to escape my filters constantly but also a pile of gaming-accounts and logins to some other websites have accumulated.

In a short while I'm going to shut down all the accounts using my mail-address. For that I'm going to request a password-reset, log in to those accounts and deactivate them (if possible). I'll try to keep information sniffing at a minimum but if I see additional possible contact info maybe I'll do another contact try. Nevertheless all accounts which show no further activity (e.g. another credential reset by the "other" user) for some time then will be shut down permanently.

Gah, I hate to do this but you left me no choice...

Update 2014-03-01: Deleting a Facebook account is nothing short of complicated. All that Facebook offers (more or less) directly available is the possibility to deactivate your account. But this is in reality just snake oil as your account still exists and allows further logins and data profiling and just hides almost everything from others. To really and permanently delete your account one has to dig deep, and I mean really really deep, in Facebooks help and info pages to almost accidentially trip over this link:
With this link you can tell Facebook to really delete your account and all associated data which they at least promise to do after a 14 day cooldown period where you can still decide to change your mind. Which I won't do as I didn't even sign up myself in the first place...


Sorry again for the lack of updates. There have again been several important personal things to deal with which took their time and did not leave enough spare time for something else. Among these were (and still are) things like helping my brother and his girlfriend moving to their new home or trying to organize and compare offerings for a thermal energy storage upgrade of the heating system in my home.

But for me personally most important was the unexpected gain of popularity and need for communication related to the RepairCafé. This has been caused by a full-page newspaper article that was published a few weeks after our second RepairCafé. After that article there have been numerous contact requests and inquiries. Apart from simply explaining details of the RepairCafé this also involves networking and bringing people in touch with each other for cooperative intermediate repairs. Furthermore we're working on enhancing our online presence and planning future events.

We decided for now on an RepairCafé event every other month, with Nov. 23rd being our next date. Additionally we're planning a coop-event with the environmental department of Graz the day before. As this coop-event will take place at a shopping center it will be a large public appearance and there are numerous things to prepare for that. One of the things is to organize some helpers which can be present there and cover the whole day as well as finishing up our homepage and preparing some material to show at the event.

Bear with me, I'm trying to come up with more postings but time is currently a rare gem again.


Last Saturday the second local RepairCafé took place. While the first RepairCafé had a slow start and not many repaired goods to present afterwards this second time was a huge difference.

This time was a larger group of helpers and interested people and also much more success in repairing stuff. There also was a short visit by a journalist from a local newspaper and maybe an article will be written. The success stories range from walking sticks on the simpler side (took only seconds to fix) to replacing a dead battery in a MP3 player with a transplant from another broken player. Radios, remote controls and cameras have also been taken care of and are now also in a completely usable and working state again.

I'm really happy how this initiative has developed and in my opinion it is a great success so far. I'm very thankful for all the people who helped me to bring to live and hope the pace and support will keep up and spread even more.


There hasn't been much activity here in the blog in the recent weeks and to be honest there also hasn't been much tech-related activity from my side which would be worth commenting. In fact my computer has been on standby pretty much the whole last week.

The reasons for this are diverse and include stuff like babysitting, assisting with moving and an increased stress-load at work which left me exhausted quite some evenings. Furthermore the extreme temperatures in the past weeks also dampened me down and in sum my motivation for anything has been just high enough to attend some evening activities and make sure that my place doesn't get too messy.

But temperatures are going down again and with a bit of luck the period between individual posts on this blog will shrink as well.


The last few weeks I've been busy organizing a local RepairCafé. A RepairCafé is an event where a group of private persons meet and try to fix broken everyday stuff. Everyone is invited to visit and take broken items with them to repair them together with the people present, watch them (and learn) repairing the goods or just have a nice chat.

The idea for organizing a RepairCafé came to me several weeks back when I read about it somewhere on the Internet. Shortly after that I visited the Barcamp Graz 2013 where I had a talk with a group of other interested people and decided to take on the task and try to set up such an event in the near future (see also this post from May).

Well, some meetings and many new connections and contacts later, last Saturday the first RepairCafé took place at the Traumwerk open shop together with a clothing change event organized at the same time. We chose that event to attract some more people than we could reach independendly from each other and I think (at least from the RepairCafé position) this worked quite well.

There haven't been so many people who took the chance and brought in broken stuff but there was a bunch of people who just heard of the event when they were already there. And it seemed to be an interesting idea to most of them so that we were often asked how often this took place or when the next event is planned. Not too bad I guess.

Currently I'm finding a date for the next public meeting to have a short recap on Saturdays event and plan or discuss our future steps.


You may remember that about half a year ago I had some thoughts about how to change the photo hosting platform for this blog. Up to that day I used Flickr when I recognized that they had changed their licenses and external linking policy. The new conditions in the license and policy did not allow embedding of photos from external locations anymore. Since that time I've been using a workaround (by embedding Google Photo images via the legacy Picasa Web albums interface) for the images in my blog postings.

Well, it seems that Flickr/Yahoo has revised their decision again. I guess it has something to do with their tries to get back into mainstream again and is very probable connected to their incredible 1TB Flickr relaunch.

But not only do they allow external embedding again, they even reenabled that functionality at a much more accessible location than before. Via the "Share" symbol, which is available at any location within Flickr, you can immediately access the sharing/embedding menu for photos or albums on Flickr.

For me personally this makes the decision not easier. Back in November I began using Googles services for photo hosting which allows embedding but is not really straightforward as it requires the workaround I mentioned above (via the Picasaweb-interface) to retrieve the sharing HTML code. And that code wasn't 100% correct as it contained some invalid links which I had to fix manually.

I guess, I'll switch back to Flickr again for new albums in the future but continue to use Google Photos/Picasaweb for the ones which I created there. It's nice to see that there are still some companies out there who reconsider past decisions and revert them. Enabling integration of provided services at independend locations instead of locking in any data/files/information the users provide is in my opinion a key factor to make it possible for others to leverage the services to otherwise impossible solutions.


I don't exactly know why but in the past month I somehow did not find the time and motivation to create a proper post but several things have happened and this is just a quick summary over them all.

This may or may not be followed by individual posts on each single subject. I hope that I get around to that but no guarantees. So lets get it on.

On the LED Cube front I hinted on a "recent technical acquisition" in my last post on that subject. Well, this acquisition is nothing less than a full blown digital oscilloscope. YAY. It took a few weeks to decide and also a few days to find a suitable distributor but now I'm a proud owner of an Owon SDS7102V 100MHz digital scope.

The next notable gadget I (finally) received is the long-awaited Pebble watch. Within two days this little gem became the most notable thing which I didn't know I have been missing as companion for my phone for a long time. Despite some bad reviews on other places, I've been expecting an "extension" to my phone's display and that's exactly what I got. No need to long for the phone in my pocket anymore when there's something up. Within a second I know what's up and can still decide if I should take out the phone or just ignore a received spam mail until later. Furthermore much less distraction for other participants in case of meetings. Currently I'm mainly using this Star Trek inspired watchface for displaying the time and I also have installed Pebble Notifier on my phone to forward notifications of some selected applications to the watch, even if these aren't natively supported by the Pebble app itself. Great tool. And it's quite exceeding the expected runtime, my current record is set at 10 days without recharge (and that's before I discovered the option to not turn on the backlight when there's enough ambient light).

I also attended several events. The first one was the Grazer Linuxtage which is a mixture of project exhibition and series of lectures all centered around Linux. Like two years ago, where I also attended, the lectures were quite interesting and I hope that I find some time to try out or have a deeper look at some things I noted down during the lectures. The only negative point of the event is that the place is getting much too small for this event. Many of the lectures I attended that day were so crowded that late-comers could not even enter the lecture hall anymore. I hope that this changes in the future.

One followup-event which I got notice of on the Linuxtage was a (Linux) Show and Tell at the realraum Graz. At this event people showcased their favourite or special Linux tools, i.e. special use cases and capabilities of SSH. Before that event I thought that I'm not that bad with the Linux console, but I've been pretty much floored by the experts there. Which is not necessarily as bad as it sounds because at least I understood everything the guys were talking about :)

The barcamp Graz was the next event which I visited. That time this was a three-day long event and luckily I could be there all days. A barcamp is like a conference just with the difference that every attendand is a participant and presenter. The detail topics of the sessions are not planned before but are decided on and ordered by all participants at the start of each day by themselves. It was a very interesting experience and made it possible to have a look at many different topics from many different points of view.

One special thing I took away from the barcamp was the idea of a Repair Cafe. This is a privately organized meetup of people to just repair broken everyday stuff and get some more lifetime out of it. It is some sort of counteraction against the creeping planned obsolescence of things. We were several people who were interested in that idea and it seems that Brigitte and I are currently the ones who are further driving the idea. Maybe there is the chance of a permanent recurring event where everyone helps everybody :)

Since Google Reader is discontinued by July 1st I've been looking for alternatives for some time now. I had a long look at Feedly but in the end didn't decide on it because it does not have a clean web interface but only works through native apps or browser plugins. So I chose to install Tiny Tiny RSS on my own. During installation I just hit a roadblock or two. In fact, my problems were that the minimum requirements for TT-RSS were PHP 5.3 and special server modes (e.g. no php_basedir/open_basedir restriction) while my hosting provider only offered PHP 5.2 with active open_basedir restriction. After trying to find an alternative to that (which wasn't successful) I decided to go the hard way and back-port and refactor Tiny Tiny RSS to work with my hosters restrictions. It took a few hours but finally I had a flawlessly running TT-RSS despite the settings of my hosting. I will post the changes here as soon as I come around to create a proper patchfile (maybe that will happen in the nearer future).

And finally last weekend I had the honor to be invited to my cousins wedding. It was a very nice and private wedding with (almost) only the closest relatives invited. Thanks for that and best wishes!


Last time I hinted that I finally put together the full 3x3x3 cube.

From Building LED Cube

From another perspective it is better visible that I changed the soldering process a bit from the first layer compared to the others.

From Building LED Cube

The top layer has some brownish residues on the bottom of the LEDs. These are traces of the soldering flux which burnt into the LEDs bases when I kept the soldering iron a tad too long close to them. For the other layers I left out the additional flux and also tried to keep the heating phase as short as possible on the pins. The result is that the two lower layers have clean LEDs. But two of the joints broke again and had to be fixed during the first test in the breadboard so they don't seem to be as stable. Another thing I should remember for later is that I should sand the iron wires next time before soldering. They look a bit dirty in the cube, swallow some light and probably are harder to solder that way too.

Nevertheless the finished cube allowed some cleanup of the crowded breadboard by reducing the required traces to only a single "bus" and relocating the layer control. Furthermore the "bent wire" connection for the planes (visible in the photos from last time) have been replaced by croco clip wires for a higher reliability and flexibility.

From Building LED Cube

And powering up the cube and testing all LEDs for correct functionality shows everything working as expected and its whole glory.

From Building LED Cube

The observant reader may have noticed that the circuit of the layer logic has changed since its last appearance. This is the intermediate result of many hours of playing working with my latest technical acquisition. But more on that in a later post.

As for the grid construction of the cube in general: I doubt that I could solder the big 8x8x8 in the same manner as I did the small cube. With the small one I initially soldered the three 3x3 layers individually and then put the layers together by first attaching the corner connections and then the inner leads. As I could do this by hand it just worked but in the height of 8 layers stabilizing one (unstable) 8x8 layer for soldering and keeping the distances exact is nearly impossible. So I need some sort of metal or wooden rack during soldering but I'm not sure yet how it should be constructed and used. There are some ideas floating in my head but I have to think more about those and probably test some of it.


A little more than a month ago I failed soldering the iron wire for the first LED grid. At that time I didn't know what went wrong. Well, in the meantime I found out, adapted my approach and succeeded in soldering the first layer.

What went wrong? I purchased annealed iron wire instead of a plain (galvanized) one. Seems that I didn't recognize that there were two different kinds of iron wire available at the store and (of course) I picked the wrong one. Apparently solder does not stick to untreated annealed iron wire as the surface is pretty much fully oxidized so that solder doesn't stick without more aggressive solder aids like acidic solder flux. Annealing also makes the wire softer which I don't appreciate as the cube should be stable and sturdy. So the usage of plain galvanized iron wire is not only the solution to my soldering problems but also the preferrable solution anyway.

The difference of the wires is obvious once you know of the types. The annealed one is on the left:

From Building LED Cube

Using the new iron wire the first layer was soldered together quickly

From Building LED Cube

I haven't been honest in the beginning of this post. Meanwhile I not only soldered a single layer but all three layers of the 3x3x3 cube and put them together on the prototyping board. First tests in action were successful and promising. But more on that and why I doubt that I can build the 8x8x8 cube in the same procedure (horizontal layer by layer) next time.


For my LED Cube Project I already hinted that I may use an old ATX power supply as repurposed power source. In the past two weeks I found some evening time to work on that subproject. The plan was to use an old ATX power supply which I had left from old computer parts and equip it with banana sockets to make the common PC voltages easily available to use for my electronic projects. This repurposing seems natural as the voltages available from PC ATX power supplies are the same which are most commonly used in hobby microelectronics (3.3V, 5V, 12V). Additionally these devices provide a high stability and current capacity as they have to offer those requirements for stable computer operations which demand extremely fast switching load capability and still let the PC rely on a stable supply.

I found several resources on the internet which explained how to refit an old ATX power supply to offer nearly stabilized Lab Power Supply capabilities. It seemed not too hard and I decided to use the information from that descriptions to add the banana sockets, status LEDs and the switch directly into the metal case of the power supply itself. From the pictures on the internet that seemed possible without much problems.

Since that is now finished and (surprisingly?) working as expected I'd like to share my experiences.

Update 2013-03-08
I did not use fuses for the power lines when modifying my PSU. In theory the PSU should turn itself of in case of shorts but there may still be the possibility for very high currents during a short period of time. It is highly advised to add properly sized (check the rated max current) fuses to each supply current line!

This was the old power supply which I could scavenge from a retired computer.

From ATX Power Supply Repurpose

From the outside it looked pretty innocent. During my preparation research I learned that ATX power supplies have some characteristics which have to be considered during modification and utilisation of the electronics.

  • altough there is a standard for ATX power supplies, some supplies do not meet certain requirements (esp. behavior in edge cases)
  • activation is pretty easy, just connect PS_ON (green) to GND
  • to provide stable voltages many power supplies require a certain minimum load
  • power supplies are not guaranteed to be short-safe
  • a signal on the PWR_OK line does not guarantee a stable power source (especially on cheap supplies)
  • stored leftover energy in the power supply can be lethal, so extreme caution is highly recommended

To find out the exact behavior of my power supply I tried out various connectins and measurements directly on the ATX connector. As the side of the supply told it was capable of up to 22 Amps on the 5V line so I've been already very careful here and checked the ATX connector layout several times to prevent accidents and violent reactions within my hands. I've been a bit nervous during that measurements that's maybe also the reason why I forgot to take photos of this. Well, I learned following from these tries:

  • PS_ON is really easy to control
  • my power supply also requires a minimum load
  • the PWROK signal works as expected
    • no PWROK without load
    • PWR_OK turns off again if load is removed later on
  • the standby lines keep their voltage quite some time after disconnecting the supply from main power, indicating a high internal capacity

Before I decided to rip open the guts of the supply, I left the box sitting unconnected for two days to be absolutely sure that I'm not suprised by some leftover charge. After two days the box was stripped naked.

From ATX Power Supply Repurpose

The open supply made me realize some additional but unexpected problems. Firstly there was much less space available for additional wires.Secondly the space on the front panel was obstructed by heatsinks. Therefore it would be a pretty limited working area and I also had to place the banana connectors between the heatsinks. Luckily at least all cables were properly colored and even correctly annotated on the PCB. So I continued and marked the locations of all additional components on the frontplate.

From ATX Power Supply Repurpose

During my tests on the breadboard I realized that load resistors (I used two 5Ohm/5W ceramic resistors in serial) get quite hot when connected to power, so I decided to not have them dangling around in the box but clamp them tightly on one of the heatsinks. Checked, that this solution also fits in the tight space with the banana connectors and wires in place and continued to the next step: drilling the holes in the front plate.

From ATX Power Supply Repurpose

I chose the size of the holes by measuring the dimensions of the banana sockets, LED covers and the switch with a caliper. After that I drilled smaller ~1mm holes to better be able to control the position during drilling and re-check the dimensions and gaps between them. During that I had to reposition the holes for GND and 12V as I did not initially take onto account the metal bridge of a hanging transformator, which I removed for the work, behind it. After that I extended each hole to its final size with the correct drill.

Quickly after beginning the first hole I saw that the case was thicker than I anticipated and much more flings built up than I expected. I was worried that these could pour into the power supply and cause unpleasant surprises when they survived the final cleaning between the contacts on the supply board. During drilling I could only make sure that the outer side of the drilling holes did not spray flings into the case so I folded up some newspaper pieces as protection and sticked them tightly on the back of the holes to catch all flings which would otherwise fall into the PSU on the inside during drilling. This worked remarkably well.

From ATX Power Supply Repurpose

After the holes were finished I began to mount the status LEDs, the power switch and the first two banana sockets.

From ATX Power Supply Repurpose

Also the load resistors were soldered together, clamped on the heatsink and, as almost everything I mounted inside the PSU, protected by maybe a bit too much shrink tubing.

From ATX Power Supply Repurpose

With the more complex wiring in place I continued with the connections to the remaining voltage sockets which should not take too much time. At least that's what I thought. In reality connecting the remaining four voltages caused much more trouble than the first part. The main problem for me was that I initially tried to always connect all available wires for a certain voltage rail to the banana socket. I failed with this target as it was very difficult to screw the wires onto the sockets in the very tight working area between the components of the PSU. Furthermore the thick pack of wires were squeezed out of the screwings when they were tightened. In the end I decided to only connect two or three cables to the sockets, clip off the rest and isolate those with shrink tubing. For the 3V3 connection one of the cables I connected was the brown 3V3_SENSE connection which is necessary for a stable 3.3V supply voltage.

Another problem was that the black shrink tubing was very difficult to get over the socket connectors when the cables were in place but with a lot of fiddling I managed to pull all of them over the sockets and properly isolate the power rails.

From ATX Power Supply Repurpose

Finally I cleaned out the PSU with a compressor and lots of air, did a thorough visual inspection of the modifications and the board, re-installed the initially removed transformer and closed the case of the PSU. The ATX bench power supply in its final beauty:

From ATX Power Supply Repurpose

After carefully plugging in the PSU and using a rubber glove to turn on main power on the backside I did a quick check if the case was free of erronous current. Then I again carefully turned on the new switch on the front, checked the safety of all metal parts once more and finally did a touch-test if it's really safe to the bare hand. Being confident that everything was OK and the LEDs correctly indicated the status I took a check of the voltage levels on the sockets with the multimeter.

From ATX Power Supply Repurpose

My multimeter showed all voltage levels to be within acceptable limits (11.7V, 5.1V, 3.4V, -5.1V, -11.4V) and without any fluctuation. I therefore consider this PSU repurposing sub-project a complete success. What's still left is to stick rubber bumpers on the bottom of the PSU and add properly printed annotations to the elements on the front instead of the pencil writing. But since I don't have any of that around that'll have to wait a few more days.

If you're interested in more images, there are many more available in the album which also show the progress in a bit more detail and from different angles. Included are also some shots of the mess on my desk during the project and an accident with a banana socket where it broke when I tried to screw it tight with too much wires.

Some resources for those who are interested (sorry, most of them are German):


Just to share a small tip which over time has saved me lots (really, lots of lots) of time.

It is possible in Firefox to define a bookmark as a shortcut which can be entered in the URL bar of the browser. So for example if you often visit a certain webpage with a long or complicated URL, e.g. you most certainly add it as a browser bookmark at some point. Maybe you even put that bookmark on your favourites bar so that you only have to travel a short distance with your mouse to open the page.

A browser bookmark already saves a lot of time but there is still some more potential to speed it up and this is where URL shortcuts enter the stage. To be honest it's not only the shortcut alone but a combination of a keyboard shortcut and URL shortcut. But first things first.

To define a bookmark to be available as URL shortcut you have to enter the Firefox bookmark manager. Then navigate to the bookmark and click it. Its properties are now shown in the lower part of the window. To define an URL shortcut for it click on "More" and a line "Keyword" should appear. Whatever word you enter here is later an alias for this URL in the browser. For example you could enter "st" in the bookmark for the Star Trek URL above. From now if you just enter "st" in the browsers URL bar, is loaded.

This is fast but still not much faster than clicking a bookmark. To make it really faster you have to activate and enter the URL bar by using the keyboard shortcut CTRL-L. CTRL-L and entering "st" should now really be faster than moving the mouse if you're just a bit experienced with touch typing on a computers keyboard.

But wait, there's more!

If you have defined a keyword for a bookmark it is possible to supply parameters to this bookmark. This work by using "%s" at the portion of the URL which should be replaced by anything which you write after the URL shortcut into the URL bar.

For example if you dislike the CTRL-K keyboard shortcut to jump to Firefox' search box you could decide that you want as the keyword "g". Edit this bookmark again and change the bookmarks URL to be "". Now you can also add the search queries to the URL shortcut/keyword on the URL bar. Entering "g star trek" should provide lots of joy to the average trekkie :)

At work my favourite URL shortcuts are defined as following:

  • ora -> for quick access to explainations of Oracle error messages. Eg. entering "ora ORA-01455" leads to a good explaination of the cause of this error.
  • leo -> translates german or english words into the respective other language.
  • wiki -> is a shortcut to the Wikipedia article. Most words are already directly available on wikipedia so this works 90% of the time for me.

Many webpages offer a search functionality and if you want to make this accessible in a very quick way just look how the search results page URL is composed and replace the portion of the search term whith %s for your bookmark.

Simple, fast, unbelievable effective.


I already explained that I use Bit Angle Modulation (BAM) in contrast to Pulse Width Modulation (PWM) in the logic which controls the brightness of individual LEDs in my LED Cube. During the implementation of the brightness routines in my source I realized that it worked pretty as expected at high refresh frequencies but I got very weird results for lower refresh rates.

Especially if I set the brightness to 50% (decimal 128) the LED had a clearly visible on/off-pattern of 4Hz in when running the cube at 1kHz. The explaination of this is pretty straigtforward: when the brightness is 128, standard BAM causes the LED to be active 50% of a full 256-cycle. 1kHz has ~4 full cycles and therefore the LED turns on and off ~4 times/sec.

Wouldn't it make more sense to have the LED alternate on each refresh, so that the average brightness is still 50% but the LED turns on and off with a period of two refreshes instead of 256? Similar to PWM but without the requirement for very high modulation rates?

My overall solution to tackle this issue was to add a simple counter which is increased with each refresh. When it reaches its maximum at 256 it's reset to 0 again. I use this counter to look up a bit-value in a table, which results in the bit to check for in the brightness value in each cycle. I then use this bit to AND it to every single brightness value of each LED and if it's non-zero the LED is turned on for this refresh. The initial values for this lookup table indicate the bit-values and resulting on-time for each bit of the brightness value. See the original code here. Of course this version still suffers from the problem described above, if the value is 50% the LED is on for the last 128 cycles of the 256-cycle period which leads to a slow and visible on/off blinking effect at low refresh rates.

The remedy for this is simple though, as the check-values are already in a lookup table. Just distribute the check-values much more evenly in the table and split up the connected on-time for each BAM-bit across the 256-cycle period. The resulting table is this. In this table every bit-value is strictly evenly distributed and spaced relative to each other so that the same values always have the same period.

The result of this change, which involved the usage of some LibreOffice Calc trickery, now allows for much smoother brightness control at much lower frequencies. Though there are limits to this. If the brightness is 1, it will still cause a visible 4Hz blinking at 1kHz refresh rate of the cube. There's no way around this besides limiting the minimum refresh rate to higher values. But in contrast to expensive PWM and unmodified BAM modulation, this variant should reach a relatively regular ~32Hz flickering already at a brightness as low as 8 (~3%).

So in pseudocode the looping and brightness algorithm for the LEDs works as following:

int counter = 0;
int bamBit = 0;

while (true) {
  // calculate if each LED is on or off during this refresh
  bamBit = getBamBit(counter); // get current BAM bit from lookup table
  for(int layer=0; layer<COUNT_LAYERS; ++layer)
    for(int x=0; x<COUNT_X; ++x)
      for(int y=0; y=COUNT_Y; ++y)
        ledsActive[x][y][layer]  = ledBrightness[x][y][layer] & bamBit;

  // display this refresh

  // reset counter at end of whole modulation period
  if(counter > 255)
    counter = 0;

Update: I'm not sure if this really works in practice as it should in theory. Until today I've used a not perfectly even distributed version of the lookup table (see this version) which I smacked together by just mixing up the values in a much simpler way (splitting the blocks and putting them together in a more distributed fashion) which was much quicker to come up with. Nevertheless I have the impression that the flickering has not smoothened at lower refresh rates and brightnesses as expected. I'll have to look into that sometime in the future again and make a better comparison of both versions. But yet it's still much better than the unmodified BAM brightness algorithm.


Just a quick status update on the progress of the cube since my last post.

On the hardware side there has been activity on two different topics. At first I had the opportunity to analyze my circuit and try to find out what's causing the ghosting effect at higher framerates using a friends oscilloscope. This involved getting comfortable with the usage and application of an oscilloscope in general and then trying to find out the different effects of different measurements and several different wiring variants of the transistors on the board.

From LED Cube Images
From LED Cube Images

This took a good part of a Saturdays afternoon and in the end I was pretty confident that the cause of my problem is that the base of the PNP transistor is not recovering fast enough to the blocking voltage as the IC leaves the pin floating after disconnecting it from GND. Attempts to remedy this with pull-up resistors allowed me to increase the refresh rate of the cube about 10x up to ~1kHz without noticeable ghosting but that's not really sufficient for my taste. My target is to allow up to 50kHz refresh rate on the 3x3x3 cube without noticeable afterglow of the LEDs. On the internet I found several topics where similar problems are discussed and all of them seem to have a common solution: add a Schottky diode to bring up the base voltage level faster. I had no schottky readily available so I unsoldered one from an old PC motherboard and used it to cover one of the three LED layers on the breadboard. Results are promising so far, I hope this still works when all three layers are equiped with a schottky. For now I think I can manage to work with lower cube refresh-rates until I'm able to pick up correctly dimensioned schottkys for all three layers. Until then this will be the situation on a single transistor at 5kHz (Yellow: base current; Green: collector current):

From LED Cube Images

Update: Short explaination to this graph. It was measured by hooking the oscilloscope to the base and collector of one layer PNP transistor. Pull-Ups are in place. Clearly visible (by the "knobs") are the layer switches causing some disturbance each time. When the layer gets activated the transistor instantly switches to conducting mode. But when it is disconnected again, it requires about half of the next layers visible time (~2us) to completely go into non-conducting state again. The faster the refresh-rate the longer the afterglow in each layer...

The last few days I've also been tingerking and thinking of how I could build the cube skelleton. I found no practical way to solder the LEDs together in a stable manner without adding additional wire. So yesterday I purchased a bit of iron wire and tried to solder the first layer. I drilled a few holes in a wooden plate, put the LEDs in it and soldered the LED pins together where possible.

From LED Cube Images

Next I prepared the iron wire, straightened it, cut out the parts...

From LED Cube Images

... prepared them for being soldered together with the LEDs to build the first layer...

From Building LED Cube

... and failed miserably, because the solder did not stick to the iron wire

From Building LED Cube

And I have absolutely no idea currently, what went wrong. Obviously another gap in soldering knowledge which I have to close when I want my next attempt for creating the LED grid to be successful.

At least on the software side there has been much more progress and success. I created a Github project for the LED cube driver software and improved and refactored the whole code several times now. So far I'm pretty confident that I created a quite flexible architecture and codebase so that it should be scalable for the 8x8x8 cube with minimal effort. Furthermore the animation framework is pretty stable and capable enough that I was able to create a new animation from scratch (one where you can move the bright LED using the cursor keys) within ten minutes. Each animation is encapsulated in a single class and completely independent from the cubes real refresh-rate. Notable features of my code which are finished (for now):

  • smooth BAM (Bit Angle Modulation) for controlling the brightness of single LEDs
  • console status output and ...
  • ... keyboard control for the animations, I/O via ncurses library
  • flexible animation architecture, independent from cube refresh rate
  • stable timing framework for controlling animation and cube refresh rates
  • a small set of prototype animations (whole cube pulsating, a single linear moving light, single random LEDs pulsating, a keyboard-controllable light)

In the last few days I've spent some time in the evenings/nights to set up a complete prototype circuit of the 3x3x3 cube on breadboard and create the first parts of the driver software.

There have been some minor issues (e.g. realizing that the larger breadboard has a different layout and connection scheme than the small one or running out of wire jumpers and cables) but in the end I managed to build the circuit on the available larger breadboard space in its full beauty.

From LED Cube Images

Starting the tiny test application which I wrote for the first IC test circuit even brought up the desired result on the first attempt so I've been pretty happy with the initial outcome.

From LED Cube Images

The next logical step was of course to enhance the driver software to allow for more sophisticated patterns and also do measurements on how big the impact on the multiplexing performance would be. Well, before I could finally finish that measurements the first non-expected issue manifested and left me puzzling.

I set up the cube pattern to light up the voxel (1,1) on the first layer, (2,2) on the second and (3,3) on the third layer and removed all delays to perform the multiplexing at maximum speed. Let's say the result did not exactly represent what I had in mind.

From LED Cube Images

When I limited the multiplexing to ~10Hz everything looked ok and only one LED per layer was lit but already at 100Hz additional LEDs became dimly lit and with 1kHz it became pretty clear that there was a speed-dependend issue, as on every currently active layer the corresponding LED which was active on the previous layer still received some current which increased with multiplexing speed.

From LED Cube Images

I re-checked the circuit for obvious and not-so-obvious problems (using my limited knowledge) but there were no aparent issues. Since the LED driver ICs are rated up to 30MHz my only possible explaination of this effect is that the transistors for some reason do not turn off fast enough after a layer switch. I'm somewhat sure that it's not based on the transistor type itself as I can't imagine that a standard transistor can't even manage to switch fast enough to produce a clean 1kHz signal. These are PNP transistors, so it allows current to flow E->C as long as B is connected to GND (or at least much lower than E). The LED driver IC is, according to its data sheet, fast enough when disconnecting the OUT pins from GND so that there should be no recognizable delay caused by this component. So my current understanding brings me to the conclusion that there is a small timespan where there is still current flowing out of the B of the transistor even if the OUT pin on the IC is not active anymore. Has simply the wire itself a capacitance which is just large enough to cause this?

In the meantime I've found a more-or-less acceptable workaround for this (thanks to my work colleagues for throwing some ideas back and forth with me), but more on that in a later posting. Yet, the underlying cause for this strange behaviour is still not clear and I'm determined to understand and resolve it eventually.


Well, since the failure last time I've geared up some more. Sadly additionally to the equipment I also picked up a cold which interrupted my progress for some days. Nevertheless, it became pretty boring and so I decided to give it another try yesterday afternoon when my headace was merciful enough to allow me some hours of concentration.

I've learned two things through this second attempt:

  • a clean solder tip is really essential (which was the main issue the first time in retrospective)
  • solder flux is almost mandatory for SMT soldering

A big help was also to watch some SMT hand soldering tutorials. In the end I think I was able to fix my mistakes and I guess the soldering of the IC turned out not perfect but also not too bad.

From LED Cube Images

Looking nice, waiting for some action :) To check its functionality and if I damaged it during my previous drama it was quickly integrated into a test circuit on the breadboard.

From LED Cube Images

A manual test by quickly connecting and disconnecting the various pins manually resulted in a strong hint that everything was working but it seems that at 3.3V the IC is very sensitive on the CLK line and when holding the CLK wire just my hand while having it disconnected from 3.3V or GND it generated continuous clock signals autonomical to set or clear the OUT pins just fast enough to be recognizable. Since this could still be a hardware failure I decided to put together the first software fragments I have created in the meantime (a simple C++ layer for setting the GPIO ports).

A bit of debugging and tinkering later, where I already managed to light up single LEDs I was looking at this:

From LED Cube Images

This is a picture of the Raspberry Pi controlled LED driver circuit which is already continuously running a basic multiplexing logic which could be used to drive the prototype 3x3x3 LED cube. It's not visible on the photograph (there was some flickering visible in the camera's preview screen) but the LEDs on the right side are for controlling the layer selection and only one of it is turned on at any time. The LED on the left side represents the center LED set in the middle layer, therefore only turned on when the selection LED for the middle layer is also active.

Out of curiosity I also added some counter logic which tells me the refresh rate of the cube. It seems that I can update the 3x3x3 LED cube with about 500kHz when running at 100%. Adding a usleep(1) brings that down to 8kHz leaving the RPi idle with 60% so there should be plenty of reserves for additional logic to drive cube animations.

But one possible weakness of my design (driving LED cube directly via the RPi) showed first signs. I recognized very short and tiny flashes and blackouts in the LEDs while running my test application. It becomes more visible when I move the mouse pointer. This is very likely one of the effects of Linux being no Realtime-OS and running stuff in the background delays the update of the cube. Even if it's just in a milisecond scale it's very visible in a sudden surge or peak of the LEDs brightness. This will be one of the issues which I have to deal with later, probably by introducing a timing logic based on absolute time and spin-locking instead of relying on OS-provided delay methods. It may also be caused by voltage fluctuations caused by the RPi's CPU sucking more power during background tasks but that should be remedied when I build a proper power source (which is also planned for the cube, probably from an old ATX power supply).


Yesterday I received the last important parts which prevented me from starting to build up the concept circuitry in real hardware, namely the adapter boards for the LED driver SMD IC STP16CPS05. I also acquired a new soldering station and a fine solder tip to be able to work on the tiny contacts. I was not able to pick up solder flux and solder paste as it was not in stock but I decided in the evening that I still give it a try and solder the stuff simply with my 0.5mm solder wire.

To sum it up: it was a desaster. I had no problem with the first two opposite pins to fix the IC on the board but when I began soldering the inner pins the solder did not stick correctly, formed balls and began spanning several pins quickly. I had quite some problems getting the excess solder away from the pins and at some time even the desoldering wick became trapped between the pins. After an hour I managed to get most of the solder out of it again but the plan of ordinary soldering went down the drain. So much for that. I'll spare you the pictures of the incident and I hope that the IC and board were not damaged in the rescue process.

I now suspended the soldering activities again until I'm able to pick up proper SMD soldering equipment: solder flux, solder paste and desoldering wick with flux.

At least I did not make another mistake. Initially I planned to solder the connectors onto the adapter board prior to the IC so that I could stabilize it while soldering in the breadboard. Just later I found out that if I had done this, I wouldn't have been able to reach the IC pins anymore with the solder tip...

| | Comments (2)

While I've been waiting for the final parts to arrive (LEDs, SO-DIP-Adapter, ICs, etc.) I did some more theoretical work and tried to scale the 3x3x3 driver circuit to 8x8x8.

This is the result:

From LED Cube Images

This circuit diagram also shows one specific feature of my cube. I want to transmit the LED status via serial connection to the driver ICs but in contrast to eg. the solution on HNTE I want to transmit the serial data to all driver ICs in a concurrent fashion, not via chaining them. It should work by providing all ICs with the same clock and latch signal but running a seperate signal from the Raspberry Pi's GPIO to each IC's serial input. That way I can set up the configuration for a single layer with only 16 clock cycles instead of 64. I'm not sure if this works as expected. If not, I'll have to fall back to daisy chaining the ICs serial lines.

That's why I also tried to come up with a flexible solution for the software which allows me to quicly adapt the serial output if I have to change the circuit. My goal is to create an algorithm which determines the required clock/serial/latch output in an efficient way from an 8x8x8 LED status array. It should also be easily configurable so that I can port it from the first 3x3x3 prototype to the final 8x8x8 cube with minimal changes even if I have to change the driving circuit.

I had no success so far though which may or may not be related to the fact that I only found time to think about that in the past week after 11pm each day as I've been busy with other stuff earlier each evening.


As already mentioned in my LED Cube intro post one of the milestones on the path to a full-size 8x8x8 cube is a smaller cube for trying out my ideas and testing the fundamental theories on a smaller 3x3x3 cube. Of course on the way to a 3� cube there are more fundamental issues to solve.

The first issue is to get familiar with using the GPIO pins of the Raspberry Pi, as this will be essential for feeding the driver circuit later with the required animation/multiplexing data. So in the last few nights I've been busy downloading Raspbian, setting up the network connection with my computer (I don't have a HDMI- or Component-capable device available near the work area) and preparing the first GPIO test with LEDs.

It was a good first step which took a couple nights, but after issues with wrong resistors, not-working DHCP from my computer and a wrong connected Pi Cobbler ribbon cable, I could file success with 3 lit and controllable LEDs. These will represent the three channels which I will use later to feed the serial data to the driver IC.

From LED Cube Images

I also began drawing the circuit diagram using the free (for private use) EAGLE PCB Software. I did this to already have a better plan when all the parts arrive and maybe for a much later stage when the cube is ready and I bring the circuit from the breadboard to a custom PCB which is the other main functionality of EAGLE. The handling of EAGLE is a bit difficult, but an excellent (german) tutorial video for EAGLE helped a lot and covered everything I needed to finish the circuit for the 3x3x3 cube.

From Building LED Cube

The next steps on my plan are ordering the final parts, enhancing the circuit drawing for 8x8x8 and beginning to write the LED driving software.


It is pretty clear that it's very hard to control 512 LEDs without some tricks. Most already built LED Cubes rely on two realization concepts to bring the cube to life:

  • some sort of integrated LED driver circuit (read: using chips)
  • use multiplexing / POV to lower the number of LEDs to be controlled individually

Using an LED driver IC to controll the large number of LEDs is almost a no-brainer. Although there are solutions possible to control that many LEDs without resorting to integrated circuits (e.g. Charlieplexing logic) they all come with one or more drawbacks like complicated wiring schematics, lots of additional required components or being only able to light a single LED at any time. Using a LED driver IC avoids all those problems and makes it possible to control many LEDs even for non-professionals.

Multiplexing takes advantage of the human eyes incapability to detect light pulses or variations in brightness if they happen just fast enough. It's the same principle which is used in TV sets and in the cinema. In a LED cube this principle is realized by only lighting up one layer of LEDs at any time and switching between the layers fast enough so that the human eye gets the impression that the whole cube is active. For an 8x8x8 cube this means that at most 8x8=64 LEDs (within one layer) are active at any given moment and the currently active 64 LEDs are switched within the 8 layers several times per second. This reduces the required logic to drive 64 LEDs and a simple selection logic to choose one of eight layers resulting in 72 wires leading to the cube.

The heart of my LED cube will be the STMicroelectronics STP16CPS05 (datasheet). I got the inspiration for this driver from this project and decided to use it because:

  • serial input possible using 2 pins (+1 for latch)
  • serial input accepts 3.3v, perfectly fitting for the Raspberry Pi GPIO
  • high maximum frequency of 30MHz, great for fast multiplexing (and probably software-driven PWM)
  • 16 output pins
  • simple integration and control (just clock in active/open LEDs and signal latch)
  • chainable (like done in HTNE's cube), but in my circuit this won't be required
  • cheap

One drawback of this IC is that it is not offered in a DIP-package which could be immediately used on a breadboard. Therefore I will have to solder the ICs onto adapters to use them on my breadboards and such adapters themselves are not that easy to come by.

Some friends suggested alternate ICs, eg. TLC5940, MM5450 or the MAX6962ATH but either are those much more difficult to interface with, have a smaller range of applicable voltages or I would have to use them in the same way as the STP16CPS05 without the ability to take advantage of their additional functionality. So I settled with the, in my opinion, simplest solution.

Update 2013-05-11 Found another possible alternative, the TI [TLC5925][9]. This looks like a possible replacement if I have problems with the STP15CPS05.

[9]: "TLC5925 16bit LED Sink Driver]


2 3 4 5 6 7 8 9 10 11 12 13 14