Let’s get into details! The system is running on Aleutia T1, which is a really nice, silent PC-ish thing. PC-ish, because the performance is not really up to todays standards, but on the other hand it’s quite cheap, really silent and comes pre-installed with Ubuntu. Cool! (However, I installed Windows XP…) I got mine with a SSD, which means that there are no moving parts whatsoever, therefore it can stay on 24/7.

Using a simple XAMPP setup, it runs my photoframed software mentioned in the previous post (demo, source).

The webcam setup is quite interesting. First I tried to plug the webcams using some USB extension cords. It was highly unstable, so now the PC is actually positioned in a cardboard box, lifted from the ground, so all the cables fit exactly.

Another issue with the webcams is having it stream, but also have it stream securely. A promising format seemed to be MJPEG: this is just like sending out JPEG frames as fast as the connection can manage. I run the following code to generate a MJPEG stream using VLC. The stream is only accessible from localhost for security reasons.


vlc.exe dshow:// :dshow-vdev="USB Video Device" :dshow-adev=none :dshow-size=640x480 --no-sout-audio --sout=#transcode{vcodec=mjpg, vb=512, fps=1, width=640, height=480}:standard{access=http{mime="multipart/x-mixed-replace; boundary=7b3cc56e5f51db803f790dad720ed50a"}, mux=mpjpeg, dst=127.0.0.1:8080/cam.mjpg}


The boundary thing is a code required for modern browsers to correctly recognize the data type. If you remove the IP-address at the end, you’ll allow anyone to watch the stream. Now the next proxy is to make sure only authenticated people are able to see the stream. I tried this using a PHP script which simply read the stream and echo’ed it (and some other variants). I also tried using the Apache proxy module. But both options have the same problem: as I have a terrible internet connection, I really need the last frame. Once a frame is transmitted, the new frame must be the most recent frame possible. However, all options I tried seem to cache the data, so you’ll see 1 second of recording spread out on, like, half a minute on the client.

In the end I just went with a simple script I found online somewhere, that reads exactly one MJPEG frame and spits it out as ordinary JPEG:


$boundary="\n--";

fclose($f);


Now you have to refresh the image using for example Javascript, so that’s fine too. The webinterface I’ve written for this purpose also features a slider to set refresh interval, which is pretty handy if you’ve got a shitty connection like myself. Also, this brings me to the home automation part, which is actually pretty brief. All devices in my room are plugged into a KlikAanKlikUit unit, and the PC’s got a TPC-200 interface plugged in, and a little bit of software does the trick (demo, source).

The TPC-200 interface comes with a DLL which has one single command: Send(id, value), with id being an integer and value a boolean. A simple executable wrapper, hacked together in VB, makes it easy to send commands from PHP, using exec.

The first room control breach has happened already: I used the inferior Apache Basic Authentication for the login procedure, and it turns out that sessions can keep open for a long period of time. Even when the server restarts during that time. I logged on the system on the laptop of a friend of mine, and 3 days later, he scared the crap out of me by playing with my lights. ;-) The PC restarts every night at 5am, so I’m still amazed that the session lasted that long.

Anyway, I quickly tracked him down using the access logs and we had a good laugh about it, but I still don’t trust the security anymore: the inside camera is pointed at the ceiling now… SSL and stuff like that will probably be secure enough, but if you’re considering building the same setup, don’t plug in your nuclear power plant.

Most of the original source code is lost, and the system doesn’t work well anymore, so I’m redesigning it. In a few months you can expect another blog post on this, but I thought a writeup of the old design would be nice.

It started with an old laptop. In an impulse I decided to see how quickly I was able to strip it until only the bare essentials were left. It was quite easy to disassemble it, and the wires were long enough to separate the display from the other components.

Once the laptop was disassembled, it was easy enough to go to the DIY store and buy some materials. With some careful measuring, patience and painting twice, the job was done in a few evenings.

To display the photos, a clock, and some RSS feeds, I used a PHP script by Tommy van der Vorst, running in a fullscreen Firefox window. It worked pretty well. After some modifications, it was used by myself and others for 3 years.

A few months later I stumbled upon this post on a forum, which describes how to easily hack a cheap home automation remote control to hook it up to a computer. There were sets available for about €20 to control lights and devices with a remote control. So I bought two of these sets. The first hack was to hook it up to ordinary lights that are directly connected to a power source, without a wall socket in between. The setup wasn’t very safe, but it worked.

Next, I followed the instructions on the forum post: hook up the remote control to the serial port, detect commands using LIRC, and send them back to the remote control. It worked fine on the computer, but the problem is that on laptops the serial port is weaker: it usually won’t give a nice and strong 12 volt signal.

The solution was rather simple: by hooking up transistors to every button, you can simulate a press of that button simply by putting a small voltage on the transistor. The easiest way to do this is by using the parallel port. Fortunately, the laptop was pretty old so this was no problem.

With some Visual Basic programming, the Microsoft Speech API and some PHP scripts it was possible to control the lights by voice and over the internet. Which is pretty cool. Unfortunately, I lost most of the source code, so I won’t be able to share it here. Right now I’m building a new version, and when it’s done I’ll share the code!

For now, I’ve started improving the PHP script that shows the photos, which I’ve dubbed photoframed. It’s pretty nice already, you can download and contribute to it on my github page. It even works perfectly fine in an iframe like the one below.

In a few months the new system should be up and running, so I’ll probably write another blog post then. Meanwhile, I invite everyone to look at the source code of photoframed and contribute. Or you can just leave a message in the form below. ;-)

One of the coolest projects I have worked on resulted in the turning of heads when biking through the city, and was also a great challenge as it involves some tricky hardware and software. The result was pretty darn amazing though.

So this was a really cool project that took a lot of my time when I was seventeen years old. Do you know these gadgets that write text in the air? Ever wondered how they work?

