Monitoring Air Quality in the Great Smoky Mountains with a Network of Low-cost Air Quality Sensors

Al Fischer, PhD

Instrumentation Specialist | Department of Chemistry and Physics | Western Carolina University

dfischer@wcu.edu

Introduction

For decades, air quality regulators have relied government-sponsored air quality monitoring sites to ensure regulatory compliance (attainment) of air quality standards. These sites house instrumentation that meets the analytical standards set forth by the Environmental Protection Agency (Federal Equivalent Methods, FEMs) and provide exceptionally high-quality data. However, such instrumentation involves a large up- front purchase price and the sites can be costly to maintain and sometimes subject to political will. Although this approach has overall led to stark improvements in air quality nationwide, it has created a relatively sparse network of sensors that may neglect hyperlocal conditions such as areas directly downwind from a point- source of air pollution (e.g. a factory) or in a mountain cove where many residents heat with wood. (1)

Over the past decade, improvements in low-cost and open-source microcontrollers combined with rapid development and cost-reductions in environmental sensors have made it possible to take a new approach to monitoring air quality. It is now possible to deploy dozens of low-cost (100-200) sensors for much less than the price of one regulatory site, which enables collection of hyperlocal data and offers an opportunity to involve non-scientists in data collection through citizen science. (2) Such an approach has been used for decades by the Audubon Society with their annual Backyard Bird Count, by Weather Underground in the collection of weather data, and – more recently – by Purple Air in the collection particulate matter data. Although some sacrifices are made in data quality, such as lower sensitivity and a need to focus on relative (rather than absolute) trends, these sacrifices are somewhat offset by the high spatial resolution and redundancy inherent in a network of many sensors where there was previously only one. Moreover, similar studies have found such sensors “may indeed be suitable for air quality, health, and urban aerosol research” when comparing to FEMs. (3)

During this study, students enrolled in Chemistry 191: Issues in Environmental Chemistry at Western Carolina University will develop low-cost sensors capable of being deployed in a network such as that discussed above. Each sensor will measure temperature, relative humidity, barometric pressure, volatile organic carbon (VOC) abundance, and concentration of particulate matter less than 2.5 μm in diameter (PM2.5) and will cost roughly 100.0 Once complete, the sensors will be deployed for a field campaign at a “pristine” site at Purchase Knob in the Great Smoky Mountains National Park and at a rural-urban site in Sylva, NC.

Note that this is a primarily educational project that aims to engage students in learning about air quality and chemical analysis. The student goals of the study are to: (1) compare PM2.5 levels between a pristine and urban site and track changes in PM2.5 levels at both sites during the transition from fall into winter, (2) look for correlations between the sensors’ VOC readings and ozone concentrations reported by the North Carolina Department of Environmental Quality ozone sensor installed at Purchase Knob, and (3) validate the sensors’ temperature, humidity, and pressure readings against the research-grade weather station installed at Purchase Knob.

Materials and Methods

Hardware Design

The Cullowhee Clean Air ("wheeCAIR") sensors are sub-100 sensors capable of measuring temperature, relative humidity, pressure, volatile organic compounds (VOCs), and particulate matter (PM). At the heart of the sensor is a 32-bit, 120 MHz ARM Cortex-M4 microcontroller in the form of a Teensy 3.5 (pjrc.com). The Teensy 3.5 contains an onboard real-time clock and SD card for long-term data logging, and communicates with a Honeywell HPMA115S0-XXX PM sensor via one of its serial ports and an Bosch BME-680 temperature, humidity, pressure, and VOC sensor via the I<sup>2</sup>C protocol. Table 1 provides part numbers for the sensors, while the figure below shows a block diagram of the wheeCAIR sensors. A full bill-of-materials is available in Appendix 1, and photos of the sensors are provided in Appendix 2. The microcontroller, both sensors, and a battery pack are connected via a custom printed circuit board (PCB, OSHPark) and housed in a weatherproof PVC type-LB conduit body with a 3.2 cm diameter opening at the top and bottom for air ingress and egress, respectively (Figure A2-2). A small fan in the HPMA sensor actively draws air into the enclosure. Sensors may be powered either by a battery pack (3 1.5 V alkaline batteries or a 5V rechargeable battery) or by USB.

