BLE Connect options

[Eric Vanderhoof]

Hi there,

I’m excited to see that the BLE blocks have been released in the Pilot version. I was working through how they could be implemented to allow communication between ESP32s, and I noticed that there is no “connect” block that allows for connected to a broadcasted BLE device. I’m assuming that this is what is meant by only having “peripheral” mode thus far, so that makes sense.

Other than the ESP32s, the only other devices I have available regularly are chromebooks. Could you recommend a block-based programming site that uses the web bluetooth standard to send bluetooth communication from a chromebook? I have looked at Snap!, but am coming up with a blank as far as other options. MIT App Inventor is not an option since I can’t install apps on the school chromebooks. I would like to replace our current ESP-Now based system, since it’s not officially supported by Microblocks.

Also, when a device is broadcasting on BLE, where does it get its name? With a classroom full of devices, I will need to figure out a way to distinguish between them.

I realize this is still early in development, but I just wanted to offer to try out any connection ideas you all have. Thanks for all you’re doing!

Sincerely,

Eric Vanderhoof

[John Maloney]

Your question is very timely! The latest MicroBlocks release includes preliminary support for communicating with boards that support MicroBlocks using the "Nordic BLE UART" service.

This features allows a phone, tablet, or laptop that has BLE support -- including Chromebooks -- to connect to a board and exchange data in both directions. The mechanism works using the WebBluetooth API from browsers that support it, including Chrome, Edge, and many Android browsers. That should allows us to create a Snap! library that uses WebBluetooth to connect to BLE-enabled boards.

The UART service will also work from App Inventor running on Android (but not iOS) devices using the App Inventor BLE extension. I've some done successful preliminary tests using that mechanism in App Inventor. I'm still working out the simplest App Inventor code to initiate a connection, but I am meeting with the App Inventor team later this afternoon and hope to get some useful advice from them.

The BLE UART mechanism is a one-to-one mechanism. If you want to broadcast to all boards within range, you can use the OctoStudio library to both receive and send broadcasts. (It currently only allows you to send five commands or "shapes" but may be extended in the future.) However, since the OctoStudio system sends broadcasts to all boards in range, there can be cross-talk issues if multiple student groups attempt to use it in a classroom setting. That said, it can be useful if only one person broadcasts at a time.

For ESP boards, WiFi Radio library is ideal. It is fast and supports separate radio groups, which allows groups of students to work independently of each other. There is no browser API for the underlying UDP protocol, so a Chromebook cannot communicate directly with boards using the WiFi Radio. However, a Chromebook could use a MicroBlocks program running on an ESP32 board to relay messages via UDP.

Finally, WebSockets is another alternative that works from the browser.

In short, there are quite a few ways to communicate between Chromebooks and ESP32 boards with MicroBlocks!

[Eric Vanderhoof]

Hi John,

Thanks for the explanation! I look forward to trying out the Snap! library once it’s developed. The possibility for keyboard and screen input in Snap! is something I’ve been interested in using with robots for years. Since my students are focused on competition robot control, I’ll probably end up going with whatever option has the best range and the lowest latency.

Thanks again,

Eric

[John Maloney]

Tomorrow I am having my middle-school robotics students create remote control panels that will run in the browser on their Chromebooks. The control panel will allow them to send simple commands to their micro:bit V2 based robots using the BLE Serial library.

If this works well, the next step will be to use Teachable Machine to send commands when it recognized images it has been trained on. The students will hold pictures in front of the Chromebook camera to control their robots. (This is to work a bit of AI into the course.)

The same thing could be done in Snap!

You need to use a browser that support WebBluetooth such as Chrome or Edge.

[Eric Vanderhoof]

Hi John,

I'm looking forward to hearing how that went. Does Snap! have a WebBluetooth library? I haven't seen one when I've looked.

Thank you,

Eric Vanderhoof

[John Maloney]

I don't think Snap! has a WebBluetooth library, but one could be added.

[Eric Vanderhoof]

Hi John,

It would be awesome to add WebBluetooth to Snap!, as it would give us a very versatile block-based environment to provide control by a variety of possible means. I have been researching any block-based coding environments that would allow us to make a progressive web app that could output bluetooth controls in the meantime. All I have come up with have been paid business application-making services. I did find a web bluetooth terminal, though I haven't experimented with it yet.

Here's its link: https://loginov-rocks.github.io/Web-Bluetooth-Terminal/

Here's its github page: https://github.com/loginov-rocks/Web-Bluetooth-Terminal

I suppose it could use an interface similar to this, though Snap! would do the same thing: https://github.com/QuirkyCort/IoTy-MQTT-Client

What language are your robotics students using to make their control interface? I look forward to seeing how that turns out.

Thank you,

Eric Vanderhoof

[John Maloney]

Another possible option if you want to target Android mobile devices is MIT App Inventor. Turgut has been experimenting with their BLE extension. Unfortunately, that extension does not appear to run on iOS devices. There is an iOS browser that supports BLE: "Bluefy". Not sure how well it would run Snap!

But for laptop/desktop computers, I think Snap! + a WebBluetooth library (to be written) would be a good solution.

[Eric Vanderhoof]

Hi John,

