The two identical UASs deployed during the missions were developed on a DJI Matrice 600Pro platform equipped with DJI A3 Pro flight control systems. The unfolded dimensions (including propellers, frame arms, GPS mounts, and landing gear) of the system are 1668 mm × 1518 mm × 727 mm. The recommended maximum payload capacity of the platform is 5.5 kg. At no load, the UAS has a flight endurance of 35–40 min on a single set of six DJI TB48S batteries. The manufacturer-specified positioning accuracy is ±0.5 m in the vertical axis and ±1.5 m horizontally . The maximum ascent and descent speeds are 5 and 3 m s-1, respectively. The flight controller offers real-time access (read-only) to the UAS's onboard sensor data, such as position, velocity, and attitude, through a serial interface. Additionally, a mobile application allows a user to plan and deploy a flight trajectory, and the remote controller allows intervention from the user at any point.

Table  describes the specifications of the temperature and humidity (TH) sensors used for the dataset. Every UAS flight used one iMet XQ2 from InterMet Systems (Grand Rapids, MI, USA) as the primary TH sensor. The XQ2 is a self-contained sensor package designed for UASs to measure atmospheric pressure, temperature, and relative humidity. It is also equipped with a built-in GPS and an internal data logger along with a rechargeable battery. A serial interface provides access to the logs or real-time observations produced by the sensor at 1 Hz. The internal data logger was only used as backup and is not part of this dataset. Data included in the dataset were collected through the data acquisition (DAQ) system using the serial interface. Some UAS flights featured an older version of this sensor, called iMet XQ1, as the secondary backup sensor.

Some flights also used a nimbus-pth as the secondary sensor, which is a sensor package unit we designed and built for pressure, temperature, and humidity sensors. Several nimbus-pth's can be chained as nodes for data collection. In some data files, two of these nodes might be present. In such cases, one of them was aspirated inside our sensor housing, and the other one sat directly underneath the UAS in a traditional non-aspirated configuration. In the data files, the first two sensors were shielded and aspirated inside the housing, and the third sensor (when available) was in a traditional non-aspirated configuration.

The sensor housing is designed to meet or exceed sensor placement requirements, such as consistent aspiration for the sensors and shielding from solar radiation and other indirect heat sources. The housing draws air passively by exploiting the pressure differential between the region just above a propeller and the region just beyond the rotor wash. The airflow through the housing is always maintained as long as the propellers are spinning and provides a consistent aspiration for the sensors . The inlet and outlet of the housing are shaped like a cone to provide high-speed airflow across the housing tube with a small pressure difference between the two ends. Additional design considerations are made to ensure that the flow is consistent and provide airflow ≥ 5ms-1 across the sensors even at the lowest propeller speeds.

Sensors are placed inside the tube structure as shown in panels (c) and (d) of Fig. . The entire sensor housing is painted with reflective white paint, and tubes are wrapped with aluminum foil tape. This results in excellent rejection of solar heating and avoids unpredictable radiation heating bias. Such placement of sensors provides solar shielding and shielding from other artificial heat sources such as motor or battery waste heat. Since the entire housing is placed outside the body of the UAS, it creates further isolation from the artificial heat sources in the UAS. Additionally, since the aspirating airspeed is very high , it reduces the error from all these sources even further .

The housing is also designed to be modular, printed entirely using a 3D printer, and has an easy screw-in assembly. The impact of the housing on the UAS's stability and flight time is minimal. Further details and the full schematic of the housing and the evaluation can be found in our previous work .

Data were collected using a data acquisition (DAQ) system comprised of an Odroid-XU4 , a compact single-board computer that runs a Linux operating system. Odroid runs the robot operating system (ROS)  that communicates with the serial devices through its USB ports. The ROS facilitates the collection of many different sensor data independently at their own output frequency, recording the timestamp for when data were generated and when they are received by the ROS. The ROS interfaces the collection of all available devices even in the case of a single device failure. Synchronization of the data can be done either at runtime or in post-processing. In our case, it was done in post-processing using MATLAB.

The communication with the DJI flight controller was implemented using the ROS interface of DJI Onboard SDK  available to developers. This allowed the recording of all the telemetry data from the flight controller, along with high-quality positioning information. The GPS data from the iMet XQ2 and iMet XQ1 sensors were discarded as the positioning information from the flight controller was found to be of better quality.

The Odroid was connected with a ground computer using wireless 2.4 GHz XBee radios for the operation of DAQ, debugging, and periodic checks on the data when the UAS finished a flight. The data collected by the DAQ were retrieved to the ground computer for archiving at the end of each day using an ethernet connection.

Temperature and humidity sensors were connected over serial with the ROS to send periodic updates of the observations. The UAS's autopilot also interfaced with ROS to provide updates of position, velocity, altitude, attitude, etc., which were also recorded to spatially and temporally synchronize the observation.

As mentioned in Sect. , the primary sensor was the iMet XQ2, and its data were recorded in the dataset with a header underscore _1 (e.g., Temperature_1, Humidity_1, Pressure_1). Other sensor data headers were followed with _2 and _3 when available. Sensor_1 and sensor_2 were shielded inside the sensor housing; however, sensor_3 was placed under the UAS in a traditional configuration without aspiration. The placement of the sensors inside the housing and sensors without the housing are marked in Fig.  for reference. Specific placements of the sensors on the UAS used in the data collection are described below.