**Figure 1:** Block diagram of the wheeCAIR sensors. The battery pack consists of 3 C-type batteries and may be replaced with a standard 5-V USB power supply or rechargeable batter pack if desired. Block diagram of the wheeCAIR sensors. The battery pack consists of 3 C-type batteries and may be replaced with a standard 5-V USB power supply or rechargeable batter pack if desired.

Table 1: Component Sensors in the wheeCAIR Platform

MeasurementSensor
Particulate Matter (PM$_{2.5}$)Honeywell HPMA115S0-XXX
Volatile Organic Carbon (VOC)Bosch BME-680
TemperatureBosch BME-680
Relative HumidityBosch BME-680
PressureBosch BME-680

Software Design

The wheeCAIR sensors were programmed using the Arduino "language" and IDE (Arduino.cc), with the Teensyduino add on (pjrc.com). The sensors were designed and programmed for prolonged battery life to allow long-term field experiments where power is not available. The sensors are usually kept turned off after each measurement and the microcontroller is placed in a low-power hibernation mode. The microcontroller wakes every 10 minutes to turn the sensors one, complete a 30-second measurement, record the timestamp, and log the data. Standard C-type alkaline batteries will last at least one month using this program. A block diagram of the sensor algorithm is show in the figure below.

Block diagram of the wheeCAIR program. Block diagram of the wheeCAIR program.

Field Deployment

The sensors were deployed at The Appalachian Highlands Science Learning Center near Purchase Knob in the Great Smoky Mountains National Park on October 21, 2019. The sensors were affixed to trees using cable ties and left to collect data until November 17, 2019, at which point they were collected and the data were retrieved from the SD cards. A full list of sensor GPS coordinates is located in Appendix 3.

Results and Data Processing

Data are archived and freely available on GitHub. Please attribute the author if you use the data or design for the sensor. The structure of the data repository is as follows:

WheeCAIR
       |----- data
       |         |----- [location] (see codes below)
       |                       |----- [year] > [date_sensorName].txt
       |                                 |   > [location-year].jmd or .jl - Julia data processing code
       |                                 |   > [location-year].html - HTML formatted lab notebook
       |                                 |----- datasheets > datasheets completed at deployment
       |                                 |----- img > Webcam/weather images (if available)
       |                                 |----- met > meteorology data (if available)
       |                                 |----- plots > PDFs of key figures
       |----- firmware > code used program sensors
       |----- hardware > hardware info

Initial Look at the Data

Data processing is done using the open-source language Julia. To aid in data processing, I will use several additional packages. The following code will import those packages. They can be installed first with import Pkg; Pkg.add("PackageName") if necessary.

using CSV # used to read CSV files easily
using DataFrames # used for R- or Pandas-like data frames
using Plots # used for plotting
using Dates # used for timestaps
using Statistics # statistical tools
using StatsPlots  # boxplots
using Query # DataFrame queries

Of course the first step is to import the data:

X = CSV.read.(
        joinpath.(pwd(), filter!(s -> occursin(r"\.TXT", s), readdir()),),
        header = false,
    );

The next steps give the columns names and then formats the time column correctly. Note that Daylight Saving Time ended on November 3, 2019 and that the sensor clocks do not update. This will be fixed here as well.

for i = 1:length(X)
    rename!(X[i], [:Sensor, :Timestamp, :T, :RH, :P, :VOC, :PM]) # give columns logical names
    X[i][!, :Timestamp] = Dates.DateTime.(X[i][!, 2], "YYYY-mm-dd HH:MM:SS") # convert from string to time
    X[i][X[i][:, :Timestamp].>Dates.DateTime("2019-11-03T02:00:00"), 2] =
        X[i][X[i][:, :Timestamp].>Dates.DateTime("2019-11-03T02:00:00"), 2] .+
        Dates.Hour(-1) # Subtract one hour for DLST
end

