Getting Started with Micro Python on ESP32

micropython.PNG

I got my little game working on the Raspberry Pi yesterday, and today I got to thinking how I could make it work on something a bit, er, cheaper. It’s not so much that I begrudge paying the price for the Pi, more that I can think of more demanding things to do with the Pi than just run the game. My thoughts turned to the ultra-cheap ESP32 devices that I’ve been playing with. The only snag is that I’ve written the entire game in Python for the Raspberry Pi, and I don’t fancy re-writing it in the C++ that these devices normally run.

So, why not run Pyhon on an ESP 32 device?

This turns out to be really easy. If you’ve installed ESP32 devices as part of your Arduino development environment you will have a useful little program called esptool.py on your machine. To convert a device to Micro Python you just have to plug in one of those ultra-cheap devices, find out what serial port it is connected to (in my case com4) and then use the command below to program the chip with Micro Python.

esptool.py --chip esp32 --port com4 --baud 460800 write_flash -z 0x1000 micropython.bin

This loads the image in the file micropython.bin into the device. To get a Python image, go to the download site and look for ESP32 devices. I used the one in the file esp32-20190714-v1.11-146-g154062d9c.bin

Above you can see what happened when I ran the command.

Above you can see what happened when I ran the command.

When you restart your ESP32 you will be able to talk Python to it via a command prompt. That’s fine, but what you really want is an IDE that lets you write and deploy Python programs.

The best one I’ve found is called Thonny. It’s works with “normal” Python nicely enough, but it also has an option you can use to point it at an embedded device:

thonnydevice.PNG

In the options menu above I’ve told Thonny to search for a device running MicroPython and connect to that. Now, when I run a program it is deployed into the device and executes from there.

The MicroPython installation provides a tiny filesystem that can hold python programs. When you run a program it is transferred into that filesystem and runs from there. There are two special program files on the device, boot.py and main.py. The program in the boot.py file is executed when the device powers up, followed by the one in main.py The Thonny program has an option (in the Device menu) to save the program you are editing one of these files. This makes it really easy to make your Python program run when the device is powered up. I made my game program the main.py one and now I have my original Python program running inside a device that only cost around a fiver.

It wasn’t quite as simple as just copying the files over. The api (application programmer interface) to use GPIO ports and Neopixels are different in the two devices and I discovered that MicroPython does not provide a random.shuffle method. This meant that I had to create my own shuffling function, which wasn’t too hard.

Anyhoo, I now have my program running in Python on a tiny embedded device. Which is rather nice. I’ll put the code up on GitHub later this week.

Making a PAX counter

PAX counter and plastic pig

PAX counter and plastic pig

PAX is an abbreviation for “passenger”. A PAX counter is a device that counts passengers, although you could use it to count people in lots of other situations too. One way to count people is to detect the devices they are carrying. I’ve built the PAX device above from the code here. It’s based on the Heltec WiFi Lora device and I’ve printed a rather neat little case for it too.

It listens to Bluetooth and WiFi. It doesn’t eavesdrop on anyone, or log data packets, it just counts the number of different device addresses that it sees and then sends the totals over LoRa to an application.

If you want to build it my strong advice is to use Visual Studio Code running under Windows 10 and with the PlatformIO framework installed. I used this and followed the instructions carefully and the program built and deployed without much fuss. I did get one warning about a missing configuration for the LMIC but this doesn’t seem to matter. The device works fine and I’ve even managed to send control commands back into the device over LoRa.

If you want to get a rough idea of passenger traffic at a particular location then I can see it being a very useful device. I’m a bit worried about privacy issues though, in that while it would be very hard to go from the MAC addresses of my devices to actually identify me directly, it would be trivial to detect that the same person has been to a particular place multiple times. This might be considered an encroachment onto privacy.

Whether or not you use the data like this is really down to self-discipline as an individual programmer, but then again they are already doing this kind of thing in shopping centres…

More Heltec Fun

heltec v2.PNG

Welcome to the blog all about the Heltec Lora 32 V2 device that occasionally mentions Rob Miles.

Last night I was feeling quite pleased with myself because I reckoned that between us we’d solved all the problems relating to our Air Quality sensor. We’d picked hardware that seems to work, a case that seems the right size and even got a power supply that looks like it will cut the mustard. We’ve even figured out how to attach the box to a lamp post.

I should know not to think things like that. In my experience it is just at this point in a project when something that has been totally reliable suddenly breaks for no reason. So it was with our Air Quality sensor. The LoRa transmission code broke. The driver locked up after only having sent one packet. Since this has never gone wrong before it was a bit of a scary head scratcher. Just before I’m due to head off to Dundee for some external examining too. Oh well.

Last night I did the very best thing that I could. I stopped thinking about the problem and walked away from it for a while. And today, that approach paid off. Coming back to it fresh I decided to look for some known good code on the Heltec site. At which point I found the following little gem:

