Author Archives: Cara Walter

Moving platform to Adafruit Feather M0

Posted on by

Author: Lars Larson

Taking it back to basics with the eGreenhouse package, reprogramming the sensor suite one component at a time to ensure a smooth transfer to the Feather.

Here’s the plan:

  • Adafruit Feather M0 Proto
  • Adalogger FeatherWing for saving sensor data to an SD card
  • OPEnS custom nRF PCB for communication with the HyperRail

Currently, the Feather saves data to the Adalogger successfully; running the lux sensor as a start. Moving on to the rest!

One notable stumbling block with the transfer between Arduino Uno and Adafruit Feather M0: SoftwareSerial is not supported by M0 –> must recreate serial communication via hardware serial. This is accomplished by setting up a Serial SERCOM, following this Adafruit tutorial: https://learn.adafruit.com/using-atsamd21-sercom-to-add-more-spi-i2c-serial-ports/creating-a-new-serial

More to follow,

Lars

Intro to the Project

Posted on by

By: Brett Stoddard

Thermal sap flow sensors were initially proposed in the paper [German paper] in [date of german paper] by [german paper author]. Since then, several key improvements have created a sensor that semi-popular amongst researchers. However, their current high price point has reduced adoption.

A good case study for the modern state of commercial thermal sap flow sensors is Dynagague. Their probe style sap flow sensor which costs around $300-500 for a single sensor and an additional cost of ~$400 for the datalogger.

By using a few tricks in the design, we at the OPEnS Lab in contribution with [Friend of Trees] hope to design a sap flow sensor that costs less an $100 to produce including labor (priced at $50/hour) that meets the same performance at Dynagague. I plan to do this by redesigning almost everything to incorporate modern SMT manufacturing techniques open sourced communication protocols.


Here is an image of the rough schematic for the build.Here is an image of the rough schematic for the build.

