A First Configuration of the Freewave Z9-T DEVKIT

Posted on January 15, 2019 by Cara Walter

Author: Grayland Lunn

Configuring the Freewave Z9-T DEVKIT radio can be at challenging at times, so this is a post meant to supplement the Freewave setup guide. This blog is not intended to cover all of the elements of setting up the radios, but instead to cover some gaps that may exist within the documentation.

The quick start guide can be found at Freewave’s Support Website. Their support website requires registering a free account with your email. A full user guide is also available for the Z9-T DEVKIT and for the Z9-T radio in the ZumLink 900 Series tab of the support website.

It is likely easiest to use the terminal interface tool Tera Term. This is what the quick start guide uses, and it is what the author used to configure the radios. Tera Term can be downloaded here. However, if you are using a unix system, use PuTTY instead to open a USB serial connection to the radios.

Now, let’s get started with setting up the radios. You should have both this blog and the quick start guide open at the same time for best results.

Hardware Setup

Connect the antenna to the radio without any power or other connections.
Ensure the 5 pin x 2 pin jumper on the devkit is connected on the USB side of the pin block and NOT on the TTL (D9 Port) side.
Connect the provided 12V power cable.
Connect the micro USB serial cable between your computer and the Freewave radio. Take note of the COM port that was added, this will be used in the CLI configuration.

Configuring Your Terminal (Windows)

Follow the CLI configuration steps provided in the quick start guide. Be sure to press the S1 interrupt button on the radio every time a new terminal setting configuration is attempted (CLI configuration step 8). If you do not press the S1 interrupt button on the radio before sending enter in the terminal tool, the radio will not connect. Here is an example of the correct setup steps:

Select a new baud rate in the serial port setup pane.
Accept new configuration.
Press the S2 interrupt pin.
Press enter in the terminal window. If the shell does not return a new line with “>” at the line head, the serial port is not configured correctly, go back to step 1 and try another configuration.

The quick start guide steps are for programming the radios out of the box, and the configuration settings may have been changed by another developer, so here are a few common configurations to try if the Freewave CLI is not connecting.

Try a different BAUD rate.
- A baud of 115200 is most common, and 3000000 (three million) is also common and used for uploading new firmware.
- Available CLI BAUD rates are 9600, 19200, 115200, 230400, 460800, 921600, and 3000000.
Try turning flow control off.
- The two available flow control settings for the radios are Hardware (ACK/NACK for PuTTY) and off.
- If flow control is turned off, the most likely BAUD rate is 115200. This setting is used with the NavSpark GPS for the Slide Sentinel project.
Try a different serial port or plug and unplug the USB connected to the devkit to make sure you are using the right port. Be sure that you are using a micro USB data cable.
The data, parity, and stop bits are unlikely to change based on our lab’s current usage, however check the data format of the last use case if you still can’t get the radio to connect to the CLI tool.

Configuring Your Terminal (Mac/Linux)

Unfortunately no TerraTerm port exists for OSX or Linux distributions. If you are using a machine running these operating systems you will need to use an alternative application for establishing terminal serial connections and configuring Freewave Z9-T.

First, plug in the device and determine if your machine recognizes the Freewave Z9-T development kits, open a new terminal and run:
```
$ ls /dev/cu.usbserial*
```
The above command will list all usb serial devices connected to you machine, these devices show up in /dev directory. If a Freewave developer kit is connected and recognized you should see the terminal return something like this:
```
$ /dev/cu.usbserial-DEVKIT
```
The easiest way to establish a serial connection to the device and enter the Freewave shell is using the screen command line tool. Run the below command to verify that you machine has the tool installed.
```
$ screen --version 
```
If you receive the following error “-bash: screen: command not found”, then you must install the tool by installing it:
```
$ brew install screen (mac)
```
```
$ sudo apt-get install screen (Linux)
```
With screen installed, a serial connection can now be created. In a terminal window type the following command:
```
$ screen /dev/cu.usbserial-DEVKIT 115200
```
Press the interrupt button on the Freewave development kits then enter the screen command. If all goes well your terminal will go blank. Simply hit enter twice and you will be prompted by the Freewave shell. Proceed to “Using the Freewave Shell Command Line Interface” section for configuring the radios properly.

Using the Freewave Shell Command Line Interface

Use of the shell is not covered in depth within the quick start guide, so here are some helpful tips for using the shell.

Press tab at any time to auto complete a command or show all available commands.
Typing a specific command or group of settings will allow you to see the current value(s) for those settings. Try typing “serialPortConfig” to see the current serial port settings. Make note of these for the next time you need to connect to the radios.
Typing “radioSettings” will show the current radio configuration.
The shell is not case sensitive, no need to worry about case.
To change a value, just type “fakeValue=x” for instance cliBaudRate=115200 will update the baud rate that is used for connecting to the freewave shell.
If you want to know all the available values for a setting, type “fakeValue=” and press tab to show all the available values.
More description on settings is contained in the Z9-T user reference manual, here.

A Basic Connection Between two DEVKITs (Windows)

The quick start guide provides all the settings necessary for connecting two radios with a wireless link. One setting that could not be changed was the “radioSettings.maxPacketSize” setting. Attempting to change this will always return “RESULT 20: SETTER NOT VALID” however this is not an issue as long as both radios have the same value for maxPacketSize.

Note that you must update the firmware of each radio if it is not up to date. The firmware update guide is in the Z9-T user reference manual, section 8.

When first attempting to connect and send a file via a radio link, follow the data logging steps provided in the quick start guide using this copy of Alice in Wonderland as the test file. It has no <CR> or <LF> characters which cannot be used by the terminal logging software. Once the radios have been configured correctly for the data transfer, start the log on the gateway terminal. And send the file using the Tera Term send option from the terminal connected to the Endpoint.

Be sure that neither terminal is connected to the Freewave shell, this will prevent data transmission.

A successful transmission will show text flowing in both terminals, and the log will be accumulating data. Once transmission is complete, stop logging. Run a file comparison (FC command in windows command prompt) to ensure data was transmitted without error.

A Basic Connection Between two DEVKITs (Mac/Linux)

NOTE: ensure that you have updated the firmware on the radio and “radioSettings.maxPacketSize” is configured to the same value on both radios as detailed in the above section. These configuration steps do not differ between Mac/Linux and Windows.

In order to send a message between the two radios you will need to exit the Freewave shell on both the Gateway and Endpoint. From the Freewave shell connections type:
```
exit 
```
Hit enter. Then press the reset button on the dev kit boards.
Download the copy of Alice in Wonderland, and ensure you know the full path to the file.
Now from the terminal which previously held a connection with the Freewave Z9-T configured as a Gateway enter:
```
Ctrl + a
```
Then enter a colon like so,
```
:
```
The above sequence of keystrokes signals the screen tool that you are going to enter a command. In order to send the file we need to first load the copy of Alice in Wonderland into a buffer. To do this run:
```
readreg p /path/to/Alice/In/Wonderland
```
The terminal should return the following statement:
```
Slurped X character into buffer
```
Now we are ready to send the file. I recommend having the terminal window connected to the Freewave Endpoint in visible sight so you can see the file contents printed to stdout as the Endpoint receives the file. To send the file to the Gateway type the input command signal Ctrl + a and : (colon) then enter:
```
paste p
```
You should see a steady stream of data printed to the terminal window connected to the Endpoint Freewave. Congratulations you just transferred Lewis Carrol’s Alice in Wonderland across the air between two Freewave Z9-T’s!

Cosmic Ray Environmental Sensing Online

Posted on January 4, 2019 by Cara Walter

Author: Emre Akbulut

We are in the preliminary stages of analyzing different options for how to modify the Cosmic Watch v2’s configuration and code to suit our purposes in detecting gamma rays. There are some assumption based methods like using the Cosmic Watch’s master-slave configuration and deducting the difference between them as the total amount of gamma rays. However, by working with the radiation detection group we are hoping to find ways to employ more exact methods in gamma ray detection.

While waiting for parts I began reading about scintillators and SiPMs being used to detect gamma rays and muons. Muons are have an average energy level of 4 GeV at sea level [1] while gamma rays have a much lower energy range typically defined as 100 KeV to 5 MeV [2]. The way the Cosmic Watch Muon detector works is when a muon hits the scintillator it emits light, the SiPM then sees this emission of light and converts it to a voltage pulse. The resulting pulse ranges from 10-100mV, which is too small to be read by the Arduino Nano, so the signal is amplified by 20-25 through an op-amp so it can be read by the Nano as an ADC voltage value.

One interesting thing I found was how one individual created a DIY gamma ray detector with a miniature solar cell [3]. This functioned similar to the Cosmic Watch in how a pulse was created from gamma rays and then amplified to be displayed. It may be worth looking into if this method of detection could be improved to suit our purposes.

Another thing I noticed when looking through the materials we are using for the Muon detector we have is that the scintillator we have, bc408, is not meant for gamma ray detection. However, the bc412 from the same manufacturer can detect gamma rays from 100 KeV to 5 MeV [4]. We will need to meet with the radiation detection group at OSU first before considering the use of bc412 material.

[1] “Muons.” [Online]. Available: https://cosmic.lbl.gov/SKliewer/Cosmic_Rays/Muons.htm. [Accessed: 24-Jan-2019].

[2] “Radioactivity : Gamma Rays in Matter.” [Online]. Available: http://www.radioactivity.eu.com/site/pages/Gamma_Matter.htm. [Accessed: 24-Jan-2019].

