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.

Air Quality Hardware Meetup

We had a splendid hardware meetup today. A whole bunch of new people turned up, including Dave White, Hull City Council Air Quality Officer. We wanted to discuss sensor design, data visualisation and a bunch of other things. So we did. It was great. Lots of plans made which I really look forward to seeing lead somewhere.

At the time I promised to put up a bunch of links to things that folks might find interesting. I think these are the ones, please feel free to let me know if there is anything missing.

  • You can find out about Connected Humber here.

  • You can join in the conversation about Connected Humber, Air Quality or anything else you fancy chatting about here.

  • You can read my amazing blog here. Oh, you are doing. Thanks for that.

Adventures in Colour at the Connected Humber Hardware Group

40471170163_79f0259417_k.jpg

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.

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.

IMPORTANT NOTICE ABOUT C4DI HARDWARE GROUP

If you’re wondering where the Meetup site for the c4di hardware meetup group has gone, we’ve moved our operations to GetTogether. Alternatively you can just turn up at a Meetup at c4di on the first and third Thursday of each month, starting at 6:00 pm.

Note that the above picture is not one of mine, I’m using an image from unsplash.

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.

November the 1st Hardware Meetup

45627144722_cbd840f439_z.jpg

Another first Thursday of the month, another Hardware Meetup at c4di. This time I had an agenda of my own. I’ve just found out that you can get printed circuit boards made for really low prices. Really low. This has stirred within me an intense desire to find out how to make them. (posh prose eh?)

Anyhoo, it turns out that among the Hardware Group membership there are folks with experience with the tools that you can use to make your own PCBs using a free tool called Kicad. We’ll be doing a PCB design special event at the next meeting, on the 15th of November. If you’ve got any interest in building your own hardware you really should come along. The price of having lovely boards made specially for you is so low as to make them an extremely attractive prospect for makers.

You can sign up for the next meetup, and keep track of what we are doing, by joining our new group on Get Together.

Connexin Live

I can’t help thinking that  HullOS  has a much better ring to it…

I can’t help thinking that HullOS has a much better ring to it…

A couple of weeks ago I was at the Hull Arena marvelling at how Hull could put on such a fantastic digital awards ceremony. Today I’m at the same place marvelling at how Hull can host a splendid technical event. One of of the first thing the delegates were told about Connexin was that they are a Hull company. Born and bred. And proud to be here.

Connexin are a local company with global plans and big hitting partners in the form of Cisco. A Cisco person had even flown all the way from San Francisco to speak at the event. The theme was something very dear to my heart; Smart Cities. We heard from Hull City Council and Hull University about their ideas for the future and from folks from Newcastle about what they had been up to.

These are challenging and exciting times for local government. Challenging because budgets are being squeezed as never before, and exciting because technology is showing real potential for improving the lives of the people that the councils serve.

It was great to hear all these inspiring plans being laid in Hull. I couldn’t stay to the end unfortunately, I had to go and see how the Hardware Group at c4di was getting on. The answer, by the way, is very well. We’ve got three new members who’ve turned up and want to have a go with the Arduino. I’m putting together some kits for them for the next meeting. You can come along and have a go too if you like. The next meeting is on the 11th of October at c4di, starting at 6:00 pm.

MQTT topic management conundrums

31119526288_2b9d11758e_z.jpg

Well, this sounds like a gripping title for a post eh?

But actually for me it’s a thing. I’m getting my head around MQTT as a way of sending data from our air quality sensors to the systems that want to work on the data. MQTT is a “publish and subscribe” transport. An MQTT node can send messages to a particular address managed by sn MQTT broker process running on a machine somewhere. Other processes can subscribe to that address on the broker and, when the mode sends a packet of data (string of bytes) to the that address the broker will then send that message to everyone who has subscribed to that address.

Make sense? OK, think of it as a mailing list for a pop star, perhaps David Essex. Anyone interested in what David is up to can subscribe to the mailing list, which has a particular name. David’s publicist, who produces the content describing the amazing life that I’m sure David has, (other pop stars are available for this exercise) connects to the mailing list as a publisher, and sends messages which are then sent out to all the subscribers. So MQTT Is basically a fan mail management system.

The address expressing the a particular endpoint is called a topic. Topics are hierarchical. So, an air quality sensor could send a messages to the following topics with the respective data items from that sensor:

Sensor01/temp
Sensor01/pressure
Sensor01/humidity

Alternatively, an air quality sensor could send a single message containing all three values, encoded as a lump of JSON (JavaScript Object Notation) to a single endpoint:

Sensor01/data

Which is better? I’m not sure. Object Oriented Rob says that having all the related items in a single cohesive object which can also contain things like timestamp and location information will make it much easier to process. Free Wheeling Rob says that having individual data on separate topics makes it possible to handle data produced at different rates by different sensors, and also makes it easier for something only interested in temperature (a fan perhaps) to just subscribe to that data item. And both Robs need to remember that the broker is just that, a broker. It doesn’t have any bearing on what will happen to the values that are passed through it from a device to a process that is doing something with it.

As usual, when faced with a problem like this, I’ve gone a bit meta. To me the important thing is probably not which particular way the values are configured for a given application, but that it should be easy to change this configuration during the lifetime of a node. To this end I’m working on a little protocol which will let a node advertise the readings that it has available and then be told which readings to be sent where. Once a node has been told where to send its data it will do that until told otherwise. This means that we can change how we use the sensors so that we could use either of the above approaches.

The good news is that this will be wonderful. The bad news is that I’ve got to do it. Oh well. Today I got a Python program talking to MQTT. The next step is to get JSON working on the Arduino so our systems can start exchanging configuration information.

Talking MQTT

