ERU2 – Winter 2015: Chris’ Proposal

Sensor Datalogger with Real-time remote monitoring

Goal:

The goal of this project is to develop a simple-yet-robust sensor datalogger. Below are the main specifications and the identified preferred solutions to meet them.

  1. Hardware Requirements:
    1. Per-unit cost must be kept low; mandatorily under $150 (and preferably under $100) out-the-door, excluding installation costs.
    2. Units are to be designed to minimise installation costs by using existing, standard infrastructure where it exists.
  2. Software Requirements:
    1. Units must be monitorable in real-time, but also able to record the data either locally or remotely.
    2. The sensor must be easily field-deployable, requiring no special techniques (programming or electronic) to install.
    3. The datalogger must be compatible with a variety of sensors (temperature, humidity, noise, light level, etc.), up to 6 simultaneously, without firmware modification.
  3. Preferred Solution:
    1. For the hardware base, the preferred solution is an Ethernet-enabled Arduino board (either an Arduino Uno with an Ethernet Shield or an Arduino Ethernet, which combines the functionality of both aforementioned components on one board). Regardless of the particular variant of Arduino used, the Power-Over-Ethernet add-on will be installed.
      1. The Arduino is well-suited to this task, as it incorporates six on-board analog inputs, which many sensors require, has a small footprint, and is inexpensive, even with the addition of Ethernet functionality. Simplicity is also a consideration, as the Arduino’s on-board A-D converters remove the need for the external A-D converters needed by many other platforms.
      2. Wired Ethernet was chosen as the communication medium of choice since it is cheap, ubiquitous, and is (for the most part) configuration-free. Wireless Ethernet was considered, however, it was rejected due to the difficulty of properly authenticating any device in an enterprise environment, and the inherent unreliability of wireless signals in old construction or high-use environments. (Read: wireless is finicky).
      3. Wired Ethernet also allows power and data to be provisioned over one inexpensive cable, instead of requiring a separate power run, thus reducing installation costs. The increased cost of purchasing the PoE add-on for the Arduino and a PoE Ethernet switch are dwarfed by the expense of running new electrical outlets, especially in old construction.
      4. Both the Ethernet Shield and the Arduino Ethernet provide an on-board Micro SD slot, which can be used for configuration and storage purposes.
    2. For the software solution, as little processing done on the Arduino as possible. Data interpretation, other than the conversion of raw sensor data into a standard format (i.e. an 8-bit integer), should be done by the requesting machine. A standard firmware package will be uploaded into each Arduino, with the configuration of Ethernet and Sensors determined by config files on the SD Card.
      1. The rationale behind doing as little processing as possible on the Arduino as possible is simple: the Arduino has limited processing power, and tends to get bogged down if too many complex requests are received simultaneously. Doing little processing also allows the end-user greater flexibility in interpreting the data.
      2. The standard firmware package allows the sensor units to be field-deployable with little more than a standard laptop. The Ethernet components require certain data, such as IP and MAC addresses, that must be user-defined. Ordinarily, this data is incorporated into the firmware, but this means that each sensor unit must have custom firmware, making deployment and firmware updates labour-intensive and prone to mistakes. The config files allow this data to be set by a technician in the field without programming knowledge, perhaps using provisioning software. The same argument holds for the identification of sensors, with a sensor config file identifying the type of sensor and input number.
      3. Data will be passed from the sensor to the end-user via an XML get request and the return of a small XML file. The XML file will contain two pieces of data for each sensor: type and value. The “type” data will be compared to an array of sensor types to determine how the “value” data is to be interpreted. This communication scheme allows the device to be polled for real-time display and data storage without the device having to handle the requests differently.

Parts

For proof-of-concept and prototype:

2 – Arduino Uno

2 – Arduino Ethernet Shield w/POE

2 – 8GB Micro SD card

4 – LM35 Temperature sensors

2 – Adafruit MAX 4466 breakout boards w/Electret Microphone

2 – Solderless breadboard (small)

Assorted wire, jumpers, etc.

The sensors described above are example sensors only; any 0-+5V analog sensor or compatible digital sensor (such as those that use the OneWire Protocol) could be used.

For deployment, the Arduino Uno and Ethernet Shield w/PoE will be replaced with an Arduino Ethernet, and the solderless breadboard will be replaced with a printed circuit board.

Timeline:

A working proof-of-concept will be operational by March 20, 2015, to be followed by a one-week bench test.

The proof-of-concept will incorporate all major hardware components outlined in the scope, along with sufficient software components to test the functionality of the hardware.

Posted in Blog, Electronics for the Rest of Us! Tagged with:

Leave a Reply

Your email address will not be published. Required fields are marked *

*