[Ian Cole’s] son is learning to play the drums on an electronic drum set, and he wanted a way to continue practicing during his frequent visits to his grandparents’ house. [Ian] had picked up a Spikenzielabs “Drum Kit Kit All-Inclusive” (DKKAI) earlier this summer, and set out to build an easily transportable drum set.

The DKKAI comes with an ATmega168-based board and a set of piezos that can be used to register hits. It was up to [Ian] to provide the rest of the kit, so he set off to IKEA in search of cheap, durable drum heads. He returned with a handful of 1/2 Liter plastic bowls, which he mounted on a PVC pipe drum stand.

The piezos were mounted on thin aluminum discs, which were in turn glued to the back side of the bowl lids. The piezos were wired to the DKKAI kit via the PVC tubing, with the signals ultimately fed into an iPad running Garage Band. [Ian] says that his portable drum set works quite well, and although there are some things that require changing, his son is very happy with his new practice set.

Check out the video below to see the portable drum kit in action.

We asked, and [Zach] listened.

Earlier this week, we featured a circuit he built which allowed his tiny Star Wars Christmas tree to visually replicate the series’ theme song. Several of you, along with myself, thought it would be far cooler if the tree also played the music to accompany the light show, so [Zach] set off to add that functionality.

Worried that the music would get annoying if it played along with the lights constantly, he tweaked his circuit design to incorporate a piezo buzzer that could be easily switched on and off. After wiring it to the MSP430 driving the light show, he tweaked the program to output signals to both the light string and buzzer simultaneously.

While the light show accurately represented the song, he initially ignored flat and sharp notes as they would be indistinguishable to the eye. In audio form however, the missing notes would be glaringly obvious, so he re-transcribed the sheet music resulting in the video you see below.

If you happened to follow [Zach’s] lead and put one of these together in your own house, be sure to swing by his site and grab the latest code, complete with audio track.

The echo box performs exactly as its name implies. If you tap out a rhythm on the lid, it will tap the same thing back to you. Except it isn’t tapping to make the sound, but vibrating.

The concept is similar to the Knock Block. In that hack, a piezo element detected a rapping on the wooden enclosure and repeated the rhythm by striking the lid with a solenoid. This iteration also uses a piezo element as the sensor. In the image above you can see a segment of PVC pipe in the upper corner. That houses the element, sandwiched between two pieces of wine bottle cork. That cork just touches the lid of the box, transferring the vibrations to the element.

The sound is created by a motor with an offset weight on its spindle. When the motor spins, it causes vibrations. The enclosure is one wood box inside of another, so the vibrating motor cause the inner box to shake against the outer one to make noise. Hear it for yourself in the clip after the break.

[Steven] had one of those musical gift cards laying around, and thought he might as well reuse the piezo speaker inside it. Without a particular project in mind, he soldered an LED to the piezo and tapped on it, which caused the LED to illuminate as expected. He started to wonder what quantity of force would be required to light the LED, and if it could be done by a raindrop.

He first tested his theory in the shower, and as you can see in the video below it actually worked, though the light was dim and sporadic as you might imagine. He eventually discovered that for optimal lighting, the piezo worked best when struck by single droplets falling with pauses in between, from a minimum height of 4 feet. To achieve a water flow within those specifications, he built a rain funnel so that he can control the droplet frequency and intensity.

It seems to work pretty well from what we can see. Off the top of our heads we can’t seem to come up with any practical applications of the water powered LED, but it is an interesting set of experiments nonetheless.

Have an idea to use this setup that we totally missed? Let us know in the comments!

[Thanks, Rob]

[Rob] has been working on his drum trigger build, and he’s finally decided to share it with us. His drum heads and triggers don’t look like anything we’ve ever seen, but he’s pretty confident he has a good kit in the works.

The first unconventional of the build is the drum triggers. The triggers are piezo elements folded up or cut down to fit inside highlighter bodies. These piezo/highliter/drum triggers were filled with melted candle wax to make sure the piezo doesn’t rattle around. [Rob] seems to have taken an empirical approach to cutting up piezo elements – smaller elements are less responsive, so they’ll be used for the zones of the drum head.

