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
First of all, the comment regarding your intended application is very important. For this answer, I'm going to assume the you want the highest data rate possible (i.e. Wii-type controller that sends near-instantaneous data). I give you two options below. In both cases, the receiver is simple: receiver board (either another XBee or the sister board of the transmitter you are using) connected to a USB-serial converter connected to your computer.
Option 1: Really easy to build, not-so-low power
An XBee 1mw Chip Antenna can be configured to transmit at whatever datarate you need, has a max. range of 100m, and, best of all, has six on-board ADCs. You can configure the XBee to automatically sample these and transmit their values. X, Y and Z from the accelerometer can go directly into AI0, AI1 and AI2 pins on the XBee and they can both be fed with 3.3V.
- Good: You only need a battery, the accelerometer and the XBee to transmit, and another Xbee to receive.
- Bad: The XBee has 45mA peak current when transmitting.
Option 2: Not so easy to build, low power
The transmitter board you mentioned can be powered by 3.3V (according to the datasheet). Alternatively, you could use this 2.4GHz transciever. In both cases, you will need a microcontroller (easy) or an ADC with serial output (harder, will need a PCB, something along the lines of the MAX1245) to convert the analog signals from the accelerometer to digital signals for the transmitter. I recommend you use a microcontroller (Arduino Pro Mini 3.3V for prototyping, then just an ATMega328 when you're done with the design).
- Good: Low power (7-10mA).
- Bad: Will cost a lot more design time and burnt fingers.
Option 3: Stereo FM transmitters modulating 3 channels of data
This is in response to "Can I do it without converting the signals?".
- Use resistors and op-amps to bring the accelerometer's readings down to 90mVrms.
- Use two of these stereo FM transmitters, hook up X to Rin, Y to Lin, and Z to Rin of the other transmitter.
- Configure the transmitters to Tx on different frequencies.
On the receiver side:
- Aquire the FM signals and demodulate back to right and left audio. You could use something like this.
- Amplify and offset the three channels (right and left channel on one, and only right on the other) to measurable voltages (op-amps would work, but I have a feeling we just added a ton of noise to the whole thing).
- Plug these signals to any microcontroller (Arduino, if you're feeling lazy) with ADCs and send them out as serial data to your computer.
NOTE: Most FM tuners will have band-pass filters that will screw this whole idea up.
Best Answer
The ADXL335 outputs analog data so you can use the ADC on the xbee look at this Guide