Samsung Android 10 BLE Connectivity Regression

Mobile
28

Thank you so much
Aakarsh

29

I think scanning is not the problem for us, only the longer message after MTU changed is failed to be sent and the connection is cut off.

30

Anyone who is interested in tracking this problem, you can also look at https://developer.samsung.com/dashboard/support/19306,
I will keep update on the link above, but you need to sign in then you can view.

1 Like
32

Hi,

FYI. The link you posted goes to the dashboard, which is unique for each user. That ticket can be seen by you and the Samsung employees with access to Zendesk, but other developers cannot see it.

33

Here the reply from Samsung developers:
According to the log analysis, there have been many attempts by the application ā€˜eu.lukeroberts.lukerobertsā€™ to configure MTU size to 184 or 23. Link loss occurred after MTU has been changed in case of MTU size 184 only.
Our development team suspects that the remote device have encountered problem when MTU size has been changed to 184.

According to the Bluetooth specification, the link loss occurs because the packet is not received from the data channel for a specific time between the BT chipsets of both terminals. Therefore, it should be checked from your side why BT chipset did not send ACK packet to the data channel.

Please capture air log if possible. If you donā€™t have any air sniffer then you should check the source codes of the remote device to process MTU negotiation event pkt.

Best Regards,
Shaswati Saha
Samsung Developer Program

Currently we are still working on finding correct sniffer for us to get more bluetooth communication log, and then we can carry on.

Cheers.

35

Do you know when I turn on
ā€œEnable Bluetooth HCI snoop logā€ in the Developer options screen,
Where can I find the btsnoop_hci.log* ?
Is there anything useful in this log file to analyze this problem?

39

Hi, dan

Thanks for suggestion. Unfortunately, passing BluetoothDevice.TRANSPORT_LE to connectGatt does not solve issue. Itā€™s true I also tried

44

Iā€™m also experiencing the same problem with Galaxy S10+ (SM-G9750, Android 10, OneUI 2.0) other Galaxy S10 devices, while connecting to ESP32 chip. Requesting MTU causes 100% disconnect (Reason 0x8 - Timeout), while sending large data blocks over BLE. Only workaround we have found for now - is not to request MTU at all, but it makes data uploading too slow.

45

Your experience is a little different with us, the request of changing MTU to larger can be successful, only when you send the data is bigger, the connection will be cut off.
Anyway, our. temp workaround is also not requesting large MTU, we are working to provide more logs to Samsung to make it fixed.

Dante

49

Same problem here.

Several galaxy 7 and 8 phones tested and no issues.

Galaxy S10 fails with disconnect after sending large amounts of data.

Same problems with Redmi 6A Phone.

A fix would be nice!

It seems looking at a ble sniffer and the logs in this thread that the first large data packet is sent and ACK OK and then this packet is repeated many many times in quick succession until the ble stack panics and drops the connectionā€¦ but I am not an expert in this, just what I have seen.

52

We have the same problem for Android 10 Samsung phones. There is no problem with Android 9 Samsung phones or other Android 10 devices like Pixel. We lowered the message size but data transfer is really slow right now.

53

Any updates here?

We can confirm the exact same issue. Setting MTU > 23 followed by a write event causes a disconnect due to the timeout because the phone hardware never sends anythingā€¦

A few other findings we can read with MTU>23 and like everyone else this only happens on Android 10 Samsung devices.

@dan1580253621 any response yet? We can confirm the reason the phone is not getting an ack is itā€™s not sending anything. I think weā€™ve collectively tested this on enough devices to be 100% sure this is a Samsung issue. We get the ack from pixel device and from s10 running non Android 10.

Happy to help however we can but if supports idea of help is ā€¦ the phone sent the payload and your hardware didnā€™t respondā€¦ then this is a wasteā€¦ are they hearing us when we say it works on EVERYTHING ELSE but your device.

54

Hi @jos1586339450

Thank you for your update, and actually I open another ticket on the https://developer.samsung.com/dashboard

And Samsung developers have replied to me, they can reproduce this problem, and they can make sure that Samsung phones didnā€™t receive any ACK from the remote device, but they didnā€™t know the ACK is not sent by the remote device or the Samsung phones lost the ACK for some reason, they need me to grab the air log for them, then they can look into this problem.

You can read the reply I copied above, so the current problem is that I canā€™t get the air log because the WFH made me not able to work with my remote device team.

So if you can provide bluetooth dumpstate/btsnoop log and the air log which is the log from your remote device, I will chase them with your log and let them to take a look.

Thanks,

Dante

55

Dan the remote device is not sending an Ack because it doesnā€™t receive anything at all from the Samsung phones. Once you change the MTU>23 and attempt to write it fails because the Samsung is not actually sending the data.

Iā€™m going to try to reproduce this issue between 2 Samsung devices today just to prove the points.

If Samasung can reproduce this then why do we need to do anything at all? Can they not diagnose there own issues? Iā€™m happy to help,but pretending this is our remote devices fault is a joke. Thereā€™s atleast 5 of us in here with same problem and I bet thereā€™s 5 more that havenā€™t traced it down yet.

Unfortunately in my case we have live field devices and customers being impacted with no work around.

57

The temp workaround is not making MTU > 23, then the writing can work well.

There is some mistake about my expression, they just analyse my log, but not try to reproduce the problem.

If you think, you have enough log, you can submit another ticket on
https://developer.samsung.com/dashboard.

I think more tickets will make them to take more care about this problem.

Thanks,

Dante

58

Understood - Iā€™m working to create logs and will submit them tomorrow. That workaround is only valid if you donā€™t depend on a higher MTUā€¦which we absolutely do.

New learning today: Any MTU setting between 24 & 512 results in only allowing for a payload of 20 characters. You can set the MTU to 24 and send 20 characters all day. you can set the MTU to 512 and send 20 characters all dayā€¦but if you try 21 characters in either example the phone will ā€œNOTā€ send the payload, but it think it does send itā€¦then the timeout happens and the connection is closed.

I honestly donā€™t think the logs will show this glaring issue, but I will capture the logs tomorrow and upload it.

How quickly do they look and respond to the tickets @dan1580253621 ?

2 Likes
59

Generally support will reply within 24 hours but on this issue it has to go to another tier of support and total turn around time could be different.

If you can send me the ticket number in a private message, Iā€™ll ask that this be given some priority as it is a hot topic on this discussion board.

Ron
Samsung Developer Program

60

Agreed about being able to set the MTU and then still send the usual smaller payload and the phone disconnecting when you try and send more characters, same behavior here.

Thanks

61

Cool, thank you for your time and effort.

If there is any update, please let me know, we are still eager to resolve this problem.

Thanks,

Dante

62

Hi all,

I also sent my data and it is still under investigation. They know that an issue exists and many developers already sent them trace.

Lets see if we got a patch soon