BLE Connection Error

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

exist a strategy to understand if a connection request has failed?

In an our application seems that sometimes the central device performs a connection request but the connection up callback, on the peripheral device, is not invoked.

The central device is a smartphone with Android 5.1 OS. In particular the APP receives the error 133 (GATT_ERROR)

Thanks,

Armando

0 Likes
12 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

There's no built in functionality for being alerted of a failed connection attempt from the peripheral side.

One possible implementation would be to register for a callback to receive low level l2cap packets, and filter through them to find the connection requests coming from the central. I'm working to make sure we can expose this functionality at the application level, but I don't believe it will be a problem.

This is assuming the connection process even got to that stage. It could very well be failing before receiving the l2cap connection request.

Jacob

0 Likes
Anonymous
Not applicable

Hi Jacob,

thanks for you suggestions.

Please tell me if you have any news about the l2cap callback or if you have other ideas to solve my problem.

I have read some discussions about the GATT_ERROR 133 but I haven't found the real cause of this error.

Armando

0 Likes

A google search of GATT_ERROR 133 shows that this is a very common error and doesn't seem to refer to any single problem. It seems that there is a different fix for it depending on your Android device. What Android App are you using? And what BLE application did you download to your peripheral?

I'm still working on this problem. I was unable to expose the l2cap packets, but am working on some other possible ways to be notified of a connection request from a central.

Were the error to actually be occurring at the GATT level, you'd have to already be in connection. Can you attach your UART traces from the peripheral? Perhaps this could give some clues.

Jacob

0 Likes
Anonymous
Not applicable

Hi Jacob,

the GATT_ERROR 133 is common but I didn't found a fix. We are using an our custom Android APP and an our custom BLE application. We have used the WICED SDK 2.2.2. Now we are trying to use the 2.2.3 version of the SDK.

In our BLE application code we have placed a TRACE message on the connection_up callback but seems that this callback isn't invoked when the smartphone tries to connect and receive the GATT_ERROR message.

Have you any ideas to observe if the smartphone really sends the CONNECTION_REQUEST without a BLE sniffer?

Thanks,

Armando

0 Likes

What do your UART traces show from the peripheral?

Your best bet will be to use a BLE sniffer at this point. The only way we could capture connection request packets from the firmware would be to patch the ROM code. This would take a very long time and give limited information compared to an air traces.

I also encourage you to try using BLE apps provided by the SDK and BLE test apps on Android and see if the error still occurs. That way you could attempt to narrow it down to either the Android App or the BLE App.

Jacob

0 Likes
Anonymous
Not applicable

Hi Jacob,

I've a trace message into the connection_up callback. When the problemi occurs I'don't find this message into the trace file.

Seems that the callback isn't called from the stack.

Now I've another questions: exist a way to trace the BLE services and characteristics that our device exposes after each connection?

During an other test we have encountered the following problem: after about 700 connection the smartphone has started a new connection and then a service discovery. After the service/characteristic discovery the smartphone hasn't found the UUID of a characteristic.

We want to understand if it is possible that the device hasn't exposed all the characteristic into the gatt_database.

Thanks,

Armando

0 Likes

Does this occur once and go away? Or are you unable to perform a discovery at all after it happens the first time?

How repeatable is this failure? Consistently at ~700 connections?

What do the debug traces of the peripheral show when this occurs? Does your Android show any errors occurring?

I've never heard of anything like this occurring, but will look into it.

Jacob

0 Likes
Anonymous
Not applicable

Hi jakewtorres

the problem that the APP is not able to find a characteristic, didn't occur again.

For the GATT_ERROR (133) we have noticed that if we try to connect and disconnect more times (about 1000 times) in an ambient without other RF devices the occurrency of the error is very low (one or two time maximum).

It is possible that this error occurs for RF collision?

Armando

0 Likes

Yes, this is possible. When a connection request is sent by the central, it doesn't wait for an ACK from the peripheral. So, whether or not the transmission is corrupted in a noisy environment, the central has no way of knowing that the connection failed until the peripheral fails to respond thereafter. This is very likely the error you're seeing.

pastedImage_2.png

Since your rate of connection failure is a higher than we normally expect, I recommend that you try a different central device--Android or iOS--to see if the error is isolated to your current central of if you are working in an unusually noisy environment.

Jacob

Anonymous
Not applicable

Hi Jacob,

we have repeated the test with different Android device and we have noticed that the failure is always high, between 3% and 10%.

With IoS the problem never occurs.

Armando

0 Likes

The problem is clearly stemming from Android according to those results. The rate of failure is not unheard of, but is higher than average. It is up to your Android application to have stable error-handling functionality to resend the connection request packet until the slave responds.

Jacob

Hello Armando,

For air traces you could use a cheap ble sniffer to see what is getting sent. Here is one from Adafruit which is around $30 and you can connect it to wireshark to view the traces.

https://www.adafruit.com/product/2269

Hope this helps.