Menu
I'm working on a BluetoothLE sensor device, for which I need to form a one-to-many broadcast of data. As per the spec, peripherals may only have a single master, and due to limitations of the chip and stack I'm designing on, a master can only have three slaves. From what I understand, Android cannot become a BLE slave anyway, so having my device as a master is not an option.
Both the BT4 spec and manufacturer documentation talk about another mode of operation, referred to as Broadcast mode. In broadcast mode, a connection is never made, and the application data is transmitted as part of the advertising packet. This will exactly fit my needs, as many Android/iOS phones can simultaneously scan down each packet. An advertising packet is transmitted multiple times in bursts, so I suspect reception of data to be mostly reliable. If a packet is lost here and there, it can be tolerated.
Where this gets interesting, is that I want these packets to carry live sensor data, that updates at a rate of 10-20Hz. From examples I've found on the web, BLE in this mode is mostly being used for "iBeacon" type implementations, where they are broadcasting static data. I cannot find any information on how advertising packets are filtered within the Android stack. It could be that they return one result per Bluetooth hardware address, or it could be the unique combination of address and data. The second option would work for this application. If starting and stopping the scan resets the filter, I can make something work as well.
The Android documentation mentions nothing about how device filtering in the scan method works. I've been able to find one post on the net attempting to solve this same problem, which has an unresolved response: BLE: Multiple discovery of the same peripheral during scan. In iOS, my colleague informs me that there is a parameter that can be passed to the scan function that makes this possible.
I've attempted to trace the code back from the startLeScan() call in the Android source, but the code is quite complex, and the use of abstraction has made it difficult to identify the implementation of the object that contains it. The farthest I've gotten is to an IBluetoothGatt object returned from the BluetoothManagerService class method getBluetoothGatt(). This object receives the request to start scanning. It is being instantiated around line 790 of BluetoothManagerService.java on the current revision live on github. The object is being cast from the result of a message, so I suspect maybe the result is phone/driver specific. It is beyond my expertise to be able to trace it any further.
Another question I would like to resolve is how rapidly the scanning can be switched on and off. Scanning is a power intensive operation, yet the broadcast of data will happen periodically on a fairly precise, real time timer. As a result, it would be a great optimization if the scan can be switched on and off, such that the broadcast and scan are synchronized, with the scanner shut down the other 90%+ of the time. This will likely need to be tested experimentally.
I'm still doing feasibility research to see if this is possible for our accessory for Android. My present phone cannot yet run version 4.3, so I have no way of testing/hacking this experimentally.
245
With Android 4.3 and 4.4 so far, it appears to be a mess: Some devices call onLeScan(BluetoothDevice device, int rssi, byte[] scanRecord) multiple times for one device in one scan, some don't. There is no way to configure the filtering like in iOS (see answer of Arkadiusz Konior). So, I now start a list, because I can't ask my users such a question about their device.
However, restarting scaning is also no problem on "not filtering" devices. So, I restart scaning on every device now.
Not filtering (Continuously calling onLeScan())
Filtering devices (applies to Standard)
Unknown filtering behavior (Please help to associate the device to a certain group)
95
The text in pages 2535-2536 in the Bluetooth specification (Core_v4.1.pdf) about duplicate advertising reports is somewhat unclear. However the text on page 1258 is clear. It specifies a Filter_Duplicates parameter to the HCI_LE_Set_Scan_Enable command. In Android version 4.4 (Kitkat) this parameter is 0x00 (Duplicate filtering disabled).
There is a simple way to find out if any filtering is done in the Bluetooth chip from Android versions 4.4 (Kitkat). Make the phone a developer phone, enter developer options and check “Enable Bluetooth HCI snoop log”. Then turn Bluetooth OFF and ON once to make the settings bite. From now on all HCI packets between the application processor and the Bluetooth chip will be stored on the phone in a file which is pulled by adb pull storage/emulated/legacy/btsnoop_hci.log . This is not a text file and you need a program from http://www.fte.com/products/default.aspx or wireshark to view btsnoop_hci.log. For wireshark you need a pretty recent version, because older versions does not support BLE. My experience is that there is never any filtering in the Bluetooth chip, i.e. the HCI Event “LE Advertising Report Event ” is sent for every ADV_IND and ADV_NONCONN_IND that the Bluetooth chip receives. This goes for phones with Bluetooth chips Qualcomm/Atheros WCN 3680 and Broadcom BCM 4339.
Correction: the path to btsnoop_hci.log can be different depending on the phone manufacturer. You can find the correct path by adb shell cat etc/bluetooth/bt_stack.conf | grep BtSnoopFileName
15
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
