cancel
Showing results for 
Search instead for 
Did you mean: 

BlueNRG-MS not visible by android

hardware
Associate II
Posted on January 30, 2016 at 00:07

Hi,

We are encountering the following issue: after some time (minutes), the module is not visible by Android phones anymore, but is still visible by other iPhones or BlueNRG-MS devices.

The time after this happens seems highly correlated with the Advertising Interval used (the shorted the interval, the shorted the time after which the device is not seen by Android).

The only solutions to see the module on Android after this are:

- hardware reset of the BlueNRG-MS module

- using 'offloaded' scan on the Android devices

Is STMicro aware of such issue and is there any solutions?

Thanks,

Christian

#android #bluenrg #scanning #scanning #bluenrg-ms #bluenrg-ms #bluenrg-ms
6 REPLIES 6
Posted on March 09, 2016 at 15:41

Dear Customer,

- Which version of fw stack version are you using?

- Which version of Android are you using?

- Can you reproduce the issue using the BlueNRG GUI?

- Have  you a sniffer log?

Let me know,

regards,

GM

hardware
Associate II
Posted on April 25, 2016 at 19:37

- Which version of fw stack version are you using?

7.1c

- Which version of Android are you using?

Have confirmed the issue with android 5 and 6 on about 15 different phone models

- Can you reproduce the issue using the BlueNRG GUI?

Yes

- Have  you a sniffer log?

Unsure what do you mean? Which level of sniffing?

hardware
Associate II
Posted on April 26, 2016 at 19:42

Confirmed the same issue using the STEVAL-IDB006V1 Usb, running firmware 7.1e with DK 1.9

Steps to reproduce:

- ACI utilities: Init device, default values, OK

- ACI utilities: Advertising, change Advertising_Interval_Min and Max to 100ms

- Scan for with android and see it.

- Wait for 24hours (or less, I've seen it occur in 8 hours)

- Scan for with android and don't see it anymore, scan with iphone and see it, scan with another bluenrg and see it

tyoung
Associate II
Posted on April 27, 2016 at 15:23

We had the same problem over here with BlueNRG-MS. We solved it by setting the scan response with the name and flags AD's. Android appears to absolutely require a scan response in order to find a device, rather than just rely on advertising interval like everything else seems to do.

Also, lowering the advertising interval may help with any scanning/connection difficulties. I believe we have ours set at 60ms.

hardware
Associate II
Posted on April 29, 2016 at 00:23

Can you explicit what you mean by ''setting the scan response with the name and flags AD's'' ?

That's very interesting.

tyoung
Associate II
Posted on May 04, 2016 at 17:48

You useHCI_LE_SET_SCAN_RESPONSE_DATA to set the data in the response. I forgot that you also need to put the service UUID's in the packet (probably the most important part!).

In the scan response data, you need the flags AD (0x01), services AD's, and the name AD's (either 0x08 or 0x09; we use 0x09 since we can fit the complete local name in our packet). The flags AD I believe is implicitly added since it's not explicitly defined in our code. We have only one service. So the basic structure for the data we pass into that method is as follows (Python example from our devkit testing, should be easily translatable to C):

# Device name (we can only fit 10 in our packet)
name_str = ''Example123''
name = list(bytearray(name_str))
len_name = len(name)+1 #The +1 is to account for the AD type byte (0x09)
# Complete list of 128-bit service UUIDs
uuid_list = [0xXX, ..., 0xXX] # (16 bytes, little endian for each 128-bit UUID)
len_list = len(uuid_list)+1 # The +1 is to account for the AD type byte (0x07)
# In order for the services to be found, the scan response data needs to be set.
# + 2 in the Scan_Response_Data_Length accounts for the two AD types (0x07 and 0x09)
response_data = [len_list, 0x07] + uuid_list # 0x07: Complete 128-bit service UUID list
len_resp_data = len(response_data)
HCI_LE_SET_SCAN_RESPONSE_DATA(Scan_Response_Data_Length=len_resp_data+len_name+2,
Scan_Response_Data=response_data + [len_name, 0x09] + name)

Obviously in some cases, it may not optimal to include every service, so just include the one(s) you need. There's an ''incomplete 128-bit UUID list'' for this case. There are AD types for 16-bit UUID's as well. The complete list of valid AD types is specified here:

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile