Sensor Node: Engineering Diary
Why Develop Sensor Node?
The answer to that question is very easy. It needed to be done.
According to health statistics, on average 20 children die and 28,000 are hospitalized every year in New Zealand from preventable diseases like asthma, pneumonia and bronchiolitis. A great inspiration for this work, Dr Lance O Sullivan writes in his autobiography : “giving people a prescription for asthma or a skin infection and sending them home to run down cold damp houses is like pouring money in the ground. And a missed opportunity for improved health outcomes.”
In his book, Dr O Sullivan talks about families living in unhealthy homes. He writes that “a healthy environment is the most potent intervention we can give some of these families with recurrent illnesses. It’s fair to say that out of everything I could possibly achieve, creating warm, safe homes for children would be the most effective.”
Inspiration For the Social Entrepreneur
Engineering SPECIFICATION
As an engineer, I like to put things into engineering terms. For Sensor Node, our list of things we need to achieve looks something like this:
Low cost. It must be achievable for less than $100.
Very long range connectivity. We must be able to connect to a house anywhere in New Zealand without relying on WiFi or other private networks.
Battery powered and long battery life. It must not rely on a wall socket and once installed must be self sufficient for a few years.
Easy to use. Complexity is a barrier to usability. It must require no specialist knowledge to install, use and maintain.
Accurate. To make it suitable for a wider audience, it must achieve at least 0.5 deg C accuracy and 2% Relative humidity.
So long as we achieve these core objectives, we will be in a position to determine whether a home is going to make people sick; perform impact assessments following interventions; and we will have a tool to contribute towards scientific research.
How good is Good enough?
The first rule of product design is stick to the specification! But the real danger for engineers is not under-delivering: it’s over-delivering. You should always keep in mind the question: “how good is good enough?” If you loose track of this, before you know it you’ve designed a $5,000 wrist watch, or a car that goes 300 kph, or another insane razor contraption with 8 blades on it. Engineers just can’t help it! Features that no one needs, or understands how to use.
I’m a firm believer in the Pareto Principal. Or the 80 / 20 rule. The idea is that you get about 80% of the benefit from about 20% of the cost or effort. To put into engineering terms, I’d define the benefit as the specification (the list of things we like). The engineer’s job is to minimise the down side, which is usually the cost.
And the best way to do this is to create a specification and stick to it. Change it if you like, just don’t get sucked into designing fancy features that no one asked for. Always keep in mind, “how good is good enough?” Don’t be tempted to spend hours optimising something beyond the point where it significantly improves the outcome.
Delivering the Goods
With the specification in mind, let’s have a look at a few aspects of the technical design:
Front End Sensor.
The Communications Protocol.
The Mechanical Design.
The Electronics.
The App and Cloud solution.
Front End
We can measure pretty much anything. And there’s a very good chance someone has already done it! Water flow, electrical current, air Pressure, CO2... You name it: you can buy a sensor for it, off the shelf.
But remember that we want to measure the bare minimum that we need to achieve our goal. In this case temperature and humidity. We could add a carbon dioxide sensor, but immediately our current consumption goes up six-fold. And our cost more than doubles. It’s a perfect example of reaching for another 10% of functionality, but at disproportionate cost. So, let’s not do that! Temperature and Humidity it is. Done!
Communication Protocol
When we go to choose the communications protocol, there are a number of trade-offs to consider. We have range / power consumption / data rate / cost / latency / ease of integration. If we focus our minds on what we absolutely need and no more, we can see that we need Long Range; Low Power and Low Cost. We don’t really need Low Latency; High Data Rates or Easy Integration, although ease of integration is a bit of a given these days, since virtually everything is a piece of cake to build. If you can’t buy a module or an integrated circuit for it, its probably not worth doing!
Range Versus Data Rate
So to achieve long range and low power (which goes hand in hand with low data rate), our best bet is Sigfox.
Mechanical Design
Since the mechanical design has virtually no impact on the quality of the data, I’m going to skip to the end and say, do whatever you like. I’m about 80% sure that no one cares. And that’s the 80% I’m interested in. Do the cheapest, easiest thing you can. The first batches are 3D printed. As soon as we reach higher volume production, we will move to injection molding.
Electronics
We need a low cost, low power … blah blah blah. Sorry, I can’t hear anything past this, because in the world of embedded microcontroller design, low cost, low power is synonymous with the Texas Instruments MSP430. So we’ll use one of those. They cost about a dollar, and they do everything we need without using any power at all. Moving on.
App and Cloud Solution
This is where it gets tricky. I would say that it has to be scalable. And possible to deploy and maintain ideally by a single developer. Based on those basic criteria, let’s go with AWS. It’s relatively easy to use, even for a complete novice, and it will scale way beyond anything I’ve got in mind. I’d say in terms of the 80 / 20 principal, there’s no point looking any further. You might be able to argue the case for Azure, in which case, use Azure. But it doesn’t really matter. Choose one. And get stuck in. Just don’t use both. That would be wasteful!
Outcome
Sensor Node achieves all of the specifications listed above. We plan to start selling it for $100 each, $80 at volumes of 200 units, $60 at volumes of 1,000. And offer further volumes discounts should demand exceed this.
We can reach over 95% of New Zealand homes.
Sensor Node will run for 3+ years on two AAA batteries.
The accuracy of the device is +/-0.2 deg C and +/-2% relative humidity (0 - 100 %).
Conclusion
Sensor Node as it stands forms a good basis for a Minimum Viable Product (MVP). We have focused on the 80%. Not the 20%. We want good enough, not perfection. The next steps will be continuous improvement and looking to provide custom integrations for larger business end users.