[3] “Alan Yates’ Laboratory – Photodiode Gamma Ray Detector.” [Online]. Available: http://www.vk2zay.net/article/265. [Accessed: 24-Jan-2019].

[4] “BC-408, BC-412, BC-416 | Products | Saint-Gobain Crystals.” [Online]. Available: https://www.crystals.saint-gobain.com/products/bc-408-bc-412-bc-416. [Accessed: 24-Jan-2019].

March 29, 2019

Major developments have happened since the last blog post. Some questions that were answered from the previous post:

BC412 and plastic scintillators will not offer the resolution we need for detecting gamma rays due to their low Z value. This is because the method of using gamma ray detection to get the snow water equivalency (SWE) of snow requires very high resolution detection.
Steven Czyz, one of Dr. Farsoni’s Ph.D students informed me and Selker on the issues with an inexpensive way to detect gamma rays mentioned in the above bullet point. However, Steven’s ph.D thesis project is a full spectrum, small gamma ray detector which cost about $5,000 to build two. He said that after he finishes his ph.D project thesis that his gamma ray detectors will probably be not used; so it is possible we could use them.

Originally with our backgrounds we were expecting gamma ray detection would be inexpensive and neutron detection would require very expensive that would only emit light due to neutrons.

On March 15th, 2019 during a meeting with John we were reaching out to Eljen Technology inquiring about their neutron detectors. John explained the overview of the CRES project and asked about their green sandwich “paddle” for thermal neutrons and asked if it was possible to get any defective scintillators to help orient ourselves with neutron detection.

About two weeks later they decided to contribute an entire 6 cm by 20 cm green sandwich “paddle”, which is composed of two scintillating tiles, EJ-426, and a green wavelength shiftier EJ-280. They sourced this from a larger order in Europe and there is already a small square cut on one of the tiles to for using a SiPM with the sandwich. This contribution is worth about $200, about the same price it took to assemble the muon detector.

To my excitement about this I started looking into this green paddle configuration to see what modifications we would need to make to the current CRES electronics. First off was understanding if our SiPM for blue light would work. The color wavelength chart below for reference will help understand why the sandwich configuration is used.

EJ-426’s emission spectrum peaks around 450 nm which is on the boarder of violet and blue light. The EJ-280 takes the violet/blue light and then shifts the wavelength to green light. This sandwich has some advantages over typical light collection methods like used in the Cosmic Watch V2 Muon Detector.

The OPEnS Power Control Board: A circuit to reduce the standby current draw of microcontroller projects to 130uA

Posted on January 4, 2019 by nelkem

At the OPEnS Lab, we’ve found a common requirement amongst our projects: a long, long, long battery life. The OPEnSampler was particularly challenging due to its simultaneous 3.3V, 5V, and 12V power requirements. MOSFET circuits exist that can manipulate power sources and drop their standby currents to near-zero, but designing these in a way that latched their state in both directions, and were powered exclusively from the source battery, was difficult. This short blog post will discuss the features and considerations of Release 1.0.0 of the OPEnS Power Control Board.

The schematic

The circuit was designed by Mitch Nelke. There are two core integrated circuits in this board. IC1 represents the flip flop IC and is responsible for latching its EN-bar output HIGH or LOW after a HIGH pulse on its Clock Pulse input or a LOW pulse on its C-bar input, respectively. IC2 represents the 12v-5v switching regulator component that drops the battery’s 12v supply to the 5v used to power the microcontroller and other components.

The Flip Flop

The flip flop circuit power is sourced from the battery’s raw 12v, though it is dropped down to 4.3v by the zener diode D1. R1 was chosen based on a minimum required current of 60uA, derived from the max required input current of the switching regulator’s enable pin and the current required by the flip flop IC plus a bit of extra as a buffer. This 4.3v source is also used to pull the flip flop’s D input HIGH at all times. The Clock Pulse (CP) input is pulled to ground by a 10k resistor. On a rising edge on CP, the flip flop reads the boolean state of D and sets its Q output to match that value. With this setup, a HIGH pulse to CP will always set Q HIGH.

The C-bar input has a weak pullup resistor, R2, to 4.3v. When C-bar is pulled LOW, such as through the RTC_INT input or a HIGH input from INT_2, the flip flop IC ignores any clock pulses and sets its Q output LOW. When C-bar is raised HIGH, Q will stay LOW until the next clock pulse.

GPIO_READ allows a microcontroller input pin to read the state of the real time clock’s (RTC) interrupt alarm while the device is on. RTC_INT should be attached directly to the RTC’s INT/SQW pin, and GPIO_CP should be attached to the microcontroller’s output pin that is responsible for shutting the device off.

The Switching Regulator

