Making bendy pipes with FreeCAD


Achievement unlocked. I now know how to make “bendy” things in FreeCAD. It’s actually not that hard once you work out what FreeCAD needs to know. Essentially you use one Sketch to define the path of the template and another (which should be at right angles to the path) to define the closed shape to be created. You can even add another closed shape at the end of the path and then have the shape smoothly change from one to the other. I’ve used this to create tapered tubes.

I’m doing this to make another Air Quality sensor. I want to send the air path round a curve that is too tight for pipe. I also want to add a “u-bend” so that it is harder for water to get into the sensor. I’m quite pleased with the above. Now I just have to figure out how to mount it in the case….

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.

Air Quality, Lora and Azure Functions at Leeds

I’m treading the boards again on Thursday evening this week in Leeds. I’m talking about our work with Air Quality sensors and whatnot. With a special guest appearance of the Air Quality Top hat. Should be fun.

If you live in Leeds you can register here. If you don’t live in Leeds you can still travel there and attend if you wish, but I’d probably draw the line at intercontinental flights to get there…..

Please note that, in a break with recent tradition, this session will not be rhyme. (unless they offer me money)

Laser Cutting at Hull Makerspace


I really like it when I head out of the house with the intention of achieving something and then actually manage to complete the task. Today I headed down to the wonderful Hull Makerspace with the intention of completing my air quality sensor mount design and maybe even cutting it out of perspex.

And that’s exactly what I did.

Fair enough, some of the holes are in the wrong places and some are completely missing. But a little drill work and my first prototype is now ready to be fitted.


The holder has our custom circuit board on one side and the SDS011 sensor on the other.

Making an Air Quality Top Hat


This how I made my Air Quality Top Hat. It’s actually more of an Air Quality belt really, in that the sensors and the lights are attached to a strip of webbing which can then be fitted around the hat. I’ve made it slightly too long, so that it can also be turned into an Air Quality belt if you prefer.

Click on the image for a large version on Flickr

Click on the image for a large version on Flickr

I’m using a Wemos D1 Mini and a Winsen ZPH01 particle sensor. The sensor will detect 2.5 micron particles but it’s not super stable (mind you - it is very cheap). For the light display I’ve added a strip of NeoPixels.


The wiring is just point to point, with some wires twisted together, soldered and then covered with heat shrink cable. The ground line is connected to the grounds on the pixel strip, the Wenos, the ZPH01 ground and the ZPH01 control line to pull that line low and request that the sensor sends serial data out of the TX line. The 5V line from the WEMOS is connected to V+ on the ZPH01 and the V+ of the NeoPixels.

The data line of the NeoPixels is connected to D4 on the WEMOS which is actually GPIO2. I’m using a lovely pixel library from Makuna which uses the onboard UART on the ESP8266 to drive the pixels. This forces them to be connected to GPIO2.

I’m using a specially hand tampered SoftwareSeral driver to get the sensor data, which is read on GPIO12 which is exposed as D6 on the WEMOS device.

The device is powered by a short usb cable that I’ve plugged into the WEMOS and then taped in place. I can use a USB extension lead to program the Wemos and plug it directly into a usb power bank to power the whole thing.


Rather than find a plug and wire up a cable, I’ve actually soldered the wires directly to the back of the sensor. I’m not proud of this, but it does seem to work. The Air Quality sensor and the Wemos are secured to the belt by double sided adhesive foam.

The software I’m using is an early release of my Monitair software for Air Quality sensors. You can find the “Top Hat” version on GitHub here.

Amazing facts to impress your friends....

If you want to really impress someone just tell them this:

“If you want to use MQTT with PubSubClient and talk to an Azure IoT Hub over secure sockets you should use Version 2.4.2 of the LOLIN Wemos framework or your program will crash when it runs out of memory during socket open.”

Then again, it might just be me that would be impressed by this.

Connected Humber MonitAIR Circuit Board


There comes a point in a project where things start to look real. I think we’ve hit that in our Air Quality monitoring project. At the Connected Humber hardware group this evening Brian gave out some populated versions of the sensor circuit board he’s designed and had made. Rather than making all the individual connections by hand we now have a beautiful little board that takes our processor, some power supply and switching circuitry and sensor connections.

It’s very pretty. The next step is to marry it up with our housing designs and start putting sensors into the hands of our waiting test users.

Exciting times.

Sensor Base Design the Hard Way


If I ever join you climbing a mountain, I’ll probably be the one wearing roller skates and carrying a piano.