#if defined(V1)
const lmic_pinmap lmic_pins = {
    .nss = 18,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = {26, 33, 32},
};
#elif defined(V2)
const lmic_pinmap lmic_pins = {
    .nss = 18,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = {26, 35, 34},
};
#endif

This is the code that maps the pins on the LoRa device to the driver software. And it is different for Version 2 of the Heltec device. Just in the “.dio” element. These are the numbers that map the indicator pins on the LoRa chip to the software expecting to be told things like “the last packet has been sent” or “a new packet has just arrived”. With the wrong pins assigned my driver was getting stuck waiting for messages that would never arrive. I fixed the numbers and all is now well.

These issues haven’t dimmed my enthusiasm for the device, I still think it is rather neat. However, I’m going to compile a little document that sets out all the differences I’ve discovered between the two versions of the Heltec device. For myself, if nobody else.

Heltec Lora V2 I2C Pins Fun

heltec v2.PNG

I seem to be filling the blog with items about the difference between versions 1 and 2 of an embedded controller. But then again, someone might find this useful.

Anyhoo, my shiny new Heltec devices have broken another part of my Air Quality sensor, but this time in a good way. When I was using the previous version of the device I had to use to additional pins to implement the I2C connection to the BME280 environment sensor. In the new version we can use the same I2C connections as the OLED display, i.e. pin 15 for SCL and pin 4 for SDA. This works fine as long as you initialise the OLED panel before you initialize any other I2C devices.

Using the existing I2C controller frees up a pair of precious pins. You also get the benefit of a new Heltec version 2 feature. The device has two 3.3V outputs that can be controlled via pin 21. This means that your program can switch off the power to connected devices before entering deep sleep mode. You could also use this to perform a hardware reset of any connected device by turning its power off and on again. The power pins can’t deliver a huge amount of current, but it is nice to be able to control them in this way.

ESP32 powered webcam for 7 pounds

esp32-cam.PNG

In my fingers above you can see something rather amazing. It’s an ESP32 powered webcam and it is priced at a stupidly low level. Mine arrived earlier this week and I’ve found a splendid howto that gets you started. You’ll need a serial interface to program the camera as it doesn’t have a usb connection. I used the one I got with some Arduino Pro-minis a while back. A couple of tips:

  • make sure you update to the latest version of the ESP32 board. The older camera sample will not compile.

  • the device can be a bit picky about power supplies. Mine gave “brownout” warnings for a while before I connected the 5V input to a slightly beefier supply than the 3.3V I used to program it

The camera serves up a website with a wealth of controls that you can use to change the image quality. You can use it to grab stills or watch a video stream. It even supports facial recognition and it has a micro-SD slot for saving stuff to. Amazing.

2019-04-18.png

For the price you really should get one of these and have a play. I’ve been looking for a quick way to get pictures into Azure for training image recognition. I think I may have just found it.

Crippled Hexabot

Ages ago (well, four years) I made a hexabot from a kit. Today I thought I’d get him out with a view of adding some sensors and an ESP32 to make him a bit more autonomous. He was a bit lame. Two of his servos had stopped moving. Fortunately I had some spares and so I set about getting him walking again.

It didn’t go well. I broke a replacement servo finding its mid point and fitted the second one upside down. Twice. I think that a few hours of gardening has destroyed my ability to work with electronics.

However, I think he is now back to his sprightly best. I’ve ordered a camera pan and tilt (around 3.50 with servos) and a distance sensor with pan mechanism (also around 3.50) from AliExpress. Looking forward to them arriving.

Photographing circuits

46590782695_965c886419_k.jpg

I’m writing some embedded development content and having great fun doing it. I need to take pictures of the hardware during construction. In the past I’d be reaching for a proper camera, but nowadays I use the camera on my phone. The quality is very good and a tiny phone camera has a depth of field that makes sure that everything in the picture is nice and sharp. It’s also rather nice that the pictures on the phone are sent straight up to my Onedrive camera roll where I can just pull them out and drop them into the document I’m writing.

Air Quality Fun at Leeds Sharp

Some of the audience at the start. Note my lovely Surface Go running the whole thing…

Some of the audience at the start. Note my lovely Surface Go running the whole thing…

Had a great time at the Leeds Sharp meetup tonight. I was there to talk about Air Quality, Azure Functions and Lora. With a guest appearance of my Air Quality top hat. I’m pleased to be able to report that every demo worked. Even the impromptu one that I wasn’t expecting to…If you want a look at the slide deck you can find it here.

One of the lovely things about the night was that the first two folks that I saw at the venue were a couple of Hull alumni, Joshua and Andrew . They were there to make a video of the event. So they did. It’s really good, they’ve caught the presentation content along with some shots of me prowling around looking nervous. I think I’ll hire them for all my events. They’ve put the video on YouTube, you can find it below.