The switching regulator efficiently converts the 12v input to a 5v output. This part of the circuit is essentially ripped from the LM2575 datasheet’s recommended circuit. Its EN-bar input acts as a low-true output-enable and is attached directly to the flip flop’s Q output. The 5v output of the regulator is fed through the MODE jumper. The MODE jumper’s first two pins should be connected during regular use, but should be disconnected when a USB is plugged into the microcontroller (to program it, for example) to not have competing 5v supplies.

The Board

The board layout was done in EAGLE CAD by Sam Edwards. I’ve added dimensions and turned off tStop and pour planes so it is more clear.

Connections

The board is designed specifically to work with Adafruit’s Feather M0 microcontroller series. It should be powered by a 12v battery plugged into the 2.5×5.5mm barrel jack receptacle.

The +5V pin should connect to the M0’s USB power pin or the Arduino Uno’s Vin. MODE should be closed with a jumper to enable the 5v output of the board.
The +12V output should be connected to any circuitry that requires 12v.
RTC_INT should be connected to the real time clock’s interrupt output, or any other independent circuitry that sends a LOW-TRUE signal to turn the device on.
GPIO_READ should be connected to an input pin on the microcontroller if the real time clock’s alarm needs to be read by the microcontroller when power is already enabled.
GPIO_CP should be connected to the microcontroller’s digital output that is designated as the shutoff pin.
INT2 should be connected to any external circuitry that should power the device on with a HIGH-TRUE signal.

Testing

A current draw test was conducted by measuring the current with a multimeter between the battery’s positive lead and the positive input on the power control board. The power control board was attached to the OPEnSampler’s Microcontroller Breakout Board, upon which Adafruit’s Feather M0 Wifi microcontroller was also attached. The microcontroller was programmed ahead of time to simply power its LED upon powering up. One jumper cable was connected to the real time clock’s 3v3 power pin, supplied by the M0, and was temporarily connected to the power control board’s GPIO_CP pin to turn the device off. Another jumper cable was connected to ground and RTC_INT to turn the device on.

The device had a current draw of 22mA when powered on and only 130uA when powered off. When powered by the small 2000mAH, 12v battery used on the OPEnSampler, the device will have a maximum standby battery life of 641 days (not accounting for the battery’s internal leakage current). If the device had used normal sleep methods that can reduce the consumption down to 1.5mA, the maximum standby life would have only been 55 days. With no standby mode at all, the battery life would have been less than four days.

Considerations

An important consideration is that I am not an electrical engineer, nor am I pursuing a degree in electrical engineering. There is much to be improved on this board, and if you have any ideas, or find a bug in its design, you shouldn’t hesitate to contact the OPEnS Lab or leave a comment on this post! Additionally, this was only tested on Adafruit’s Feather M0 Wifi breakout, so your mileage may vary on other boards (especially ones that are not in the Feather M0 family!).

Finally, when using this board it is important to understand that the microcontroller is completely shut down on “standby” mode. This means that after the real time clock wakes the device up, it will start at the setup routine and any variables stored in flash will be erased. Be sure to use non-volatile storage methods for variables that must be saved between power cycles. The OPEnS Power board, for example, includes a small EEPROM chip. Adafruit’s Feather M0 Express includes extra SPI or QSPI flash memory that isn’t erased between power cycles as well.

Conclusion

The primary application of the OPEnS Power Control Board is to increase the battery life of a sensor suite powered by a 12v, 2000mAH battery. This board is capable of dropping the standby current of microcontroller-based projects down to 130 micro-amps. The minimum standby current that could be achieved previously was about 1.5mA based on Adafruit’s tutorial linked previously. The OPEnS Power Control Board increased the theoretical max standby battery life from 55 days to 641 days. The device fully shuts off on standby and wakes up from pulses to either of its two interrupt vectors, one HIGH-TRUE and one LOW-TRUE.

Link to GitHub

Written by Mitch Nelke, OPEnS Lab OSU

25 meter HypeRail + eGreenhouse

Posted on December 10, 2018 by lopezalj

Abstract: The HyperRail was modified to be used with the eGreenhouse, a sensor suite for real-time greenhouse monitoring. The system is about 25.5 meters long and is located in the Northwest Research Extension Center in Wilsonville, OR.

Deployment: The HyperRail has the standard setup of electronics, but in this iteration it includes a short range radio. This radio is used to upload the data from the sensors up to a google spreadsheet. Here is a link to eGreenhouse page that details the the setup of the sensors.

The image above shows the RF chip breakout board that goes on the Feather M0. The image below shows the HyperRail + eGreenhouse deployed in the greenhouse.

eGreenhouse Online

Posted on December 10, 2018 by Cara Walter

Author: Lars Larson

The full-scale deployment has been successfully tested on a 25-meter OPEnS HyperRail. The full transmission sequence was verified from hub to sensor node, back to the hub, then relayed to an ethernet hub over 100 meters away. CO2 and other sensor data was sent from the greenhouse to Google Sheets and plotted in real time.

