How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Open Source: Why We Often Get Back More Than We Give
This story is for The Nerds. If you want a Build Guide, click here. This section is about the choices I made along the way, and how things progress from a few disparate insights and ideas, and some cardboard, to working prototypes and testing in other people’s homes.
I write these things down, as they are somewhat like a diary, so they help me reflect and process my work with people - but I also do this because I’ve always appreciated it in other creative I respect.
Images: I love the introspective works of the likes of Christoph Neimann, Stephan Sagmeister and Thomas Thwaites, to name a few. Similarly, I am in awe of the writing and oratory styles of the likes of Bell Hooks, Werner Herzog and David Sadaris - on recent audiobook playlists. I regularly treat myself to ‘Art Books’ from the auteur directors like Stanley Kubrick, Wes Anderson, Hayao Miyazaki and various Pixar films - which show the process of collaboration in an attempt to define a vision. I say these not to ‘peg’ myself at their level, but that we all have our idols, and as to my earlier point about ‘stealing’, we all borrow ideas, and are arguably not lone agents, but part of a zeitgeist. I value other technical creatives like Brendan Dawes, Alex Dechamps-Sonsio, and Matt Jones, to name a few, who don't just create great work, but consider reflection and discourse part of their output.
Image: I was recently at a screening of Eno, and Brian Eno pointed out that a significant part of a creative output is not what the creator instigates, but how the rest of the world engages with it also. I took this to mean that this is not as pretentious as some avant-garde works, (where I’m not sure the artist even knows what they are trying to say always), but rather it’s about the humility to respect a significant portion of the value of a creation is in the eye and mind of the beholder. It is a dialogue. And so too is this. Please critique, compare, contrast, collaborate…It is open-source by design.
Designing The Change You Want To See in Tech
At its simplest level, this is an account of one way to create a digital device that uses an API. However, as I’ve said in many talks/blogs - the hard part of tech integration is rarely the hardware or the software - it’s the human factors that surround them. As you’ll see with Flood Alert, this project lives and dies by the latter, and indeed, it’s the reworking of human engagement which is what will have the most bearing on the next phase expected to involve Machine Learning (AI). Above all, it is this tension between the unblinking indifference of AI, and the humanity we do, or do not, put into it.
Charlie Brooker certainly has one of the best title names with ‘Black Mirror’ to evoke the dystopian view of this, but after seeing him speak at the O2 in London in 2018, he conceded that writing dystopia is 10 times easier than writing credible and compelling utopia. And so as much as I am acutely aware of how bad things can get, I agree with Brooker when he said that it’s ironically our correctly recoiling at ‘tech gone wrong’ - that arguably proves we do have our heart in the right place. The more I learn about tech, I learn 10x about what it is to be human. Daft Punk may well have felt the same, making robotic music, yet calling the album Human After All.
Okay, enough preamble - on with the prototyping!
From ‘quick and dirty’ cardboard prototype beginnings, after about 3 months, we arrived at this lovely 3D printed, working prototype (video in action). For those of you curious as to how I designed this, I thought it fun to share some of the journey, as although seemingly quite simple by design, it has some nice design details you may be inspired by to add to your own projects, and very much a result of sparring with the excellent Pete Milne (Code, API, Electronics) throughout the process of designing the user interaction.
Starting: Cardboard and ProtoBoard
Having been inspired by the CryptoInk form factor and function - of being able to be magnetised to a Fridge, whilst also standing like a Photo-frame on a desk, I sought to make my own version of this for the needs of this project, (see previous blog post). Card helped me to rough out the ergonomics (how we interact with it), the anthropometrics (the product, relative to the size of our hands, etc.), and of course the style and other functionality like where to place the magnets, power supply, etc. All this is often summarised as UI/UX design, but for me nothing beats doing this by hand early on, to avoid elementary mistaken assumptions or weird things which one can miss in a virtual world like CAD. Things that are light-weight and feel can often catch designers out if they do not ‘export’ periodically to real life and test these human interactions.
Although I often cite the cardboard model as the ‘starting point’ in talks, (as this is a convenient way to make the process relatable and easy to understand), in truth, the true process was more of a ‘dance’ between working out a package size for the hardware components, ie the ProtoBoard layout, and the desired user experience of the design of the enclosure.
This is how I got the general ‘feel’ or where it was possible to lay things out. Perhaps because of my ‘formative years’ being at Dyson in 2009-2013, where there was more of a pragmatic ethos around PCB design not being too ‘decedent’ - one tried to give things in a straightforward manner. It’s not that one cannot use 50-layer PCBs, perhaps if you're Apple making the Vision Pro, this is fair, but when it’s a Flood Alert, I felt it reasonable to make a 2-layer, 2-sided PCB for as little cost and complexity as possible.
We could perhaps get into a philosophical debate about whether allowing too much complexity is a good idea. Its design means things like AirPods are wonderfully small, but it also means you can’t repair them whatsoever! Does this mean that if Flood Alert was a consumer product, I’d certainly try and make it smaller and more space efficient, but as this is a prototype and beta test, a bit of simplicity, repairability and resulting chunkiness seems fine!
Recycling Prototypes: From Canary to Falcon to Flood Alert
Below is the circuitry from the previous RS DesignSpark project - the Good Air Canary. It’s much more elaborate than the Flood Alert, but we reused a lot of it. (See Ideation also).
Images Above: Previous Good Air Canary / Flood Falcon electronic setup.
It may seem that this ‘V2’ circuitry update seems to ‘arrived out of nowhere - fully formed’, but the reason this development seems so rapid is because most of the general functionality was transferred from the Good Air Canary / Flood Flacon circuitry to the Flood Alert circuitry (minus the servo motor, and to fewer Arduino boards).
Images Above: Follow-on Circuity of the Flood Alert, with only the necessary parts remaining, and some newly added lights and buttons.
You might say we ‘recycled’ perhaps 70% of the hardware and of course various experiences (do’s and don’ts) we were ready for the second time around, like using USB 5v power, instead of 12v, as the servos, speaker boards, etc. - didn’t need the extra voltage, which simplified the design significantly. Large items like the speaker - needed as they produced full-spectrum sound, were replaced by smaller, cheaper, less complex components like a piezoelectric buzzer, as the Flood Alert only needed to ‘beep’, not ‘squawk’ and talk!
Similarly, with the Flood Alert, we were able to remove a lot of the ‘rat’s nest’ of wires as these mostly translated into efficient PCB ‘tracks’, whereas all the speakers and servos of the previous Canary/Flacon design remained pretty ‘busy’ things to manage in the design.
Now came the process of optimising the PCB, such that it would be as small as possible - but for a 2-sided PCB. As you can likely tell, I positioned the traffic light LEDs in such a way that meant that they were above the Arduino (on the flip-side), but this in turn meant there was a ‘natural break’ between the Red/Yellow/Green lights and RGB LED (multicoloured). I could pretend this was all by design but actually, it’s what some call a ‘happy accident’ in the design process, where that space denoted a differentiation between the common user functions (traffic lights) and the technical RGB LED, which tended to show things for diagnostic like whether the WiFi was connected, and the API was linked.
Similarly, if you look closely, you’ll see the top button is ‘resting’ on top of the buzzer. I didn’t have any 90-degree buttons, so this was a fun little hack which stood in until I ordered some from RS Germany! Again, much of design is ‘improvisation’ and just getting it done.
CAD Modelling & ProtoBoarding the PCB Design
The PCB was then referenced in CAD, and this allowed me to build the enclosure around it.
From this, I could design the Enclosure. My design intention, as with many 3D printed prototypes/pilot projects - is to make them as simple to print as possible. I’m actually pretty pleased this entire thing only had 3 printed parts, with one being a button extender.
This is a rudimentary, and somewhat chaotic bit of freehand wiring on my part, but it’s always helpful to check everything works - even if a bit ‘chunky’ or ‘messy’ before sending to make a PCB. Even with this jumble of wires, everything fit nicely and the system worked as planned after a little debugging, and changing some UI/UX preferences with Pete Milne.
UI/UX Design in Parallel to 3D Prototypes
It’s tempting to think the design and engineering process are neatly sequential, like making a soup - you add this then that then that, and simmer - and voila! Perhaps a better cooking metaphor is making that very British of banquets - the Roast Dinner, where you’re juggling a lot of things and adjusting things in relation to another.
Whilst considering the LED positions, I was also considering the graphical design of the warnings. Perhaps in later versions, we may want to make the buttons light up with graphical prompts on the eInk screen, but for now, this seems fine to have them ‘related’ but not needing to be pixel-perfect in their alignment. So I opted for a more forgiving approach, which was also (as Pete Milne pointed out) more in keeping with the official government warnings. So it seemed prudent to align with this standardisation to avoid any misunderstanding, and to also assume that they had to have tested their graphics and wording to be optimal for the general public.
Images: Government Hazard warnings for Flood Risk.
Images: Jude and Pete’s revised hazard warnings for Flood Risk.
Although we have some issues with reducing the text slightly, we’ve tried to align as much as possible with the Environmental Agency wording and intent, also adopting the 4 screens. I created these in Adobe Illustrator, and scaled the images to the right size, where Pete then converted them to the rendering code in another programme and imported it into the Arduino IDE software. Sounds easy, but isn’t!
The software test was looking good with all the API working nicely. However, as always, as a designer, you have small considerations like taking the warning triangle off to make the ‘no flood warnings’ more calm, and hence, by contrast make the alerts more visually distinctive.
Images Above: Pete and I were aware of eInk screens which could produce Red as well as Black pixels, however, you’d think that given these are seemingly so similar, and even made by the same company Waveshare, it’d just be an easy case of getting the drivers and presto!
Sadly, nothing could be further from the truth. Having watched Pete Milne work with other engineers, I’ve come to learn that when Pete says ‘it’s tricky’, this translates to even quite seasoned engineers as ‘damn near impossible!’.
For the original Black and White screen there was no working source code / drivers, so he had to write it from the ground-up reading what manuals and tech specs he could find around the web. Not to sound like I’m just plugging RS, and being down on Waveshare, but this is often one of the problems with going with a ‘random supplier’ - they might be manufacturing all manner of OEM stuff, and putting it on AliExpress or eBay does not mean you’re getting the customer support, if you’re not a major vendor/buyer.
So in hindsight, it’s pretty impressive that Pete did this once, but perhaps we’ll get lucky and they’ll do an update for the Red version, but looking at the time of writing this particular size does not seem to have had many updates. Do ping us on GitHub if you crack the code, and we might be an update!
Aside from this, the code with the Black and White screen worked great, and Pete and I spent some time ‘dialling in’ the small details of font size and sequencing of information, but essentially it came together very smoothly.
Communicating Design Specifications and Design Intent
It’s worth saying, things do not usually go this smoothly for everyone, and this is more credit to Pete Milne’s frankly ‘shifu-like’ skills with systems electronics than mine. Projects are made and lost by the quality of the folks you work with and for that I’m very lucky. Another excellent engineer is Kevin, the PCB designer, who again, got it right the first time, as he did with RadioGlobe and the Canary!
I would say that it always makes sense to annotate a quick screengrab of the design and to explain the functionality. I had worked closely with Pete, so he knew the ins and outs of the project, but Kevin pretty much had to take it all on the first meeting. So this is where good diagrams and explanations of form and function and design intent really help!
In fact, at the time of writing this blog series, I also just watched a Film about Ambessa Play, following the design (DFMA) through to manufacture in China. (link). What is apparent is how you need to specify a lot of things which often feel obvious to you, as you’re very familiar with the thing you’ve been working on for ages, but to someone else - in this case, Kevin, the PCB designer, it is best to ‘take it from the top’ and explain all features afresh.
Images Above: Explanatory reference drawings for engaging others new / supporting the project for discrete tasks like PCB manufacture.
Above: One of the pet irritations of engineers’ is often adding too many decimal points to drawings. In my defence to the 2 decimal places here, it’s simply because I was working with the standard 1/10th inch spacing of PCB through hole components which was 2.54mm. So I’ll be honest it seems weird to look at it!
Above Image: Testing the Electronic components ‘fit’, and also the not unimportant mechanical validation of ensuring the magnets being strong enough to stick to any metallic surface!
And in case you were wondering if I was being extremely sloppy with the use of internal space in this, I was still ‘on the fence’ as to whether we might add a LiPo Battery - to make the Flood Alert truly remote. Although the CryptoInk project had a battery, I felt that the Flood Alert was most likely to be kept in one place in the home, and not regularly repositioned, but I was willing to be wrong, so hence leaving some space that would mean we could still add a rechargeable battery (and charging circuit) if needed.
Kevin took a combination of my measurements, and design intent notes, and suggested components (from Pete Milne), and then revised and composed the PCB layout as shown above. Despite my having no clue in how to design a circuit, electrically speaking, I seem to thoroughly enjoy doing component layout and wiring, and in many ways, this means I’ve actually at least physically prototyped the board before I send it to Kevin! So in many ways, if I can do it in basic hook-up wires and protoboard, it can nearly always be done in 2 PCB layers (or with a couple ‘cheats’ with a bridging wire if need be).
Image Above: I was so excited to get these from Eurocircuits, I hardly even had time to compose this photo and light it properly. They looked great, and soldered up perfect!
Above Image: And here we have it - all soldered up nicely! So as you can see this has dramatically reduced the ‘rat’s nest’ of cables, and it now runs on just a few GPIO / header pins.
Above: Pete Milne was in London, so picked up a pack of the parts to test if he could follow my instructions and successfully build one. It’s arguably a ‘user test’ with an advanced user (!) - but always good to still check that there is not anything easy to make a mistake on, or where a tolerance is really tight/loose etc by someone else’s standards.
Above: Great to see it working in someone else's hands!
Scaling-Up Production
For the first pilot, we went for a ‘baker’s dozen’ of 13 Devices, with 10 to test with the general public and some spares for testing and archive. Given that it took me about 3 hours to solder the ‘DIY’ PCB, with bespoke cut wires, and about 20 mins for one with Kevin’s PCB, it was a huge improvement. Of course, if we made a batch of 100+ we’d outsource this and likely redesign the components to be surface mount (SMD) and not ‘through-hole’, but as we were still finding value in the ‘flexibility’ of this ‘Proto-PCB’, such as changing resistors to adjust the individual LED brightness for example, this is still very useful for this stage of the project.
The PCBs cost around a few pounds for each board, but with shipping from Europe, this meant the overall effective cost was about £7-8 each, so not cheap. In contrast, if you are not in a hurry, and can wait longer from PCBs in China, the quality can vary, but for such a simple design it’s unlikely to be problematic, and will be a fraction of this. No surprises that this is always a balance of how ‘serious’ your project is, where an economy of £100 may be great if a hobbyist, but irrelevant if you’re putting it in something which has consequences that eclipse such savings, if it breaks - or worse - has a hard to diagnose fault. The choice is yours, but over the years as I work on more ‘critical’ projects, time and reliability usually outweighs any component savings - when at the pilot/beta/test stage.
Going The Extra Mile on Data Privacy - and Ease of Use
I would not have expected one of the best things we did in this project was to buy our own GSM (mobile) WiFi. It seems staggeringly obvious in hindsight, but because we were thinking of our working being analogous to most other commercial IoT projects, which need you to enter your password - if you have a Smart Doorbell for example you’ll know what I mean.
The issue is that these intermediary things are not cheap - you have to build an app, and even aside from the expense, our real issue was that because we were designing the Flood Alert to be for people who were non-techy, and perhaps vulnerable, it was just becoming a total headache to figure out how to get a 85-year-old lady, living alone set up with a Flood Alert.
Even if she did have a friend (i.e. chaperone) to oversee my installation, it’d still get tricky to ask her to enter her home WiFi password into our beta software. I’m not wishing to sound disrespectful to any member of the public, but it gets pragmatic if one is accused of misconduct, creating a virus, messing with their internet or whatever… you can see how this can get out of hand fast, through a misunderstanding! Even if they didn’t make a complaint, it might just be that they decide to switch the device off, feeling a bit suspicious. Being sympathetic, this is the tension of the project that we’re trying to design something that is actually quite techy, but needing to really push hard to make it intimidating and very very simple to use.
So when we realised that for £27 for a TP-Link SIM/WiFi Router, and £50 for 2 years of data on 3Three Mobile SIM Only plan, this may sound like a lot but for a research project with the general public (i.e. £77 vs the seemingly endless cost of litigation and other issues) this was a non-brainer to remove so many issues. Not only that it ended up making the system go from ‘typical’ (but not great), to ‘best in class’ in terms of data privacy - because it was working on it’s own WiFi, with all data paid for by RS DesignSpark, there was basically no risk of any issues with the user’s home WiFi.
The Holy Grail of Tech Pilots: “Plug n Play”
Once again, this is testament to Pete Milne’s excellent streamlining of the code, as all I had to do was look up someone’s local area, pick an appropriate set of Environmental Agency warnings (in my case for Walthamstow: Lee Valley Tributaries - was 062WAF53LLTribs, for example), and this would be saved (along with WiFi credentials) to the Flood Alert’s Arduino and it was all set. The 3Three data plan also simply ‘started’ when you took your first byte of data. Simple.
It really worked ‘right out of the box’ - we had achieved Plug & Play status!
Images: Left are the Lee Valley Tributaries (rivers), in yellow. Right is the code for said river data.
Image: The only thing left was to make a cool ‘box’ for it to ‘come out of’, which could be shipped to any user for testing. This was an ‘Air Pistol’ carry case for £10 in case curious off Amazon.
Testing While in Hong Kong
As I was visiting relatives in Hong Kong and took a Flood Alert with me. In addition to this, I was also working on what became the Fight to Repair project (again, for RS DesignSpark).
Taking the opportunity to see how this worked whilst on holiday, I was aware the API from the Environmental Agency would still remain specific to my home in the UK, (we didn’t have time to code a Hong Kong Flood Alert equivalent, although the APIs surely do exist). Anyway, because it’s battery-powered and runs on almost no data in terms of WiFi, I put it on to test, also curious if it had any unforeseen ‘overseas’ or ‘firewall’ issues…
3:26am. It worked a charm, though regrettably when on holiday and because of the timezone-shift, (UK 8:26pm), the hour was ungodly to get a beeping alert, whilst still asleep in bed! And indeed, not the most restful thing when supposedly on holiday (and yes, my wife is incredibly tolerant - I’m a lucky man!), but truthfully I was quite excited it worked! Even if the realisation this is not ‘great news’ arrived a few seconds directly after this…
Whilst in the UK I’d previously brushed off most warnings of the last year and a half, as being ‘cry wolf’, as mentioned - none were about surface water data, only rivers, so this didn’t really ‘correlate’ to our street. With that said, I must admit when away from your home, your imagination gets the better of you, and so I asked my neighbour to look in on our house in case it was the one time a biblical deluge was falling!
I was pleased to find out that it was all ok and nothing as usual, but certainly, it made me see the potential for wanting an alert whilst on holiday - crucially with enough warning that someone had a few days, or at least many hours to get sandbags, etc. I also was reminded of Heather, from Flood Forum’s point about how the emotional aspects of flooding are under-acknowledged, and even in this small way that ‘jolt’ of reeling somewhat ‘helpless’ when getting this news away from home and having not got a perfect action plan certainly gave me pause of thought on how to not just consider the Alert, but also the interventions that are needed around this, be they preventative or relative and ideally having both.
The next stage of the project documents the first attempt to test Flood Alert with new users…
Footnote: Future Proofing / Room for New Ideas
I mentioned in the Ideation Blog that I wanted to have the capability to also explore expansions of the hardware and software. Although adding Machine Learning ‘on-device’ would likely require a new computer as the Arduino may not be powerful enough - resulting in AI processing likely needing to be done ‘on the Cloud’, I was also exploring the possibility of using the Nano 33 BLE Sense (Rev 1) (192-7587) Module from Arduino, which has a stunning array of environmental sensors on it, and is even encrypted (rare in BLE).
The idea being we might be able to monitor actual environmental data from a tiny little low-power module outside your home.
The idea of having an Expansion Board with ‘hyper-local’ Environmental Sensors, was that it could enhance the predictions of weather and hence flooding. It was even an interesting experiment to see if the ‘non-visual/camera’ light/proximity sensor combined with colour sensing capabilities would be able to work out if the clouds were looking grey and hence rain was likely - ideally verified by a change in barometric pressure (which it also has) as well as temperature and humidity. It would do this without being a privacy concern, as the optical sensor was not a camera per se.
So for basically £25 extra - this would have been a powerhouse of data for citizen science!
But there was a ‘spanner in the works’: The fundamental issue with the Arduino Nano 33 IoT board which was the ‘brains’ of our Flood Alert, is that it only has one Aerial - and although it can do WiFi *or* BLE, we were hoping to use it to connect to the Environmental Sensor board (Nano 33 IoT Sense), but we’d have to do one or the other, not both!
This was a frantic and somewhat naive sketch of mine when thinking about how to solve this with Pete Milne. One of the features of WiFi is that when it ‘drops’ or disconnects, it ‘tries again’ by listening out. If it reconnects the lost signal within a second or two, you’ll notice it doesn’t ask for you to formally reconnect again and input passwords, etc.
We wondered if we could deliberately use this design feature to our advantage, by dropping the WiFi signal for a split second, booting up the BLE signal, pinging the Environmental Board, the ENv Board would ‘wake’ from sleep when it was ‘pinged’, it would then transmit a tiny packet of the day’s environmental data to the Flood Alert main board, then go back to sleep, the BLE could be dropped, and the WiFI reconnected again - all within a second or two.
The Mickey Finn / Switcheroo
I temporarily, and in hindsight, perhaps regrettably, dubbed it “The Mickey Finn” - a somewhat macabre reference to when someone distracts someone, and then slips them a drug into their drink, to temporarily ‘knock them out’. My metaphor hopefully being less about heinous crimes, and more about the ‘sleight of hand’ needed to switch something without another party being aware, inserting a payload (in this case data), and then act as if nothing has happened - ie to do a Bluetooth data collect, without the WIFi realising it.
Long story short, Pete tried this, and it’s insanely hard, so we opted for having a ‘wired’ option, which means we could simply attach a 1-2 metre cable and pop it out of a window of suchlike. Not quite as fancy, but it’d suffice if we needed to in future.
I will henceforth redub it the ‘Switcharoo’ having more time to sanitise my metaphors for you, gentle reader’s unsullied disposition. I wish you no offence, but this is also why most engineers don’t show you their sketchbooks - they are troublesome things when the fever dreams of innovation have passed and sober reflection returns!
Image: AUX Port added to the design. ‘Blanked over’ and disabled for the pilot, but wired up internally, just in case we were to ship out an expansion pack - be it wired or BLE.
It’s Only Stupid - ‘Til It Ain't
The funny thing about this shaggy dog story of the ‘Switcharoo’, and why I shared it, is that often these ‘R&D Tales’ get edited out, because they didn’t work. I’ve naturally edited out many dead-ends and fruitless endeavours (lest this blog get any longer), but this particular exploration is especially interesting as Pete and me were testing the very limits of what current technology can do, and in doing so either seeing what in the short term is not worth the bother, but long term it may well be useful.
The one thing you learn as you progress in your career as an engineer, is that it’s not just about being smart, it’s tempered by the timing of other things. I cannot guarantee there will be a need for a ‘Switcharoo’ feature in most Edge IoT features, but in many ways, this is a rudimentary form or WPS, which if you didn’t know is the WiFi equivalent of Bluetooth’s ‘pairing’ mode…only it’s multi-modal, or double device, if you like. Not just at 1:1 connection.
What I find interesting is that we need the ease of being able to gather data with all these IoT / Edge IoT / Industrial IoT devices - and yet they also need to be much more secure, to avoid hacking or just breaches of privacy. As I mentioned the fact that this board (Rev 1) has a cryptographic encryption chip - fascinated me, and it’s slightly worrying perhaps that Arduino dropped it in Rev 2 (I think), perhaps I need to follow up on that, but either way - my point is that all these little innovations are still being resolved, and I think this is why people like Pete Milne and myself go down these Rabbit-Holes - as at a bare minimum you learn a lot, but potentially you could hit upon a really significant thing. I’m sceptical that we’ve discovered a new multi-devices WiFi/BLE switching standard, but one can see how nonetheless it will likely only have more necessity as our lives become more intertwined with sensors and other such auxiliary electronics. To some, this sounds dystopian and Big Brother-esque, but often the change is so gradual that we as humans normalise it. Most people will not consider that your Apple AirPods can also measure your body temperature, motion and possibly brain waves (in future) - and could potentially deduce if you’re sick, emotional, sleepy, menstruating, or any other variety of tiny biosignals, which combines with other accessories like smart phone and smart watches all combine to make some staggering inferences that are honestly quite mind-bending to understand. It’s only weird and crazy Sci-Fi until it isn’t…
Anyway, for now, we needed to refocus on V1.0, and see where that took us.
Onward to the ‘get it done’ Build Guide of the Flood Alert V1.0….!
Blog Series Contents:
Prologue - The Case for 'Hyper-Localisation' of Civic Data
Research & Development:
Part 1: Filling the Local Data Gap
Part 2: Civic Services & User Experience Research
Part 3: Ideation of Flood Alert Concept
Part 4: Prototyping Back-Story
Part 5: Citizen Science Learnings
Open Source Build Guide:
Part 6: Build Guide for 3D Printed Assembly
Part 7: DIY Decals for 3D Prints
Part 8: Code & Data Guide
Future Ambitions:
Part 9: Project Reboot with Machine Learning
Comments