Android issues for TI bluetooth stack?

Thanks codesmith and JXS!

I will try with different connection parameters and try generate sniffer trace from the behaviour...

To give you an update on recent investigation:

I factory reset the phone to start from zero (i.e. clearing bluetooth cache etc.) and install a Google example code to scan for and connect with Bluetooth LE devices. In that state Android reports our CC2541 devices but connecting gives a undocumented result code 133 (thank you Google). However, I can connect to another BLE device using the same Android code (this device is built on an NS SoC) and _THEN_, after successfully connection once to the NS-based product I can connect to the CC2541. Quite confusing... =(

Regards, TMA

Note that I'm using Samsung S5 updated to Android 5.0 that connected without problem to my CC2541 application on pre-5.0 versions of Android.

Ok, I did analyse the low level communication, made a comparison between our CC2541 application and another working BLE peripheral...

Seems like the problem comes from the address type indication in the advertisement message(!). We are currently using the default BLE-stack setting ADDRTYPE_PUBLIC (indicated by TxAdd=0 in the Adv PDU header), but this seem to confuse the current BLE implementation in Android 5.0 and connecting to such device doesn't even happen on a lower level. When changing the to TxAdd=1 (i.e. indicating a random address) I have no problem connecting to our device, AND after that I can connect to other devices running our application with TxAdd=0 indication.

Is it Google or our own implementation/configuration who is the bad guy here?

I hope this helps someone else out there, I've spent to many hours on this problem...

Hi,

Thanks for sharing your findings! Unfortunately, as with any major smartphone OS upgrades, there can be compatibility issues as you've seen here. Also, for Android there does tend to be more variability in terms of implementation since Android CDD does not specify the behavior of the BLE stack low layer functionality. Therefore, it is up to the respective phone manufacturers to configure the BLE stack within the bounds of the BT core specification.

Best wishes

Hi JXS,
Yes, after developing for both iOS and Android it'a quite obvious which platform suffer from manufacturer fragmentation...
Come to think of it, we are using the pre-loaded TI address and advertise that as a public address.
Is that correct of us, i.e. are these addresses within a IEEE-registered address-space?

Best regards,
TMA

Hi TMA,
If possible, can you attach a screen shot of an advertising event? This should confirm the address matches the Adv flags.
The TI preloaded BD_ADDR is a public address.

Best wishes

Hi JXS,

As pointed out earlier we've been using the pre-loaded TI address and advertising it as a public address (see below).

Very convenient since we're interested in advertising a unique address for every individual device... but, as pointed out above this does not fly with Android 5.0.

After some testing I've found that Android 5.0 is not operating well with public addresses and simply changing it to a (random) static address solves the problem (se below, just pure luck that address stays the same). 

 

This works well on both Android 5.0 and previous versions (tested on several manufacturers).

Though I'm thinking that the simplicity of using a pre-loaded public address as a static address is not a very good idea. Two different public addresses might end up as identical static addresses because the random type is indicated by the MSB of the address. Yeah, I know it's unlikely but not impossible... ;-)

Regards, TMA

Hi Guys,

This may be the same problem listed here?:
e2e.ti.com/.../393198

I am trying to get my CC2540 with the SimpleBLEPeripheral (stack 1.4.0) example working again with Android 5.1 Lollipop.

What exactly are you changing in regards to ADDRTYPE_PUBLIC to get it to work? Will the stack be updated?

Hi,

Sure that might be the same problem...

You simply have to configure the stack to advertise a random address (static or not doesn't seem to matter) instead of a public public one. See my previous post on how to verify the address type. Then connecting to Android > 5.0 seem to work fine...

Regards, TMA

Hi TMA,

Sorry but I am new to this field. Could you elaborate a little more?

What I tried (from following your posts) was in the peripheral.c file I changed gapRole_AdvDirectType = ADDRTYPE_PUBLIC; to gapRole_AdvDirectType = ADDRTYPE_STATIC; in the GAPRole_Init function. That didn't seem to help and is probably way off from what is required?

Unfortunately I don't have the hardware to run a sniffer at the moment.

I appreciate your help.

I think this may be causing problems for a few other people as well so it would be good to get a response from TI here.

stackoverflow.com/.../android-could-not-connect-to-bluetooth-device-on-lollipop
stackoverflow.com/.../cannot-establish-ble-connection-between-android-5-and-ble-device

If we could:

A) get more specific instructions for modifying the software stack based on TMA611's findings
B) get a call from TI as to whether the software stack will be updated or if we should be hassling Android?

