dataesr/scientific-paragraphs-categorization huggingface dataset:
Each node has an internal SD memory to store sensor data, the history of the actions of the node (log file), and the configuration file. This configuration file, which is read by the microcontroller at start-up, is defined by the user and lists the configuration parameters of the node. A LoRa RF module is implemented on the electronic board to send data through the private LoRaWAN network. A GPS module has also been added to localize the sensor and to deliver a timing reference to the system. The power supply is delivered by a 3. 6 V/9000 mAh battery cell managed by a charge controller circuit. The SoLo node also integrates a small electronic card on which several sensors are implemented. These internal sensors can be activated or not. They measure temperature, air humidity, atmospheric pressure, luminosity, and acceleration.
Firmware Presentation The block diagram of the architecture of the firmware implemented inside the node SoLo is given in Figure  5. Drivers allow reading the sensors whose data are both written in a CSV file on the SD card and in a buffer to temporarily store the data ready to send. Before their transmission, the data are encoded and encrypted inside a single LoRaWAN frame with a payload limited by the Data Rate (DR) value selected (51 bytes with DR = 0 up to 222 Bytes with DR = 7). A main feature of the developed system is the possibility to easily configure its operations through a text file written on the SD card ("the configuration file" cited above). A list of the main parameters currently available is given in Table  1. Still, new ones can be added by modifying the firmware depending on the needs (new sensors, embedded data processing, new transmission strategy, etc.
Firmware Presentation The block diagram of the architecture of the firmware implemented inside the node SoLo is given in Figure  5. Drivers allow reading the sensors whose data are both written in a CSV file on the SD card and in a buffer to temporarily store the data ready to send. Before their transmission, the data are encoded and encrypted inside a single LoRaWAN frame with a payload limited by the Data Rate (DR) value selected (51 bytes with DR = 0 up to 222 Bytes with DR = 7). When the node initiates a LoRaWAN communication, an acknowledgment is returned by the server if it accepts the data to be sent. If the node does not receive this acknowledgment, it does not try again but stops communication until the next scheduled transmission time. Then, the previous data will be added to the new one within the limit of the payload.
Data Workflow The data workflow infrastructure is composed of two main software modules: (1) the Network Management Module (NMM) and (2) the Data Management Module (DMM). The NMM focuses on LoRaWAN communication and architecture. LoRaWAN is one of the LPWAN technologies widely studied currently  [31, 36, 37]  with a MAC (Medium Access Control) layer protocol based on the LoRa (Long Range) physical layer. The NMM is built on a LoRaWAN stack such as ChirpStack  [38]  or The Things Stack  [39]. According to this stack, a LoRaWAN gateway is equipped with software called the "packet forwarder. " The role of this software is to automatically forward all the received messages to the server. In basic configuration mode, the packet forwarder of a gateway accepts all the LoRaWAN frames, even those which are not related to its private network.
The filtering/selection of the frames is realized in the higher-level software components of the Lo-RaWAN stack. In the case of the ChirpStack stack, these components are the "Gateway Bridge", the "Network Server", and the "Application Server". These tools are responsible for selecting only the frames received from the accepted nodes. At the level of the "Application Server," different Web interfaces are available, allowing, for example, the monitoring of the communication infrastructure (ex: the availability of the gateways) and the registration of authorized nodes. A single gateway can cover a wide area thanks to the performance of the LoRa radio modulation, but in large or very hilly fields, it is possible to deploy several gateways in a monitoring site to have better communication coverage.
All these gateways can be associated with the same network server. In this network topology, no modification is required at the level of a gateway when a node is added or removed. This flexibility is a major asset for agricultural or environmental applications where changes to the network devices can frequently happen. Thus, nodes with different sensors can be added or removed depending on the required monitored parameters. Outdoor When the node initiates a LoRaWAN communication, an acknowledgment is returned by the server if it accepts the data to be sent. If the node does not receive this acknowledgment, it does not try again but stops communication until the next scheduled transmission time. Then, the previous data will be added to the new one within the limit of the payload. This mode of transmission saves energy when the conditions for the LoRa communication are not optimal.
The filtering/selection of the frames is realized in the higher-level software components of the LoRaWAN stack. In the case of the ChirpStack stack, these components are the "Gateway Bridge", the "Network Server", and the "Application Server". These tools are responsible for selecting only the frames received from the accepted nodes. At the level of the "Application Server," different Web interfaces are available, allowing, for example, the monitoring of the communication infrastructure (ex: the availability of the gateways) and the registration of authorized nodes. A single gateway can cover a wide area thanks to the performance of the LoRa radio modulation, but in large or very hilly fields, it is possible to deploy several gateways in a monitoring site to have better communication coverage.
All these gateways can be associated with the same network server. In this network topology, no modification is required at the level of a gateway when a node is added or removed. This flexibility is a major asset for agricultural or environmental applications where changes to the network devices can frequently happen. Thus, nodes with different sensors can be added or removed depending on the required monitored parameters. Outdoor nodes are also submitted to extreme conditions, which increase the risks of failures and require "fast" node replacements. Concerning the data, this NMM converts LoRaWAN frames of SoLo nodes into files generally in JSON (JavaScript Object Notation) format. The generated data files are then processed by the DMM of the data center infrastructure. This DMM has multiple functionalities, and it can be called "hybrid" because it combines tools from different software families.
For example, it integrates database management systems (DBMS) in the NoSQL model (storing JSON and using corresponding SQL (Structured Query Language) queries) and more recent search engine technologies. As a DBMS, we can mention PostgreSQL  [17]  with PostGIS extension and, as a search engine, Elasticsearch  [18]. Other functionalities are related to data visualization with the availability of tools such as Grafana  [40]  and Kibana  [41]. Data can also be processed as (input and output) streams using, for example, MQTT (Message Queuing Telemetry Transport) protocol  [42]. Data can also be exported in new JSON format, CSV, and others. Depending on the data connectors and converters used, the possibilities are huge. In order to achieve real-time data visualization and to address the most various cases of possible use, a near-real-time multi-pipeline architecture has been designed in a generic way.
Altogether, these tools enable reliable and near real-time data management. Interestingly, it provides a data visualization allowing, for example, to immediately check the installation of a sensor or a node in situ. Sensors 2023, 23, x FOR PEER REVIEW 7 of 25 nodes are also submitted to extreme conditions, which increase the risks of failures and require "fast" node replacements. Concerning the data, this NMM converts LoRaWAN frames of SoLo nodes into files generally in JSON (JavaScript Object Notation) format. The generated data files are then processed by the DMM of the data center infrastructure. This DMM has multiple functionalities, and it can be called "hybrid" because it combines tools from different software families. For example, it integrates database management systems (DBMS) in the NoSQL model (storing JSON and using corresponding SQL (Structured Query Language) queries) and more recent search engine technologies.
The routing of each measurement to its right index location is done using an index naming convention in which the experiment name (present in the node file configuration as mentioned in Table  1 ), the node name, and the measurement date is used. This way, variables can be easily isolated and queried to generate time series. Although the ingested data format is JSON in the context of a SoLo node, the pipeline can also handle structured sources (such as databases) or semi-structured sources (such as flat CSV, text, and JSON files). More information about data integration can be found in our previous article  [44]. In order to analyze the performance of the networks, we studied the data workflow, the battery consumption, the rate of data loss during data transmission and the received signal strength over a given period.
These metrics are those classically used in the literature to qualify wireless sensor networks  [45, 46]. The routing of each measurement to its right index location is done using an index naming convention in which the experiment name (present in the node file configuration as mentioned in Table  1 ), the node name, and the measurement date is used. This way, variables can be easily isolated and queried to generate time series. Although the ingested data format is JSON in the context of a SoLo node, the pipeline can also handle structured sources (such as databases) or semi-structured sources (such as flat CSV, text, and JSON files). More information about data integration can be found in our previous article  [44]. In order to analyze the performance of the networks, we studied the data workflow, the battery consumption, the rate of data loss during data transmission and the received signal strength over a given period.
Site description The INRAE site of Montoldre is one of the real conditions deployment sites of the network and data infrastructure presented in the previous sections. The Montoldre farm is located in the department of Allier in the Auvergne-Rhône-Alpes region at 300 m above sea level. The main goal of this monitoring site is to study the water in an agricultural use case. The network is based on different SoLo nodes connected to a local gateway through the LoRaWAN communication protocol. One of the particularities of this deployment is using an Ethernet connection between the gateway and the LoRa Server instead of a mobile technology protocol found in other sites.
Scientific objectives In the Montoldre monitoring site, an experiment was conducted for months with the acquisition of data related to air and soil elements. Water is studied as the essential element for the cultivation of agricultural plants. Sensors are also used in the context of this experimental farm to have information on soil conditions for machines or robots working in the fields. The performance of node SoLo is also tested on this site: robustness of the communication, autonomy, etc. (see Figure  10 ). Air temperature, humidity, and luminosity measurements are collected using the embedded sensors of the SoLo nodes. For the soil temperature and moisture, SoLo nodes are equipped with Truebner SMT-100 sensors  [59] ; see Figure  11. With these low-cost soil sensors, the goal is to get soil dynamics more than accurate measurements.
Real-Time Visualization of the Data For data visualization, a dedicated interface was built for each data-col with a possible mix of dashboards, mostly graphs and data tables. A collect Node operating indicators are also monitored, such as battery level, RSSI (Receive Signal Strength Indicator), and SNR (Signal-to-Noise Ratio) for quality of transmission. For this experiment, SoLo nodes are located at different distances to test the impact of a LoRaWAN star topology network with heterogeneous ranges. Indeed, some nodes are localized at 50 m of the Montoldre LoRaWAN gateway, which is very close if we consider the LoRa capabilities. Other nodes are placed at 500 m of the gateway. The goal is not to reach a maximum transmission range but to study the possible impacts of spreading the nodes through different conditions at the level of an experimental farm.
Data visualization is done by time series generated by queries on quantities (variables). Strikingly, the simplicity of the queries allows all users to create their own graphs. Secure access through the use of a personal account (a local account on the platform or the eduGAIN personal account by operating OpenSAML authentication) and the https (HyperText Transfer Protocol Secure) protocol enables data isolation, i. e. , providing everyone with access only to the data they need and they are allowed to access. This is achieved with the combined use of group and organization with data sources in Grafana. An interesting point is potentially creating data sources for particular events by reindexing existing data reduced to defined variables, time intervals, or material. This reindexed source can then be deleted once the event is completed.
Finally, although focusing on the real-time aspect, the dashboards can also be used for more sophisticated queries, such as cross-referencing or historical data. In this case, these graphs retrieved data from sources built upon PostgreSQL databases. go from a group of SoLo nodes in the same or in different areas of a specific monit site. The following Figure  12  shows an example of the data visualization interface. For example, this interface allows comparing measurements from different nodes equipped with the same sensors. Comparison between different areas or ex mental deployment conditions can be made. Here, the graphs and tables are comple tary. Graphs provide a "rapid look" at the measurements and their evolution over Tables allow focusing on a given date or period with visualization of the data values visualization is done by time series generated by queries on quantities (variables).
The results are plotted in Figure  14. Two pairs of values extracted from data transmitted by nodes deployed on-site have also been added. Figure  14  shows a good correlation between the value of the initial slope of the discharge and the battery lifetime. Using the regression equation  = 2 10. , the value of the battery lifetime (y) can be evaluated by measuring the initial slope of the discharge (x) thanks to the data transmitted by the LoRaWAN network. Even if the precision of this estimation is limited to about 20% and does not consider the impact of significant temperature variations during the deployment of the node on site, this method is simple, robust, and useful for scheduling the maintenance period.
Packet Loss Analysis In a wireless sensors network, the analysis of the Packet Loss Rate (PLR) is crucial to assess the reliability of the network. Several factors affect the PLR, such as the weakness Figure  14  shows a good correlation between the value of the initial slope of the discharge and the battery lifetime. Using the regression equation y = 2 × 10 -5 × x -0. 944 , the value of the battery lifetime (y) can be evaluated by measuring the initial slope of the discharge (x) thanks to the data transmitted by the LoRaWAN network. Even if the precision of this estimation is limited to about 20% and does not consider the impact of significant temperature variations during the deployment of the node on site, this method is simple, robust, and useful for scheduling the maintenance period.
The residuals (i. e. , variations in RSSI not induced by changes in distances between nodes and gateways) are then integrated into the dataset, and a random forest regression model is fitted to identify the visibility variables (VIEW, LOS_CONF, LOS_F_rate) that contribute the most to explaining the deviations from the standard lognormal path-loss model. Statistical comparison of RSSI between groups was also performed using the nonparametric Kruskal-Wallis test implemented in the ggstatsplot R package  [63].
July 2021 to 14 November 2021 for the Auzon site (N = 33,661 RSSI measurements distributed over four nodes), from 25 May 2021 to 20 December 2021 for the Aydat site (N = 33,405 distributed over five nodes), from 5 January 2021 to 20 April 2022 for the Montoldre site (N = 31,193 distributed over four nodes) and from 14 April 2021 to 23 May 2022 for the ZATU site (N = 2374 distributed over three nodes). The LogD parameter is computed as the decimal logarithm of the Euclidian distance between each node and its associated gateway. Euclidean distances between nodes and gateways are derived from their geographic locations expressed in Lambert 93 cartographic projection and collected in the field using a Trimble R10 GPS/GNSS device with centimeter accuracy. The viewshed of the gateways of the four study sites was computed using Digital Elevation Model (DEM) with a ground resolution of 1 m (RGE dataset from the French Institut National de l'information Géographique et forestière-IGN) and the Viewshed toolkit provided by the ArcGIS Pro software (3d Analyst Tools).
Each node of the study site is then classified as IN or OUT of the viewshed of its gateway and stored in the VIEW bimodal variable of the dataset. The LOS_CONF parameter is derived from the LOS topographic profiles of each node which are extracted from the same RGE DEM using the Stack Profile tool provided by the ArcGIS Pro software (3d Analyst Tools). Each node is then classified into one of the three topographic configuration classes (A, B, or C) based on the open or broken nature of the LOS and its topographic mask index, according to Figure 15 The LOS_F_rate is the rate of the LOS covered by trees (>3 m high), computed from the 2019 aerial photographs provided by the CRAIG and the IGN.
SoLo nodes from 3 3 July 2021 to 14 November 2021 for the Auzon site (N = 33,661 RSSI measurements distributed over four nodes), from 25 May 2021 to 20 December 2021 for the Aydat site (N = 33,405 distributed over five nodes), from 5 January 2021 to 20 April 2022 for the Montoldre site (N = 31,193 distributed over four nodes) and from 14 April 2021 to 23 May 2022 for the ZATU site (N = 2374 distributed over three nodes). The LogD parameter is computed as the decimal logarithm of the Euclidian distance between each node and its associated gateway. Euclidean distances between nodes and gateways are derived from their geographic locations expressed in Lambert 93 cartographic projection and collected in the field using a Trimble R10 GPS/GNSS device with centimeter accuracy. The viewshed of the gateways of the four study sites was computed using Digital Elevation Model (DEM) with a ground resolution of 1 m (RGE dataset from the French Institut National de l'information Géographique et forestière-IGN) and the Viewshed toolkit provided by the ArcGIS Pro software (3d Analyst Tools).
16S Rrna amplicon sequencing and processing of raw sequences Genomic DNA was extracted and purified as previously described. A single lane of the Illumina MiSeq system was used to generate 251-base paired-end reads from variable region V4 of the 16S rRNA gene using barcoded universal primers (515F/806R) in ticks. The paired 16S rRNA raw sequences obtained from the OeMG, OeSG, OmMG, and OmSG samples were deposited in the SRA repository (Bioproject No. PRJNA931807). Analysis of 16S rRNA sequences was performed using the QIIME 2 pipeline  (v. 2021. 4; Bolyen et al. , 2019). The raw sequences (demultiplexed in fatsq fles), were denoised, quality trimmed and merged using the DADA2 software  (Callahan et al. , 2016)  implemented in QIIME2  (Bolyen et al. , 2019). The obtain amplicon sequence variants (ASVs) were aligned with q2-alignment of MAFFT  (Katoh et al.
, 2002)  and used to generate a phylogeny with q2-phylogeny of FastTree 2  (Price et al. , 2010). Taxonomy was assigned to ASVs using a classify-sklearn naïve Bayes taxonomic classifier based on SILVA database (release 138;  Bokulich et al. , 2018). Only the target sequence fragments were used for the classifier (i. e. , the classifier was trained with primers 515F/806R;  Werner et al. , 2012; Ren and Wu, 2016).
05) on QIIME 2. Beta dispersion was calculated using the betadisper function and the Vegan script implemented in RStudio  (Oksanen et al. , 2021). Statistical analyses of beta dispersion were performed using an ANOVA test (p ≤ 0. 05). Cluster analysis was performed with the Jaccard coefficient of similarity using Vegan  (Oksanen et al. , 2021)  implemented in RStudio  (RStudio Team, 2020). Jaccard distance is represented between 0 and 2, and lines are proportional to this distance. Differences in taxa abundance between the four conditions were tested using a Kruskal Wallis test and implemented using the ANOVAlike differential expression (ALDEx2) package  (Fernandes et al. , 2013)  on RStudio  (RStudio Team, 2020). The ALDEx2 method involves constructing Monte Carlo samples of Dirichlet distributions to account for the uncertainty in the number of reads in each sample.
Inference of bacterial co-occurrence networks Co-occurrence networks were created for each dataset using the taxonomic profiles at genera level. The networks provide a graphical representation of the microbial communities, with nodes representing taxa and edges indicating significant correlations between them. Analyses of significant positive (weight > 0. 75) or negative (weight < -0. 75) correlations were performed using the Sparse Correlations for Compositional data (SparCC) method  (Friedman and Alm, 2012) , implemented in RStudio  (RStudio Team, 2020). Visualization and measurement of topological features (i. e. , number of nodes and edges, network diameter, modularity, average degree, weighted degree and clustering coefficient) of the networks were performed using Gephi v0. 9. 2  (Bastian et al.
, 2009). Four Core Association Networks (CAN) were computed to search for conserved interactions in networks of different species and same tissues (i. e. , OeMG vs. OmMG, and OeSG vs. OmSG) and networks of the same species and different tissues (i. e. , OeMG vs. OeSG, and OmMG vs. OmSG) using the software toolbox, anuran (a toolbox with null models for identification of nonrandom patterns in association networks;  Röttjers et al. , 2021) , and in a version available for Python 3. 6.
Keystone taxa identification Keystone taxa were defined based on three criteria, as previously reported  (Mateos-Hernández et al. , 2021) : (i) ubiquitousness (microbial taxa present in all samples in an experimental group), (ii) eigenvector centrality higher than 0. 75, and (iii) high mean relative abundance (i. e. , higher than that of the mean relative abundance of all taxa in an experimental group). The eigenvector centrality measures the influence of a node in a network, a high eigenvector score means that a node is connected to many nodes which themselves have high scores  (Ruhnau, 2000). Eigenvector centrality values were exported from Gephi (v 0. 9. 2) software  (Bastian et al. , 2009). For each sample in both datasets, the mean clr value was calculated and plotted together with the eigenvector centrality values using GraphPad Prism (v 8.