dataesr/scientific-paragraphs-categorization huggingface dataset:
Base Station The role of the base station (Figure  1c ) is four-fold: (i) control and maintain the network, up to 100 nodes; (ii) collect the sensor measurements from the sensor stations; (iii) locally store the data; and (iv) transmit the data to the server on the Internet through a cellular connection. The base station is built around a 100 mm diameter aluminum pole. The waterproof fiberglass enclosure mounted 1. 5 m from the ground contains several elements. First, it contains a Network Manager from Metronome Systems (Figure  2c , 1 ), which acts as the gateway of the SmartMesh IP network. The Manager contains two main elements: a SmartMesh IP module and a GNU/Linux computer consuming only 50 mA. They are connected to one another by an internal serial interface. This Network Manager uses a 2.
Server The role of the server (Figure  1c ) is three-fold: (i) receive the data sent by the base stations of multiple deployments; (ii) store the data in a database; and (iii) offer a web interface to navigate and download the data. The server is rack-mounted and located at UC Berkeley. It is equipped with an 3 GHz Intel Core i7 CPU, a 1 TB drive, and 8 GB of RAM memory.
Low-Power Wireless Mesh Network Each device (sensor station, repeater node, and base station) is equipped with the same SmartMesh IP LTC5902-IPM (http://www. linear. com/product/LTP5902-IPM SmartMesh IP Wireless 802. 15. 4e PCBA Module with Antenna Connector) wireless module. This module contains a combined radio and micro-controller system-on-chip, an antenna connector, and all required passives and crystals. It comes preprogrammed and takes care of all the networking aspects. It either runs entirely standalone ("master" mode) or can be driven by an external micro-controller through a serial interface ("slave" mode). When switched on, all of these devices form a low-power wireless multi-hop mesh network. The fact that it is multi-hop means that if a sensor station is too far from the base station to transmit its data directly, other device(s) serve as relays.
Software Architecture The Sensor Object Library (SOL) software architecture was fully developed for the deployments described in this article. The details about SOL System have been previously published in  [28]. This section provides the necessary overview, illustrated by Figure  3. SOL resides in four different locations: the sensor station (Section 2. 3. 2), the repeater node (Section 2. 3. 3), the base station (Section 2. 3. 4) and the server (Section 2. 3. 5). All the code developed is provided under a BSD open-source license (as an online addition to this paper, all source code can be found at https://github. com/realms-team). The code is being developed using state-of-the-art software development project management tools, and is production-ready.
Sensor Object Library (SOL) The driving concept in the design of SOL is that each sensor measurement or network statistics is represented as an atomic SOL object. Conceptually, this self-contained SOL object is formed by the fields listed in Table  1. This format is an equivalent to the well-known Type-Length-Value (TLV) scheme, to which we have added address and timestamp fields. A publicly-maintained SOL registry (https://github. com/realms-team/sol/blob/master/registry. md) lists the different SOL object types, and for each the format of the value V. Figure  4  shows an excerpt of the SOL registry, on the format of a SOL object corresponding to the Sensirion SHT25 temperature and humidity sensor. It indicates that the value V field is 4 bytes long: a 2 byte temperature value followed by a 2 byte relative humidity value.
The SOL registry currently contains 55 entries. A SOL object can be encoded in 2 different formats, an example of which is shown in Figure  5. When the sensor station generates a SOL object, it encodes it in a compact binary format, typically 10-50 bytes. This is what the sensor station writes into the packets it sends to the base station across the low-power wireless mesh network. The base station converts the binary encoding into the equivalent JSON encoding. JSON  [29]  is a text-based encoding ubiquitous in machine-to-machine communication on the Internet, and well-supported by tools, including the database and web interface on the server. We have developed Python and C core libraries to manipulate SOL objects, including serialization, de-serialization, conversion and validation routines.
Sensor Station Firmware The SmartMesh IP module of the sensor stations comes pre-programmed. The only modification applied is that it is configured to operate in "slave" mode, allowing the PSOC to drive it over a serial port. It is also configured to automatically join the network. The PSOC firmware handles the following basic tasks: (i) it samples the different external sensors; (ii) it saves those measurements locally on the SD card; and (iii) it sends that information to the SmartMesh IP module. These different steps are executed every 15 min; between those activity periods, the PSOC is in ultra low-power mode. The PSOC also implements advanced features, such as the ability to request the sensor station to resend some of the previous measurements stored on its SD card. The firmware comes with a library of drivers for the different sensors.
Base Station Software The SmartMesh IP module of the base station comes pre-programmed as manager for up to 100 nodes, and is used as-is. The GNU/Linux computer, running a Debian Jessie instance, handles the following tasks: (i) it drives the cellular modem connected to it; (ii) it waits for notifications from the SmartMesh IP manager, containing the sensor measurements generated by the sensor stations; (iii) it stores those notifications locally in a back-up file; (iv) it converts the SOL objects contained in the notifications from their binary to their JSON encoding; and (v) it sends these objects to the server. The cellular modem is configured to switch to low power standby mode when its input voltage drops below a threshold of 11V.
Server Software The server runs Ubuntu 14. 04. 1 LTS, a flavor of GNU/Linux. Three base services are deployed: (i) a Python-based program offers a RESTful HTTPS/JSON interface for base stations to send their data to; (ii) an InfluxDB time series database (https://www. influxdata. com/) holds all the SOL objects; and (iii) a Grafana web frontend (https://grafana. com/) allows a user to navigate the data. The server builds a web frontend on top of these base services, allowing the user to see the logical topology of the network (Figure  6a ), see the map of the network (Figure  6b ), and navigate the sensor data (Figure  6c ).
If no cellular connectivity is found, the back-up option is to use a satellite connection. Sensor station placement: Once the possible locations for the base station are identified, the next step is to identify the locations of the sensor stations. This is done based on a combination of hydrologic and network considerations. The goal is to identify 12 locations (in the deployments covered in this article, the limit of number of sensor stations per deployment site is 12, based on budgetary considerations) within the 1 km 2 deployment area which capture the variability of variables known to affect snow cover: slope, aspect, vegetation and elevation. This is done by a machine-learning program developed in our laboratory  [30]. An additional constraint is that, given multiple potential sensor station locations, we prefer locations that are close to the base station to limit the number of repeaters.
Deployments The technology described in Section 2 has been deployed in three DWR-maintained independent sites across the Feather River basin in California, USA. The sites are Bucks Lake (BKL), Grizzly Ridge (GRZ) and Kettle Rock (KTL). Table  2  gives the position of the deployments, as well as the geographical size and number of devices. Table  3a -c summarizes the topographical features of the sensor station locations in each deployment. The number in the "Sensor station" column is the same as the one in Figure  7. "Slope" indicates the slope of the ground at the sensor station location. "Aspect" indicates the orientation of the slope relative to North. "Vegetation" indicates the percentage of vegetation at the sensor station location. This feature was estimated basing on the NLCD canopy dataset (https://www.
Examples of Hydrologic Data from WSNs Figure  8  shows an example of mid-winter sensor data from Grizzly Ridge beginning 15 January 2017 and ending 1 March 2017. Figure  9  reports a second example from the same site, but in this case spans from 1 May 2017 to 15 Junuary 2017 (snowmelt season). These two temporal windows are used to exemplify the entire spectrum of hydrologic fluxes and states that were monitored during the 2016-2017 water year using wireless sensor networks. Line colors for panels (e-h) are the same as panel (a). Because measurements of air temperature and relative humidity show relatively small variability within nodes, panels (b,c) only report maximum-minimum range and mean. Solar radiation is only measured at node 1 (pillow) and shown in (d). Soil moisture and temperature sensors at 25 cm depth malfunctioned at both nodes 6 and 8 during the reported periods.
The only period of constant snow depth was recorded between 14 May 2017 and 17 May 2017 and was marked by simultaneous negative air temperature, saturated air, and decreased solar radiation. While these conditions might be indicative of precipitation, a cross-check with snow depth data (constant) and co-located soil moisture data (decreasing at most nodes) can exclude significant precipitation events during this temporal window (again in agreement with the co-located rain gauge). In terms of soil temperature, the end-of-season date was marked by diurnal temperature cycles that were not observed during periods of snow on the ground (Figure  9g -h,  [38] ). Shallower temperature probes (Figure  9g ) showed more pronounced cycles than deeper sensors (Figure  9h ), which is consistent with expected temperature profiles with depth.
In addition, for the purposes of comparison, we highlight the depth recorded by the sensor node placed at the snow pillow. This node represents the same location as the pre-existing, standard snow and meteorological station. While this station also measures SWE, this variable is not directly measured by our wireless sensor networks. The datasets show similar temporal patterns: accumulation occurs from December to February; peak accumulation in March; and snowmelt from April to May. Snow courses, however, tend to overestimate the mean site snow depth and may even exceed the maximum measurement from sensor nodes. The coarse temporal resolution of the snow courses makes it difficult to capture important hydrologic statistics such as date of peak snow or snow meltout date. The WSN data reveals that spatial variability increases over time in response to different solar radiation inputs across the nodes, mainly due to different aspects and vegetation coverage.
Estimated Performance We use the Dust Networks SmartMesh Power and Performance Estimator (http://www. linear. com/docs/42452)  [26]  to calculate the performance of the network. Table  4  provides a full list of the input parameters. We use Figure  6a  to count the number of devices at each hop. All other input parameters correspond exactly to the application deployed. Table  5  lists the key estimated performance indicators. The average current consumption of a device depends on its position in the network: the closer to the base station (the lower its "hop" value), the more stations it has to relay for, and the more current it consumes. All SmartMesh IP modules consume <50 µA. For repeater nodes that joined the network, that is the maximum current consumed (there are no other components).
Since a repeater node is powered by a 17 Ah battery, this translates to tens of years of battery lifetime (A device consuming 49. 7 µA should live for 39 years when powered by a 17 Ah battery. That being said, the shelf life of the Tadiran TLH-5930 D-cell battery is 20 years. The effective maximum lifetime is hence 20 years). A sensor station is equipped with many more electronics, including the PSOC and the sensors. The current draw of the SmartMesh IP module becomes negligible. The sensor station is powered by a 17 Ah battery pack, recharged by a 15 W solar panel, which is enough to perpetually power all electronics. Table 5 also indicates that the average latency (the time it takes for a sensor measurement to travel from the sensor station to the base station) is <6 s max. It takes <30 min for the entire network to build at installation.
Some datasets, like MODIS, only provide direct information about snow covered area and are available at daily timesteps but at relatively coarse spatial scales (500 m), whereas other platforms only provide bi-weekly snapshots (see the US Landsat mission) or are still in an experimental phase (see for example the EU SENTINEL mission). Remote sensing is a promising complementary tool to WSNs, as it may provide information on broader spatial patterns that WSNs lack. WSNs provide the finer temporal resolution necessary for short-term streamflow forecasting. In California, for example, the Airborne Snow Observatory is now providing maps of snow depth at an unprecedented spatial resolution  [21] , even though the spatial and temporal extent of these scans is still limited by budgetary constraints.
Design Choices: Comparison with Other Wireless Solutions Numerous wireless solutions-both academic and off-the-shelf commercial-are available which may be considered for our application. Below, we offer a brief comparison and justification for selecting the SmartMesh IP system. Low-power wide-area network (LPWAN) technology has received attention in the last year, with two competing approaches, Sigfox and LoRA. They are similar in that compliant radios send small frames to one or more base stations up to 15 km away. The range makes it a very appealing technology, and remote environmental monitoring could be an ideal target application. However, we have identified several potential drawbacks which rule out LPWAN for our purposes. First, the amount of data LPWAN technology can carry is too little.
Rationale for using SmartMesh IP The analysis above has lead us to opt for SmartMesh IP, coupled with a single cellular connection at the base station. The result is a complete end-to-end solution with key benefits, which we list below. Low complexity and cost. The low-power wireless network connects all sensor stations to the base station locally at the deployment site. This means that only the base station (not the sensor stations) needs to connect to the Internet, improving reliability and resiliency of the system. Multi-km 2 deployment area. Given its multi-hop nature, a sensor station can be arbitrarily far from the base station. A deployment can span several km 2. Ultra low-power operation. The SmartMesh IP modules consume <50 µA on average, allowing over a decade of battery lifetime.
Wire-like reliability. SmartMesh IP was designed for critical industrial applications, and offers over 99. 999% end-to-end reliability. Fully bi-directional communication. At any point in time, a network administrator or monitoring program can send commands to any of the devices in the network. This ability permits, for example, tuning parameters midseason. Over-the-air reprogramming. As a corollary to having bi-directional communication, all SmartMesh IP modules can be securely reprogrammed over-the-air. Built-in diagnostics. Each SmartMesh IP device regularly generates diagnostic data allowing a network administrator to have full visibility over the health of the network. Proven and truly off-the-shelf. Over 60,000 SmartMesh networks have been deployed so far. One vendor alone, Emerson, claims over 31,900 networks, with cumulated node operating hours above 9 billion (http://www.
Comparison with Existing WSN Systems for Snow Monitoring Multiple research projects, described below, aim to use WSNs to monitor snow properties. A 57-node WSN was successfully deployed across a forested, 1-km 2 headwater catchment in the southern Sierra Nevada of California using SmartMesh IP technology as the system backbone but with different sensors, hardware and software design  [34]. The software and hardware used did not allow for data recovery. It was determined that a 50-m node-to-node spacing would conservatively lead to a good PDR. More importantly,  [34]  highlight the importance of network reconfiguration during the actual deployment using information of RSSI and PDR collected by the network to avoid network collapse. A histogram of PDR values showed that after readjustment, about 80% of all network paths are performed "within the desired 85-90% design value, and over 50% of all paths are at 100% PDR"  [34].
3. A firmware/hardware bug prevented some sensor nodes from sampling and sending data after a power recovery from a total battery discharge. The bug was attributed to the gradual voltage increase during recharge that mainly affected the real time clock component. The problem was subsequently fixed by adding a power-up voltage threshold and a delay to guarantee the different NeoMote components are operational before the main code starts. Only a few nodes exhibited this behavior, which was resolved by the code update. 4. We experienced extensive rodent damage to exposed antenna, sensor and solar power wires, especially at Bucks Lake. The cables close to the ground were all in metal conduit but the wires from the solar panel and temp/rH at the 5 m level were exposed. The 5 m of snow in 2017 allowed the pesky rodents to access these exposed wires.
g. , through a Markov-model of the system evolving in multiple environments  [60] ). Finally, we intend to generate real-time SWE maps by blending our WSN data with remote sensed products such as MODIS and Landsat fractional snow cover. These spatial snowpack maps can then be assimilated into runoff models such as PRMS in an attempt to improve reservoir inflow forecasting. From a hydrologic perspective, this is the most important direction of future developments and the real testing ground for the value of WSNs. Snow patterns are highly variable in space and time and this heterogeneity has important feedbacks with various aspects of the biosphere, including vegetation distribution and streamflow timing during the dry season. While these results show potential for an improved monitoring of hydrologic fluxes at locations that are representative of relevant physiographic features, leveraging this information to provide real-time and spatially consistent information at catchment scale will expand the dataset and provide more useful tools for water resources managers.
Acknowledgments: This work is partially supported by the  California Energy Commission  through the grant " Improving Hydrological Snowpack Forecasting for Hydropower Generation Using Intelligent Information Systems " ( EPC-14-067 ),  Pacific Gas and Electric Co , the  California Department of Water Resources, UC Water, Inria  through the REALMS associate team, and the  European Commission  through the  H2020 F-Interop  and  H2020  ARMOUR projects. We thank  Ms Katharina Snyder  for her support and  Kevin Richards  for his guidance and support. We also would like to thank those who participated in the network deployment. They include  Zeshi Zheng ,  Amanda Lee ,  Robert Taylor ,  Ansel Mcclelland ,  Katya Rakhmatulina ,  Wassim Lababidi ,  Mohammad Tuqan  and  Ziran Zhang.
Abstract. In this study, vertical profiles and columnintegrated aerosol properties retrieved by the GRASP (Generalized Retrieval of Atmosphere and Surface Properties) algorithm are evaluated with in situ airborne measurements made during the ChArMEx-ADRIMED field campaign in summer 2013. In the framework of this campaign, two different flights took place over Granada (Spain) during a desert dust episode on 16 and 17 June. The GRASP algorithm, which combines lidar and sun-sky photometer data measured at Granada, was used to retrieve aerosol properties. Two sun-photometer datasets are used: one co-located with the lidar system and the other in the Cerro Poyos station, approximately 1200 m higher than the lidar system but at a short horizontal distance. Column-integrated aerosol microphysical properties retrieved by GRASP are compared with AERONET products showing a good agreement.
Differences between GRASP retrievals and airborne extinction profiles are in the range of 15 to 30 %, depending on the instrument on board the aircraft used as reference. On 16 June, a case where the dust layer was coupled to the aerosol layer close to surface, the total volume concentration differences between in situ data and GRASP retrieval are 15 and 36 % for Granada and Cerro Poyos retrievals, respectively. In contrast, on 17 June the dust layer was decoupled from the aerosol layer close to the surface, and the differences are around 17 % for both retrievals. In general, all the discrepancies found are within the uncertainly limits, showing the robustness and reliability of the GRASP algorithm. However, the better agreement found for the Cerro Poyos retrieval with the aircraft data and the vertical homogeneity of certain properties retrieved with GRASP, such as the scattering Ångström exponent, for cases with aerosol layers characterized by different aerosol types, shows that uncertainties in the vertical distribution of the aerosol properties have to be considered.
The EARLINET  (European Aerosol Research LIdar NETwork; Pappalardo et al. , 2014)  and LA-LINET (Latin American LIdar NETwork;  Guerrero-Rascado et al. , 2016)  have also been established in order to provide long-term database for the vertical and temporal distribution of aerosols over Europe and Latin America, respectively. The retrieval of particle vertical microphysical properties from multiwavelength lidar systems is possible by inverting measurements of three aerosol backscatter and two extinction coefficients, known as the 3β + 2α configuration, using the algorithms developed by  Müller et al. (1999) ,  Böckmann (2001)  and  Veselovskii et al. (2002). However, 3β + 2α measurements are scarce compared with the large database of elastic lidar measurements. In this sense, different inversion methods were recently developed within the framework of EARLINET in order to retrieve vertical profiles of aerosol microphysical properties using combined information of elastic lidar and sun-photometry measurements.
Field campaigns with state-of-the-art instrumentation offer unique possibilities for the evaluation of new retrievals techniques of particle microphysical and optical properties. Recently, the ADRIMED (Aerosol Direct Radiative Impact on the regional climate in the MEDiterranean region) field campaign, which was part of the international cooperative research program Chemistry-Aerosol Mediterranean Experiment (ChArMEx;  Dulac, 2014) , was carried out with the main objective of capturing the high complexity of the different aerosol types in the Mediterranean region  (Mallet et al. , 2016). Several in situ and remote sensing measurements both from surface and on airborne platforms were collected during this campaign using state-of-the-art instrumentation. The measurements were performed at different stations over the western Mediterranean region during summer 2013 to create an updated database of the physical, chemical and optical aerosol properties as well as the vertical distribution of the major "Mediterranean aerosols"  (Mallet et al.