[Rob]‘s drum heads are made from tennis and badminton raquets. The implementation is actually kind of clever: [Rob] restrings the raquets on the bias to vary the feel and responsiveness of the head. Check out the Flickr photoset of the build here.

The ultimate goal of [Rob]‘s build is a “glass” drum set certainly inspired by [John Bonham]‘s Vistalites. Whenever [Rob] puts up a video playing Moby Dick on his new kit, we’ll be sure to put it up.

[Tom] wanted to try his hand at high-speed photography and needed some equipment to get things rolling. Not wanting to spend a ton of money on a lighting rig or trigger mechanism, he decided to build his own. In a three part series on his blog, he details the construction and testing of his high-speed setup along with the improvements and lessons learned along the way.

His adventures started out with a small off-brand Cree LED clone and an ATiny15L that was collecting dust in his workshop. He built a simple circuit that would trigger the LED to light his subject, which in [Tom’s] case was a bowl of milk. Rather than using a motion or sound trigger, he opted to mount a small piezo to the bottom bowl, firing the LED any time a droplet hits the bowl’s surface.

The pictures he took were decent, but he knew he could get better results. He purchased a new, more powerful Cree LED, and wrote a small terminal program that allows him to tweak his flash parameters using his laptop. The results he gets now are far better – in fact, he has a whole gallery of pictures you can check out.

If you want to delve into high-speed photography as well, all of the schematics and code can be found on his blog.

[John Thomson] usually keeps his phone on vibrate when it’s in his pocket, and he often forgets to turn the ringer back on when setting it down to charge. This typically results in a bunch of missed calls in the meantime, so he had to devise a way to counteract his forgetfulness.

You might remember [John] from the Santa-pede contest we held last December. He wanted to try his hand at yet another competition, the Avnet Dog Days of Summer contest, so he scrambled to come up with a quick fix for his situation. He concocted a simple circuit based on [ChaN’s] design for a “Simple SD Audio Player with an 8-pin IC” that would alert him to incoming calls, even when his phone was on vibrate.

[John] used an ATtiny85, just as [ChaN] did, adding a speaker for sound output and a piezo sensor to detect his phone’s vibrations. When the piezo senses a bit of motion, the audio player kicks in, blaring a series of sounds that are sure to get [John’s] attention.

[Leafcutter] is big in to making music and has put together all sorts of musical instruments and tools over the years. Recently, he was inspired to make his own piezo crystals, and wrote in to share the results of his experiments with us.

[Leafcutter] is no stranger to messing around with piezo elements, and after seeing [Collin’s] tutorial on making your own piezo crystals at home, he knew he had to give it a try. He stopped by the grocery store to fetch all of the ingredients, then followed [Collin’s] instructions to the letter…well, almost. It seems that he might have cooled the solution too quickly, so he found himself with a jar full of tiny, barely usable piezo crystals instead of larger ones like [Collin] was able to produce.

Undeterred, he decided to see if the stuff was any good, and rigged up a makeshift contact microphone using some conductive foil and a clamp. He piped the output to his amplifier, and wouldn’t you know it…it worked!

He has a small sound clip of what the mic sounded like on his site, and it worked pretty darn well despite the crystal’s tiny size. He is going to give the whole process another go, so we hope to see more experiments with bigger crystals in the near future.

In our hands-on review of the Digilent chipKIT Uno32, we posed the question of what the lasting appeal might be for a 32-bit Arduino work-alike. We felt it needed some novel applications exploiting its special features…not just the same old Arduino sketches with MOAR BITS. After the fractal demo, we’ve hit upon something unique and fun…

So just what are the chipKIT’s unique features over a stock Arduino? Until the expected Ethernet shield ships this summer, a few ideas are on hold. Let’s see then…there’s no shortage of MIPS, of course…but there’s also heaps of RAM and flash storage. And with the latter, sampled audio came to mind. There are Arduino shields for just this sort of thing — the Adafruit Wave Shield turns up in many projects, using an SD card for sound storage — but if one’s needs are modest, the chipKIT’s PIC32 is perfectly capable of storing brief audio samples in its own flash program space, no cards, adapters or added expense required. We estimate the Max32 can hold nearly a full minute of voice-quality audio.

