Stackable Tool Chest

I had a couple of weeks off and nothing better to do than to build something.

I’ve wanted to build a stackable tool chest on wheels for a while because the boxes I was using to carry my stuff to build days was falling apart.

This is the story of the journey that I took.


Rolling cabinet

On the rare occasion that I decide to make some (amateur) music, I head to the garage. For the longest time, I was using an old desk but this was taking up too much space. In our never-ending quest to tidy the garage, we donated it to a local goodwill store but that left me with needing something to store my recording equipment. It had to be more compact than a desk and I wanted something mobile too.

So, I put together a rolling cabinet using 3/4″ plywood with a couple of shelves and a couple of drawers. It gave me the excuse I needed to get out  the air compressor and brad nailer that I got for Christmas. So, only 7 months later and it’s finally being put to use.

What I learned from using it is that rectifying mistakes with brad nails is harder than with screws but it’s a cool tool to use 🙂

Speaker stand

With the opening of a new Living Spaces close by, we were tempted to get a new couch to replace our 15-year-old leather recliners. Multi-piece sectionals are the rage now but that complicates how we place the speakers for our surround system. Our old couch was a 2-seater and that meant we could put the rear speakers either side of it on the floor. They came in very handy for resting cups and stuff. The new couch is L-shaped and that means we can’t put one of the speakers at the side of it. So, time for another project. This time I built a speaker stand.

I learned how not to hold a handheld router so I only got 1 stand built. The mistake I made with that is in the video.

I’m not going to leave the wood bare, I plan to stain it a much darker colour.

LED light panel

I help build the sets for my daughter’s high school productions twice a year and it’s become a “tradition” that I have a little project for a specific part of the set that I build myself.

This year, the musical was “Little Shop of Horrors” and there’s a scene in the dentist’s office where Orin Scrivello ( the dentist ) shows Seymour an example of a neglected mouth on an X-ray image. I decided I was going to build a simple LED light panel to use with that X-ray.

It’s been a while since I recorded a build project and somehow managed to confuse record with stop so didn’t catch everything. However, I managed to salvage the footage I had and here’s the result:

Roombaduino – part 25 – Follow-up

A long while back, I demonstrated how to multiplex 2 OLED i2c displays which have the same i2c address. The video is here:


I was asked a couple of questions in the comments about how it worked.

Firstly, when the data has been sent to the display, does it stay there? That is do you need to refresh it?

Secondly, are both OLEDs able to share the SCL (clock) line?

I’ll answer in reverse order. Yes and No. 🙂

As I explained in the video, all the devices you want to multiplex share the clock line. The SDA (data) line is what is multiplexed.

For the actual data being sent, there is no need to refresh it. I don’t have the exact details on exactly how that information is stored ( who reads datasheets? ) but the code I used for the video demonstration is below and I don’t refresh anything.


#include <Wire.h>
#include <OzOLED.h>

#define MUX1 6
#define MUX2 7
#define MUX3 8

#define NUM_SCREENS 2
int screen = 1;
int i = 1 ;

void setDisplay( byte displaynum )
 digitalWrite( MUX1, (displaynum & 0x01 ? HIGH : LOW) );
 digitalWrite( MUX2, (displaynum & 0x02 ? HIGH : LOW) );
 digitalWrite( MUX3, (displaynum & 0x04 ? HIGH : LOW) );

