I have a BLE test device. I have connected it to three apple products successfully, with bi-directional communication having latency of < 1 second in each direction. I have also tested four Android devices. All four Android devices have latency on the order of 5-10 seconds for communication in each direction.
Is Anyone using BLE devices with Android and have success? I suspect there is a serious problem with BLE in Android given low performance on 100% of Androids tested and high performance on 100% of Apples tested.
Related
I am looking for definitive values for the maximum number of concurrent BLE devices you can connect to on both iOS and Android. I have done my own research and testing and it is not consistent. The Bluetooth LE spec does not limit the number of simultaneous connections, but the platforms have added caps due to memory constraints.
On Android 7 I was able to connect to 22 BLE peripherals simultaneously. One Android 9, I was only able to connect to 12 BLE peripherals at a time. And on Android 10 I have at times been able to connect to 12 BLE peripherals simultaneously and the same setup could connect to 14 BLE peripherals simultaneously at other times. All of this testing was on Samsung Galaxy Tab 10 hardware.
iOS is a similar story. I have been able to connect to 8 BLE peripherals simultaneously on iOS 9, 12 BLE peripherals simultaneously on iOS 10, 11, and 12, and 15 BLE peripherals simultaneously on iOS 13. I have not tested iOS 14, yet. This testing was done on iPad Mini 2s, iPad Mini 5s, and iPhone 7+s with the same results on all hardware. Others on this site claim to have seen as many as 20 concurrent devices on iPhone 6S with iOS 10 - I cannot confirm that.
I have seen lots of similar numbers from others' testing and some have even referenced documentation from Android and Apple calling these values out. I have not been able to find anything in the documentation from the last few releases of Android or iOS that call out these maximum values.
Could anyone help point me out to the true, documented values? Thanks!
The sad truth is that there are no documented values anywhere to be found, for most devices. The manufacturers don't state the Bluetooth limitations anywhere. When the product goes through Bluetooth certification and declaration, it however needs to specify every single supported Bluetooth feature supported, but not how many connections it can handle.
The BLE spec does not state any limitation, so it's up to the Bluetooth implementation to decide.
First, the Bluetooth chip (controller) usually has its own restriction. The HCI does not expose any functionality to query the maximum number of connections, so the host stack does not know what the controller's limitations are. First when the maximum is reached and the host tries to connect another device, the controller will return an HCI error code of maximum connections reached.
All Bluetooh chips have unique limitations. They usually range from somewhere between 3 to 20, as you have noticed. This limitation is more important than the specific OS and version the device runs.
Now if we look at the Android Bluetooth host stack, it has a hardcoded limit of 7 connections the last time I checked the source code. So in Pixel and Nexus phones, which run the "vanilla" Android, the limit will be 7, even though the Bluetooth chip can itself handle more (I've recompiled AOSP with an increased limit and verified this on Nexus 6P). I've seen that other manufacturers, such as Samsung, increase this limit to match what the Bluetooth chip actually supports.
Anyway, looking at specific OS versions will not give any useful information; you must test each device individually.
My issue is that iOS and various android phones receive number of BLE advertise packet from specific ibeacon, for example In 5 minutes from a specific beacon iOS receives about 904 advertise packets and android phones receive about between 230 to 480 depending on the phone.
Does anyone know if there is a setting that can set scanning rate of the BLE module? If not what else might cause this issue?
I use "CBCentralManager" to utilize BLE module in iOS and "blutoothLeScanner" in Android.
//Creating an instance of CBCentralManager
private let bluetoothManager = CBCentralManager(delegate: nil, queue: nil)
//Start Scanning
bluetoothManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey:NSNumber(value: true)])
The scan parameters are hardcoded in both OSs, but on Android you can choose between the following three modes:
https://developer.android.com/reference/android/bluetooth/le/ScanSettings.html#SCAN_MODE_BALANCED
https://developer.android.com/reference/android/bluetooth/le/ScanSettings.html#SCAN_MODE_LOW_LATENCY
https://developer.android.com/reference/android/bluetooth/le/ScanSettings.html#SCAN_MODE_LOW_POWER
Note that if you scan in the background, SCAN_MODE_LOW_POWER will be used regardless of what you select.
There is a large amount of variation between Android device models (often called fragmentation) and this applies to the Bluetooth LE behavior as much as anything. Differences between Android phones is a more likely explanation for the discrepancies you see than the scan rate, which defaults to a 100% duty cycle (LOW LATENCY) on all Android devices I have seen, and is similar to iOS.
Given the same conditions, some Android devices scan a similar number of BLE advertisements in iPhones (e.g. Pixel and later Nexus 5+ devices.) But not all Android devices provide as good of results.
You don't say specifically which Android models that you tested which saw fewer advertisement detections, but there are a number of things that might cause this:
Some older Android devices like the Nexus 4, Nexus 7 and Moto G (1st generation) would only detect on advertisement per scan per unique bluetooth device. Restarting the scan was needed to detect a second packet from that device. You might try restarting your BLE scan every second or so to see if this helps.
Some Android devices like the Huawei P9 have very poorly performing BLE antennas, so they are rarely able to detect BLE devices at more than 10 meters, whereas iPhones typically detect at 40-50 meters or more. You can see if this is the cause of your issue by looking at the signal level (RSSI value) for packets received. Are the RSSI values consistently weaker (more negative) on the Android device vs. iOS? If so, then this explains the discrepancy.
I know the same behaviour from some phones.
Note that your peripheral probably does advertising on 3 BLE channels. (?) It might be possible that your Android device only listens on one channel.
Moreover and on some cases even worse, it is possible that your phones listens on one channel at a time and another channel some time later, thus, also does channel hopping for scanning. It is possible that you get aliasing effects and see the advertising only a few times. This is why the Apple Accessory Guide recommends certain advertising intervals of the peripheral. (chap. 23.5)
How many devices can be connected to at one time via Bluetooth using the BLE firmware on Android?
A search of the Android Bluetooth Firmware source shows the following:
Max concurrent active synchronous connections (BTA_GATTC_CONN_MAX):
4 on Android 4.3
7 on Android 4.4+
Max concurrent active notifications (BTA_GATTC_NOTIF_REG_MAX):
4 on Android 4.3
7 on Android 4.4
15 on Android 5.0+
As a comparison my experience with iOS is that 8 devices can be connected at at time.
I tried connecting more than 7 devices the other day on Android 7.1 and Bluetooth stopped responding. Starting and stopping didn't help; the only thing that fixed it was restarting the device.
After working with several apps that connect to 4+ devices I can say from experience that these numbers are theoretical. Depending on each individual device and its hardware you'll have an easier or harder time connecting to and maintaining a connection to the maximum number of BLE devices.
Follow Bluetooth at Wikipedia,
A master Bluetooth device can communicate with a maximum of seven devices in a piconet (an ad-hoc computer network using Bluetooth technology), though not all devices reach this maximum.
You need know Master/Slave in Bluetooth first.
I think the good answer depend on your aim.
You're right when you know "can communicate with how many devices" depend on Hardware (Bluetooth Chip).
Bluetooth chip on Apple iPhone 4, 5 or Samsung Galaxy S3, S4 ... totally different with Basic Bluetooth Chip.
In my case :
I'm working with Firmware side related to BLE.
His peripheral device has used Basic Bluetooth Chip since it did not has enough memory to store many capacities as many features, likes Bluetooth chip on Apple iPhone 4, 5 or Samsung Galaxy S3, S4 ....
Therefore, his peripheral device only paired with one device in one time.
Thanks,
Both of the answers here are wanting so I thought I should add one:
There are connection limitations built in to the different BLE hardware. I think the lowest I've encountered is 3 connections at once and the highest was about 12-13 connections. These were limitations due to the design of the hardware and had nothing to do with the OS being used, though. Usually the limitation is due to the fact that the hardware has to keep track of certain data and there's a limited amount of memory in the hardware.
So, I don't know specifically for Android, but it doesn't make much sense for a limitation to be imposed at the OS level. Likely when you try to make a connection, and you've reached the limit due to the hardware, you should receive some sort of error/exception preventing the new connection. I think there's actually a "connection limit" error in Bluetooth, but some hardware gives other exceptions like "out of resources". Again, I'm not sure how that gets reflected on the Android level.
I come into BLE development without any knowledge in Classic Bluetooth development and I really don't know what "pair" means in BLE. Isn't that something only exists in Classic Bluetooth?
If you are talking about connection, when Android 4.3 first came out I made a few test on the SDK on Nexus 7 2013. The maximum number of devices it can connect is 4. I didn't test if this number changes in 4.4, but I can confirm it will not be anything less than 4.
For every system, be it any firmware or OS like Android or iOS, there is a configured maximum concurrent connection limit. But in reality the connection parameters of each connection play a very important role in determining weather or not the system will be able to achieve that many concurrent connections.
For example, if the configure connection limit is 4 then the system can not have more than 4 concurrent connections. But if all of the connected devices are demanding a higher connection interval(say a 50mS connection interval) then the system may not be able to support all of them. This results in either some of the connections dropping out or not being able to connect entirely. But if the connection parameters are a bit relaxed(say a 1sec connection interval) then all the connections can be serviced properly.
We would like to connect sixteen vibrators to an Android phone using Bluetooth, and control the vibrators individually.
As far as I know, you can only have eight devices in a piconet, so that would place a limit of seven vibrators (the phone itself being the eighth device). First of all: Is that correct?
And do up to seven connected devices work well and reliably in Android? Or is there some additional limit or problems from Android's Bluetooth implementation or APIs?
For our sixteen vibrators, will we have to build a scatternet with additional devices that bridge between the phone's piconet and additional piconets with some of the vibrators? Does anyone have experience with this, and does it work well?
(And no, it's not a sex toy!)
As far as I know, you can only have eight devices in a piconet, so
that would place a limit of seven vibrators (the phone itself being
the eighth device). First of all: Is that correct?
Ok to be technically precise - Bluetooth Classic can connect and be in active connection with upto 7 devices
at a time. But then an active device can then be put in park mode and it can have a large number of device in park modes, so device can be moved to park from the connected - active state and vice versa.
But again at any one point you can have only 7 active devices So the master device should manage a large number of devices by keeping (unto 7 ) active and rest parked and keep switching them between active and parked modes.
And do up to seven connected devices work well and reliably in
Android? Or is there some additional limit or problems from Android's
Bluetooth implementation or APIs?
Well in Android the problem is - There is no one implementation and many different bluetooth Radio hardware gets used by different manufacturers. So the answer is it depends. Some are pretty reliable Some are really bad.
But there are no public APIs to control / use the Park mode that I described above - But if you can operate on the internals or have access to it from your app you could do what you are asking for,
On Scatternet :
Again Android does not have any API for you to control it, It will be complicated - but your could force it into a scatternet configuration, but again there are limits - the best I have seen in commercial devices is for a device to be in 2 or 3 piconets at the same time, Which means you can be connected to (7+2) 9 devices at a time (it does not meet your requirement of 16).
Bridging / Mesh configuration may be feasible - Where 2 of your devices form their own piconetcs i.e with 8 devices in each group then the leader of the group (Master) connects to Android deevice - and you manage the data relay at the application.
Now having said all this - have you looked at Bluetooth Low Energy - A perfect candidate to conenct a bunch of sensor devices - Ther is no theoritical limit on the number of devices that can be connected at a time - But practically 16 or even larger is very feasible.
Android currently does not have public APIs for it . (As of Today)
But most (almost all) latest adroid devices comes with Bluetooth Hardware that is Version 4.0 meaning it is capable of Bluetooth Low Energy.
And iOS devices - Mac, iPhone , iPad has great support and developer access / apis for it.
So it will be the way to go, and I am pretty Sure Android will come with developer APIs soon for BLE (atleast I hope so)
I'm contemplating the development of an Android app that detects all or most nearby mobile devices (iPhone, Android, etc) in the immediate neighborhood that are turned on. I don't need to interact with these devices, just detect them, and a requirement is that the detected devices can't need to have any special / unusual apps installed on them. The app only needs to work for typical U.S. devices and networks.
I've thought about a few ways to do this (somehow detecting bluetooth, wifi, or cellular transmissions / identifiers), but I'm looking for specific implementation methods for a way to detect a relatively large proportion of nearby devices. I'm not sure which of these methods is possible / feasible or how to put them into practice...
Perhaps using Bluetooth: Is there a way using the Android SDK to detect non-discoverable Bluetooth devices (not in discoverable mode)? The Nokia Developer site seems to suggest this is possible using Service Discovery Protocol (SDP), but I'm not sure if this is possible more generally in Android.
Perhaps using cell tower mast switching simulation? Ok, this is almost certainly beyond the reach of Android, but this article suggests that there may be a way to "mimic cell mast switching process to trigger quiescent phones into transmitting. Phones respond with their ID and authentication signals...".
I think you should see this, it is a paper, and you cannot view it for free, but in the summary, it clearly states:
Concerns about Bluetooth device security have led the specification of the “non-discoverable” mode, which prevents devices from being listed during a Bluetooth device search process. However, a nondiscoverable Bluetooth device is visible to devices that know its address or can discover its address. This paper discusses the detection of non-discoverable Bluetooth devices using an enhanced brute force search attack. Our results indicate that the average time to attack a non-discoverable Bluetooth device using multiple search devices and condensed packet timing can be reduced to well under 24 hours.
But for an android application, you need the detection time to be well under a few seconds instead of less than 24 hours, so a practical solution may not yet be available.