Playing with the idea, we found we could do one better. Actually, several better. A limitation of SD card-based players like the Wave Shield is that they can only play one sound at a time. Dealing with the FAT filesystem and buffering audio data off the card takes nearly everything the Arduino’s little ATmega chip can muster…polyphonic sound requires kludges. But our flash-resident audio samples on the chipKIT are trivial to access. With the fast 32-bit CPU, many samples can be processed simultaneously…and then, with gobs of RAM, time-based effects such as reverb can be added. And before we knew it, there was a toy synthesizer sitting on the table:

Having previously dabbled with the PIC32 using Microchip’s tools, we were surprised by the simplicity with which this went together. A few early rough spots aside, the chipKIT and MPIDE environment show major promise for being every bit as simple as Arduino. In fact, the whole build was completed faster than the documentation phase. And then a second surprise, even to us: everything in the parts list, aside from the chipKIT board itself, is common stuff that could be found at RadioShack. No funky special ICs, components or mail-order shields. Most of the “magic” is in software, thanks to this fast microcontroller.

Here’s a demonstration of the finished mini-synth in action:

Please excuse the demonstrator’s tragic lack of rhythm and coordination. This is why professional musicians get paid millions while amateurs lead sad lives as technology bloggers. Be thankful that we spared you the blooper reel.

Input is via five piezoelectric transducers (RadioShack #273-0073, $2.19 each) attached to analog inputs A0 through A4. We could have just used pushbuttons, sure, but we wanted something that could sense the pressure of each hit, and these were cheaper than force-sensitive resistors. Piezo sensors have a specific polarity, and the positive side (red wires) should connect to the analog inputs, and black to ground. There’s also a 2000 Ohm resistor added across each element:

Input for the reverb effect is straightforward. Two 10K potentiometers on analog inputs A6 and A7 (these are on the second row of analog inputs on the chipKIT Uno32, not present on Arduino). One controls the amplitude, the other controls the delay:

Finally, sound output uses high-speed PWM output on digital pin 3, passed through a simple low-pass filter to a headphone jack:

On our breadboard we’re using a handy little headphone breakout board from SparkFun, but one could just solder the appropriate wire leads onto a bare jack from “The Shack” (ugh). You may want to optionally add a 1 Meg pot just before the headphone jack. The circuit worked fine as-is with headphones or an amplified iPod speaker, but totally saturated our camera’s microphone input when fed directly.

This demo uses 16 KHz sound samples. As per Nyquist theory, the low-pass filter is then designed for an 8 KHz (-ish) cutoff frequency. For purely voice applications, half those rates should be sufficient (saving flash space and allowing longer samples), and the two resistor values should then be doubled.

And that’s it for parts. Can you believe it? On to the code…

To begin, we need something that can convert sound files into a format the C compiler can use. An ugly little UNIX command-line utility converts WAV files from a very specific format (8-bit mono, uncompressed) into C header files that can be #included by the MPIDE project. Arduino normally would use the PROGMEM directive to put these tables into the code flash space, but that’s not required here. Surprisingly, the much-loved Audacity program wouldn’t export 8-bit WAVs, but we found it possible to batch convert sounds using iTunes.

const signed char sample_drum[] = {
        0x02,0x03,0x01,0x00,0x00,0x00,0x00,0x01,
        0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,
        ...HUNDREDS OF LINES OF STUFF...
        0xff,0xff,0xff,0xfd,0xfd,0xff,0x00,0x00,
        0x00,0x00,0x00,0x00,0x02,0x00 };

We’ll spare you the horror of looking at that code or doing the conversion. You can download the complete set of project files here, and then adapt it to your own needs. The remainder of this article deals only with the MPIDE code.

But first, one fix is required: in our prior article, we encountered an issue with the chipKIT’s analog read speed, and a fix was discussed in the comments. This involves scrounging among the MPIDE source files for “wiring_analog.c” and changing a few lines. The old code resembles:

delayMicroseconds(99);
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);
mAD1ClearIntFlag();

This should be changed to:

delayMicroseconds(2);
mAD1ClearIntFlag();
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);

We’re told this change will be incorporated into later releases of the toolkit and this won’t be necessary for much longer. If you’re just ripping out the digital audio code from this project and ignoring this drum pad stuff, you can skip the change altogether.

