I'm looking for a way to detect the disconnection of a Bluetooth device immediately after it has happened (2 second max), typically in a "device too far" scenario or Device battery is dead. Currently I can detect it with a BroadcastReceiver by getting a BluetoothDevice.ACTION_ACL_DISCONNECTED, but it takes about 16 to 20 seconds to fire.
Is there any way to get notified in 2 seconds Max.
I used BroadcatReceiver but it is not fast enough to get alert in 2 seconds Max, so is there any other kind of approach available to get notification quickly that bluetooth is disconnected.
I use this createRfcommSocketToServiceRecord(UUID); to connect a paired device and i am bound to use it using UUID.
I have visited a lot of links regarding this issue, but no one matches with my needs.that's why any help would be appreciated.
thanks.
I think the only way you can reliably sense loss of connection quickly (within two seconds) is via your own application protocol that you use over the Bluetooth connection. For example, your application protocol might implement a heartbeat that occurs every 500ms. If you don't see a heartbeat within two seconds then you could trigger your own event.
Bluetooth is a socket-based stream protocol that is designed to work over an unreliable medium (i.e. radio), and as such has to tolerate errors in (or loss of) packets. For this reason it will take significantly more than 2 seconds before your Bluetooth stack declares it has given up and disconnected the device, as you have found.
I have an application on Play which is designed to talk with an automotive ECU via Bluetooth and my strategy for sensing disconnection is exactly as I suggested in my first paragraph.
Update 20th June 14
I see in your bounty comment and also your comment below that you're asking for a code example, but it's kind of difficult for me to provide one without knowing anything about the application protocol that you're running over the socket connection. Or to put it another way, what exactly is it about my first paragraph (i.e. the heartbeat suggestion) that you do not understand or cannot create code for yourself? The concept of using a heartbeat really is quite simple. You would define a certain message type in your application protocol that represents a heartbeat message. One end of the connection sends this heartbeat message periodically, say every one second. The other end of the connection checks that this heartbeat message is received every second or so and drops the connection after a two-second time-out. It is impossible to be any more specific than that, because I can't see your existing code and I don't know what kind of messages you are currently exchanging over the socket.
After nothing work around!
I got two things to get my work done.
I need to check that is my Bluetooth socket is not in use(Sending Receiving) till 2 to 5 sec I disconnect that and when user wants to send data to the receiver device I connect that again.
Or I'll try to connect the socket after 2 to 5 sec so that if it is not ready to connect means it is already connected, else it will be connected and I refresh the previous socket references.
but first option is more valuable to work perfectly in my problem.
This is a problem with old bluetooth and more hardware than software.
If you want to notice that the connection is broken you need to do polling (a heartbeat), something like "are you alive? are you alive?"... This is bad for battery so... the users will finally uninstall your app.
I recommend you to change to BTLE (bluetooth low energy), devices like Nexus 5 has this.
With BTLE you have a proximity profile which can tell you the quality of the signal, so, you can guess the distance (near, far, out of range) and therefore you can also tell if the devices are disconnected.
Another nice point is that if the devices are out of range but one is again in range you could get noticed as well, so this is really nice for apps to open doors by proximity for example.
Check this:
https://developer.bluetooth.org/TechnologyOverview/Pages/PXP.aspx
In the other hand Apple has invented the concept of iBeacons, devices that are distance aware, and the good thing is that there is also an implementation of iBeacons for Android:
http://developer.radiusnetworks.com/ibeacon/android/
Related
Referencing blog posts like this one, and SO questions like this one. I am going to assume that this is a general behavior (and not a bug on my side). The common answer seems to be something to the effect of: "Change the BLE firmware so it actively disconnects."
The question which is not well addressed is how Android apps handle what must be a very common occurrence? Connection is lost unexpectedly due to "range", I.E. radio signal strength.
Is there a way for an app to be notified "immediately" on the loss of connection?
It does seem unrealistic that all apps just sit there for something like the 20 seconds which is mentioned as a core OS timeout value. Is that what we should all be doing even though my equivalent app on iOS knows about the loss of connections in less than 1s?
Example 1
One common type of BLE device is the "Find my keys" type. Many of them have a feature to alert the user when you leave the "keys" unintentionally. I assume that this uses the connection going down as an indicator of you walking too far away. Right?
Example 2
Your app is supposed to be notified of of value changes from a characteristic on the device. This would be any kind of sensor data where you have some threshold is being crossed for example. I can think of plenty of examples where you'd want to know immediately that your "sensor" is out or range.
Known Workarounds
I have seen one workaround amounting to constantly monitoring the RSSI to the BLE device but that seems like it would eat up a lot of battery. Similarly any failure to write to a characteristic (that normally succeeds) could also be used, again with battery life paying a price.
Something approaching a definitive answer to this questions seems like a good resource.
In latest versions of Android they lowered the default timeout to 5 seconds, which is of course much better.
I guess most peripherals send their own Connection Update request where they can set a different timeout value, which solves that issue (except for the small time between connection setup and until the connection update has gone through).
So called "out of range" detector apps are according to me pretty useless and hard to make good because BLE devices will probably sometimes temporarily disconnect anyway, even though they are in range.
For your actual question if it's possible to "immediately" get notified on the loss of the connection, the basic answer is no, because the Bluetooth controller doesn't send anything to the main cpu that packets were lost (that's the whole purpose of having a timeout so you are allowed to have packet losses). But you can of course try to poll the rssi or set up a flow where the peripheral every constant interval sends a notification and then you can in your app detect if you don't get the notification after some amount of time. But in this case it's smarter to just set your own timeout (from the peripheral) using the connection parameter update procedure.
I am trying to send 10 bytes of data, every 30milisecond,s between 2 android devices using bluetooth low enegry notifications. The goal is to achieve low latency communication and there is no interest in low energy.
You can check the results in the Delay graph(Y field = delta time between packets). The first 10seconds the communication is being perfomed good enough. (The interval between the packets is max 30-40ms). However after the 10th second, the intervals are either extremly high or extremely low.
This is probably happenning due to non strict connection interval parameters. You can check a sample of hci_events that shows clearly the slow down is caused by the hci_events.
I have tried to configure the parameters of the connection, calling from the master the function
requestConnectionPriority
However, it didn't change anything on the result graph. I also check the packets using wireshark and findout that the master didn't even send a request for configuring the connection interval. I also tried another configuration request with
requestMtu
with exactly the same results, no update packets was send from the master.
So, there are 2 questions that show up from this observations.
Has ble a timeout in the 10th second in order to ensure low energy consumption? If so, how can I disable it?
Is some thing wrong calling requestConnectionPriority, from the android 6.0.1 with the role of the central(master)? Can you give me a simple example on how is being called properly?
Note that requestConnectionPriority is called right after the connection being establish in the onConnectionStateChange of the BluetoothGattCallback.
The device that has role of a slave(server) is running (Android 5.1.1) and the master(client) is running (Android 6.0.1).
Thanks a lot!
IMPORTANT UPDATE: It's crucial to mention the way the connection is being initiated between the devices.
The central device calls device.connectGatt, where device is BluetoothDevice device = mBluetoothAdapter.getRemoteDevice(address). Address is a hardcoded string, the peripheral's public mac address. You can check logcat logs and also hci logs.
I have also tried connecting with the legit method (peripheral advertising and connect to scanned random address), but I get an error 'initiate direct connection fail, topology limitation'. You can check logcat logs and also hci logs.
Has ble a timeout in the 10th second in order to ensure low energy consumption? If so, how can I disable it?
No
Is some thing wrong calling requestConnectionPriority, from the android 6.0.1 with the role of the central(master)? Can you give me a simple example on how is being called properly?
I'm not aware of any bugs regarding requestConnectionPriority. But you could try to execute that method after the onServicesDiscovered callback. Android temporarily changes connection interval to 7.5 ms during the GATT service discovery so it might be confused if you don't wait until the service discovery is completed.
Regarding requestMtu, make sure you execute that method while there are no other GATT operations pending (otherwise it won't work).
One additional tip is to use an air sniffer and not only look at the hci logs.
I'm currentily developing an application which uses Bluetooth Low Energy to communicate with a BLE device. The problem is that the project require an high continuous exchange of data for working.
Currently i've developed 4 fragments which share the same BluetoothGatt istance and the same data array. When i connect to the BLE device, i set the connection priority to high, then i start a writing loop which writes the data, usually just 4 bytes, every 50 mls.
At the same time i start reading and i update my interface.
I've noticed that if i stop the writing i receive a packet of data every 50 mls, but if i let the writing loop working the reading time increase from 50mls to 100 or more.
That's not a real big problem but it reduce all the sistem performances.
I looked on the internet for solutions but i didn't find nothing, except the connection priority that already helped me a lot, i'd like to know if someone have never managed such problems and how he did it. thanks
BLE Device that you are using has something which is called "connection interval". It is set in firmware of device. Minimal value for it is 7.5ms, but usually is set to 30ms or more (iOS even will not work with intervals lower than 20-30ms or it will simply miss the packets).
So when BLE device firmware is designed, connection interval is set to some value which is safe and will work with most mobile devices, and also very important to save the battery.
Al this means that you can transfer to, or from device once per connection interval, no mater if it is read, write or notification.
Some devices has configuration settings which allows changing of connection interval, but if you just wanted to know what happens, thats it.
I'm currently trying to make an Android app that will have some interaction with a BLE device. That device doesn't have the Ibeacon protocol.
What I want to do is auto connect to that device every time it is in range even (and almost 99% of the time) when the app is not in foreground. The only thing I know is that it is a BLE device, I have access to it name and address (00:1E:C0:29:BD:F8).
It is crucial tha the app connect to it every time it come in range. Even if the phone is lock it must connect no matter what (except if the phone is shut down XD). But as soon as the phone has booted and that bluetooth is activated, I must be sure that my app will be able to connect to tha device if it come in range.
I wanted to know what is the best way to do so.
The only way I can think of is to start a service as sticky, that will scan every 15 seconds (or something similar) for the device it already has registered to auto-connect.
The downfall of that method I guess is that it will surely drain the battery, I'm not sure about that but doing a scan for 3 to 4 second every 15 second must use up a lot of battery.
What do you guys think of that ?
Does anybody know a better solution I could use ?
Thank in advance for the help.
Is it possible to set up the Android Bluetooth Chat sample app to connect more than one person at a time, and have a mini chat room? What would that entail?
tl;dr version: Bluetooth sucks for this, don't use it, use wifi instead, probably backed by a web backend.
I have investigated this issue thoroughly throughout the years in the interests of a social wireless network research project. My general advice is: it doesn't work with more than two / three people. Bluetooth just isn't designed with wireless peer to peer networks in mind.
In general, it seems that the cheap Bluetooth controllers included on Android devices (especially HTC's devices, iirc) don't really handle any more than two or three connections at a time. I'm unsure if this is a hardware or firmware problem, but I can recount some basic anecdotes. I was working to implement this idea at the SDK level (i.e., without firmware modifications) around the beginning of 2011, and was able to get a peer to get two additional connections (i.e., three devices, each connecting to the other two) to work for a period of a few minutes to an hour before the connections would suddenly die and the socket would become unusable, requiring reconnection. Unfortunately, 20 minutes was an upper bound, and generally it was impossible to get connections to more than one other device at all reliably.
The goal of the project was to support multiple people interacting with each other silently in the background, but this never materialized, instead we ditched Bluetooth and went with wifi instead, which worked much much better. In the abstract, I think people view Bluetooth as a possible medium for reliable peer to peer communication, but it wasn't really designed that way: it's more of a medium used for short range communication between small devices (think headsets).
Be aware that if you want to do this, the maximum number of devices to which you can connect is fixed, because as per the Bluetooth spec, a piconet supports a maximum of seven devices. (See the wikipedia article.)
The required change is simple: you use a different UUID for each device. This can be implemented a number of ways, using an out of band exchange mechanism, or simple scheme where you assign UUIDs in an increasing fashion and when connecting to the network, try each in succession.
Here are some relevant Google groups threads:
Bluetooth peer to peer networks
Multiple connections on Android Bluetooth
I remember posting a more elaborate one detailing how to do this (with code) that I might dig up as well.., if I can find it. It should be from late 2010 or early 2011.
So the answer is, in the abstract, yes, you can try to do this, by using multiple UUIDs (after you use one, that's it, and you have to try another using some assignment protocol). However, in practice, after a lot of trial and error, this doesn't really work for what you probably want to use it for, and it's a lot better to go with an internet backend instead. By the way, this is also good for another reason, most users don't really like to turn on their Bluetooth for fear of their battery being drained..
Leaving this here, in case it helps someone else.
I was able to make my custom chat room following official bluetooth tutorial and modifying it a little.
Unfortunately, I cannot provide most of my code, but main idea is:
Every device is acts both as server and as a client. When Chat is started, device starts its server thread. Server thread is the same as official but doesn't ends when accept connection. It just keep listening.
Client thread is identical as in tutorial.
Both server and client thread manages connection same. I created separated threads for accepting messages following this tutorial and one for sending them.
private void manageConnectedSocket(BluetoothSocket socket) {
//create thread responsible for sending messages.
SendingThread w = new SendingThread(socket);
MainActivity.addSendingThread(w);
//Creates listener for messages to accept.
MainActivity.addListener(socket);
}
Now in main activity always when user click send button, for each worker (sending thread) send message to remote device. Listening is running asynchronously.
IMPORTANT:
You need to handle exceptions when message send fails and remove sending and recieving thread for device when you detect it is disconected. In my case I used well known UUID "00001101-0000-1000-8000-00805f9b34fb". For every device.
You need to wait 3 second between atempts to connect as client because some devices has weak bluetooth hardware and it is refusing connect as client.
Bt connection is supporting up to 7 -10 connections. So you will be limited in that range. I think it is designed for extensions of main device and not for random comunication
Source: search "bluetooth programming" on google