Picking the Right Feather for You

Abstract- The 32u4 or the M0

As our projects continue to evolve alongside with the advances of technology it is important to keep the OPEnS lab up to date with the latest and greatest prototyping technologies at our disposal. There is no example greater than that of the microprocessor. This post will explore two of the most advanced, widely available microprocessors on the market today.

Background and Objective

Since 2010 the Arduino Uno has been the standard in prototyping electronics due to its wide variety of functions, ease of programming, and cost. However, much like any other piece of technology it is becoming outdated by faster, smaller and cheaper microprocessors such as the pro-trinket model released in 2014. (A previous article I wrote linked here highlights the key advantages of the Trinket over the Uno.) Fast forward to early 2016 to the release of adafruits most current line of development microcontrollers, called “Feathers” with a host of companion shields referred to as “Featherwings“, where these processor boards now come integrated with certain features such as WiFi connectivity, Bluetooth, LoRa radio and Shields that allow for RTC data logging, Ethernet connectivity and various display interfaces. The Objective of this article is to discuss the two major types of processors used within the Feather line of microprocessors.

Materials and Methods

Featherwing 32u4 v.s Featherwing M0

Which is best? Well, it depends on a host of things. To begin let’s start with a side by side comparison with specs, cost and common troubleshooting problems that I and others in the maker community have encountered. Differences I found especially imporant are denoted with an *.

At the Feather 32u4’s heart is at ATmega32u4 clocked at 8 MHz and at 3.3V logic, a chip setup that has long been tried and tested. This chip has 32K of flash and 2K of RAM and is very comparable of that of a basic Arduino Uno (excluding the use of EEPROM memory).

At the Feather M0’s heart is an ATSAMD21G18 ARM Cortex M0 processor, clocked at 48 MHz and at 3.3V logic, the same one used in the new Arduino Zero. This chip has a whopping 256K of FLASH (8x more than the Atmega328 or 32u4) and 32K of RAM (16x as much)!



Programming with the M0: The Basics Proto

  • Cost: 19.95 from Adafruit (Price equivalent only on Basic Proto Model)
  • Measures 2.0″ x 0.9″ x 0.28″ (51mm x 23mm x 8mm) without headers soldered in
  • Light as a (large?) feather – 4.6 grams
  • ATSAMD21G18 @ 48MHz with 3.3V logic/power*
  • 256KB of FLASH + 32KB of RAM*
  • 32.768 KHz crystal for clock generation & RTC
  • 3.3V regulator with 500mA peak current output
  • You also get tons of pins – 20 GPIO pins
  • Hardware Serial, hardware I2C, hardware SPI support
  • PWM outputs on all pins
  • 6 x 12-bit analog inputs
  • 1 x 10-bit analog ouput (DAC)
  • Built in 100mA lipoly charger with charging status indicator LED
  • Higher sustained current draw to processor*
  • Power/enable pin
  • Reset button

Programming with the 32u4: The Basic proto  

  • Cost: 19.95 from Adafruit
  • Measures 2.0″ x 0.9″ x 0.28″ (51mm x 23mm x 8mm) without headers soldered in
  • Light as a (large?) feather – 4.8 grams
  • ATmega32u4 @ 8MHz with 3.3V logic/power*
  • 32K of flash and 2K of RAM*
  • 3.3V regulator with 500mA peak current output
  • You also get tons of pins – 20 GPIO pins
  • Hardware Serial, hardware I2C, hardware SPI support
  • 7 x PWM pins
  • 10 x analog inputs (one is used to measure the battery voltage)
  • Built in 100mA lipoly charger with charging status indicator LED
  • Pin #13 red LED for general purpose blinking
  • Power/enable pin
  • 4 mounting holes
  • Reset button
  • Long Battery Life*

From a purely technical perspective, it is clear that the ATSAMD21G18 ARM Cortex M0 processor is a superior processor in nearly every regard. However, running such a robust processor comes at the cost of power consumption which is likely an important factor in the design of whatever project you are looking at.

Ease of use and support

While specs are an important aspect to consider when selecting which type of feather you are going to work with another key component is the technical support available for the device. Like any new piece of technology, these adafruit products are not without their pitfalls, manly in the support of preexisting header libraries. I have found in my personal experience that the 32u4 model of the feather which uses an older processor found in many Arduino products has much more firmware support and has the ability to repurpose existing Arduino sketches much easier than with the M0.

The ATSAMD21G18 ARM Cortex M0 processor is much newer and more robust, which comes with the issue of not YET having support for many of adafruit and Arduino libraries. However, if your project doesn’t rely on interfacing with pre-existing technology or have dependencies on the old software you will probably be fine.


In short, if you are doing projects that otherwise would have been prototyped on a device like an Arduino that doesn’t require a lot of processing power or large complicated scripts and battery consumption is of importance, the best choice would be the Feather32u4.

For more sophisticated projects that don’t require a lot of external dependencies, and for those with a strong background in computer and microprocessor programming, the feather m0 with ATSAMD21G18 ARM Cortex is a workhorse that allows for some pretty sophisticated programming with an abundance of memory and processor speeds.

Troubleshooting Some Common Problems

I “did something” and now when I plug in the Feather, it doesn’t show up as a device anymore so I cant upload to it or fix it…

No problem! You can ‘repair’ a bad code upload easily. Note that this can happen if you set a watchdog timer or sleep mode that stops USB, or any sketch that ‘crashes’ your Feather

  1. Turn on verbose upload in the Arduino IDE preferences
  2. Plug in feather 32u4/M0, it won’t show up as a COM/serial port that’s ok
  3. Open up the Blink example (Examples->Basics->Blink)
  4. Select the correct board in the Tools menu, e.g. Feather 32u4 or Feather M0 (check your board to make sure you have the right one selected!)
  5. Compile it (make sure that works)
  6. Click Upload to attempt to upload the code
  7. The IDE will print out a bunch of COM Ports as it tries to upload. During this time, double-click the reset button, you’ll see the red pulsing LED that tells you its now in bootloading mode
  8. The Feather will show up as the Bootloader COM/Serial port
  9. The IDE should see the bootloader COM/Serial port and upload properly

– Tom DeBell

Assembly Day 1



Azad and I spent part of the morning assembling the frame of the bottle-based OPEnSampler. I found quite a few changes I will make when assembling the next sampler. In the end we found the device didn’t quite fit in the duffle bag and so some machining will need to be done to reduce a couple dimensions.


The assembly of the frame was a simple but tedious process. There were only a few unique parts: two different lengths of 15mm square aluminum extrusion, aluminum brackets, M3 screws, and M3 square nuts. The aluminum extrusion was cut by the manufacturer to specified lengths to skip right to the assembly stage. Azad and I each assembled an end face and attached a long extrusion, though it would have been easier to attach all the long extrusions to one face first and then attach the other face afterwards.

We found that attaching all the brackets at once to an extrusion resulted in sliding and flopping brackets while joining the opposite end to the frame; I’ll be sure to write the instructions so that brackets are attached only when necessary to avoid headaches. If that was unclear, most of the problems can be summarized as not attaching brackets when we should have attached them. 

Fitting into the Bag:

Unfortunately I failed to dimension the frame to fit into the bag opening, which is slightly smaller than the bag space itself. Additionally, the height and length of the sampler were a bit too large to fit in the space anyways, so tomorrow I will have to disassemble the frame and head down to the machine shop to reduce a couple dimensions. Luckily it is easier to reduce the size of the device than to expand it, and there seems to be plenty of space for the bottles if I remove the ice tray from the design.


IMG_0214 2.JPGIMG_0214 2.JPG

CO2/O2 Summer Research Summary and Data

Author: Chet Udell

1.     Introduction

The spatial and temporal distributions of CO2 at the earth-atmosphere interface and at the boundary layer above it are of great importance for soil, agricultural and atmospheric changes. In general, the source of elevated CO2 concentrations at this boundary layer depends upon root respiration and soil microbial activity (Blagodatsky and Smith, 2012; Buchner et al., 2008; Nakadai et al., 2002).