Simple Bluetooth BLE between ESP32 devices

46106418305_9d9af13253_k.jpg

There are lots of things in life that are supposed to be difficult. One of them is getting Bluetooth to work between devices. However, this is now not the case. Because I can do it.

It’s not quite a simple as you might expect though, the BLE server and client examples for the ESP32 devices distribution don’t work straight out of the box (they really should) because they use different service and characteristic ids and (and this is the tricky one folks) the device name for the server is more than three characters long (which for some reason stops the client from recognising it).

Anyhoo, to make things really useful for you I’ve slightly fettled the samples and dropped them on GitHub for you to just grab and go. They make it super-easy to send messages from one ESP32 to the other.

You can find the library here: https://github.com/CrazyRobMiles/SimpleESP32BluetoothBLE

ESP32 Bluetooth BLE to Windows 10 Universal Apps

BLE Windows 10.png

So I’ve got this lovely little M5Stack device with an ESP32 processor on it and it is supposed to support Bluetooth BLE. So I thought I’d see if it did. So fired up the example Bluetooth BLE program in the Arduino SDK and then I fired up the Bluetooth sample from the Windows-Universal-Samples and tried to get them to connect.

And they just did. Astonishing. In no time at all I was sending messages from the PC to the M5Stack, and with a bit of fiddling I managed to get data values going the other way as well. I find this amazing and wonderful. Previous attempts to get Bluetooth working like this have always been fairly horrid and fraught. With this I just hit the pair button inside the app on Windows 10, accept a security prompt and then I’m sending packets of data backwards and forwards. I’m definitely going to build something based on this,

Adventures in Colour at the Connected Humber Hardware Group

40471170163_79f0259417_k.jpg

We had a great time at the Connected Humber Hardware group meetup tonight. We talked air quality, transistor design, top hats (of course) and making colours.

There’s nothing like playing with something to build your understanding of what is happening. Jay has been making remote controlled lights and has built a remote controlled a three colour led. Individual colours worked fine, but mixing them didn’t give the colours that we were expecting. This turned out to be because the individual red, green and blue light sources in the led were all very different in brightness. However after a bit of experimentation with series resistors he managed to get a reasonably balanced result, as you can see above. What’s more this serves as a lovely illustration of how primary colours can be combined to make others.

Great fun. If you want to take part (and why wouldn’t you), our next meeting is on the 3rd of April at 6:00. You can find our more about our meetups here.

BME280 Power Fun

bme280.PNG

Sometimes the old solutions are the best. In this case the solution is “Turn it off and then on again”. I’m using a BME280 temperature, pressure and humidity sensor in the air quality monitor that I’m building. It works well, except sometimes, when it refuses to say hello when it starts up.

This has caused a certain amount of head-scratching. However, after a while I worked out that it only misbehaved after I had downloaded some code into the device. It’s as if it doesn’t like being woken up twice once it has been powered up.

Now if it gets stuck I just unplug the device and plug it back in. It’s something to be born in mind when you can’t get something to work.

I have a special category in my work (particularly with hardware) called “Things you do to make it work but you don’t know why”. This is another one.

Neopixel leds and power supply fun

When you try to make hardware it sometimes turns out that every bit is the difficult bit. Like today for example. Yesterday my latest Neopixel lights arrived. They are on a strip of 8x32 pixels on a flexible pcb. It’s awesome, with power demands that I’m not that happy thinking about. The plan is to do something vaguely “Steam Punk” with them, perhaps involving my recently purchased top hat.

To celebrate I broke out my 10 amp 5 volt power supply. The one that I’ve not dared use yet. Having checked that the power supply produced a vaguely sensible voltage (around 5.5 volts) I tested the Wemos I was going to use (won’t get caught like that again) wired it all together and fired it up.This part of the project should have been the easy bit.

It didn’t work.

In a panic I disconnected the power supply, thinking that I might have wired the positive and negative wires the wrong way round (which is a good way to destroy anything). And suddenly it started working.

It turns out that this is completely normal behaviour. The problem is in the way that the NeoPixels detect their signals. They regard anything above two thirds of their power supply voltage as “true”. If the power supply is 5 volts two thirds of that is around 3.3 volts, which is exactly what the Wemos device produces on its output pins. Happy days.

However, if the power supply voltage is higher than 5 volts the voltage level needed to send a message to the NeoPixels becomes higher than the 3.3 volts that I get from the Wemos and so the communication starts to fail.

So it’s all down to my power supply being too powerful. There are two possible solutions. The first is to use a level converter to boost the signal from the Wemos to 5 volts so that the pixels will react to it. The second is to drop the power supply voltage down to 5 volts so that the maths is in my favour. Ongoing……