The UK Minister for Small Business, MP Andrew Griffiths, came in to our new Lab this week, I had a chance to talk to him about our LoRa projects, and demonstrate our philosophy and equipment for rapid prototyping – illustrating how we take our ideas and concepts to reality in a matter of hours.
He was a very nice chap and seemed genuinely interested in what we are doing.
So this last few weeks I’ve been doing lots of grown up adulting, proper projects and things, and over the course of these few weeks I’ve heard the word “Metric” more times than I care to remember, its a very relevant word right now as it forms the basis for a number of work projects. But I like to understand things, so decided I wanted my own project to do uhh… metricing. With environmental data seeming to be the “Hello World!” of metrics, what better way than an environment monitor for the man cave command bunker. The data collection side is looking pretty good in prototype stage…
A little RaspiPi Zero W, collecting at this stage from a Bosch BME280 sensor over I2C (Temp/Baro/RH%), what a nice little sensor, as the sharp-eyes can see there is also an adafruit ADC there too, into which I’ll be feeding an MQ-135 air quality sensor, and likely some kind of light and/or UV sensor. Eventually I may bin the whole lot off for the new Bosch BME680(?) which combines all the previous functions into one package. Very cute.
With the data collected by EnviroPi ™, it’ll be fired over to my latest acquisition, a little HP microserver, running Ubuntu, and a time series database of some kind (Likely Graphite Carbon, but undecided at this stage as I’m wavering toward Influx), all visualised nicely with Grafana. The main question is, why? The answer is, why not?
Aside the poor colloquial joke title, its been a good morning. Having only really be
gun to cut my teeth with LPWAN at the tail end of last year, this morning I set what appears to be a UK distance record for LoRaWAN, just under 70km, from 902ft up a hillside in Wales, to North and East Manchester gateways. I think I’d call that success.
The node is a Pycom LoPy4, with an IMST antenna, had a few pings at that distance, and not really even getting toward the end of the signal strength, so if I can find somewhere eq
ually geographically forgiving then there is definitely more to come. Snowdon I guess…
Blogs are a funny thing, they always feel like a better idea as a concept, than they do as a reality – in that for me at least, I start one with good intentions, but then entirely forget about it, and continue to just post on the regular social media channels with no regard for the fact I actually have my own platform upon which I can say and shape as I please.
The other thing of course is that like most people (assumption), I consider my life to be quite ordinary, people constantly remind me that my work with CAD and 3D printing actually IS something a bit outside of the norm, and that I should be talking more about it and doing more with it – but its a way of life for me so I actually don’t think a great deal of it, I just move from one project to the next.
Playing with LoRa this weekend, kind of would help if I had my own gateway so I knew how far my messages were getting – single channel gateway is on order, but I’ll take this little puppy to work tomorrow and try it out there – I know there is good network coverage… Working on LoRa is all good, but when stuff doesn’t appear at the other end of the TTN, in the situation I am now with no gateway access, I have no idea where stuff is going, or how far its getting!
In better news however, my floating filament system for the Prusa i3 works beautifully 🙂
So I have a power supply, I have a nice little maker space at home to play around, and now thanks to the lovely kits by Keyestudio (available at great prices from Gearbest.com) I have a wealth of excellent sensors to play around with.
This is the Uno kit (as you can probably see), and I’m waiting on a Mega kit too, plus I have two Dragino LoRa boards just arrived from China too, so, I’ll brainstorm a few ideas and make some cool stuff of some kind!
FabLab training was great for getting my brain working around this kind of kit, for getting me to think in a developmental way. I’ve a load of extra atmospheric and temperature sensors too that I bought on eBay in bulk, so as a friend of mind said, “sending the temperature is the Hello World of LoRa” I think I need to follow that up with some kind of weather/enviro monitor kind of thing, just for shizzles and giggles…
So after the training the other week, I feel fueled up to do more electronics, constantly faffing around with the power on Arduino is really frustrating, as it appears to be able to deliver very little grunt when its powered by USB, so the minute you have anything interesting connected, the +5V is down to more like +4V, not good. Did some googling for a bench power supply, and without wanting to take out a mortgage for a TTI or HP supply, those lovely folk at Farnell came to the rescue in the form of the (seemingly well respected) Tenma range…
After a bit of buzzing around on YouTube, the reviews seemed good (it appears to be a re-badged “Korad” unit) and it was available in many flavors – single, twin and triple output versions with varying degrees of destructive power… The price sweet spot for my application appeared to be the Tenma 72-10495, which is a twin output 0-30V 0-5A unit, for just a shade over £120 before VAT and delivery, I opted for twin output as its nice to be able to provide 5V and 3.3V at the same time, or 5V and 12V etc. Placed the order, got the unit two days later (it was near midnight when I placed the order…) in perfect condition, delivered by the worlds brownest couriers, UPS.
Tested its outputs against my (old but trusty) calibrated Fluke 8010A meter, and it all shows nicely to within 0.02v, so I’m happy with that for a sub £150 power supply! The question now is what projects do I start to power with it, or more pertinently if I can’t come up with a good project, what scrap electronics do I blow up with 30V 5A DC?
So thanks to the Virgin Train strikes, the last day of my week’s training ended up from home, no bad thing, its preferable to being stranded in the capital over the weekend! So rather than scooting home on the Friday as per the original plan, I ended up back at home Thursday night, with a concrete idea of what I was doing Friday, thanks to some excellent direction from Tony, our tutor. Clearly the Friday plan was achieved, as this is it. The blog, website and content was my Friday. As engineers our own brand is important, it defines us, shows what we can do, and gives us all a place outside of our work lives to truly have a platform to demonstrate who we are, and what we do outside of client and company needs. Twitter is all well and good, but one little tweet is lost in the billions of other tweets, and so our own blog and platform through which to promote and communicate is essential.
So the day started out with a quick bit of web research to find what is generally regarded as the best web host (shameless plug for GoDaddy, excellent service, best online management portal!), then a few minutes reading up on wordpress integration. Finally after some mooching around looking for domains I settled on this one (the .XYZ being particularly good as a tie in to 3D printing!).
As you can see, we’re all set, my own domain and blog site, a handy platform through which to vent, to comment, and to feed back. So it was a good week, good time to sit down with the other engineers, play around making, designing, mending, coming up with ideas – it was all great fun, and well supported by our tutor Tony, who gave just the right level of involvement to keep us all pointed in the right direction, but without being overbearing or barking direct orders! Looking forward to 2018 I hope we can all get together more often, and show that the whole is far greater than the sum of its parts…
…on my walk in each morning, I’d been by this shop, each and every day I wanted to steal the big fish just a little bit more. Thankfully I didn’t, it would have been somewhat impractical on the train journey home.
Fish aside, it was the last day of the training for me and Ash, we should all have been there the whole week, but Hannah had other commitments and had finished on the Wednesday, I had to travel back Thursday (the day of this post) due to train strikes on the Friday (the day I actually upload this post), and Ash was desperately needed back at his base in Cardiff, as the site has only just opened and he had a mountain of setup still to do, and hordes of visitors wanting to go and look at the place… So with this in mind, myself, Ash, Charlie and Paul, all readied ourselves to make the air quality monitor system work as advertised…
Group Project – Air Quality Monitor
Initial tests of the system showed a number of bugs, while we had successfully tested subparts of the overall system, combining them all together to produce the full system introduced a number of timing and delay errors that needed to be tracked down and eliminated. Today we need to make the system work in its entirety.
The system was fully assembled and a number of runs of code from the previous day were used to test the input and output systems, while code from the main controller was revised and edited a number of times to eliminate timing issues, and introduce an element of debugging capability so we could watch each stage of the protocol at work.
A number of small bugs were located in one of the output modules, where it was sending on an incorrect radio channel (A change made late in the previous day), and another where it didn’t mirror its output status onto the LED screen, so it was hard to keep track of why the output kept going high, yet the display showed everything was still off, this was debugged by Charlie on closer inspection of my original code, which he had duplicated and adjusted to control a Neopixel output, rather than a servo.
Changes from the previous day included isolation of the input signals from the control modules to the main, into their own radio channel (moved from channel 1, to channel 2), leaving channel 1 purely for the output signals alone, as early on we had suspicions that due to buffering with the microbit radio receive, that we could be causing a huge delay by the application being so radio heavy, by forcing each Microbit to look through a mountain of messages that may not be relevant.
Sensor module code was cleaned and made more efficient, as a deeply nested logic loop in the sensor module code appeared to have issues during compilation causing significant slow down and delay in reporting and response of its signal data.
Once again I took the lead on making the test code and prompting hardware that can be used to trigger both input events, and test control outputs.
On the test bench the system eventually worked exactly as planned, with risk events (simulated using handwash, as it has a high alcohol content!) triggering appropriate alerting or corrective action as defined by the main controller. It worked!
Designing cases and making the system viable for use in the Lab network, further clean up of the code needed (may personally re-write in MicroPy just to neaten it up) and refinement of UX to give more useful display feedback on the system status. Perhaps using button A to toggle the display between some kind of status page.
We did it! We made it work, despite the battles with Microbit radio (need to play around with that more outside of Block Editor, I am suspicious of the compiler used), we made a functional air monitor and management system. It was a good week too, nice to have the engineers together working on a joint project and working to a common aim… Long may that continue in to 2018.
Day three was soon upon us, the first day we (all the engineers, of which there are five) work together on a common project, using some of the skills and knowledge we’d picked up on the first two days of the course.
Immediately we knew it had to be something useful, so the previous evening after hanging around in the maker space getting sore throats, we decided that an air quality monitor system might be cool. In our crate of goodies there were a number of Air quality sensors, and on day one Ash had been playing with the sensor on an Arduino to measure pollution, so he suggested porting his code over to the microbit, so we could use it to pull the data in, and then use radio (from my day one) to transmit to some kind of master device, which could maybe trigger warnings and fans and such, should the air become “polluted”.
We knew straight away that we wanted to use Microbits “Block Editor”, its a drag and drop coding environment, as one of our number, Hannah, was by her own admission a complete novice to coding, so we wanted her to be able to get involved in what we were doing, though as its transpired she turned out to be a natural at soldering, and ended up making five or six microbit breakout boards which we later used on the sensor modules and output boards, rather than getting too stuck in to the coding, though by the end of the training she had definitely come on leaps and bounds and was playing around with the block editor quite happily.
So as with the previous days we worked away nicely, though this time as a unit, leading to this write up on my perspective of the day…
Day three overview: Group project, air quality monitoring and response system
Four remote air quality monitor sensors placed around an area deemed potentially subject to low quality or hazardous air, these are to be interfaced to a microcontroller which will send the sensor data to a main controller, which in turn makes decisions based upon those inputs and can trigger resulting actions such as ventilation and/or warning systems.
Will use radio for data transmission of a group developed protocol, to identify the sending unit, and carry the air quality data to the main controller.
4 x Remote monitor units
1 x Main controller
4 x Output controllers
The air quality sensors output an analogue voltage, proportional to the “Risk” the sensor detects in the air (it measures a number of characteristics critical to the determination of “good” or “bad” air), each sensor is connected via analogue input to a Microbit, which sends an integer value to the main controller via Microbit internal radio, as well as identifying itself as part of the protocol.
At predetermined thresholds, the main controller to which all data is sent makes informed decisions on alerting and corrective actions, relative to the risk event triggered. Each of the remote sensors runs a live display of the quality value (0-9), while the master displays an average for the whole area, based upon the four remote values.
Output controllers are also Microbits, these can be triggered by the main controller when a risk/quality event occurs, there are four output controllers connected to various alerting or corrective devices, from simple warning lights, to solenoids to open windows, to fans for ventilation. In this way the system can manage the risk area.
Active involvement in development and setup of protocol to control transmission of data to main controller, process for flow control established with group to ensure message data is sent only on demand from main controller, rather than just streaming of data at all times.
Developed transmission test controls using extra microbits to establish method of transmission was reliable and proved concept and execution of protocol. Built all test solutions during initial development phase to iteratively test the transmission aspects of the project worked as they were built, to ensure solid foundation of data movement via radio.
Built and coded output controllers to interface with lights, and servo controls.
Probably our best day, we worked together really well to delegate tasks, and played nicely to each others strengths, by the end of day one the system was sort of working, so we left feeling pretty happy with the progress, knowing we could do some debugging the following day…