And then there’s our sketch code:

// Mini sampling synthesizer for chipKIT Uno32.

#include "sounds.h"       // N_SAMPLES and data are here
#define PWM_PIN         3 // OC1 PWM output - don't change
#define SAMPLE_RATE 16000 // All samples fixed at 16 KHz
#define MAX_SOUNDS     10 // Polyphonic limit
#define MAX_ECHO     4000 // 1/4 sec fits in Uno32 RAM

short
  echo_data[MAX_ECHO]; // Circular buffer for echo

int
  echo_delay = 0, // Duration of echo effect
  echo_vol   = 0, // Echo effect volume (0-1023)
  echo_pos   = 0; // Current position in echo buffer
volatile int      // May change during interrupt:
  n_sounds   = 0; // Number of sounds currently playing

struct soundStruct {
  int sample; // Index of corresponding audio sample
  int pos;    // Current position within sample
  int vol;    // Playback volume, 0-1023
} sound[MAX_SOUNDS];

#define N_PADS N_SAMPLES // One pad for each sample

struct padStruct {
  short max;       // Max pressure during press (0-1023)
  short count;     // Timer for filtering out noise
  byte  triggered; // If set, currently reading a press
  short add;       // If >0, begin sound at next interrupt
} pad[N_PADS];

void setup()
{
  memset(pad, 0, sizeof(pad));    // Clear drum pad data
  memset(echo_data, 0, sizeof(echo_data)); // Clear echo
  pinMode(PWM_PIN, OUTPUT);     // Enable PWM output pin

  // Open Timer2, 1:1 w/256 tick interval (for 8-bit PWM)
  OpenTimer2(T2_ON | T2_PS_1_1,256);
  OpenOC1(OC_ON | OC_TIMER2_SRC | OC_PWM_FAULT_PIN_DISABLE,
    0,0);

  // Open Timer1 with interrupt for sample mixer (16 KHz)
  ConfigIntTimer1(T1_INT_ON | T1_INT_PRIOR_3);
  OpenTimer1(T1_ON | T1_PS_1_1, F_CPU / SAMPLE_RATE);

  delay(1);  // Slight delay avoids false trigger at start.
}

// Piezo transducers as input pads are fussy.
// To avoid false positives, a bit of hysteresis is used:
#define PRESS_MIN     20 // Must read at least this force
#define PRESS_COUNT    3 // for this many samples, then...
#define RELEASE_MAX    8 // Must read less than this force
#define RELEASE_COUNT 15 // for this many samples.
// Still imperfect; there are occasional double-triggerings
// and false triggers on adjacent pads.  Could be addressed
// with better mounting and isolation of pads and/or with
// improved input filtering in code or in hardware.

// The loop() function just reads pad and dial inputs; all
// audio work is done in the subsequent interrupt function.

void loop()
{
  int i, a;

  for(i = 0; i < N_PADS; i++) {  // Sample each pad...
    a = analogRead(i);

    if(pad[i].triggered) {    // Previously pressed?
      if(a <= RELEASE_MAX) {  // Yes, released now?
        if(++pad[i].count >= RELEASE_COUNT) {  // Really?
          // Sounds aren't added to play list here, just
          // flagged; they're added to the mix in the
          // interrupt.  This avoids a race condition
          // where this code may be trying to add a sound
          // while the interrupt is removing one.
          pad[i].add       = pad[i].max;
          pad[i].triggered = 0;
          pad[i].count     = 0;
        }
      } else {  // Still pressed...watch for new max
        if(a > pad[i].max) pad[i].max = a;
        pad[i].count = 0;  // Reset release counter
      }
    } else if(a >= PRESS_MIN) {  // Untriggered; new press?
      if(++pad[i].count >= PRESS_COUNT) {  // Really?
        pad[i].triggered = 1; // Flag to watch for release
        pad[i].count     = 0;
        pad[i].max       = a;
      }
    } else {  // Untriggered and below press threshold
      pad[i].count = 0;  // Clear press counter
    }
  }

  // Echo parameters come from potentiometers on A6 and A7
  echo_vol   = analogRead(6);
  echo_delay = map(analogRead(7), 0, 1023, 0, MAX_ECHO);
}