Now I can take a quick glance at the data. I will look at the temperature data and PM data to see if I can spot any problems.

p = plot(grid = false, legend = :outertopright,
    framestyle = :box, fg_legend = :transparent
)
for i = 1:length(X)
    p = plot!(
        X[i][!, :Timestamp], X[i][!, :P],
        label = X[i][1, :Sensor]
   )
end
xlabel!("Timestamp"); ylabel!("Temperature (°C)");
display(p)

I note several issues:

  • The EBAM sensor has a timing issue – the real-time clock reset to the programming time upon deployment. (time shifted)

  • The APBW sensor did not collect data. (0 reading throughout deployment)

  • The sensors were not turned off until returning to Dillsboro, NC. (spike in pressure at end of deployment)

  • Harder to see is that the CBALEJ sensor only collected data unil about 2019-11-05 and will have fewer data points than the rest.

# fix EBAM problem:
X[1][!, 2] = X[1][!, 2] + (X[2][1, 2] - X[1][1, 2]);

# remove APBW data:
deleteat!(X, 3);

# remove last bit after leaving GRSM with sensors still running:
for i in 1:length(X)
    X[i] = X[i][1:end-50, :]
end

Now, plotting the corrected data using the previous plotting code it looks much better:

Examining the rest of the data:

axis_labs = ["Temperature (°C)", "RH (%)", "Pressure (mbar)", "VOC (arb.)", "PM (\\mug / m³)"];
for ci = 3:7 # data columns for plotting as y
    p = plot(
        label = X[1][1, 1],
        grid = false
    )
    for i = 1:length(X)
        p = plot!(
            X[i][!, 2], X[i][!, ci],
            label = X[i][1, 1],
            legend = :outertopright
        )
    end
    xlabel!("Timestamp"); ylabel!(axis_labs[ci-2])
    display(p)
end

Bosch BME-680 Performance

The Bosch BME-680 will be compared to the data from the NOAA weather station located at Purchase Knob.

noaa = CSV.read("met/222X.DAT", skipto = 5, header = false);
rename!(noaa, Symbol.(Array(CSV.read("met/222X.DAT", skipto = 2, limit = 1, header = false)[1, :])));
noaa[!, :TIMESTAMP] = Dates.DateTime.(noaa[!, :TIMESTAMP], "YYYY-mm-dd HH:MM:SS");
noaa = noaa[noaa[!, :TIMESTAMP] .> minimum(X[1][!, :Timestamp]), :];
noaa = noaa[noaa[!, :TIMESTAMP] .< maximum(X[1][!,  :Timestamp]), :];
noaa[noaa[!, :RH_Avg] .> 100, :RH_Avg] .= Ref(100);

Temperature

Data from NOAA is provided every 15 minutes. Data from wheeCAIR sensor is provided every 10 minutes. Data for both will be aggregated into 1-hour averages for this reason.

It appears there was a 1-hour offset between the NOAA and wheeCAIR sensors; I removed this offset.

noaa[!, :Hour] = floor.(noaa[!, :TIMESTAMP], Dates.Hour);
noaa_mean = DataFrame(
    Timestamp = unique(noaa[!, :Hour]),
    T = aggregate(noaa[!, [:AirTC_Avg, :Hour]], :Hour, mean)[!, :AirTC_Avg_mean],
    RH = aggregate(noaa[!, [:RH_Avg, :Hour]], :Hour, mean)[!, :RH_Avg_mean]
);

whee_mean = []
for i in 1:length(X)
    X[i][!, :Hour] = floor.(X[i][!, :Timestamp] - Dates.Minute(60), Dates.Hour);
    df = X[i][!, [:T, :Hour]]
    insert!(whee_mean, i, DataFrame(
        Timestamp = unique(df[!, :Hour]),
        T = aggregate(X[i][!, [:T, :Hour]], :Hour, mean)[!, :T_mean],
        RH = aggregate(X[i][!, [:RH, :Hour]], :Hour, mean)[!, :RH_mean],
        Sensor = X[i][1, :Sensor]
    ))
end