void setup() {

 pinMode( MUX1, OUTPUT );
 pinMode( MUX2, OUTPUT );
 pinMode( MUX3, OUTPUT );

 for( int s = 1 ; s <= NUM_SCREENS; s++ )
 setDisplay( s );

 // Rotated 180 degrees
 OzOled.sendCommand( 0xC8 );
 OzOled.sendCommand( 0xA1 );
 OzOled.sendCommand( 0x0DA );
 OzOled.sendCommand( 0x012 );
 OzOled.setBrightness( 0xFF );

 OzOled.sendCommand( 0x8d );
 OzOled.sendCommand( 0x14 );


void loop()

 setDisplay( screen );


 OzOled.printNumber( (long)i );
 if( screen > NUM_SCREENS ) screen = 1;

Raspberry Pi 3 – NTP problem solved – some power issues

I got a Raspberry Pi 3 recently and installed the official Raspbian image from

I came across a couple of issues:

  1. NTP would not sync.

ntpq -p would show that all the servers were in a state of .INIT.

ntpdate would work but ntpd would not.

It turns out that the kernel driver for the built-in WiFi chipset can’t handle the NTP packets over UDP. The solution is to add the following to /etc/rc.local:

/sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p udp --dport 123 -j TOS --set-tos 0x00

and reboot.

This is discussed on the forums at

  1. Power management is a problem running it off an Anker 10-Port charger (

I knew that the Raspberry Pi 3 drew more power but it seems to be unstable with this particular charger. That’s not to say the charger is at fault, it’s running 6 other Raspberry Pis quite happily but they are older models and I don’t think the ports supply the required current. I’m ordering a 5v 2.5A power supply to see if that resolves the issue.

The WiFi chip needs to have power management disabled to get it to be responsive.  To do that, you can create a file /etc/modprobe.d/8192cu.conf and add the following:

options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

I’m not certain this is addressing my immediate problem but once I get a more powerful power supply, I’ll be able to check.

UV Light Box – Part 2 – Control Interface

I spent a lot of time working out how I wanted the controls to work and designed the software in C first so that I could work out a generic menu system that allowed me to configure it via an array of menu items.

The definition of the menu items is:

typedef struct {
 int id;
 char *label;
 void (*display_action)();
 void (*select_action)();
 void (*up_action)();
 void (*down_action)();
 int submenu_id;
 int prevmenu_id;
} menu_t;

So each item has an ID and a label followed by a set of actions. When the menu item is first displayed, it’s either the fixed label or, if the label is empty, the display action is called. This allows me to vary the display for things like the timer counter start value where the operator can choose the length of the timer. The select, up and down actions are function calls to vary the behaviour but the left and right actions are always to move to the parent menu or to a submenu.

This structure means that the actual menu handling code is relatively simple. Each button press will call the appropriate function in the structure. It’s the actual functions that can change and I can code for those as I go along.

The code itself is called inside the Arduino loop() function so I’m not using interrupts for the timer and the processor isn’t stuck in delay() cycles. Each time I go around the loop, I am taking the current number of milliseconds since the processor started up and compare that to a previous value I took. If the difference between the current and previous values is over a threshold, I take an action. For a timer, the resolution is seconds so I take the action to update the timer every 1000 milliseconds. For button checking, I take an action every 125 milliseconds.

This video shows the timer and menu system working. I still have some bugs to iron out in terms of timing but it’s working as expected.

UV Light Box – Part 1

I’ve been playing around with etching my PCBs for projects and using toner transfer to do that. There are some problems I have with that method ( that’s not to say it’s not a good method, it’s just that my results haven’t been as I would have wanted them ) and so I’m starting a project to build a UV Light Box to expose UV-sensitive film to UV light as a different way of creating a mask for the etchant. This video starts that journey:


Roombaduino – part 24 – Simple UI

I took a little time to look at the design for a simple UI for the Roombaduino. I needed to know the voltage level, which brushes are in operation and what mode the Roomba is in.

During this, I was getting a notification from the Arduino IDE that I was going to run low on memory using the example sketches and some of this is down to including the Serial library for debugging output. Once I stopped using that, the sketch was at 44% memory usage compared for 65%. Given that the amount of memory available

Roombaduino – part 23 – Custom connectors and working modules

I put together some custom cables with ribbon cable, heat shrink and connector pins to replace the breadboard pins I was using. These connectors are a little more resilient.

I connected everything up including the wireless transceiver and tested the modules both with the I2C scanner and the serial monitor with the initial remote control sketch.

Everthing seems to be working fine so I now need to get the sketch on the main MCU to send data to the Roomba again and then I’ll start work on the case.