Visit to HJ Andrew’s Experimental Forest

Author: Marissa Kwon


Abstract: 

On Thursday July 27th, members of the OPEnS Lab finally deployed a working prototype of the Evaporometer at the HJ Andrew’s Experimental Forest.  They were accompanied by Professor Bo Zhao, a member of his data visualization team, and coordinators at the HJ Andrews Forest as the receiver hub was set up at a station near the Discovery Trail and the Evaporometer-transmitter was drilled into a log overlooking a stream.

Installing the Hub:

The finished receiver is programmed to write data to a local SD card and upload info to an online google spreadsheet when an ethernet connection is available.  In addition to a reliable ethernet connection, the receiver requires an AC power source.  An existing weather station located just off the path of the discovery trail equipped with wifi and power was the perfect location to install our sensor.


The router providing internet service to the hub hooked up to the inside of the weather station.The router providing internet service to the hub hooked up to the inside of the weather station.

The router providing internet service to the hub hooked up to the inside of the weather station.


Our receiver hub connected to the power cables on the Discovery Trail weather station, recording transmissions from the Evaporometer.Our receiver hub connected to the power cables on the Discovery Trail weather station, recording transmissions from the Evaporometer.

Our receiver hub connected to the power cables on the Discovery Trail weather station, recording transmissions from the Evaporometer.


Walking through HJ Andrew's with the transmitter on debug mode, waiting for the loss of signal to be reported.Walking through HJ Andrew's with the transmitter on debug mode, waiting for the loss of signal to be reported.

Walking through HJ Andrew’s with the transmitter on debug mode, waiting for the loss of signal to be reported.

Deploying the Evaporometer:  

After the the receiver hub was installed the Evaporometer range was tested by placing the transmitter in debug mode and waiting for the signal to cut out.  After walking through the forest, it was estimated that the transmitter could be placed up to a quarter of a mile away from the hub.  The Evaporometer was reprogrammed off debug mode to transmit readings every 5 min.  Then the strain gauge attachment was primed with 500 ml of water over a 20 minute period by holding a slow drip device over the wick, according to protocol.  It was confirmed that data was uploading to our online spreadsheet and the visit to the forest was successful.


Using a smartphone to view data from our receiver hub, logged on a google spreadsheet.Using a smartphone to view data from our receiver hub, logged on a google spreadsheet.

Using a smartphone to view data from our receiver hub, logged on a google spreadsheet.


Lab members Tom Debell and Chet Udell mount the device above stream. Lab members Tom Debell and Chet Udell mount the device above stream. 

Lab members Tom Debell and Chet Udell mount the device above stream.


The Evaporometer collecting evaporation, temperature, light, and humidity changes over a stream.  As of 7/27/17 the Evaporometer is visible from OSU's Webcam:  HJA Flood Cam.The Evaporometer collecting evaporation, temperature, light, and humidity changes over a stream.  As of 7/27/17 the Evaporometer is visible from OSU's Webcam:  HJA Flood Cam.

The Evaporometer collecting evaporation, temperature, light, and humidity changes over a stream.  As of 7/27/17 the Evaporometer is visible from OSU’s Webcam: HJA Flood Cam.

– Marissa Kwon, URSA Engage and Summer REU Student Researcher

Prototype 2 Development

By: Alex Krejci

Abstract/Introduction
This light-weight, low-cost weather station is being designed as a solution for collecting weather data while the station is mounted to a temperature-sensing fiber optic cable that is suspended by a weather balloon. After mounting to the fiber, the station will be lifted into the air up to several hundred meters, where it will collect auxiliary data and corroborative data to support temperature, humidity, and wind speed data collected by the fiber. The station is designed to be low cost such that it could also be used for a variety of other weather monitoring applications.

Parts

  • Electronics
    • Teensy 3.2 microcontroller
    • SHT31 – Temperature and humidity sensor
    • BMP280 – Pressure sensor
    • IR led and receiver with LM358 op-amp comparator – wind speed
    • BNO055 – 3-axis orientation sensor as well as 9 dof imu
    • DS3231 – real-time clock
    • MicroSD port
    • RGB LED
    • Lithium polymer battery – 350 mAh
    • Custom PCB
  • Housing
    • 3D printed body and head
    • O-ring to seal from water
    • Propeller with housing for IR led and receiver
  • Mounting
    • 3D printed mounting clip to attach device to bearings
    • Thrust bearings with washers
    • 3D printed bearing support post
    • 3D printed fiber grippers
    • Wood frame to attach fiber grippers to bearing post

Measuring Capabilities
•    Temperature
•    Humidity
•    Pressure
•    Pitch, roll, yaw/wind direction – pitch tells us how much the head of the vane tips up or down so we can correct for the wind speed as this reduces wind cross section. Roll isn’t as critical, but is important to monitor for anomalous events. Yaw gives us the device orientation; this should be the same as the wind direction.
•    Acceleration, magnetic field, and angular velocity – The values are combined into a sensor fusion algorithm to give pitch, roll, and yaw. Recorded separately, they give us an idea of what is happening especially during anomalous events. The recorded data can’t be used to calculate pitch, roll, and yaw in post-processing as the recording frequency is lower than the in-situ sensor fusion algorithm update.
•    Wind Speed – using the propeller, we get an idea of wind speed. This will be combined with pitch measurements to correct for cross-sectional changes as the device will oscillate as it hangs on the fiber.