Three nRF transmission boards are under testing for reliability and range (Itead, SparkFun, Amazon). When the nRF is proven stable, the deployment will start running continuously with the help of a wireless charger.

More updates to follow in January 2019 with a live data feed from Google Sheets.

Second Tests: Cherry Tree

Posted on August 21, 2018 by Cara Walter

By: Jonathan Fookes

Design

A probe was built as described in this build guide. The following data was returned from the sensor. This probe is was designed by Dongjun Lee and Jonathan Fookes using the previous design from Brett Stoddard.

Methods

Because our probe was designed with an Ethernet connection, we created a PCB with an eight pin connector that sat directly on top of our Adafruit Feather M0 with Lora capabilities. Instead of using an NPN mosfet similar to the one used in the Orchid Test, a voltage regulator kept the voltage across the heater at a steady 3.3 V. These device was fully integrated with the LOOM interface for easy setup and implementation, as laid out in our LOOM implementation guide. The electronics were run with two batteries: 12 V, 2 AH to power the heater in pulses, and a 3.7 V, 2.5 AH battery to power the M0.

Similar to the Orchid Test, analog values were recorded by the board’s dedicated analog in pins. As per default, these readings were 10-bit although the M0 chip has the capability to do 12-bit ADC (detailed in this link), therein increasing the theoretical precision four-fold. These raw values were logged onto an SD card.

The waterproof enclosure was built to contain the fully constructed circuit and each of the batteries. Even though the tree was too far away from the lab to successfully transmit and received LORA data, there is space for an antenna and LORA can be set up using the LOOM interface if desired. The waterproof Ethernet connector is where the probe can connect to the circuitry, ensuring a secure connection. A hot glue gun was used to add an extra waterproof seal.

Energy Saving: The Power Problem

Our design uses heat pulses in order to save energy. Given the current models and code for both the TDM and HRM sapflux measuring methods, we conducted a current draw test with the batteries we had on hand to see if our designs will be able to run continuously in the field for 2 weeks as requested.

TDM Probe

Current Draw: 20.88 to 20.91 mA while on, 0.13 mA while off (not negligible)

TDM heater Pulse: 4 minute pulse every 30 minutes, aka 8 minutes an hour, 192 minutes per day. This is 3.2 hours.

The TDM probe uses: 67 mAh per day(Heater on) + 2.7mAh per day(Heater off) ~= 70mAh per day. The TDM heater probe can be on for 28.5 days with a 2,000 mAH battery.

TDM base

Assume we measure SHT31D + probe temperatures + soil moisture

M0 Current draw: 25 mA in Idle, and +130mA when measuring and transmitting data. (25mA * 24h per day) + (130mA * 48sec per day) = 600 mAh(idle) + 1.73mAh(Transmit data) = 601.73 mAh per day. The M0 can run for 16.6 days when we use a 3.7V 10,000mAh battery.

HRM Probe

Current Draw: 225 to 237 mA

HRM Heater pulse: 2.5 sec on and 2.5 sec off. It works on 2 minutes every 30 min, aka 2 minutes an hour, 48 minutes(0.8 hours) per day. 180 mAh to 190 mAh per day. The HRM heater can run for 10.5 days when we use a 12V 2,000mAh battery. For 2 weeks test, we need higher capacity of battery.

HRM base

M0 Current draw: 25 mA in Idle, +130mA when measuring and transmitting data, and 156 mA when relay switch is on.

Relay switch is on for 2.5sec and off for 2.5 sec. It works on 2 minutes every 30 min, aka 2 minutes an hour, 48 minutes(0.8 hours) per day. (156mA *0.8h per day) + (25mA *23.2h per day) + (130mA * 48sec per day) = 124.8mAh(Relay on) + 580mAh(Relay off and idle) + 1.73mAh(Transmit data) = 706.53mAh per day. The M0 can run for 14 days when we use a 3.7V 10,000mAh battery.

TDM Test: Return of the Data

After a couple of failed test runs, we were finally able to graph data using our TDM probe. We used the Dynamax data calculation example from their website and created the following graph for the sap flow in a wild Cherry tree for about

The trend of this data is consistent and promising!

We have a two-week long test of our TDM probes coming up in the following weeks, where we will be able to show more conclusively if our probes are providing accurate sap flow data.

HRM Test: The Phantom Data

Our first HRM test was a success, however we are still working on a method to calculate sap flow from the data we have collected. Below is the data we collected in the wild cherry tree. We are continuing to work with the Heat Ratio equation to plot Sap Flow in grams per hour with respect to time.

This plot shows all of the data points we measure on our HRM test. The y-axis is degrees Celsius. Because we collected data every 15 minutes during this test, the x-axis is time, and represents X*(15 minutes)