t_ts = plot(grid = false, legend = :outertopright,
    framestyle = :box, fg_legend = :transparent,
    ylims = (-20, 30)
)
for i = 1:length(whee_mean)
    p = plot!(
        whee_mean[i][!, :Timestamp], whee_mean[i][!, :T],
        label = whee_mean[i][1, :Sensor]
   )
end
plot!(noaa_mean[!, :Timestamp], noaa_mean[!, :T], label = "NOAA")
xlabel!("Timestamp"); ylabel!("Temperature (°C)");
savefig("plots/temp_timeseries.pdf")
display(t_ts)

t_scatter = scatter(
    grid = false, legend = :topleft,
    framestyle = :box, fg_legend = :transparent,
    xlims = (-20, 30), ylims = (-20, 30),
)
for i in 1:length(whee_mean)
    scatter!(
        noaa_mean[1:nrow(whee_mean[i]), :T],
        whee_mean[i][!, :T], label = whee_mean[i][1, :Sensor]
    )
end
one_to_one(x) = 1*x+0;
plot!(one_to_one, -30, 40, color = :black, linestyle = :dash, label = "1:1")
ylabel!("Temperature-wheeCAIR (°C)"); xlabel!("Temperature-NOAA (°C)");
savefig("plots/temp_scatter.pdf")
display(t_scatter)

The scatter plot above shows all wheeCAIR temperature readings against the NOAA weather station readings. A 1:1 line is shown for comparison. For clarity, lines of best-fit for each specific sensor are omitted here.

t_box = plot(
    legend = :none, fg_legend = :transparent,
    framestyle = :box,
    ylims = (-10, 15), xlims = (0,8)
    )
for i in 1:length(whee_mean)
    violin!(
        whee_mean[i][!, :Sensor], whee_mean[i][!, :T] .- noaa_mean[1:nrow(whee_mean[i]), :T],
        label = whee_mean[i][1, :Sensor]
    )
end
for i in 1:length(whee_mean)
    boxplot!(
        whee_mean[i][!, :Sensor], whee_mean[i][!, :T] .- noaa_mean[1:nrow(whee_mean[i]), :T],
        label = nothing, fill = :transparent, marker = :gray
    )
end
hline!([1, -1], linestyle = :dash)

xlabel!("Sensor Number"); ylabel!("\\Delta T (°C vs. NOAA)")
savefig("plots/temp_boxplot.pdf")
display(t_box)

The box and violin plot above shows the statistics and distribution for of the difference in temperature measured by each wheeCAIR sensor and the NOAA station. In other words, all sensors should show a tight distribution around 0 if accurate. The manufacturer specifies a temperature accuracy of ±1°C for the BME-680 , and all sensors showed a median difference (median shown as the middle line on the box plots) within that error (dashed lines represent ±1°C). However, all sensors showed deviation far outside this range at times. It appears the more exposed sensors had larger fluctuations in temperature (as would be expected). For example, the EBAM sensor was installed on the side of the air-quality shed at Purchase Knob and received more direct sunlight than any other sensor. Resultantly, it often reads higher temperature than the others. Likewise, the CBALEJ, AHRR, and RRMD sensors were the most sheltered (located under in the forest under tree cover) and showed the smallest spreads compared to the NOAA sensor. It's unclear how much of this spread is due to siting and/or sensor design and how much is due to imprecision in the sensor itself at this point.

rh_scatter = scatter(
    grid = false, legend = :topleft,
    framestyle = :box, fg_legend = :transparent,
    xlims = (0, 100), ylims = (0, 100),
)
for i in 1:length(whee_mean)
    scatter!(
        noaa_mean[1:nrow(whee_mean[i]), :RH],
        whee_mean[i][!, :RH], label = whee_mean[i][1, :Sensor]
    )
end
plot!(one_to_one, -10, 110, color = :black, linestyle = :dash, label = "1:1")
ylabel!("RH-wheeCAIR (%)"); xlabel!("RH-NOAA (%)");
savefig("plots/rh_scatter.pdf")
display(rh_scatter)

