CODEWITHSUNDEEP
javaandroidbluetooth
keegs_la_trobe
keegs_la_trobe

Reputation: 94

Irregular Bluetooth Transfer Speed?

I am currently sending a lot of separate strings that contain data between two devices via Bluetooth, however for some reason it takes an irregular amount of time to transmit similar strings. Below is an example of the write times of two similar strings: 

String: K:92:281:-50529028
Write time: 2
String: K:93:281:-50529028
Write time: 41

The measured time is in milliseconds. Here is my write function, I am using a BufferedOutputStream to transmit the data: 

public synchronized void write(byte[] bytes) {
    long writeTime = System.currentTimeMillis();
    try {
        mmOutStream.write(bytes,0,bytes.length);
        mmOutStream.write('\n');
        mmOutStream.flush();
    }catch(IOException e) {
        Log.e(TAG,"Write IOException");
        cancel();}
    String s = new String(bytes);
    Log.d(TAG,"String: " + s);
    Log.d(TAG,"Write time: " + (System.currentTimeMillis() - writeTime));
}

Is it possible that it is because I am performing separate writes and not one large uniform write that it is greatly slowing it down?

Upvotes: 1

Views: 207

Answers (2)

Evgheni Crujcov
Evgheni Crujcov

Reputation: 470

IMO, such a drastic difference in times to transmit similar strings has to be due to collisions occurring over the wireless. Don't see how you'd avoid them since its inherent to any wireless communication on shared bands.

Upvotes: 0

Trevor
Trevor

Reputation: 10993

From personal experience, the latency (time taken for data to travel from one device to another) can vary considerably between writes and also depends on the Android device (or Android OS) used. Bear in mind that there is some amount of OS framework code that must handle your data writes, and then there is the Bluetooth stack itself, all of which requires CPU time to handle. It may also be partly down to the framing of the Bluetooth protocol as data is sent over the air in packets.

If your particular example shows a second write being performed immediately after the first, perhaps the longer time in the second case is due to an underlying native write() call blocking for a while because the underlying OS is still handling the first buffer.

The best answer I think you'll hope to have on this is to just accept this latency exists, and design your application to cope with it. You may get better throughput if you make larger writes.

Upvotes: 1

Related Questions