// This is the mixing/sample-playing interrupt,
// invoked at 16 KHz to match the audio sample rate.
// With guidance from Mark Sproul's PIC32 port of
// Brett Hagman's Tone library for Arduino.
extern "C"
{

void __ISR(_TIMER_1_VECTOR,ipl3) playSample(void)
{
  int i = 0, sum = 0;

  mT1ClearIntFlag();  // Clear interrupt flag

  while(i < n_sounds) {  // For each sound playing...
    // Waveform is cumulative, NOT averaged
    sum += (int)sample[sound[i].sample].data[sound[i].pos] *
      sound[i].vol;
    sound[i].pos++;  // Advance counter.  If end hit...
    if(sound[i].pos >= sample[sound[i].sample].size) {
      n_sounds--;  // Decrement number of sounds playing:
      // Move sound at end of list to the slot currently
      // occupied by the vacating sound (unless the same)
      if(i < n_sounds) {
        memcpy(&sound[i], &sound[n_sounds],
          sizeof(soundStruct));
        continue;  // Sound moved; dont advance index
      }
    }
    i++;
  }
  sum /= 1024;

  // Add in echo effect (if enabled) from circular buffer.
  // This takes place before audio level clipping so that
  // any clipping distortion won't be repeated in echo.
  if((echo_delay > 0) && (echo_vol > 0)) {
    sum += echo_data[echo_pos] * (echo_vol + 1) / 1024;
    echo_data[echo_pos] = sum;
    if(++echo_pos >= echo_delay) echo_pos = 0;
  }

  // Clip audio to 8-bit range.  This may cause distortion
  // when multiple sounds or echo exceed the 8-bit range.
  // Invoking the "quick & dirty" alibi again.
  if(sum < -128)     sum = -128;
  else if(sum > 127) sum =  127;

  SetDCOC1PWM(sum + 128);  // Set PWM output value 0-255

  // Check for any new sounds flagged by loop().
  // Done last because sounds finished above will
  // free up polyphonic slots.
  for(i = 0; i < N_PADS; i++) {
    if(pad[i].add) {
      if(n_sounds < MAX_SOUNDS) {
        sound[n_sounds].sample = i;
        sound[n_sounds].pos    = 0;
        sound[n_sounds].vol    = pad[i].add + 1;
        n_sounds++;
      }
      pad[i].add = 0;  // Clear flag even if not added
    }
  }
}

} // end extern "C"

Explanation:

The setup() function initializes two timers:

• Timer 2 and Output Compare 1 (hardware features of the PIC32 chip) are used for pulse width modulation (PWM). In conjunction with the filter previously described, this positions the speaker for each audio sample (Google for “PWM DAC” for explanations and examples). The PWM input clock is set to the chip’s full speed of 80 MHz, with an interval of 256 “ticks” (for 8-bit resolution), yielding a PWM waveform at 312,500 Hz. For this sort of DAC filtering it’s recommended that the PWM frequency be at least ten times the sample rate, so this is more than adequate for our needs. This is also why the code bypasses the native Arduino analogWrite() function for PWM, which operates on a much slower clock. Lastly, using Output Compare 1 dictates that we must use digital pin 3 for the audio output; this is one of the five native hardware PWM lines on this chip.
• Timer 1 operates at our audio sample frequency (16 KHz) and has an interrupt function attached. This function mixes audio samples and changes the PWM duty cycle of Timer2/OC1. The rates on both of these timers are set up once and never need to change, just the one duty cycle is varied.

This section of the code (and one line in the interrupt function) is admittedly not very Arduino-like, directly accessing hardware features in a non-portable manner. A more formal implementation would abstract these details into a library to which the novice programmer could just pass data. But for the sake of a simple, single-file demo, there it is, warts and all. In many ways, this is just a starting point to work from.

The loop() function reads the state of the piezo sensors and marks sounds to be played (received by the interrupt, later). There’s some crude debouncing of the piezo inputs…this really could use some more sophisticated filtering (which the PIC32 could easily handle), but it was skipped for brevity. The code generally detects varying pressure, but there’s still a fair bit of false triggering going on. In this function the reverb controls are also read: just two analogRead() calls, with the second one then mapped to the full length of the reverb buffer.