mqttmessages.PNG

Ha! Today has been a good day. I’ve got my Air Quality sensor talking MQTT to the Connected Humber server and sending messages. This has been a bit of an adventure, mainly because I had to mess around with the libraries for the Heltec device that I’m using.

Anyhoo, I’m now sending messages over both LoRa and MQTT at the same time. Go me. Now I just need to add some configuration options and I think we might actually have a product here.

Incidentally, I’m using a Windows app called MQTTBox to view the messages on the server and post test messages to my sensor. Works rather nicely. And free.

Rob at Ron Dearing UTC

30041497068_3f43db175b_z (1).jpg

Despite arriving a tiny bit late, I had a great time at the evening event at Ron Dearing UTC today. A whole bunch of folks came to see me to talk about technology and I showed off some Hull Pixelbots, my silly goggles and the prototype air quality sensor that we’re working on over at Connected Humber.

Of course, I totally forgot to take any pictures at the event. Silly me. That’s why there’s a rather splendid picture of Whitby pier at the top of this post instead of anything relevant to the night.

Anyhoo, I talked to a bunch of folks and gave out a bunch of advice. Summarised thusly (posh prose)

  • If you’re into computing, start playing with the Arduino device. It’s cheap to get started (much less than a video game) and extremely creative. Buy a Sintron Arduino kit (search ebay or Amazon for “Sintron Arduino” to see a selection of kits. The one that is around thirty pounds is good value. If you want to start cheaper, come along to a Connected Humber event (we have them on the first and third Thursday of the month at c4di starting at 6:00pm in the evening). We’ll sell you an Arduino and some hardware for five pounds and give you some things to do with it. You can find out more here.

  • Start learning about 3D design. Lots of people that I spoke to were already doing this. The ability to think in 3D will stand you in good stead whether you go into fields ranging from video games to product design. There are lots of free packages you can use, I quite like FreeCad, although it can be a brute to get to grips with. If you’re a programming type, take a look at OpenScad. If you want to use a free, professional level, tool take a look at Blender. It will really make your head hurt, but you can do awesome things with it. Take a look online for howto videos for these tools. If you don’t like the ones that you find, make some better ones of your own.

  • Which brings me to my third point. Lean to write and talk. When you start doing something, start writing about it too. Put your writings into a blog, a personal diary or a log. I don’t mind. The important thing is that you do this. I made the point lots of times that you can learn a good living, and have fun, as a programmer. But if you also have the ability to write well and are good at communicating your ideas this makes you much more useful and interesting to employers, getting you even more interesting and rewarding things to do. So you should work at getting those skills. Deliberately do things that take you out of your comfort zone. Practice talking to people (networking is a big part of success) and try to force yourself to speak in public. Trust me. It really pays off.

By the end of the evening my voice had just about worn out, as had the batteries in the robots. But it was great fun. And then I went home and had bananas and custard for supper. Such fun.

Air Quality Sensor Version 1.0

If you think that all I've done over the last week is work on my Air Quality sensor you'd be wrong. But I have been quite busy with it. I've now got a proper menu system with messages and numeric input. Plus a box. The box has been particularly fun to design, especially as the Heltec micro controller, in common with lots of similar devices, doesn't seem to provide any way that it can be fitted into a case. I've ended up making a little clamp that holds it in position. I'm not happy with this, but then again I'm not crazy about my looks either - but what are you going to do? 

To say that the case is printed version 1.0 it has gone together quite well. I'm using the "dead cockroach" assembly technique, where you regard the chip as a dead cockroach lying on its back and connect the wires to the upturned legs. There are no components other than the devices that I'm wiring together. The only tricky bit is that the clock and the temperature sensor share the same SDA and SCL lines and so I've had to make up some custom cables. But it's all working, and now I have a box with all my sensors and whatnot that I can start to to build software for. 

42346248680_6e74e01191_z.jpg

This is the ugly truth about what's in the box. We'll gloss over the way that the wires for the RTC are too short to allow it to be fitted onto its mounting post, and the wire for the sensor is far too long......

The next step is to add a "WiFi Setup" mode that can be used to get the device onto the internet and then we can start pushing readings into the cloud. You can track the project on GitHub here. Bear in mind that this is a work in progress, and so nothing is fixed. This is all part of the Connected Humber Monitaire project, you can find out more here

Building an Air Quality Sensor

I've been having proper fun today. I started with one of my tiny Heltec embedded controllers and an urge to connect it to an air quality sensor and a temperature/air pressure/humidity sensor. 

It wasn't easy, but it was possible. Biggest problem was that the temperature sensor uses an i2c connection to the Heltec device, and so does the lovely little OLED panel that you can see above showing numbers.

Turns out the way to make it work is to create another Wire instance and then use that for the temperature sensor. Anyhoo, it works. If you want to see the code you can find it here.

I've written everything using message pumps and state machines so that it should be possible to have all this working together without something getting stuck. 

Hull Meetups is becoming Connected Humber

Things are changing, but not changing. The c4di Hardware Group is turning into Connected Humber. We'll be meeting up at exactly the same time, in exactly the same place, doing pretty much the same things. Only more so.

We're going to turn the group into a Community Interest Company CIC, which will make it possible for us to do even more interesting things, and give us a recognisable presence when dealing with companies and local bodies. 

For existing members the biggest change is that you can now find out about meetups and what we are doing by using the Connected Humber website. We'll be bidding fond farewell to the Meetup site that we've used in the past and we have a Slack channel for members of the group. Ping me a message if you want an invite, or turn up to the meetup this Thursday (16th August). 

We've lots of community activities planned, starting with a project to build a network of Air Quality sensors that we plan to deploy around the area. Exciting times.