Using Serial1 with the Azure IoT Devkit

44356419010_f4bcb68f9f_z.jpg

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

heltec.PNG

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

44247228950_cdfe151736_z.jpg

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

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

45220458011_2edd510e2a_z.jpg

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

43502448734_f7e1380228_z.jpg

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. 

immylight.PNG

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

20180728_125007748_iOS.jpg

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. 

20180728_125201067_iOS.jpg

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. 

20180728_125233162_iOS.jpg

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. 

20180728_125925209_iOS.jpg

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. 

20180728_130354241_iOS.jpg

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. 

20180728_131000274_iOS.jpg

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. 

20180728_131654449_iOS.jpg

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. 

20180728_134728884_iOS.jpg

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.

20180728_140214682_iOS.jpg

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. 

20180729_153303529_iOS.jpg

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. 

20180729_154325889_iOS.jpg

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.

20180729_155119003_iOS.jpg

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. 

Make your own Theremin. Sort of.

theramin.PNG

A Theremin is a musical instrument that you control by waving your hands. It's used a lot to provide spooky sounds for science fiction and horror movies. A "proper" theremin uses a tuned circuit that is which is controlled by the player waving their hands near a couple of antennas. 

I thought we could have a go at making something similar using just a light sensor and an Arduino, so I've come up with the circuit above to get started. You can find the detailed instructions here. We've been using these little exercises at the c4di Hardware Group, which met again today and will meet again on Thursday 5th July. Sign up here if you want to come along and make some annoying noises....

Working with the Arduino at the Hardware Group

I really must take more, or at least some, pictures of the Hardware Group at c4di in action. But I'm always too busy talking about stuff to get out the camera.

Anyhoo, we had a great meetup today. We've got a bunch of new members who are just getting started, so we've put together some tiny hardware kits that they can use to get started. Like those "Build an Aston Martin in easy steps" magazines that you can buy in the new year, If you want to pick up a kit and have a go, come along to our next meetup on the 7th of June. You can sign up here

Hull Raspberry Pi Jam with robots

20180505_091359858_iOS.jpg

Well, that was great fun. Spent the morning at the Hull Raspberry Pi Jam. It was something of a "RobotFest". I had my Hull Pixelbots and Coretec Robotics were there with their balloon Raspberry Pi powered balloon busting robots. I was trialling a new idea I've had, called the "Robot Rumble". The idea is that players code up their robot warriors to get as far into their opponents area as possible. You can find the draft rules here

As it turned out we didn't get that many rumbles going, but folks had great fun making their robots do things, including some things I'd never have thought of, which was rather nice. And from the sounds of bursting balloons and cries of victory coming from the other side of the library, fun was being had there too. 

The second part of this post was going to have the title "Three Thing Game Judging Fun". But instead I'd have to use the title "I probably shouldn't have eaten that chicken from the fridge". Number one wife did ask me to check the sell by date but I was confident it was fine. And besides, I'd thrown the package away.

By 2:30 it was turning out that the chicken might not have been that fine after all. And an attempt to "kill or cure" by drinking a can full of "Old English Ginger Beer" didn't have the desired effect. Which meant I had to beat a hasty retreat from the event and head home for a lie down amongst other things. 

Fortunately the effects don't seem to have been too long lasting, which is a good thing as I'm supposed to be driving to Birmingham tomorrow. 

 

esp8266 wacky wifi

 one way to get a screenshot....

one way to get a screenshot....

This is rather weird. It all started when I got my old Nexus 7 tablet out of retirement. I'm doing some upgrades for the web server for the Raspberry Pi event coming up, and I wanted to use the Nexus to see if the web site would work on an Android powered browser. 

One of the applications on the Nexus is a WiFi analyser that I've used to pick and choose my WiFi channels. When I fired it up I noticed a few strange transmitters which were taking over the spectrum (as you can see above). 

I finally tracked this down to the esp8266 devices that I use in Hull Pixelbots. For some reason, when they wake up, they start doing things on WiFi channels. I've no idea of the precise meaning of this transmission, but I don't particularly like it. It turns out that if you turn off the WiFi before you do anything else (even turn it back on to connect to an access point) then you don't see this. 

I'd love comments from anyone else who've seen this, or has more knowledge of what is going on. In the meantime all my programs now start with:

WiFi.mode(WIFI_OFF);

Arduino Retro Computer

Derek put me onto this. It's a retro computer made from two Arduino devices, one of which generates VGA output. Many years ago I discovered that people were using PIC devices to produce video output, this does something similar with an Arduino to generate VGA video. It uses a tiny interpreted basic that is not a million miles away from my HullOS software, although the Basic implementation uses a lot more gotos....

"In-band" error signalling is dangerous

38848188484_28844cceab_z.jpg

I've been working on the Hull Pixelbot for what seems like ages (You probably think I've been blogging about it for roughly as long. Don't care. My blog.)

Anyhoo, today I learned the perils of "in band error signalling". The phrase "In-band" is a radio term. It means that control information is sent in the came channel as the data. My "in-band" errors worked like this:

int findVariablePos (char * name)
{
    int result;
     /* Stuff happens in here to find the variable  */
    return result; // return the offset of the variable */
}