Improvement of CO2 gas concentration detection could lead to a better understanding of the agricultural cycle and the transport mechanisms at this critical interface. Moreover, better monitoring methods to detect CO2 concentrations can provide improved modeling and decision-making to enhance agricultural productivity. Until recent years, the techniques for detecting CO2 concentrations included only stationary sensors that give close-range readings or the use of remote sensing platforms, which have limited accessibility due to their high costs and relatively low resolution (Toth and Jóźków, 2016). In addition, the use of remote gas sensing is usually inapplicable inside greenhouses.

The growing use of open open-source hardware (e.g., Arduino) for research purposes creates new opportunities to bridge the gap between CO2 detection at high resolution and affordability. In agriculture, the use of open-source hardware and sensors for CO2 gas sensing is still novel with little supporting research. However, recent research has revealed the possible applications of operating such gas sensing systems for agricultural purposes. For example, the use of an open-source gas sensing device to detect CO2 concentrations in a rectangular greenhouse (106 m × 47 m) was recently proven by Roldán et al. (2015). Using a low-cost electrochemical CO2 sensor, they provided a high-resolution CO2 concentration map inside a greenhouse. Their device also had temperature, relative humidity (RH) and luminosity sensors. All of the data from these sensors can be used for better greenhouse operation decision-making..

The aim of our research is to evaluate CO2 concentrations and dynamics using new CO2 (NDIR technology) and O2 (UV technology) sensors inside a greenhouse. We aim to integrate these gas sensors, together with temperature, RH, and luminosity sensors, on a single logging device to gain high spatial and temporal resolution of the greenhouse environment. In addition, we aim to make the device small and transportable to eventually deploy it on a drone or a rail system to get location-tagged data throughout the greenhouse.

2.     Materials and Methods

The sensors used in this project are detailed on Table. 1. All sensors were chosen according the following guidelines:

(1)  Sensor accuracy similar to that of a laboratory sensor. For example, the CO2 sensor should have the same accuracy range as other CO2 sensors that were reported in recent published studies.

(2)  Only off-the-self, open source sensors.

(3)  The sensor should be low-cost compared to other existing sensors.

(4)  Only sensors that are modular and light-weight, such that the complete system will be light-weight.

Table 1. Details of the device sensors. The “Name/Model” column includes links for each sensor’s web site. Total cost of sensors (without the optional GPS Logger Shield) was less than 300 $.

 [ coming soon ]

3.     Results and discussion

System integration included all the sensors detailed in Table. 1. Picture of the device and connection scheme are detailed in Fig. 1-A and B, respectively. Two power connections were tested: a 9V battery and a fix connection to wall power using a 9V adapter. The advantage of using the 9V battery is the mobility of the device; however it was sufficient only for ~5 hr when logging data at 5-min intervals.

Fig. 1.  Device description, (A) a photo of the device in the laboratory, (B) connection scheme of the different sensors.Fig. 1. Device description, (A) a photo of the device in the laboratory, (B) connection scheme of the different sensors.
To test the device, data was logged for six days in the laboratory (Fig. 2). Overall, measured parameters were as expected. During daytime the temperature was higher than nighttime with lower RH values. Correlation was observed between the working hours in the laboratory (08:00-17:00) and the peaks in luminosity and CO2 measurements. Once the first laboratory member entered the laboratory and turned on the light, we observed a corresponding increase in the luminosity sensor data. In addition, the CO2 in the laboratory air increased slowly due to laboratory member’s respiration, reaching almost 1,000 ppm. During Saturday and Sunday (8/12/17-8/13/17) the laboratory was closed, therefore luminosity decreased to zero and CO2 equaled atmospheric values (~400 ppm). O2 measurements were considered as problematic because of their high dependency on temperature. O2 concentrations range from 20.5% to 20.8%, however the oscillations were related to the temperature changes and not to changes in absolute values. Each time the laboratory air reached a minimum in temperature, O2 reached a maximum and vice-versa (Fig 3). Different attempts to calibrate the O2 sensor to the temperature were not successful, including using the ideal gas law(e.g., VAISALA, 2012) and talking with the manufacture (“CO2Meter”).