Here we have the difference between the temperatures of the two probes you see in the first graph. The y-axis is still in degrees Celsius and the x-axis shows time of day.

While we do not have calculations for Sap Flow yet, we know that a lower difference means that there is an increase in sap movement up the trunk of the tree, and a higher difference means less. We can infer this from the Heat Ratio Equation. The HRM difference data shows that the lowest difference occurs between ~11:30am and 7:00pm. This is consistent with our TDM data, shown in the section above. While our TDM measuring method is more complete and can render Sap Flow calculations, we are confident that our HRM measuring method can be used to produce accurate readings as well.

Our TDM probe prototype in the wild cherry tree! (8/03/2018)

Our HRM probe prototype in the wild cherry tree! (8/16/2018)

What’s next for the Sap Flow Team?

Now that we have gathered promising data from a tree, we will be deploying both our TDM and HRM prototypes in an orchard, where we will attempt to gather data for two weeks continuously. More on this to come!

Almost ready for action

Posted on August 21, 2018 by Cara Walter

Author: Lars Larson

The custom PCB’s are in, and the system is nice and stable. The Powerboost 1000c powers everything well, running off a 3.7V battery. The wireless inductive charging system also works as planned.

The first iteration of a 3D-printed enclosure could use a couple of adjustments, but it will work for initial testing. The main issue is that the HyperRail may be long enough to require an antenna for the nRF chip, which will not fit in the current enclosure.

The software reliably integrates the sensor system with the HyperRail with easy customization of time and distance intervals. Data can be transferred to the hub and forwarded to a second base with Ethernet capability up to 400 meters away. Construction, deployment, and experimentation begin in early September.

Check out the pics below for the enclosure, PCB, and powering system.

Updated Sap Flowmeter Build Guide

Posted on August 13, 2018 by Cara Walter

By: Jonathan Fookes

Abstract

This post will provide step by step instructions on how to build your own thermal dissipation sap flow sensor using everything provided on this blog and the following steps: ordering / creating parts, soldering the probes, applying the thermal epoxy, wiring to an Ethernet cable, implementing the circuit, programming the microcontroller, and installing into the tree.

Index

Order and Create Parts
Solder Probes
Apply Thermal Epoxy
Wiring the Probe
Creating the Circuit
Programming the Microcontroller
Designing Enclosure
Install in a Tree

Step 0: Required Tools

Before jumping into the project, it’s important to mention that this project requires a few specialty devices to make.

Soldering iron station
Tweezers
Power drill with 6mm drill bit
3D-Printer Access
Electrical tape
A computer with Arduino IDE installed

Step 1: Order Parts

Below are two different bills of materials (BOM) that contain all that is required to build one of these sensors. The files for the pcb board can be found in this zip file. Base_v1 is the version we used in the design listed here. Base_v2 includes an updated switch to easily switch between TDM and HRM implementations (coming soon?). To edit, you will need to download Eagle by Autodesk as well as a few part libraries including Brett’s personal library of Eagle PCB parts. The total cost of a sensor is estimated to be just under $170! The comprehensive list of all parts used to make either an HRM or TDM probe run in working order are included in the Bill of Materials below.

Additionally, an Adafruit Feather M0 LoRa is needed with a 3.7 volt battery (suggested 4AH) for the sake of this build guide ($34.95 + $19.99 resp.). It also requires our custom build PCBS, the probes (we recommend ordering 2 more probes than needed) and our 8-pin routing board that connects directly to the Feather M0.

The Feather M0 can be substituted for any micro controller with analog-in pins with some changes to the code to accommodate these new pins (mentioned briefly in Step 4) and if a different voltage batter is used, you should take a look at this blog post and change the heater resistor value. We used the Adafruit because their boards work well with each other. In addition, the Feather M0 with LoRa can transmit data for remote data gathering and troubleshooting. See more on that here.

When ordering the electronic parts I would highly suggest you buy spare parts, especially any 0603 resistors (baked into the single sensor BOM).

Step 2: Solder Probes

Once you’ve received all the parts, it’s time to break out the soldering iron, tweezers, and reading glasses (optional) to tackle the most difficult step of this build: soldering on US0603 sized resistors. Soldering these on is a major test of patience even for veteran electrical engineers, but not impossible for first-time solders. Here are a few tips and tricks that should help: article from build-electronic-circuits.com, video from Engenuics Technologies.

For this design, two thermistors need to be soldered into their nodes on two of the probes, and a heater resistor on one of the probes. The location for these on the probe are illustrated in the picture below. (NOTE: Keep the thermistors and heaters separate so as not to confuse them)

Step 3: Apply Thermal Epoxy

The next step involves the thermal epoxy. This is used in order to evenly spread out the effect of the heat pulse and to get better contact when inserted into a tree bore-hole. In the past, this was done using a 3D-printed mold, but we discovered applying the mold by hand is just as effective.