During the LAPSE-RATE field campaign, measurement objectives for each day were determined based on the weather forecast, site availability, and available team resources. Many designated locations of San Luis Valley of Colorado, USA, were planned beforehand as atmospheric sampling sites depending on atmospheric phenomena of interest. The planning of locations, atmospheric phenomenon to be observed for the day, and assignment of teams are described in . We conducted flights in locations designated as Golf, Gamma, Leach, India, and Charlie between 14–19 July as part of the LAPSE-RATE flight campaign  as well as individual research objectives. GPS coordinates of these locations are provided in Table  and illustrated in a terrain map in Fig. . Inset (b) of Fig.  shows the flight locations of UNL UASs in the context of all the LAPSE-RATE flight campaign locations of interest where all the teams were operating based on the measurement objective of the day.

Flight strategies for each day were dictated by atmospheric phenomena being measured. The teams participating in the LAPSE-RATE campaign coordinated flights across the San Luis Valley according to the atmospheric phenomena of interest for the day and the atmospheric variability expected at different sampling locations. Measurement objectives of LAPSE-RATE in which the UNL participated in data collection are calibration flight (CLF), boundary layer transition (BLT), convection initiation (CI), cold air drainage flow (CDF). Table  shows the locations of UASs deployed by the UNL by date, time, and the corresponding mission objectives.

All the flights were conducted under the command of one remote pilot in command (PIC) with a “Federal Aviation Administration (FAA) part 107” license in accordance with the FAA's rule. All the flights included in the dataset were conducted using preprogrammed missions in the DJI Ground Station (GS) Pro app  by the remote PIC, with very few exceptions of manual flights. Occasionally the remote PIC took control over segments of flights from the automatic mission control of the app when deemed safer by the PIC, e.g., when passing through a turbulent layer of atmosphere. Although visual observers (VOs) were not required by the FAA, two VOs were present at each flight location for greater situational awareness and safety during each flight. VOs were monitoring the UAS's movement, took handwritten notes about flight events and weather, and scanned the surrounding area for manned and unmanned flights.

All the flights were legally conducted under an FAA Certificate of Authorization (COA) for altitudes up to 914.4m a.g.l. when Notices to Airmen (NOTAMs) were active in the blue area marked in inset (a) of Fig. . For all our flights, however, we were limited to flying up to a 500m maximum altitude due to the altitude limitation set in the firmware of the UAS. On the days when NOTAMs were not active for the COA, all the flights were conducted up to the legal flight limit of 121m a.g.l. as defined in the “part 107” regulations.

Data from 14 July 2018 can be used with MURC data available at the Zenodo data repository  to obtain a calibration. Correction of bias in sensor readings during post-processing requires calibration against a known reliable measurement. It also serves as additional validation for the sensor platforms and their collected data. It also facilitates the comparison of data collected by different platforms by providing a “ground truth” to compare against. Our previous paper  discusses the deviation of our observations with MURC data over a period of 10 min. Other work  compares all the different platforms participating in the LAPSE-RATE campaign along with ours against MURC tower data.

Ten flights from the M600P1 platform on 18 July 2020 starting at 20:21 UTC (local time 14:21 MDT) can be used to study the effect of ascent and descent speed on the sensor readings. Flights were conducted up to 150m altitude, with speeds ranging from 1–5 ms-1 ascent speed and 1–3 ms-1 descent speed. While it is desirable to move at a faster speed to optimize battery power usage to profile at greater altitudes, it may contribute to the effective sensor response time. Characterizing the sensor response at the different ascent and descent speeds would allow for the corresponding correction in the post-processing of the data. Our analysis of these data can also be found in our paper .

The first six flights from each platform can be used from 17 July 2020 to study the sensor performance within an inversion layer. The speed of flight through the inversion layer ranged from 0.5–5 ms-1 for ascent and 0.5–3 ms-1 for descent. The flights were coordinated with radiosonde launches from the National Severe Storms Laboratory (NSSL) to compare the UAS profiles against the radiosonde profiles. The University of Nebraska-Lincoln (UNL) Mobile Mesonet was also collecting data at the ground for surface-level observations. The dataset for radiosonde observations by the NSSL  and surface observations by the UNL Mobile Mesonet  is uploaded to Zenodo for intercomparison. The ability to detect the inversion at the correct altitude by the UAS sensor proves that the UAS is collecting the observations at the sensor level rather than from the upwash or downwash of the UAS. Additionally, detection of inversion provides confidence in the quality of the data from the sensor housing in both ascent and descent. Different ascent and descent speeds are used to identify the maximum speed that can be used while still acquiring quality data. Characterization of the sensor in the inversion layer provides a means for correction of observation level in case an offset is detected in the inversion layer when compared to a radiosonde. These data could also be used for comparison to the theoretical work for ascent and descent rate of sensing platforms .

Data are available to study sensor performance during horizontal transect with different orientations relative to the wind. The last three flights from each platform on 17 July 2020 can be used for this purpose. Horizontal flight speed ranged from 2–10 ms-1. These data can also be compared with radiosonde profile  and surface observations  similar to Sect. . The horizontal flights at different speeds against various orientations of wind provide additional characterizations for the quality of sensor data at various atmospheric wind conditions. Different horizontal flight speed simulates different incident wind speed at the sensor housing inlet and its effect on the observations. At the same time, the orientation of the sensor housing simulates incident wind at different orientations and its effects on the sensor observations. The orientation characterization is particularly important as waste heat from the UAS can be carried into the sensor housing in an unfavorable wind orientation. Any bias that may appear in these tests would need to be considered in the profiling flight plan to optimize the orientation of the sensor housing inlet relative to the wind to collect quality data and make appropriate corrections in the post-processing. Our analysis of these data can also be found in our previous work . Although traditionally a multirotor UAS is used for vertical profiling, our data show reliable data collection is also possible for horizontal profiles and transects using our sensor housing.