Housing Design
The housing for prototype 2 is composed of two parts, the body and the head. The body is where the electronics will be house. It has a large rear fin for orienting the device into the wind. The mounting clip is used with a 3D printed mounting bracket that allows the devices to hang from a thrust bearing assembly. The propeller mount post is where the propeller will hang below the station when assembled; this includes a hole for wires to run through. The head is easily removable and creates a water tight seal for the electronics as well as housing the battery. When the head is removed, you will have easy access to the SD memory card, an indicator light letting you know the status of the device, the battery connector for charging, and the microcontroller USB port for reprogramming. The bottom side has ventilation holes to allow airflow for the temperature, humidity, and pressure sensors that are all positioned just above the ventilation holes. The holes are also angled so that air can easily flow in from the front and out the back.


Electronics Design
The circuit design is shown below in breadboard view as well as the two sides of the PCB. Currently the circuit is built by printing a custom PCB and soldering the breakout boards for each chip onto our custom PCB. The wind speed sensor is shown as an IR led, IR receiver, and an op-amp comparator circuit. A teensy 3.2 with a Cortex M4 processors is used as the microcontroller.
All devices are chosen to run at 3.3V, and most devices communicate over I2C protocol. This limits the number of wires needed, and also makes it easy to add or swap out I2C parts.
The device is programmed to sleep between measurements to save on power. The orientation sensor, however, stays awake currently. Shutting it down will interfere with the calibration. And sleeping interferes with the orientation calculations that require constant input of data.



Operation
When operating, the station is turned on with a switch. The station undergoes a startup sequence with a color-coded Morse code sequence. Each device is checked for operation. If the morse code is green, the device is operation, if red, it is not. For example, the real-time clock is coded as the Morse letter r (dot dash dot). If a red light is flashed in this pattern, the clock has a problem, if green, it is good. Blue lights indicate some other status.
If all green lights occur, then the device is ready to calibrate. The BNO055 is calibrated by going through a sequence of steps. First, the device should be left stable for ~5 seconds. This calibrates the gyroscope. Each time the gyro is started, it has a different offset value. Allowing the device to sit still lets the device determine the offset and correct future values.
Then, the device should be orientated with each of the six sides facing downward. Slowly wobble the downward face. The goal here is to let the sensor read the earth’s gravitational field on only one axis. It does this by finding the peak value of that axis as you wobble the downward face. Hold each axis downward for about 5 seconds.
Finally, the move the device in as many orientations as possible. This is often done by sweeping the device in a figure-8 pattern. If you do this will spinning around (an entertaining dance for sure), it will provide better results. As you do this, the device creates a map of the magnetic field that it measures on each of the sensor axes. It then calculates hard and soft iron corrections for the magnetometer. This is usually the most difficult sensor to calibrate, and calibration often changes as the device is left out. This can be done for ~60 seconds.
When the device collects a data point, it flashes the indicator LED before collection (short flash) and when storing (long) the data. If the light is green, the device was calibrated during the previous reading. If the flash is red, the device was not completely calibrated.
The station will collect data at a pre-programmed time interval and store the data on an SD card. It is powered using a 350 mAh lithium polymer battery, giving a battery life of 15 hours.  When done, the SD card can be removed and the data uploaded to your computer.

Developing an altitude hold algorithm for a quadcopter

Author: Jonah Siekmann

For the past few months, the drone portion of the RFID moisture project has been focused on the altitude hold algorithm of the drone flight controller as a sort of first step towards autonomy.

Abstract

Currently, the user is responsible for throttle, pitch, roll and yaw – in theory, altitude hold would remove the need for the user to moderate throttle while GPS navigation would remove the need for the other three. The user would just need to flip a switch on the remote control, and the drone would use a sonar sensor to determine the altitude from the ground. The sonar is mounted on a gimbal so that regardless of the drone’s orientation, it is always pointing at the ground.

Materials & Description

We constructed a gimbal from two digital servos and used an MPU 6050 to get positional data. We also used an HC-SR04 sonar sensor and arduino to process the data. Initially, the sonar sensor was located directly underneath two propellors, which resulted in propwash interfering with the sensor receiving pings. This meant the flight controller could go for seconds without a single reading indicating its position relative to the ground – an extremely unsafe predicament. It could have crashed or flown dozens of meters into the air in the meantime.

 Some online research revealed that the best place for a sonar sensor was in the exact center of the frame. So the drone’s battery, Arduino, and gimbal were removed and reassembled in a spot that allowed the gimbal to be in the center. The result looks like this:

This allowed for much more consistent readings. Afterward, the problem arose of using a PID controller that assumed a constant time interval to control drone altitude. Normally, a PID controller looks something like this.

  integral += error; //integrate errors by adding them together
  derivative = (error - prevError); //get derivative by finding difference
  prevError = error;
  output = KP * error + KI * integral + KD * derivative; //multiply by gains

And this worked fine for previous flight controllers that I’d written. However, this is because they used a constant loop time of exactly 4ms – meaning that the flight controller would poll sensors for new data exactly every 4ms.

