Successful “Real Time” Data Logging (Finally!) – A Step by Step Walk Through

Author: Tom DeBell

Update 10/3/18

The description of process of using PushingBox and the Google scripts was updated 10/3/18 (primarily with regards to the usage and interfacing with the Google Script). The most up to date and comprehensive tutorial is now maintained here.

Abstract

Connecting… Connecting… Transmission Received!

After months of prototyping, experimenting and redesigning we have successfully deployed our first, “fully open source” transmitter and receiver with near real time updates to a google spreadsheet.  This post will give a step by step procedure on how to set up all the software and web interfaces for this project.

Step One – Creating and Deploying your Google Sheet

A) Log in to your free Google account and create a new “Google Sheet,” this is the spreadsheet which will be populated by the sensor data received by the Ethernet Featherwing data logger. At this point, you will need to copy and save your spreadsheets URL key for use in your Arduino code. This key is listed in the URL between the “/d/ ” and the “/edit ” of your new spreadsheet (see red box).


IDID

B) Name your Spreadsheet something original like “Environmental Data,” now we must create our Google App Script (similar to JavaScript) which will process our data and populate our spreadsheet correctly. To insert our Google App Script we first navigate from our spreadsheet to the Script Editor, found under the Tools tab:

Tools →Script Editor

We will now be on the Google Script Editor page. Now we can name our Gscript something extra-creative like “My Environmental GScript”, but do not have to. Fortunately, we do not have much that we have to do on the Script editor page.

1) Copy and Paste the Google Script code into the Editor. (link to GitHub with all needed codes here)

2) Save the script: File→Save All

3) Deploy as a web App: Publish-→ Deploy as web App…

C)  Our final Step for setting up our Google sheet will involve configuring the Web deployment parameters. It is important you set all these fields correctly. If you don’t set all four fields exactly your spreadsheet won’t work properly (trust me…). This step takes place immedietly after clicking “Deploy as Web App”.


Field 1) Copy and Save the “Current web app URL:“ which has just been generated, we will need this later when we configure our API in PushingBox.

Field 2) Save a project version as “new” on each iteration, it’s important to note that if you don’t make a new project version for each script revision you make (if you decide to make any revisions), your script revisions won’t be updated on the web. This is counter-intuitive, and easy to neglect, but this is currently how Google has this system configured.

Field 3) “Execute the app as: “ set this to “me(your GMail here) ”.

Field 4) “Who has access to the app: “ set this to “anyone, even anonymous.” *This is important, and allows Pushingbox access the spreadsheet.* 


Step Two – PushingBox API

Pushingbox.com serves as simple, free, and easy Application Programming Interface (API) middleman in allowing our Evaporometer data to be palatable to Google Sheets. The need for using the PushingBox API intermediary is to turn our HTTP Ethernet transmitted data into Google compliant HTTPS encrypted data. Although other programmers have found workarounds to this system (found here) using PushingBox is easier, and we are given up to 1,000 requests (Data Transmissions) a day.

*1,000 push requests is more than enough for updates every 2 minutes in a 24-hour cycle but not enough for minute by minute updates (thus the “” around real time) but this service is completely free.*

Below are the steps for configuring Pushingbox to work with our data:

1. Create a PushingBox account using your Gmail.

2. At the top click on “My Services”

3. While now in “My Services” go to the “Add a service” box and click on “Add a service”.

4. The service you will want to create is the last item on the list of services and is called: ”CustomURL, Set your own service !”. Now select this CustomUrl service.

5. A box will open up and ask for three items. Fill them out as below, then hit submit

Name of your CustomURL configuration:

Root URL: This url will start with https://script.google.com… as this is your Google Script address saved from Part 1


6. After submitting your service you must now create a scenario for the service. To do this select “My Scenarios” at the top of the page.

7. Enter an appropriate name for your scenario in the “Create a scenario or add a device” box. After you name your service click the “add” button to the right.

8. Now it will ask to “Add an action for your scenario” You should now choose the “Add an action to this service” button listed next to the service name you created in the previous step. This assigns your new scenario to your new service.

9. A data box will open asking you for your “Get” or “Post” method (we use the Get method although this seems counter-intuitive). For recording all our Evaporometer data into your Google sheet you need to link your variable names listed in your Google App Script to the names listed in our Arduino sketch. Formatting the names correctly in the Pushingbox API will accomplish this linking task.