fig2.pngFig. 2. Time series results from six days in the laboratory.

fig3.pngFig. 3. Temperature effect on the O2 measurements.

Second deployment of the device was in an agricultural greenhouse located in Oregon State University, Corvallis, Oregon. The device was installed in the end of the greenhouse; ~5 m from the window and ventilation entrance (Fig. 4-B). To achieve reliable measurements, direct sunlight on the sensors was blocked using a cover installed 4 cm above the device. The cover was only above the device, such that air could freely circulate between the device and the surrounding greenhouse air. The only sensor that was exposed to direct sunlight was the luminosity sensor. Taking measurements in the shade is considered as standard procedure  (for more details, see the “American geoscience institute” website). Moreover, shade is essential for the CO2 sensor because this sensor uses infra-red technology (radiated heat energy); thus exposing it to direct sunlight will bias the measurements by changing the infra-red energy in the sensor.

Results from the greenhouse measurements are shown in Fig. 4-A. Temperature and RH had the same typical daily cycles as shown in the laboratory data. During daytime, air temperatures were higher with lower RH values compared to nighttime. We note that the Y-axis scales are different between the greenhouse and the laboratory because of higher diurnal cycles in the greenhouse (no AC was used). Luminosity sensor reached full saturation (40,000 lux) during daytime, which indicated direct sunlight inside the greenhouse.  Two reasons can explain the “noisy” luminosity readings shown in Fig. 4-A. First, the presence of clouds that temporarily decreased the light entering the greenhouse, and second, the fact that the device was measuring only at a single point below the plant leaves, thus the reading were subject to shade influence according to the angle between the sun and the leaves above the device. CO2 had a small diurnal changes in the scale of a few tens of ppm. These oscillations were within the sensor accuracy limit (± 30 ppm ± 3 % of measured values), and therefore cannot be observed using this sensor model. We note that the experimental greenhouse that was tested here was only with a low density of plants (i.e., number of plants per greenhouse area). In high-dense greenhouses, such as commercial tomato greenhouses, the overall photosynthesis will be much greater, causing  CO2 daily oscillations above 100 ppm and thus the CO2 sensor will be more relevant. O2 dependency on temperature was the same as in the case of the laboratory measurements and not because of actual changes of the O2 in the greenhouse air.

fig4.pngFig. 4. (A) Time series results from five days in the greenhouse, (B) a picture of the greenhouse taken from the entrance door.

We also tested the use of a GPS Logger Shield to get position readings inside the greenhouse. In this case, the shield replaced the real time clock and the microSD board. The accuracy of the GPS position is highly dependent on the greenhouse roof material. In our case, the position readings were not stable with maximum offset of 32 m compared to the true device position inside the greenhouse. Results of the GPS readings are shown in Fig. 5-A were each re point is a single position reading and the green point is the true device position. The number of satellites for each reading is shown in Fig. 5-B.

fig5.pngFig. 5. GPS experiment, (A) GPS positing readings from one fix position inside the greenhouse (green symbol marks the true position), (B) number of satellites in each reading.


4.     Summary

Integration of the different device sensors was successful and two 5-days measurement periods were conducted inside a laboratory and a greenhouse. Main conclusions at this stage are: (1) temperature, RH, and luminosity sensors were reliable and in the desired accuracy range, (2) problematic dependency of O2 sensor with temperature, (3) CO2 accuracy was not sufficient to measure the daily CO2 oscillations inside the experimental greenhouse.

We are now focusing to achieve the following objectives until the end of 2017: (1) improving the code for better power consumption; (2) validation of our CO2 sensor against a standard laboratory CO2 sensor that is frequently used in academic studies – IRGAs GMD-20 manufacture by Vaisala; (3) deploying the system on a drone or on a HyperRail device to obtain spatial greenhouse data and not only fix point measurements. The HyperRail is a low-cost rail system originally designed for moving a hyperspectral camera inside a greenhouse (additional information can be found in this link); (4) finalizing a short paper on the integration and deployment of the system in a greenhouse, which is now in preparation.