The scatter plot above shows all wheeCAIR RH readings against the NOAA weather station readings. A 1:1 line is shown for comparison. For clarity, lines of best-fit for each specific sensor are omitted here.

rh_box = plot(
    legend = :none, fg_legend = :transparent,
    framestyle = :box,
    ylims = (-100, 100), xlims = (0, 8)
)
for i in 1:length(whee_mean)
    violin!(
        whee_mean[i][!, :Sensor], whee_mean[i][!, :RH] .- noaa_mean[1:nrow(whee_mean[i]), :RH],
        label = whee_mean[i][1, :Sensor]
    )
end
for i in 1:length(whee_mean)
    boxplot!(
        whee_mean[i][!, :Sensor], whee_mean[i][!, :RH] .- noaa_mean[1:nrow(whee_mean[i]), :RH],
        label = nothing, fill = :transparent, marker = :gray
    )
end
hline!([3, -3], linestyle = :dash)
xlabel!("Sensor Number"); ylabel!("\\Delta RH (% vs. NOAA)")
savefig("plots/rh_boxplot.pdf")
display(rh_box)

The box and violin plot above shows the statistics and distribution for of the difference in relative humidity measured by each wheeCAIR sensor and the NOAA station. In other words, all sensors should show a tight distribution around 0 if accurate. The manufacturer specifies a temperature accuracy of ±3% RH for the BME-680, and most sensors showed a median difference outside that range. (shown as the middle line on the box plots) within that error (dashed lines on the plot at ±3% RH). Further, all sensors showed deviation far outside this range at times. It appears the more exposed sensors had larger fluctuations in temperature (as would be expected). There is no apparent trend with location or siting of the sensors, so I must conclude that this is likely due to inaccuracies in the BME-680 sensors and not due to poor siting of the wheeCAIR sensors.

Exploring PM Data

using Query
rh_over80 = @from i in noaa begin
     @where i.RH_Avg > 80
     @select {Timestamp = i.TIMESTAMP}
     @collect DataFrame
 end

pm_ts = plot(
    grid = false, legend = :outertopright,
    framestyle = :box, fg_legend = :transparent,
    ylim = (0, 1000)
)
for i in 1:length(X)
    plot!(
        X[i][!, :Timestamp], X[i][!, :PM],
        label = X[i][1, :Sensor]
    )
end
plot!(rh_over80[!, :Timestamp], seriestype = :vline, alpha = 0.1, color = "#1E90FF", label = "RH > 80%")
xlabel!("Timestamp"); ylabel!("[PM] \\mug / m³")
display(pm_ts)

Note the large spikes. This is unexpected. The sensors saturate just under 1000 μg/m$^3$, so many of these spikes represent saturated sensor conditions. This site should not be experiencing PM concentration that high so often, so this is likely a sensor issue.

One expected source of error is fog. The RH readings from the NOAA weather station seem to corroborate this, as spikes are observed everywhere RH > 80%.

An image from the webcam on 2019-10-30 12:00 EDT (shown below) confirms fog was present; likewise, spot checking images from other times indicates the same.

These data will be excluded from further analysis.

A Purchase Knob webcam image from 2019-10-30 12:00 EDT showing fog present. A Purchase Knob webcam image from 2019-10-30 12:00 EDT showing fog present. [National Park Service/public domain]

for i in 1:length(X)
    X[i][X[i][!, :RH] .> 80, :PM] .= Ref(NaN);
end

whee_pm = [];
for i in 1:length(X)
    X[i][!, :Hour] = floor.(X[i][!, :Timestamp] - Dates.Minute(60), Dates.Hour);
    df = X[i][!, [:T, :Hour]]
    insert!(whee_pm, i, DataFrame(
        Timestamp = unique(df[!, :Hour]),
        PM = aggregate(X[i][!, [:PM, :Hour]], :Hour, mean)[!, :PM_mean],
        Sensor = X[i][1, :Sensor]
    ))