However, in the case of a sonar sensor, the time it takes to get a reading depends on how far away an object is. If a drone is hovering 20 feet in the air, it can take around 40ms to get a ping back from the ground – an extremely long amount of time in computational terms. So instead, an interrupt subroutine was used as described in this instructable:

https://www.instructables.com/id/Asynchronously-Reading-the-HC-SR04-Sensor/

However, this meant that the time in between readings is not constant and can vary hugely. For a PID controller, this is a massive problem – say two readings are taken, the first at 3m and the second at 2m. If there is a one second difference between those readings, then they can be taken to mean that the drone is dropping at 1m/s and needs to be corrected immediately. If there is a ten second difference, it is only dropping at 0.1m/s and the correction should be a lot less forceful. However, the PID controller as above would consider both of these cases to be identical and react inappropriately.

Essentially, it’s necessary to take time into account when reading data from a sensor that does not provide readings at a constant rate. The resulting PID subroutine looks like this:

  int dt = micros() - timeOfLastExecution;
  timeOfLastExecution = micros();

  integral += error * dt; //multiply error by time interval since last reading
  derivative = (error - prevError)/dt; //divide rise over run - dY/dt
  prevError = error;
  output = KP * error + KI * integral + KD * derivative; //multiply by gains

Results

This steps described in this post allowed the altitude hold algorithm to be realized. Below is a video of a rough working version of the altitude hold algorithm – the PID values are not yet tuned. The throttle was not touched for the entirety of the following video after about 0:07 seconds – the only axes controlled were pitch and roll.

Data Logging Using The Ethernet Featherwing.

The Birth of The OPEnS HUB

Abstract

For the past several weeks the primary focus of myself and the other undergraduate researchers at the OPEnS Lab has been to get a working, deployable prototype of an Evaporometer (link here) sensor for use for a partner research group. This project required numerous data transmission protocols and untimely it is our hope to add remote data-logging capabilities using the Ethernet Feathering.  


Our Ethernet Featherwing Shield integrated with the Adafruit  FEATHER 32u4 RFM95   LoRa   Radio  board. Our Ethernet Featherwing Shield integrated with the Adafruit  FEATHER 32u4 RFM95   LoRa   Radio  board. 

Our Ethernet Featherwing Shield integrated with the Adafruit FEATHER 32u4 RFM95 LoRa Radio board. 

Objective

The goal of this project is to establish a means of remotely data logging sensor data to a google sheet via the Ethernet Featherwing shield and the third party cloud based API, PushingBox. For more on how to set up the google sheet and PushingBox service please see a previous project I did using the ESP8266 WIFI chip found here

Materials and Methods

The key components required for this project  were 1) the Ethernet FeatherWing Shield , 2) The Adafruit FEATHER 32u4 RFM95 LoRa Radio – 915 MHz (or Feather board of preference), 3) an authorized Ethernet port with access to the internet, 4) Ethernet cable, 5) Solder, Header pins, and basic electronic skills, 6) and of course a computer with the Arduino Integrated Development Environment (Latest Version downloadable here). 


Bare Ethernet Featherwing ShieldBare Ethernet Featherwing Shield

Bare Ethernet Featherwing Shield

 

More About the Featherwing

The Ethernet FeatherWing plugs into any Feather (all in one microcontroller made by Adafruit, more info here)  and adds hard-wired networking. To make it as cross-platform compatible as possible, the board is set up using SPI, plus one extra configurable pin. This Ethernet option allows for a strong reliable connection to the internet and can allow for fast, real-time updates via any wired access point. 

Results/Discussion

