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.

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.

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.

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.

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.

Today I thought I’d have a proper play with the Azure IoT Devkit. There’s a ton of content out there about getting started. It’s actually quite simple to follow. In it’s simplest form you just follow the instructions here, but since the device has a proper security chip I though I’d veer off and see about using the Azure IOT device provisioning service and an X-500 certificate to create a very secure device. It’s another of the built-in examples that are provisioned when you add the Azure IoT Workbench to Visual Studio Code.

Rather pleasingly, I got it working. I’m now looking at making the device into an air quality sensor, just as soon as I can figure out how to get the serial port on the IoT board working.

There’s also an example where you can speak to the board in english and have it display the translation in a language of your choice. Great fun.

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.

Well, that was fun. It was the first proper outing for my robot army. We were all at AzureCraft in London. It was an absolutely great event, kids getting together to make things in MInecraft. And learn to program along the way.

I'd set up my Robot Arena in one of the board rooms at the fantastic venue. Over the day groups of kids and parents came to take up the challenge of controlling their robots and getting them to line up in the arena with no collisions. Harder than it looked, but everyone who came along was up for the task. Quite a few folks came back for another go, which was nice.

Great fun. Thanks to the folks at the UK Azure User Group for setting up the event and inviting me along.

I've managed to get my hands on a Surface Dial. It's a spiffy new PC control that acts like an, er, dial. You can use it to manipulate value in programs in a very precise and controlled way. The dial works best with the Surface Studio (which I've not been able to get my hands on) but you can use it on any PC which has Bluetooth. It appears as a Human Interface Device and has a really simple API that you can use to make any of your programs dial controlled.

I wanted to use it to control the movement of my Hull Pixelbot and, after only half an hour or so of coding I had it working.

It's not a particularly direct form of control just yet, but that is because of the way I'm sending control messages via the Azure Internet of Things hub, which is not really created for such rapid messaging, but it does work, which is rather nice. I made a "hotel vision" video of the program working. I'm going change the code to make a more direct connection to the robot.

Of course, what I really want is two dials on the PC, one for speed and the other for direction, but just at the moment you can't connect two Surface Dial devices to a single PC.

I like going to the C4DI developer meetups. If you are a programmer and you are based in Hull, you should go along too. You can sign up for developer and also the hardware meetups here.

Anyhoo, this month we had Martyn Coupland talking about Azure. Martyn works for Inframon as a "Senior Cloud Architect". As he said his job title I had this vision of a meeting full of serious faced engineers saying things like "And this is our new Cumulonimbus 5000, with extra fluffy light bits...". But that would be silly.

What Martyn actually does is map business process onto platforms based in the "cloud". The cloud is basically a bunch of computers on the end of a high performance network connection. It is how you turn computing into a service, rather like water or power, which you can buy based on your needs.

If you have a thing you want to do, for example host a web site, provide the back-end for an application or even run a business, the first thing you do isn't buy a big rack of computers. What you do is talk to someone like Martyn who will design you a system that lives in the cloud.

If your idea takes off big time you don't have a problem, you just crack open the champagne and turn on more cloud based processing power. If your idea sinks without trace you put the champagne back in the fridge, chalk it up to experience and work on the next project, reflecting that at least you haven't got a room full of expensive hardware to get rid of.

Martyn gave a very good rundown of how Microsoft Azure works and how good it is. I knew a bit of this from the Rather Useful Seminar by Caitlin and Peter but it was very interesting to hear how it has progressed even in this short time. Most amazing fact for me was that the majority of Azure installations don't run Windows software. I forget the figure (forgot to write it down) but there are a huge number of open source solutions sitting out there on Microsoft infrastructure. It turns out that you can build an image using your favourite operating system, whatever that is, and then deploy it into the cloud very easily.

At the end of the talk I was chatting with Martyn about Hull Pixel Bot and mentioned that I plan to make the robots all clients of an Azure based location and communication service. He reckoned that it was eminently doable, which was good to know. He'll be coming back to Hull to do some more, implementation focused, sessions later in the year. He's also an MVP, which is nice.

Caitlin and Peter, two of our students, gave a Rather Useful Seminar today all about Azure. I like it when students give seminars. There are a few good reasons for this:

students tend to know what is relevant to other students and can pitch the material accordingly

It's a great experience for the students to actually give a presentation to an audience

I don't have to do any talking, I can just sit and watch

Anyhoo, they showed us how easy it is to build a cloud based service that your program can then use, and that all this cloudy goodness is available for free via Microsoft DreamSpark.

At the end of their talk I asked for a show of hands for anyone interested in learning more, and perhaps taking part in an Azure jam session in one of our labs. Pretty much every hand in the room went up. Including mine.

So, in the next week or so we'll see about booking one of our labs for an hour or so and having a go at building a web application from scratch. Should be fun.

robmiles.com

Rob Miles is technology author and educator who spent many years as a lecturer in Computer Science at the University of Hull. He is also a Microsoft Developer Technologies MVP. He is into technology, teaching and photography. He is the author of the World Famous C# Yellow Book and almost as handsome as he thinks he is.