The interrupt handler is where all the fun stuff happens, and it’s surprisingly simple.

The extern “C” declaration makes the C++ compiler happy with the interrupt function declaration.

The program is designed for up to ten concurrent sounds, the details of which are held in the “sound” structure array (there’s more than enough CPU performance for greater polyphony, but it’s mostly just a matter that the input pads aren’t terribly practical for this). When a pad hit is sensed, a new item is added to this array (up to the maximum). Structure elements indicate which audio sample is used for this sound, the current playback position within the sample, and the volume level.

Audio samples are stored as signed values (rather than unsigned) because this makes them easier to mix (just add together) and easier to adjust gains (just multiply). Every opportunity is taken to use fixed-point math. From the prior fractal demo, we saw what a massive performance difference this can make — sometimes orders of magnitude. Most of our analog readings (returned as 10 bit integers from 0 to 1023) correspond to a gain (relative volume) value of 0.0 to 1.0 (or 0% to 100%). To perform this scaling in fixed-point units, add 1 to the reading, perform the multiplication (one instruction on the PIC32), then divide by 1024 (a simple shift operation, also one instruction). There’s no loss in accuracy vs. converting to floating-point; the source and destination values are going to be quantized anyway.

// Floating-point, slow:
// scale = float 0.0 to 1.0
out = (int)((float)in * scale);

// Fixed-point, crazy fast:
// scale = integer 0 to 1023
out = in * (scale + 1) / 1024;

Along these lines, note that where the audio samples are summed, this division is skipped until the end. This saves some cycles and the result works out the same. Algebraically speaking, (A/X)+(B/X)=(A+B)/X, and so forth. The interim 32-bit sum isn’t likely to overflow.

Fixed-point math happens again when applying reverb. The echo volume, in the integer variable echo_vol (10 bit again, from one of the analog knobs) is in the range 0 to 1023, corresponding to 0% (no reverb) to 100% (echo is as loud as the original sound). Reverb (in echo_data[] array) is a circular buffer — as sounds are played, the contents here (scaled by echo_vol) are first added to the output, then the result is placed back in the same position in the array and the position counter is incremented by one. When the end of the array is reached (or a shorter limit indicated by echo_delay) we “wrap around” back to the beginning.

The final resulting audio value is clipped to an 8-bit range. This may introduce clipping distortion when many loud sounds are used simultaneously. For brevity again, bells and whistles have been omitted, but courageous programmers could opt to add “soft clipping” here to limit such distortion. There’s ample CPU muscle.

The final 8-bit signed value is then transposed into the unsigned range and fed into the OC1 duty cycle for PWM output.

Lastly, the interrupt checks for any sounds that the loop() function flagged as being “hit,” and adds these to the concurrent play list. This flag-and-add behavior, rather than adding items directly in loop(), avoids a potentially nasty race condition whereby loop() could be in the midst of adding a sound just as the interrupt is removing others, throwing off the counter.

And that’s all there is to it. This demo only uses about one fourth of the storage on the Uno32, which itself has one fourth the capacity of the Max32…and we’ve yet to exploit any sort of compression. There could be some fun applications here, maybe adding better Super Mario sounds to toilets or voice prompts to other chipKIT projects (“Your door is ajar”). What other ideas could you see happening here?

Spring is upon us and Instructables user [Mischka] decided it was a good idea to combine two flavors we never considered putting together: The Easter Bunny and the A-Team.

He decided to build the egg as an Easter gift for his brother, who is a huge fan of the A-Team. He found a slightly larger than normal plastic egg, and proceeded to paint the shell white, adding a printed picture of Mr. T once the paint had dried.

The guts of the egg are made up of a Picaxe 08M micro controller mounted on a Picaxe protoboard. Rather fond of buzzing, beeping audio, he decided to forgo a normal speaker and opted to use a piezo instead. To activate the music when the egg is shaken, a tilt switch was added to the board as well. He uploaded his software to the Picaxe, sealed up the egg, and called it a day.

