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.

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.

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 That helped me come up with this:

  "wifi": [
    {"ssid":"ssid", "password":"pass"},
    {"ssid":"", "password":""},
    {"ssid":"", "password":""},
    {"ssid":"", "password":""},
    {"ssid":"", "password":""}    

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

digitalWrite(GROUND_PIN, 0);

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

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

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.

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.  

Cloud Connected Camping Lights


I was in the Pound Shop over the weekend looking for camping lights. What with we me going camping in a month or so. I'm going to the Electromagnetic Field event at the end of August, and I've been buying sleeping bags and contemplating life under canvas for a few days. 

I found a likely looking light in a camping shop for a fiver but being from Yorkshire I thought I'd take a look at cheaper solutions. I found the lights above, packed in a nice little box, for a pound a pop. Astonishing value, so I bought four. 

Then I got to thinking about making the light more interesting. I've done this kind of thing before and I had some pixel rings and Wemos devices lying around, so I thought I'd have a go. Worst case I'd break a light that cost me a pound. 


This is the light dismantled. I undid the screws that held the base on popped the top off and then slid the transparent cover down and off the bottom of the light. Then I used a knife blade to pop the plastic reflector off the top to reveal the pcb that holds the 11 white leds. I'm going to replace this with a 16 led neopixel ring which just fits. You can get these rings for around 8 pounds, or much less if you're prepared to wait for them to arrive from China. 


The plan is to fit the led ring a shown above, drill some holes in the plastic support and run the wires behind through them, providing a connection and also holding the ring in position. I can bring in the hot glue later if I want to make things even more secure. 


I held the led ring in position, scratched marks on the reflector and then drilled the holes. I'm not very pleased with the bottom hole, but I don't think anyone will see it. I'm only using three of the connections, but I drilled four holes so I didn't have to remember which was the one I don't need. 


These are the wires that I made up for the connections to the led ring. I used solid core wire. I'm connecting to the ground, 5Volt and Data input lines using black, red and white wires. The colour of the wires doesn't matter much, as electricity doesn't seem to care about wire colour.

If you read the Adafruit help pages for the Neopixel ring they talk sensible things about series resistors and capacitors that you can add to improve the signal to the led ring and reduce the chances of damage. I'm leaving those out because I like to "live on the edge", but you might want to add them if you build a light like mine. 


This is the led ring after I fitted it to the reflector with the wires pushed through the appropriate holes. Looks quite tidy to me. Next up we have to take a look at fitting the processor board to the light. 


This is how the lamps are made. They have a slide switch which controls power to the led ring. It's a bit hard to see, but there's a series resistor on the positive side which is wired from the battery terminal to the switch. I'll use the switch to turn the device on and off. 

I'm going to add an ESP8266 device on the Wemos platform. I love this device and configuration, and it just fits. It will give me WiFi for connectivity and my plan is to port my wedding light software onto the Wemos platform. 


This is the device with the signal and power wires soldered in. For some reason I was nervous about soldering solid core wires onto the Wemos PCB and so I soldered in some jumper cables instead. I've done this before and it's a good trick. Rather than soldering a socket and then plugging into it (and having the worry that the plug might come out) instead I just solder the plug straight in. I'll cut the plugs off the other end and wire things up by twisting wires together, soldering them and covering with heatshrink tubing. Probably not as posh as using proper connectors, but much cheaper and at least as reliable.

I'm using one data pin to control the lights. Just because I'm moody, I decided to solder this wire in directly. I stuck the Wemos device onto the back of the reflector using some sticky velcro tape that I got from Maplin. I'm really going to miss that shop.


This is the completed processor fitted to the reflector. I've done the wiring and so I now just have to power up the device to get it going. This is also a useful stage to reach because now that I've connected the power lines for the leds and the processor together I can plug the Wemos device into the PC using a USB cable and test that the lights work. So I did this. There will now be a short break while I get the software together. 


Writing the software took longer than I expected because I found a bug. However, once I'd fixed that I turned my attention to the base of the light. I soldered some new wires to the switch and onto the battery terminals. Now I just have to connect the red and black cables to the ones on the processor and I'm good to go. 


This is the lights and the power all soldered together. I've made the wires much longer than they need to be, this is so that it will be easy to pop out the reflector and re-program the Wemos when I find another bug.


This is the light in action, just after I'd asked it to turn green.

I'm presently using MQTT to connect to the Azure IOT hub and sending text commands to configure the light. The commands are a subset of the HullOS language that I've been using on the Hull Pixelbot. Next I want to make a controller device that pushes commands up into the cloud to tell the light what to do. 

If you're looking for something to play with I can strongly recommend this light. There's a reasonable amount of space to play with - I'm thinking of adding a temperature sensor so that the light can change colour depending on how warm it is. I've discovered that I can perform my light flickering at the same time as wait for MQTT server commands and it all seems to work splendidly. I'll put the code up on GitHub when I've tidied it up a bit. 


With a bit of care you could  take the original 11 pixel ring and cut the tracks on the pcb so that each led could be controlled individually, perhaps by an Arduino Pro-Mini to get a really cheap controllable light device.