AI2 – selecting BLE devices

This article could also be titled “Read the manual!”

Jetro asked me if it is possible to use the Powered Up smart hub with two train motors in a way that motors work both at same time but in opposite directions. The idea is assembling using a train with one engine wagons at each end like this:

So when the train is moving both motors can be used with just one control.

It is possible with medium motors (my Puppy robot does that when I use the joystick of the App just in a particular axle) and I checked with the only Powered Up train motor I have that it also works (medium motors and train motors seem to have same ID or no ID at all).

So I told Jetro it should be easy to rebuild my App for that specific purpose.

And it really was! Just remove the joystick-related blocks and add two sliders and a few check buttons. So at start only one slider is available and both motors (A and B) run at same speed in opposite directions:

A checkbox allows reversing the direction and the STOP! button quickly stops both motors.

If we want to control the two motors independently another slider appears:

Great, it worked with my Puppy so I asked Jetro for his BT address so I could add to my list of LEGO smart hubs.

But that’s silly!

Yes, I am lazy. But that’s really silly. There must be a way to scan for nearby BLE devices and choose the one we want to use.

So I read the documentation for the AI2 BluetoothLE extension. And they wrote several How Tos including a “Bluetooth Low Energy Basic Connection” that says “Make a basic app that scans for Bluetooth devices and allows you to connect to a selected device”. It also says is for micro:bit and Arduino… but I’m a sceptical old dog.

I didn’t quite copied the example… as I already were using a List Picker button I adapted the example to it.

So these are hte blocks that allow us to use the ‘Choose’ to select which device we want to control:

When the app starts it also starts scanning for nearby BLE devices. The first block above uses “when DeviceFound” to create a list with all devices found. This is list keeps being refreshed while the Scanning process is running.

The list contains the BT Address of each device, it’s friendly name and the RSSI at the time of discovery (a kind of measure of the signal strength that we can use to decide if it is near or far from us).

So when we pick a device from the list (second block above) the text property of the button changes from “Choose” to the friendly name of the device chosen. This name is returned by the “call FoundDeviceName” (not in the original HowTo, that’s why reading documentation is important).

When we press the Connect (or Disconnect) button we now use a slightly different method: “call Connect Index” instead of “call ConnectWithAddress”. I also took the chance to stop the scanning process or restart it (previously the scanning was always running).

So now my App can be used by any one. I feel I’m almost a programmer by now 😀

This is how it works with Puppy:

now I just need to get a second Powered Up train motor to test it with a real LEGO train.

A final note: today at office I found a lots of bluetooth devices nearby. I’m not sure that all are BLE but that’s what the App adds to the list. So I should add a way to filter this list for LEGO-only devices. That means devices whose BT address starts with “”00:16:53” (all my BOOSTs smart hubs) or “90:84:28” (my Powered Up “HUB NO.4” smart hub)… but if LEGO sells lots of these I will probably have to add a few other headers.

Making an Android app for LEGO Powered Up – explanation

So how does this “App Inventor”-thing work?

To create an app for Android we just need a browser to access the online app creator tool. We have a Design view where we add our components like buttons and sliders and a Blocks view where we use the method blocks provided  by each component we added to our Design.

We can build our app and download an ‘apk’ file to install on our Android phone or tablet but that’s not practical while we are still testing some ideas and debugging the way our blocks work. So the best way is installing the MIT AI2 Companion App on our Android device so every action we make in the online tool is synchronized to it through USB or wi-fi.

App Inventor 2 provides a Palette with lots of usefull components but to use LEGO Powered Up we need to add an Extension that allows AI2 to talk with Bluetooth Low Energy devices. At the moment BluetoothLE is the only supported extension and I must say they have been doing a great work this last year (they even gave me access to a beta version a few months ago while fixing a bug I was dealing with) including writing a good explanation of all the blocks provided with some examples for Arduino and BBC micro:bit.

After importing the extension  we just drag it to the Viewer to get a ‘BluetoothLE1′ component at the bottom of the Viewer, on the “Non-visible components” area. Doesn’t seem much but if we change to Blocks view and look to this component we’ll see lots of blocks.

So let’s start creating our App!