Preliminary testing of the Ethernet Featherwing showed promising results, however more testing and code modification will be needed in order to log data to google sheets using Domain Name Servers. However, below is some sample code used to determine if a connection has been made to the internet using Adafruit servers. 

  1. /*
  2. Web client
  3.  
  4. This sketch connects to a website (http://www.adafruit.com)
  5. using an Arduino Wiznet Ethernet shield/FeatherWing.
  6.  
  7. created 18 Dec 2009
  8. by David A. Mellis
  9. modified 7/14/2017
  10. by Tom DeBell, For use in the OPEnS Lab
  11.  
  12. */
  13.  
  14. #include <SPI.h>
  15. #include <Ethernet2.h>
  16.  
  17. // Enter a MAC address for your controller below.
  18. // Newer Ethernet shields have a MAC address printed on a sticker on the shield
  19. byte mac[] = { 0x(), 0x(), 0x(), 0x(), 0x(), 0x() };
  20. // if you don’t want to use DNS (and reduce your sketch size)
  21. // use the numeric IP instead of the name for the server:
  22. //IPAddress server(74,125,232,128); // numeric IP for Google (no DNS)
  23. #define URLHOST “www.adafruit.com” // name address for Adafruit (using DNS)
  24. #define URLPATH “/testwifi/index.html” // url to grab
  25.  
  26. // Set the static IP address to use if the DHCP fails to assign
  27. IPAddress ip(192, 168, 0, 177);
  28.  
  29. // Initialize the Ethernet client library
  30. // with the IP address and port of the server
  31. // that you want to connect to (port 80 is default for HTTP):
  32. EthernetClient client;
  33.  
  34. unsigned long lastConnectionTime = 0; // last time you connected to the server, in milliseconds
  35. const unsigned long postingInterval = 10L * 1000L; // delay between updates, in milliseconds
  36. // the “L” is needed to use long type numbers
  37.  
  38. //#define WIZ_RESET 9
  39.  
  40. #if defined(ESP8266)
  41. // default for ESPressif
  42. #define WIZ_CS 15
  43. #elif defined(ESP32)
  44. #define WIZ_CS 33
  45. #elif defined(ARDUINO_STM32_FEATHER)
  46. // default for WICED
  47. #define WIZ_CS PB4
  48. #elif defined(TEENSYDUINO)
  49. #define WIZ_CS 10
  50. #elif defined(ARDUINO_FEATHER52)
  51. #define WIZ_CS 11
  52. #else // default for 328p, 32u4 and m0
  53. #define WIZ_CS 10
  54. #endif
  55.  
  56.  
  57. void setup() {
  58. #if defined(WIZ_RESET)
  59. pinMode(WIZ_RESET, OUTPUT);
  60. digitalWrite(WIZ_RESET, HIGH);
  61. delay(100);
  62. digitalWrite(WIZ_RESET, LOW);
  63. delay(100);
  64. digitalWrite(WIZ_RESET, HIGH);
  65. #endif
  66.  
  67. #if !defined(ESP8266)
  68. while (!Serial); // wait for serial port to connect.
  69. #endif
  70.  
  71. // Open serial communications and wait for port to open:
  72. Serial.begin(115200);
  73. delay(1000);
  74. Serial.println(“\nHello! I am the Ethernet FeatherWing”);
  75.  
  76. Ethernet.init(WIZ_CS);
  77.  
  78. // give the ethernet module time to boot up:
  79. delay(1000);
  80.  
  81. // start the Ethernet connection:
  82. if (Ethernet.begin(mac) == 0) {
  83. Serial.println(“Failed to configure Ethernet using DHCP”);
  84. // no point in carrying on, so do nothing forevermore:
  85. // try to congifure using IP address instead of DHCP:
  86. Ethernet.begin(mac, ip);
  87. }
  88.  
  89. // print the Ethernet board/shield’s IP address:
  90. Serial.print(“My IP address: “);
  91. Serial.println(Ethernet.localIP());
  92. }
  93.  
  94. void loop() {
  95. // if there’s incoming data from the net connection.
  96. // send it out the serial port. This is for debugging
  97. // purposes only:
  98. if (client.available()) {
  99. char c = client.read();
  100. Serial.write(c);
  101. }
  102.  
  103. // if ten seconds have passed since your last connection,
  104. // then connect again and send data:
  105. if (millis() – lastConnectionTime > postingInterval) {
  106. httpRequest();
  107. }
  108.  
  109. }
  110.  
  111. // this method makes a HTTP connection to the server:
  112. void httpRequest() {
  113. // close any connection before send a new request.
  114. // This will free the socket on the WiFi shield
  115. client.stop();
  116.  
  117. // if there’s a successful connection:
  118. if (client.connect(URLHOST, 80)) {
  119. Serial.println(“connecting…”);
  120. // send the HTTP PUT request:
  121. client.println(“GET ” URLPATH ” HTTP/1.1″);
  122. client.println(“Host: ” URLHOST);
  123. client.println(“User-Agent: arduino-ethernet”);
  124. client.println(“Connection: close”);
  125. client.println();
  126.  
  127. // note the time that the connection was made:
  128. lastConnectionTime = millis();
  129. }
  130. else {
  131. // if you couldn’t make a connection:
  132. Serial.println(“connection failed”);
  133. }
  134. }

Below is a screenshot of what the Serial Monitor should print out fallowing a successful test.


Successful Internet Connection Test!Successful Internet Connection Test!

Successful Internet Connection Test!

Future of Project

More updates will be posted here once a connection to Google Sheets has been made. 

 

– Tom DeBell, Beginning/Continuing Researcher Support Program Researcher

Evaporimeter Deployment Outside OPEnS lab

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 consumptionThe Evaporimeter on its first test run - mainly for the purpose of debugging and monitoring battery consumption

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.&nbsp;&nbsp;Data on each line reads dev ID, timestamp, temperature, humidity, load cell, infrared light, full spectrum light, and battery voltage.A sample of data written to SD card - with NaN data and test data with timestamp and voltage.&nbsp;&nbsp;Data on each line reads dev ID, timestamp, temperature, humidity, load cell, infrared light, full spectrum light, and battery voltage.

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

The Evaporometer 2.0: Improvements After a Return from a Brief Vacation

Author: Marissa Kwon

ABSTRACT

It has been some time since any updates were posted on development of the Evaporimeter device designed to remotely transmit evaporation data via LoRa transmission to a central receiver and then to an internet hub.  There have been A LOT of changes – so many additions and revisions to the overall design that perhaps now it is best to introduce the Evaporimeter as an entirely new model with an expanded focus on reporting data for a multitude of environmental factors.

And now introducing the OPEnS Lab’s “newest” take on the remote sensing…

COMPONENTS

The aim of our transmitters is to become as powerful and “invisible” to the surrounding environment as possible.  To achieve this we have added and removed various components to make our sensors more efficient and send a wider range of data.  Here is a breakdown of all components attached to our new transmitter.


 - ADAFRUIT FEATHER 32u4 RFM95 LoRa Radio - 915 MHzThis new development board is roughly the same length and width of the ProTrinket, and comes with built-in LoRa transmission capabilities as well as a place to solder in a ufl connector.  The Feather also includes a portable battery attachment which we will be using for our power source 
