-
Notifications
You must be signed in to change notification settings - Fork 583
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BleGattCallbackTimeoutException when writing a characteristic with different data payload many times in a short period of time. #855
Comments
Hey, thanks for using the library! This looks like an Android BLE stack error/unhandled situation. Most probably a HCI log would have hints on what is going on. Are those long writes you make related somehow to configuring your peripheral's BLE configuration? |
Thanks for your replying. Yes, I use long writes the characteristic with different data payload to configuring my peripheral's BLE. Could you guide me some tips to workaround this issue? |
First of all – what configuration are you setting specifically? Maybe it's not needed or timed wrong? As for the refresh, there is a topic about it already — it's possible |
Thanks for your tips. |
I don't think queuing these writes sequentially will help as they are executed sequentially FIFO anyway. If you could share what these individual writes are configuring it could help understand what is going on. Additional questions:
|
It is a feature called feature A of the peripheral device, when the application start or resume (move from background to foreground), I try to write/read configurations of this feature A, for example: get/set volume, get/set status (on or off),...
There are 5 different commands with data payload from 2 to 9 bytes.
No, I just try to write/read when the connection already is established. I also checked the BLE connection is connected or not before write/read.
It is already paired/bonded I am trying to write/read 5 different BLE commands when the application moves from background to foreground. The app and peripheral are always paired/bonded while app is in background. |
What does it change from the Bluetooth perspective? Are there changes in the bluetooth services available? Connection timings change?
If so, I see no need in using |
Thanks for your support. |
Thanks @dariuszseweryn. Their phone are: Samsung S23, S23 Ultra. Both are running Android 13. After the timeout exception, the bluetooth is disconnected automatically with either:
I wonder why the library automatically disconnect bluetooth in this case? Why don't we keep the connection and the application can handle the connection by itself? |
That was expected.
The library does not disconnect by itself but only reports what the Android BLE Stack is doing. You still did not share what Bluetooth connection configuration can change with those 5 commands you write so I cannot give you more suggestions apart of looking into the BLE Stack. To get more insight on what the Android BLE Stack is doing (or rather what it is not handling correctly) you would need to check the Bluetooth HCI Log. |
Sorry for making you confuse about the changing of BLE connection configuration by those 5 commands I write to the BLE device. The 5 commands just change settings for a function in the device that doesn't relate to Bluetooth configuration.
The commands don't change anything relate to Bluetooth. |
Now, the tester report that we are facing the BleGattCallbackTimeoutException on all BLE write commands that we send to device randomly. That means if we write a BLE command to device 10 times, each command 1 second apart, we can observe the timeout exception at least 1 time (1/10 tries). But it is odd that the bug is only observed in testers's environment with their Samsung S23 and S23 Ultra. I think I should check bluetooth HCI log on their phone. |
HI @dariuszseweryn ,
|
How do you verify that the peripheral did not received the write request? Is the write request successful in the HCI log? If yes, you could verify that the packet is actually (not) sent using a BLE sniffer. |
There are not any log line from the peripheral device's log when the write request is sent from the app via BLE.
From my understanding, the HCI log about write request is successful be like:
It is hard for me to sniff the BLE packets. Because I don't have the Samsung S23 phone. Anyway, What do you think if I do a trick to command read characteristic before a command write? To make sure that the Gatt client is working. |
Depending on the log level (stack/driver vs application) this may not be a decisive proof. i.e. it is possible the peripheral could receive the request but either stack failed on delivering the request to the application or the application itself did fail to create a log due to some silent failure. I haven't seen so far the issue you're experiencing therefore I am inclined to think that the problem lies in peripheral's firmware (I have seen a lot of them).
This could help if the problem is somehow related to timing of commands — it is rather a blind shot, though.
If you (or some tester) would be able to sniff BLE (I usually used an nRF dev-kit based solution) you could have a very concrete proof if the Android Stack is the problem or the peripheral side. If the Android would be the problem you could file a bug to Samsung. If the peripheral you would be sure that the firmware needs to be fixed (or peripheral's MCU vendor [TI, nRF, etc.] needs to fix their stack) Have you tested with other Android phone vendors? Google Pixels, etc.? |
But the tester reported that they did not observe the issue on IOS (My application is running on Android and IOS).
I also checked with other Android phones like: Google Pixel 7A, Samsung A52, Samsung S22 Ultra. But I didn't observe the issue. |
iOS has a completely different BLE stack and does implicitly different things than Android so it's hard to compare the behaviour between them. If extensive testing on other vendors's phones did not show the problem it seems that its model specific. HCI log you posted lacks a bit in the context of the requests that happened right before the failed one. You could compare if the only difference is the lack of the response or there is something more there. |
Hi @dariuszseweryn ,
|
Describe the bug
I have a BLE device with several characteristics and all of them are working.
But when I try to write 1 characteristic many times with different data payload in a short period of time (for 10 request in 5 seconds) by using com.polidea.rxandroidble2:rxandroidble:1.18.1 library on Android, it leads to BleGattCallbackTimeoutException and then automatically disconnect bluetooth with device. But I have an IOS application connects to the same BLE device, it still works as expected in the same scenario.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Smartphone (please complete the following information):
Logs from the application when bug occurs (this will greatly help in quick understanding the problem)
To turn on logs use:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: