In the Spring of 2011, CCAT decided to revisit an old priority that had never been fully implemented: The collection of data and various metrics that would help us measure how we're doing on several sustainability or self-sufficiency related fronts:
- Electricity generation (through our PV system, currently)
- Electricity consumption
- Solar hot water temperature
- Natural gas consumption
- Wood consumption for our wood-burning stove
- Greywater quality (TSS, BOD)
- Tap water quality (health hazards)
- Water consumption
- Garden productivity
- Compost production
- Indoor air quality
Some of the data will be automatically collected through sensors and devices. Other data will require recurring human readings.
The goal is to make this data easily accessible to everyone -- employees, Co-Directors, students, and the whole world -- for analysis and education.
Real-time digital data collection[edit | edit source]
At the heart of the digital portion of our project is a proprietary data logger, a CR1000 by Campbell Scientific. It measures the input from modular sensors, processes it internally, and saves the results to its internal memory.
When we first started the project, the logger was only used to monitor our solar hot water system. Our engineering technician had to connect to it manually once a month to download its stored data tables.
We wanted to make the logger automatically upload its data in real-time, but we wanted to do it as inexpensively and with as little waste as possible.
Challenges we encountered[edit | edit source]
- Campbell Scientific wanted to charge $300+ for a serial-to-ethernet adapter and another several hundred dollars for software that would publish the data to the web. We tinkered with the logger for a few hours and realized that it had a terminal mode. We decided to buy a really long serial cable for $10 and write a simple Java program using an open-source library from the Arduino project (called Processing) to communicate with the logger in this mode and parse its output into a text file, bypassing the proprietary solution altogether.
- The terminal mode was intermittently unstable. We could not understand why the data logger would sometimes respond and sometimes not. With some trial-and-error and lucky guesses, we realized it simply had a very short time-out (3-5 seconds) between commands. We made our program poll more frequently (every second or so) and re-send the initialization sequence (5-6 carriage returns in quick succession) whenever the logger stopped responding. This appeared to work, but time will tell if it's stable over longer periods of time.