3078-00-2.jpg

ADAFRUIT FEATHER 32u4 RFM95 LoRa Radio – 915 MHz

This new development board is roughly the same length and width of the ProTrinket, and comes with built-in LoRa transmission capabilities as well as a place to solder in a ufl connector.  The Feather also includes a portable battery attachment which we will be using for our power source



3013-01.jpg

ADAFRUIT DS3231 PRECISION RTC

This external “real time clock” breakout gives our transmitters the ability to enter sleep mode and awaken periodically to collect and transmit data.  While in sleep mode, the microprocessor’s routines are halted and the battery power is conserved.


 - ADAFRUIT SHT31-D Temp/Humidity SensorThis breakout allows our sensors to report back temperature (where 100 degrees F is signified by a 1) and humidity (as a percentage) values using I2C communication.  This breakout will be exposed to the outdoor environment through a small reinforced opening in the sensor housing.  
2857-04.jpg

ADAFRUIT SHT31-D Temp/Humidity Sensor

This breakout allows our sensors to report back temperature (where 100 degrees F is signified by a 1) and humidity (as a percentage) values using I2C communication.  This breakout will be exposed to the outdoor environment through a small reinforced opening in the sensor housing.


 - ADAFRUIT TSL2591 FULL/INFRARED SENSORThe TSL2591 has built in infrared and full spectrum diodes that allow it to separately measure infrared, full-spectrum, and visible light in three modes - simple, advanced, and API.  We will be using the advanced mode to simply report light intensity in the full and infrared spectrum.  As for visible light, we would like to add another RGB color sensor in the near future.  

ADAFRUIT TSL2591 FULL/INFRARED SENSOR

The TSL2591 has built in infrared and full spectrum diodes that allow it to separately measure infrared, full-spectrum, and visible light in three modes – simple, advanced, and API.  We will be using the advanced mode to simply report light intensity in the full and infrared spectrum.  As for visible light, we would like to add another RGB color sensor in the near future.


 - HX711 LOAD CELL and STRAIN GAUGEThis hasn't changed since the update and will be used to help measure evaporation by calculating the difference in the weight of the water in the catchment over time. 
next.png

HX711 LOAD CELL and STRAIN GAUGE

This hasn’t changed since the update and will be used to help measure evaporation by calculating the difference in the weight of the water in the catchment over time.

– Our battery was also replaced from 1000 mAh to a larger 2000 mAh one, allowing us to leave the sensors in the field undisturbed for a longer period of time.

More updates on the new transmitter and a discussion on our sensor’s potential use for wide range of studies to come.

Another post describing the results of field testing on the Evaporimeter equipped with RTC and sensors will be posted hopefully by the end of next week.

– Marissa Kwon URSA/Summer REU Student Researcher

Preparing Evaporometer for Andrew’s Cyber Forest Deployment

Author: Chet Udell


Evaporometer team meeting at OPEnS Lab. Bo Zhao (OSU GeoVisualization) and Chet Udell (Director, OPEnS) center holding Evaporometer transmitter node. Marissa Kwon and Manuel Lopez (far right) Evaporometer technical team. Shaozeng Zhang (front-right) from Anthropology plans to study the interplay of data, translation, mapping, and public engagement with this project.Evaporometer team meeting at OPEnS Lab. Bo Zhao (OSU GeoVisualization) and Chet Udell (Director, OPEnS) center holding Evaporometer transmitter node. Marissa Kwon and Manuel Lopez (far right) Evaporometer technical team. Shaozeng Zhang (front-right) from Anthropology plans to study the interplay of data, translation, mapping, and public engagement with this project.

Evaporometer team meeting at OPEnS Lab. Bo Zhao (OSU GeoVisualization) and Chet Udell (Director, OPEnS) center holding Evaporometer transmitter node. Marissa Kwon and Manuel Lopez (far right) Evaporometer technical team. Shaozeng Zhang (front-right) from Anthropology plans to study the interplay of data, translation, mapping, and public engagement with this project.

Abstract

The Evaporometer wireless star network system is weeks away from being prepared for the Andrew’s Cyber Forest! This post details the features and improvements leading up to the current state of the system.

Objectives

Bo Zhao (OSU GeoVisualization) and Chet Udell (Director, OPEnS) have teamed up to deploy a number of wireless environmental sensors in the Andrews Cyber Forest. The Evaporometer wireless star network currently consists of one receiver hub connected to the web and a group of sensor transmitter devices. Devices communicate through LoRa long-range low-power radios up to 20km line of sight. Data will be publicly accessible and visualized in realtime by Bo Zhao’s group.

Devices

Transmitter nodes consist of the following:

Hub consists of:

Method of use

Multiple Transmitter nodes will be distributed in a star network arrangement around the central hub. They will each transmit data from their sensors in 15min intervals. Receiver Hub will log each transmission onto a local micro SD card. It also uploads transmissions in near real-time onto a secure Google spreadsheet. Bo Zhao’s bots will dynamically pull data from this sheet for visualization.

Deployment will take place July 27.