Copy and paste the following string into your box.

?key0=$key0

amp;val0=$val0

amp;key1=$key1

amp;val1=$val1

amp;key2=$key2

amp;val2=$val2

amp;key3=$key3

amp;val3=$val3

amp;key4=$key4

amp;val4=$val4

amp;key5=$key5

amp;val5=$val5

amp;key6=$key6

amp;val6=$val6

amp;key7=$key7

amp;val7=$val7

amp;key8=$key8

amp;val8=$val8

amp;key9=$key9

amp;val9=$val9

amp;key10=$key10

amp;val10=$val10

amp;key11=$key11

amp;val11=$val11

amp;key12=$key12

amp;val12=$val12

amp;key13=$key13

amp;val13=$val13

amp;key14=$key14

amp;val14=$val14

amp;key15=$key15

amp;val15=$val15$ 

Note: STATEMENT BEGINS WITH ” ” TO INDICATE “GET”

The result should look like as follows (roughly, as the data string shown in the image is slightly out of date, but the rest is correct), but with your own scenario name and Device ID number:


*Make sure to copy your “DeviceID” string that will be generated after setting up the service, you will need it for both preliminary testing in the next step, and later for the Arduino Sketch in Part 4.*

Step Three- Testing API and Google Spreadsheet

Before we move on to the last step, in which we program the Adafruit Feather 32u4 with LoRa Radio Module and complimentary Ethernet Feather Wing which will log data through the web, it would be helpful to test that everything we have done thus far is correct. If we wait to complete the hardware portion then the cause of any errors may be more difficult to track down. Fortunately, we have a simple method of testing our code so far. We can just directly enter some hard-coded pseudo-data into our web browsers address bar and check that our Google sheet is being updated correctly. Here is an example of what you might copy and paste into your browsers address bar.

http://api.pushingbox.com/pushingbox?devid=<<YOUR-PUSHINGBOX-DEVICEID>>&key0=sheetID&val0=<<SPREADSHEET-ID>>&key1=tabID&val1=<<SHEET/TAB-OF-SPREADSHEET>>&key2=deviceID&val2=<<NAME-GIVEN-TO-ARDUINO>>&key3=TimeStamp&val3=50&key4=TempC&val4=200&key5=Humid&val5=80&key6=LoadCell&val6=1000&key7=IRLight&val7=2000&key8=FullLight&val8=3000&key9=BatVolt&val9=4.2
 

If you like you can even re-enter new fake data with different values for subsequent rows, however, remember you only have a 1,000 requests per day from Pushingbox.com so don’t go crazy! If this procedure did not update your spreadsheet then go back and review Parts 1 -3 of this instructional for errors before attempting Part 4. Congratulations if you have made it this far, the worst is over! (it took me about a dozen times to get all the previous steps correct) Update – the modification of this process and the Google Script since the initial writing of this blog post were primarily to simplify these steps


Step Four – Hardware Set-up and Arduino Sketches

After confirming you were able to push some hard-coded pseudo-data directly from your browser onto your Google Sheet you are now ready for the next step which involves sending data directly from the Feather 32u4 and complimentary Ethernet Feather Wing to Google via Pushingbox over an Ethernet connection. Before you can upload and run the included Arduino sketch to the Feather Board you must complete the following three steps.

Hardware

1. Wiring the Feather 32u4 board to the Ethernet FeatherWing:  a guide on how to do this can be found on the adafruit website here, as well as one of my previous posts, found here.

Software(1):

2. There are a few steps to set up your Arduino IDE to work with your Feather 32u4 board.. These steps include downloading the necessary libraries and configuring the Arduino IDE (1.6.4 or later) with the correct Feather Board package. Many of you will have already installed all the software you need, for those that have not, below are links to retrieve the needed libraries and the Feather 32u4 board support package.

The two required libraries for our particular sketch:

Two great tutorials to walk you through getting the correct Feather 32u4 board and Ethernet FeatherWing package installed into the Arduino IDE if you haven’t done this already:

Software(2):

3. You are now ready for the final step of the project, you need to copy and paste the included Arduino sketch, customize it for your device, and then upload the sketch onto your Feather 32u4 board and Ethernet FeatherWing. Update – that sketch is now out of date, refer to the Loom Library instead for the corresponding updated code and process.

