This week, let's try something new: a virtual project.

The basic idea is to describe a possible (virtual) embedded systems project and to have the EmbeddedRelated community debate its design and implementation considerations. 

If you guys play along, your insights should make for a very fun and instructive thread.   

The Project

A few weeks ago, our water heater tank leaked in our basement.  Luckily, my wife noticed the leak quickly enough so there was no water damage.  We had the tank replaced.  Next time though, I'd rather not count on luck to detect a leak before it's too late.  I started looking for some embedded device that detect water on the floor and alarm/notify through sound, email and possibly text message (sms) and/or phone call.  I was able to find a few options.

Now, let's say that we would like to make our own device with the following key specs:

• Battery operated and the battery should last at least a year and ideally much longer.
• Should be able to connect to a WiFi network in the building for sending the email notifications
• The device should be as inexpensive as possible to produce

What is your take on:

• Which microcontrollers would you consider and why?
• What peripherals would be needed, which ones would you recommend?
• How would you proceed for prototyping?   (eval board?)
• Where would you buy the parts needed for the prototype?
• Main challenges envisioned?
• ...

I understand that we will be only scratching the surface here and if this was for a real project, many more considerations would have to be taken into account.  But let's see where this leads anyway.

To encourage the participation of many, $150 will be divided based on the number of thumbs-ups awarded by the community.

Thanks a lot for you participation!

#VirtualProject

In addition to the details provided in Geato's response, there are a few other design elements to keep in mind when making an IoT device with extremely long battery life. Also, I would highly recommend calculating out your theoretical power consumption and battery life before you start designing a board. Hope this is helpful!

1. System Level and Power

As Gaeto mentioned, the key is to ensure that the system is in deep sleep mode the majority of the time. This requires control over the MCU and wireless radio power states. 

While you can have two serparate MCUs, where an ultra-low power MCU like the MSP430 FRAM series (<1uA in RTC deep sleep) monitors the sensor and then powers on the rest of the system, this is likely overkill for this application.

Additionally, a critical component of ultra-low power systems is power managment. It is critical to choose a battery with low leakage current (your best bet will be a primary battery) and a regulator with low quescent current. When in deep sleep mode, the power system will often draw the largest percent of power.

I would recommend either 3 AA batteries since size is not a constraint or a Lithium Manganese primary battery (CP505050, 3000mAh). For the regulator, focus on choosing a low Iq and a low input voltage. The TPS62740 is one option having 360nA quiescent current, input range from 2.2V to 5.5V, and is not a BGA package. Be sure to choose your rail voltage to minimize the power consumption of the MCU and wireless radio as it changes based on voltage.

2. MCU and Wireless

As an alternative to the ESP family, the CC3220MOD from TI has 1 uA shutdown current and is readily available from standard suppliers. This has an dedicated ARM MCU for the wireless protocol which can be shut down, and an application MCU to facilitate low power operation. TI also provides many examples for working with this module.

3. Alternate Sensor Design

In addition to the design provided by Geato, one can use a capacitive sensor (essentially the same as a capacitive touch sensor) to detect water. It will not be as low power as Geato's solution, however the significantly fewer parts will be used easing implementation, debugging, and testing.

4. Direct Answers

Which microcontrollers would you consider and why?

I recommend the CC3220MOD from TI. You can use TI-RTOS or Amazon FreeRTOS to easily integrate with the cloud.

What peripherals would be needed, which ones would you recommend?

No specific peripherals are needed if Gaeto's circuit is used. The only peripheral needed is to support the water sensor. Keep it simple

How would you proceed for prototyping?   (eval board?)

Depending on budget, you can use the SimpleLink Wi-Fi CC3220SF Wireless Microcontroller LaunchPad for prototyping. Once you have a proof of concept, I would create a custom PCB. To keep things simple you can also create a Shield for the LaunchPad to minimize the amount of development required.

Where would you buy the parts needed for the prototype?

Mouser, Digi-Key, or the TI Store. Get the PCB from OSH Park and a stencil from OSH Stencils.

Main challenges envisioned?

See above. In addition to the aforementioned challenges, actually achieving a low level of power consumption when in sleep mode is non-trivial. You should set up an INA based current measurement system for measuring low-currents rather than using a DMM.

For the cloud infrastructure, you can use the AWS IoT service for a really simple way to receive notifications via text or email. It is surprisingly simple to setup and quite inexpensive.

There are a miriad of IOT devices out there that can do the job. On the lower cost side, there is the Photon / Electron, CHIP Pro, and ESP family like the ESP32. My focus would be on making the sensor tell the processor when to broacast a message