How many devices are out there using CC254x IC in peripheral mode that are no longer working as people update to Android Lollipop?

I've been testing CC2541 as BTLE peripheral on several Android handsets from different manufacturers and came to these conclusions on the subject PUBLIC/RANDOM Bluetooth Smart addresses:

- Pre-Lollipop this behaviour were manufacturer specific, e.g. Samsung and some Sony handsets were ok with public addresses but HTC were not

- With Lollipop (or more specifically Android 4.4.4) this behaviour became more or less manufacturer wide (at least with the handsets I have available for testing)

- I'd call it a bug rather than a feature since it is possible in to "fool" Lollipop handsets to connect with devices advertising public addresses, but only after successfully connecting to a device with random and not with full Android API support (e.g. reading RSSI still doesn't work).

I would say this is a big problem for many developers of peripheral equipment since you often want to advertise a publicly known, unique address. This is not fully possible to do with random static addresses since two bits of the actual address are used to indicate type of random address. To be really sure you'd have to use a private address range with 46-bit addresses.

Hence, I think we should hassle Google big time for this, though I'd give very little hope on a "quick-fix". My experience with Google (at least with matters concerning Android) is that they are really, really slow at even answering questions on their forums. They could at least give us information if the public address behaviour is a bug or by choice. Personal opinion though... I do most work on iOS. ;-)

About configuring the TI stack: You cannot change the default address type just by changing gapRole_AdvDirectType. Instead you have to use GAP_ConfigDeviceAddr() to configure the desired address type AFTER the stack has been initialized.

Regards, TMA

Thanks for your reply.

I am still having difficulty with the stack workaround.

peripheral.c

GAPRole_Init
gapRole_AdvDirectType = ADDRTYPE_PUBLIC;
Set to:
gapRole_AdvDirectType = ADDRTYPE_STATIC;

---------

static void gapRole_ProcessGAPMsg( gapEventHdr_t *pMsg )
...
case GAP_DEVICE_INIT_DONE_EVENT:
...
if ( stat == SUCCESS )
...
Added this at the end:

VOID GAP_ConfigDeviceAddr( gapRole_AdvDirectType, NULL );

The BLE address is changing each time but still can't connect correctly.

If you are using ADDRTYPE_STATIC you need to provide an actual address instead of NULL. If this method call fails I think you would find that the TxAddr flag still indicates a public address. Might also be a good idea to clean out the bluetooth cache in your Android handset between retries when tuning the TI-stack...

Hi guys,

I have checked with SimpleBLEPeripheral in all default configurations and my Galaxy S5(T-Mobile, Lollipop 5.0) and it just worked fine. Sorry we couldn't locate any 5.0.1 or 5.1 android device yet. I will update when I get a chance to have tests with 5.0.1 or 5.1. Sniffer logs showing both success and failure cases would help us a lot.

By the way, please refer to this post regarding how to set the static address: e2e.ti.com/.../414771

- Cetri

TMA6611 said:

If you are using ADDRTYPE_STATIC you need to provide an actual address instead of NULL. If this method call fails I think you would find that the TxAddr flag still indicates a public address. Might also be a good idea to clean out the bluetooth cache in your Android handset between retries when tuning the TI-stack...

In the comments of GAP_ConfigDeviceAddr it says "NULL to auto generate otherwise the application can specify the address value".

I tried the code from Centri's link:

uint8 mac_pseudo[6];
LL_PseudoRand((uint8*)mac_pseudo, 6 );
GAP_ConfigDeviceAddr( ADDRTYPE_STATIC, mac_pseudo );

I am getting random addresses after each restart of the device but still cannot connect/discover services. This is on my Nexus 5 with 5.1. For me the Nexus 5 was connecting on 5 and 5.0.1.

Hello, and thank you for the information you provided.

I have a similar issue, of GATT connection error (133), when advertising interval is greater than 2 seconds (~50% connection success rate at 5 seconds interval).

I am using :

• nRF Master  Control BLE application
• Android 5.1.1
• CC2541

I've tried this modification, in order to get a Static address

   

