Progress Update #2 – Arduino Datalogger
The goal of this project is to create a simple-yet-robust datalogger, capable of both real-time monitoring and remote data storage. Below are the main specifications:
- Hardware Requirements:
- Per-unit cost must be kept low; mandatorily under $150 (and preferably under $100) out-the-door, excluding installation costs.
- Units are to be designed to minimise installation costs by using existing, standard infrastructure where it exists.
- Software Requirements:
- Units must be monitorable in real-time, but also able to record the data either locally or remotely.
- The sensor must be easily field-deployable, requiring no special techniques (programming or electronic) to install.
- The datalogger must be compatible with a variety of sensors (temperature, humidity, noise, light level, etc.), up to 6 simultaneously, without firmware modification.
The datalogger proof-of-concept currently in design is based on an Arduino Uno with Ethernet and Power-Over-Ethernet add-ons. This hardware platform was chosen based on the simplicity of adding both digital and analog sensors and in communicating these results via ethernet.
This part of the proof-of-concept phase focused on communicating the raw sensor data over ethernet to a client computer. The ethernet implementation is based on the Web Server/Temp Sensor example found at Starting Electronics: http://startingelectronics.org/tutorials/arduino/ethernet-shield-web-server-tutorial/SD-card-IO/
The Arduino serves a simple webpage in response to an HTTP GET request which displays two gauges, one for temperature and one for noise, and then the webpage requests new data every 10 seconds via an XML GET request. The webpage itself is stored on the SD card. (The hardware is virtually unchanged from last time, with the exception of the addition of a debugging LED.)
One problem that I have encountered is one of firmware size. On paper, the firmware size is well under the Arduino’s limit; however, it appears that the webpage data read off of the SD card for transmission to the client is stored temporarily in unused memory of the same block as the firmware. If the firmware size is too large, the webpage will not open, failing with a “server stopped responding” error. This does not seem to affect the XML update requests, as once the webpage is loaded, the XML requests are filled happily, even if multiple clients are making the same request simultaneously. (The whole thing is even iOS compatible, providing that the webpage loads.)
Next step is to bench-test the proof-of-concept for one week to make sure that the Ethernet connection is stable. This consists of periodically checking whether the temperature sensor data matches adjacent alcohol thermometers and whether the noise sensor data is consistent with data from previous noise observations. The webpage is refreshed twice daily.