Hi team,
I'm currently updating a few Micro:bit projects for a curriculum and replaced the BLE and Micro:bit extensions with the latest versions (edu.mit.appinventor.ble-20230728.aix and com.bbc.microbit.profile-20200518.aix) and all works well on older versions Android (11-), except when testing with Android 13 (Samsung Galaxy Tab S6 Lite, Android API version 33), it seems that the response with the startscannning and stopscanning functions are really slow as can be seen in this video ( IMG_4545.MOV - Google Drive ), but it's a lot quicker in other devices e.g. Android 11 Samsung phone. Anything that I can do to finetune it? I've tried changing the timeout properties but doesn't seem to help, and checked the NoLocationNeeded in the extension. Could it be related to the local resources when running on Android 12+?
Attaching the project for your reference. Many thanks!
Cheers,
Ed
Athlete_Data_STARTER_copyBLE.aia (448.6 KB)
1 Like
Hi @Edward_Cheng,
The NoLocationNeeded flag is only used in the case of compiled apps. It doesn't apply in the companion. I think at least some of the performance difference is due to the fact that Google is trying to make BLE use even less energy in newer Android versions starting with 12.
We don't have any code specifically for Android 12 and later that would intentionally slow down the scan. It's possible that Google added some newer flag that causes the scan to be slow by default for battery life preservation that we need to work around.
Cheers,
Evan
1 Like
Hi Evan,
Many thanks for the clarification! Bit of a UX issue but should be able to work around it. Many thanks!
Cheers,
Ed
Here's a build where I've explicitly called setReportDelay() to 0. See if that helps mitigate the timing issues on the newer devices. Note that after loading the extension you will need to restart the companion app.
edu.mit.appinventor.ble.aix (202.0 KB)
Thanks a lot Evan, doesn't seem to be much different though. Anyway no worries, I'll rework on the app with an option to store the Micro:bit ID + subsequent auto-scanning/connecting such that the user will only need to manually select it for the first time. Thanks!
Did that fix the slow scan issue Edward? As I understand it, even if the device address is hard-coded, the BLE extension still needs to find it in it's list of available devices....
Hi Chris,
Apologies for the radio silence — I haven’t logged in for a while. I’ve recently updated the BLE extension to version 20240822, and it appears to have broader compatibility across a range of Android devices now, which is great to see.
That said, scanning performance remains a bit slow, particularly in classroom settings where there are dozens of Micro:bits nearby. We’ve found that initiating the scan away from the classroom, e.g. 20+ meters, results in noticeably faster scanning and smoother connection. I suppose this is just a limitation of how BLE behaves, rather than something that can be resolved within the extension itself.
Cheers,
Ed
Hello Edward
Yes, that is the case, so many different signals and receivers in one place can be difficult. The classroom may also have some physical boundaries that Bluetooth struggles with, furniture and people in the way, large areas of metal such as heating radiators etc.