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)
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.
I am working on an android application where we are using ble device I find to get the rssi to calculate the distance. I am working on beacons for months together now but still understanding its behaviour is very difficult.
I have a BLE device broadcasting at 10hz(10 packets/sec).
Using BluetoothLeScanner.startScan(scanCallback) to get the rssi. Scan is continuous and So as of understanding we are suppose to get all 10 adv packets every sec. Since the scan is continuous there is no missing of data packets.
But the behaviour is different on every phone. I have tested on multiple phones and observed behaviour on few phones are as below,
Moto C Plus, AV: 7.0: 6-8 Callbacks/s
Redmi Note 4, Av: 7.0: 4-6 Callbacks/s
Moto G 2ng generation, AV: 6.0: android finds 1-3 callbacks for few seconds and no callbacks for seconds like 5,10 even for around 20+sec.
One Plus one, AV: 6.0.1 : frequent is 1-3 callbacks and rest of behaviour is same as Moto G, no callbacks for seconds( like 5,10 even for around 20+sec)..
I don't have any device running android version 5 to find the behaviour on that.
Query:
Why this inconsistency in advertising visibility on android vary?Is it because of Android versions or individual android devices ?
(Sure that my BLE device is broadcasting exactly at 10hz)
I found varies blogs on beacons, Bluetooth low energy but not find sufficient information on this particular behaviour.Any Insights are greatly appreciated.
Not 100% of beacon packets are detected by Android devices for a number of reasons. Among them:
Advertising packets are sent on a number of different radio channels, and the transmitter and receiver must be on the same channel at the same time.
Radio noise sometimes causes errors in bits in the digital signal on the receiver side making the CRC (i.e. checksum) fail to match, so the receiver ignores the packet.
Collisions in transmitted packets from multiple bluetooth devices in the vicinity happen. When collisions take place, the packets are generally not received because they overlap eachother and interfere with eachother.
Bluetooth advertisers automatically randomize the spacing of their packets so a transmitter at 10Hz does not send out exactly 10 packets every second. Some seconds may have 11 packets, others 9.
Even in the best conditions you will not get 100% of packets transmitted at the receiver. The best quality receivers getting strong signals in low noise environments might get 90% of advertised packets.
There is also a huge difference between different Android device models caused by using different bluetooth chipsets, different bluetooth antennas, different cases (which can block, amplify, or leak signals), signal interference with WiFi (which uses the same frequency band and often shares the same chip.) As you have seen, the number of packets detected on some Android models can be significantly less even under the same test conditions.
The primary driver in packet reception rate differences between Android models probably has to do with the Bluetooth antenna and interference from WiFi circuits. I have noticed that some Android models (such as the Huawei P9 Lite test device I own) show a much weaker RSSI (signal level) on average for the same beacon transmitter than the Android Nexus 5X receiver. This signal is 20dB weaker. Weaker signals relative to noise usually mean higher rates of packet loss for the reasons described above. One of the first Android devices supporting BLE, the Nexus 4, could usually not detect BLE packets at all if WiFi was turned on.
On the Samsung Galaxy S6 Edge +, I noticed that depending on which channel the advertisement packet was on, the RSSI would be significantly higher or lower, possibly due to the antenna being less tuned to the slightly varying radio frequency of some channels. This mean that the noise was higher relative to signal on the weaker channels, and a higher rate of packet loss when advertising was detected on those channels. Unfortunately, Android APIs give no indication of which channel was used to detect a packet, so there is no way to correct for this.
Bottom line: this is a complex issue that has many, many variables. The results you are witnessing are not unusual.
I have a working BLE scanning app that has been working fine for last few months on Nexus 5 (on various API versions from 4.4 to 6.0 ). Today we ran the app on different device "Huawei Ascend Mate2" that has API 22 and found what I thought was an interesting or peculiar behavior: callback gets fired continuously (about thrice a second), but my iBeacon is detected in only one callback and in remaining callbacks it picks other devices in the house (like netgear router and roku etc; I donot know if this netgear and rouku are even BLE devices).
My BLE scanning code is very similar to the one described here http://www.truiton.com/2015/04/android-bluetooth-low-energy-ble-example/
This thread
Android 4.4 BLE Scanning lack of stability suggests that BLE scanning is stable on 5.0+, but in my case that is not true because I am on API 22
This thread
Android BLE Beacon scanning on different phone models suggests that we need to turn on and turnoff the scanning every 1.5 seconds and that is not practical in our use case because our app should run for 10 hours every day (we think starting/stopping of system resource is expensive operation)
I am puzzled on why the same beacon is getting detected in continuous callbacks on Nexus 5 (tested on both 4.4 and 6.0 Android APIs); but when running on "Huawei Ascend Mate2", though callback is continuously invoked, the same iBeacon is detected only once while other non BLE devices are detected in subsequent callbacks.
This is the first time I tested outside Nexus. Did anyone test BLE scanning on "Huawei Ascend Mate2"? Any observations and comments would be appreciated.
"Huawei Ascend Mate2": Device model number is MT2L03 and Android version is 5.1
I worked with a lot of different devices and I can tell you, that the behaviour is very different on different devices. I don't have an Huawei Mate2, but I could observe similar behaviour, where you only get a scan result once per device. So if you need to have multiple scan result for the same device you need to restart the scan from time to time. I think 1.5s is a bit too much, but this depends on your use case.
I'm trying to communicate two smartphones with Android 5.x through BLE.
First of all, I've installed the sample app from Google (https://github.com/googlesamples/android-BluetoothLeGatt) to test if the devices are correctly y scanned, but tablets and smartphones are not detected (the bluetooth is visible and enabled in both cases).
In the list only appears bracelets like Xiaomi MiBand, Fitbit... and some Macbooks, but nothing else.
I've read this report: https://code.google.com/p/android/issues/detail?id=82293
and this post (with Android 6.0 must be enable the location): Bluetooth Low Energy startScan on Android 6.0 does not find devices
I've tested with multiple scan apps from the Play Store, but all of them show the same result... I'm going crazy.
Scanning from Settings -> Bluetooth the result is correct (smartphones and tablets are detected).
Any idea about this problem? Why this devices are not appearing on the BLE scan?
Smartphones and tablets used to test:
Samsung Galaxy S5
Xiaomi Redmi Note 2
BQ Edison 2
iPhone 5
If device has BLE it does not mean that it will be visible (broadcast) any data by default. In order to achieve communication between two smart phones you need to have (install or write your own) application that uses BLE to create proper BLE service that will be exposed to other devices.
Some BLE capable devices such is iPhone for example broadcasts BAS (Battery Service) or similar, but I don't think that Android does.
So, don't expect to find any device on scan that you have described, and if you still need
to communicate two smartphones with Android 5.x through BLE
try to read Bluetooth Low Energy documentation and be ready to understand UUID, GATT, Characteristic...
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.