Cannot connect over Bluetooth to PXT paired micro:bit

[whaleygeek]

microbit.org-ticket: 389 pxt-ver: pxt.microbit.org version: 0.6.13

Cannot connect to a micro:bit over Bluetooth where it has been paired via a PXT loaded script.

I tried this as follows:

phone: Vodafone VF-795 android: 5.1

1) Clear any bluetooth pairing record from android. flash a PXT script in via USB. Go through the pairing process, which works. Try to CONNECT from the android app - fails.

2) Clear any bluetooth pairing record from android. flash an identical Blocks script in via USB. Go through the pairing process, which works. Try to CONNECT from the android app - works.

We also noticed that the hex file for the PXT script for the identical script is about 6K shorter. The script only has a single 'show leds' in it, showing the letter 'Y'.

pxt_connect_fails.zip

[jaustin]

@bluetooth-mdw I think we might need a little assistance here - is the procedure described above what is meant to work? If so, how can we proceed here?

[pelikhan]

Successfully tested with JustWorks and Passkey settings and Bitty Data Logger on Samsung Galaxy S5, Android 6.0.1

[ghost]

Sounds like we need the PXT script and/or hex file.

The only thing I know that would prevent you from connecting to a micro:bit you'd paired with is if something else had already connected to it. nRF Connect sometimes seems to do this behind the scenes. Suggest they use the onConnected/onDisconnected event handlers in the PXT app to display "C" when connected and "D" when disconnected to check the connection state.

[kenyoncoder]

Some confusion seems to have arisen. I originally raised this issue with the micro:bit foundation support desk and @whaleygeek reported it here.

My objective was to use the Samsung Android App on my phone to flash code to a micro:bit over Bluetooth. The guidance given is to flash some simple code over USB, pair using the Samsung App and then you can either flash one of the provided examples from within the Samsung App, or create a new piece of code via the phone.

What I identified and what @whaleygeek reported here is that if you create a simple piece of code eg flashing one LED on and off, using Blocks, the above processes with the Samsung App work.

If you create the same piece of code using PXT, you can pair, but you can't flash code from the Samsung App. Furthermore, the .HEX file from Blocks is 6K bigger than the .HEX file from PXT, suggesting something may be missing??

I can now add a little more information:

The default configuration for PXT includes Radio but not Bluetooth - this is the configuration I was using, because there was no other guidance and it doesn't work.

I have since discovered that if you add Bluetooth (even though you don't intend to explicitly include any Bluetooth blocks in your code) to the configuration, (and therefore remove Radio from the configuration) and then compile the same code as before, the .HEX file is bigger and everything now works with the Samsung App.

I hope this helps

[ghost]

Thanks @kenyoncoder that's a nice, clear explanation.

'Radio' doesn't work because it's not Bluetooth, it's a proprietary wireless technology which smartphones do not support.

Glad you solved your problem too. What do you think should be different in PXT to help avoid this issue?

[kenyoncoder]

Thanks @bluetooth-mdw

I think there are 3 possibilities:

1. Provide clear guidance on the Web that PXT, in its default Configuration, will not produce a .HEX file that supports flashing from the Samsung App, and that the Bluetooth package must be loaded, even though there is no intention of using it.

2. Include the necessary component(s) of Bluetooth (but not expose them) in the default configuration. I have no idea how realistic this is.

3. Make Bluetooth the default package instead of Radio.

Even the 1st possibility, (assuming I could have found it) would have saved me hours of experimentation with different phones and tablets and hours of googling looking for an answer.

[ghost]

(3) would certainly get my vote :-)

I'll leave it to @pelikhan to ponder this one though. Some good observations about user experience here I think.

[whaleygeek]

This seems wrong to me still.

So, if you want to flash a PXT script over bluetooth, that when run on the micro:bit uses the radio blocks, how would we do this?

[pelikhan]

You don't, they are mutually exclusive.

[pelikhan]

We are planning on a revamp of the "new project" experience which would allow for a BLE template.

[jaustin]

pelikhan wrote:

You don't, they are mutually exclusive

I'm not sure that's right, or at least not sure it needs to be - SoftDevice and the Bootloader are still actually built into a binary that uses the radio. If you enter the bluetoothy pairing mode with a radio script, can you not update that way?

If not, then it would be good for @jamesadevine and @finneyj to take a look to see if this would be possible (the work that we're planning to do on the bootloader might make the bootloader itself a possible vector for this too, so pxt/DAL wouldn't need to know)

[finneyj]

Folks, I think SoftDevice and bootloader are present in all PXT builds, but disabled (assuming we're still using the "bbc-microbit-classic-gcc" yotta target). If you drop the micro:bit into pairing mode, you can program it using Bluetooth, then reboot it and run the users script.

A bit fiddly, but we put this in as a back door so that any BLE capable build of the runtime would always have a guaranteed route through which it could be reprogrammed over BLE.

[pelikhan]

This issue seems to be related to the DAL not PXT.

[whaleygeek]

@finneyj Is there a ticket allocated in the lancaster-university github that I can follow the progress on this on?

[finneyj]

@whaleygeek no ticket on microbit-dal, as unless I've misunderstood something, we already have the behviour described above. If you enter pairing mode, you should always be able to reflash using BLE, even if the user script does not enable BLE itself.

[whaleygeek]

@finneyj Oh I get it now. So, our docs say you should just press the CONNECT and FLASH buttons and it should work. The user followed the docs and it did not work. But there is a 'back door' way of doing this by puttting into pairing mode, which you say works (and actually the iOS app guys have confirmed this works for them).

It seems to me we need to change our docs and always get users to enter pairing mode before trying to flash code, as reports I have from the iOS team is that this works reliably and the app-assisted method fails quite regularly.

I'll close this particular issue as it is, as @pelikhan not a PXT issue, and as @finneyj says, not a DAL issue. It's a docs issue.

Thanks

[finneyj]

right! Thanks @whaleygeek. Curious why entering pairing mode is more reliable though - it's exactl the same code on microbit-dal. let's chat about that offline.