Archive for March, 2009

Our Shrinking Economy

Posted by rob on 30 March 2009

Coin Shrinking from Jeremy Ruhland on Vimeo.

Turn half dollars into quarters! Turn quarters into dimes! Turn dimes into little semi-molten balls of metal! All this is possible with the proper application of insanely high electrical current at very high voltage.

"God made the quarters. It's up to us to make them shrink." --anon.

The coins don't just shrink; they keep their identity and fine details. But do they keep their value?


Hackerbot Labs is proud to contribute to America's economic downsizing.

How does it work?

A high voltage DC supply charges the big 300 µF capacitor to 10 kV, or about 15,000 J of stored energy.

The rig.

This energy is released as quickly as possible into a small copper coil wrapped around a coin.


The fast changing current creates a very powerful magnetic field in the coil, which creates a very powerful magnetic field in the coin itself. The strong opposition between the two fields causes the material of the coin to contract, while at the same time the copper coil expands. A few dozens of microseconds later, the coil has violently exploded inside a specially built blast chamber. And the coin itself is much smaller!

spark gap trigger

Where does the coin go?

No material is lost from the original coin: the weight and volume are the same as the original. But the coin now has a smaller diameter and is thicker, while retaining much of its surface detail. It's also extremely hot just after firing!

Isn't this dangerous?

Oh yes. An average automated defibrillator (AED) provides a jolt of about 150 joules. The energy stored in the big cap is about 100 times that much.


There's also the tremendously loud noise, a very bright flash of UV when the spark gap switch closes, the possibility of fire and toxic gas when stuff in the chamber burns or pyrolyzes, and bits of copper shrapnel moving with enough energy to blast clean through six-ply blocks of plywood. And somebody always burns themselves when they try to pick up the newly shrunken quarter.


To contain and prevent much of that danger, we have designed a custom-built blast chamber out of very thick high density plastic. It contains the shrapnel and covers most of the electrodes, and provides a solid platform to hold the mechanical spark gap trigger. The trigger is engaged by yanking a very long rope: simple but effective.

ready to fire

Who invented this thing?

It wasn't us. We just built one. It's an actual industrial process called electromagnetic forming. See some of these links for more coin shrinking madness:

The Laser Box

Posted by Gnewt on 1 March 2009
This is a long-exposure photo of me being scanned by the laser.

Parts list:

  • OpenDMX USB dongle

A while ago I was given a SHINP CL-16RGY by 3ric, to play with. We had no software for it, no experience with the box, and no clue what we could make it do. Here's the story of what I did to make it work, and what we're going to use it for in the future.

First, I needed to install a driver the Enttec Open DMX USB dongle. This is how we send signals to the laser. The first bit of info I found was here, a tutorial on exactly the USB dongle we have. One problem: it's for a Linux box. I have a Windows laptop. I fired up my Ubuntu virtual machine and got to work.

Compiling the driver was fairly easy. Mentioned in the tutorial I linked to is a driver from All I had to do was run a git command, make, copy the driver into the right directory, and then depmod. Voila, plugged the dongle into my laptop and it was recognized by Ubuntu as /dev/dmx0. Perfect! Next step was figuring out how to send it commands. I found some sample code somewhere (though unfortunately I can't remember where). It looked like this:

#include <stdio.h>
#include <string.h>
#include <fcntl.h>

int main()
  unsigned char buffer[513];
  int fd;

  memset(buffer, '\0', 513);

  fd = open("/dev/dmx0", O_WRONLY, 0);
  while (1) {
    write(fd, buffer, sizeof(buffer));
The CL-16RGY from

This worked to prove that the driver was working. The laser box has a little green LED on the back which signifies DMX512 data being received. It was blinking furiously. I thought "well, since it's receiving data, everything after this will be easy." I was very wrong. The manual told me that certain channels controlled certain things (channel 1 for X position, channel 2 for Y position, etc), and I assumed that the information would be correct. No. Of course not. It can't be that easy.

I nearly gave up the project at this point. The terrible layout of the buffer was pissing me off. After a while though, I found a Windows DMX program. It didn't work how I would have liked it do, but it let me adjust the channels in realtime, so I could figure out what things were. I squealed with joy (on the inside, of course) and took note of which channels corresponded to which functions. At the time, my code was in Python, so I edited the Python file and ran it. LAZOR WORKING! I tried editing a few of the channel values to make sure I was editing the correct positions in the buffer, and it worked just like it should.

My code at this time was in Python though, and I wanted the end result in C. I pretty much recreated the same code in C, implemented getopt, and cleaned up the code. It ended up being beautiful! Here is the sourcecode, a binary, and the CL-16RGY manual:


Tag Cloud