CrawlSpaceSensor

Project CrawlSpaceSensor
File:Whyunoimage.png
Sensor inside crawl space
Status	Initializing
Contact	bertrik
Last Update	2017-04-23

Introduction

This is a project idea for monitoring the crawl space under a house for water ingress. Basically looking for a nice use case to try out these miniature LIDAR sensors that are now available cheaply (about E8,-).

This things monitors the crawl space for the following properties:

• water level (in case it is flooded), using a VL53L0X lidar sensor
• humidity and temperature using a DHT11 or DHT22

Measurement data is uploaded once an hour over WiFi to an MQTT server.

Since there is likely no mains power easily available in a crawl space, it is battery operated.

Design

The plan is to use an ESP8266 to read the sensors, connect to the house WiFi and upload the measurement data once an hour. When not measuring, the ESP8266 is in deep-sleep mode (something like 80 uA current). Time-of-day is retrieved using (S)NTP.

Hardware

• ESP8266 in a Wemos D1 mini board, because they're so easy to use
• LiFePO4 battery, because they have about the right voltage for direct drive and are safe to use
• VL53L0X LIDAR module to accurately measure the water level
• DHT11 or DHT22 to measure humidity and temperature

VL53L0X LIDAR

This module integrates a VCSEL laser, a photo diode, probably some analog circuitry and a small microcontroller to do digital processing. It has an I2C interface, but it seems you need a library from ST to get an actual meaningful distance out of it.

I'm not actually sure how it works exactly, it measures the time-of-flight between light sent out by the laser and received back through the photo diode. Apparently it involves averaging a lot of individual measurements, since the API manual mentions:

 "Increasing the timing budget increases the range measurement accuracy. That is: x N on timing budget => standard deviation / square root of N. For example is the timing budget is increased by a factor of x 2, then the range measurement standard deviation decreases by square root of 2."

Taking a measurement after reset requires a couple of initialisation steps, the user manual for the library API is so verbose about these steps that it's actually getting confusing which steps you really need to do.

The API describes basically three ranging profiles with impact on the time required to do one measurement:

• high accuracy
• high speed
• long range.

I plan to use the high accuracy mode since measurement time is not very important (doing only one measurement per hour and the run-time is already dominated by other tasks).

The documentation appears to be very careful in avoiding claims about accuracy of the ranging measurement. This could be because there are a lot of factors involved, like temperature, cover glass, calibration, target characteristics, etc. The API user manual indicates the following settings for high accuracy mode:

• a "signal rate" of 0.25 (I guess this is a measure for the amplitude of the laser return signal)
• a "sigma" of 18 mm
• a measurement timing budget of 200 ms

I think the accuracy can be further improved, e.g. by increasing the measurement time. According to the remark mentioned earlier, I expect that doubling the accuracy requires four times the measurement time

Using a cover glass on top of the sensor makes things more complicated, so I plan to not use a cover glass.

Software

Measurement cycle

Software tasks in one measurement cycle are: (estimated run-time)

• wake up from deep sleep (1.0s)
• connect and authenticate to the WiFi (3.0s)
• perform an SNTP request to get the current date/time (1.0s)
• perform a distance measurement using the LIDAR (3.0s)
• perform temperature/humidity measurement (1.0s)
• publish measurements to MQTT (1.0s)
• calculate sleep time until next wakeup and enter deep-sleep (0.0s)

Total about 10 seconds per measurement cycle.

Initially, when no WiFi network is known, the sensor starts its own access point presenting a captive portal allowing a WiFi network to be selected.

Battery Life

A typical LiFePO4 "AA" type battery has 700 mAh capacity.

Sleep current is estimated to be about 0.10 mA total (about 80 uA for the ESP8266 in deep-sleep, about 5 uA for the VL53L0X in HW standby mode).

When awake, current consumption is estimated to take 100 mA on average for 10 seconds. This means each measurement takes about 0.28 mAh.

So, over one measurement cycle of one hour, we consume about 0.10 mAh in sleep-current and about 0.28 mAh in run-current, for a total of about 0.38 mAh. With a 700 mAh battery this would allow about 1800 measurements, making the battery last about 76 days.