end
pm_ts = plot(
    grid = false, legend = :outertopright,
    framestyle = :box, fg_legend = :transparent
    # ylim = (0, 20)
)
for i in 1:length(whee_pm)
    plot!(
        whee_pm[i][!, :Timestamp], whee_pm[i][!, :PM],
        label = whee_pm[i][1, :Sensor]
    )
end
xlabel!("Timestamp"); ylabel!("[PM] (\\mug / m³)");
savefig("plots/pm_timeseries.pdf");
display(pm_ts)

pm_scatter = plot(
    grid = false, legend = :bottomright,
    framestyle = :box, fg_legend = :transparent,
    xlims = (0, 10), ylims = (0, 10)
)
for i in 1:(length(whee_pm)-1)
    mini = min(nrow(whee_pm[i]), nrow(whee_pm[length(whee_pm)]));
    scatter!(
        whee_pm[length(whee_pm)][1:mini, :PM], whee_pm[i][1:mini, :PM],
        label = string(whee_pm[i][1, :Sensor], " vs. VBAC")
    )
end
plot!(one_to_one, -5, 15, color = :black, linestyle = :dash, label = "1:1")
xlabel!("[PM]-VBAC (\\mug / m³)"); ylabel!("[PM]-Other (\\mug / m³)");
savefig("plots/pm_scatter.pdf");
display(pm_scatter)

After excluding data collected during periods of high humidity, the PM data seem to more-or-less agree with each other. The scatter plot above shows all sensors plotted against the arbitrarily chosen VBAC sensor; the 1:1 line is shown as the dashed line for comparison. Again, individual best fits for all sensors are not shown in the pursuit of providing a clear graphic. Notably, the CBALEJ sensor was very low throughout the run, indicating a potential problem with this specific sensor that did not exist with the others. Likewise, the RRMD sensor was often higher than the others, although the co-located AHRR sensor does not appear to show such large spikes. Again, this seems likely to be due to the sensor manufacturing distribution rather than atmospheric phenomena.

Conclusions & Future Directions

The goal of this study was to allow students to conduct a first test of their wheeCAIR sensors in a realistic environment. In general, the sensors performed well. Difference in meterology readings compared to the NOAA station are either within the error specification of the sensors, or can be explained by poor siting/exposure (e.g. sensors that read higher temperatures were often exposed to direct sunlight). In general, PM readings seem to correlate well between sensors, although it's impossible to say from this data if they are accurate. Future work will compare the sensors to a federal equivalent monitor to test accuracy. Future work will also explore the differences observed in the meteorology data and attempt to identify/employ better siting protocols to avoid inaccuracies in the data.

The major problem noted during the study was the susceptibility of the sensors to fog. There are presumably several ways around this, which could include hardware improvements (e.g. adding a Nafion dryer/diffusion dryer or heating the air prior to measurement) and/or software improvements (e.g. using image recognition to find periods of fog and automatically exclude those data). Future work will focus on both avenues for improvement.

As a final note, the VOC data is not yet analyzed here. Initial results showed it to be highly variable, show little correlation between sensors, and be very temperature-dependent; therefore, it is not shown here.

References

  1. Julien J. Caubel, Troy E. Cados, Chelsea V. Preble, and Thomas W. Kirchstetter. “A Distributed Network of 100 Black Carbon Sensors for 100 Days of Air Quality Monitoring in West Oakland, California” Environmental Science & Technology 2019 53 (13): 7564-7573. DOI: 10.1021/acs.est.9b00282

  2. Nuria Castell, Franck R. Dauge, Philipp Schneider, Matthias Vogt, Uri Lerner, Barak Fishbain, David Broday, Alena Bartonova. “Can commercial low-cost sensor platforms contribute to air quality monitoring and exposure estimates?” Environment International 2017 99: 293-302. DOI: 10.1016/j.envint.2016.12.007

  3. Brian I. Magi, Calvin Cupini, Jeff Francis, Megan Green & Cindy Hauser. “Evaluation of PM2.5 measured in an urban setting using a low-cost optical particle counter and a Federal Equivalent Method Beta Attenuation Monitor”, Aerosol Science and Technology, 2013 47:564-573. DOI: 10.1080/02786826.2019.1619915