A) Your MAC Address (Found in Ethernet packaging)

B) Your Static IP address (May need to be given by IT admins)

C) Your Pushing box Device ID (devid)

That’s it, you’re done! If everything was completed correctly your output will look something like the picture below:


Populated Google Spreadsheet (left) and Ardiuno IDE with example code.Populated Google Spreadsheet (left) and Ardiuno IDE with example code.

Populated Google Spreadsheet (left) and Ardiuno IDE with example code.


Final Receiver and Ethernet data logger set-up.Final Receiver and Ethernet data logger set-up.

Final Receiver and Ethernet data logger set-up.

– Tom DeBell, Beginning Researcher Support Program Researcher

Visit to HJ Andrew’s Experimental Forest

Author: Marissa Kwon


Abstract: 

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

Installing the Hub:

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


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

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


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

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


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

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

Deploying the Evaporometer:  

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


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

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


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

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


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

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

– Marissa Kwon, URSA Engage and Summer REU Student Researcher

Evaporimeter System Testing

Abstract:

The system has been completed and we are now testing the components’ response to semi-realistic conditions. I say semi because it is only being tested right outside the lab. Here is what our setup looks like. 

Objective: 

With these tests that we are running, we aim to verify the functionality of the whole system. We need to make sure that the receiver and transmitter are communicating. On the receiver side, we want to see that it can run on the power supply and no connection to a computer. On the transmitter side, we want it to run on battery and be able to transmit all the data coming in from the sensors. We also intend to verify the data coming in from the sensors.

Materials and Methods:
We are going to implement an evaporimeter system right outside the lab and test the components’ response to the local enviroment. 

To simulate a rainfall we will use the OPEnS Lab rain catcher calibrator with the 20 min setting. Here is the setup:  


OPEnS Lab Evaporimeter TransmitterOPEnS Lab Evaporimeter Transmitter

OPEnS Lab Evaporimeter Transmitter

The image above displays the evaporimeter in action. 


OPEnS Calibrator SetupOPEnS Calibrator Setup

OPEnS Calibrator Setup

We set the calibrator setup above the evaporimeter and allowed it to drip 500ml of water in 20min. 

We have been testing the system and fixing anything to have it ready for deployment; this was all done during July 17th-21st. We will be doing more testing on the 24th to finalize the data collection and begin the analysis. 

One final thing to do is to print the electronics casing in white to prevent the humidity and temperature sensor from reporting incorrect data from the heat absorption of the black plastic. 

Evaporimeter Deployment Outside OPEnS lab

Author: Marissa Kwon

ABSTRACT

This post is dedicated to our testing results and a few comments about why the Evaporimeter’s first test took so long to complete!

OVERCOMING OBSTACLES


The Evaporimeter on its first test run - mainly for the purpose of debugging and monitoring battery consumptionThe Evaporimeter on its first test run - mainly for the purpose of debugging and monitoring battery consumption

The Evaporimeter on its first test run – mainly for the purpose of debugging and monitoring battery consumption

Ambitious First Testing: While the basic Evaporimeter was fitted with a transmitter and load cell long ago in previous posts, this fairly simple (in C language) task left plenty of room for other functions to be added to our micro controller’s memory.  For quite some time new sensors and features to better our transmitter just kept coming, causing our Evaporimeter to evolve into more of a multipurpose climate sensor.   To have the best first testing experience, we decided to implement those components to collect useful data about the environment and save battery that eventually made it into our final design.

“It Was Just Working Yesterday…”: Prior to testing on Thursday, temperature and humidity data was printing as NaN.  We made sure this was not due to a coding error or a broken sensor and determined the problem was with a faulty I2C connection.  This issue was fixed by switching out the wire wrapped connections with female wire connectors.

TESTING DETAILS

On Thursday 7/13 and Friday 7/14 the Evaporimeter was placed outside and set to record data from 9 am to – 5 pm.  The receiver was left inside connected to an SD card writer, but for this test no data was recorded online.

We programmed alarms to occur every five minutes, so the timestamps below should show data collection at 5 min intervals.  Data to the SD card reads dev ID, timestamp, temperature, humidity, load cell, infrared light, full spectrum light, and battery voltage.  Data from the transmitter is sent as a string separated by commas in a way that is compatible with online google spreadsheets, the final destination for our data once the Evaporimeter is deployed in HJ Andrew’s Experimental Forest.

