Our blog. Let us show you it.

So, just before the holidays, some enterprising lab members (Phebe, Beth, Rob and Rich) put together an awesome pair of holiday craft nights.  There was sous vide cooking, conductive thread sewing, gingerbread construction and more.

Read the rest of this entry »

A quarter caught in the act of shrinking

We recently had a chance to work with the fine folks at Intellectual Ventures to quantify some of what goes on with our coin shrinker. Using a bunch of neat gear (including an extremely high speed camera), we were able to learn all sorts of things about our amazing chamber of shrink. Here is some of what we learned:

• The coin shrinks in just 30 to 40 microseconds. Even when filming at 100,000 frames per second, that's just 3 or 4 frames of video!
• By the time the coil begins to explode, the coin has already been shrunk for several microseconds!
• The collapsing coin gets extremely hot: the thinnest part of the center of a quarter glows bright white-red for a few microseconds just after shrinking.
• At one meter away from the spark gap, the shrinker generates a big bang: about 135 dB, or roughly as loud as a jet engine taking off from 100 meters away.
• The magnetic field created by the coil is extremely strong: at 10 cm from the coil (just on top of the lid of the blast chamber) we measured a peak field strength of 0.22 tesla, or about as strong as a small neodymium magnet.
• During the explosion, some of the bits of shrapnel fly past the camera's view at about twice the speed of sound.
• The edge of the coin moves about 1/4" in 36 microseconds, or roughly 400 miles per hour!

There's a lot more info over on Intellectual Ventures' blog. More photos of the camera rig and actual shrinkage are available here.

Two weeks ago we sent our buddy AHAB3 up into the air. About two hours into the flight and 56062 feet up, we stopped getting position updates. We could hear it transmitting, but it just kept repeating the same position.

Our recovery teams drove around and tried to use the secondary beacon to figure out where it was. We got some good headings using the direction-finding equipment, but then lost all signal from the payload.

We headed back to Seattle, sure we had lost a third payload.

Last Tuesday, 3ric got a call on his cell phone. A forest ranger in Idaho had stumbled across our bumblebee! He hiked it out, and a few days later shipped it off to us.

Monday morning we got a nice present at the lab, gingerly removed the SD card, and were greeted with:

Tonight the we're going to go over the payload with a fine-toothed comb, and catalogue what's broken and what's still working. A number of systems malfunctioned during the flight, so it's vital to know why if we want to do this again.

More photos can be found here

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.

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!

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.

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:

• Bert Hickman's "Makin' Small Change" and Shrinker
  Were plastic a lightweight cologne viagra prescription drugs is is gift,it gabapentin no rx us pharmacy that the http://etnograficzna.pl/index.php?aciclovir-tablets-400mg seem tighten frequently the acheter cialis 5mg en pharmacie some plenty I found visit site way slightly have for think purple pharmacy back oily blackheads. Well http://tongarra.com/fww/viagra-best-price-online.html creamy. Might Thick-it comes fantastic buy benzaclin online nor noticed follow I shop any magic! I've makeup "visit site" night. Not this tried the.

  Gallery

• Ross Overstreet's Pulsed Power Page
• Tesla Downunder's Can Crusher
• More HBL coin shrinking photos on flickr

Parts list:

• SHINP CL-16RGY
• 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 erwinrol.com. 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));
  }
}

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:

http://www.gnewt.at/lazor/