Peripheral.c
============
        ....
        gapRole_AdvDirectType = ADDRTYPE_STATIC; // Was ADDRTYPE_PUBLIC
        ....
        if ( gapRole_AdvDirectType == ADDRTYPE_PUBLIC ) // Was uncoditional
            VOID osal_memcpy( params.initiatorAddr, gapRole_AdvDirectAddr, B_ADDR_LEN );

This did not help.

It seems that the connection success reaches 100% only when the advertising interval is 2 seconds or less.

TMA, how did you manage to solve the connection problems?

Thank you

Koby

Dear Sir,

I have same issue and suffer that, read many relative posts in the forums and try many methods to change TxAdd to 1 but still doesn't work still 0, could help provide example code base on simpleperipheral to let's know how to change to ADDRTYPE_STATIC from ADDRTYPE_PUBLIC and TxAdd will also change to 1. It should be an examplein of SDK for TI teachs developers how to change address type from ADDRTYPE_PUBLIC to ADDRTYPE_STATIC , otherwsie no one know the right way to do that just try error repeatly.

Thanks in advance.

Hello,

In SimpleBLEPeripheral.c,  within the peripheralStateNotificationCB():

    case GAPROLE_STARTED:
      {
        uint8 ownAddress[B_ADDR_LEN];
        uint8 systemId[DEVINFO_SYSTEM_ID_LEN];

        GAPRole_GetParameter(GAPROLE_BD_ADDR, ownAddress);
        
        GAP_ConfigDeviceAddr( ADDRTYPE_STATIC, ownAddress ); // <- Add this line
..

Note that the MSB of your public address may be modified to conform to the Non-Resolvable Private Address Generation Procedure.

Best wishes

Hi JXS,

I tried it and this works can change Txadd to 1 not 0 now.

Thanks appreciate your help.

By the way I didn't quote understand your reminding "Note that the MSB of your public address may be modified to conform to the Non-Resolvable Private Address Generation Procedure." ? Could help give more detail explanation since I also not understanding what problem will happen and how to avoid it ?

Thanks

Hello,

Thank you for letting us know that it's working on your end.

Regarding the note about the MSB of the address, this is meant to let you know that the static random address you supply to the stack may not be the address you observe on the sniffer since the address must have the MSB bits set according to BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] , Part C, 10.8.2.1 Non-Resolvable Private Address Generation Procedure. This is meant to be informative only.

Best wishes

Dear JXS,

Here I found one issue if I use STATIC address in advertisement (Txadd =1) in the simple peripheral + observer  sample application.

The scan function will not find any device even it's in the white list if set TRUE to use whitelist in the GAPObserverRole_StartDiscovery function. 

but work fine and can filter whitelist devices if I use PUBLIC address in advertisement (Txadd =0) . Some questions list below and hope to get answers if possible.

1) Could help explain and let me know how to enable white list function during scan if I need use the STATIC address in advertisement (Txadd =1) .

2) How to enable MSB bits of address in BLE stack 1,4,2,2 ? could help provide simple instruction to test ? , what's the right procedure to using whitelist type (no bonding) of security with Android 5/6.x  environment ? (whitelist not workable anymore with Android 5.x becasue it uses PRA (Private Resolvable Addresses) ? ) .  

Thanks.

Dear JXS,

The first question I posted to another thread. ==> e2e.ti.com/.../564281

Another strange thing I found was:

Two same CC2540 device (HW and FW image) one can connect to Androd 5.x with TxAdd=0, PUBLIC address another can't connect to Android 5.x with TxAdd=0( PUBLIC address type) but can connect to Androd 5.x with only modification TxAdd=1, (STATIC address type) .

The device which can't be conneced will be discovered by Android APPs as CLASSIC and BLE type not BLE only even the Flags is 0x06.

Why some device an work but some device can't ? Is it possible to use TxAdd=0, PUBLIC address type with android 5.x without problem ?

Thanks

Hello,

There is no reason within the core specification why a Central device can't connect to a public or random/static address. The fact that the device in question is reporting LE-only devices as Classic points to one or more anomalies with this device. Unfortunately, this is not uncommon due to different manufacturer Android implementations. I suggest contacting the manufacturer of this device to see if there is a SW update or at least report the issue.

Best wishes