OPEnSampler Update, Bertha

By: Chet Udell

Abstract

Our efforts over the past moths have culminated in a robust lab-tested prototype of the OPEnSampler we endearingly call “Bertha.” We’ve determined this will be our in-house lab prototype that we will use as a testing bed for integrating new features and hardware. Lessons learned experimenting with Bertha will directly translate into field-deployable OPEnSampler versions to be distributed for use. This post details the technical specifications of Bertha, features, Serial Commands, and use cases.

Technical Specs

  • Frame dimensions are 24in x 12in x 12in and made out of 40mmx40mm extrusion.
  • 2 12VDC Peristaltic pumps (250ml water pumped in 2min)
  • 24 250ml aluminum-lined Mylar bags (spout packs)
  • 25 12VDC valves (24 valves attached to bags, 25th valve is used as a system flush outlet valve)
  • Arduino Uno, Microprocessor
  • Custom PCB with TPIC power-shits registers for handling valve actuation
  • Motor driver board
  • High Precision, Temp-compensated Real-Time Clock, for microprocessor sleep/wake(sample) scheduling.
  • Mode switch toggles between Sampler operation modes: standard operation mode, serial command mode.
  • EEPROM saves configuration of sampler parameters (sample duration, flush duration, next valve to sample, etc).
  • Serial command set for configuring the sampler’s behavior out in the field and for sending discrete commands (puppet-string) to turn on/off discrete components of the sampler. e.g. turn pups on/off/reverse and open/close specified valves.
  • Power-save Sleep mode, for ling battery life in the field. At the moment, drawing 24 250ml samples should require just 1 Amp Hour of a 12VDC battery. In standard operation mode, sampler stands by in low-power sleep in between taking samples. In serial command mode, electronics remain awake and stand by for configuration commands from computer.

Modularity

In consultations with many different researchers hoping to use this OPENSampler, we identified that the technical specifications of the sampler will vary depending on the context of use. This includes: What kind of water source is being sampled, what is being tested or analyzed, and environmental conditions and considerations in the field. To this end, we decided to make a “core” system that would be extensible using attachments for particular deployment contexts. This architecture is not dissimilar with many vacuum cleaner systems, where the core remains immutable but changes utility based on the attachments used.

Packaging: The frame is designed to be dropped into a variety of different “packages” depending on the field requirements. In many instances, a waterproof duffle bag may suffice for carrying the device into back-country environments. Rigid stack-able boxes made from corrugated plastic may be desirable for other deployments. For field deployments requiring samples be temperature protected (from wither extreme heat or cold), dropping this into a rolling lockable travel cooler such as the Pelican 80qt Elite.

Use

Switch the sampler into “serial command mode.” Not required, but should be done for best practice. After programming the Uno over USB, you may either switch the sampler directly into standard operation mode or send serial commands to configure your sampler’s parameters. Switching modes back and fourth may be done at anytime. In operation mode, a sample cycle is initiated whenever the specified time has elapsed.

Each sample cycle consists of the following states:

  1. System Flush
  2. Sample Draw (in next bag in sequence)
  3. System Sleep/standby

Samples may be removed from the device without manually removing bags. This is achieved by switching the sampler into serial command mode and typing commands into the Arduino Serial Monitor window to draw samples out one by one in any desired order. See commands below. This process may be automated (and should be) using a program to send a sequence of timed commands. A sample python script can be found on the project GitHub site.

