Using TTN Mapper to show LoRa coverage

heatmapblog.PNG

I’ve been playing with TTN Mapper. It’s great. There’s an app you can get for your phone (Android or IoS). You configure it with the details of your Things Network application and then you can wander round with a portable LoRa device and help to build a map of coverage.

You don’t have to actually connect your LoRa device to your phone, you just have to enable the mapper program on your phone to connect to your application and then it will detect LoRa packets from the device in that application and use the gateway metadata to help build the coverage map.

I’ve configured one of my Pax counter devices so that I can use it for mapping. Note that you need to be careful to put the sensor name in exactly as it is configured in the application. My iphone keyboard “helpfully” converted one of the characters in the device name to upper case and broke the mapping.

Some of the strings you have to enter are quite long. I opened up the Things Network site on my phone and then copied them out of the browser into the setup page of the application.

You can use a wildcard for the device name but this might get confusing if the mapper starts thinking that messages from distant sensors are actually with you and your iphone. But this would be a good way to work if you make a network with a single LoRa device that you are going to use just for mapping.

I’m going to try and get into the habit of taking the phone and a LoRa device with me whenever I go for a walk.

Server Discussions at c4di

c4diserver.PNG

We had a quiet, but useful, hardware meetup today at c4di. Although most of the talk was of servers and software.

We’re in the process of migrating our services onto a shiny new Azure platform (if virtual machines can ever be regarded as shiny). As of today we’ve got the bulk of the work done. This means that you can go to our map and see something useful. We made some changes to the configuration live at the meeting which was great fun. I also insisted that we turn off the server and then turn it back on again, so that we could make sure that there are no manually started services that we need that would cause things to break if we ever had a reset. I’m pleased to be able to report that the server passed with flying colours.

Next we have to move our web sites and a couple of other services and then we’ll back in business. Huge thanks to everyone, particularly Starbeamrainbowlabs and Brian, for making the move.

Starbeamrainbowlabs has written some neat blog posts on the migration process that you can read here.

Lamppost Sensors Live

data.JPG

Well, this is rather exciting. The air quality sensors that we handed over to Hull City council to be attached to lamp posts and measure air quality are now attached to lamp posts and are measuring air quality.

We didn’t expect them to show up on the network just yet, but thanks to one plucky LoRa gateway in the middle of Hull, three of the four sensors are getting readings into the servers.

The next step is to get the data onto our interactive map so that everyone can see what it looks like.

Byte ordering is a thing....

48177980026_ebc8ea2177_z.jpg

I’m upgrading the Air Quality sensor software so that I can send configuration messages over LoRa to the sensor. The thing I’m most interested in is the ability to tell the sensor the rate at which it should send readings. It would be useful to have a message sent every five minutes or so for testing, and then dial back the rate once the sensor has been installed. I’m using a tiny packet format to do this. The packet is three bytes long:

01 58 02

The first byte is the command number (there is only one command at the moment). The other two bytes are the number of seconds the sensor should wait between sending each reading. The value I want to send won’t fit into a single byte (a byte can represent an unsigned integer up to the value 255 and I want to have intervals longer than 255 seconds) so I’m using two bytes. The first byte is the “low” byte of the value I’m sending and the second byte is the “high” byte. In the tiny sample above the low byte is HEX 58 and the high byte is 2. This gives an interval of 2 * 256 + whatever 58 hex is in decimal. This boils down to an interval value of 600 seconds, or 10 minutes.

I wrote the software, tested it, installed it in all four of the sensors we are building and then set them off. I then sent the above command to the sensors to set 10 minute updates and then relaxed in the knowledge of a job well done.

And all my sensors stopped transmitting completely. Wah.

Turns out that I am an idiot. I’d done everything right except the last bit, when I’d sent the following command:

01 02 58

I’d got the MSB and LSB bytes the wrong way round. Rather than having 2*256 I now have HEX 58 times 256. A big number. A six hour or so number. So all my sensors were now not going to transmit for six hours.

Sending the new command wasn’t a problem, but because of the way that we are using LoRa the sensors only look for new commands when they send a reading. So I had to wait for six hours before the command would get picked up and acted on. This is something to bear in mind about LoRa. The remote node is not always listening for a message, it only turns on after it has sent something. This is one way they manage to get such impressive battery life for LoRa connected devices.