The epoxy in the BOM is a two part epoxy with a curing time of 45 minutes. To use, squeeze out equal parts from the A and B syringes and mix this well with a mixing stick. Use the mixing stick to apply a thin layer of epoxy, gently wiping away any excess epoxy with a paper towel. Wait at LEAST 45 minutes to dry, suggested overnight. Make sure that disposable gloves are used during this step. t’s also suggested that mold release spray be used on the inside of the mold to help the epoxy from sticking. Once the epoxy has dried, lightly sand the probes to remove rough edges and create a smooth surface. Here is a picture of our HRM Ethernet probe for a visual of what the finished product should look like.

The two outside probes (thermistor probes) have been sanded. As you can see, there is a smoother texture than the middle probe (HRM coil heater probe), which has not yet been sanded.

As we make more probes, we will include more pictures to show the application process in greater detail.

Step 4: Wiring the Probe

The probes should be wired to the board as shown to work with the current code.

We used an ethernet cable to connect the proper M0 pins to the probes as shown in the schematic. This was done by carefully routing our specially built PCB 8-Pin connector board (Base_v1 as listed above), specially designed to properly connect the probes with the color-coded guides listed below and the 8-pin connectors listed in the BOM. Cut off one end of the Ethernet cable to expose the 8 wires inside the protective inductor outside. Use the following schematics and Ethernet color chart to properly connect the probes so that they work as desired.

Insert probe guide from the PCB for which pin (on each probe) goes to which color of wire (with Ethernet color-coded cable pinout)

TDM

1 VCC – White & Orange – Pin 1 on the Heater Probe

2 A0 – Orange – Pin 2 on the Heater Probe

3 GND – White & Green – Pin 3 on the Heater Probe

4 V_BAT – Blue – Pin 4 on the Heater Probe

5 GND – White & Blue – Pin 5 on the Heater Probe

6 VCC – Green – Pin 1 on the Thermistor Probe

7 A1 – White & Brown – Pin 2 on the Thermistor Probe

8 GND – Brown – Pin 3 on the Thermistor Probe

HRM

1 VCC – White & Orange – Pin 1 on Thermistor Probe 1

2 A0 – Orange – Pin 2 on Thermistor Probe 1

3 GND – White & Green – Pin 3 on Thermistor Probe 1

4 V_BAT – Blue – Pin 4 on the Heater Probe

5 GND – Blue & White – Pin 5 on the Heater Probe

6 VCC – Green – Pin 1 on Thermistor Probe 2

7 A1 – White & Brown – Pin 2 on Thermistor Probe 2

8 GND – Brown – Pin 3 on Thermistor Probe 2

Here is a picture of our finished TDM probe. A picture of the finished HRM probe is included in thermal epoxy application section.

Step 5: Creating the Adafruit Board Circuit

The circuit for the sapflow probe is made with a variety of Feather boards from Adafruit, including Feather M0 with LoRa Radio, Power Relay FeatherWing, and Adalogger FeatherWing with SD add-on. Our custom PCB is also used, which has the voltage regulator used for the TDM method, the 8-pin connector, and tracing that allows to switch between the TDM and HRM methods (depending on which probe is ended up chosen). Currently, both models require a 3.3V battery that can power the Feather M0 board and a 12V battery that can power the heater. Below is a picture guide for how to set up the stack of boards, using a FeatherWing Tripler PCB board from Adafruit as a mount.

This is our custom PCB, which is linked above, without any parts on it yet. This is the best place to start!

Our fully assembled PCB. Note the type of headers used in these and subsequent pictures. This is crucial for proper assembly!

Picture of the Feather M0 with LoRa Radio with the pins correctly soldered on.

Stack the custom PCB construction on top of the Feather M0 with LoRa as shown, and solder female pins on the FeatherWing Tripler as shown.

Next, solder the pins onto the Adalogger FeatherWing RTC + SD Add-on as shown. Insert Micro SD card

Solder the pins onto the Power Relay FeatherWing as shown.

Stack the Power Relay on top of the Adalogger and place the new block onto the FeatherWing Tripler.

This shows the power connections for the HRM Power Model. Red is (+) on the 12V battery and Black is the (-) on the 12V battery.

This TDM circuit for our probe uses a voltage regulator instead of the power relay. This is soldered directly onto our custom PCB. Below is on picture of the boards used for the TDM circuit. NOTE: not used with the 8-pin connector, this particular model was made before we had received these. Note the labels and picture caption for construction. For differences between the TDM and HRM implementations, visit our Second Tests: Cherry Tree page for an extensive list of differences.

Ignore the small red and blue wires shown on the custom PCB. We blew one of the traces and that just corrects the error. The 12V battery is put directly to the voltage regulator through the pins on our custom PCB.