The function findVariablePos returns the offset into the variable name table of the variable with the given name. In a program a variable is a named location that you can use to store data that is used as the program runs. If my program does this:

i = 99

- this is an attempt to store 99 in a variable called 'i' for no readily apparent reason. The thing running the program needs to have a way of finding out where in the computer the variable i is actually stored. That's the job of findVariablePos. Deep inside the program that actually runs the Hull Pixelbot script there is a statement like this:

int iPos = findVariablePos ("i")

The statement above (we're writing C by the way) would get me the position in the variable table of the variable with the name 'i'. "Aha", you say. "What if the program doesn't contain a variable called 'i'. ". Well, in that case the findVariablePos function returns the value -1 to indicate that the name was not found. This is kind of sensible, because you can't have anything at the position -1 in a table, negative numbers are meaningless in this context. All good. To make things clearer I even did this:

#define VARIABLE_NOT_FOUND -1

This gives meaning to the value, so that I can write tests that make sense:

if (iPOS==VARIABLE_NOT_FOUND)
{
    Serial.println("Variable not found");
}

All good. Works fine. Then I re-factor the code and add a bunch of new error codes. I then decide it would be nice to have a set of numbers that the user (and other programs) can use to make sense of error messages. And I make the following change:

#define VARIABLE_NOT_FOUND 2

This makes sense in the context of fiddling with my error numbers, but it means that if the program ever puts a variable in location 2 in the variable table, the program will completely fail to find it because every time it gets the offset value this will be regarded as meaning that no variable was found. 

Which is of course what happened. The problem in caused by a bad design decision (using the data value as a means of signalling errors) and then doing something without considering the consequences. The latest version of findVariablePos looks like this:

int findVariablePos (char * name, int * position)
{
    int result;
     /* Stuff happens in here to find the variable  */
    
    *position = result;
    return FOUND_OK;
}

The result of the call is returned via one channel (the result of function) and the position value is returned by the method setting the value of the second parameter, which is a pointer to the variable. The call is a bit more complicated:

int iPos;
if (findVariablePos ("i",  &iPos) == FOUND_OK)
{
    Serial.println("Found the variable");
}

However, it now doesn't matter what the error numbers are, and whether or not they clash with any valid variable positions. 

"In-band" error handling is great if your'e in a hurry and you're trying to keep the code simple and quick. But they also leave you open to problems further down the tracks. 

World's Smallest Arduino compatible board at c4di Hardware Group

atomx1.PNG

Did you know that the worlds smallest Arduino compatible device is made in Hull? I didn't until Hayden turned up with one at the hardware group at c4di tonight. He's designed and built a lovely little device. I've played with tiny Arduinos before. They are usually a bit hard to connect to a computer because they lack a proper usb connection and are a bit under-powered when you get them going. 

The device that Hayden has made gives you serious computing power in a device you can hang off any micro-usb cable and program using the standard Arduino SDK. It puts a 48 Mhz  device with 256K of ROM and 32K of RAM onto your fingernail. You can find out more (and buy one for yourself) here. We had it flashing a led, which is probably not really the best use of its power, but it is a start....

It was a great meetup. We had some new folks turn up keen to learn, and some who had brought things to talk about. You can sign up for the next one on Thursday 7th December (and you should) here.

Arduino vs One Drive

Some things you just have to learn the hard way. For a while I've been frustrated by the way that my Arduino projects would build fine for a while, and then fail after I had saved them. 

Eventually I worked out that if you're working on a folder which is being shared by One Drive (or DropBox and probably Google Drive) this causes the Adruino SDK to get upset when it tries to build a solution. This must be due to the file sync process causing files to be locked when they shouldn't be.  Move the files to your desktop and the program builds perfectly. 

Of course, the proper way to share a development project between a bunch of machines is to use GitHub, and that's what I'll be doing in the future....

Buy this Arduino Book

If you're looking for a book about the Arduino that is stunning value for money, just head out to your local newsagents and track down a copy of the latest Teach In from Everyday and Practical Electronics (or EPE). It provides an excellent introduction to the Arduino device and then, as a bonus, adds a bunch of chapters about PIC development and some other good stuff.

Like all of the EPE publications, this is well written, technically accurate and laid out in an easy to read manner. And you even get a CD-ROM with lots of useful stuff on it too. 

Full Disclosure: Many years ago I helped Ian and Tony to write a Teach-In for the magazine. It's nice to see that Ian is still writing for them, there's a lovely piece from him about state machines in the back of this very publication. 

A must-buy in my opinion.

HullPixelbot Code takes shape

Building on the work yesterday, I've now made a little code editor that can be used to control the HullPixelbot motor controller. You can load and save programs and send them via a serial port into an Arduino. The programs are stored in EEPROM inside the device, so that they run when the robot starts up. Next step is to distribute the programs over MQTT using the esp8266. Then I'll be a lot closer to my dream of autonomous robots that I can easily reprogram.

The program above starts a movement and then tests a conditional branch behaviour that fires when the motor stops running. You can use this to write code that starts the robot moving and then responds to events.

The nice thing about the programs so far is that they are very frugal. I've got everything running on a single Arduino Pro-Mini and it seems to work OK at the moment.