5.     References

Blagodatsky, S., Smith, P., 2012. Soil physics meets soil biology: Towards better mechanistic prediction of greenhouse gas emissions from soil. Soil Biol. Biochem. 47, 78–92. doi:10.1016/j.soilbio.2011.12.015

Buchner, J.S., Šimůnek, J., Lee, J., Rolston, D.E., Hopmans, J.W., King, A.P., Six, J., 2008. Evaluation of CO2 fluxes from an agricultural field using a process-based numerical model. J. Hydrol. 361, 131–143. doi:10.1016/j.jhydrol.2008.07.035

Nakadai, T., Yokozawa, M., Ikeda, H., Koizumi, H., 2002. Diurnal changes of carbon dioxide flux from bare soil in agricultural field in Japan. Appl. Soil Ecol. 19, 161–171. doi:10.1016/S0929-1393(01)00180-9

Roldán, J., Joossen, G., Sanz, D., del Cerro, J., Barrientos, A., 2015. Mini-UAV Based Sensory System for Measuring Environmental Variables in Greenhouses. Sensors 15, 3334–3350. doi:10.3390/s150203334

Toth, C., Jóźków, G., 2016. Remote sensing platforms and sensors: A survey. ISPRS J. Photogramm. Remote Sens. 115, 22–36. doi:10.1016/j.isprsjprs.2015.10.004

VAISALA, 2012. How to Measure Carbon Dioxide [WWW Document].

Investigating a Solenoid Valve’s Strong and Weak Orientations



We observed our $1 solenoid valves were failing under low pressure conditions. After some investigation and testing, we found we could safely orient the valves in  to ensure the flush valve will fail first while the sample valves will form quite strong seals when closed. This solution allows us to continue to use the cheaper valves and keep our cost of materials down.


Cost is a limiting factor when choosing components for the OPEnSampler. There are many repeat components, including the 24 sample containers, 52 compression fittings, 25 feet of tubing, 32 aluminum brackets, 16-20 pieces of aluminum extrusion, and 26 solenoid valves. Increasing the cost of any of these by several dollars would increase the total cost of materials by $100 to $200, depending on the component. We chose cheap $1 solenoid valves from AliExpress with this factor in mind, knowing the next best alternative were adafruit’s $7 solenoid valves. It turns out, however, that our $1 solenoid valves are quite weak and fail under normal use conditions due to the water pressure from the pump. Luckily, the solution was quite simple.


Solenoid valves open and close the flow of water with a linear actuator that pushes out or pulls in. In cheap normally-closed solenoids a spring holds the actuator out, pressing an o-ring against the face of the inlet as a seal. When current passes through the solenoid, the actuator pulls in against the spring and water is allowed to pass from inlet to outlet. The diagram below, taken from dyxminipumps.com, shows how our $1 valve’s inlet and outlet (openings A and B, respectively) are perpendicular to each other.

dyxpump diagramdyxpump diagram

Using A as the inlet and B as the outlet, the valve will fail under quite low pressures. This is because the actuator is only blocking flow because of the force of the small spring; a small pressure from a pump only has to surpass the force of the spring to force the actuator backwards, opening flow from A to B. Orienting flow in the reverse direction, however, yields different results. Any pressure applied from opening B acts perpendicular to the motion of the actuator, neither adding nor subtracting from its closing force. In this orientation the valve will stay closed under very high pressures and a pressure buildup will cause other components of the water line failing first, such as the tubing popping out of fittings. This is quite undesirable in the normal application of these valves, such as in coffee machines, but we can take advantage of the failure behavior of the two orientations for the OPEnSampler.

By directing flow in the sample valves from B to A they will stay closed in the event of a pressure buildup, maintaining the integrity of the samples by preventing cross contamination. If the flush valve is oriented opposite, from A to B, it will be the weakest point in the water line and will fail first, effectively becoming a pressure relief valve for the system so that the water is released out the drain before fittings break. 

