What transmitter receiver setup is best for me, and how do i set them up?

[LegitimateOG]

What i need to do is transmit x, y, z data from an accelerometer to a serial to usb converter, which will be connected to a pc.
I plan to have more than 10 accelerometers connected in this fashion to the pc, so capacity for this is necessary.
The purpose of the accelerometers is to track human body movement.
Smaller is better.
I plan to power via 3.3v AA battery pack on accelerometer side, and usb (which I believe will be dropped to 3.3v) on the other side.
I believe the communication can be one-way as no data needs to be transmitted to the accelerometer.
I want the data transfer rate fast enough that any delay between reading from one accelerometer to the rest is not noticeable to humans.
This device will be packaged in with the product I plan to sell, therefore isolating the channels of communication is important.

This is the accelerometer I am using currently: https://www.sparkfun.com/products/9269

If there is a solution that can transmit and receive right out of the box, that would be preferred.
I am open to changing any of my current equipment if you know of a set that works together.

 

[kellys_eye]

Bluetooth springs immediately to mind. But without knowing the data rate, sampling rate etc it's just a 'guess'.

 

[duke37]

If you have ten accelerometers, how are you going to stop clashes in the data unless each accelerometer is asked to transmit. In other words they will need a receiver.

 

[hevans1944]

The ten (or more) accelerometers are analog devices. You will need to digitize (at least) thirty analog signals and then send this digitized data to your serial-to-USB interface, presumably using some sort of wireless data link such as Bluetooth or XBee. That's not the hard part.

The hard part is defining how many bits of resolution you need for each accelerometer axis, how fast you need to update those bits among thirty or more accelerometer axes, what type of serial encoding and data integrity you need, based on the worst-case bit-error-rate of the communications link, and how you are going to power all this with a 3.3 V AA battery pack for any reasonable length of time (in other words, define a power budget).

A reliable data link requires two-way hand-shaking and error-correction to maintain data integrity. This has nothing to do with the accelerometers (the data) per se, and everything to do with how the data is encoded for transmission and how error detection and correction is implemented... all more or less trivial tasks for any decent sized microprocessor paired with a Bluetooth or XBee transciever.

You need to perform some "back of the envelope" calculations to determine what data throughput rate you need. Serial ASCII is not the most efficient way to send massive globs of real-time data, but it does have the advantage of being easily manipulated at the PC end of the data link. Even at the maximum serial data rate, there will probably be a noticeable delay between updates, but choose an encoding and do the math yourself. You can "mix and match" identification strings in with the accelerometer data to allow easy separation and display of the data on the PC. Or, if this seems to be too much trouble (extra coding required!), you can just count frames from a unique ID frame thrown into the stream of data to identify which data belong to which accelerometer. Clearly, all this is a form of serial multiplexing and is the slowest of all possible data links. It gets a lot more complicated if you want to move data at warp speeds.

I think you have a good product idea... a sort of Fitbit on steroids... but now you need to do your homework and flesh it out with real design specifications before even considering building anything.

 

[LegitimateOG]

Thank you very much for the replies. Especially hevans1944 for the incredible detail.
Btw - I am developing this project alone with no knowledge of communications, and without knowing anyone knowledgable in communication, so if some questions sound stupid or obvious, that is why I am here .

I have done some homework based on the accelerometer I originally mentioned and with theorizing the use of XBee Series 1 - 1mW (Trace Antenna)

I determined what the minimum response acceleration of the accelerometer would be based on what bit resolution was used. The results are: @ 12 bits of resolution the accelerometer will respond to an acceleration greater than 4.5mm/s² and @ 16 bits of resolution, response when acceleration is greater than 0.28mm/s².

I'm guessing I will be using 14 accelerometers in the end, each with 3 axis, therefore 42 data channels. 42 * 12 bits = 504 bits total, or 42 * 16 bits = 672 bits total.

The datasheet of the XBee lists two data rates: RF Data Rate @ 250 kbps and Serial Interface Data Rate @ 1200 bps - 250 kbps. (I assumed I would be using the latter) If my math is correct, this means that one XBee will have no problem handling my data if I am sending (the bit totals) per second. Depending on what the minimum bps for Serial Interface Data Rate means. Do I need to be sending a minimum of 1200 bps? Or if I have a lower number of bits, will it be sending those bits multiple times per second? If it is sending more than once per second will the "duplicate" bits be holding the same information or not?

Questions about using XBee: Is the multiplexing handled by programming/configuring the XBee? Or would I need to implement a multiplexer receiving the ~42 data channels before sending to the XBee? Also is a microprocessor required to interface with an XBee, or can a microcontroller be used? The XBee has 8 digital i/o pins, do you think it make more sense to get 3 sets of XBees and use parallel communication over serial, considering crosstalk/interference and cost versus simplicity and speed?

Im sure I still have much to learn thanks for helping out!