A year or so, I was getting into digital video cameras and was thinking how great it would be to have an open-source camera platform. The hardware design and low-level driver stuff would be implemented already, so people could easily build their own dream camera software. There’s already some precedent for this, with the Canon EOS 5D Mark II “Magic Lantern” firmware, which is a truly amazing work of reverse-engineering. But because the 5D Mark II is closed hardware, there’s still a limit to what the Magic Lantern people can do.

Well, I saw on SlashDot today that some researchers at Stanford plan to offer a Frankencamera, an inexpensive, open platform for still camera algorithm development. I’m anxious to see this camera produced and what people will do with it.

So here I am, enjoying a week of vacation from my day-job, and a little break from the steady stream of ShareBrained orders that have come in over the last couple of months. And what should arrive in my inbox? This, from Emmanuel in France:

This is astounding craftsmanship. I must say I am humbled. I never imagined my modest little clock kits would be worthy of such incredible attention and craftsmanship. It gives me immeasurable delight to know I am, in some very small way, helping to bring these beautiful works of art into existence. I’m so grateful for the opportunity. Thanks to all of you.

We’ve posted some of our favorite Chronulators in our new Chronulator gallery. We’ll be adding to the gallery as time permits. You can also see (or post) Chronulators on Flickr.

If you have a Chronulator and haven’t sent us pictures or posted them to Flickr, what are you waiting for? Send them to ideas@sharebrained.com or post them under the Flickr tag “chronulator”.

UPDATE: Texas Instruments has a neat little video on powering their MSP430 microcontroller from fruits and martinis! The Chronulator uses the same chip, although the meters draw substantially more current — you might need something bigger than a couple of grapes…

I want to try powering a Chronulator from some alternate power sources. Batteries and AC adapters are so boring.

The Chronulator requires 2.0 to 3.6 volts (V) and about 100 microamps (uA). That’s a miniscule amount of power. So this should be easy. I’m thinking a potato battery, and a small (just a few square inches) solar cell.

For the potato battery, I’ll likely need three or four “batteries” in series to get enough voltage. There should be plenty of current.

Since we can’t count on the sun for power at night, the solar cell solution will use a super-capacitor. The super-cap will charge up with excess power during the day, and release it at night. I bought a super-cap from All Electronics a while back. Maybe I’ll grab a RadioShack solar cell and see how this works in practice. I’m concerned that the super-cap might bleed down too quickly at night… But if this works, it’d be super-simple — no charging circuit necessary!

This is awesome. An implementation of USB 1.1 (low-speed) completely in software. Imagine projects with USB interfaces that have no additional, expensive, hard-to-solder ICs… Talk about simple. I gotta do something with this.

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?

I was at the finish line of the “Hood to Coast” running relay race a few weeks ago. As each team’s last runner approached the finishing area, the rest of the relay team was called up to run with them, across the finish line, together. As each team finished, an announcer called out the team’s name.

Some of the team’s names bordered on the obscene, others were named after songs. One team was named after the Beastie Boys song, “Brass Monkey”. My mind drifted to other Beastie Boys songs and locked on to “Sabotage”. For those not familiar with the song, it starts with some extremely loud and in-charge guitar and drums. It seemed to me to be the ultimate, dramatic “finishing” song. If only the organizers would be willing to play team songs over the PA… Of course, there are many reasons why they wouldn’t. It’d be a logistical nightmare to get CD tracks or MP3s from the teams in advance, and the organizers would no doubt need to pay ASCAP or BMI for the rights to “perform” the music. But what if the team or their support crew could play the song, guerilla-style?

I turned that thought over in my head for a bit. You couldn’t bring in your own PA. It’d be unwieldy and would attract attention. It would require set-up and power. You’d need a portable, self-contained PA. I’d seen that before… A guy came to my DorkBot “chapter” recently with a battery-powered amplifier/speaker cabinet. It was a wood box with a battery (probably lead-acid), a fairly hefty solid-state amplifier, and a speaker. Take that idea and build it into a smallish box (backpack-sized) with some sort of audio source — maybe an inexpensive FM receiver?

But a single system loud enough to have the desired effect would be too large for a backpack — without causing severe skeletal trauma, that is. Parallel-ize the solution — make six or so smaller cabinets. How do you make sure they all play the same sound at the same time? Put FM radio receivers into each? That would work, but seemed inelegant. How would you make sure the cabinets stayed tuned-in but quiet and innocuous until blast-off? And where would you find a decent, semi-powerful FM transmitter and how would you power it? And what about the FCC?

Perhaps the solution is to put the audio source inside each box. Have a digital audio playback device (something like a simple MP3 player), capable of playing just a minute worth of audio. Maybe it could reuse all these useless CompactFlash micro-SD cards that come with mobile phones and cameras. Trigger the playback in each box using a low-power, low-bandwidth, long-range wireless technology. I don’t think a BlueTooth UART link would work — can you pair one transmitter with multiple receivers (broadcast)? Maybe ZigBee? Or a super-simple, proprietary (Nordic) or IEEE 802.15.4 transceiver? Make each system hold up a two-way link. The master box would transmit a periodic beacon and receive responses from the slave boxes. The slave boxes would have an indicator showing if they were in range. And the master trigger would not fire unless all the slaves transmitted an acknowledgement and received a secondary go-ahead from the master (after all the slave acks are received).

So what could you do with this? I must confess I haven’t thought too much about it — the technical design challenge is enough to keep me distracted for a while. But you and your five closest friends could take these boxes on a walk to a public square or parade and drop a short political speech or social commentary sound bomb. And because the audio would eminate from many directions, it would be immersive and perhaps difficult to identify the exact source. That could be fun…