I hope your day is going well. I've used various web serial bluetooth terminals and have not yet been able to connect to the ESP32 running microblocks. There are quite a few devices in our school environment and I am not sure which is the microcontroller. Would it be possible to have a block that returns the bluetooth identifier that is analogous to the MAC address? Often it takes quite some time to have a bluetooth list update with the device names.

Here's the code I was using to read the bluetooth, in case that's helpful. Thanks for all the work you're doing to develop this functionality.

bluetooth_control1.ubp https://drive.google.com/file/d/1HV8jdFnXXHDKf9IcQM_SFEDMj829ygdA/view?usp=drive_web

[Turgut Guneysu]

Hi Eric,

John is teaching classes today, so I am jumping in.

Here is a MB program that will exchange BLE messages with ESP32 BLE.

https://drive.google.com/file/d/1oAPgQ0M3TtILpgEwPdPKKrZQvtxgBdeU/view?usp=sharing

ESP32 I am using is ESP-WROOM-32 DEVKit v1.

On Android side I am using the Serial Bluetooth Terminal program, from PlayStore:

‌

‌

‌

Here is a screen shot after connecting to ESP32BLE and exchanging messages:

Hello from Android
Hello from MB

‌

‌

‌

‌

NOTES:

• Make sure you are running latest Pilot (see under Settings/About):
• FLASH your device with the latest firmware for ESP32. * Make sure your Location option on your Android Phone is turned on. This makes BLE work and the phone detect devices. *
• The Android program will work with both Standard BT and BLE. Make sure to select the BLE option.
• Open the Terminal program, under DEVICES you should see ESP32 with the MicroBlocks 3-letter designation.
  Select it and then from the TERMINAL, connect to it and start exchanging messages.

‌

When you receive a message in the MB program, it will display it on the IDE (since you don’t have a screen on the ESP32).

‌

‌

By the way, here is a screenshot of your program receiving from ANDROID Terminal APP:

‌

‌

Hope this helps.

Turgut

[John Maloney]

Thanks for providing this example, Turgut!

Things worked pretty well with the robotics class today.

The technology itself worked perfectly, but the work flow I had them do was cumbersome and confusing for some students.

In particular, the script I gave them in the starter project had the "start BLE serial" under a "when started hat". However, when the board running BLE serial the IDE can't connect to it using BLE. Since I knew that, I also provided a "when button A pressed" script that called "stop BLE serial". But the students kept forgetting to press the A button and so they could not connect to the board from the IDE. (They could always use a USB cable to connect, but by now they are used to programming over BLE, which is more convenient when you are working on mobile robots.)

Clicking the reset button does not get them out of this situation because the "when started" script immediately runs and calls "start BLE serial".

Next time I'll put the "start BLE serial" under a button hat so it must be manually started. That would leave the board able to connect to the IDE after it is reset. It might also help to add some sort of visual feedback (e.g. flashing an LED a few times when starting BLE serial).

In spite of some problems, today's lesson went much more smoothly than similar remote control lessons I've led using two micro:bits (one as the remote control the other as the receiver). In this case, the controller was a web page so the students could focus on the receiving end of the system.

Creating a remote control system is more difficult than you might expect, especially if when one is writing code for the both controller and the controllee. Today's activity simplified things by using a fixed, web-based controller so students only needed to code the receiving side.

[Eric Vanderhoof]

Turgut, thanks for the example code and for the explanation on the bluetooth terminal program. I'll have to give that a try later this week.

John, I'm glad to hear the class went well. From what you're saying, you went ahead and designed a web page with predefined outputs that the students then could base their receiver programs around. I did something similar with the ESP-Now based remote control system earlier this school year. I provided basic code for two sticks on the controllers and a framework for making the remaining controls if the students were at that level of comfort with coding.

I'll let you know how the example code turns out and give you whatever feedback I can.

Thanks again,

Eric

[John Maloney]

There are quite a few devices in our school environment and I am not sure which is the microcontroller. Would it be possible to have a block that returns the bluetooth identifier that is analogous to the MAC address?

The latest pilot release has the block BLE id (in the Input category) that returns the three-letter code MicroBlocks uses to distinguish between BLE-enabled MicroBlocks boards. In BLE scans, MicroBlocks boards appear as "MicroBlocks XXX", where XXX is the three letter code for your board. The board stops advertising itself when either the IDE is connected to it (including via a hardwired USB cable) or when another BLE device is connected to it.

Also, you will only see the BLE UART service after the board has run the start BLE serial block. If that block has not been run you will still see the board scans but the service it advertises will be the (custom) MicroBlocks IDE service, not the BLE UART service.

BLE is only supported in the pilot release so you'll need to make sure that you've installed the firmware from a recent pilot release on your ESP32 boards. The latest pilot firmware is version 233.

[John Maloney]

I'm going to mark this as resolved since it isn't a issue with MicroBlocks itself, but feel free to continue to comment on it; we'll continue to see your comments.

[Eric Vanderhoof]

Hi John,

Thanks for the info - I'll give it a try once we get back to school from spring break. My first hunch is that I need to install the firmware from the pilot release, but we'll see! I'll let you know how it goes.

Sincerely,

Eric Vanderhoof