I'm struggling a bit with the power consumption on my wireless sensors (previously mentioned here).
I've chosen an C8051F912 as the MCU (extra 128 bytes needed for my OTA encryption scheme), but I can't seem to get the sleep mode down below 20uA. (That doesn't sound like a lot of power consumption, but it adds up when considering that I want the batteries to last years.)
So, I am taking a break from low power design to focus a bit on my base station. (For those coming into this blog entry cold, I am designing a Internet-ready home monitoring system with a focus on keeping track of independent elderly people, specifically those who are candidates for nursing homes but aren't quite ready for that transition yet.)
I've decided to approach the base station design from a post-implementation perspective: What would someone find if they did a teardown on my device?
Why come from this perspective? I would hope that what a savvy engineer would find the implementation sound and even respectable. So, why not base my design decisions on this point of view?
Now, I am not just talking about a hardware teardown, but a software one too. But, I won't get too wrapped up on how my code looks or how it is structured. I am more interested in interoperability: How does the software interface with the outside world -- in particular, the end user and the Internet.
Let me preface this with one of my primary design goals: Set and Forget.
This is not a system to be played with or to constantly probe from a web browser. The typical customer is a caretaker or adult child of an elderly person. This is about applying modern IoT technology to an old problem. But, this is not a Nest. This is about the kind of IoT (Internet of Things) that operates discreetly in the background of your life -- you just want to know when interesting things happen, otherwise it isn't on your daily radar.
I have said before that even the base station can host sensors, so for this particular teardown, we will look at a single use: Someone buys the basestation plus a water flood sensor to monitor their laundry room. This example isn't solely "elderly" oriented but does represent the case where someone would want a true "set and forget" sensor. (I won't cover "wireless sensor nodes" here, since while necessary, they are bound to a lot more hassle that I'll address later -- things like RF interference/jamming, etc.)
I am trying to bridge the world of industrial strength monitoring with the IoT. I expect the sensors to be "integrated" with the house. You will want to install them properly (mount them) and permanently. These are devices that should last for years. The mantra is that they "must work".
The water flood sensor is a good example of a "must work" sensor.
So, this is a long one. Feel free to jump ship here, otherwise, grab a cup of coffee, sit back and ... here we go:
ContentsThe water flood sensor is a pair of gold plated probes on a 2x4" plastic plate. The plate can either rest on the floor, be glued or attached to a baseboard with screws. Two thin wires connect it to the sensor node (in this case the base station). The base station can be mounted on the wall. It is about the size of a desk of cards. On the side are 6 screw terminals (for 4 sensors plus +DC and ground. The water flood sensor attaches to two one of the sensor screws and ground. The user is expected to use the full length of wires or to trim and strip them to a desired length. You can connects up to 4 water flood sensors if you want to place them strategically in a room (e.g. under the sink/tub, next to the water heater, etc).
(First critical question: Why screw terminals instead of modular connectors? Answer: This allows the user flexibility in where they mount the base station. It can be several feet away from the sensor. A module jack would fix the length of the wire. I am assuming either a professional installer or someone comfortable enough to run wires.)
The base station hosts 2 AA batteries for power failure backup (which should run a couple of weeks before needing to be replaced). Lithium or alkaline are recommended for maximum shelf life.
The base station is normally plugged in to an AC outlet (via a standard USB 5VDC power supply). Since the station uses Wi-Fi, it wouldn't run very long on batteries.
ConfigurationThe USB port is also used for "configuring" the base station. Once plugged in, it shows up a disk drive.
Then you go to the product website and enter data into a form.
You can associate a screw with a type of sensor (in this case a water flood sensor). You must also enter the SSID and password for your wi-fi router. Additionally, for notification, you must provide an email address. None of this data is retained by the website and is all done over https.
Once entered, this data is downloaded as a file. You must save the file (or drag it) to the attached base station. The LED will blink rapidly and if all goes well it will remain lit. A slow blink indicates an error.
Once installed and turned on, the base station contacts the wi-fi router and you are sent a "startup successful" email.
The base station will send you once per week "heartbeat" email to indicate that all is well. If you want check "on demand" you can send it email and it will respond with status.
If water is detected, you are sent email.
That's it. Set and forget.
There are 4 phillips head screws holding the unit together. The case is UL94-5VA flame rated. Two flanged holes support mounting the enclosure to the wall. When mounted, the battery compartment flush against the wall. This is a light form of security to prevent someone from taking the batteries out.
The screw terminals are side mounted. There is a small recessed reset button on the bottom of the enclosure.
Inside there is a small circuit board hosting the three main components: A TI C3000 Wi-fi module, a Nordic nRF24L01P low power RF transceiver (for wireless sensor nodes) and a C8051F381 USB MCU. The Wi-Fi modules is tethered to an antenna that traverses the inside edge of the enclosure. The screw terminals are connected via ESD protection diodes to the MCU.
(But, why an 8-bit MCU? Why not an ARM Cortex? The C8051F381 is essentially an SoC. There are very few outside components needed. Panoptes uses the internal precision oscillator, so there isn't even an external crystal. There is a built in 5VDC-in regulator and USB support. And, for what the system does, an 8-bit is adequate. Plus, the fewer the parts, the simpler the design.)
There is a small piezo buzzer mounted over a small hole piercing the front of the enclosure. A small red LED next to it pulses every few seconds. This is to indicate that the unit is on and connected. If it cannot connect to the wi-fi router or cannot reach the Internet, the LED blinks rapidly.
Measuring power consumption of the unit shows that it consumes around 105mA when idle (not sending a notification) and peaks at about 250mA, briefly,when sending notification. Most of this current is due to the Wi-Fi module. The 105mA suggests that the base station maintains a connection to the Internet at all times.
Pouring water upon the floor (thereby triggering the sensor) cause the unit to beep loudly and send a notification email. After 10 minutes the beeping stops and the unit awaits to be reset. It blinks rapidly red during this time. You can cease the alarm by pressing (and holding for 3 seconds), the reset button on the bottom of the enclosure.
If the AC power is pulled from the base station (e.g. a power outage), the unit falls back to the battery, sends an alert email, powers down wi-fi and beeps for 5 seconds. The base station is still fully functional, but is expected to only last a few days without AC power.
The current measures steady at around 500uA at this point. Any water sensing event will cause both the beeping alarm and an attempt to send an email notice (in case the wi-fi router itself is battery backed). Every 2 minutes the station beeps to remind anyone near by that the unit is battery powered.
Pressing and holding reset at this point will cease the beeping but the alert capability remains.
The base station is connected 24x7 to a server running in the "cloud". This connection is via TLS/SSL and it is the cloud host that sends notification emails. Why not send email directly? The cloud server ensures mail delivery (caching and doing multiple delivery attempts as needed). Plus, for sensors that need correlation outside of simple alerts, the cloud server does all of the logic and interfacing.
Email is used as the primary notification (and status query) mechanism due to its ubiquitousness. Email is everywhere and doesn't require any special software to be loaded on your PC or smartphone.
No software updates are pushed to the device. Nor can the device be remotely controlled. It is a monitoring sensor. This IoT base station is one way.
Panoptes is designed to be a part of your house. It isn't sexy, but it is indeed a player in the IoT. Outside of 802.11b/g and TLS/SSL , it is bound to no particular Internet standard that may go away in the near future. You can use it with low power RF based sensors or simply standalone with up to 4 wired sensors.
Despite the low BOM, Panoptes is a high quality product designed to last. At $100 per base station, $10 - $20 per wireless sensor, and $2 per month cloud based subscription, it is a worthy investment considering the repair costs of house flooding.
The only thing missing seems to be Zigbee support. But, until low cost wireless sensors are offered in the Zigbee space, the nRF24L01P is adequate.
Thanks for reading!
EDIT: Looking seriously into the Kinetis K20 again as the base station MCU. I could use a little extra help with the Internet protocol side of things and the 8-bitter suffers there.
EDIT2: The TI CC3000 Wi-Fi module has an OTA configuration scheme called SmartLink. This rids me of the need for USB support as I can configure the AP and password over the air. I still need to figure out how to send email address and other config stuff, but I should be able to do that over the air too.