We placed the Evaporimeter outside with a fully charged battery (at 4.2 volts) we could see how the voltage dropped gradually over the course of a few hours while time stamps could indicate exactly how much time the Evaporimter could run before the battery is cut off (approaching 3.2 volts).  Roughly .2-.3 volts were lost over 24 hour’s time with data being sent at 5 min intervals.  By calculating the total amount of cycles that can be completed with these values, we can safely estimate that the battery would last anywhere from 1.3 – 2 months when data is transmitted on an hourly basis.


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

A sample of data written to SD card – with NaN data and test data with timestamp and voltage.  Data on each line reads dev ID, timestamp, temperature, humidity, load cell, infrared light, full spectrum light, and battery voltage.

Note: We continued to double check and tweak parts of the Evaporimeter during the test on 7/13 explaining the timestamps jumping from 9 – 9:35 and 9:35 – 11:20 at the beginning.

Editor’s note:  After reviewing the data written from our SD card it was evident that closer to .2-.3 volts was being used per day and the first estimation was overly optimistic.  This information was overlooked at first due to the transmitter being off for quite some time on 7/14/17, and more accurate battery life estimations have replaced the incorrect information below:

 [Roughly .2 volts was lost over the course of two days when the transmitter runs continuously waking at 5 min intervals – giving the battery a maximum of 10 days to run if fully charged.  With these values the microcontroller can enter and wake from sleep mode 288 times before the battery drops 0.1 volt. With hourly alarms and we can reasonably estimate the battery will last a few months].

   – Marissa Kwon, Summer REU Student Researcher

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

Author: Marissa Kwon

ABSTRACT

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

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

COMPONENTS

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


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

ADAFRUIT FEATHER 32u4 RFM95 LoRa Radio – 915 MHz

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



3013-01.jpg

ADAFRUIT DS3231 PRECISION RTC

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


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

ADAFRUIT SHT31-D Temp/Humidity Sensor

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


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

ADAFRUIT TSL2591 FULL/INFRARED SENSOR

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


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

HX711 LOAD CELL and STRAIN GAUGE

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

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

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

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

– Marissa Kwon URSA/Summer REU Student Researcher

Preparing Evaporometer for Andrew’s Cyber Forest Deployment

Author: Chet Udell


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

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

Abstract

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

Objectives

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

Devices

Transmitter nodes consist of the following:

Hub consists of:

Method of use

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

Deployment will take place July 27.

We’re Getting Closer! Adding More Functionality to the Final Produce

Author: Marissa Kwon

Abstract:

We’re releasing details about our project after ten weeks of development including support for portable limply batteries, project code/resources, and why some additional functionality is necessary before deployment.


IMG_1984.JPGIMG_1984.JPG

Why It’s Best to Wait:

After much discussion about integrating more functionality into our the Lora/Super Validator, we have decided to postpone field tests for now in favor of adding a few more weather and climate sensors to the Super Validator, measuring power consumption, and saving power by adding in an external clock to enable the micro controller to go into sleep mode until the clock’s alarm periodically wakes it.

What’s Next:

I have a working temperature and humidity sensor set up to write out data measured to an SD card, and our next goal is to be able to set up the LoRa radiopacket array to also send these values to from a remote location.  Granted that these field devices also won’t have unlimited or even large supplies of power readily available, I don’t want our Lora to be wasting power by constantly sending information and waiting for a reply.  Since climate and weather change gradually the user would only need readings about once or twice an hour.  The micro controller is capable of saving power by entering a sleep mode, however it also need and external device to interrupt its sleep so that it can do its job.  That’s when a real time clock will come in handy by sending an alarm to the Protrinket at a certain time every hour to wake it up; after all transmission code is done, the Protrinket can go back to sleep.

Currently our device is powered by a 3.7V, 1000mAh Lithium Polymer battery. Once all the components are working together, I will need to measure the current draw of each component to estimate the final battery life.

Links to Resources:

Here are links to our most recent LoRa Super Validator transmitter and receiver code.

Also here are links the Adafruit site for the new components: SD card reader, Real time clock, and temp/humidity sensor.

And finally here’s more information about the LiPo battery.

MSDS sheet for the LiPo battery

– Marissa Kwon URSA Undergraduate Student Researcher

Electronics Enclosure for Evaporimeter

