Bluetooth is a term that covers a protocol stack and the hardware specification required to implement radio based links between two or more devices in a standardised way. The aim is to allow consumers to be able to purchase "Bluetooth" capable devices from any vendor and that those products should function with each other without issue. Thus your Nokia mobile phone should function with a Motorola head-set or the hands-free car kit in your BMW without any issues or problems.
Allowing "anything" to connect to "anything" via the Bluetooth protocol does not always make practical sense, neither is it always worthwhile. For example, does it make sense that a Bluetooth enabled printer can connect to a Bluetooth headset? Additionally, the type of data you wish to transfer over the Bluetooth link is important to know. For example, if I wish to print something out via Bluetooth, I am more concerned that my letter is printed without error rather than how long it takes (within reason). For audio, I am more concerned that I have a stream of continuous audio without breaks, pops or crackles but if a millisecond or two of audio is lost occasionally or the signal is not 100% accurately reproduced upon arrival, I probably won't hear this. (Hence, if you are an audiophile, Bluetooth is not a choice you would consider!)
Thus, depending on what type of data and functionality is desired, the Bluetooth SIG (they write the specification) have defined different "profiles" to cover them. For a plain vanilla data connection to provide a wireless alternative to a COM/RS-232 type connected, you have the "Serial Port Profile" or SPP. For high-quality audio transfer you have the "Advanced Audio Distribution Profile" or H2DP. For low-quality telephony audio for head-sets you have the "Head Set Profile" or HSP. (see http://en.wikipedia.org/wiki/Bluetooth_profile)
So, to the Arduino BT module. Looking at the brief overview it seems to be targeted at serial data transfer and I am probably not far wrong in saying that it uses primarily the SPP profile. Thus the data rate on offer will vary wildly depending on factors such as distance, interference etc. Not an issue perhaps for wireless data, but no good for wireless audio where a 'as good as electronically possible' minimum data rate needs to be guaranteed.
Thus you need to look for a Bluetooth module that supports the A2DP profile, of which there are many (randomly found product is here http://kcwirefree.com/audio.html)
A system build up for an audio link via Bluetooth could look as follows:
Audio In/Out <-> Audio CODEC (hardware) <-> Microcontroller <-> BT Module <-> Antenna
or
Audio In/Out <-> Audio CODEC (hardware) <-> BT Module <-> Antenna
^ ^
| |
Microcontroller
Note that there are some BT modules that have all the necessary support and only require the external Audio CODEC and no microcontroller at all.
The audio CODEC is a hardware chip that converts analogue audio signals into a digital bit stream, as well as doing the reverse, which has a interface functioning similar to SPI except the clock runs continuously. Such an interface is often call I2S. They also have a real SPI interface that is used to configure the CODEC (sample rate, amplification of signals etc.) An example from Wolfson is here: http://www.wolfsonmicro.com/products/codecs/WM8731/
The microcontroller performance depends on how much of the Bluetooth protocol is implemented in the Bluetooth module. The Bluetooth protocol stack splits fairly neatly in two; below HCI and above HCI, where HCI stands for Host Controller Interface. Bluetooth implementations for PCs (as an example) use Bluetooth modules/chipsets where only HCI and below is implemented, and then rely on the the PC operating system to run the HCI and above portion of the software stack. The upper half of the stack requires a decent performance processor (own experience says 16-bit and 16MHz or better considering you probably want to run your own application too!) Many Bluetooth modules have the whole stack and much more running on them and then offer some sort of proprietary protocol over a serial interface (USART, I2C or SPI) allowing you to interact with the Bluetooth module. This protocol allows you to choose the profiles you want to use, set up a PIN code, create and destroy connections etc. In this case a simple 8-bit microcontroller with a few kBytes flash and a few hundred bytes of RAM should suffice for implementing an audio link.
Bluetooth is not a simple protocol to implement. Even the big consumer electronics manufacturers have challenges to get it right (although they have more at stake if it doesn't work perfectly all the time!)
It may seem like a cop-out/taking the easy path but I would seriously recommend using a module solution that is designed to support audio over Bluetooth such as the link already mentioned (http://kcwirefree.com/audio.html) Your chances of success are much higher and you will be able to concentrate of some other cool features you may want to implement rather than struggling to make the Bluetooth link work.
Please note: I am in no way related to any of the companies I mentioned here - they are simply the most relevant links that appeared highest on Google when I looked.
Hope this fills some knowledge holes. Feel free to add any corrections you see necessary!
Best regards, Stuart
That was - early in the history of LEDs - pretty common, even without the PWM stage. Depending upon the angle of the IRLED, you can get a VERY long distance out of one... but aiming gets rapidly more difficult with longer distances. A very carefully aimed IRLED with a very narrow beam can transmit audio reliably over several miles in clear weather.
The greater the distance, though, the greater the likelihood of incidental noise from reflection, refraction, and air movement.
The old Popular Electronics magazine published several articles long ago about transmitting unmodulated audio with IRLEDs. Back then, LED beam angles were nearly all pretty broad, so theirs required focusing/collimating lenses. Today, you can easily find IR laser LEDs so there's little need for collimating lenses except arguably at the photodetector end.
Best Answer
Interesting design - literally the simplest thing that could possibly work.
The risk of damage to the audio devices from this setup is pretty minimal, as there's no external power supply involved. The only question is the current tolerance of the output of the cellphone headphone driver. Make sure all your exposed wires are insulated from one another (tape, heatshrink etc).
Adding an amplifier to the system is an idea in the right direction, although now you're at risk of destroying the LED driven by it - extremely likely with an audio amp of any power.
I would suggest building a standard transistor LED driver (e.g. Driving LEDs from audio signal ). Use a visible LED first to check it's working then swap it out for the IR one.
It's also worth applying volume normalisation to the WAV file you recorded and playing it back at maximum non-distorting volume.