This was tested in the lab by connecting the outlet of the pump directly to each of the valve’s openings in turn and running until failure. The pump ran for two minutes without valve failure while B was connected as the inlet and A the outlet, but failed after a few seconds in the A-B orientation.


The sample valves will be oriented with flow from B to A and the flush valve will be oriented A to B. By taking advantage of the failure conditions of each orientation we can continue to use the cheap $1 valves without worrying about their low-pressure rating. This not only reduces further design work and prototyping but also saves about $150 per unit compared to the $7/piece alternative.

An Update on the HyperRail


The last post was about getting the HyperRail working with basic code. I have now improved the coding to give the user more control. The user can now control RPM and I have added some other functions.


I intend to give an update on the programming of the HyperRail and new features the new code has.

Materials and Methods:

All was done using the Arduino IDE and all the code used for in this iteration can be found here.


Choosing a Peristaltic Pump


There are currently two pumps to choose from for the OPEnSampler: a low flow rate, unknown-precision peristaltic pump and a high flow rate, “low precision” pump. They have their pros and cons and this writeup will discuss the angles of attack for deciding which one is more appropriate for our system.


The WMC Pump has the following specs:

  • 12V DC 400mA
  • 297 mL/min flow rate, among other lower flow rate options
  • 5mm Viton Tubing, among other options
  • Barbed Fittings

The Honlite Pump has the following specs:

  • 12V DC 1.2A – 3.2A
  • 1100 +- 8% mL/min flow rate
  • Tygon Tubing, among other options
  • Compression fittings for 1/4” OD tubing, among other options



WMC Pump Head

The WMC pump has been tested on our prototype system and has proven to be reliable and true to its specs. It can reliably pump 250mL/min of water at zero net suction head, which is about three times as fast as our previous dual-pump system. Despite such an improvement, the flow rate is still quite low for attaining representative samples of suspended sediments, such as fine-grain sands [source]. A flow rate of 530+ mL/min is required to reach the EPA’s recommended 60 cm/s minimum line velocity for such sampling where the flow of the analyte heavily relies on the mass and specific gravity of the particulates [source]


Honlite Peristaltic PumpHonlite Peristaltic Pump

Honlite Peristaltic Pump

The Honlite pump from AliExpress has yet to be tested however the manufacturer supplies more specifications than the WMC pump. The defining characteristic of this pump is its 1100 mL/min flow rate at 12VDC, almost 4 times the rated flow rate of the WMC pump and twice the minimum recommended flow rate for sampling suspended solids. Some downsides are its high variance in flow rate of 8%, though further testing of the WMC pump could prove this is not an usual variance, and further testing of the Honlite pump could prove this variance is controllable. The pump head only has two rollers (three is standard) and so the rhythm of the pump could be noticeable, but will quite likely have a negligible effect on the sample quality.

One method of fixing the inconsistency of any pump used is to add a flow rate meter in series with the pump line. This flow rate meter can catch when the pump is struggling or increases its velocity significantly and adjust the PWM control of the pump driver chip, effectively increasing or decreasing the voltage supplied across the pump to account for the change in flow.


Both pumps cost around $65 (the Honlite pump costs $30 with $35 shipping to the US) so reliability and flow rate are the most significant factors. Neither pump states its maximum suction head, though almost all peristaltic pumps seem to have a maximum suction head greater than 5m. This is why the Honlite pump was chosen for the Q4 2017 design, but several WMC pumps will be purchased as backups in the event we find the Honlite product to be faulty.

It is quite difficult to find a peristaltic pump with a sufficient flow rate for such a low cost and this is the primary source of skepticism for using the Honlite pump. How are they able to achieve such a large flow rate without increasing cost? The answer could be they are mass producing these pumps in a highly efficient system, or perhaps their pumps are not as reliable. Consistency in sample volume may not be a large concern, however an inconsistent sample volume is almost exclusively caused by a varying velocity of sampled water in the tubes. This varying velocity can certainly lead to varying turbidity and suspended solids measurements [source] [source], and so consistency is a huge factor in choosing a pump.






Evaluating the TCS34725


