Introduction
One goal of the long-term measurement of eddy-covariance ecosystem fluxes is
to calculate annual net cumulative transport of carbon, heat, and water vapor
between the underlying surface and the atmosphere e.g.,.
In order to perform this task accurately, these yearly calculations require
continuous data (i.e., no data gaps), which places stringent demands on the
data-collection hardware and software, as well as the persons collecting the
data. The collection of such high-frequency turbulence data is rife with
challenges. Within the past 2–3 decades, many of these flux measurements have
been made from towers placed in different ecosystems, and used to monitor the
environment . These towers are often interconnected into regional
networks, such as North and South America (AmeriFlux, and
the National Ecological Observatory Network NEON, ),
Europe (EuroFlux/CarboEurope or the Integrated Carbon
Observation System; ICOS, https://www.icos-ri.eu/), Australia and New
Zealand (OZFlux, ), and Asia (AsiaFlux,
), to name a few (additional network details are available
on the main FLUXNET website, https://fluxnet.ornl.gov/) .
Part 1 of our three-part paper describes the data acquisition system used at
the Niwot Ridge Subalpine Forest AmeriFlux site (US-NR1, ),
with an emphasis on how the system has evolved over time. Part 2 describes the US-NR1 site characteristics and
Part 3 describes the data quality assurance (QA/QC), gap-filling, and in situ
tests for checking long-term data quality. Overall, the underlying
philosophies used to collect and process the US-NR1 data (and which part it
is related to) are as follows:
whenever possible (and reasonable), collect and archive data at as high a
sample rate as possible (Part 1);
for high-frequency data, time stamps of individual data samples
are essential (Part 1);
provide real-time data monitoring (Part 1);
have a robust method for documenting and smoothly handling
additions and/or removals of instrumentation at the site (Part 1);
provide data users with an easily accessible blog or logbook
(and photos) which details activities at the site (Part 1);
whenever possible (and reasonable), include redundant sensors
and/or have QA/QC checks performed by sensor intercomparisons (Part 3);
make use of meteorological data from nearby measurement sites
for quality control, gap-filling, and determination of sensor drift (Part 3).
Early US-NR1 publications e.g.,
documented the primary instruments used and provided brief descriptions of
the data collection. Subsequent US-NR1 publications often contained
additional instrumentation details e.g.,their
Appendix A; however, the focus of these papers has been on
scientific findings, not data system details. There are many excellent
references on data acquisition hardware and software, with an emphasis on
collecting high-frequency data e.g., as well as practical advice related to data
acquisition within the eddy-covariance literature
e.g., and textbook overviews of atmospheric
data-collection techniques and sensors e.g.,.
Most papers, however, provide only a short description or summary of the data
acquisition with more detailed information found in college theses,
manufacturer literature, or institutional reports. In general (and with good
reason), the flux community has placed more emphasis on publishing details of
flux calculations e.g.,, the downstream data QA/QC
e.g.,, or
software comparisons e.g.,.
Data acquisition technology changes rapidly. For example, over the past
decade, as data disks have become cheaper with increased capacity, storing
high-rate data has become easier. Recently, small single-board computers such
as the Arduino and Raspberry Pi and related open-source software have opened
up the future for new ways to think about and implement data acquisition. The
data acquisition papers listed above rarely discuss logistical details
related to long-term measurements. Though such considerations are often
fairly straightforward and logical, enactment of them early on in the
data-collection process is crucial for successful implementation of long-term
(i.e., multi-decade) scale measurements. For example, having the metadata
available to properly extract and process (or re-process) all of the
high-frequency raw data collected since day 1 is an important consideration
for any data collection and related software packages. Many modern
instruments (such as the LI-COR model LI-7200, and others) now make the
sensor metadata a part of the raw data files. While this is extremely useful,
a typical AmeriFlux site has a multitude of complex and varied instruments
that need to be kept track of, going beyond the metadata of a single sensor.
In our study we provide not only the details of data-acquisition hardware and
software; we also describe our experience and methodology for documenting and
recording site metadata and configuration changes.
The specific goals in Part 1 of our study are the following: (1) describe the
US-NR1 data acquisition system (hardware and software) and its evolution over
time, (2) document performance characteristics of the data system, and
(3) create a lasting archive (provided in the Supplement) of the
current metadata, data-acquisition software, and details of activities at the
US-NR1 site.
A chronological summary of changes to the US-NR1 data acquisition
hardware and software.
Hardware systemsa
Date
At US-NR1 tower
At C-1 trailer
Software
Timekeeping
Additional comments
1 Nov 1998
PC/486 (Linux)
Sun SPARCstation 5
ASTER/ADAM-ATIb
Network w/NTP
ADAM-ATI was a data acquisition system/board from
Rocketport serial card
(russter.colorado.edu)
Applied Technologies Inc. (http://www.apptech.com/)
(duck)
using a Rocketport multi-port serial card
2 Aug 2002
Dell Inspiron 7000,
No hardware
ASTER/ADAM-ATIb
Network w/NTP
Dell laptop, http://www.dell.com/
Edgeport/8 converter
change
Edgeport/8 USB-to-serial converter (w/8 DE-9 ports),
(quacker)
http://www.digi.com/products/models/301-1002-08
18 Jun 2004
No hardware
Dell Precision PC
ASTER/NDAQc
Network w/NTP
Dell Precision Workstation 360n Minitower,
change
(russter2.colorado.edu)
https://en.wikipedia.org/wiki/Dell_Precision
20 Oct 2014
Eurotech PC/104 Titan,
No longer
NIDASd
GPS w/NTP
Eurotech PC/104 single-board computer,
Emerald 8P Module
necessary
http://www.eurotech.com/en/products/TITAN
(isffa.colorado.edu)
Emerald-MM-8P 8-Port Serial Module,
http://www.diamondsystems.com/products/emeraldmm8p
a Parenthetical items in bold are either the local or
network name of the associated hardware that will be referred to within the
text and throughout our study. b The NCAR Atmosphere-Surface Turbulent
Exchange Research (ASTER) facility uses automatic data-acquisition modules (ADAMs)
to collect data from remote locations and send them to a base station
. Specific details about the ADAM-ATI used at
the US-NR1 tower are in Sect. in the text and within the
Supplement (USNR1_ati_duck_manual.pdf). c NDAQ stands for the NCAR
Data Acquisition system (see Sect. in text for details).
d The NCAR In-Situ Data Acquisition Software (NIDAS) is open-source
software developed by the NCAR Earth Observing Laboratory (see Sect.
in text for details). Current NIDAS information is available on github,
https://github.com/ncareol/nidas/wiki.
Data acquisition system
Prior to the establishment of the US-NR1 site in 1998, a trailer was parked
at the National Center for Atmospheric Research (NCAR) Earth Observing Lab (EOL),
and a copy of the hardware and data acquisition system being used at
the time by the Atmosphere-Surface Turbulent Exchange Research (ASTER)
facility e.g., was created. This trailer was
subsequently moved to the University of Colorado (CU) Mountain Research
Station property near the Long Term Ecological Research (LTER) Mountain
Climate Program C-1 site, located about 500 m northeast of the US-NR1 tower.
The trailer housed the tower base station computer and was connected to the
tower by a four-strand fiber optic cable. As shown in
Table , the US-NR1 hardware and software have been
periodically updated to keep up with hardware and software upgrades by the
NCAR EOL Integrated Surface Flux System (ISFS) group . A
schematic of the data flow from instruments to final data archival on the CU
campus server (urquell) as it existed between June 2004 and October 2014 is
shown in Fig. , and the data flow after October 2014 is in
Fig. . Each night, the raw data files were copied
from a computer at the site to urquell with rsync. Throughout our
discussion, standard unix commands will be shown in the typewriter font and
we will refer to the computers within the data system by the network names
which are listed in bold in Table and shown in
Figs. and . The EOL
data-acquisition software described below was written in C/C++, and we have
included examples of different versions of the software within the
Supplement of this paper.
Schematic flow chart of data collection with the ASTER/NDAQ data
acquisition software that was used between June 2004 and October 2014 at the
Niwot Ridge US-NR1 AmeriFlux site. The data flow is from the instruments (at
the top of the chart), to the CR23X data loggers, to a laptop (quacker) at
the tower for time-tagging, to a desktop computer (russter2) in the trailer
at LTER C-1 for archiving, followed by nightly copying of the raw data files
to the server on CU campus (urquell). The horizontal dashed lines represent
spatial separation of hardware locations; distances are noted in the
schematic (the upper portion of the schematic is at the US-NR1 tower, the
middle portion at LTER C-1, and the lower portion on the CU campus). The red
boxes indicate high-rate data system components that are discussed within the
text (Sect. ).
As in Fig. , except showing the data flow with the
NIDAS data acquisition system, which was used starting on 20 October 2014.
With the NIDAS system, the computer in the trailer at LTER C-1 (russter2) is
replaced with a network switch/hub. The red boxes indicate high-rate data
system components that are discussed within the text (Sect. ).
Campbell Scientific data loggers
The backbone of the data acquisition system at the US-NR1 site is a set of
Campbell Scientific CR23X data loggers . Prior to 2002,
the older CR21X data loggers were also used (i.e.,
Table ), but we base our discussion on the CR23X. The CR23X
has 12 analog differential input channels (using a 15 bit analog-to-digital
converter), ingests serial data from multiple instruments (typically using
the Campbell Scientific Synchronous Device for Measurements (SDM) protocol),
and provides control ports for sending simple commands that can be used for
tasks such as opening/closing solenoid valves. The CR23Xs act as the primary
interface between the instruments and the tower data system
(Figs. and ). After sampling data
from multiple instruments, each CR23X streams serial data to a computer at
the tower (duck, quacker, or isffa), whose purpose is to time-tag the
individual serial data samples as they are ingested into the high-rate data
acquisition system (Sect. ). For the data system to
successfully sample data at a rate of 10 Hz, it was necessary to output
binary data from the CR23X CS I/O DE-9 port using a pair of short-haul modems
(for example, Black Box Inc., model ME800A) for RS-422 serial data streaming
from the CR23X to the tower computer. For 1 Hz data sampling and streaming,
the short-haul modems were unnecessary and the CR23X data output could be in
ASCII using the CR23X optically isolated RS-232 DE-9 port and a standard
serial cable. For all CR23Xs, communication between the CR23X and data system
occurred at a baud rate of 9600 bps.
For some instruments, such as the Applied Technologies Inc. (ATI) sonic
anemometers, serial data were streamed directly from the instrument into the
data system, without using a CR23X. The data system could also directly
collect serial data output by the Campbell Scientific model CSAT3 sonic
anemometers; however, for our purposes, the CSAT3 data were typically
collected using a CR23X and the SDM protocol. This allowed the CSAT3 wind
data to be synced with any measured scalar, and also conserved usage of the
data system DE-9 input serial channels (which were often a limited resource).
Campbell Scientific data loggers used at the US-NR1 AmeriFlux site.
The loggers are listed by the approximate date they were installed on the
tower. At the start of the project (1 November 1998), three data loggers were
used (FAST CR23X, PROF CR23X, and CNR/LIGHT CR21X). Early in the project,
CR21X data loggers were sometimes used in place of the CR23Xs (where
appropriate, this is listed in the notes below). By the end of 2001, the
CR21Xs were replaced with CR23Xs. The serial numbers and logger locations
refer to the data loggers currently in use at the site. The logger programs
are the latest version of the code (for example, fast_24.csi means there are
24 versions of the FAST logger program since this naming scheme was
initiated). The SOIL, TC, and MRS loggers were not connected to the high-rate
data system.
Output data details
Current
Logger
logger
Ingested by
Data rate
Logger name
model
location
program
data system
(Hz)
Data period
Notes
FAST
CR23X
Tower, 17 m
fast_24.csi
Y
10
1 Nov 1998–present
A
sn 1036
PROF
CR23X
Tower, 13 m
prf_02.csi
Y
1
1 Nov 1998–present
B
sn 1037
CNR
CR21X/CR23X
Tower, 26 m
rad_03.csi
Y
1
1 Nov 1999–present
C
sn 2089
SOIL
CR21X/CR23X
North Canopy
soil_03.csi
N
5 min avg
30 Jun 1999–present
D
sn 2932
Tower, ground
MET
CR21X/CR23X
Tower, 11 m
met_10.csi
Y
1
21 Sep 1999–present
E
sn 2931
UC
CR21X/CR23X
Mini-tower,
uc_06.csi
Y
10
Sep 2000–present
F
sn 2091
ground/pallet
TC
CR21X/CR23X
North Canopy
tc_13.csi
N
5 min avg
Sep 2001–present
G
sn 2090
Tower, 2 m
MRS
CR10
North Canopy
mrs_03.csi
N
5 min avg
Nov 2001–present
H
sn 18657
Tower, 4 m
NCTC
CR23X
Tower, 11 m
nctc_05.csi
Y
1
Sep 2002–present
I
sn 2403
(platform)
UCB
CR23X
Mini-tower,
ucb_17.csi
Y
1
Sep 2005–present
J
sn 6425
ground/pallet
MARK
CR23X
Tower, 11 m,
mark_11.csi
Y
10, 20
Nov 2014–present
K
sn 2768
(platform)
A: primary role: eddy-covariance flux data from a sonic anemometer
(Campbell Scientific, model CSAT3), a closed-path infra-red gas analyzer IRGA
(LI-COR, model LI-6262), an open-path IRGA (LI-COR, model LI-7500), a krypton
hygrometer (Campbell Scientific, model KH2O), thermocouple (type-E), LI-7200
analog CO2, and EC155 analog CO2. B: primary role: vertical CO2 profile data from a closed-path IRGA (LI-COR,
model LI-6251); valve control and valve-status variable for the LI-6251,
precipitation, and air temperature. C: a CR21X (LIGHT logger, program LIGHT.CSI) was used from 1 November 1999
until 7 July 1999. Primary role: radiation data. Sometimes called the RAD logger. D: a CR21X (program SOIL_TDP.CSI) was used between 30 June 1999 and April 2000.
Primary role: soil temperature and soil moisture data. E a CR21X was used between 21 September 1999 and 21 June 2000. Primary role:
relative humidity, prop-vane winds, barometric pressure, valve control, and
valve-status variable for the LI-6262; prior to 26 May 2010, the MET data logger
had a loose wire/connection in the SC932 9 pin to RS232-DCE interface converter
that was between the CR23X and short-haul modem and caused intermittent periods
of 1 Hz data loss. F: a CR21X was used initially. Primary role: undercanopy eddy-covariance data
(two CSAT3s and one or two LI-7500(s)). G: a CR21X was used initially. Primary role: tree bole temperatures. H: primary role: vertical snow temperature profile. I: primary role: vertical thermocouple air temperature profile. Sometimes called the NCARTC logger. J: primary role: soil temperature and moisture and undercanopy radiation. K: primary role: tree accelerometer data; thermocouples at 10 and 20 Hz.
In addition to streaming high-rate data, the CR23X data loggers were
programmed to store 5 min (or 30 min prior to May 2003) averages of the
measurements on the CR23X 4 Mb internal flash storage. These data were
manually downloaded during site visits. Even though the CR23X internal clock
can drift with time (discussed more in Sect. ), saving
the mean values locally was an important feature of the data system because
it allowed for the collection of key meteorological variables (such as
radiation, temperature, and wind speed) during periods when the data system
was not working. These mean meteorological variables could subsequently be
used for gap-filling the turbulent flux measurements
e.g.,. A list of the data loggers used at US-NR1 is in
Table , and an archive of all versions of the logger programs
is included as a zip archive in the Supplement
(USNR1_logger_code.zip). As noted in Table , three of the
data loggers (SOIL, TC, and MRS) were not connected to the high-rate data
system. The SOIL and TC data loggers were mostly used to measure biomass
temperature and soil properties that typically do not require high-rate or
fast-response measurements. These temperatures were measured using a
multiplexer specifically designed to measure thermocouple temperatures
(Campbell Scientific, model AM25T), and the measurement capacity of the data
loggers was also expanded using another Campbell Scientific multiplexer
(model AM416). The MRS CR10 logger was used to measure vertical snow
temperature profiles e.g.,.
High-rate data collection
ASTER/ADAM-ATI configuration (1998–2004)
The original concept of the NCAR ASTER facility was to use multiple automatic
data-acquisition modules (ADAMs) to collect data from remote locations and
send it back to a base station that runs the ASTER software
. For the initial deployment at the US-NR1 site, a
data acquisition board from ATI with 16 serial input channels that was
connected to a 486 PC running Linux (dubbed duck) was used. The typical NCAR
ADAM used Motorola 68000 VME hardware (running VxWorks), so the ASTER/ADAM
software was modified to be compatible with the ATI data-acquisition board
and thus called the ADAM-ATI software (Table ). A copy of
the manual for the ADAM-ATI duck is included in the Supplement
(USNR1_ati_duck_manual.pdf). The base station running the ASTER software
was a Sun Sparc5 workstation (russter) in the trailer at C-1.
At the end of July 2002, a Dell laptop (dubbed quacker) running Red Hat
Linux (2.4.18-5) replaced the duck, and the ADAM-ATI software was adapted and
installed on the quacker. For this upgrade, the Sparc5 (russter) in the
trailer at C-1 was unchanged. In order to acquire the serial data from the
CR23Xs, the quacker typically had nine DE-9 input channels (one on the back of
the laptop and eight from an Edgeport/8 USB-to-serial converter). For periods
when more than nine DE-9 input channels were needed, a USB hub was used to
connect two Edgeport/8 converters simultaneously; however this setup was
subject to system lockups and less robust than using a single Edgeport/8
converter. The main task of the quacker was to time-tag the incoming serial
data samples from the CR23Xs and stream these data directly to russter where
the raw data files were created and archived. Additional software on the
quacker, which was integrated into the ASTER system, was used to control a
microprocessor (16-channel B1 (digital) Optomux Protocol Brain Board, Opto 22,
Inc.) that was part of a multi-inlet CO2-measurement system
used in multiple experiments at the site
e.g.,. This software
is included within the Supplement (USNR1_opto22.zip).
ASTER/NDAQ configuration (2004–2014)
In spring 2004, the Sparc5 workstation in the trailer at C-1 (russter) was
starting to show signs of failure. In June 2004 russter was replaced with
a Linux-based Dell PC (russter2), and the ASTER base station software was
installed on it (Table , Fig. ). At this
time, the ADAM software had been recoded to run on Linux-based systems and
was called the NCAR Data Acquisition system (NDAQ) software. Therefore, when
russter2 became the base station, the quacker software was upgraded from
ADAM-ATI to NDAQ. Even though NDAQ was considered “transitional” software
by NCAR (eventually replaced by NIDAS, as described in the next section), it
was used at the US-NR1 site for over 10 years.
Two network cards were installed on russter2. One network card was for the
local 10.0.0.X subnet, which used a pair of fiber optic cables between C-1 and
the quacker at the tower. The other network card used a long network cable
running under the road at C-1 to a fiber optic converter switch that was part
of the MRS network (maintained by the CU campus network services), and
connected russter2 to the CU campus and the outside world.
As instruments were added or removed from the tower, all data-system
configuration changes were saved within the ASTER software on the base
station russter2 in different OPS directories (described in
Sect. ). In contrast, the NDAQ software and system
configuration on the quacker was relatively static. Examples of the ASTER
software on russter2 and NDAQ software on the quacker are included in the Supplement.
NIDAS configuration (2014–present)
In summer 2012, russter2 experienced a hard drive failure and was starting
to show signs of other problems. After discussion with EOL, it was decided to
upgrade to the current EOL hardware and software, which was a single-board
Eurotech PC/104 Titan computer (http://www.eurotech.com/en/products/TITAN)
running the NCAR In-Situ Data Acquisition Software (NIDAS)
. After a period of testing in the lab and at the site, on
20 October 2014 a Titan PC/104 stack (isffa) running Arcom Embedded Linux
(AEL v4i5) was deployed at the tower. The Titan replaced both the quacker and
many of the russter2 functions, taking over the tasks of data sample
time-tagging, raw data archiving, and daily copying of the raw data files to
campus (Fig. ). However, some russter2 functions,
such as cockpit (Sect. ), were now run on urquell (on the
CU campus). The Titan was also directly connected to a GPS receiver to
provide timekeeping (and time server) capability. By having the Titan
perform all of these tasks, the complexity of the system (and possibility for
hardware failures) was greatly reduced.
NIDAS was designed to be used on a wide variety of platforms (such as the
NCAR aircraft) and is scalable for sampling small to large numbers of
instruments. When a Titan PC/104 computer is combined with NIDAS, some of the
key features are its small size (the Titan footprint is 90 × 96 mm),
low power consumption (maximum power usage of 1.5 Watts), its adaptability to
diverse network configurations and data bandwidths, its capability of high-bandwidth
sampling with high accuracy time tags, support for multiple I/O buses and
data acquisition expansion cards, embedded processors, and its adaptability to
distributed displays and processing. NIDAS has also been compiled on
inexpensive, single-board Linux-based computers, such as the Raspberry Pi
(https://www.raspberrypi.org/). The most recent version of the NIDAS software
is maintained on github (https://github.com/ncareol/nidas/wiki).
The Titan comes with 4 RS-232 and 1 RS-422 DE-9 serial ports. We combined
this with an Emerald 8P Module that provided an additional 8 DE-9 serial
input channels. In total, 13 DE-9 serial ports were available for inputs from
the CR23Xs and other instruments (replacing the Edgeport/8 converter). Having
these extra DE-9 ports allowed us to add a new CR23X data logger (the MARK CR23X,
see Table ) to the data system in November 2014.
From a user's perspective, NIDAS differed from ASTER/NDAQ in several important
ways. First, any data system configuration (OPS) changes in NIDAS are
recorded in a single Extensible Markup Language (XML) file, rather than in
the ASTER “config” files (specific details about the OPS files are in
Sect. ). Second, in addition to the high-rate data being saved
locally on a USB solid state thumb drive connected to isffa (considered the
primary raw data files), they are also saved in real time on urquell as long
as the network connection is working (these are considered the secondary raw
data files). This redundancy allows for high-rate data to continue to be
collected even if the hard drive on isffa fails or the local data archiving
stops for some other reason. Similar to ASTER, it is also possible to have
multiple Titans (or other computers running NIDAS) simultaneously stream data
into urquell, creating a single raw data file with data from multiple remote systems.
Raw data format
The NIDAS raw data files are about 50 % larger than those from ASTER/NDAQ
(with ASTER high-frequency raw data collection typically on the order of
100 Mb day-1 compared to nearly 150 Mb day-1 with NIDAS). The
larger NIDAS file size is due to several upgrades to the binary data format,
such as an absolute time tag, support for longer samples, and minimal
alteration of the data as-read from the sensor or CR23X data logger (whereas
the ASTER software converts sensor data to a binary format). For time
information, the ASTER binary data used a 4 byte integer that is the number
of milliseconds since 00:00 UTC of the given day. In contrast, NIDAS uses an
8 byte integer that represents the number of microseconds since 1 January 1970,
00:00 UTC. The total amount of raw data collected each year is listed
in Table . Backups of the raw data files are done using
multiple methods. In addition to keeping the raw data on the urquell RAID
hard drive, copies are put on DVDs and USB external hard drives, and are finally
archived by the AmeriFlux project on Lawrence Berkeley National Laboratory computers.
Timekeeping
In order to collect high-frequency data, timekeeping is an important
consideration. If left alone, the clock in an individual CR23X and computer
will drift with time. The CR23X factory specifications for clock drift are
±1 min month-1 for -25 to 50 ∘C, which degrades to
±2 min month-1 for temperatures between -40 and -25 ∘C.
Because the serial data samples were all time-tagged by the data system
computer (duck, quacker, or isffa), the internal CR23X clock was of minor
importance. To synchronize the data system computer clocks and ensure
accurate time tags, network time protocol (NTP, http://www.ntp.org/) was
used. NTP has the advantage of choosing a time source from either a
network-based or local time server, such as the GPS pulse-per-second (PPS)
output/clock e.g.,. In the NDAQ
configuration, russter2 used a time server on the CU campus to maintain an
accurate clock, and it was also configured as an NTP time server to keep the
quacker clock from drifting. For the NIDAS configuration, the Titan was
directly connected to a GPS receiver (Campbell Scientific, model GPS16X-HVS)
to maintain clock accuracy e.g., and act as the
local NTP time server. Both russter2 and the Titan/isffa were configured as
precision time protocol (PTP, i.e., IEEE 1588TM-2002) servers to be available
for any instruments that require PTP, such as the LI-COR model
LI-7200/LI-7550 infra-red gas analyzer (IRGA). It would also be possible to
have isffa act as a PTP, version 2 (i.e., IEEE 1588TM-2008) server depending on
the needs at the site.
Between September 2013 and July 2015 a Campbell Scientific CPEC200 system
with an EC155 IRGA and CR3000 data logger were installed on
the US-NR1 tower as part of an IRGA comparison experiment
e.g.,. The CR3000 data logger was connected to a
second 16X-HVS GPS for precise timekeeping and scan interval regulation. The
EC155 10 Hz raw data were stored locally on the CR3000 and an analog CO2
voltage from the CPEC200 was also ingested by the FAST CR23X into the tower
data system. For the purposes of the current study, a comparison between the
10 Hz data archived on the CR3000 and the analog CO2 voltage provides an
opportunity to examine time-stamp differences between these two (independent)
systems and a way to check the data-system timekeeping accuracy.
Variable names
Because the data system at US-NR1 is based on NCAR ISFS software, we have
adopted the ISFS variable-naming nomenclature. Here, we provide a short
description of the naming scheme with more details at
https://www.eol.ucar.edu/content/isfs-variable-names. Briefly, slow-response
sensors that are sampled at a rate of 1 Hz (or less frequently) use
upper-case variable names (e.g., P, T, for slow-response barometric
pressure and air temperature), while the high-frequency, turbulence
measurements used for eddy-covariance are named with lower-case letters
(e.g., u, v, w, and tc for three wind components and temperature from
a sonic anemometer). Calculated 5 min statistics are saved in a daily netCDF
file (discussed in Sect. ), which have variable names such
as u_u, u_v, w_w, and w_tc for the variance and covariance
between the variables (higher order statistics are also calculated). Variable
names can also be further qualified by attaching a suffix to indicate the
measurement location or height, where either an underscore or a dot can be
used, e.g., w_tc_10m or w.tc.10m.
Real-time data monitoring
The first step in data quality control is recognition of a problem or issue
with the data from a particular instrument. The ASTER and NIDAS software
facilitated this important task in two ways. First, it includes real-time
monitoring of all variables measured by the data system in a simple display
called “cockpit” (Fig. ). This display is possible as long
as network access to the data system is available. The ability to quickly
scan and observe all variables at once is a key feature. As seen in the
screenshot of Fig. , each box in the cockpit window
corresponds to a different measured variable. Another helpful feature is to
leave a trace of the older data (shown in light gray) so problems are easily
observed. The cockpit display evolved from a similar display documented by .
The second feature is that the software produces near-real-time statistics
(means, variances, co-variances, third moments, etc.) of the variables.
Typically, a 5 min period is used for the statistics, and they can also be
recalculated as part of the post-processing. These statistics are saved in
daily netCDF files that are considered part of the
final data product. These 5 min statistics can be used to generate plots for
examining daily trends or look for problems. For an example of daily plots
generated by NIDAS for QA/QC, see http://www.eol.ucar.edu/isf/projects/CHATS/isff/qcdata/. For the ASTER
software, the 5 min “covar” netCDF files include a record of what was being
sampled by the data system at that time. For example, by doing ncdump-h nwt.001007.nc,
the following type of information is found in the global attributes section:
From this record, we can determine when instruments were removed and/or added
to the tower data system.
Screenshot of data monitoring software (cockpit) from 7 February 2014.
Each box shows data from an individual sensor where the blue line is
the current, real-time data being collected and the gray background is the
trace of data collected since the cockpit session was initiated. The upper
set of inset panels offers an enlarged view of the eight panels outlined in red in
the upper left-hand corner of the cockpit window; here, the wind components
and temperature measured by two CSAT3 sonic anemometers with base variable
names u, v, w, and tc are shown.
Tracking configuration changes
Any long-term measurement (that is subject to setup changes over time) needs
a simple, robust method for recording the metadata and software that keeps
track of these changes. This is needed, for example, as new instruments are
added or old instruments are removed. The ASTER and NIDAS software are
designed to keep track of configuration changes using what are called the
“OPS” files. This consists of a simple text file with dates and times where
configuration files for each particular setup are saved in a subdirectory
based on the OPS file configuration number. For the data system at US-NR1, we
are currently operating on OPS 86, which suggests that there have been
86 changes to the system configuration. There have, however, actually been more
changes than 86 because when data were first collected, configuration changes
were not accurately recorded. This has led to some uncertainty and guesswork
in re-extracting data from the early period of US-NR1 operation (e.g.,
1998–2000). However, as mentioned in the previous section, the 5 min netCDF
data files provide guidance in determining the OPS configuration during these years.
For the ASTER software, the important files that needed to be updated for OPS
configuration changes were the “config” files: archive_config,
channel_config, ingest.conf, prep.config, and covar.config. These were
simple ASCII files that contained all the information about which serial
channels were collecting which CR23X data, the format of the incoming serial
data, variable names, and which variables to calculate 5 min statistics. The
OPS/config files were mirrored on urquell so that the variables could be
extracted from the raw, binary data files (using the ASTER prep
command) for subsequent data processing. A file called “ops.config”
contained the information about which dates/times corresponded to which OPS configuration.
A screenshot example of the US-NR1 web calendar from October 2015.
The web calendar includes a color-coded short summary of activities done at the
site as well as links to photos and a more detailed logbook entry of the
visit. The web calendar is accessible online at http://urquell.colorado.edu/calendar/.
For the NIDAS software, the config files were replaced with a single XML file
(niwot.xml). The OPS dates and time information are in a file called
“configs.xml”. On the Titan, only the portion of the niwot.xml file related
to the data acquisition is required. This data acquisition information is
mirrored in the niwot.xml file on urquell, along with some additional
information related to the 5 min statistics and cockpit display (which are
both done on urquell, not the Titan). Similar to the ASTER software,
prep is used to extract data from the raw, binary data files.
The Supplement includes the full archive of OPS files for the
ASTER (USNR1_OPS_aster.zip) and NIDAS (USNR1_OPS_nidas.zip) software as
well as more details and examples using prep and examples of how to
load these data into MATLAB (USNR1_prep.zip).
Record-keeping
Complementary methods (described below) were used for archiving metadata and
keeping records of activities at the site.
Web calendar
A simple web-based calendar is used to summarize dates when the site is
visited, include a link to photos taken, and provide any additional
information. The calendar website is maintained as
http://urquell.colorado.edu/calendar/ and a screenshot of the web calendar
from a recent month is shown in Fig. . Here, one can see
that different colors indicate different types of activities; short
descriptions of the weather and weblinks to details and photos are
included for each date the site is visited. There are currently over
14 000 individual photos taken during visits to the site, which are all linked
to the web calendar. The usefulness of this
calendar is especially apparent when the data are being analyzed and
something strange or odd is observed on a certain date. This calendar allows
any interested person with web access to quickly find and examine what
activities (if any) were occurring on a particular day. The full set of HTML
calendar web pages is included in the Supplement (USNR1_webcalendar.zip).
A screenshot example of the US-NR1 logbook entry from 2 November 2013.
The logbook is accessible online at http://urquell.colorado.edu/logbook/.
Example photos from different webcams installed on the US-NR1 tower.
The camera name, camera type, raw image size, and dates of operation are
provided above each photo. Cameras niwot, niwot2, niwot3, and tree1cam are
all pointed north; niwot4, niwot5, and FLIR are looking east/northeast; and
the cloudcam is looking west. The cameras niwot2 and niwot4 are the same
physical camera. Images from niwot, niwot2, niwot3, niwot4, and niwot5 are
all available from the University of New Hampshire PhenoCam project website
(http://phenocam.sr.unh.edu/). The emissivity-corrected FLIR image was
captured on the morning of 2 October 2015 as the upper canopy was warming up.
The cloudcam and tree1cam cameras were not capturing images for the entire
period shown.
Field logbook
The link to details in the web calendar leads to the online electronic
site logbook, http://urquell.colorado.edu/logbook/. Our logbook is created
using the unix-based Tool Command Language (Tcl/Tk) coupled with the Linux
simple windowing shell (wish) program. A screenshot of a typical
logbook entry is shown in Fig. . The key information provided
is who was at the site, why the visit occurred, the weather, any
miscellaneous notes, and then a detailed summary of what was done. The amount
of detail provided is at the discretion of the person writing the entry. The
software allows for any individuals with accounts to add information to the
logbook and generate HTML output for posting on a website. Any blogging-type
of software could be used for an equivalent electronic logbook. The full logbook and
logbook web pages are included in the Supplement
(USNR1_logbook.zip). Information prior to the existence of the electronic
logbook in 2003 is included in the Supplement as PDF scans from
handwritten logbook notes (USNR1_turnipseed_logbook.zip).
Digital cameras
Another useful resource that has been on the US-NR1 tower since July 2007 is automated cameras or webcams (Fig. ). In general, these
cameras have been part of the University of New Hampshire PhenoCam project
(http://phenocam.sr.unh.edu/) and can be used to track changes in the
forest phenology e.g.,. The cameras that are
part of the PhenoCam network all use NTP for an accurate time/date stamp on
each photo. The photos also serve as an image-based way to document
conditions at the site; for example, they could be used to evaluate the
presence of snow on the canopy. If pointed toward the sky, these cameras can
be used to help document clouds and cloud motions
e.g.,. In August 2015, a
thermal infrared camera (FLIR Systems, Inc. model A655sc) was added to the
US-NR1 tower for spatial monitoring of the canopy temperature
Fig. f;.
In mid-2014 we explored the use of inexpensive (≈ USD 100) stand-alone
cameras (Wingscapes, http://www.wingscapes.com/) to take photos of the clouds
(Fig. g), track snowmelt in spring (Fig. h),
observe liquid water evaporation/infiltration in the summer, and monitor the
comings and goings of human activity at the site. For the Wingscapes cameras,
the date/time is reset when the photos are downloaded. We had mixed success
using the Wingscapes cameras, with several of them failing.
Time series of the estimated time offset between the CR23X MET data
logger clock and the data system clock in 2009 (a negative offset indicates
that the MET logger time lagged behind the data system time). The offset is
calculated based on the time of the LI-6262 calibration, which is controlled
by the MET data logger and programmed to occur every 4 h, starting at
midnight. On average, the drift in the CR23X clock was approximately
-0.5 s day-1. The blue line indicates the CR23X worst-case clock
drift specification of -4 s day-1 (i.e., -2 min month-1 for
temperatures between -40 and -25 ∘C), while the red line
corresponds to a clock drift of -0.5 s day-1. The sharp jumps back
toward zero occurred when the CR23X clock was manually reset during site visits.
Results and discussion
CR23X clock drift
Every 4 h, the CR23X MET data logger opened and closed solenoid valves
that allowed the primary closed-path IRGA on the tower (LI-COR, model LI-6262)
to sample a span gas and nitrogen . The MET
data logger also created a 1 Hz variable that recorded the status of the
LI-6262 valves. Since the MET data logger CR23X clock would drift, the exact
time the valves were opened and closed was always approximate, but known
precisely from the valve-status variable. Prior to 26 May 2010, the MET CR23X
(Table ) had a loose wire in the Campbell Scientific (model SC932)
9 pin to RS232-DCE interface converter, which was between the CR23X and
short-haul modem. This intermittent problem resulted in missing 1 Hz data,
which necessitated recreating the valve-status variable based on when
the LI-6262 IRGA sampled the nitrogen. This event was clearly defined because the
LI-6262 CO2 and H2O drop sharply to zero as the nitrogen was sampled.
By tracking the time of the calibration events we are essentially tracking
the CR23X clock-drift, and we found that the MET logger clock typically drifted
on the order of -0.5 s day-1 (Fig. ). This clock
drift rate was an order of magnitude better then the worst-case CR23X
manufacturer-specified clock drift of ±4 s day-1. Since we
manually reset the data logger clocks on site visits (as described in
Sect. and shown by the step changes back to near-zero offset
in Fig. ), we found that the CR23X clocks always tended to
lag behind the actual time, and none of the CR23Xs at our site experienced a
positive clock drift.
A time series of the difference between the 10 Hz analog EC155
CO2 measured by the US-NR1 data system and the 10 Hz digital EC155
CO2 data saved on the CR3000 for (a) 14 November 2013 and
(b) 12 November 2014. The differences are shown where the analog
samples have been shifted by one sample forward and backward in time as
described by the text above the time series.
A 30 min time series of the time lag estimated from the phase spectrum between the analog and digital
signal of the CO2 dry mole fraction from the EC155 IRGA for (a) 2013
and (b) 2014. In (c), the 21.5 m air temperature from
both years is shown (see legend). The analog voltage is ingested into the
data system by the FAST CR23X data logger, while the digital signal is
archived on a CR3000 connected to the EC155. A negative sign indicates that
the analog signal lags behind the digital signal.
Time stamp quality
As an independent check of the data-system clock, we used a CPEC200 and
associated EC155 IRGA that were connected to a CR3000 data logger (with its
own GPS) that were added to the tower in September of 2013
. The CR3000 locally stored digital CO2 from the
EC155 that also output an analog CO2 voltage into the FAST CR23X data
logger (Table ). When the differences between the 10 Hz analog
CO2 voltage and digital CO2 are compared
(Fig. ), small pulse-like changes in the amplitude
of the difference that have a period of anywhere from 2 to 6 h can be
observed. The CO2 mole fraction has a typical mean value of around
400 µmol mol-1, and the differences shown in
Fig. are all smaller than
±1 µmol mol-1, suggesting that the CR23X analog sampling has an
accuracy much better than ±0.25 %. Furthermore, if the analog data are
shifted forward and backward by one sample, the pulsed differences only occur
when the analog data are shifted backward in time by one sample (red line in
Fig. ). Closer examination reveals that when the
non-shifted data difference is at a minimum, the shifted data difference is
at a maximum, and vice versa. These characteristics suggest that the digital
and analog CO2 data have a slight time or phase shift relative to each other.
To look further into this, the lag between the analog and digital EC155
CO2 time series was calculated for each 30 min period from the cross-spectral phase
angle (i.e., ratio of the quadrature spectrum to the cospectrum,
). The lag was estimated from the median of the
cross-spectral phase within a frequency band of 0.05 to 3.3 Hz. The resulting estimated lag
is shown for 2013 and 2014 over a 5-day period in November when the
ASTER/NDAQ software (Fig. a) and NIDAS software
(Fig. b) were each being used. Here, we can observe
more clearly that the lag between the EC155 analog CO2 voltage and
digital CO2 was bounded by zero and -0.1 s, which corresponds
to the sampling interval of the FAST CR23X. Though the clock drift in the
CR23X does not affect the time-stamping of the individual data samples, it
does affect the CR23X 10 Hz output into the data system, and reveals itself
as a gradual change in the lag between zero and -0.1 s
(Fig. ). By counting the number of cycles on a given
day, we can estimate the daily clock drift rate for the FAST CR23X data
logger. For 2013, the drift rate was on the order of -0.25 s day-1.
In 2014, the nominal drift rate was around -0.4 s day-1; however,
during an extremely cold period (around day 316) the air temperature dropped
below -25 ∘C (Fig. c), and the clock drift
rate increased to around -0.7 s day-1. This is consistent with the
CR23X specifications that the clock drift rate is larger in cold conditions
(described in Sect. ). Though we cannot fully explain
why the lag time differed in 2013 and 2014, the important result is that when
either the ASTER/NDAQ or NIDAS configurations were being used, the CR23X
logger samples were being properly time-tagged and the CR23X FAST logger lag
was bounded by the sampling interval. Furthermore, though the phase
difference would be important when making any calculations with a sensor
independent from the FAST CR23X data logger, the lag should not have any
effect on calculations using data that are strictly from the FAST data
logger (i.e., for the eddy-covariance flux calculations).
Another useful test was to examine the time-stamp differences between
individual high-rate samples (Fig. ). The frequency
distributions are included to emphasize that most (around 85–95 %) of the
data collected are within ±0.001 s of the desired time difference
(i.e., the time series plots can be a bit misleading to the eye). Here, we
have included serial CSAT3 sonic anemometer data that were collected at
sample rates of 20 and 30 Hz using a Eurotech Viper PC/104 running NIDAS
(the Viper is very similar to the Titan PC/104 computer).
The 20 Hz data had a well-defined peak at 0.05 s
(Fig. c), whereas the 30 Hz serial CSAT3 output
showed two peaks, one at 0.03 s and one near 0.04 s
(Fig. d).
We also examined time-difference variations for output from a CR3000 that was
directly connected to the Titan prior to the Titan being deployed on the
tower; there was similar jitter around the 0.1 s time difference
(Fig. b). Because relatively few data samples were
missing, we suspect the data loggers (and CSAT3s) were outputting the samples
at the required sample rate, and the variations in time-stamp differences
were most likely due to the buffers and interrupts within the serial chip of
the computers used for the data system. These system processes cause the data
system to constantly be needing to catch up with the incoming serial data
stream. An example of this can be observed by noting that the 20 and 30 Hz
CSAT3 data were transferred to campus each day (via rsync) at 17:00 MST, which
is exactly when some level of disruption in the time-stamp differences occurred.
The variations in time-stamping occurred for different sample rates as well
as different combinations of software and hardware (e.g., the quacker with
the ASTER/NDAQ configuration (Fig. a), and the Titan and
Viper PC/104 computers running NIDAS). Additional examples of the time
differences for other data loggers on the US-NR1 tower were presented in the
discussion portion of the review process . EOL
software engineers are currently trying to better understand the reason for
these larger-than-expected variations in the time-stamp differences. As long
as the number of samples is correct, it can be assumed that the order of the
incoming serial data is correct and the samples can be “regularized” to
evenly spaced time intervals . In NIDAS and ASTER, the
prep command does this regularization with the “-r” switch,
which adjusts the data time stamp to the nearest evenly spaced time interval
(for an example, see Supplement, USNR1_prep.zip).
Time series of the time difference between high-rate data samples
collected for different data systems at the US-NR1 site for (a) 10 Hz
data from the FAST CR23X logger using the ASTER/NDAQ configuration,
(b) 10 Hz data from a CR3000 connected to the Titan PC/104 running
NIDAS in the trailer (prior to deployment at the tower), (c) 20 Hz
data from a CSAT3 collected by a Viper PC/104 computer running NIDAS, and
(d) 30 Hz CSAT3 data collected with the same Viper. Details are also
listed immediately above each panel. The Viper PC/104 data system was added
to the US-NR1 tower in September 2014 to collect data from seven CSAT3 sonic
anemometers for a full year. To the right of the time series is a frequency
distribution showing the number of samples within each time-difference bin.
The dashed lines show the time-difference range used for the frequency
distribution plot. The text in the right corner of each frequency
distribution panel is the bin size used and the fraction of samples that the
middle three values (highlighted by the open circle) make up of the total.
The fraction of missing high-rate (10 Hz) data from the FAST CR23X data
logger shown by month and year. Months with greater than 20 % of high-rate
data missing are highlighted in bold. In the two right-hand columns, the
total size (in gigabytes) of the raw, high-rate binary data collected for
each year and the approximate number of site visits per year are provided.
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Annual
Total
No. site
Year
1
2
3
4
5
6
7
8
9
10
11
12
averages
size (Gb)
visitsa
1998
0.33
0
0.165
2.04
1999
0.23
0
0
0.02
0.12
0
0.27
0.17
0.11
0.05
0.03
0.04
0.089
18.41
2000
0.06
0
0.01
0
0
0.02
0.06
0.01
0.04
0
0
0
0.019
27.02
2001
0
0.01
0.07
0.03
0
0
0.02
0
0
0
0
0.09
0.023
27.78
1
2002
0
0
0.11
0.04
0.12
0.16
0.23
0.06
0.08
0.24
0.05
0.10
0.100
28.35
6
2003b
0.01
0.05
0.23
0.14
0.08
0.08
0
0.03
0.20
0.04
0.21
0
0.090
33.38
79
2004
0
0.02
0.02
0
0.03
0.02
0.02
0.15
0
0.02
0.04
0.04
0.031
35.32
93
2005
0.06
0.05
0
0
0.03
0.03
0.05
0
0
0
0.01
0.05
0.026
34.96
68
2006c
0
0
0
0.11
0.24
0
0.11
0.01
0.03
0.05
0.03
0
0.052
34.78
68
2007d
0.05
0
0.02
0
0.07
0.07
0.01
0.03
0
0
0
0.32
0.050
34.76
53
2008
0.08
0
0
0
0.02
0
0
0
0
0
0
0.01
0.015
36.21
41
2009
0
0
0.03
0.10
0.04
0.07
0.03
0.10
0.09
0.03
0
0
0.043
39.08
51
2010
0
0
0
0.02
0.04
0
0
0
0.01
0
0
0
0.009
40.11
40
2011
0
0.11
0
0
0
0
0.01
0
0
0.06
0.09
0
0.022
39.21
33
2012e
0
0
0
0
0
0
0.03
0.04
0
0
0
0
0.007
39.15
26
2013f
0
0
0
0
0
0
0
0
0.20
0
0
0
0.016
35.58
28
2014
0.03
0
0
0
0
0
0
0
0
0.02
0
0
0.005
44.80
38
2015
0
0
0
0
0.02
0
0
0
0
0
0
0
0.003
72.68
29
0.033
0.017
0.031
0.028
0.048
0.029
0.051
0.037
0.045
0.033
0.046
0.038
0.036
623.62
654
Monthly averages
Cumulative values
a These are the number of site visits per year by the lead
author (S. P. Burns) who starting working at US-NR1 in January 2003. b From
18 to 20 March 2003, a major snowstorm knocked out the power at the US-NR1
site.
c From 28 April to 8 May 2006, the power line to the US-NR1 site was
compromised. d From 20 to 29 December 2007, russter2 had a hardware
failure. e On 12 August 2012, russter2 had a hard drive failure.
f From 10 to 12 September 2013, the county of Boulder experienced significant
rainfall e.g.,, shutting down power to the site and
making access to the site difficult.
Data system robustness
Because the goal of US-NR1 data collection was to have a continuous
year-round time series of measured fluxes, one of the important data-system
metrics is how much downtime or lost data occurred in the high-rate (10 Hz)
data set. Table summarizes the amount of lost or missing
10 Hz data by month and year. On average, there was about a 97 % success rate
for the high-frequency data collection. There were several months when the
high-rate data loss exceeded 20 % (highlighted in bold in
Table ); however, most of these occurred early on in the
project. As noted in the footnotes of Table , most
periods with lost data were caused by extended power outages or hardware
failures. Since the Titan and NIDAS data systems were deployed in October 2014,
the percentage of lost high-frequency data has been less than 0.02 %.
An indication of how much effort it takes to run/manage an AmeriFlux site
such as US-NR1 is provided in Table , where the number of
annual site visits by the lead author ranged between a low of 26 in 2012 and
a maximum of 93 in 2004. The years with a higher number of visits were
typically when new instruments were being deployed, special field projects
were taking place, and/or hardware or power problems occurred. The
typical maximum time between site visits was approximately 3 weeks (with
near-constant data quality monitoring using cockpit from the CU campus
between the site visits).
Since the main tower is a metal object that is about twice the height of the
surrounding forest, in a mountainous location with active convection during
the warm-season, lightning is another consideration. When the tower was
erected, Lightning Eliminators & Consultants, Inc.
(http://www.lightningprotection.com/) installed a grounding system with two
“spline-ball” terminals at the top of the tower connected to buried
grounding rods at the base of the tower. Smaller ground rods surrounding the
tower were connected to each other by solid copper wires. Though there has
been lightning damage to components of the data system (mostly short-haul
modems and the Edgeport/8 converter, through the power line), to the best of
our knowledge, the tower has never taken a direct lightning hit. We have
found that powering the CR23X data loggers with deep-cycle batteries allows
them to keep on saving the internal 5 min mean averages (useful for
gap-filling) during power outages. We also found that lifting data cables off
the ground reduced collateral damage (e.g., electrical damage to short-haul
modems) when lightning struck near the tower. Either fiber optic cables or
wireless data transmission would be another way to minimize problems with lightning.
Though the CR23X is somewhat older technology (production of the CR23X
stopped around 2007), these data loggers have proven to be an extremely
durable, stable part of the US-NR1 data system. In collecting the 10 Hz data,
we have pushed the CR23Xs to the point where it can barely keep up with the
data-collection demands. For example, the FAST CR23X has typically been used
to ingest data from three SDM sensors (two CSAT3 sonic anemometers and one
LI-7500 IRGA) along with data from seven differential and four single-ended analog
channels. Adding additional sensors to the FAST CR23X would not allow it to
complete the full measurement cycle in 0.1 s. The only maintenance for
the CR23Xs has been the replacement of the internal battery after about 10 years.
We should also consider periodically checking the analog-to-digital
converter, but empirical evidence (such as that presented in
Sect. ) suggests they are fairly stable.
One downside to the CR23X is that it cannot sample at 10 Hz and use a GPS to
keep the internal clock from drifting. If the CR23Xs were upgraded to a more
recent data logger (such as the CR3000), then a GPS could be used to keep the
internal data logger clock from drifting. However, as described in
Sect. 4.2, because the CR23Xs are coupled with NCAR EOL data-acquisition
hardware and software (running NTP), the data samples from the CR23X are
time-tagged by the data system, making the CR23X internal clock less important.
Summary and conclusions
We found that high-rate (10 Hz) eddy-covariance data collection from multiple
off-the-shelf data loggers at the Niwot Ridge Subalpine Forest US-NR1 AmeriFlux
site was made more manageable by using a centralized computer and
data-acquisition software developed at the NCAR Earth Observing Laboratory
(https://www.eol.ucar.edu/). Using a centralized computer allowed for
consistent data storage, robust time stamps, and a flexible, real-time
calculation of statistics. The EOL software also contained a real-time
display that allowed all the measured variables to be displayed at once
(i.e., cockpit shown in Fig. ). All these features helped
to quickly alert tower staff of any potential instrument or data-system
problems and minimize the amount of lost high-rate data.
Though the data-collection philosophy has remained similar over the 17-plus
years of US-NR1 operation, the hardware and software for data-collection has
evolved and incorporated considerable improvements (with an ultimate goal of
creating a data-acquisition system that operates as long as power is
available). We worked to achieve this goal by replacing a data-acquisition
system that depended on two computers and the network for time-stamping
(Fig. ) with a data-acquisition system that depended on a
single PC/104-based computer and used a network-independent GPS for
time-stamping (Fig. ). These changes resulted in a
more robust collection of high-frequency data. Over 17 years, the average
high-rate data-collection success rate was ≈ 97 %, which increased
to better than 99.98 % (Table ) after the upgrades.
Furthermore, by powering the data loggers with external deep-cycle batteries,
it was possible to continue collecting the mean meteorological measurements
that are useful for gap-filling flux data during power outages.
Consistent with others e.g.,, we found
that GPSs provide a robust network-independent time source that coupled well
with already-established timekeeping protocols, such as the network time
protocol (NTP) and precision time protocol (PTP). GPS usage for timekeeping
has already been integrated into several measurement platforms (e.g., the
LI-COR SmartFluxTM System). Given that GPSs are readily available
from data logger manufacturers (e.g., Campbell Scientific, model GPS16X-HVS),
we strongly encourage using GPSs for environmental data collection, especially
by regional data-collection networks such as AmeriFlux.
A useful data-system integrity check was to sample data from an independent
data system and compare the sampled data with time series from the other
system for mean/offset and time-stamp differences. From this test, we found
that the CR23X data logger clock drift varied between 0.4 and
0.7 s day-1, which created a small time lag in the eddy-covariance
high-frequency data that was equal to or less than the sampling period of
0.1 s. The time lag should not impact the flux calculations because the
eddy-covariance variables are all measured with a single CR23X. Finally, we
outlined the techniques that we have employed to record and preserve the
activities and metadata at the site (including web-based calendars and
logbooks, as well as photos). We strongly recommend that careful
consideration be given to site documentation and metadata information at the
outset of any long-term measurement campaign. Furthermore,
already-established protocols e.g., should be
followed as closely as possible at the start of the project. A snapshot of
the current state of the US-NR1 metadata as well as the data-acquisition
software used is provided within the Supplement of this paper.