[Bug] The hub took too long to respond (Android)

[laurensvalk]

Describe the bug
Firmware installation gets to 100%. Then after a few seconds this error pops up:

The hub took too long to respond

When you turn the hub on after this, the light blinks purple so there is no firmware. This happens on Technic Hub and City Hub.

Move Hub works fine.

To reproduce
I used Pybricks Code v1.0.0 with Android 11 on a Moto G Pro. This is Android One so fairly close to stock Android with little manufacturer customization.

Also happens on Pybricks Code Beta 1.1.0-beta.3

Related 1

I would rather start a new issue about Android since this one is about macOS.

Originally posted by @dlech in #329 (comment)

Related 2
#400 (Now deleted?)

[dlech]

Can you log the Bluetooth packets when you repeat the problem?

[PierreArch]

I am experiencing the same issue with my Samsung Tab S6 running Android 11.
I cannot complete the download to my Powerup hub. I works well with the LEGO Powerup app. I have made several attempts toggling between both environments with no avail.

[dlech]

To solve this, we will need more information. See #270.

Chrome developer tools can be attached remotely. https://developer.chrome.com/docs/devtools/remote-debugging/ (this changed somewhat recently, so hopefully the docs have been updated)

Capturing Bluetooth packets on Android seems to change every few releases as well. On my Android 8 phone, I go to System > Developer Options and turn on Enable Bluetooth HCI snoop log. Then reboot for good measure. Then repeat the steps that caused the error. Then turn off the log. Then reboot. Then (on the same menu) Take a bug report. I don't remember which option from there, maybe Full Report. Then you can email the report to yourself, or something like that. Then buried in the report somewhere is the Bluetooth log.

[laurensvalk]

Can you log the Bluetooth packets when you repeat the problem?

I will. I might also try a few older builds of Pybricks Code to see if it got introduced there (vs. an Android update.)

EDIT: Maybe not. When accessing the build over the local network it says that the browser does not support Web Bluetooth.

[PierreArch]

Hi, Please find here attached, two different tentative I made at a few minutes intervals. I hope this will help you resolve this issue. In the mean time, I can use my EV3.

[dlech]

Github does not accept email attachments, so you will have to open the issue in a web browser and attach it that way.

[PierreArch]

Here are the files. Tks

btsnoop_hci.log.zip

[dlech]

Thanks very much for this. From the logs, we can see the problem. The payloads are being truncated.

The size says how many bytes are being sent (including 4 bytes for the flash address), so the payload should be 36 - 4 = 32 bytes, but it is only 14 bytes.

I'm guessing that somewhere between Android 8 and Android 11, the default MTU negotiation behavior changed and it is using the smallest possible MTU (23 bytes) which limits the payload to 14 bytes (and size should be 20).

There is no way to get the MTU through existing web browser APIs. And we are just making the assumption that all platforms negotiate something higher, assuming the Powered Up hub supports it (the BOOST Move hub has max MTU of 23 anyway, so it should theoretically still work on Android 11 already).

Or maybe I have only flashed BOOST Move hub with Android and the comments about 8 vs. 11 are invalid? (The rest of the comments still apply though.)

So to fix, our options are:

1. Always assume the minimum MTU. This will make flashing firmware slower, but should always work.
2. Add a platform detection for Android. This will fix the immediate issue, but the problem could happen on other platforms in the future as well. And platform detection in web browsers is notoriously fragile as well.
3. Fix the Android MTU bug in Chromium itself. https://crbug.com/1164621
4. Implement getting the negotiated MTU in Chromium itself. API which provides the negotiated MTU is required WebBluetoothCG/web-bluetooth#383

[dlech]

It also seems odd that we aren't getting an error from a bad checksum since the hub is not receiving all of the data. So there could be a bug there too.

[dlech]

I think 2. in the short term plus 3. and/or 4. in the long term could be feasible.

[laurensvalk]

Regarding your question about move hub working in theory, this is also true in practice (see first post in this thread).

And option 2 as a first step seems like a good plan 👍

And thanks @PierreArch !

[dlech]

Or maybe I have only flashed BOOST Move hub with Android and the comments about 8 vs. 11 are invalid?

I seem to have some faulty memory modules between my ears. I was able to reproduce on Android 8 and confirm the fix works.

[PierreArch]

I am glad I could help by sharing the files, how can I use this fix now? I am new to GitHub and I am not sure what to do next. I tried the app using the same shortcut and it didn't work !
Please advise,

[dlech]

As noted in the changelog, the fix is still unreleased. But I'm actually planning on doing a release today, so you won't have to wait long.

[dlech]

Fix is released in Pybricks Beta v1.1.0-beta.4.

[laurensvalk]

Fix is released in Pybricks Beta v1.1.0-beta.4.

Confirmed working 🚀, so we can probably close this.