In an earlier post, I mentioned my daydream of a distributed sonic-disruption device. I’m thinking the best way to approach this project is to break it into several small pieces and offer those pieces separately. Those individual pieces might prove useful for many other purposes.
Sound Player: A compact, inexpensive, low-power device capable of playing back sounds from a FAT32-formatted micro-SD card (like those included with new mobile phones). Ideally, it would be centered around a cheap microcontroller (yes, the AVR+Arduino might be the best choice). The microcontroller would use a resistor ladder or a high-frequency PWM output for the digital-to-analog conversion. In any case, the audio quality needs to be decent (for music), but not stellar — so no separate audio codec. The output would either be line-level, or have enough power to drive headphones. If more power is needed, you need an outboard amplifier. With some extra code, the microcontroller could read multiple inputs (A/D, digital, and serial UART/MIDI) and could act as a simple synthesizer. Hook the thing up to some variable resistors and switches and you have a purpose-built sampler. Not too interesting by itself, but by customizing the source code, the inputs could control a glitching algorithm or provide a means to scrub back and forth through samples kinda like scratching a record. Or maybe you could hook it up to a capacitive sensor bar — then you could really scratch! If the capsense device could support multi-touch gestures, you could do something Monome-like, selecting chunks of samples to loop, restarting loops, reversing loops… OK, I’m drifting from the topic.
RF Trigger: A small RF transceiver, based on something simpler than BlueTooth or Zigbee. Perhaps one of the Nordic Semiconductor RF24L parts. The protocol should ensure that you won’t set off the sound bomb when most of the slaves aren’t in-range (which would lessen the impact). The protocol would be simple:
- Slaves transmit their existence and ID periodically (at random intervals to avoid collisions).
- Master acknowledges slave beacons and keeps a catalog of slaves and last-report times.
- Master receives a “trigger” event and transmits an “arm” signal to the slaves.
- Slaves acknowledge the “arm” (using their ID as a hold-off to avoid colliding with other slave ACKs).
- If the master receives ACKs from all (or most of — user preference) the expected slaves, it sends a “fire” signal.
- Slaves receive the “fire” signal and emit a signal (or maybe a whole byte worth of I/O pins)
This device would be handy for Halloween, for photography (maybe the remote bird photgraphy project in MAKE Magazine a few months back). It’d even be handy for robotics.
The sound bomb system would also require an amplifier (I’m thinking an ultra-efficient, compact class-D amp) and a regulator to drop the battery voltage to something safe for the circuitry.
Oh, and on the master system, you’d want a big red button. Maybe somebody sells surplus game show plungers?