Sometimes it seems to me that I have a stubborn determination to do things the hard way. For example, today’s task was to create some designs for an outdoor air quality sensor. I wanted a circular fitting to go in the base of a pipe and a support that would attach to the fitting and hold the processor and air quality sensor.

Some people (I think I call these people the “sensible ones”) would reach for their CAD tool and begin designing. Not me though. I reached for my Python interpeter and the ezdxf library that lets you write Autocad files from your code.

I wanted to use the “nut holder” approach to fitting where the laser cut plastic (which is what I want to make the stand out of) holds nuts that a bolt engages with to grip it. I’ve used these on the Hull Pixelbot quite successfully. I was quite proud of the “nut holder generator” that I’d written for the Pixelbot, it even makes each change of direction into a tiny curve, which apparently reduces the chances of the plastic cracking after it has been cut. However, my original code only drew the holders in one direction, whereas for the holder I wanted to put them all around the edges of a circle, as shown above.

Cue lots of bits of paper covered in drawings of triangles, sines and cosines and cursing over code. Eventually I managed it though, and the next step will be to get the plans cut into plastic so that we can make some sensors.

Building the Monitair Configuration Interface


I’ve got the web based configuration for the Monitair working quite well now, but it is a bit of a faff to use. You have to connect to the WiFi access point served by the Monitair device and then navigate to the web page it is hosting.

If you have got the device connected to your PC, perhaps to download the software, it would be nice if you could configure the settings via the serial interface. Well, you can now. I’m using the same data source as is used to generate the web page, and I’ve added some useful commands as well. Now you can set any of the values in a device straight after programming it, which is rather nice.

Building the Monitair Configuration Page


The new configuration web page for the Monitair sensor is taking shape. Above you can see the “home page” that the sensor displays during setup. Rather than having one enormous page of settings we now have links to sub-pages which contain different setting categories. The page is generated from a data structure so that it is very easy to add new settings.


These are the simple settings for the device. You can leave everything else at the default values and the sensor will just work on the Connected Humber MQTT broker. The only things you really need are WiFi connection details and the MQTT password. If you happen to know your location details you can put them into the form so that the sensor readings can be displayed on the map. When you click Update the settings are written into EEPROM on the device. You can use the advanced configuration pages to select things like the hardware pins that various peripheral devices are connected to. I’m rather enjoying writing this…

Cottingham Parish Council

After an awesome hardware meetup at c4di tonight Robin and I went on to a meeting of Cottingham Parish Council. We were there to talk about Air Quality, something we are quite passionate about - what with us having done quite a lot of breathing over the years.

As it happened they were discussing an air quality issue just before we were introduced, which gave us a lovely context in which to describe the work of the Connected Humber Group on designing, making and deploying sensors around the area.

Everyone was very interested and I it looks like we’ll be working together in the future on this, which is lovely.

Air Quality on the radio

The coloured fountains in Hull city centre look lovely.

The coloured fountains in Hull city centre look lovely.

Every now and then I get to do the newspaper review for the Radio Humberside breakfast show. It means getting up at stupid o’clock in the morning but it is rather fun. We talked about a bunch of things, including Air Quality, which was actually in the news today. Apparently the air in London Underground tunnels contains dangerously high levels of particulates (just the things we are measuring with the sensors that we are building at Connected Humber). According to the standards that we’ve been using, things get unhealthy when an indicator value we are measuring goes above 60 or so. The values they are seeing in the deepest stations are around 450….

The bit that took my breath away (really) was that someone actually said something like “Although the levels are high, it doesn’t matter because people don’t spend a lot of time on the tube”. Unless, of course you happen to drive a train or work in the station…..

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.

Creating a WiFi Configuration Tool


One of the problems with any WiFi enabled device is the initial configuration. How do you tell your device the settings for your WiFi when you can’t talk to it via WiFi? It’s a “chicken and egg” situation, even though it doesn’t involve any chickens or eggs.

One answer is to make your device set up as a WiFi access point of its own, and then connect to this from a WiFi enabled phone or computer to configure all the settings. There are quite a few libraries of routines out there that will help you do this, but none of them did exactly what I wanted, so I’ve built my own.

You can see the configuration screen it generates in the screenshot above. You connect to it via your browser and then fill in the various options. It has support for five different access points and also lets you configure all the MQTT settings for a sensor as well.

I’ve got it working with my MQTT Mini Air Quality sensor. To configure the WiFi you simply turn the sensor upside down, plug it in and it starts up in “configure” mode. You then connect to the access point and perform the configuration. Then flip the sensor the right way up, restart it and away you go.

