SparkFun Forums

[lmc169]

My idea is a remote cloner, a basic device that when you point a IR remote at it, it remembers what the remote said so it can spurt it out via the microphone port to my computer and audacity where it can record it as sound. That can then be saved as an MP3 and put onto my MP3 player where it can spurt out the same IR code that the original remote gave out. Complicated yet?. I have just ordered a IR Receiver breakout board from sparkfun and I would like to know how to connect it to an arduino or have I just wasted my money?

Thanks
Luke

http://www.sparkfun.com/commerce/produc ... ts_id=8554

[Random]

Saving it to an MP3 seems way overkill - is there any specific reason?
I'd go for storing it as the data you record, the series of 0s and 1s that the breakout board sends out.

You could then store that in EEPROM or similar - the Arduino chip actually has some onboard EEPROM you could store the data in.

As for interfacing it to the arduino, I'd connect the data pin to any old pin and have a push switch start monitoring the pin in a loop.
When the state changes, add the change to a buffer, and then wait for the next state change. You should be able to build up the received transmission.
Perhaps make the user record anything twice so you can verify you got the right code?

After that, have another switch to send out the recorded transmission, or something.

[lmc169]

Thanks for quick response
1) I was using the MP3 player so that the files could be stored on the device with easy navigation (just play the file/remote function you want), power and portability. I dont particularly want to be lugging my arduino round when I want to turn off a TV. I can also chop up codes in audacity to make special functions (go to channel 19)

2) I am the user. This is a project so that when we loose the remote we have a 'spare'

3) I need to store something like 150 codes for various remotes (car stereo, TV, freeview box, the list could go on and on and on and on...)

4) I have no idea how to use a buffer

Thank you very much and sorry im ranting
Luke

[Random]

Aha, I can see why you'd want the MP3 player.

Sounds like a pretty neat idea.
However, I'm still not entirely sure how easy it would be to store MP3s that accurately contain the data, and then send them to the IR transmitter - it seems you'll still need some kind of microchip connected to an IR transmitter -- the SparkFun unit seems to be just a receiver -- and in that case, you'd probably be better off storing the IR codes on the microchip.

[lmc169]

I am basing this project on the Griffin iRemote.
It was a little thing you plug into your ipod and it could control your IR stuff via recording codes on your PC and playing them back as sound files.
Google it

Luke

[bigglez]

Greetings Luke,

My idea is a remote cloner, a basic device that when you point a IR remote at it, it remembers what the remote said so it can spurt it out via the microphone port to my computer and audacity where it can record it as sound.

Good idea. The amount of data from an IR remote
is just a few bytes. Holding the key modifies the
IR code, but repeats it as long as the button is held.

That can then be saved as an MP3 and put onto my MP3 player where it can spurt out the same IR code that the original remote gave out. Complicated yet?. I have just ordered a IR Receiver breakout board from sparkfun and I would like to know how to connect it to an arduino or have I just wasted my money?

Certainly not a waste of money!

There are several data rates for different IR
remotes (Sometimes called 'frequencies', but more
like 'baud rates'). Some IR receiver chips have
the bandpass filter built in, so the signal from a
remote on another data rate will be ignored. There
are three data rates in play, AFAIK.

A universal IR receiver would have all of these
by adding extra receivers on the different rates
and using code to identify which one is which.

Another member here (oPossum) has a really
neat gadget just for this job. Read more here.

Comments Welcome!

[Random]

