Let's Make Robots!

Embed Audio Signals?

So I got this nifty iPod plugged into Walter and I can easily control it with serial commands. If I were to want to sync say, movements of the head to the audio being played, I now can only do it manually... I.e. I would actually use a stopwatch and time when I would want each move to start/ continue and add the needed pauses to the code.

Remember those old film-strips in school? They had that beep to tell you to advance to the next frame. Could this "beep" be embeded into audio and be "read" by code? Maybe a super-high-pitched note that we can't hear but a pulsin could "hear". Or run the audio into an ADC and listen for a "silent"  that is say, 1 sec long. Or could I record a series of audio clicks that could be counted? 

There has to be a easy figure-out here if not, this shoulc be a fun thought-excercise... But really, how cool would it be to be able to sync head movements to the audio that is being played...

Gimme wha cha' got.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thanks guys (rik)...

I guess the next thing is to simply play some pure tones into a digital input and see if they can be read with a pulsin. Quick question though, do you think that different tones would also show up as different voltages going into an ADC input? I mean really, different frequencies (audio or otherwise) is really just a bunch of on and off's right? Is an audio tone in reality a PWM signal? Maybe I should try a series of tones or a sweeping one and just see what comes in from an ADC channel. Oh! I love experiments!!

Volume is the easiest setting to manipulate in Audacity or similar software. I have no idea about the reliability of such a modulation though. Different software may produce different ADC volumes in the end. And software differences creep up everywhere. Even when using the same program (Audacity) every time. Every little setting would potentially screw up the resulting output signal, volume wise.

It really depends on the frequencies played and the speed of your ADC - if a square wave's half period is shorter than the ADC's acquisition time, then you'll (usually, depending on ADC architecture) get an analog value like you'd expect from an averaged PWM signal. If the waveform is anything other than a square wave you'll still get analog values out, but the readings will be a little more complicated.

Proper music players have multi-bit DACs used to produce the output waveforms, which means they're not simple 'on and off' square waves like you'd get from a PWM generator. If the duty cycle of several waves is the same, and the waveform is the same, then the ADC will get the same analog reading regardless of the waves frequency, provided the frequency is high enough. If the frequency is too low you'll get all sorts of weird readings from the ADC, due to conflicts in wave transition timing with the ADC sampling period.

If you want nice, clean data from your audio-driven ADC you've got two options as I see it:

1 • Square wave audio, with maximum frequency no more than half the ADC frequency. Each ADC reading will give you an 'on' or 'off' that you can use immediately. If you get anything other than almost zero and almost maximum, this means the wave changed during the reading, and you can either use it to signal an incoming bit, or just discard the reading.

2 • Any waveform you'd like (square is still good), but with frequency significantly above the ADC frequency. Now we're looking at something a lot closer to PWM, where the averaged input will give you an analog value that corresponds to the duty cycle of the wave being read at that moment. Instead of basic binary serial you can now encode potentially an entire byte worth of data into a single tone. This is going to be a more complicated option however, and it's quite likely that your iPod won't be able to produce a high enough frequency to outrun the ADC.

Walter's voice on the left audio channel. Anything else on the right channel. Goes directly into your ADC for whatever purpose you want to give it.
Good point Rik, record the music in mono on one channel and instructions (digital or analog) on the other.
20kHz should still be sufficiently high to be virtually inaudible to someone with even then sharpest hearing - although if you have any pets it may be a different story =)

Because your music is digitally encoded and using an MP3 for playback you won't be able to use frequencies higher than 20Khz as the sample rate is usually limited to 40Khz. You need a high and a low sample minimum to make a tone.

Perhaps a better way would be a circuit like they use for disco lights to make them flash to the beat. Then your software can just count the beats to syncronise movements and eye colours. 

I made this circuit recently using an LM324 quad op-amp for flashing our LED spotlights to the music. It is designed for 24V DC but should work on lower voltages. I can send you an assembled PCB if you want.


It has a FET output capable of driving a 30A load but with a suitable voltage divider (depending on what voltage you run it at) across the output it would drive a digital input nicely. 

You are right on target... I just need a little "mark" signal and the "personality code" ie head moves would take it from there in terms of a pre-determined series of movements. In terms of syncing the other way, I would need this mostly in a demonstration style situation. I.e. "I am Walter, I have cool LED eyes, here they are "mark"".--and the "Do cool eye move code" would take over.

I was also thinking about  the high-pitched "chirp" idea but I guess I just have to do some trials with "pulsin" and/or "count" and/or a stand-alone circuit or whatever to see what the chip can "hear". Not to mention, I am a podcaster with a lot of audio hardware and software but I just dont know how I can produce a simple tone that high!

Good feedback, everyone keep it coming.

I like the idea of using high frequencies to embed data into the audio stream - a few ms of, say, 40kHz could signal the start of a data packet, and the message would follow in classic asynchronous serial style, with perhaps 40kHz for a '1' and 30kHz for a '0'.

If Walter is selecting the audio track himself, then I guess all you need are markers like the ones you mentioned - Walter would have a list of sequential commands to initiate as each marker is read from the audio. Not quite as elegant as embedding serial data bytes into the audio, but probably easier to put together.

Have you thought about approaching the problem from the other direction, and syncing the audio to Walter's movements? If you're looking to use sound effects, etc, then this would be quite easy, but naturally music won't work so well if every few bars the audio stops while Walter catches up, or skips ahead if Walter is too fast =)