CavAirLogger

A time-synchronized multi-sensor atmospheric in-cave monitoring system

Project Overview

One of the best ways to really understand if a cave "goes" is to feel the air. Just move a rock and a blast of cold air came out of the earth? The cave is probably really big. However, this doesn't really tell you how to get from where you're at to big passages.

This air movement generally comes from changes in atmosphere between the underground environment and what's going on topside. A big weather front moving in can either make the cave suck air in or blow air out. When this happens, tracing where the air is going to (or coming from) in the cave can help tell you where the going passage might be. However, it can be hard to feel this.

This project aims to build a set of small time-synchronized weather stations to be placed in the cave and run during one of these weather events. By looking at slight changes in temperature, humidity, or pressure we might be able to tell where the most likely leads are in the cave.

The final product should be a small, low-power microcontroller, sensors for temperature, pressure, and humidity, an SD card for data logging, and a battery system capable of lasting several days.

Challenges

Most weather sensors have a fairly high resolution, but do they all match up against each other? Do they all respond in the same linear fashion when changes occur? While the precision and resolution of these sensors might be the same, they may not all be accurate, or even providing similar readings for other reasons.

The first step of this project is to build an array of weather sensors and compare their outputs over time to determine if the sensors will track with each other. If the output of these sensors is consistent to each other, then we will be able to start monitoring the minute changes in conditions in a cave.

One aspect of this system that warrants further study is the usage of CO2 sensors in these logging devices. The working theory is that CO2 is formed from below - from water off-gassing from an aquifer. It pools in the lower cave passages in some caves. If a weather event occurs such that the cave "breathes out" it should, in theory, start expelling this slug of CO2 out the main exits of the cave. This would be a great way to track where the cave goes, but these CO2 sensors can be a bit pricey - $20 or so compared to just a few bucks per breakout module for the other sensors we currently plan to use. At a scale of 10-20 stations, we want to do at least some planning for cost. For now, we'll focus on getting an array of basic sensors working.

Design

These devices are not meant for human usage. The goal is to go to various parts of a cave, place the device, turn it on, then let it go for a long time - up to several days - to catch a weather front moving through. As such, we won't need a display or other indicators on the unit, other than power and "recording data." We won't need complicated menus or buttons. This greatly reduces the amount of code necessary, as well as the power requirements and fragility of the system. A simple red LED blinking slowly to indicate data is being collected will do great, and the smaller the better so we don't potentially upset some of the local cave fauna.

Architectire

What parts to use?

During the investigation phase of this project, the following parts were considered.

Part Id	Part Name	Cost (each)	Accuracy	Current (mA)	Production Status	Available in Breakout	Notes
BMP180	Temperature/Pressure	$6	Temp: 1.0 - 1.5 Pres: 1 hPa	0.012	Obsolete	Yes
BMP280	Temperature/Pressure	$7	Temp: 0.5 - 1.0 Pres: 1 hPa	0.0027	Current	Yes
BMP390	Temperature/Pressure	$10	Temp: 0.5 Pres: 0.5 hPa	0.0032	Current	Yes
BME680	Temperature/Pressure + Gas	$20	Temp: 1.0 Pres: 1.0 hPa	0.15	Current	Yes
HDC1080	Temperature/Humidity	$7	Temp: 0.2 Hum: 2% RH	0.0013	Current	No	No breakouts easily available
HDC2080	Temperature/Humidity	$10	Temp: 0.2 Hum: 2% RH	0.0003	Current	No	No breakouts easily available
HDC3020	Temperature/Humidity	$12	Temp: 0.2 Hum: 1.0 - 1.5% RH	0.0007	Current	No	No breakouts easily available
HDC3022	Temperature/Humidity	$12	Temp: 0.2 Hum: 0.5 - 1.0% RH	0.0004	Current	No	No breakouts easily available
LM75	Temperature	$5	Temp: 2.0	0.28	Current	Yes	Lower Accuracy
DS18B20	Temperature	$7	Temp: 0.5	1.5	Current	Unnecessary	Cheap and small but one-wire interface
AHT10	Temperature/Humidity	$6	Temp: 0.3 Hum: 2% RH	0.98	Current	Yes	Limited to 20-80% Humidity (won't work in cave 100% atmosphere)
AHT20	Temperature/Humidity	$7	Temp: 0.3 Hum: 2% RH	0.98	Current	Yes
AHT21	Temperature/Humidity	$8	Temp: 0.3 Hum: 2% RH	0.98	Current	Yes	Same as AHT20 but with improved calibration and stability

For this project, the priority is making sure the sensor works in the environment (100% humidity) is available in a breakout (so prototyping and development is easier) and is relatively low power.

Part Choices

The parts that were selected:

• BMP280 - cheaper than the BMP390 with similar specs
• AHT21 - easy interface and factory calibration

Both are available at amazon in small breakout modules

First Step is a Sensor Array

Because we're going to be measuring "local weather" at each station, then a key assumption of this project is "all the sensors measure the same". But...do they?

The first step of this project was to develop a test harness to determine how much each sensor would drift from another. Let the sensor run for a longer time and see how it compared to other sensors over time. If the sensor drifts too much, or there's too much noise, then we'll need to pick a new sensor.

This presents another challenge - how to get 8+ I2C busses on a microcontroller. While bit-banging the I2C lines is an option, it can be buggy and seems like a distraction to this experiment. Strong preference here would be to use 8 hardware driven I2C lines in order to basically eliminate any potential communicate issues.

Fortunately Texas Instruments makes a handy part - the TCA9548A - an I2C switch. This allows some external GPIO to select 1 of 8 I2C devices and then communicate with it directly. Using this method we can replicate having the equivalent of 8 weather stations connected to a single MCU and we can aggregate the data onto an SD card in a single CSV file. Handy!

RTC

One minor modification was necessary during development of the project. The RTC library to drive the DS3231 was hard-coded to use a particular I2C bus. The preference is to allow for selection of this bus, and to allow for (potentially) multiple clock devices to be used. A fork of the arduino library was created here to support different I2C busses and multiple devices.

Parts

Part Id	Part Name	Datasheet	Breakout Purchase Link
AVR128DA32	Microcontroller	Datasheet	Mouser
MicroSD	MicroSD Card Breakout		Amazon
DS3231	Real-Time Clock	Datasheet	Amazon
TCA9548A	I2C Expander	Datasheet	Amazon
AHT21	Temperature/Humidity	Datasheet	Amazon
BMP280	Temperature/Pressure	Datasheet	Amazon

Putting it all together

Assembling the system was straightforward. Code was deliberately built in a way such that sensors could be added/removed at will in case the array needed to be changed, new sensors added, etc.

static RTClock rtClock(&Wire, -1); static AHT21Sensor aht21a1(&Wire, 7); static AHT21Sensor aht21a2(&Wire, 6); static AHT21Sensor aht21a3(&Wire, 5); static AHT21Sensor aht21a4(&Wire, 4); static AHT21Sensor aht21a5(&Wire, 3); static AHT21Sensor aht21b1(&Wire1, 7); static AHT21Sensor aht21b2(&Wire1, 6); static AHT21Sensor aht21b3(&Wire1, 5); static AHT21Sensor aht21b4(&Wire1, 4); static AHT21Sensor aht21b5(&Wire1, 3); static BMP280Sensor bmp280a1(&Wire, 7); static BMP280Sensor bmp280a2(&Wire, 6); static BMP280Sensor bmp280a3(&Wire, 5); static BMP280Sensor bmp280a4(&Wire, 4); static BMP280Sensor bmp280a5(&Wire, 3); static BMP280Sensor bmp280b1(&Wire1, 7); static BMP280Sensor bmp280b2(&Wire1, 6); static BMP280Sensor bmp280b3(&Wire1, 5); static BMP280Sensor bmp280b4(&Wire1, 4); static BMP280Sensor bmp280b5(&Wire1, 3);

static Sensor* _sensors[NUM_SENSORS] = { &rtClock, &aht21a1, &aht21a2, &aht21a3, &aht21a4, &aht21a5, &aht21b1, &aht21b2, &aht21b3, &aht21b4, &aht21b5, &bmp280a1, &bmp280a2, &bmp280a3, &bmp280a4, &bmp280a5, &bmp280b1, &bmp280b2, &bmp280b3, &bmp280b4, &bmp280b5 };

void SensorCollection::process() { #if SENSOR_VERBOSE unsigned long startTime = micros(); #endif for(uint8_t i = 0; i < NUM_SENSORS; i++) { Sensor *thisSensor = sensors[i]; if (thisSensor == nullptr) continue; thisSensor->processPerFrame(); } #if SENSOR_VERBOSE unsigned long stopTime = micros(); unsigned long duration = stopTime - startTime; if(duration > 10000) { Serial.printf(F("Sensor Data Collection took %lf ms\r\n"), (double)duration / 1000.0); } #endif }

You can see from this code, both the wire interface (I2C bus 0 or 1) can be used, as well as the I2C Expander line used (-1 if wired directly, as the RTC is).

Test Results

The device was run for several hours by simply leaving the set of sensors alone in my office and recording data. Normal Texas spring temperature fluctuations in a room with a nearby window and overhead A/C vent measured by the array of AHT21 devices are shown here:

By itself, this isn't very interesting, other than to note that the "factory calibrated" sensors seem to have some obvious differences in calibration. Exploring user-calibration might be an option going forward.

Since we're going to have many independent weather stations in the cave and we want to make sure both the time and the data match, in order to expose minute differences in atmosphere over time, we need to look at "do the sensors drift apart over time." The best approach for this is to use sensor 1 as a baseline and adjust all other sensors by the average difference of the temperatures over time. (generate a list of differences between sensor X and sensor 1, then average this number, and apply this averaged number to offset the temperatures). This exposes "how much does each sensor drift from sensor 1".

The same approach was taken for the BMP280 data.

Referring back to our "temperature over time" graph, most of the drift seems to occur when there are swings in temperature. Once the temperature stabilizes, the sensors seem to stay fairly well aligned - both the AHT21 and BMP280 showed a general drift of +/- 0.05C during steady state (the middle chunk of this graph). This is likely good enough for our cave weather station analysis.

Finally, we'd like to understand "how well do the AHT21 and BMP280 temperatures compare." To do this, we took an average of all AHT21 and BMP280 temperatures at each data point. Then we built a list of differences at each of these data points. We used the average difference, and added this to the BMP280 sensor. This shows us "how much do the AHT21 and BMP280 sensors, in general, drift apart over time."

Once again, we see the greatest drift occur when the temperature is changing, but in general, we can get the sensors to agree to within 0.05C. That seems plenty.

Next Steps

• We'll need a way to synchronize all of the individual weather stations. Let's build a unity project that communicates with weather stations over serial using SLIP and can instruct them to "synchronize their watches" then watches for an IR flasher or signal drop to set clocks to a particular time.
• We would also like a way to normalize and calibrate temperatures in real-time - basically applying the excel average adjustments before the sensors are deployed, or applying user calibrations to each sensor. This will be challenging to do one at a time.
• The unity device would be handy for calibrating sensors and downloading data from each weather station, instead of pulling cards on each.
• Experiment with wind sensors - similar to a MAP sensor in a car that uses a hot wire and resistance to determine mass of air flowing into the engine. Purchased a breakout, let's get it to work. Detecting very small wind movements would be really awesome for this project but I'm unsure how well this would work in 100% humidity in a cave.