Using audio files, you may find you can just plug that IR receiver into your microphone port -- the microphone has two pins (unless it's stereo, in which case use just one channel), so if you connect GND from the IR receiver and the data line into the microphone port, and supplied 5V to the IR module via another power supply, you may be able to record the IR signal as audio. Note that you'll need to check that the PC can take 5V as an audio signal, and the resulting file may be pretty noisy, but it's as good as connecting the Arduino to a microphone port.

Once you have the MP3, working backwards -- plugging the headphone port into an IR transmitting LED -- may send the signal back out.


However, I'm not sure that the SparkFun module will transmit everything you need to know to reproduce the signal, as it looks like it may just output the actual signal data. This would make reproducing the signal pretty difficult!

[lmc169]

Thanks for the support!
The reason that I wanted to record the signal in audacity is that it keeps the data rate (i think..)
Should I get separate rate transmitters and connect them in parallel so that they send out the same thing just at different speeds?
I have heard of oPossum but everything on his site is way to complicated for me. I would love to build something like that its just that I dont have the capability to do it.
Is this possible?

[Random]

Looking at the datasheet (here: http://www.vishay.com/docs/81603/tsop85.pdf ) it seems that it does output only the data, not the rate it's transmitted. This would probably not be so useful for sending the data out again, unless you can find out the data rate your TV uses, and have a microchip output the correct data on an IR.
It may be possible to take this into account while recording so that the MP3 reflects the output data you require, in which case an IR LED would be able to send out the data from the MP3.

[lmc169]

is it possible to just connect up the data receiver to arduino pin 9 and microphone to in 10 and do something along the lines of this:

Code: Select all

if (pin 9 is a 0){
mic LOW
}
if (pin 9 is a 1){
mic HIGH
}

obviously it would be a bit more complex than that but would it be possible? is the data rate just how fast the remote outputs 0's and 1's or is it different?
thanks for all your help
Luke

[Random]

If you were just doing that there's really no point to having the Arduino at all, you could just plug the IR receiver into the mic port.
However:

The IR receiver will receive data as a series of very fast on/offs for each overall 'on', if you look on the datasheet it has graphs of how this appears.
It will just send a 1 for each total '1' it receives, but that will be made of perhaps 1, perhaps 100 pulses of IR light. 0s are outputted when there's no IR light at all, I believe, so while you will get the IR data, you won't get the rate it's transmitted, which means you won't be able to recreate it.
You may be able to find out how fast it's transmitted and hence have the Arduino recreate that instead, however.

N.B.: I could be wrong, this is just what I've gathered from reading the datasheet.

[lmc169]

thank you very much
I am shattered and i might just fall flat onto my keyboard if I stay up much longer.
Thanks for all your help and i will look into this in more detail tomorrow.
Luke

[riden]

From what I can determine, the Griffin iRemote was not meant to allow the iPod to control devices, but for the iPod to be controlled by an IR remote. I don't think it made it to market.

If I understand your idea, you want to produce a MP3 file that contains the sampled IR stream (including the carrier) that your MP3 player would feed to an IR LED to transmit the codes. A problem with this approach is that the frequency sampling rate has to be 2x the maximum carrier frequency. That means your sample rate will be 76KHz for 38KHz remotes up to 112KHz for 56Khz remotes. These are very non-standard MP3 rates meaning that your MP3 player probably won't know how to decode your file if you were able to create it. The fact that the carrier gets turned on and off with the data is another issue. MP3 encoding is not a lossless technology and I'm pretty sure that it won't be able to accurately reproduce the rapid on and off switching of the carrier because of the way MP3 obtains its data compression. But, it would be interesting to see if it could. It would be fairly easy to test this without having to build much in the way of circuitry.

Here is an idea that MAY allow you to use MP3 data files to store remote sequences. It does, however, require some additional circuitry: On the MP3 player side, you need a way to select a carrier frequency and then turn the stream on and off using the data. A system could be designed to encode the data using FSK (frequency shift keying) and then the carrier frequency value could be embedded in data stream. Your player would need an add-on that can decode the FSK data, act on the data stream, and then generate and switch the carrier on and off. Of course, you will need to generate the MP3 file using FSK data encoding on the encoding side.

I think that you have an interesting idea, and there may be ways to make it work. However, I don't think it will be as simple as you were hoping.

[oPossum]

The Griffin product used two half frequency sine waves out of phase by 180 degrees (one in each channel). Each channel was connected to an IR led in such a way so that when the sine wave peaked it would emit a short IR pulse. The result is an IR carrier at twice the max frequency of an audio player (~22 kHz). Very clever scheme. I think they used wav files, not MP3 or AAC.

[oPossum]

The Griffin product was called Total Remote. It was for Windows Mobile.

Great explanation of how it works