I’m very pleased with how well it works. I’ll have the code for the new, super configurable MQTT Mini device on GitHub before the end of the week. Then I’ll port the configuration mechanism over to larger, ESP32 based sensor.

Great fun.

Using the Second Serial Port on the Azure IoT Devkit

For some time I’ve been trying to create an Air Quality Sensor using the Azure IoT Developer Kit. It’s a nice little device that has a bunch of environmental sensors, a nice OLED screen and a couple of buttons. It is also properly secure, in that it contains secure storage and you can validate access using X500 certificates.

I like it a lot, but I’ve not been able to use it for air quality work as I couldn’t get the second serial port to work on it. This is important because the air quality sensors that we are using deliver their readings over a serial connection. I’ve tried doing what the documentation says to do but it just didn’t work.

I posted a question about this on the GitHub repository for the kit and got a response indicating that what I was doing should just work.

But it didn’t.

So I had a proper look in the code in the device SDK. After a bit of digging I discovered that two of the source files are missing statements that make the second serial port available to Arduino programs. The file Variant.cpp needs the statement:

UARTClass Serial1(UART_1);

..and the file Variant.h needs the statement:

extern UARTClass Serial1;

Then it does work. I’ve tested it and everything. The picture above shows my cunning test rig, using a USB to serial adaptor that I wired to the devkit. If you’re connecting the device using a MicroBit connector you will find that pin 1 is TXD and pin 2 is RXD.

I’ve put the changes into a fork of the devkit sdk that you can find here. I’ve also told the developer team about my fix, so that it should appear in the “proper” version soon. I’m very pleased to be able to contribute a tiny bit to the development of the device. I feel like a grown up programmer…..

The only problem I have left to solve is that my Air Quality sensor needs a 5 volt power supply. While the USB connector on the Developer Kit board receives this from the host device the power connection is not surfaced anywhere on the board. I can see why this is: you wouldn’t want people inadvertently sending 5 volt signals into the input pins, but it means that my wiring is going to have to be a bit more complicated than it might be.

Anyhoo, I can now start porting my Air Quality Sensor code into the Devkit, which is nice. I’m also going to make a little box for it too.

Air Quality Designs and Software now on GitHub


If you woke up with an urge to create an Air Quality sensor out of either a Heltec or a Wemo device then I’ve got good news for you. You can download all my software and hardware designs from here. You can make sensors that use LoRa in OTAA or APB (these will make sense if you know LoRa or go to my talk later this month). You can also use MQTT to talk to Azure IOT Hub or another MQTT broker including Mosquitto.

All configuration is performed using JSON messages that can be sent via the serial port or over the air. It is very easy to configure a device, no need to re-burn the software each time you want to deploy another sensor with a different name and network configuration.

I call this a “shirk in progress” release, in that I’ve been too lazy to release any new versions for a while. However, I'm now using this as my main development repository and so you can expect updates, including more detailed documentation, over time.

Using an Azure Function to receive MQTT Messages

The video shows me pressing a button on my Air Quality sensor to trigger the sensor to send a new reading via MQTT. The action then switches to the output of an Azure Function running on my PC which is responding to this. I’m very pleased with this.

MQTT (Message Queuing Telemetry Transport) is a neat way to connect embedded devices together. I’ve used it to talk to the Hull Pixelbot devices over the internet using Azure IOT Hub. Using MQTT in this way has meant that my server applications can send commands to the robots to tell them what to do, and also receive messages back.

Creating a server application is all very well, but it is a bit too much like hard work for me when I’m writing code for the Air Quality sensors. In that situation I don’t really want to have a server application sitting in the cloud twiddling its digital thumbs while it is waiting for incoming messages.

What I really want is a way of connecting a lump of code (ideally a C# method) to the event “Hey out there. I’ve got a new Air Quality Reading”. It turns out that Azure Functions just do this. You deploy the function into the cloud and bind it to the Azure IOT Hub and the endpoint that you want it to listen to. And then, whenever your remote node (which could be anywhere in the world) wants to send a message it posts an MQTT update and your function runs.

This is my function at the moment:

public static void Run([IoTHubTrigger("devices/#",
Connection = "IoTHubConnectionString")]EventData message, ILogger log)
$"C# IoT Hub message: {Encoding.UTF8.GetString(message.Body.Array)}"

I stole most of how to do this from a very useful howto here. The next thing to do is add some code to the function that puts the data values from the post into a data store and perhaps add handling of alerts if we see air quality values which are out of range.

The next thing to do is build a similar mechanism to process LoRa updates sent via the things network.