We will use some BluetoothLE blocks to communicate with our LEGO “HUB NO.4” device. This blocks require a ServiceUUID and a CharUUID that we will store in global variables:

Currently the ServiceUUID and CharUUID are the same as LEGO BOOST hub but please note that there is no guarantee that future firmware releases will keep them allways equal.

We will also create a list of our devices:

Yes, a list of one device is silly but I have more devices like my BOOST Vernie and of course I’m planning to have a few more Powered Up devices in a near future so a list is usefull. You can call whatever you want to your devices but you need the Bluetooth address of it (so “PUP#1” is just an easy to remember tag that I choose for my “90:84:2B:06:AB:5D” hub).

You can get your BT address installing Nordic nRF Connect for Mobile app on your Android device and scanning nearby BLE devices while turning your LEGO hub on. If you changed its name with the LEGO App you will see a BLE device with that name, if not you will see “HUB NO.4” or “Smart Hub”, depending on the firmware version of your hub:

Now we go to Design View and add all components needed:

From the ‘User Interface’ section:

  • two buttons: ‘BtnConnection’ and ‘BtnRst’
  • one ListPicker

From the ‘Drawing and Animation’ section:

  • one Canvas
  • one ImgSprite

And from the ‘Sensors’ section:

  • one Clock

I added a few others that are really not needed, just used them for aligning and cosmetic purposes.  I also renamed the buttons names to better remember their purpose and changed some of their properties.

Now back to our Blocks view, we need to take care of what happens when our App starts:

We start a Bluetooth LE scan to find all BLE devices nearby. This is necessary later on when we want to connect to our LEGO device.

Then we create our list of Hubs (seen above), set the text of the Button used for the BLE connection, draw our Joystick at the center of the canvas and initialize our Clock.

This Clock will be used to keep the BLE connection active after we connect: we need to keep talking with the LEGO hub because after a pre-defined period without communication it will shutdown to prevent battery draining.

For now we just keep the clock disabled and set the period  to match the global variable “TRACKSPERIOD”.

We also define what happens when we click our ListPicker:

(we change the text to the friendly name of the chosen LEGO hub)

Now we define what happens when we click on our connection Button – we want it to connect to the device we chose whenever there is no connection yet and to disconnect when already is:

(we also activate or deactivate our Clock at the sametime)

I will not explain the blocks related to the Joystick – they are used to calculate the duty cycle (speed) of the two motors from the position of the joystick. These values are store in two global variables: ‘SpeedA’ and ‘SpeedB’.

The next important part is sending the calculated values to the motors.

The hexadecimal command used to control a WeDo 2 Motor (we should probably call it a “Powered Up Medium Motor) is:

0800810 p 115100 dt


  • ‘p’ is ‘0’ if we are using ‘Port A’ and ‘1’ if using ‘Port B’
  • dt is the hexadecimal representation of the duty cycle (a percentage value)

The AI2 BuetoothLE extension uses a list of decimal values so

8 0 129 0/1 17 81 0 dt

Lucky for us the extension also accepts signed or unsigned values so we don’t need to take care of the conversion when duty cycle is negative:

so every time the Clock reaches our “TRACKSPERIOD” value it sends the commands for the two motors. Setting a smaller period allows a better control but also increases the activity of the App so for too small periods it might not work properly. And, of course, setting a larger period will increase the latency of our control and might also cause our connection to drop.

Hope this explanation is clear enough for anyone that wants to try their own app. Feel free to make questions on my YouTube channel, I’ll try to answer the best I can.

Making an Android app for LEGO Powered Up

The new LEGO trains are now Powered Up based.

Like WeDo 2 and BOOST, this is a Bluetooth 4 Low Energy (BLE) device that uses the new type of 6-pin plug that LEGO announced a couple of years ago with the WeDo 2. At that time this new design was referenced as Power Functions 2 or PF2 but the final name is now Powered Up.

Unlike BOOST, the new smart hub included with the trains doesn’t include motors. LEGO found a way to arrange 6 AAA batteries inside it in such a compact way that the final size is exactly the same of the Power Functions LiPo or AAA batteries… with all the new electronics included:

Others like Sariel and Hispabrick already reviewed this device so I’ll just show how to to use it.

This new hub announces itself as “HUB NO.4”.  It will probably have a much better name but for now I will call it this way.

A good thing with “HUB NO.4” is that it  provides the same UUID services as BOOST. So most of the examples I wrote for BOOST work with Powered Up with just a few modifications.

For instance, the LEGO WeDo 2 motors can be used the same way as with BOOST:

gatttool -b 90:84:2B:06:AB:5D --char-write-req --handle 0x0e --value 0800810011510060

The handle (“0Eh”) is the same. The payload is also simillar, with the same 3 initial bytes (“080081”, hexadecimal) followed by a fourth byte that selects the output port (“00” = port A, “01” = port B), followed by the same 3 bytes (“115100”) and finally the last byte is the duty cycle (or speed) applied to the motor (“60h” = 100d = 100%).

Since I already had an Android app made with MIT App Inventor 2 for the  Vernie model of the BOOST set I made just a few modifications to make it work with “HUB NO.4”:

  • removed the blocks that controlled the head and cannon trigger
  • removed the blocks that sensed the colors
  • added the BT address of my “HUB NO.4” to the list of devices to pick
  • changed the motor commands used by BOOST (simultaneous control of pair A+B) by the motor commands of two WeDo 2 motors

That’s it!

This the Designer view:

and this is the Blocks view:

If you’re interested, I exported the project as an “.aia” file. It’s not polished (for instance the blocks still make references to Vernie) but you get a good base to start.

In my next article I try to explain how this App was created.

MQTT on Windows

I needed to use my Windows 10 Virtual Machine to attend a workshop where labs could only be accessed from Windows operating systems (buh-uh-uh!).

So since I’m back to Windows again, let’s see if If how I can use MQTT on it.

There are two builds of mosquitto tools for Windows: one that it’s based on cygwin and another ‘native’ built with Microsoft Visual Studio

I started with the second: mosquitto-1.4.15a-install-win32.exe

Please note that I’m using a Windows 10 (x64) virtual machine, not quite full updated and it’s July 2018… things might/will change a bit after a while.

So this is x86 (win32) build but it works on x64. It just needs 3 aditional libraries (dll’s) to work:

  • libeay32
  • ssleay32
  • pthreadVC2

The install wizard says that the first and second library can be extracted from the light install of OpenSSL for Windows. But recent versions of OpenSSL no longer use this libraries so I had to download an older one: version 1.0.2o

So I installed this build with the option to include the libraries in the local bin folder where I went to copy “libeay32.dll” and “ssleay32.dll”. Both libraries properties had “file version, product version 1.0.2o”.

I copied these 2 files to a new folder “C:\mqtt”

Then I went to POSIC Threads for WIndows project and downloaded the 2.9.1 release and extracted “Pre-built.2\dll\x86\pthreadVC2.dll” also to “C:\mqtt”. File properties had “file version, product version”.

Then I installed mosquitto 1.4.15a on the same “C:\mqtt” folder, extracting files and configuring the service. This created a Windows Service named “Mosquitto Broker” with a “MQTT v3.1 broker” description, configured as “Automatic” but not started.

From command line, changing to “C:\mqtt” and executing “mosquitto_pub.exe” gives an error stating that another library is missing (MSVCR100.dll). This is from “Microsoft Visual C++ 2010 Redistributable Package” so I installed the x86 version.

Now the same command worked and I could also start the service (“Mosquitto Broker”).

The command line argument are the same as for Linux so

mosquitto_pub.exe -h localhost -m "0" -t sfx -r

works and if I open a second command line window I can see this message arriving:

mosquitto_sub.exe -h localhost -t sfx

Nice. Now I can use LEGO MINDSTORMS, Linux, Raspberry Pi, Android, Arduino and Windows systems on my IoT projects. If someone offers me an Apple OSX device, I’ll be a true polyglIoT ! 😀

Rock Concert IoT

So last days I’ve been assembling the stage surroundings, a truss-based structure to support the left and right video walls and also the self-powered speakers:

LEGO Rock Concert: good progress with the stage and electronics

I gave up hiding the speakers under/inside the stage. I know, speakers aren’t LEGO but I think they look good enough this way.

Also I have been testing the Raspberry Pi Zero W with the PiTFT and a local USB webcam. I use ‘VLC’ to stream the webcam video to the wireless network and can show a stream on the PiTFT with ‘mplayer’. And since mosquitto-clients package is also available for Raspbian I got a way to control everything with just a bash script with MQTT.

So this is the IoT setup now:

LEGO Rock Concert: The IoT

From any mosquitto publisher I can select which stream to show on each video wall and also start a bash script on the EV3 with the sound card and the LEGO Power Function lights so a music plays while the lights blink.

Only problems till now:

  • ‘mplayer’ takes 5 seconds to start playing the stream, doesn’t seem to be a problem with the raspberry nor with the stream, just some kind of warm-up from mplayer, if I can’t fix it will have to find another video player that works with the PiTFT (it’s framebuffer, not X-based)
  • a small USB endoscope camera I was considering using has some problems to show up on first boot of the Rasberry Pi so I will probably use another webcam, bigger but more reliable

While testing the IoT I used my Ubuntu laptop (‘mosquitto-pub’ and ‘mosquitto-sub’) but found a MQTT Dashboard App that works fine both on my Android 5.0 Phone and my Android 4.0 tablet. But I also wanted to use an EV3 as a controller so I tested a few bash scripts with the local keys but found it too limited… so decided to make a better control panel:

LEGO IoT Control Panel

The four medium motors are used as selectors,  I divided a whole rotation in 8 intervals (45º each) to have 8 options on each motor. So it works like this:

– one selector for Video Wall #1

– one selector for Video Wall #2

– one selector for Sound and Lights

– one selector for Special Effects

I can choose what stream I want to show on each video wall and start playing a music. Later I will add more options (photo presentation, youtube video…) and use the 4 EV3 touch sensors to adjust parameters for each option (like the brightness, the frequency or the effect of the lights, the volume of the sound, forward/backward while showing some presentation…).

A video explaining this:

I speak in english but my voice is weak and I had an allergic caugh in the middle so I added sub-titles (also in english).

Video Wall

Xutos’ concert had several projection screens at the background so I want to have at least one small display in the background, above the drum player own stage.

Outdoors concerts sometimes have a videowall or a projection screen at each side of the stage so also want that.

First attempt of a videowall was with a NodeMCU (Arduino-like) and a small  ST7735S based 128×160 display:

It looks great for using as the right/left side displays but there’s not enough power for videos, justs static images (but the NodeMCU has enough internal memory to store a few images so some kind of presentation is possible).

The wiring is SPI so I could use just one NodeMCU to control several displays in parallel (using same Chip Select pin for all) or individually (NodeMCU has a few I/O pins).  I intend to return to this idea later on.

For a “few” more Euros I got a better display, a 2.4″ 320×240 PiTFT for the Raspberry Pi. It’s just a bit larger so it can still used as side displays.

I first tried it with a Raspberry Pi 2, installation is pretty forward:

Unfortunately the RPi is too big and to hide it with LEGO I needed a frame much bigger than the PiTFT. So I opted for a Raspberry Pi Zero W instead:

So the LEGO frame is now smaller and much lighter:

So I just need to repeat the process to have a pair of side displays for my Rock Concert stage.

For the drum player display I think this display is too small so perhaps I’ll try a 3.5″ PiTFT. I could also use a small Android tablet but then I will have problems controlling it – I don’t want to continuously stream video to the displays, I was thinking on using some kind of sensors so the public (real people) could control what to display on it, eventually also control a webcam to show different angles of the concert.

But that’s for another day.

Wireless charger for MINDSTORMS EV3

A few months ago I was discussing with Juan about his ideas for a charging station for mobile robots. He was already creating several prototypes but I remember suggesting a wireless circuit, an idea that kept bumping inside my mind until a few weeks ago when I found a very cheap (less than €2,5) Qi receiver at bangood:

Qi receivers for mobile phones supply only 5V through the USB plug but we can use a boost circuit to raise the voltage. This circuit advertises an output current of 1A, if true (we never know, do we?) doubling the voltage to 10 Volt would reduce the output current to 500 mA with an ideal boost circuit. There are no ideal circuits but at least 400 mA is expected, not great but enough to charge a LEGO robot so lets try…

The remain parts are simple:

Any breakout board is fine as long as it exposes the GND and 5V pins, I got one at a local store for less than €2

There are other models, even cheaper, but I also got this one from a local store and it works good: 2 input pins, 2 output pins and an adjustment potentiometer, that’s it!

– a power plug compatible with LEGO EV3 battery

I cannot suggest a proper plug because I’m not 100% sure of the size… I think it is a 1.7 mm jack like this from Amazon:

I simply cut a plug from a cheap wall charger I had around (not the LEGO one! :D)  so I didn’t even had to solder wires

– a couple of wires, preferably red and black

That’s it!

Assembling is very easy so I’m not even goig to draw a circuit:

  1. solder 2 wires to the microUSB breakout board +5V volt (or VBUS) and GND pins
  2. solder the other end of those 2 wires to the input pins of the boost circuit (GND to IN- and +5V/VBUS to IN+)
  3. solder other 2 wires to the output pins of the boost circuit (OUT+ and OUT-)
  4. solder the other end of thos 2 wires to the jack (OUT- to the outter metal part, OUT+ to the inner part)

Here a picture with all soldered:

Then you need a voltmeter to adjust the output voltage. Put the Qi receiver over a Qi emitter and assure it’s coupled (most of them give some kind of visual indication of the coupling state like a blue LED) and trim the potentiometer with a small screwdriver until you got 10.0 Volt (you can use higher or lower values but higher will mean less current available so more time to charge and lower might not be enough for the internal circuits of the EV3 battery to work properly).

In this video you can see the green LED of the EV3 battery blinking – that’s part because the Qi receiver wasn’t properly aligned with the Qi emitter,  part because both Qi components are low-end quality (the emitter is from a friend, it was a gift at an HP event) and finally part because the Qi emitter was being powered up from my laptop – after switching to a 3.1A wall adapter USB charger I got better performance, even a few millimeters of spacing.

Stage Lighting

So the stage size is settled, it will use 3×3 LEGO standard baseplates (32×32 studs each).

Now time to think about the lighting.

For the first version I wanted to be able to control each of the spotlights individually. To minimize wiring I decided to use a 1-wire bus (2 wires for power, 1 wire for data) and I found a 1-wire USB controller that worked very well with linux and (of course) with ev3dev.

I was very happy with the Ev3 1-wire network but not so happy with the way I wired it with my LEGO trusses. I tried to create a pluggable system that would allow me to easily extend the number of spots but never got a decent and discreet solution so I use only fixed size wires, soldered in a daisy-chain. It worked but “locked” my spotlights to the trusses permanently.

So for this new version I decided to use just one or two control channels and use common LEGO Power Function lights (well, at least for this year).

As for the trusses that support the spotlights I also decided to try non-Technic parts – I liked my previous design with only Technic parts but it was already noticeable that the spotlights were too heavy and the 32L axles were bending.

Since LEGO has a truss brick already, lets try it:

So 1 one channel is easy: each Power Functions Light assures 2 spotlights and I just need to daisy chain several of them. We can even make the lights blink with just a electro-mechanic controller like In this video:

Unfortunately it makes to0 much noise so I will have to use something purely electric.

Xutos’ 25th Anniversary concert was indoor (at ‘Pavilhão Atlântico’, currently named ‘Altisse Arena’) and the lights were suspended from the ceilling so there were no vertical trusses in front of the band. If I can’t  keep it realistic I can try a mix: keep the X-shaped stage used in that concert but use a dome truss similar to this model they used in several outdoor concerts in the last couple of years:

So I tried an arch with the LEGO trusses to see it stands hold:

Then I added the Power Functions lights but since the weight was too much I had to redesign it a bit, ending with a much larger arc:

It holds ‘per se’ but is not stable at all, tending to fall to the front or to the back. So a second or even a third arc was needed and also had to raise it a bit because when wife saw it she said the lights were too low and that would prevent people to see the stage. And since wife is always right…

This has been holding tight in our leaving room for the last 7 days (and we have 2 kids!) so I’ll might just reinforce the middle connections of the trusses that have Power Functions cable extensions.

This is already a 2-channel system so I can control half of the spotlights at any time. So it’s a proper time to finally add a MINDSTORMS EV3 to the project… and since I already got six small battery-powered active speakers I can also play a music: