Author: Marissa Kwon
ABSTRACT
This post is dedicated to our testing results and a few comments about why the Evaporimeter’s first test took so long to complete!
OVERCOMING OBSTACLES
The Evaporimeter on its first test run – mainly for the purpose of debugging and monitoring battery consumption
Ambitious First Testing: While the basic Evaporimeter was fitted with a transmitter and load cell long ago in previous posts, this fairly simple (in C language) task left plenty of room for other functions to be added to our micro controller’s memory. For quite some time new sensors and features to better our transmitter just kept coming, causing our Evaporimeter to evolve into more of a multipurpose climate sensor. To have the best first testing experience, we decided to implement those components to collect useful data about the environment and save battery that eventually made it into our final design.
“It Was Just Working Yesterday…”: Prior to testing on Thursday, temperature and humidity data was printing as NaN. We made sure this was not due to a coding error or a broken sensor and determined the problem was with a faulty I2C connection. This issue was fixed by switching out the wire wrapped connections with female wire connectors.
TESTING DETAILS
On Thursday 7/13 and Friday 7/14 the Evaporimeter was placed outside and set to record data from 9 am to – 5 pm. The receiver was left inside connected to an SD card writer, but for this test no data was recorded online.
We programmed alarms to occur every five minutes, so the timestamps below should show data collection at 5 min intervals. Data to the SD card reads dev ID, timestamp, temperature, humidity, load cell, infrared light, full spectrum light, and battery voltage. Data from the transmitter is sent as a string separated by commas in a way that is compatible with online google spreadsheets, the final destination for our data once the Evaporimeter is deployed in HJ Andrew’s Experimental Forest.
We placed the Evaporimeter outside with a fully charged battery (at 4.2 volts) we could see how the voltage dropped gradually over the course of a few hours while time stamps could indicate exactly how much time the Evaporimter could run before the battery is cut off (approaching 3.2 volts). Roughly .2-.3 volts were lost over 24 hour’s time with data being sent at 5 min intervals. By calculating the total amount of cycles that can be completed with these values, we can safely estimate that the battery would last anywhere from 1.3 – 2 months when data is transmitted on an hourly basis.
A sample of data written to SD card – with NaN data and test data with timestamp and voltage. Data on each line reads dev ID, timestamp, temperature, humidity, load cell, infrared light, full spectrum light, and battery voltage.
Note: We continued to double check and tweak parts of the Evaporimeter during the test on 7/13 explaining the timestamps jumping from 9 – 9:35 and 9:35 – 11:20 at the beginning.
Editor’s note: After reviewing the data written from our SD card it was evident that closer to .2-.3 volts was being used per day and the first estimation was overly optimistic. This information was overlooked at first due to the transmitter being off for quite some time on 7/14/17, and more accurate battery life estimations have replaced the incorrect information below:
[Roughly .2 volts was lost over the course of two days when the transmitter runs continuously waking at 5 min intervals – giving the battery a maximum of 10 days to run if fully charged. With these values the microcontroller can enter and wake from sleep mode 288 times before the battery drops 0.1 volt. With hourly alarms and we can reasonably estimate the battery will last a few months].
– Marissa Kwon, Summer REU Student Researcher