ESP32 Bluetooth BLE to Windows 10 Universal Apps

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,

Building an Air Quality Sensor

After some fun and games with a drill I now have an air quality sensor mounted in my lamp. Next step is to connect the sensor and the processor board, add the temperature sensor and then stick it on the wall outside my house. Exciting times.

Adventures in Colour at the Connected Humber Hardware Group

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.

Red Nose Day Presentation Video Now Live

This is the Red Nose Day presentation in super-duper widescreen and high resolution and also starring a bucket of money. Which has all the best lines. Watch out for the bit where the cameraman falls asleep.

Air Quality Top Hat Video Live

The video shows my Air Quality Hat in action. (still time to donate at https://www.justgiving.com/fundraising/lecture-in-rhyme )

Hardware Group on Thursday

If you’re in Hull, and you’re into Hardware, don’t forget that we’re having another Hardware Group Meetup this Thursday (the 7th of March). We’ll be talking about air quality, embedded devices, LoRa and top hats.

Among other things.

You can find out more here and sign up for notification of future events here.

BME280 Power Fun

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.

Working Lights

Well, the lights have stayed up for another day. I think they’ve reached “Peak Sag”. I’m rather pleased with how well they work. It’s basically a one dimensional particle system with particles that change size and position. I’ll post the code on GitHub at some point.

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……

Storing Json Configuration Information in devices

I’m a big fan of Json. It is a great way of expressing values in a meaningful way. I’m going to use it to store settings information in our Air Quality sensors. This will make it easy to understand, and extensible. It turns out that it is also very easy to do. I started with an online json editor at https://jsoneditoronline.org/ That helped me come up with this:

{
  "ver":1,
  "wifi": [
    {"ssid":"ssid", "password":"pass"},
    {"ssid":"", "password":""},
    {"ssid":"", "password":""},
    {"ssid":"", "password":""},
    {"ssid":"", "password":""}    
    ],
  "mqtt":{
    "mqttID":"robert01",
    "mqttHost":"mqtt.connectedhumber.org",
    "mqttUser":"connectedHumber",
    "mqttPassword":"pass",
    "mqttPublish":"airquality/data",
    "mqttSubscribe":"airquality/commands",
    "mqttIntervalSecs":60,
    "mqttRetrySecs":20
  },
  "node":{
    "nodeID":"sensor01",
    "noOfPixels":12,
    "pixelColour":{"r":0,"g":255,"b":0},
    "airqSensorType":1,
    "airQLowLimit":1,
    "airqLowWarnLimit":2,
      "airqMidWarnLimit":3,
      "airqHighWarnLimit":4,
      "airQHighAlertLimit":5
  }
}

The json design provides all the information that a sensor needs, including the WiFi settings for 5 different networks. MQTT connection settings and the limits for my warning displays on the coloured pixel.

Next, I needed the C++ to convert the Json into settings that my code inside the device can use to load and store the values when the device runs. It turns out that the Arduino json library has an awesome web page where you can just paste your json and out drops C++ to read and write the values.

I just went to https://arduinojson.org/v5/assistant/ , dropped my Json design into the pate and out came the code. I’ve got to map the settings values onto the variables I’m using in the program, but that is much easier than writing everything from scratch.

This won’t work with the very small Arduino devices because they haven’t really got enough memory to run such large libraries. However, if you’re using an esp8266 or esp32 this really is an easy way to manage internal settings. I’m going to store the json itself using the internal filestore. I’ll post how to do this in a little while.

Porchlight 2.0

Well, Porchlight 1.0 fell down sometime last night. But no damage done. I’ve switched to a stronger type of adhesive strip and also wedged the light strip into place. I’ve also made an internal version of the lights so that I can test my displays without having to deploy them on the front of the house, which seems like a good idea to me. Now that I’m a bit happier with the power supply I’ve changed to a version of the code that turns on a lot more lights at once, for extra brightness.

Christmas Lights Taking Shape

Every year I have a plan to make some Christmas lights using Neopixel leds. This year I’ve actually got as far as buying he leds and a power supply unit. Today I spent a happy half hour wiring everything together and a less happy half hour finding out that if you put a series resistor in the data line to the leds (as you are advised to on the web) they don’t work reliably.

Today’s hard won lesson: it’s not always your software that’s at fault. Sometimes the hardware can go wrong too. Once I’ve got the lights working I’ll post a video on here and the code on GitHub. It’s turning out to be quite fun.

Using Serial1 with the Azure IoT Devkit

A while back I posted about changes you could make to the Azure IoT DevKit library so that your programs can use the second serial port of the device to talk to things like GPS receivers and Air Quality sensors (a particular interest of mine).

At the time I suggested that this could be fixed by adding the creation of a second serial port to the SDK. I’ve just heard back from the team and this is not going to be done. Instead we can create a Serial instance when we need one, which saves resources.

If you want to use Serial1 with your Azure IoT device you can add the following statement to your program.

UARTClass Serial1(UART_1);

You can then use Serial1 in exactly the same way as you use Serial. I’ve put a sample program on GitHub that shows how this works.

Heltec Lora 32 on Fritzing

I spent a big chunk of yesterday trying to create a Heltec Lora 32 part for the Fritzing design program. In the process I learned quite a bit about SVG files, Inkscape and pcb design. So I don’t think it was a complete waste of time….

Tomorrow I’m going to try and figure out how to add my newly created part to the Fritzing parts library. Then I’m going to make Fritzing parts for the sensors that I’m using and then I can draw some lovely circuit diagrams.

Making a Do it Yourself Ground Pin

When I’m making embedded devices, I find that ground pins are a bit like liquorice allsorts. I just can’t get enough of them. The ground pin is the one that provides an electrical ground connection. You need a ground connection for the power for every device you want to add to your circuit, and also for every data signal. If you want to provide a push button for your user to press, yes, that needs a ground connection along with the connection to the input pin that is going to read it.

The Arduino has a few ground pins in amongst its selection of inputs and outputs. The Wemos D1 Mini that I like to use only has one ground pin. It’s really annoying when you’ve got lots of spare input and output pins on your device, but you’ve run out of ground pins. It’s a bit like “water water everywhere, but not a drop to drink…”

Anyhoo, there is a piece of programming magic that you can use to convert any digital output pin into a ground pin. Actually it’s not that magical. You just have to set one of your digital pins to be an output pin and set the level to 0. Hey presto. Instant ground pin.

You can’t really use such a pin for power connections, but you can use it for data connections. I’ve just used it on my MQTT Mini air quality device. It needs some form of input and I’m determined to avoid putting buttons on it. So I’ve added a tilt sensor. This the software to react when the user turns the sensor upside down.

The tilt sensor works like a switch. One way up a small metal ball rests on two pins, providing an electrical connection. Tip the sensor the other way up and the ball falls down away from the pins, breaking the connection. I wanted to add it to my Wemos device and, of course, I had no ground pins left. So I used a data pin instead. This is the code that makes the switch work:

#define GROUND_PIN 5
#define INPUT_PIN 4

pinMode(GROUND_PIN, OUTPUT);
digitalWrite(GROUND_PIN, 0);
pinMode(INPUT_PIN, INPUT_PULLUP);

I’m using data pins 4 and 5. Pin 5 is my “do it yourself ground”. Pin 4 is my input pin. The tilt switch is wired across these two pins. Pin 5 is configured as an output pin and set to the low (ground) level. Pin 4 is configured as an input pin with a “pull-up” resistor which means that when nothing is connected to the pin the data signal on the pin is pulled into the high state. When the switch closes, this pulls the voltage on pin 4 down to the level of pin 5 (ground) causing the input that the program sees to change from 1 to 0. My code to test the pin looks like this:

if (digitalRead(INPUT_PIN))
{
// device is upright
}
else
{
// device is upside down
}

It works a treat. So, if you need a ground line for data and you’ve no ground connections - but you have some spare signals - just make a ground of your own.

PCB Design at the Connected Humber Hardware Group Meetup

Thanks to Robin for the picture

We had another great session at the Connected Humber Hardware Group tonight. Paul was telling us how to design our own printed circuit boards and get them made up. This is now so cheap that every electronics hobbyist should be getting their own custom boards made up. It turns out that it is all a matter of workflow, in that the sequence in which you put the design together is the important part. Unfortunately I was helping out with a recalcitrant LCD panel during this bit, so I’ll have to ask the other members to help me along when I start making my own circuits.

I want to make at least four, one for the fully featured Air Quality sensor, one for the “Mini MQTT” sensor, another for the Hull Pixelbot dual brain version and a final one as a badge which I think will look cool.

We’ll be continuing our exploration of PCB design at later meetups. They are free to attend, great fun, and take place on the first and third Thursday of each month at c4di in Hull. You can just turn up on the day (as a bunch of people did tonight) but you can also sign up for notification of upcoming events here.

Using Three Serial Ports with the Heltec LoRa 32

Prototype and “floral” version

I’m making pretty good progress with the Air Quality sensor. I’ve now got a command protocol running between the devices and MQTT or LoRa. As you can see above, I now have the ability to customise the splash screen. Which is very useful if you like cheese.

Anyhoo, I’ve decided that the sensor really needs GPS so that each air quality reading can be tagged with location. I can configure fixed latitude and longitude values into the device, but for real portable usefulness we need it to be location aware.

Getting a GPS device wasn’t a problem, I had one lying around. But connecting it to the Heltec processor that I’m using was more tricky. I’ve got one serial port I want to use as a connection to the host computer and another that I’m using to connect to dust particle sensor. But now I need a third connection for the GPS receiver.

After some rather unsuccessful fiddling with different kinds of software serial connections I decided that it was best to go back to first principles and see if the hardware had anything to offer.

It turns out that it does. The ESP32 chip that the Heletc uses actually contains three serial ports. The problem is that they are not always connected to pins that you can access easily. But the good news is that the ESP32 chip is capable of mapping functions to pretty much any pin and the Heltec libraries take advantage of this. You can map the transmit and receive functions of a serial port when you open it:

HardwareSerial GPS_Serial(2);
GPS_Serial.begin(9600, SERIAL_8N1, 13, -1);

The first statement creates a hardware serial port. The second sets it to receive from pin 13. I don’t really want to transmit anything to my GPS device at the moment (I’m a bit short of spare pins to be honest) and so I’ve set the TX pin to number -1 which means “Don’t use this port for transmit”.

It works a treat. And thanks to this fantastic library I’m now tagging sensor readings with location. The next thing to do is re-design the case to take the GPS sensor and print another flower for the top.

Visual Studio Code is growing on me

You learn something new every day. Today I learned that if you don’t enable the C++ extension in Visual Studio Code you can’t use any of the Arduino extension commands.

Visual Studio Code is really growing on me. It’s like a software Swiss Army knife. It wraps around your code development and there are some awesome plugins. Including an amazing one for working with MarkDown (Markdown All in One). And the GitHub integration is lovely useful.

Silly Temperatures

Chris was commenting on how warm my house is, based on the readings being transmitted by my air quality sensor. Turns out that putting the temperature sensor in a box with things that generate heat (the processor and the air quality sensor) means that you get readings that are not very sensible.

Time for a redesign methinks.

Making a lightbox

Yesterday I had a bit of a cold. Today I seem to have got all of it. So I feel rubbish; what better time to do something silly. I've decided to make a letter light for number one grandchild. See if you can use your skill and judgement to work out her name from the above picture. 

I found a really nice design on Thingiverse for letter boxes, but I would have had to stick them all together and make a box to put them in and so on and so on. No fun. So I've written a little Python program that runs inside FreeCad to grab the STL designs, convert them into FreeCad shapes, stick them all together, create a backplane for the light box and then a plinth to put them in. I've even added a hole for the power socket and wall mounting holes. 

I've discovered that I can just handle a six letter word if I print diagonally on Una my Ultimaker original - still doing a sterling job after six years. The light boxes are 30mm in size and a perfect fit for some waterproof neopixels that I had lying around. 

I'm printing out the bits and fitting them together at the moment. I'm going to make a modification that lets you make a box with multiple lines and then when it's all working well I'll put the code up on GitHub.