Bluetooth device connection: sometimes OS doesn't have device-specific name and so micro:bit isn't visible
Closed this issue · 8 comments
I've seen a couple of instances where micro:bits of mine (which may have been used with other BLE applications on this laptop, for example as a HID keyboard, etc) are not detected in ml-machine.
They are not visible in the browser popup when selecting a device.
It appears to relate to a specific micro:bit (at any time), and enabling/disabling Bluetooth doesn't help.
By using this page, I can see that for the offending micro:bit, macOS thinks it is called "BBC micro:bit" not the full name. Same device, same hex on a different machine has the correct name.
Our supposition is that my machine has cached the "BBC micro:bit" name (without the specific name) on a previous use with a different hex.
One workaround that would enable a user in this situation to continue would be to allow opening the Chrome pairing window with no name filter, or just a "BBC micro:bit" name filter. Poor in a classroom scenario, but perhaps not terrible as a fallback.
@martinwork I think you might have a quick summary for why/when a micro:bit might get caches as being a "BBC micro:bit" not "BBC micro:bit [xyxyx]" - is this when we have had BLE advertising but not from pairing mode?
CC @microbit-matt-hillsdon this will apply to the micro:bit ML tool branch too
So you are saying that the OS has swapped out the name for a shortened version, because it has previously been connected? Am i understanding this correctly?
I think having a fallback is a good idea, although I am not entirely sure how this would be implemented, as we then have to display the name instead, which only the browser knows the necessity of, since the micro:bit wouldn't have any idea whether to display pairing pattern or name
Yes, the OS has at some point seen the micro:bit advertising without it's unique code (I'm not sure the full set of circumstances in which this can happen but at least one option seems to be that you have enabled whitelisting and you have previous bonds, but are not in paring mode, and have the BLE extension in your MakeCode program). So it's more that the OS seems to have cached the name and isn't (for some reason) updating it. (Maybe because this micro:bit has previously bonded as, say, a BLE HID keyboard, but I have tried removing the bond in macOS prefs but it still doesn't show up)
For the fallback, the micro:bit is actually doing the right thing (showing the pattern and broadcasting the full name) but the OS seems not to be feeding the right name to Chrome (OR Chrome has cached the name, not the OS, I could debug that)
So, just calling
navigator.bluetooth
.requestDevice({
filters: [{ namePrefix: `BBC micro:bit` }],
[...]
would lilkely work
@jaustin Yes, I still think that, in theory, [xxxxx] is present when the last connection was to Bluetooth pairing mode, or the hex is open security (so not whitelisting and using the shortened name in application mode).
This is relevant: https://developer.apple.com/documentation/corebluetooth/cbperipheral/1519029-name?language=objc
"A peripheral may have two different name types: one that the device advertises and another that the device publishes in its database as its Bluetooth low energy Generic Access Profile (GAP) device name. If a peripheral has both types of names, this property returns its GAP device name."
But I think the micro:bit gap and advertised names are always the same.
https://github.com/lancaster-university/codal-microbit-v2/blob/a3492c4378be02a0071721dbc5a7164840be5a11/source/bluetooth/MicroBitBLEManager.cpp#L266
I don't know what triggers the client OS to update its cache. Related: service changed, peripheralDidUpdateName: and peripheral:didModifyServices:.
An experiment with iOS and nRF Connect... Having cached the short name by pairing and then connecting to a just works hex in normal mode, I had to forget the pairing to be able to connect to a USB flashed ml-trainer-universal-hex (peer removed pairing information), then iOS seemed to need 2 connections before the full name appeared in Settings.
This seems a bit odd. I think if cannot force the name to appear in the pairing menu through tweaks to the micro:bit program, i think we will have to settle for the fallback solution for now.
I'm still not sure how we would approach this change to the UI. At the moment we diplay a red warning when user cancels the device request
Maybe add an extra button to search for devices with the base name without [xxyyzz] or a link to the text which opens the device request with just the basename. How should be explain to the students that this could be an issue, without introducing unnecessary clutter? What do you think @Karlo-Emilo
@r59q Maybe a text with a link that is a button to open the unfiltered list of Bluetooth devices. Then users won't click on it just because it is a button. We could also hide it untill users have opened the Chrome Bluetooth Menu without successfully connecting to at device.
I really want to avoid the situation where students connect to each others applications as it can be difficult to debug in the classroom.
@r59q Maybe a text with a link that is a button to open the unfiltered list of Bluetooth devices. Then users won't click on it just because it is a button. We could also hide it untill users have opened the Chrome Bluetooth Menu without successfully connecting to at device.
I don't think I quite understand the proposal here? I think if the user returns to the app after not selecting a device?
I think that red text could just contain the option "or see all micro:bit devices" where the see all micro:bit devices is a link to open the dialog again with no filter?
I really want to avoid the situation where students connect to each others applications as it can be difficult to debug in the classroom.
Yes, I strongly agree! Is there a way to filter by ONLY devices without the specific name? IE exclude devices with [....] in their name?
@r59q Maybe a text with a link that is a button to open the unfiltered list of Bluetooth devices. Then users won't click on it just because it is a button. We could also hide it untill users have opened the Chrome Bluetooth Menu without successfully connecting to at device.
I don't think I quite understand the proposal here? I think if the user returns to the app after not selecting a device?
I think that red text could just contain the option "or see all micro:bit devices" where the
see all micro:bit devicesis a link to open the dialog again with no filter?I really want to avoid the situation where students connect to each others applications as it can be difficult to debug in the classroom.
Yes, I strongly agree! Is there a way to filter by ONLY devices without the specific name? IE exclude devices with
[....]in their name?
I think we are arguing for the same solution. We will add a link to the red text, if the request device prompt was cancelled.
This link will open a new request device prompt, but with all microbits, i.e ignoring the [xxyyzz] part of the name
Yes, I think we have the same solution in mind. If we can somehow filter away devices with a specific name, it would be great.