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.
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.
Every so often the rssi is not getting any stronger than -55. It can go weaker than this value but cannot go to -30 even if the phone is right next to the beacon. This lasts for about 2 minutes before it goes back to normal.
I am using the android beacon libary and currently am only using foreground scanning.
RSSI is notoriously unreliable. Bluetooth uses the 2.4 GHz ISM band, which it has to share with dozens of other device types that can emit RF in this band. Your problem might even be caused by a neighbour running a creaky old microwave oven that's not properly shielded anymore.
I've done some experiments on different devices and I made each of the scanner and receiver at the same time and saved RSSI get from other nearby devices but the result was strange. first, there was a Huawei p6 that could scan other devices signal but nobody could see its transmit signal. second, the RSSI was completely device-dependent although beacons setting was the same for all of them inside the application and I want these signals to approximate their distance from each other.
question is that is this library reliable for my purpose which is getting approximately distance of devices from each other? I should mention that these results have gotten from android devices and I think that iPhones are another problem
The fragmentation in Android devices means that there is a huge variation in not just bluetooth chips, but in the external bluetooth antennas and phone cases that affect the strength of the signal Android devices receive and transmit.
While the distance estimates provided by the Android Beacon Library are useful for finding the relative distances to different beacons, using the value as an absolute distance estimate will not be consistent across different Android devices. The library does provide a way to tune its distance estimates to a specific hardware model, but unless you are targeting only a small number of devices this approach is not practical to tune for thousands of Android models out there.
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)
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.