Monthly Archives: November 2017

ETA Attachment

Posted on by

Abstract:  I’ve bee working on the ETA attachment and here is an update on what it looks like and where the design will go next. 

Objective: The ETA is designed to hold the two light sensors and one humidity/temp sensor. The two light sensors will make the albedo measuring system, so one has to be looking up and one straight down. The humidity/temp sensor is going right under the light sensor that is looking straight up. 

Methods: I’ve been using Fusion 360 to do the CAD and I will be 3D printing on the Fusion3 F400.

Results:

Here is the attachment piece from the sensors to the hub of the electronics. This has a slide mechanism that makes it easily detachable. This piece has to be put in first before the cap because the caps actually functions as a lock for this piece, it keeps it from sliding out in case that something bumps it. 

This is a preliminary look at what the ETA will end up looking like. This rendering is still missing the disks that will be holding the two light sensors and the humidity/temp sensor. I had to do some redesign on the base to be able to accommodate the extruding piece of the ETA attachment, but I think that this piece is solid design and I can now move on to design in the bases for the sensors. 

The bases, which will look like little disks, will hold the sensors. The one that will go on the 360 swivel will hold a light sensor on top and the humidity/temp sensor underneath. The other disk will go on the underside of the swivel, it will only hold a light sensor. 

 

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.

Power Pulse Controllers Done!

Posted on by

Abstract: The Power Pulse Controller project has come to a conclusion. All three PPC’s have been made! Final testing is the next step to get them ready for use. 

Methods: N/A

Results: 

The following image displays a finished Power Pulse Controller. We sold one to Columbia University and have two in stock. I will get in contact with Jim Wagner to verify all the connections and test the units to make sure that they are ready.


Fully assembled Power Pulse ControllerFully assembled Power Pulse Controller

Fully assembled Power Pulse Controller


20171101_100329.jpg20171101_100329.jpg

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.