This is the BOM for the first draft design. The raw eagle design documents can be found at [https://github.com/stoddabr/sapflow/tree/master].

To open them you will have to download my parts library from [https://github.com/stoddabr/EaglePCB].

Entire Suite Working on the Uno

Posted on by

Author: Lars Larson

A successful Monday – got the entire sensor suite running properly.

One notable – and very easily preventable – issue that I ran into: I had wired the RTC into a ground rail that didn’t tie back to the Arduino’s ground.  Always double-check your grounds!  It’s easy to overlook, but it can cause a lot of confusing data problems.  A teachable moment, at least.

Moving forward:

Testing in the greenhouse begins this week.  I’ll replicate the previous study’s conditions as much as possible to see what kind of correlation we find.

Lars

Success on the Uno!

Posted on by

Author: Lars Larson

The CO2 sensor problems from earlier this week were due to a faulty breadboard which left insufficient current for the sensor.  After swapping the whole array to a new board, the CO2, temp, RH, and SD card are up and running.

Average values in the OPEnS Lab today:

CO2: 835 ppm, temp: 23˚C, RH: 45%

Next steps: coordinating with Elad to set up a more rigorous testing protocol, and wiring in the luminosity sensor when it arrives.

Preliminary Testing on the Uno

Posted on by

Hi all,

Sensor testing has begun.  I’ve wired up everything to match Elad’s configuration, excluding the problematic O2 sensor.  MicroSD, SHT31-D temp/RH, and DS3231 RTC are initializing successfully. However, the code is getting hung up on the K-30 CO2 sensor startup process.  I’ve isolated the CO2 sensor and will run test code on this sensor only.

Lars Larson

Beginning Researcher

eGreenhouse back online for 2018

Posted on by

Hi all, 

I’m Lars, ecological engineering student at Oregon State University, and I’ll be collaborating with Elad to push the eGreenhouse project forward.  

Next Steps:

  • Wire sensor suite and test previous code 
  • Port Arduino Uno code into Adafruit Feather (much smaller, lighter, more efficient)
  • Implement 2-way communication with the OPEnS Lab HyperRail for dynamic data 

Looking forward!

 

Lars Larson, Beginning Researcher

 

Sleeping Beauty; Low Power, RTC’s, and Sleeping Processors. – A guided walkthrough

Posted on by

By: Tom DeBell

Abstract

As our production of open source devices with a variety of sensors continues to roll out, it is of the utmost importance to try and make these devices as power efficient as possible in order to conserve battery life. The solution is simple, using a variety of adafruit and SparkFun libraries such a LowPower.h, RTClib and a custom RTClibExtended. However, the problem at hand is the compatibility and settle discrepancies between the processors we are using and how they interface with these libraries. This post will serve as a walkthrough on how to work with these power saving libraries with the latest 32u4 and M0 processor boards as well as integrating this logic into Arduino UNO projects.

Methods

I think the best place to start off is a diagram of what a template program using sleep functionality should look like. Below is flow chart of sorts of how your program should be set-up in order to follow the structure of the example code included with this guide.


Sleep-RTC Logic Diagram (1).jpgSleep-RTC Logic Diagram (1).jpg

*Important note, any delays or program functions should be contained within a conditional statement in the wake flag routine. *

Using Pin Interrupts

Often times the simplest way to conserve battery is to put the processor to “sleep” which causes the device to enter a lower power state where it is no longer constantly checking all peripherals or running any processes. However, the most common (and simplest) way to wake a processor is to specify an interrupt pin. An interrupt pin is a specified digital or analogue pin that is expecting an interrupt signal (typically rising or falling voltage). An interrupt is a signal that tells the processor to immediately stop what it is doing and handle some high priority processing, in our case WAKE UP! Below is a brief breakdown of the different syntax used to initialize an interrupt pin on the 32u4 and M0 Adafruit processors boards as well as a basic Arduino.

Arduino Uno

– use A0 pin as an interrupt (using attachInterrupt function as laid out in the code provided)

– Example Code:

32u4

– Use SleepWake32uPCINT

– Example Code:

M0

– Use SleepWakeMoInt

– Example code:

Using the DS3231 Real Time Clock to Send an interrupt signal

Note: There are two types of alarm styles (Wake up once daily, or after a certain elapsed time) included in the RTClibExtended library, Both are included in the linked sketches.

Arduino Uno

– use RCTSleepWakeUseIntA0

– Example Code:

32u4

– use SleepWake32u4RTCPCINT

–Example Code:

 M0

– use SleepWakeMoRTCInt

– Example Code:

Conclusion

After looking at three of the most common processor boards and how to establish Pin interrupts and RTC interrupts, this tutorial should greatly increase the power efficiency of our future projects.

Tom DeBell

Capstone: Project Features

Posted on by

By: Travis Whitehead

For the past two weeks, we have focused our efforts on drafting and revising a requirements specification for our capstone project (as it is required for all capstone projects). This document is available on GitHub in our project’s fork of the OPEnSampler repo, under the “capstone” branch.

Overall, there are two major components to what we will be delivering over the course of this project:

  1. An Android app (that we’re calling the OPEnSampler Companion app) that will be able to update OPEnSampler’s settings and control it directly.
  2. GSM functionality allowing the OPEnSampler device to send status updates and information to specified recipients.

Companion App:

The primary purpose of the OPEnSampler Companion app is to replace the need for a physically connected laptop. It will be used to easily read and adjust the settings on an OPEnSampler device, and it’ll be a big improvement in usability over the serial command set currently implemented.

The OPEnSampler Companion app will be able to…

  • Pair with the OPEnSampler device over Bluetooth Low Energy
  • View and update the device’s settings, such as timer mode (daily vs periodic), sample rate/timer length, sample size, etc.
  • “Puppet” the device, instructing it to open/close valves or enable/disable the pump in either direction.
  • Specify recipients of status updates.

The app we’re developing will be for Android devices. Unfortunately iOS support is out of scope for our capstone project, but that’s something others could take on down the road.

Status Updates:

Status updates will allow an OPEnSampler’s users to receive information about the device and know what it’s up to. Currently we’ve been planning on supporting email and SMS (text message) notifications, but email is the primary focus.

The OPEnSampler will notify users when a sample is collected, or when all samples are collected, and these notifications will include timestamps. Once the OPEnSampler supports measuring battery capacity, it will also warn users of low battery life. We’d also like to send information about environmental sensors included in the Sampler (like temperature).

The Companion App will be able to specify the recipients of status updates, but we’re still researching the limitations of how many users’ email addresses or phone numbers can be stored on the OPEnSampler’s EEPROM (persistent memory that stores the device’s settings). If this turns out to be a problem, we’re considering a variety of options:

  1. We could allow users to hard-code extra recipients into the program itself (making use of flash memory, which is much larger than EEPROM), with the caveat that users would have to re-upload the program whenever they wish to change these.
  2. We could expand the storage capacity of the OPEnSampler with an SD card (which could be useful for other reasons, like if we wanted to do logging).
  3. Users could simply maintain a mailing list of status update recipients, and store only the address for that list in EEPROM.

System for Testing RFID Tags’ Ability to Sense Humidity

Posted on by

Author: Brett Stoddard

Hello  Everyone! 

For the past few weeks, I’ve been further examining the RFID Dogbone Tags. This time I’m testing their capability as capacitive humidity sensors. This article describes the system I built to test them out.

Abstract and Objectives

This blog post describes a system to log data from multiple Smartrac Dogbone RFID moisture sensing tags in the air over the course of the day. The goal of this system is to log the Dogbone’s moisture sensor levels vs a DHT11 Humidity and Temperature sensor. After logging data for multiple day cycles, enough data should be present to tell if there is a relationship strong enough between the Dogbone’s measurements and the DHT11. Further testing would be warranted if such a relationship exists.

To measure multiple tags at once, this system incorporates a HyperRail prototype. The HyperRail’s details can be found distributed throughout this blog page on the OPEnS site.

Materials

Libraries

Description

 

Results

Over the weekend the system was run. It gathered some data, but not enough to make a sure prediction of whether the Dogbone tags can be used as humidity sensors. However, this is an example of what the code output should look like.

Values of RFID, Humidity, temp, EPC, time, f

What data should look like when opened in Excel

Known Issues

As of now, the SD card will only log data when the Arduino is plugged into both USB. This shouldn’t be necessary because it is already powered by Vin. This issue is probably a power supply limitation of my specific setup, however, I thought it was worth noting here.