I’ve got the power (supply)

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?

Training, Notting Hill Gate(ish), Day 5

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…

Training, Notting Hill Gate, day 4

Big fish!

…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.

Personal Contribution

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.

Final results

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!

Further development

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.

Training, Notting Hill Gate, day 3

Left to Right, Ash, Hannah, Me, Paul and Charlie…

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.

Personal contribution

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…

Training, Notting Hill Gate, day 2

So day two at Notting Hill Gate, happy with having a play around with the microbits I moved my attention to something a little further up the food chain, the still usable, but potentially more involved, Arduino platform. I bought an Uno board ages ago and played around for a few minutes here and there, but never actually got around to connecting anything to it, even only simple things, so once again this was a good time to just hook up some simple stuff, and see what is and isn’t doable…

Adding basic devices to Arduino


Testbed for use of Arduino IDE, hook up of simple devices to facilitate rapid development of more focused and useful applications – knowledge formative exercise adding each device one at a time, establish method for mode of operation for each device, and understand code  with view to merging code and devices at once, to build full scale applications using the array of I/O of an Uno board.


Arduino Uno, HD44780 Compliant LCD, RC522 NFC Card reader


Stage 1 – LCD device, attach the LCD to the Uno development board as follows:

LCD RS to Digital 12

LCD Enable to Digital 11

LCD D4 to Digital 5

LCD D5 to Digital 4

LCD D6 to Digital 3

LCD D7 to Digital 2


LCD Pin 3 to GND (Contrast)

Copy test code into Arduino device:

// Bring in the required library for driving LCD displays
#include <LiquidCrystal.h>

// LCD pin setup, see LCD example documentation for further details
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

void setup() {
  // Sets X Y configuration of LCD connected
  lcd.begin(16, 2);

  // Display something on the LCD.
  lcd.print("hello, world!");

void loop() {
  // Running code for main loop here...


Demonstrates how simple the LCD is to set up, and puts basic characters onto the screen, useful for serial debug etc. Remove wiring and LCD for stage 2.


Stage 2 – Reading with an RC522 NFC reader and dumping the output to the IDE serial monitor. Attach the RC522 in the following fashion:

RST to Digital 9

SDA to Digital 10

MOSI to Digital 11

MISO to Digital 12

SCK to Digital 13

3.3V to 3.3V


Copy test code into Arduino device:

// Bring in necessary libraries for the reader and interfaces
#include <SPI.h>
#include <MFRC522.h>

// Start an instance of the reader
MFRC522 mfrc522(10, 9);

void setup() {
while (!Serial);
Serial.println(F("Scan card to see all available details..."));

void loop() {
if ( ! mfrc522.PICC_IsNewCardPresent()) {

if ( ! mfrc522.PICC_ReadCardSerial()) {



Present card to RC522, contents of device are presented on the IDE serial monitor screen as a verbose dump. Most useful value arguably card serial, ideal for use as identity device as serial is read only block. Demonstrates simple extraction of data from NFC.

Further Development

Combining both sets of code to give output on LCD display, or message customized to the card.

Another good day of tinkering with simple stuff, but good stuff that can be combined to make BETTER stuff… Day three, is the first day of our group project.

Training, Notting Hill Gate, day 1

The week of the 11th of December 2017, I met up at Notting Hill Gate with some other engineers from my team, Paul, Hannah, Ash and Charlie, for us to embark on some joint training, what follows is a few blogs on how those four days of training panned out!

So working as a Lab engineer is a mixed role, we’re multi-discipline, people can come to us with all kinds of projects, that can need all kinds of skills. I’m pretty handy with a 3D printer and a laser cutter and some CAD software, but getting the time to play around with electronics is a rare luxury, so when we were told we’d be getting a week at our Notting Hill Gate lab with FabLab’s, the curriculum sounded like an ace opportunity to get some tinker time…

The first day was personal project day, giving yourself the time to just learn about something of interest that you wouldn’t normally have time for. Working out what to do was as simple as rummaging through some huge crates filled with all manner of goodies, from drones, to arduino boards, microbits, littlebits, you name it.

Being a big fan of the microbit, and an avid believer that they are hugely under-rated for electronic development, I decided to have a play around with a pair of microbit devices, as I wanted to use the internal radio function: It was something I’d been meaning to do for ages. Each day, we had to write up our activity, so, here is my little brain dump from day one…

Simple dual Axis spirit level with remote view via radio


Demonstrate simple use of internal inclination sensor and radio transmission and reception.


2x Microbit, 2x Battery Pack


Copy master code to one Microbit, slave code to the other. Power up both microbits, M will be displayed on the Master, S will be displayed on the Slave.


Master is the remote display, position it in an easily visible location. Slave is the inclination detection device, place it on the surface to measure, hold it steady and press button A to show the pitch on the display and send the Pitch (Y) to the master for remote viewing, or press B to do the same for Roll. (X)

Further development

Real-time display on master using a “Chasing-dot” format to show roll and pitch on the slave, real-time output on serial port.

A very simple but enjoyable first day, nice to see the Microbit Radio in action, and see just how easy it is to use, makes the Microbit very handy for a number of projects… Watch this space!