Appendix 1: Bill of Materials

Table S.1: Bill of Materials for wheeCAIR sensor

ItemPNPriceQtySupplier
Sensor, BME 6801597-1653-ND$20.9101digikey
Sensor, PM, Honeywell785-HPMA115SO-XXX$26.3401mouser
Micro SDSDSDQM-B35A$4.5001Amazon
Teensy 3.51568-1443-ND$26.2501digikey
USB CableWM25438-ND$3.7101digikey
Case, PVC, LB Conduit BodyE986G$7.1501Lowe's
Case Port Cap-$1.6900.5Lowe's
Breadboard1738-1326-ND$2.9901digikey
Wire, Hookup, Assortment, 10x25'485-3174$29.9500.1mouser
Pin headers, Breakaway, 36 position, 0.1"WM50014-36-ND$0.9012digikey
LED, RGB1830-1014-ND$0.8291digikey
Resistor, 220 ohmCF12JT220RCT-ND$0.0721digikey
ThermistorBC2301-ND$0.6601digikey
Resistor, 1kS1KQTR-ND$0.0041digikey
Capacitor, Electrolytic, 1000uFP19639TB-ND$0.3101digikey
RelayTLP222AF-ND$1.0131digikey
Header, 5 Position, 0.1S6103-ND$0.4431digikey
Header, 24 Position, 0.1S7022-ND$1.2442digikey
Retainer, Coin Cell, 12 MM, SMD36-3000CT-ND$0.7671digikey
Terminal, 4 Position, 3.5 mmWM7860-ND$1.1212digikey
Terminal, 2 Position, 3.5 mmWM7877-ND$0.7181digikey
Batteries, AA, Duracell Procell, 2900 mAhPC1500BKD$0.5206Grainger
Batteries, Coin Cell, CR1220P033-ND$0.8281digikey
Wire, PicoBlade, Pre-crimped, black0500798000-10-B8-ND$0.6761digikey
Wire, PicoBlade, Pre-crimped, yellow0500798000-10-Y8-ND$0.6761digikey
Wire, PicoBlade, Pre-crimped, red0500798000-10-R8-ND$0.6761digikey
Wire, PicoBlade, Pre-crimped, violet0500798000-10-V8-ND$0.6761digikey
PCB, CustomWheeCAIR v1.0 (custom)$6.8201OSH Park

Prices are accurate as of December 2019.

Appendix 2: Photos of the Sensor

Sensor Photos

**Figure A2-1:** Bottom (left) and top (right) view of the sensors, as soldered and assembled by students in the CHEM 191 class. Figure A2-1: Bottom (left) and top (right) view of the sensors, as soldered and assembled by students in the CHEM 191 class.

Enclosure Photo

**Figure A2-2:** Photo of the sensors in their enclosure and installed in Great Smoky Mountains National Park Figure A2-2: Photo of the sensors in their enclosure and installed in Great Smoky Mountains National Park.

Appendix 3: Sensor GPS Coordinates

Sensor NameGPS Coordinates (UTM)LatitudeLongitudeCover Type
AHRR17 N 302441 394037535.58740-83.18052Forest
APBW17 N 312071 394016935.58742-83.07424Forest Edge
CBALEJ17 N 312071 394016935.58742-83.07424Forest
EBAM17 N 312077 394016835.58741-83.07418Field/Exposed
NCZV17 N 312077 394016835.58741-83.07418Field/Under Rhododendron
RRMD17 N 302441 394037535.58740-83.18052Forest
VBAC17 N 312071 394016935.58742-83.07424Forest Edge

Acknowledgements

This work was completed by students in the CHEM 191: Issues in Environmental Chemistry seminar at Wester Carolina University during Fall 2019. It was funded by the Department of Chemistry and Physics at Western Carolina University.

This work was conducted under National Park Service Study # GRSM-02097, permit # GRSM-2019-SCI-2097. Special thanks is attributed to Paul Super and Rhonda Wise for facilitating the project.

Published from grsm_purchase-2019.jmd using Weave.jl on 2020-03-30.