Step 6: Program the Microcontroller

This device can be fully integrated with the OPEnS designed LOOM interface. The code for the program described in this build guide is posted here (LINK). This post (LINK TO LOOM) explains these different functions in LOOM and how to use them. The following is a setup guide for how to setup the user interface to run the Sap Flowmeter data collection.

If you’ve never used an Feather M0 before, check out these two pages on Adafruit’s tutorial:

If you’ve never programmed in Arduino before (or ever), I would highly recommend reading though a few of the fundamental tutorial pages on the Arduino website until you grasp basic the basic concepts and idea of what Arduino is. Linked here.

Step 7: 3D-Printing the Enclosure

Current Design

This is the current model of the enclosure. Its features include: snap-fit lid, compartments for the 3.3V & 12V batteries, mounts for the Adafruit FeatherWing tripler to hold the circuit in place, hole for the waterproof Ethernet cable gland, hole for LoRa antenna (6mm near the mounts), and hole for the soil/moisture sensor aux cable gland (9.5mm across from antenna hole). The compartments in the back right corner are to hold the batteries and prevent them from sliding around. The mounts on the base of the enclosure are design to hold M2 size screw bases. M2 screws fit through the holes in the Adafruit tripler board, thus securing it to the enclosure.

To fully waterproof the enclosure, we recommend treating the enclosure and its lid with acetone to fully seal the plastic. We also recommend lining the lid with a sealant (hot glue, caulk) to make sure no water seeps in and messes up the circuitry inside during testing. The lid of the enclosure, for now, takes some work to get off, so we designed handles to make this easier.

Again, the model for our enclosure is always updating as we improve our design, so this is not a final design by any means.

Step 8: Install in Tree

NOTE: Make sure to read and understand this section entirely before proceeding with an install.

In order to to ensure that the probes are properly spaced, a 3D printed guide should be used. This version has a 30 mm spacing between the center of the two outside probes. Future tests should test with different probe spacing. This doesn’t need to be as precise as the thermal epoxy mold; we used a Lulzbot Taz 5.

Once the probe is all set up, drill holes in the chosen tree such that each probes fits inside perfectly and inside the tree up to the probe guide. For the best results, drill the holes approximately 1 meter from the ground (CITE). To find the perfect placement for these holes, I traced the bottom portion of the probe guide onto a piece of paper to make sure the holes were perfectly spaced. Make sure to use the proper size drill bit!

Install the probe will the heater probe above the temperature probe. This is important for TDM testing. Fill the holes with the thermal paste to keep the holes sealed and the probes in place. As of right now, we have not tested with the thermal paste.

Once the probe is in the tree, make sure to cover it with some layers of protection. For an example of this, checkout the Dynamax installation video. Here is a picture of our method:

Our TDM Probe in the Tree! The probes fit perfectly into the drilled holes with properly applied epoxy. For a guide on how to test and to see our data, go check out our tree test page!

Connected Greenhouse

Posted on August 3, 2018 by Cara Walter

Author: Lars Larson

A big step for eGreenhouse today – we’re connected to the internet! PushingBox code is integrated into the HyperRail hub code that pushes sensor data directly to Google Sheets. I set up my own account, so I can log up to 1000 data points per day (roughly every minute and a half).

Other new developments:

By digging into the documentation and doing some testing, we’ve determined that the whole system can run well on 5V. This means we can use a 3.7V battery pack with a Powerboost 1000C breakout board to boost up to 5V. This setup should be nice and efficient.

Also, the UART data lines (RX/TX) on the CO2 and particle sensors both run on 3.3V logic, so there’s no need for a logic level converter.

I’ve crafted the new streamlined version with everything included into a custom PCB that’s ready to send off for manufacture when can verify the Powerboost works as anticipated.

I built a 3-meter HyperRail in the OPEnS Lab, so I’m ready to scale up to the full version at the experimental location when parts arrive.

Next steps:

Run a 3-4 day experiment on campus to work out any kinks in the system before full deployment
Calibrate the K30 using an Irgason on campus
Design an attachment system for the sensor package on the rail

Screen Shot 2018-08-03 at 2.54.28 PM.png

Successful readings on the HyperRail!

Posted on July 19, 2018 by Cara Walter

Author: Lars Larson

Great progress today – we got CO2, lux, temp, and humidity to transmit to the hub while the HyperRail moved the sensor package in specified increments. Video posted below.

The HyperRail GUI now allows for specification of the travel length, speed, and distance between stops. When the sensors get to each new location, the hub tells which sensors to take readings. Once the readings are complete and the hub receives the data, it moves the package down the rail to the next sensing location.

Next, we’ll add a box to the GUI that allows the user to select which sensors to take readings from, without having to hard-code it. Also, the user will be able to select the time interval between runs down the rail and make it automatically loop throughout the day.