The Niwot Ridge Subalpine Forest US-NR1 AmeriFlux site – Part 1: Data acquisition and site record-keeping

. The Niwot Ridge Subalpine Forest AmeriFlux site (US-NR1) has been measuring eddy-covariance ecosystem ﬂuxes of carbon dioxide, heat, and water vapor since 1 November 1998. Throughout this 17-year period there have been changes to the instrumentation and improvements to the data acquisition system. Here, in Part 1 of this three-part series of papers, we describe the hardware and software used for data-collection and metadata documentation. We made changes to the data acquisition system that aimed to reduce the system complexity, increase redundancy, and be as independent as possible from any network outages. Changes to facilitate these improvements were (1) switching to a PC/104-based computer running the National Center for Atmospheric Research (NCAR) In-Situ Data Acquisition Software (NIDAS) that saves the high-frequency data locally and over the network, and (2) time-tagging individual 10 Hz serial data samples using network time protocol (NTP) coupled


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., Aubinet et al., 2012).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 (Baldocchi et al., 2001;Baldocchi, 2008;Ciais et al., 2014).These towers are often interconnected into regional networks, such as North and South America (AmeriFlux, Boden et al., 2013 and the National Ecological Observatory Network NEON, Keller et al., 2008;Kao et al., 2012), Europe (EuroFlux/CarboEurope or the Integrated Carbon Observation System; ICOS, https://www.icos-ri.eu/),Australia and New Zealand (OZFlux, Beringer et al., 2016), and Asia (AsiaFlux, Tani et al., 2008), 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 Amer-iFlux site (US-NR1, Blanken et al., 1998-present), with an emphasis on how the system has evolved over time.Part 2 describes the US-NR1 site characteristics and Part 3 describes Published by Copernicus Publications on behalf of the European Geosciences Union.
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., Monson et al., 2002;Turnipseed et al., 2002) documented the primary instruments used and provided brief descriptions of the data collection.Subsequent US-NR1 publications often contained additional instrumentation details (e.g., Burns et al., 2015, 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., Van Atta, 1974;Aubinet et al., 2000;Billesbach et al., 2004;van der Molen et al., 2006;Matese et al., 2008;Behn et al., 2008) as well as practical advice related to data acquisition within the eddy-covariance literature (e.g., Rebmann et al., 2012;Burba, 2013) and textbook overviews of atmospheric data-collection techniques and sensors (e.g., Kaimal and Finnigan, 1994;Emeis, 2010).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., Massman and Lee, 2002), the downstream data QA/QC (e.g., Papale et al., 2006;Göckede et al., 2008;Foken et al., 2012), or software comparisons (e.g., Mauder et al., 2008).
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 longterm 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 highfrequency 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.

Niwot Ridge Subalpine Forest site description
The Niwot Ridge Subalpine Forest AmeriFlux US-NR1 site is located in the Rocky Mountains of Colorado, about 8 km east of the Continental Divide with a 26 m walkup scaffolding tower as the centerpiece of the site (latitude 40 • 1 58.349N, longitude 105 • 32 49.095 W, and elevation of 3050 m).The forest near the tower is approximately 110 years old, and primarily composed of subalpine fir (Abies lasiocarpa var.bifolia), lodgepole pine (Pinus contorta), and Englemann spruce (Picea engelmannii).Typical tree heights are between 11 and 15 m.A more detailed description of the site characteristics, forest near the tower, and a map of the area which highlights pertinent locations can be found within Part 2 of our three-part series (Burns et al., 2017).

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., Businger et al., 1990) was created.This trailer was subsequently moved to the Univer- 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 (Businger et al., 1990).Specific details about the ADAM-ATI used at the US-NR1 tower are in Sect.-Earth Observing Laboratory, 1990-present).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. 1, and the data flow after October 2014 is in Fig. 2. 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 1 and shown in Figs. 1 and 2. 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.

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 (Campbell Scientific, Inc., 2006).Prior to 2002, the older CR21X data loggers were also used (i.e., Table 2), 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. 1 and 2).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.3.2).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 di-  Figure 1.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.3.2.2).
rectly 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).
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.3.4), saving the mean values locally was an important feature of the data system because it allowed for the collection of key me-teorological 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., Papale, 2012).A list of the data loggers used at US-NR1 is in Table 2, 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 2, 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 multi-  plexer (model AM416).The MRS CR10 logger was used to measure vertical snow temperature profiles (e.g., Burns et al., 2013).

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 (Businger et al., 1990).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 dataacquisition board and thus called the ADAM-ATI software (Table 1).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 CO 2 -Table 2. 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.csimeans 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.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.

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 1, Fig. 1).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.3.7).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) (Maclean and Webster, 2012).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. 2).However, some russter2 functions, such as cockpit (Sect.3.6), 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 configu-rations 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 2) 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.3.7).Second, in addition to the highrate 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 3. 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 www.geosci-instrum-method-data-syst.net/5/451/2016/Geosci.Instrum.Method.Data Syst., 5, 451-471, 2016 hard drives, and are finally archived by the AmeriFlux project on Lawrence Berkeley National Laboratory computers.