An RGB light sensor we evaluated for use in the Evaporometer project.  This sensor measures RGB, color temperature, lumens, and visible light spectrum, and has features that currently aren’t useful for our project, but are still worth documenting in this post.

Setting up the sensor:

Screen Shot 2017-09-08 at 1.03.33 PM.pngScreen Shot 2017-09-08 at 1.03.33 PM.png

The TCS34725 was connected to an Adafruit Feather 32u4 using traditional I2C, although the RGB breakout features an additional port for a RGB LED to mimic the RGB values read by the sensor.  More on the full functionality can be found on Adafruit’s website here.  An SD card breakout was also connected to store the RGB, color temperature, lumens and visible light spectrum values.  

A sensor right next to the white LED reads the RGB values of light reflected by different objects. A sensor right next to the white LED reads the RGB values of light reflected by different objects. 

A sensor right next to the white LED reads the RGB values of light reflected by different objects. 

Testing the sensor:

For this test we were most concerned with measuring RGB values.  Color could be read by reading the different colored light that was reflected by an object. A built in white LED is used to present a consistent light source for the sensor to use.  This white light must be powered on in order to produce readings and RGB readings can only be made when objects are touching or placed directly in front of the sensor.  Our test sketch, which can be used on Adafruit and Arduino dev. boards exists here.

With the LED light powered on, the TCS34725 requires 5 mA of power to operate, making it an unfavorable candidate for long term deployment.With the LED light powered on, the TCS34725 requires 5 mA of power to operate, making it an unfavorable candidate for long term deployment.

With the LED light powered on, the TCS34725 requires 5 mA of power to operate, making it an unfavorable candidate for long term deployment.

Evaluation of the TCS34725:

After testing Adafruit’s TCS34725 and running a current test, it was clear that the functionality and power needs of this sensor were not what we were looking for on the Evaporometer project.  

A significant amount of power would be needed to read the RGB values and such data would be virtually useless in spacious outdoor areas.  While lux, color temperature, and the visible spectrum could be used to compare data with our Evaporometer’s TSL2591 sensor, it also makes sense to integrate a second TSL2591 sensor or conduct a side-by-side comparison of the two sensors to see if programming the TCS34725 to only measure lux values requires less power than the TSL2591.


UPDATE: A Closer Look at TCS34725 Functionality

As I mentioned at the end of the previous section, I thought this sensor could be useful to us so long as we disabled the RGB color reading functionality and shut off the white LED to save power.  After some digging around in the TCS34725 data sheet and TCS34725 library I learned a lot more about the full functionality of this neat light sensor – like many Adafruit sensors, this RGB sensor is capable of entering a low power mode that drastically reduces current consumption by only reading RGB color info at specified times.  Unfortunately, I also found that forgoing measurement of RGB values also makes it impossible to calculate Lux (lumens per square meter).  In this version of the TCS34725 library, lux calculations are derived from the RGB values of the light sensor, however this comment in the source code suggests that this may change: 

Screen Shot 2017-09-15 at 1.13.14 PM.pngScreen Shot 2017-09-15 at 1.13.14 PM.png

The developers suggest using the clear (C) measurement to find lux – hypothesizing that doing so may improve accuracy.  While the clear value is also measured in the same function that measures RGB values, it is possible an updated version of the calculateLux function and a well timed interrupt could also get the job done (using more power than our preferred IR/Full light sensor). 

– Marissa Kwon, URSA and NSF Grant Summer Student Researcher


Power Pulse Controllers


I have been putting together three power pulse controllers. One has already been sent out, but two more are in production. Here is a quick overview of the system specs and parts. 


I used Fusion360 for the modeling of the PPC and to create the 2D drawings so that other people can create it more easily. 


Here is the model of the finished model on which everything was based off :

The 2D drawings (link above) contain the layout of the components on the backboard and the locations of the holes made for the components that go on outside of the enclosure. There are some extra components that are not modeled in the CAD that come with the enclosure. These are not modeled because we were not the ones who put them on there; our pieces do not interfere with these pieces.

Here is a picture of the extra pieces that come with the enclosure:


Here are other pictures of the other two Power Pulse Controllers being built:


Reviewing the Diameter and Material of OPEnSampler Tubing


The EPA recommends a flow rate of 2 ft./s or greater to minimize the relative difference in velocities of suspended sediments. They also recommend a tubing diameter of 1/4 in. as well, but not for a particularly well documented reason. One unanswered question brought up in the design review meeting was the impact of tubing diameter on the quality of water samples. This short writeup discusses some of the considerations involved in the decision to use 1/4” OD Teflon tubing for future sampler designs.


Design Considerations

A paper published in 1985 collected some data on this subject [link to paper]. It discusses several trials where different concentrations of dissolved organic compounds were passed through tubing of varying diameters and materials at a known rate. The concentrations of the passed solutions were measured and recorded.

There are two obvious factors involved: the tubing absorption rate and friction. Absorption is based on contact time, tubing area, tubing material, and the analyte. Absorption is not a concern in suspended sediments but is critical when the analyte is dissolved carbons and gases. Contact time is based solely on flow rate. 

The friction coefficient is decided by the material and the force of friction will be proportional to the tubing diameter and flow rate. The force of friction will reduce the flow rate of the sample water, increasing contact time between the tubing wall and the sample water. Lower flow rates also reduce the accuracy of suspended sediment sampling where particle mass is a dominating factor that creates a differential velocity between the particulate sizes, shown by this study [link] mentioned to me by Dr. Babbar-Sebens.

The results of the experiment suggest the diameter of the tubing has a lesser effect than the material of the tubing on absorption rates for inner diameters between 1/4” and 1/2”, however increasing the tubing diameter decreases the absorption rate for the same material. This effect is unexplained in the paper and the relationship between tubing diameter and sample quality has very little research behind it. It is likely that the largest factor in choosing the tubing diameter is the maximum particulate size of suspended sediments, which requires a minimum diameter cross section throughout the entire hydraulic system including the solenoid valves and pump tubing. 

Both the study mentioned above and this other study [link] show that teflon tubing absorbs the lowest proportion of dissolved organics. The EPA in this paper [link] also suggest that a high velocity decreases the slime buildup against the inner surface. 



Because large suspended sediments (1mm+ diameter) are beyond the scope of the current sampler, Teflon tubing with a .17” ID and .25” OD will replace the current 3/16” ID Silicone tubing. Compression fittings will have to be used rather than barbed fittings. The change in diameter of the tubing will increase the velocity significantly and the teflon tubing will have much lower coefficient of friction, improving small particulate movement in sample water. Teflon tubing will be nearly impermeable to gases and will absorb extremely low amounts of dissolved compounds in the sample water, making it ideal for most of our intended applications, such as sampling for dissolved organics or volatile isotopes.




HyperRails are Working!


I have gotten the first prototype of the HyperRails working. I will be discussing the parts and setup.


This post is intended to update and inform about the progress with this project. 

Materials and Methods: 

We are using the V-slot aluminum extrusion and carriage system from openbuilds. All other parts were previously discussed in the last post about the HyperRails. These are the ones that are 3D printed in the lab. 

All of the pieces were assembled according to the CAD. This step was pretty straight forward, the one that took more time was rolling up the line on the spool and tightening it on the carriage. This took more time due to the fact that the line would tend to get loosen up and some times tangle up while coiling up on the spool.

Results and Discussion: 

Here is a video of the system in action:

The system works very well, we can see the movement of the carriage is very smooth.

Here are the links to the electrical components and code.

Test Code


Motor Driver

The main consideration for the next iteration is to make the system be able to work with all lengths. The main problem with this system is that the length of line needed for the system to work covers almost the whole surface of the coiling spool. After the line starts to overlap, the programming will have to be more complex to account for the decrease or increase of the diameter of the spool. This is the next problem to address with the next iteration. Our current system can only spool about 1.5 meters of line, and this system has to be designed to work will all lengths. One other consideration is the stretch of the line. When we were testing the system, in some cases we over extended the line and it would stretch a lot. I will need to find another fiber that has a very low stretch.