Sampler Configurable Parameters and Factory Defaults Are:

  • IsDaily = True (Take a sample either daily or at a set periodic rate throughout the day)
  • 8:00 (default daily time to take sample)
  • Sampler Duration = 100 seconds (takes 120 seconds to fill 250ml)
  • Flush Duration = 30 seconds (this will need to be set based on the length of tubing away from main sampler – longer tubing requires longer flush duration for full system purge)
  • Sample volume = 250 (in ml, this isn’t being used right now, but there in case features need in the future)
  • Sample Valve Number = 1 (next bag to draw sample into)
  • Sample Period = 3 (if the IsDaily flag is FALSE,

The above parameters may be changed at anytime by switching into Serial Command Mode. Parameters are saved in EEPROM and are preserved even if the sampler looses power. Sampler operation will proceed with the new configuration behavior when switched back into operation mode.

Serial Command Set

  • CLK, Checks the current RTC time, Hr:Min:Sec – useful for checking before using SA to set sample alarm
  • SAD (int)X (int)X, sets “Daily Sample Alarm” Hr:Mn to take samples daily at time. Uses 24hr format.
    ex: SAD 9 30 sets sample alarm to 9:30AM daily.
    ex: SAD 16 22 sets sample alarm to 4:22PM daily.
    Also sets Is_Daily flag for initialization if power-down restart, clears Is_Hourly flag
  • SAP (int)X, sets “Periodic Sample Alarm” to take samples at specified period duration in Min.
    ex: SAH 30 sets sample alarm to go off every 30min.
    ex: SAH 47 sets sample alarm to go off 47min.
  • FD (int)X, sets “Flush duration” period in ms, should be about 20sec, but will change with the length of tubing you use to get from sampler to water source
  • SD (int)X, sets “Sample Duration” time that pumps run water into each bag in milliseconds
    ** removed for this version : SV (int)X, sets “Sample Volume” in ml, a transform of Sample Duration, may not be 100% accurate, 2min per 250ml,
  • VN (int)X, Sets the next valve/bag to place sample. Sampler saves curent valve number during operation in EEPROM in case of power failure, it picks up where it left off. This ensures you can reset the valve count before each new deployment, or manually skip to next available bag should the sampler malfunction
  • RST, Full system “factory” reset – set default sample period, sample duration, reset vlve counter, writes defaults to EEPROM (over-wirghting previous settings)

Pupet-String Commands:

  • Vx (int)#, Turn valve on/off where x is valve number (starting at 1, V0 is flush valve). # is 1 for on (open) and 0 for off (close) example: V1 1 opens valve 1. V1 0 closes it.
  • M #, turn motor on/off and direction. #=0 for off, #=1 for draw water into sampler, #=-1 for draw water out of sampler    example: M 1 will begin drawing water into sampler.

From here, you may use Arduino IDE, Python, or other software to send timed sequences to sampler. For example: V0 1 followed by M 1will begin flush.  The sequence (press return where you see / ) V0 0 / V1 1 / M 1will disable flush and draw water into bag1
You could also make a “macro” or timed program in something like Python for drawing water out of the sampler sequentially into your analysis machine without removing bags! Example of this is on the project GitHub site.

Features to be integrated for Zurich Version

The Zurich version is underway, with frame being constructed out of much lighter 15mmx15mm extrusion. This will make the total sampler weight (without filled with water) about 10lbs!

Packaging: The frame is designed to be dropped into a variety of different “packages” depending on the field requirements. The package for Zurich is intended to be a waterproof duffle bag. However, for field deployments requiring samples be temperature protected (from wither extreme heat or cold),

Currently, all sampler status messages are reflected on the Arduino IDE Serial Monitor window when sampler is attached to host computer. We’re evaluating an OLED display that will show all status information during sampler operation.  There will also be a wake button for the display that will show the status of the sampler at anytime during its sleep cycle.

Features for future versions

One major issue is not knowing the operational status of your sampler when left out in the field. Instead of being forced to check in on the sampler in person, we plan to integrate a GSM extension for the core, which will send updates over texts or emails using any 2G SIM card.


System for Calibrating Dogbone RFID Moisture Sensors using Decagon 5TM Conductivity Sensor and I2C Communication

Author: Brett Stoddard

Hello  Everyone! 

This last week I’ve been working on getting a system to log data that I will use to calibrate the Smartrac Dogbone RFID moisture sensing tags in soil

Abstract and Objectives

This blog post describes a system to log data that I will use to calibrate the Smartrac Dogbone RFID moisture sensing tags in soil using a Decagon 5TM moisture sensor. The goal of this system is to log both 5TM’s electric permittivity readings (ε) alongside Dogbone’s moisture sensor levels over a long period of time to make a relationship and eventually properly calibrate the Dogbone tags to the current industry standard, dielectric permittivity. 

Using a 2GB SD card, this system will be able to record 82 million data points, more than enough for our system (each data point takes up around 26 bytes and 2*230/(26) = 82*106 ). The period that the measurements are taken at can be changed easily, but is currently set at 10 minutes which gives a solid resolution but is still small enough to analyze easily. Theoretically, measurements could be taken with a minimum period of 5 seconds. The logged data points will be saved as a CSV file because those can be read by Excel which will make analyzing data fairly trivial. 

Materials

Libraries

Description

After encountering a few problems, the system that I settled on was two Arduinos that would communicate over I2C. I was forced to do this because the “SDI Library” that is needed to communicate with the 5TM soil sensor I was using is incompatible with the “SoftwareSerial” that was critical for debugging and testing the code.

I2C communication was originally developed for and is usually used for multiple chips on the same embedded electronic system to communicate over the same bus. It’s useful for when tasks need to be split between multiple Arduinos. I2C is implemented in Arduino using the Wire library. For this situation, the slave Arduino was the one reading data from the TM5 sensor. The nice thing about I2C is that it is relatively trivial to add additional sensors to any sensors to a setup in case we want to make multiple readings at the same time. The code for implementing this setup was written by following this tutorial

One Arduino was set as a slave and read the data from the 5TM sensor. I followed Chet’s Decagon 5TM sensor guide to set this up. The master Arduino had the GPS logger, and RFID reader shields on it to record the values. The RFID reader shield uses pins 2 and 3; the GPS SD logger pins 13, SCL, and SCA; and I2C pins GND, A4 and A5 on the master Arduino. The 5TM sensor used pins 6, 5V, and GND; and I2C pins GND, A4 and A5 on the slave Arduino. The hardware diagram shown below illustrates this.


calibrator-diagram

The code for this system will be posted in the examples folder of my RFID Github library under the title “Calibrator example”.

Results

Last night, the first data set was collected using this setup over the course of 16 hours. Below is the graph (made in Excel) that shows the Dogbone moisture values (units not named) vs the 5TM conductivity measurements (dielectric permittivity, ε). There was a recorded R^2 value of .75 which means there was a moderately high correlation between the two. As one can see from the graph, over time the 5TM’s electron permittivity decreased slowly as the soil slowly dried out. Longer-term tests where the soil has time to go from saturated to dry will be key for properly calibrating the Dogbone tags to the current industry standard, dielectric permittivity.


The x-axis has units of number of 10 minute intervals

The x-axis has units of number of 10 minute intervals

Working with the “Internet” for the Internet of Agriculture

Abstract

WiFi Data Logging

For the last few weeks I have been working on using an Arduino Uno and a couple different ESP8266 WiFi modules for the purpose of  logging sensor data in real time to a Google sheet and develop a network Gateway for all of our sensor devices.

 


The  ESP8266  WiFi Module. The IOA's internet!&nbsp;The  ESP8266  WiFi Module. The IOA's internet!&nbsp;

The ESP8266 WiFi Module. The IOA’s internet! 


Hazzah!  Breakout board variation of the ESP8266 Chip which eliminates the need for wire wraps, external voltage regulation,&nbsp;&nbsp;and has expanded communication capabilities.&nbsp;Hazzah!  Breakout board variation of the ESP8266 Chip which eliminates the need for wire wraps, external voltage regulation,&nbsp;&nbsp;and has expanded communication capabilities.&nbsp;

Hazzah! Breakout board variation of the ESP8266 Chip which eliminates the need for wire wraps, external voltage regulation,  and has expanded communication capabilities. 

The ESP8266 WiFi Module is a self contained SOC with integrated TCP/IP protocol stack that can give any microcontroller access to a WiFi network. The ESP8266 is capable of either hosting an application or offloading all Wi-Fi networking functions from another application processor. This function is most important for this particular project and will be used as gateway to log data straight to the internet.

Methods

Working around Secure Connections

Google Forms requires a secured connection (SSL) but the Arduino (Or autonomous huzzah board) doesn’t have enough power/memory to create SSL connections. We will use a third party Application program interface, PushingBox to work around this. 

PushingBox API is really simple in concept and in practice.  To launch a “scenario” of notifications you can send an HTTP request . The only argument you should attach is the DeviceID (details on how to find this found below in a link) . This is the unique key that identify the scenario you want to launch. The DeviceID can be found on the Scenario Page.You can also put more arguments to define customs notifications text using your own variables which is what we will do to allow sensor data to be uploaded to a google sheet.

This allows PushingBox to confirm the secure connection needed for google to begin passing on data uploaded from the Arduino. All this in real time. A more indepth explanation of this process can be found in a Hackster.io tutorial found here

Setting up the Google sheet

Another important aspect of this project was to prepare the google spreadsheet for the data it is about to receive. This is done in a google G-script (similar to java) and the instructions on how to do this can be found here.  This step is a bit technical and requires some patience while working through.

Data, Links , Projects, and References

Wiring and other example projects the OPEnS lab has worked on  can be found here.


Original ESP8266 setup running through an Ardiuno Microcontroller.&nbsp;&nbsp;Original ESP8266 setup running through an Ardiuno Microcontroller.&nbsp;&nbsp;

Original ESP8266 setup running through an Ardiuno Microcontroller.  

***Important note***

If you are using the older ESP8266 chip it is important to have an external voltage regulator. (This problem was resolved in the Hazzah board which contains an internal voltage regulator)

On Arduino Uno, / Mega the 3.3V regulated output is able to supply 150 mA max. The ESP8266 draws up to 500 mA and could damage the Arduino.
Add a 3.3V Voltage regulator such as LM1117-3.3 to power the ESP.

A helpful diagram to reference can be found here. 


Hazzah Board being flashed using a FTDI cable&nbsp;Hazzah Board being flashed using a FTDI cable&nbsp;

Hazzah Board being flashed using a FTDI cable 

 

Note: On the Huzzah Breakout Board, the module must be put into bootloader mode described below before you can upload a sketch from the Arduino integrated development environment (IDE). 

  1. Hold down the GPIO0 button, the red LED will be lit
  2. While holding down GPIO0, click the RESET button
  3. Release RESET, then release GPIO0
  4. When you release the RESET button, the red LED will be lit dimly, this means its ready to bootloader

Then in the upload the sketch found here with the appropriate libraries found here.

Specifics on how the pinout and wiring differs for the Huzzah breakout board can be found on the adafruit site here

Conclusions and Results

After much frustration and hours of tweaking code for the ESP modules and G-Script,  I was successfully able to hardline pseudo data from the microcontroller, through the ESP module to Google sheets via the PushingBox API. This ability really opens up an expanded capability for our sensors that are in developed and will prove to be an integral part of the OPEnS lab remote sensing. 


Pseudo data from the Arduino was successfully pushed the the Gateway generated by The PushingBox API to Google SheetsPseudo data from the Arduino was successfully pushed the the Gateway generated by The PushingBox API to Google Sheets

Pseudo data from the Arduino was successfully pushed the the Gateway generated by The PushingBox API to Google Sheets

Extension of Work

The next step in this project is going to be integrating this data logging interface with data transmitted from the LaRo Radio module. This project will continue in the coming weeks in collaboration with Marissa Kwon.


Work on integrating the LoRa radio receiver and the Huzzah ESP8266.&nbsp;Work on integrating the LoRa radio receiver and the Huzzah ESP8266.&nbsp;

Work on integrating the LoRa radio receiver and the Huzzah ESP8266. 

– Tom DeBell, Beginning Researcher Support Program Researcher