It’s pretty simple, actually. There is a row of LED-lights that you swing through the air. Those leds alternate very quickly between on and off, in a very specific pattern. When you move the leds at exactly the right velocity, the pattern will become visible to the human eye, and you can actually read text or see an image.

You are able to see this text because your mind will stitch the images together, like when watching TV. It all happens so fast, that you won’t see the individual frames, but you see the image as a whole. Or in case of the TV, it looks like you’re watching an actual moving scene. This phenomena is called Persistence of Vision (POV), and quite useful when making awesome things. :-)

In theory it’s possible to attach a row of leds to the side your bike, and get the same effect as swinging it through the air. The problem with that is that you have to go fast. Very, very fast. Instead, there is something on the bike that has a much higher velocity than your forward velocity: the angular velocity of the weels.

Depending on the size of the weel and your forward velocity, you’ll get a fair number of rotations per second, enough to make it blurry to the eye. So why not take the row of leds, and put it in the wheel. Sure, you have to do some funky math to get a nice image, but it looks cool, right?!

But of course, it already exists: SpokePOV by the artist/engineer Ladyada (who, by the way, makes very cool things!). Lucky for me, those kits only come in one color. What could be cooler than making a full-color SpokePOV?

After carefully selecting parts – RGB-leds are expensive! – the drawing began. For this I usually use KiCAD, an awesome open-source electronics CAD program.

Designing the circuit board was a devilish job. The routing of all the lines to the leds took a lot of time to perfect, not to mention fitting it on a board that is as small as possible. A cool thing about Kicad is that you have an awesome 3d viewer. But a 3d model with missing components kinda sucks, so I drew a few models myself in 3ds Max.

All that done, the schematics were sent to Niels at MakePCB, who also supplied most of the components. And how awesome, a few weeks later an envelope with the circuit boards arrived. A few hours of soldering later, and the hardware was finished.

But the hardest part was yet to come: the software. Luckily Microchip supplied an excellent USB bootloader, which I tweaked a bit to use the leds as status indicators. The embedded software is all about performance: it has to be able to keep up with the speed of the weel. Therefore it was necessary to supply the program with an image in a format that is easy to decode, and small at the same time.

First, a computer program in Java converted a normal image to a rotational image using some simple trigonometry. Normally, when composing images, pixel data consists of 3 bytes per pixel: one for each color. Uncompressed, this took way too much space for a small PIC microcontroller. JPEG or PNG compression was not an option: way to complex to decode. So the color data was reduced to 1 byte per pixel: 3 bits for red, 3 bits for green and 2 bits for blue. Why the reduced count for blue? Well, there are 8 bits to the byte, so some color has to go down, and blue is the best choice as the eye is the least sensitive to that primary color.

To display the colors some standard techniques are used such as pulse-width modulation (PWM) and LED-multiplexing, which I won’t cover in detail. However, the decoding of the pixel data to 3 bytes is kinda interesting. The C implementation was too slow, so it had to be done by hand, in assembly. Using assembly for this critical piece of code (which is only a few lines long) improved the speed of the whole program by a factor 6.

TBLRDPOSTINC
MOVF TABLAT, 0, ACCESS			// Read TABLAT to WREG; WREG = RRRGGGBB
MOVWF CurrentPixel, BANKED		// Put WREG in CP (CurrentPixel)
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    WREG = RRGGGBBR
MOVF CurrentPixel, 0, BANKED 		// Put CP in WREG
ANDLW 0x06				// AND WREG with 0x06;  WREG = 00000BB0
MOVWF PWM2_0, BANKED			// Put WREG in blue channel

RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = RGGGBBRR
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = GGGBBRRR
MOVF CurrentPixel, 0, BANKED 		// Put CP in WREG
ANDLW 0x07				// AND WREG with 0x07;  WREG = 00000RRR
MOVWF PWM0_0, BANKED			// Put WREG in red channel

RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = GGBBRRRG
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = GBBRRRGG
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = BBRRRGGG
MOVF CurrentPixel, 0, BANKED 		// Put CP in WREG
ANDLW 0x07				// AND WREG with 0x07;  WREG = 00000GGG
MOVWF PWM1_0, BANKED			// Put WREG in green channel

The algorithm of the program is pretty simple: take the time of one complete cycle (360 degrees). This time is measured by using a magnetic switch, with a magnet on the frame on the bike. The time is divided by 256, and a timer is set to fire a function. This function will take the next pixels, decode the colors for all the leds (on the front and on the back of the device), and feed this color to the leds using PWM and multiplexing. Result: people watching you as you go down the street at night. Mission accomplished.

As you can see on the photos, I ended up mounting two boards on the wheel. Otherwise you had to drive quite fast.. The synchronization of the two boards happens automatically, because they will both align to the magnet. Except when accelerating or slowing down, both boards remain in sync quite well.

I managed to get this project approved as an assignment for school (‘profielwerkstuk’), so the documentation is quite extensive. It can provide an interesting read if you like to know more about the used components, programs and techniques. You’ll also read about some major design decisions. It’s only available in Dutch though.. Download.

There are still a few un-soldered boards laying around here, as well as all the hardware designs and software code. However, I won’t post it here as many things are unfinished and not at all ready for production. Also, the parts are pretty expensive, especially when taking into consideration you need at least two boards per wheel. If you’re interested though to take this to the next level though, feel free to contact me and we can talk about it. But be warned: a lot of work needs to be done to have it work really well.

Update: it seems that around the time I built this, some other guys also got the idea and commercialized it. Their simple version does not support images or synchronization of the units, but looks awesome nevertheless. Their pro version is very cool and even supports animations and on-the-fly wireless programming but is priced at thousands of dollars. It seems though, they have done a great job! :-)