Timekeeping
In  Mills, 1998Mills, , 2010;;Lombardi et al., 2001).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., Behn et al., 2008;Refan and Valizadeh, 2012) and act as the local NTP time server.Both russter2 and the Titan/isffa were configured as precision time protocol (PTP, i.e., IEEE 1588 TM -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 1588 TM -2008) server depending on the needs at the site.
Between September 2013 and July 2015 a Campbell Scientific CPEC200 system (Campbell Scientific, Inc., 2016) with an EC155 IRGA and CR3000 data logger were installed on the US-NR1 tower as part of an IRGA comparison experiment (e.g., Burns et al., 2014).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 CO 2 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 CO 2 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 slowresponse barometric pressure and air temperature), while the high-frequency, turbulence measurements used for eddycovariance 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.3.6), 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. 3).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. 3, 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 Oncley (1989).
The second feature is that the software produces nearreal-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 (Unidata, 2016) 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.

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 uncer-tainty and guesswork in re-extracting data from the early period of US-NR1 operation (e.g., [1998][1999][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" con-tained the information about which dates/times corresponded to which OPS configuration.
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.xmlfile related to the data acquisition is required.This data acquisition information is mirrored in the niwot.xmlfile 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. 4. 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).

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. 5.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. 6).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., Keenan et al., 2014).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 imagebased 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., Schween et al., 2007;Illingworth et al., 2007).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. 6f; Aubrecht et al., 2016).
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. 6g), track snowmelt in spring (Fig. 6h), 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.

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 (Monson et al., 2002).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 2) 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 CO 2 and H 2 O 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. 7).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.3.1 and shown by the step changes back to near-zero offset in Fig. 7), 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.

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 (Burns et al., 2014).The CR3000 locally stored digital CO 2 from the EC155 that also output an analog CO 2 voltage into the FAST CR23X data logger (Table 2).When the differences between the 10 Hz analog CO 2 voltage and digital CO 2 are compared (Fig. 8), 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 CO 2 mole fraction has a typical mean value of around 400 µmol mol −1 , and the differences shown in Fig. 8 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. 8).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 CO 2 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 CO 2 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, Panofsky and Brier, 1968;Piersol, 1981;Bendat and Piersol, 1993).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 5day period in November when the ASTER/NDAQ software (Fig. 9a) and NIDAS software (Fig. 9b) were each being used.Here, we can observe more clearly that the lag between the EC155 analog CO 2 voltage and digital CO 2 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 www.geosci-instrum-method-data-syst.net/5/451/2016/Geosci.Instrum.Method.Data Syst., 5, 451-471, 2016 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.between zero and −0.1 s (Fig. 9).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. 9c), 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.3.4).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. 10).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. 10c), whereas the 30 Hz serial CSAT3 output showed two peaks, one at 0.03 s and one near 0.04 s (Fig. 10d).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. 10b).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. 10a), 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 (Burns et al., 2016).EOL software engineers are currently trying to better understand the reason for these larger-thanexpected 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 (Metzger et al., 2016).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).

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 3 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 3); however, most of these occurred early on in the project.As noted in the footnotes of Table 3, 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 3, 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 warmseason, 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.4.2) 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 timetagged 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. 3).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. 1) with a data-acquisition system that depended on a single PC/104based computer and used a network-independent GPS for time-stamping (Fig. 2).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 3) 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., Behn et al., 2008;Mills, 2010;Refan and Valizadeh, 2012), 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 SmartFlux TM 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 eddycovariance 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., Papale et al., 2012) 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.