We can imagine his brother will be pretty pleased with the creation – who wouldn’t be? We only wish that there was video of the egg in action.

[Dan] likes Rock Band, but playing it makes him feel as useful as a one-legged man in an ass-kicking a drumming contest. He says that even using his friend’s ION kit leaves him searching out excuses as to why he’s not as good as he should be on the drums.

Eventually, he decided that he would settle things once and for all. The final excuse he came up with was that it is too difficult to press the drum pedal rapidly without getting tired, as the Rock Band gear does not properly simulate real drum equipment. Bass pedals on professional kits are weighted and balanced to allow the drummer to exert the least amount of work for the most return, resulting in a less tiring experience.

To give him a leg up while playing the game, he decided to rig a trigger to his Yamaha MIDI bass pedal, which is properly weighted. He consulted the Rock Band forums, and after looking at a couple of different circuit diagrams, he designed his own. He etched a PCB, mounted his SMD components, and was well on his way to becoming a drum legend.

He says that the pedal interface works quite well, and despite a couple of tiny soldering setbacks, he has yet to see any errant hits register in-game.

Be sure to check out the video below of his drum trigger undergoing some tests.

So let’s say you have a submarine, or a nuclear containment chamber which has walls made of thick metal. Now let’s say you want to transmit power or data through this wall. Obviously you’re not going to want to drill a hole since this wall is either keeping seawater out, or potential contamination in, but wireless signals aren’t going to travel well through dense metal. [Tristan Lawry's] entry in the Lamelson-MIT Rensselaer Student Prize seeks to address this issue by using ultrasound waves to transmit data and power.

In the video after the break [Tristan] speaks briefly about his project, then demonstrates the transmission of power and digital audio simultaneously through a two-inch thick steel plate. This is accomplished with a set of piezo transducers attached to both the inside and outside of the plate. Communications originate by feeding electricity to one transducer, which sends ultrasonic vibrations through the material to be received by its counterpart on the other side. It’s easy for us to understand data transmission conducted in this manner, after all that’s how the knock block receives information. What we don’t understand is how it can “transfer large amounts of electrical power”. If you can explain it in layman’s terms please do so in the comments.

[Thanks Larry via The Register]

Instructables user [tanbata] recently got his hands on a Google Anroid figurine and thought that while it looked great, it served no real purpose. He decided to change that, and converted this once-useless hunk of plastic into a miniature robot that moves and responds to sound.

He pried of the head of the figure and got busy fitting a servo into the Android’s body to enable head movement. An ATiny was added to control the figure, along with a microphone to enable it to respond to sound. A piezo was inserted to relay Morse code messages, and a handful of LEDs were installed in the body cavity and eyes of the figure just for kicks.

When the bot is powered on and senses a loud enough sound, the eyes light, the head spins from side to side, and the robot spouts off a random message in Morse code as you can see in the video below.

It’s not the most advanced project out there, but with a few tweaks, it could make for a great USB-powered email or IM notification system for your PC. Better yet, it’s a great project to do with a child who is interested in electronics, since they get to make a cool robot toy they can keep.

Here’s a way to make sure you don’t leave your Leatherman multitool somewhere. It’s an alarm system that will start a timer when the tool is removed from the holster. After five minutes the module beeps to remind you to put the tool back where it belongs. Annoying? Possibly, but if you’re not done with your work just press the reed leaf switch on the module to reset the timer. A PIC 12F683 handles the timing and generates the waveform for the piezo buzzer. Perhaps this could have been accomplished with a dual 555 chip like the LM556 (one timer for the countdown and another for the piezo waveform) but the PIC has power-down modes available that should make the button batteries last a long time.

[Goodhart] is sharing his process for building a couple different AM radios. It’s surprising how few components he’s using; the first build is just a germanium diode, some wire, and a piezo earpiece. But it strikes us that both of the radios he gives build instructions for have no power source. We’re also amused by the process of selecting the station. His example uses 770 AM, and requires you to take the wire and place it up in a tree with the two ends about 1216 feet apart. We think there’s something a bit off with the math, but with that much conductor to start with there might be enough induced current for you to actually hear something come out the piezo. We don’t think we’ll be trying this anytime soon, but we’d like to hear comments from those of you who do (or already have).