The key here is to keep Iq as low as possible which means putting the processor to sleep or powering it off. The ESP32 has an Iq of 5uA in deep sleep. My approach would be to have the water sensor wake the processor up (by wiggling one of it's GPIO pins) to broadcast a message rather than the processor polling a sensor periodically. This way the processor duty cycle is extremely low. You may still want to wake it up with a timer once a week / month to say "I am still here and my battery voltage is xx".

The circuit below uses 4000B series CMOS logic so it has a very low Iq. It drives a couple of nichrome or stainless wires with an AC coupled square wave to eliminate any net DC offset which will lead to accelerated corrosion in the presence of water. Once the probes see water, the square wave is passed through and rectified. The resulting logic change wiggles one of the GPIO pins and kicks the processor into action.

Any micro controller Arm cortex M0+ based or even AVR based will be enough for this kind of the product.

Peripherals wise serial interface like UART / SPI /I2C (every micro controller nowadays support multiple such channels). We can use one of such channels to interface with WiFi, (or we can uses ZigBee / Zewave, if such infrastructure is available) to communicate data alarms etc.

Since this is a battery driven remote sensing product, it should include battery management also along with this, which will keep track of the battery energy and should indicate the replacement of the battery, or else, if battery is dead, the product will fail to perform and we think every thing is ok, till we physically detect the leaking. An I2C/SM bus based battery management IC is very handy in such product.

This type of product is the one where there will be a lot of challenge in choosing a reliable low cost sensor. This will have issues off false alarms, which will be annoying. Also there is a possibility of sensor not detecting leakage at all after continuous usage after some time. A level sensor, clubbed with known information (like when the tank is being filled / or intentional usage) is to be integrated with the functionality aspect of the product.

Another pain point in this product is the range of wireless communication. Though many boards claim the distance of communication, it will be usually specified at line of sight, but in practical use it can never be used like that and the device has to communicate through walls ceiling / floor which will reduce the effective distance. Also the performance when battery is full cannot be considered be the same, as when the battery is nearly at the end of its capacity. It may so happen that battery end is detected but could not be communicated to the server. A continuous minutely or hourly heart beat can solve this problem but it will consume more battery.

Prototyping of this kind of product can be done using Arduino boards with interfacing WiFi (or other communication) board, hooking up sensors to ADC of the board, for prototyping you can use alkaline battery, and later we can optimize to Lithium coin cells. A robust protocol has to be used (either existing or evolved specific to this product) which include sensor information battery information, communication information in as small packet as possible.

Best Regards,

BV Ramesh.

I did the same projects twice, 9 and 7 years ago one is 2.4G based wireless network and most recent 868MHz based. If you want, tell me and I’ll give you a link where you can see it.. for States certification you will need slightly change an RF side, but that is easy.

Sensors: TI CC series, basically Msp430 + transiever 110x. Base station which serves multiple sensors devices and can do some user logic, sends SMS etc. this was an Msp430 but today i would better go with stm32

Sensor based on TI are reading adc data (and more) every 30/45seconds and sends that via 802.15.4 to the base, which later reacts on programmed hazards if any. I was calculated Sensor’s life as ~14 months from CR2450, however they live more than 18, closer to 24 months inside the houses.

As a significant issue is a base’s power consumption. In that particular projects it listens the air all the time, and current around 40mA. That last Li-Po accum to serve base approximately 24 hours only.

To detect leakage the simple method with ADC readings was used, as almost any water has a bit of salt in it.

Njoy

Howdy, I'd pick from the pool of well featured mass produced boards: Rasp Pi, Arduino, etc. To roll your own with the WiFi aspect alone is stupid, this wheel is round already.

From there, I'd go with an ADC for sense and a DAC for signal, when the sense correlates to signal above a threshold, "BEEP". Signal could be a low frequency triangle wave, very easy to generate.

I'd also power it from AC, with an ultracapacitor so it has time to notify on power outages too. To me the probability of a power outage and a water heater break is acceptably small. A wider market is the thunderstorm basement flooding issue, power outages associated are Much more likely. I'd address that with a Li-Ion reserve instead of the ultracap.

Will the sensor be placed on the floor?  Is the floor level?  What if it leaks where the sensor isn't?

The sensor should be placed in the drip pan of a hot water tank. That being said, the water will never be where the sensor is located until the leak becomes significant. (I am a devout follower of Murphy).

I have been thinking since my first post that a humidity sensor might be a better option. The sensor would adapt to background levels by developing a running average then if there is a "step change" of 2 standard deviations or more then wake up the processor. The humidity sensor should be situated at the top of the tank. Perhaps have the 2 sensors together would be a more robust solution.

... just thinking out loud ...

How about a relatively long wire that could cover a relatively large area in order to detect a leak where it is most likely to happen?

A long wire should work. You can also use a capacitive level sensor flipped on its side (or even in a spiral) to cover a wide area. This can be built with copper tape sandwiched between plastic laminating sheets to keep the entire system waterproof and safe from the elements over time. You don't want your sensors/wires corroding after a few months in a humid environment.

http://www.ti.com/lit/ug/tidu736a/tidu736a.pdf