Data availability
The Niwot Ridge US-NR1 30 min processed data are available from the urquell web page (http://urquell.colorado.edu/) as well as from the AmeriFlux Management Project (doi:10.17190/AMF/1246088).To be informed of future changes or updates to the US-NR1 data, please contact the lead author (S.P. Burns) or P. D. Blanken (blanken@colorado.edu).All phenocam photos are archived and available from http://phenocam.sr.unh.edu/.The most recent information and software from NCAR/EOL can be found on github (https://github.com/ncareol/).In the Supplement we provide the following items: Each zip archive has a corresponding README file with more details related to the files within the archive.
The Supplement related to this article is available online at doi:10.5194/gi-5-451-2016-supplement.
Acknowledgements.Andrew Tunipseed (2B Technologies) and Dave Bowling (University of Utah) designed and implemented the original instrument and data system setup at the US-NR1 site.Andrew Tunipseed also read a draft of this manuscript and kindly provided recollections and his handwritten notebooks.Jeff Beauregard assisted with site operations in 2007-2008.Over the years, students and postdocs from the Monson Lab, field technicians from MRS/LTER, and John Knowles (INSTAAR) helped to keep the tower data-system operational.Many people at NCAR EOL helped with information related to infrastructure and instruments, especially Tom Horst, Tony Delany, John Militzer, and Kurt Knudson.Jielun Sun (NCAR MMM) kindly shared a CR23X logger (and associated thermocouples).Chris Golubieski (NREL) helped with the setup of Titan/PC-104 hardware and enclosure.Edward Swiatek and others at Campbell Scientific, Inc. set up the CPEC200 and generously shared those data with us.The Niwot Ridge LTER (Mark Williams) provided the initial "forestcam", and Andrew Richardson (Harvard University) and the University of New Hampshire PhenoCam network provided subsequent cameras.Don Aubrecht (Harvard University) provided the FLIR image.Mark Raleigh (CIRES) provided advice/discussions about the Wingscapes cameras.Gilberto Pastorello (Berkeley Lab) helped with archiving of raw data files.The UnixOPS computer support group at CU (led by Orrie Gartner) was a tremendous help with the Linux/system OS and networking advice.Two anonymous reviewers provided insightful comments that improved the manuscript.The development of PhenoCam has been supported by the Northeastern States Research Cooperative and NSF's Macrosystems Biology program (award EF-1065029).The US-NR1 AmeriFlux site is currently supported by the US DOE, Office of Science, through the AmeriFlux Management Project (AMP) at Lawrence Berkeley National Laboratory under award number 7094866.The National Center for Atmospheric Research (NCAR) is sponsored by NSF.
Edited by: L. Eppelbaum Reviewed by: two anonymous referees

Figure 2 .
Figure2.As in Fig.1, 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.3.2.3).
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.,

Figure 3 .
Figure 3. 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.

Figure 4 .
Figure 4.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/.

Figure 7 .
Figure7.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.

Figure 8 .
Figure 8.A time series of the difference between the 10 Hz analog EC155 CO 2 measured by the US-NR1 data system and the 10 Hz digital EC155 CO 2 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.

Figure 9 .
Figure 9.A 30 min time series of the time lag estimated from the phase spectrum between the analog and digital signal of the CO 2 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.

Figure 10 .
Figure 10.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.

--
USNR1_logger_code.zip: all versions of the CR23X, CR21X, and CR10 data logger programs; -USNR1_webcalendar.zip: the web calendar HTML files; USNR1_webphoto.zip: the HTML files used for the site photos (and links in the web calendar pages); -USNR1_logbook.zip:the logbook (in both native and HTML format); -USNR1_turnipseed_logbook.pdf: a scanned PDF of the lab notebooks that contain information about the setup and tower operations between years 1998 and 2003; -USNR1_ati_duck_manual.pdf: PDF of the manual for the duck data acquisition system (using ADAM-ATI); www.geosci-instrum-method-data-syst.net/5/451/2016/Geosci.Instrum.Method.Data Syst., 5, 451-471, 2016 S. P. Burns et al.: Eddy-covariance data acquisition in a subalpine forest -USNR1_OPS_aster.zip: the OPS files used with ASTER/ADAM-ATI and ASTER/NDAQ; -USNR1_OPS_nidas.zip: the OPS files used with NIDAS; -USNR1_aster_ndaq.zip:source code for ASTER software which ran on russter2 and NDAQ which ran on the quacker; -USNR1_opto22.zip:source code for software which controlled the opto22 and ran on the quacker; -USNR1_prep.zip:examples of running prep on urquell to extract the raw data in ASCII for both the ASTER/NDAQ and NIDAS configurations.

Table 1 .
A chronological summary of changes to the US-NR1 data acquisition hardware and software.
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 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 1, 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 (UCAR/NCAR 3.2.1 in the text and within the Supplement (USNR1_ati_duck_manual.pdf).c NDAQ stands for the NCAR Data Acquisition system (see Sect. 3.2.2 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. 3.2.3 in text for details).Current NIDAS information is available on github, https://github.com/ncareol/nidas/wiki. sity

Table 3 .
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.
Gochis et al., 2014)er of site visits per year by the lead author (S.P. Burns) who starting working at US-NR1 in January 2003.bFrom18 to 20 March 2003, a major snowstorm knocked out the power at the US-NR1 site.cFrom28 April to 8 May 2006, the power line to the US-NR1 site was compromised.dFrom20 to 29 December 2007, russter2 had a hardware failure.eOn 12 August 2012, russter2 had a hard drive failure.fFrom 10 to 12 September 2013, the county of Boulder experienced significant rainfall (e.g.,Gochis et al., 2014), shutting down power to the site and making access to the site difficult.