Having the electronics secured and accessible on the evaporimeter is essential. The solution that we came up with is having a transparent jar that would screw on the evaporimeter’s pole attachment. Here is the updated design:

When turned to the underside, one can see the extruded base to accommodate the threads and the breadboard and battery compartments. The breadboard slot might be edited to have a slide in feature instead of having a little slot to hold it in. The battery slot is just fine. Here are some pictures of the assembled pole attachement with the jar:


Assembled EvaporimeterAssembled Evaporimeter

Assembled Evaporimeter


Pole attachment without the jar.Pole attachment without the jar.

Pole attachment without the jar.

The inside is not a smooth print because it prints on the support material, but we are more concerned about function of the inside piece and not the aesthetics. 


Jar and pole attachment&nbsp;Jar and pole attachment&nbsp;

Jar and pole attachment 

A humidity/temperature sensor and a uSD card adapter are being added to the electronics. I prototyped these new electronics and wrote code for them. An intern here at the lab is integrating the code and new electronics into the current design. 

A First Look at Field Deployment

Author: Marissa Kwon

Abstract:

As progress on the LoRa radios leads to integration into the Evaporometer Project, we take a closer look at some of the aspects of data transmission and providing portable power.

Sending and Printing Float Data:

The LoRa radios use packetized sending of 8 bit integers (corresponding to ACSII values) to relay integer and float data by first taking the integer value, changing each decimal value into the corresponding character (ASCII) value using iota(), and adding this info to the radio packet to be sent.  On the receiving end, the data from the packet array is copied into a separate array, for our purposes its an array of 7 elements/bytes, and uses iota() to change it back into the correct integer value.

For float values to be sent, you need select a decimal value the suits your precision needs.  For the Evaporometer we only decimal values to the ten thousandths place, and since our load cell will be taking measurements < 1000 grams I will need a maximum of 7 digits to store my data. The only difference I needed to make to send floats was to multiply the load cell’s measurement by 10,000 before setting it to the packet, and dividing by 10,000 in the receiver end.  In order to print a float value, I also needed to include the precision value when using Serial.print() like so:

Serial.println(my_array,4);

Attaching the Battery Backpack:

For our field test, it will necessary to rewire the LoRa chip, load cell, and pro trinket onto a smaller breadboard that can fit onto the housing designed for the Evaporometer.  The Pro trinket is now powered off a portable LiPo battery.  The micro-usb connector on the Pro trinket powers the device as well, and plugging the device into a wall outlet through the usb also recharges the LiPo battery.  To improve signal strength the soldered in wire antenna was replaced with uff connector so that a larger antenna could be attached to the LoRa chip. The change in RSSI signal strength measured in the serial monitor reflected the changes I made to the antenna as well as the changes to the operating frequency (after we ramped up our new frequency to 915mHz).


Li-Po battery backpack connected to the ground, 5V, and bus pins on the Pro trinketLi-Po battery backpack connected to the ground, 5V, and bus pins on the Pro trinket

Li-Po battery backpack connected to the ground, 5V, and bus pins on the Pro trinket


transmitter ready for housing;&nbsp;fitted with LiPo battery and uFL antenna (with pen to scale size)transmitter ready for housing;&nbsp;fitted with LiPo battery and uFL antenna (with pen to scale size)

transmitter ready for housing; fitted with LiPo battery and uFL antenna (with pen to scale size)

 Marissa Kwon  URSA Program Undergraduate Student Researcher

Super Validator Wick

Cutting up the wick has been the last part of getting the evaporimeter completed. The method used to cut the wick is quite unique. We placed densely-packed wick inside an acrylic tube and then froze it. This is done so that the wick is easier to cut because when it is dry it is difficult. Freezing it allows us to cut it with a bandsaw really quick.The wick is as long as the tube itself and then cut to size.  Here is a picture of what the setup should look like: 


Setup of the wick inside the tube.Setup of the wick inside the tube.

Setup of the wick inside the tube.

After cutting them we just insert them into the evaporimeter and let the water melt. We then fluff the wick and the system is ready to go. The only problem with this method is that the wick gets dirty while cutting. The bandsaw cleans itself on the wick and since the wick is white it is really noticeable.


Fiberglass wick after cutting and fluffingFiberglass wick after cutting and fluffing

Fiberglass wick after cutting and fluffing