3

I have to exchange data between two bluetooth devices, one of them will be an Android device. For simplicity's sake you can assume the other device will be a generic linux device running bluez producing data similar to the data a fitness tracker would produce.

The scenario seems a straightforward use case for Bluetooth Low Energy. The problem i am currently running into comes from the fact that communication has to be reliable (reliable in the way TCP is reliable). This means:

  • no losses
  • no corruption of data
  • order needs to be preserved
  • no duplicates
  • no phantom packets

While losses are prevented at link layer level, the order for instance seems not to be explicitly preserved when working with Low Energy (using indications would probably achieve this).

Not having done a lot of work with Bluetooth I am currently overwhelmed quite a bit with the amount of options while at the same time no option seems to fit the bill nicely.

Is there a "best-practice" for setting up reliable communication between two bluetooth devices? A Bluetooth Low Energy solution would be preferable, but is not mandatory.

ASM88
  • 53
  • 3

4 Answers4

3

Once your Bluetooth connection is setup its reliable. So you don't have to be worried about data loss or corruption.

So the things you're worried about can be easily handled in your side. You'll get proper connection and disconnection callback while setting up a BroadcastReceiver for your BluetoothAdapter.

In case of any disconnection you may have to restart the procedure for connection again and once its established properly you may resend the data.

I don't know about your purpose yet, but one thing I need to mention here is, I would not recommend Bluetooth communication if you're holding the connection for long time. Some devices disconnects the connection automatically after some time if there's no continuos transmission.

Reaz Murshed
  • 23,691
  • 13
  • 78
  • 98
  • I figured that loss or corruption wouldnt be problems with BLE. What about the other requirements I listed? There is nothing in the specification that would make sure order of packets will be preserved is there? Also if I would want to prevent duplicates and phantom packets I would have to implement these requirements myself? – ASM88 Aug 22 '16 at 06:51
  • `order of packets will be preserved` - I didn't find any specification too but I didn't find any problem with ordering either yet. `prevent duplicates and phantom packets` - As in usual cases there is no chance of data loss or corruption you might don't have to implement duplicate packets strategy. – Reaz Murshed Aug 22 '16 at 07:05
  • 1
    Alright. That's pretty much what I found out in my own research. Not exactly what I was hoping for, but I'm still accepting this answer as it is the most helpful. – ASM88 Aug 22 '16 at 08:23
  • Good luck with your research and please let everybody know what you've found so far. That would a great learning for me. :) – Reaz Murshed Aug 22 '16 at 08:29
1

Android has Bluetooth support, but it only allow to send ot receive data from stream. There is a very good sample project from Google: https://github.com/googlesamples/android-BluetoothChat . The only drawback of this sample is that it use Handler to nitify about Bluetooth events. I changed it a bit so it use another Thread and from it calls methods of interface you set, take a look at project: https://github.com/AlexShutov/LEDLights . This is ordinary Bluetooth, not BLE, hope it will help

Alex Shutov
  • 3,217
  • 2
  • 13
  • 11
1

Android's BLE stack is as good as the link layer specification. So you can use "write without response" in one direction and notifications for the other direction. Just make sure your peripheral side does not drop incoming writes.

Emil
  • 16,784
  • 2
  • 41
  • 52
0

BLE uses 24-bit CRC. for the amount of data transmitted using BLE the CRC is quite robust and the possibility of corruption is very low ( note that TCP CRC is 16bit and the Ethernet CRC is 32bit, please see http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html).

The ordering issues in wired network is a result of routing packets through different routes to the same destination ( plese see If TCP is connection oriented why do packets follow different paths?) . This is partially due to the use of sliding window acknowledgement protocol, which allows a number of packets to be transmitted before being acknowledged.In BLE there is no routing and the acknowledgement scheme is a variation of stop and wait ARQ scheme(2-bit lazy acknowledgement), this means that it is not possible to send a new packet without being acknowledged. These two factors makes the possibility of having an out of order transmission highly unlikely.

Community
  • 1
  • 1
bare_metal
  • 1,134
  • 9
  • 20