Galaxy Tab A8 (SM-X200) Connection Issues with GATT Error 133 after multiple connecting failures

[Marius Heil]

Hello,

we are currently experiencing a lot of trouble with a product of ours which has been used in the field since a long time but was only compatible with iOS devices so far. We are now close to publishing an app for android as well and have been testing with a number of devices.

The Gatalxy Tab A8 is however giving us a lot of trouble. It is a relatively new android tablet device and needs to be supported.

How to reproduce:

- The App tries repeatedly to connect to a bluetooth device of ours, running our custom firmware

- If the RSSI to a test device is below -75 / -80, the connection procedure repeatedly fails very often to establish a connection

- If the connection fails for a number of times (e.g. around 100 times), the tablet seems to be in a state where it will not connect to nRF devices anymore

- The device will however be able to connect to non nRF devices (e.g. an Apple TV or some other 3rd Party devices)

- We used the pre-compiled nRF52832 and nRF52840 examples for the peripheral heart rate monitor service to establish a connection, but the connection always fails for SoftDevice 5.1.0 and SoftDevice 7.1.0. We have tried this connection using an app from the PlayStore called "LightBlue".

- We have used PCA10040 and PCA10056 for testing.

- Trying to connect to an nRF device with with the HRS example app fails until we disable bluetooth on the Galaxy Tab for some time and then activate it again.

- We have also tried to keep nRF devices off until the tablet is in its "failure state" to be sure it is not linked to devices that were previously discovered.

It looks like the tablet can go into some state where it will become incompatible with nRF devices until the Bluetooth Stack has been rebooted.

Can anyone help me with this?

Side Note: Maybe this can be a similar issue to these that are also linked to nRF devices:

Samsung Galaxy Tab A8 does not work with nRF Mesh Android App - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

DFU fails with "Characteristic write error: 133" on Galaxy Tab A8 · Issue #339 · NordicSemiconductor/Android-DFU-Library (github.com)

Thanks,

Marius

[Edvin]

Hello Marius,

First, I just want to mention that the lins you provided are not necessarily related to your issue. The GATT error 133 on Android is the most common connection error, and it is a very generic error saying: "Something went wrong". It doesn't really give much information. 

Can you please try to capture a sniffer trace of the connection? For this you can use the nRF Sniffer for Bluetooth LE. Preferably, please collect a sniffer trace from one connection that successfully connects, and one that doesn't. Please upload the sniffer traces here as .pcapng (standard) files.

Do you use encryption (pairing or bonding) in your application?

Did you only try the light blue app? If so, can you please also test with the nRF Connect for Android? (for debugging purposes, just to make sure that the lightblue app doesn't do anything strange).

Wen the connection fails on the Android with error 133, does the log from the nRF say anything? Does it see the connected event? And if so, do you also see a disconnected event? If so, what is the disconnect reason in that event?

Best regards,

Edvin

[Marius Heil]

Hello, thank you for the response. I will collect a log, this will however take a few days. I know that the Error 133 is very common, but in this case it was directly linked to nRF devices only.

Some info upfront:

- I have also tried the nRF connect App and it will not work as well. It will show that it connects and then it will disconnect

- In the Segger debug log of the chip, the device will see a connect and will then see a disconnect, but I will get more details here.

- No BLE pairing/bonding/encryption is used in our case as we are doing the encryption on the application level

Marius

[Edvin]

Hello Marius,

Hopefully the sniffer trace will shed some light on what the issue may be.

Please note that I will be on vacation from Thursday, so if you are not able to upload a sniffer trace before then, then you may want to create a new ticket, so that an engineer that is working the rest of the week will be assigned your ticket.

You can see the disconnect reason as part of the disconnect event. Something like this:

        case BLE_GAP_EVT_DISCONNECTED:

            NRF_LOG_INFO("Disconnected. conn_handle: 0x%x, reason: 0x%x",
                         p_gap_evt->conn_handle,
                         p_gap_evt->params.disconnected.reason);

Also, the log from the nRF may say something else for why they are disconnected, if it is related to bonding.

Best regards,

Edvin