SparkFun Forums

[Asli]

Hey,

I do not have any bluetooth experience. I want to ask expert advise;

I am planning to connect some sensors (3 x accelerometers and 3 x gyros) to a microcontroller (AVR or PIC or something similar). This microcontroller will regularly sample the sensors at approximately 500 Hz and it will transmit the sensor data via bluetooth unit to a PC.

Data throughput of the micro controller will be
(3 accelerometers + 3 gyros) * 500 Hz * 16 bits/sample = 48.000 bits/sec

I am planning to use the following bluetooth modules for the microcontroller and for the PC
* Bluetooth SMD Module - Roving Networks
http://www.sparkfun.com/commerce/produc ... ts_id=8497
* Bluetooth Modem - USB Roving Networks
http://www.sparkfun.com/commerce/produc ... ts_id=8496

Sensors will measure 6 DOF motion of a moving mechanism. The mechanism will be actuated by a highly accurate, professional servo drivers. The driver electronics provides accurate timing pulses for the external devices to syncronize. Frequency of this pulses can be selected from the set of 1000Kz, 500Hz, 100Hz, 10Hz and 1Hz.

I can wirelessly send the timing pulses to the microcontroller to syncronise the sensor sampling process. For my application time registration of the sampled data is very important.

QUESTIONS;
* What I want to learn is that if there is a delay on the bluetooth link between microcontroller and the PC?

* Is this delay constant or predictable or random?

Thanks

Asli

[wiml]

Yes, there is a random delay. Bluetooth batches transmissions up into packets, and the receiver acknowledges each one; if there's some radio noise or something, the transmitter will have to retransmit. So, at the least, you have the packetization delay (characters wil come out of the receiver in discrete bursts even if they're fed into the transmitter continuously). If you're in a noisy RF environment, or are near the limit of the modules' range, there will also be unpredictable longer delays when a packet gets lost and has to be retransmitted. The delay is usually small but occasionally large, so you might still be able to keep two clocks in synch if you're clever about which delay information you discard. You might want to look at the design of the network time protocol NTP, which has to deal with a lot of the same problems, for ideas.

The bluetooth radios do have internal clocks and keep track of the precise offsets between each others' clocks, because they need to negotiate time-slots for transmitting and listening. You might be able to retrieve that information from each module and do synchronization that way. I have no idea if that's possible.

You might be able to use the SCO mode of bluetooth, which transmits with a fixed small delay but can lose information from time to time (this is used for things like bluetooth audio, where occasional dropouts are preferable to occasional long delays).

The expensive solution would be to put a GPS receiver on both ends of the link for accurate time, and transmit the offset between the local sampling clock and the GPS time reference.

[Asli]

Dear "wiml",

Thank you for your informative reply.

Regards,

Asli

[twospruces]

The packetization of serial data also implies that blocks of serial data sent sequentially with zero gap could get chopped up and sent across several packets, resulting in an even worse behavoir for systems that rely on timing in a close way. You end up with one large transmission cut up in to blocks. If the end system needs to see the block delivered contiguously, you are toast.

I think. Please correct me if I am wrong. I'm not a bluetooth expert, merely a disatisfied customer who wanted to replace a serial cable with bluetooth.

So you get repeat packet transmissions that cause delay. You get delay due to the formation of a packet. You get segmentation and reassembly delay, and gaps in between streams of serial data that are normally sequential with zero gap.

this technology does not perform serial cable replacement...not even close. what a joke.

too bad, it didn't have to be that bad. Bytes on airwaves should be possible, right?

[wiml]

this technology does not perform serial cable replacement...not even close. what a joke.

I think that's a little harsh. For many/most cable replacement uses, transferring the bytes is all you really need, and a few hundred ms delay here and there really doesn't matter. If predictable timing is important, then bluetooth won't cut it, but most of the time that's not a problem.

Bytes on airwaves should be possible, right?

Well, radio is inherently an unreliable medium. What do you want the link to do when interference obliterates some of the data being transmitted? Your only options, as far as I know, are either to have the link stall while it tries to get that data across (the bluetooth serial-port-profile approach) or for gaps or garbage to show up in the output (the bluetooth SCO approach). You can increase the transmitter power and apply long error-correcting codes, etc., but that just reduces how often the problem happens, it doesn't get rid of it.

[twospruces]

lots of ways to do it--
fixed packet size
FEC on a per packet bases - deep strong FEC at that

ignore the case where radio fade out kills things-- IE either enable or toss out lossless transmission due to packet loss.