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…