I managed to solve the problem by turning the sensors off and on again. They always transmit a packet when they start up so I was able to update the timing with more sensible values without having to wait six hours.

Soak testing air quality sensors

48060254666_503165681d_k.jpg

For the last few weeks I’ve had four air quality sensors sitting on the windowsill in the house that faces the nearest LoRa gateway. I’m soak testing the devices prior to putting them on lamp posts around Hull.The air quality in that room must be one of the most highly measured in the county.

Anyhoo, one of the devices decided to try and spoil Fathers Day today by falling off the LoRa network. It was one of those situations where I really hoped that it was properly broken. There’s nothing worse than something that goes wrong every now and then. Unfortunately the darned thing came back to life at the end of the day, and so we are going to replace the CPU. My number one suspect is the antenna connection, but we’ll have to do some tests to prove this.

And no, it didn’t spoil the day. Had a lovely meal out and got some splendid presents.

Heltec serial port problems fixed

48060352142_d46f965eeb_k.jpg

One of the great things about working with other people is that if you get stuck you can simply hand the problem over to someone else. For ages I’ve been having problems with the serial connection between my Heltec device and the PC failing. I’ve tried all kinds of remedies and even thought one or two might have fixed it, but no. It’s a really frustrating problem because when the connection fails I have to re-boot my PC to make it work again. This rather slows down development.

So, I asked Robin to take a look. He put an oscilloscope on the power supply and looked at what happened when the air quality sensor was turned on. This sensor has a little fan on it and it turns out that this draws quite a bit of current as it begins to rotate. This causes the 5 volt supply to drop to 3 volts for around 50 microseconds, which breaks the USB connection on the Heltec.

Putting a 470uf capacitor across the Heltec power supply fixes this. So we now have fully working serial ports. Yay!

Lamp post sensor mountings

lamp post.PNG

I’m not sure how many of my readers really want to know a good place to get plate to mount air quality sensors on a lamp post, but if you do I can recommend these. They seem pretty strong and two of the fixing holes line up neatly with this box.

If you’re prepared to shop around and wait for delivery from China you can get both these items much more cheaply than the Amazon prices.

Always put a hole in the bottom

Note that this is not our air quality sensor. This is a nuclear warhead. Almost as complicated….

Note that this is not our air quality sensor. This is a nuclear warhead. Almost as complicated….

Had a great meeting with John today about the Air Quality sensors that we are going to fit on lampposts around the city. He had a couple of pieces of very sensible advice.

  • don’t make holes in the top where the water can get in

  • make a hole in the bottom where water that gets in can drain out

It's often a power supply problem. Especially if it can't be.

46839222825_f604ea9197_k.jpg

I've been working on an an air quality sensor that we are hoping to attach to a lamp post somewhere in Hull. I’ve got the hardware just about sorted (as you can see above) and the software should work fine.

But it doesn’t.

As soon as I connect everything together the serial interface to the host computer stops working. This is not a problem in operation, but it makes it hard to configure the device. I spent a little while trying to find out how the software could behave in this way and failing. After all, it works fine in other devices that I’ve made. And then I realised a very important aspect of embedded development.

“It’s often a power supply problem. Especially if it can’t be.”

The problem appears when I connect the SDS011 sensor. This is not particularly greedy in power terms, but it does take a bit more out of the device and this seems to tip something over the edge and stop it from working. If I add a second power rail to a different point in the circuit all is well. Now, it might be that the Heltec that I’m using is sensitive in this way, but we can’t have unreliable devices. I think I’m going to have to acquire some PCB design skills and make a proper carrier board with sends the power to all the right places.

Making bendy pipes with FreeCAD

bendypipe.PNG

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

32498751897_9b128b1b89_k.jpg

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.

47387664902_52f23236ed_k.jpg

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

Making an Air Quality Top Hat

40429261693_cb34a32c42_k.jpg

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.

33518560028_6f5164e5d4_k.jpg

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.

47341799092_2b633936b1_k.jpg

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.