A Compact Rayleigh Autonomous Lidar (CORAL) for the middle atmosphere

. The Compact Rayleigh Autonomous Lidar (CORAL) is the ﬁrst fully autonomous middle atmosphere lidar system to provide density and temperature proﬁles from 15 km to approximately 90 km altitude. From October 2019 to October 2020 CORAL acquired temperature proﬁles on 243 out of the 365 nights (66 %) above Rio Grande, southern Argentina, a cadence which is 3-8 times larger as compared to conventional human operated lidars. The result is an unprecedented data set with measurements on two out of three nights on average and high temporal (20 min ) and vertical (900 m ) resolution. 5 First studies using CORAL data show for example the evolution of a strong atmospheric gravity wave event and its impact on the stratospheric circulation. We describe the instrument and its novel software which enables automatic and unattended observations over periods of more than a year. A frequency-doubled diode-pumped pulsed Nd:YAG laser is used as light source and backscattered photons are detected using three elastic channels (532 nm wavelength) and one Raman channel (608 nm wavelength). Automatic tracking of the laser beam is realized by implementation of the conical scan (conscan) method. The 10 CORAL software detects blue sky conditions and makes the decision to start the instrument based on local meteorological measurements, detection of stars in all-sky images, and analysis of ECMWF weather forecasts. After the instrument is up and running, the strength of the lidar return signal is used as additional information to assess sky conditions. Safety features in the software allow operation of the lidar even in marginal weather which is a prerequisite to achieving the very high observation cadence.

week when trained operators were available. The intermittent operation not only severely limited the amount of data, but also 25 made statistical studies such as the evolution of atmospheric gravity wave events (e.g. Kaifler et al., 2020) next to impossible.
In recent years a number of autonomous tropospheric lidar systems have been developed to address the shortcomings of the earlier manually operated instruments and increase the data output (Goldsmith et al., 1998;Reichardt et al., 2012;Strawbridge, 2013;Engelmann et al., 2016;Strawbridge et al., 2018). But until today, to the knowledge of the authors, no attempts were made to build autonomous middle atmosphere lidars. There may have been several factors contributing to the stalled development. 30 First, lidars capable of sounding the mesosphere require a much higher sensitivity given the exponential decrease in air density with altitude. Consequently, mesospheric lidars use powerful lasers, large aperture receiving telescopes and highly efficient receivers, which makes some of the solutions generally used in the development of autonomous tropospheric lidars impractical, as for instance a window covering the telescope to protect it from the environment. Second, because of the technical challenges and lower interest in the middle atmosphere as compared to the troposphere, there are only a few groups operating middle 35 atmosphere lidar instruments.
The primary objective of CORAL is the demonstration of a fully autonomous lidar system which can be used for studying atmosphere dynamics in the stratosphere and mesosphere. That the instrument should be capable of fully automatic observations was not seen as a practical feature, but rather as pure necessity resulting from lack of manpower to operate the instrument.
For the same reason, the instrument should require only a bare minimum of maintenance work. In other words, the instrument 40 should happily sit by itself, monitor itself, and collect atmospheric measurements whenever weather conditions allow optical soundings. Human interaction should be limited to approximately weekly downloads of scientific data and yearly maintenance.
Moreover, CORAL should be transportable, fully independent of infrastructure expect for electrical power, robust enough to withstand environmental conditions from the tropics to the Arctic and Antarctic, easy to replicate, and in relative terms low cost. In short, we wanted to develop a lidar system which can be set up at some remote location and left there for years collect-45 ing atmospheric data, much like ceilometers are used today by the weather services. If such a system was possible, it would surely mark the transition from the conventional, laboratory style and labor-intensive lidar systems commonly in use today and run by lidar experts, to a new generation of operational lidar systems which can be run by experts and non-experts alike. There are several benefits expected from such a new generation of lidars: 1. As the cost of lidar operators contribute significantly to the operating costs of conventional lidars, the use of autonomous 50 systems will bring the cost per operating hour down. Lower costs will enable a more widespread use of lidar systems for atmospheric research and climate monitoring.
2. Not having to rely on human operators to acquire soundings facilitates the collection of large and continuous data sets, thus offering new possibilities for statistical analysis of the temperature structure on timescales from years to minutes. Higher resolutions possible for reduced altitude ranges Table 1. A summary of the lidar technical specifications.
well trained in software design and software development. As we will show later, it takes considerable efforts and time to develop and test the software required for autonomous lidar operation. In case of CORAL, the hardware of the instrument is 60 rather unexceptional, and it is indeed the software which contains most of the complexity of the system. The purpose of this paper is threefold. First, we want to demonstrate the functionality of an autonomous operated middle atmosphere lidar. Second, given the advances in computer power and software development tools, this paper shall demonstrate that building of an autonomous lidar instrument is not overly complicated. And third, as we will argue in the discussion (section 5), the large and continuous data sets produced by autonomous instruments facilitates advances in science that are 65 hardly possible with conventional human operated lidar instruments. Following this agenda, we describe the lidar instrument in section 2 followed by the description of the software used for autonomous lidar operation in section 3. In section 4 we briefly discuss our implementation of the temperature retrieval.

The lidar instrument
Development of CORAL started in 2014 as a copy of DLR's first mobile middle atmosphere lidar system TELMA (temperature 70 lidar for middle atmosphere reserach), which was employed with much success during the DEEPWAVE field campaign in New Zealand (Fritts et al., 2016;Kaifler et al., 2015a;Ehard et al., 2017;Taylor et al., 2019;Fritts et al., 2019). CORAL measures atmospheric density in the altitude range 15-95 km and thus covers most of the stratosphere and mesosphere. The system uses a pulsed laser with 532 nm wavelength as light source and a receiver equipped with several channels for detecting both elastic scattering and inelastic scattering at 608 nm wavelength. Atmospheric temperature is retrieved by hydrostatic integration of 75 the measured density profiles (Hauchecorne and Chanin, 1980). The lidar instrument is integrated into an 8 steel container (see Fig. 1), which serves both as transport container and enclosure during lidar operation. The container is divided into two compartments: an air-conditioned room accommodates the transmitter, receiver and data acquisition systems, while the telescope is located in a separate room with a large hatch in the roof for direct access to the sky. The technical specifications of the lidar instrument are summarized in Table 1.   https://doi.org/10.5194/amt-2020-418 Preprint. Discussion started: 26 October 2020 c Author(s) 2020. CC BY 4.0 License. Figure 2 shows the schematics of the optical paths inside the lidar instrument. The laser (Spitlight DPSS 250-100 from Innolas GmbH) is a diode-pumped Nd:YAG master oscillator power amplifier system operating at 1064 nm wavelength and 100 Hz pulse repetition frequency. It delivers 120 mJ per pulse after conversion to the second harmonic at 532 nm wavelength. The remaining infrared light is separated and subsequently dumped using a dichroic mirror and water-cooled beam dump. A folding 85 mirror mounted on a fast tip/tilt piezo actuator with 7 mrad angular range directs the green beam towards a 2x beam expander, which reduces the beam divergence to approximately 170 µrad. Finally, the beam exits the laser box through an anti-reflection coated window. A motorized mirror located in the telescope compartment of the container directs the laser beam into the sky at a position that is approximately 0.4 m offset from the optical axis of the receiving telescope.

90
The backscattered light is collected using a 63.5 cm diameter parabolic f/2.4 mirror with a spot size of ∼70 µm. An optical fiber (type FG550LEC; 550 µm core diameter, 0.22 NA) mounted in the focal plane guides the collected light to the receiver.
The fiber mount consists of a spring-loaded piston traveling inside a fixed tube with the piston pushing against a linear motor (Thorlabs Z812). With the help of the motor, the position of the fiber end can be adjusted in z-direction with ∼2 µm resolution, thus facilitating easy adjustment of the telescope focus. The outer tube is held by a three-legged spider mounted on an aluminum 95 ring with a diameter slightly larger than the mirror. The ring is supported by 6 vertical carbon fiber tubes that connect it to the base plate holding the telescope mirror, and the whole telescope assembly sits on adjustment screws that allow the telescope to be pointed to zenith.
The optical bench of the receiver resides in a four-units 19-inch rack mount enclose. The optical fiber enters the enclosure at back side and terminates in front of a mechanical chopper with three slits rotating at 100 revolutions per second. The firing 100 time of the laser is synchronized with the rotation of the chopper such that laser light scattered in the lower 14 km of the atmosphere is blocked by the chopper blades and does not hit the sensitive detectors. As shown in Fig. 2, after passing through the collimation optics, the collimated beam is spectrally divided into two parts by a dichroic mirror, separating the elastic scattering at 532 nm wavelength and the nitrogen rotational Raman scattering at ∼608 nm wavelength. The Raman scattering is detected using a photo multiplier (Hamamatsu H7421; approximately 35 % detection efficiency at 600 nm) with a 3 nm 105 wide interference (80 % peak transmission) mounted in front. In order to increase the dynamic range of the detection, the beam containing the elastic scattering is further split into three beams with a splitting ratio of approximately 92.0:7.4:0.6, i.e. the detector of the far channel sees 92 % of the light, while only 0.6 % of the light reaches the low channel. Both the high and mid channel detectors are avalanche photo diodes (APDs) operated in Geiger mode (SPCM-AQRH-16 from Excelitas; ∼50 % detection efficiency at 532 nm wavelength) with 0.8 nm wide interference filters (83 % peak transmission) mounted in 110 front. The APDs are gated to limit peak count rates to about 5 MHz. The low channel detector is again a photo multiplier tube (Hamamatsu H12386-210) with a 3 nm wide cost-efficient interference filter (60 % peak transmission).

Data acquisition and control
The data acquisition system comprises three units, the acquisition computer, the control electronics, and the MCS6A photon counter. The MCS6A produced by FAST Comtec GmbH is a five-channel multi-event digitizer with 800 ps resolution. It 115 converts the electrical pulses coming from the detectors to timestamps indicating the elapsed time since the firing of the laser.
The data acquisition software running on the computer reads out the MCS6A after each laser pulse and stores the timestamps on solid state drives for post-processing as well as sorts them into histograms for displaying the photon count profiles in real-time.
Trigger signals for the laser, chopper and APD gating are produced by the control electronics. Its core is a National Instruments SBRIO-9633 embedded single-board computer with with a field-programmable gate array (FPGA). The trigger chain 120 of the lidar is implemented in the FPGA and programmable delays in the outputs allow for adjusting the timing between the signals, for example setting the phase and thus the opening altitude of the chopper and controlling the gating of the APDs.
Analog outputs of the SBRIO drive the tip/tilt piezo mirror inside the laser through high voltage amplifiers also located in the electronics box. Prior to outputting the analog signals, the drive signals for the piezo mirror are conditioned and limited in bandwidth by digital filters implemented in the FPGA to prevent the mirror from overshooting the target position and excitation 125 of resonant modes. Finally, the electronics box also houses the power supplies for the detectors and relays that are controlled by the FPGA for switching the detectors on and off.

Automatic tracking of the laser beam
One problem with container-based lidar systems is the limited thermal stability. When the telescope hatch opens and the telescope compartment cools down, thermal drifts result in misalignment between the telescope boresight and the laser beam.

130
This drift is especially problematic for lidar systems which use narrow field of views in the order of few hundred microradian for low background noise, and active tracking of the laser beam position is usually required. We adapted the conscan method that is widely used for tracking spacecraft (see e.g. Gawronski and Craparo, 2002). To our knowledge, this is the first application of conscan to mesospheric lidars.
The basic principle of conscan is depicted in Fig. 3. A scan mirror rotates about the axes x and y in a sinusoidal motion, 135 causing the laser beam to rotate around the telescope boresight in a conical scan (see Fig. 4). If the center of the cone is offset from the boresight of the telescope, the angle between the laser beam and the telescope boresight Θ periodically becomes smaller and larger due to the conical motion of the laser beam. Assuming the offset of the cone is sufficiently large, the modulation of Θ leads to an incomplete overlap between the telescope field of view (FOV) and the laser beam. This in turn causes a modulation in the signal strength of the lidar return signal, which can be demodulated and the information used to 140 infer the direction the axis of the cone needs to be shifted to in order to obtain a complete overlap. An example of such a demodulated signal is shown in Fig. 5. Looking at the geometry depicted in Fig. 6, it becomes clear that maximum overlap is achieved if vector r points in the same direction as vector s. The corresponding direction in the coordinate system of the scan  Figure 6. Postion of the laser beam and telescope boresight during a conscan (adapted from Gawronski and Craparo, 2002). mirror is given by the vector where ϑ s denotes the phase angle with the largest demodulated lidar return signal.
Equation 1 tells us in which direction we have to move the laser beam in order to achieve complete overlap, but we don't know how far along e s we have to go in order to reach the point defined by s. Based on the data at hand, there is no way to determine the scaling factor l in the relation s = le s , but we can estimate l from the amplitude of the conscan signal. For simplicity, we initially assume a perfect lidar producing noise-free measurements. Let's consider the situation where the mean 150 Θ equals half of the telescope FOV and the amplitude of the modulation signal driving the conscan, |r|, is so large that the lidar return signal oscillates between zero (no overlap) and a maximum (complete overlap) and the demodulated conscan signal, in the following denoted as A, shows oscillations between zero and one. This can be achieved only if |r| also equals half of the telescope FOV. When the modulation amplitude or mean Θ are smaller, the minimum lidar return signal must be larger than zero as there is always a partial overlap. In this case A contains a nonzero offset c and the amplitude of the sinusoidal part a is 155 smaller than one, and we can rewrite A as On the other hand, for the other extreme case where the conscan modulation and mean Θ are so small that the laser beam is always completely inside the telescope FOV, we expect no variation in A and hence α = 0. Thus, the amplitude a can be used as an estimate of the overlap. For simplicity, in the following we assume a linear relationship and approximate s as The factor 10 in the first case facilitates faster convergence when the overlap is almost complete (a is small). We note that a more accurate relation can be derived from calculation of the geometric overlap function based on the actual beam profile of the laser, but the approximation in Eq. (3) is sufficient for our purposes. After a conscan is completed, the orientation of the  Figure 5 shows such the averaged conscan signal that was acquired on 3 November 2019 05:15 UTC in the altitude range 45-55 km using the far channel detector. The demodulated signal contains a significant noise portion, but a sinusoidal modulation with a maximum at about 75 • is nevertheless evident. In order to get a better estimate of the amplitude and phase of the maximum, we perform a sinusoidal fit using the MPFIT algorithm (Markwardt, 2009).
For the example shown in Fig. 5 we obtained values a = 0.0105 and ϑ s = 71.5 • , which according to Eq. (3) cause a shift of 175 3.5 µrad towards the telescope boresight when the conscan algorithm is executed. Figure 7 shows mean angles of the scan mirror for a 4-hour long lidar measurement. After startup of the instrument, warming-up of the laser and cooling-down of the telescope compartment of the container caused a drift of about 300 µrad (distance in both axes) during the first hour. That is significant compared to the telescope FOV of 370 µrad and would lead to dramatic losses in the lidar return signal if no beam tracking were used. However, as shown in Fig. 7, with beam tracking enabled the lidar return signal remained fairly stable 180 throughout the lidar measurement. Note that while the lidar return signal was impacted by broken clouds during the first hour, yet conscan allowed robust beam tracking as indicated by the peaks in the lidar return signal reaching values of ∼ 8 × 10 4 which is approximately the same value as later when the clouds disappeared.

Adaptive detector gating
As one of the goals of CORAL is to obtain measurements as often as possible, it was clear from the very beginning that 185 CORAL would also operate in marginal weather e.g haze and variable cloud cover. Although these conditions diminish the lidar return signal, being a Rayleigh lidar, CORAL has still enough power margin to produce scientifically usable measurements in the stratosphere and lower mesosphere. However, the weaker signal requires that gating of the APDs and the opening of the chopper have to be adjusted to lower altitudes to make use of the full dynamic range of the detectors and allow for assembly of the individually retrieved temperature profiles into a single continuous profile (see Fig. 8).

190
Our implementation of adaptive controls for detector gating is rather simple. The data acquisition software integrates photon counts for two-second intervals and calculates peak count rates for each detector channel. If the peak count rate is outside a predefined dead band, the delay of the gating signal for the respective channel is increased by 3 µs if the count rate is high, or decreased by 3 µs if the count rate is low. The change is equivalent to an increase or decrease of the gating altitude in steps of 450 m. We use different dead bands mid channel, and low channel, respectively. Lowest peak count rates are reserved for the far channel in order to limit thermal heating of the APD and thus reduce nonlinear effects that may strongly affect retrieved temperatures at upper mesospheric altitudes where the lidar return signal is low. Nonlinear effects at low count rates are of less importance in case of the other channels because, at the top of the profiles, there is sufficient overlap with temperature profiles retrieved from other channels.

200
The CORAL container provides all the necessary infrastructure for the operation of the CORAL lidar instrument. It has two large doors, one in the front providing access to the air-conditioned compartment and one in the back for servicing the telescope (see Fig. 9). Two smaller hatches equipped with actuators serve as inlet and outlet for the air needed by the chiller. A third motorized hatch of size 0.8 m by 0.8 m is located above the telescope (see also The layout of the interior is sketched in Fig. 9b. The larger of the two compartments is insulated and air-conditioned to 210 22±2 • C, whereas the smaller telescope compartment is only equipped with low-power electrical heaters to raise its temperature slightly above the ambient temperature in order to reduce the humidity when the lidar is not in operation and the telescope hatch closed. The chiller, which is mounted below the ceiling, provides cold glycol with a cooling capacity of 2.4 kW and is used for booth secondary cooling of the laser and air conditioning. All of the lidar hardware with exception of the telescope is installed in the laser rack below the chiller. The space between the two boxes marked with "D" in Fig. 9b is normally kept empty and 215 can be used by a person for servicing the lidar or manual on-site control of the lidar.

Control
Control of the container systems such as heatings, hatch actuators, fans and chiller, is exercised by two ATMEGA644  In addition to the multiplexing and demultiplexing functionality, the software running on the MDMs also includes a basic 230 set of fault protection routines (FPRs). The sole purpose of these FPRs is to guarantee that the CORAL system is always in a consistent and safe state. There are FPRs dealing with technical faults as well as, in the view of CORAL, dangerous environmental conditions. For example, an FPR prevents opening of the telescope hatch if the wind speed as measured by the weather station exceeds a certain threshold, and another FPR is responsible for shutting down the laser and closing of the telescope hatch when precipitation is detected. The implementation of the most critical FPRs at the MDM-level represents a 235 safeguard against adverse effects of software errors. Because the software running on the MDMs is less than 3000 lines in total and does not rely on an intercalated operating system, the probability of a software error causing a fatal crash or deadlock is much lower than it is the case for the application software running on COCON with its hundreds of thousands of lines. In that we cannot guarantee that the high-level application software is free of errors, we have to assume that it fails at some point, and hence, with no operator in the loop to intervene, the MDMs must be capable of their own to maintain the safety and a 240 consistent state of the CORAL system to prevent fatal outcomes such as leaving the hatch open in a rain shower. Following this requirement, most FPRs trigger a routine called "safe-mode" which shuts down the lidar, disables the chiller, closes hatches and reconfigures the heating and ventilation system. It is then up to the application software running on COCON to recover from the fault that caused safe-mode. Following the the example with high wind speed, the application software monitors data coming from the weather station and, after the wind has sufficiently abated, restarts the lidar operation. The three key ingredients that make autonomous lidar operation possible are (i) the ability to control every aspect of the lidar instrument and container subsystems by means of a computer program, (ii) the availability of robust data based on which the decision can be made whether lidar operation is currently feasible, and (iii) the implementation of this decision-making logic.
The first is a pure technical aspect which we realized by implementing a message-based data exchange system on top of a client-server architecture. The functionality of each subsystem such as lidar data acquisition, laser, and autocontrol-this 260 part contains the decision-making logic-is implemented in separate computer programs that communicate via the message system. For example, autocontrol inquires the data acquisition about the strength of the lidar return signal, and the data acquisition reports the numbers back to autocontrol by replying to that message. In another example the autotrack program, which tracks the laser beam, requests photon count data from the data acquisition, processes the data, and sends a message to the lidar electronics to update the beam pointing. Short messages that may contain only few parameters or data values are implemented 265 using the Standard Commands for Programmable Instruments (SCPI) protocol SCPI, while larger data sets are sent as binary blobs preceded by a unique identifier. SCPI is a human readable protocol. For example, the command laser:shutter 1 prompts the laser to open its shutter. All aspects of the lidar system can be controlled without the need for a graphical user interface by typing SCPI commands in a terminal. This simplified testing and debugging of the software a lot given that in total >1000 commands are currently implemented in the lidar software, the majority representing configuration parameters. SCPI commands 270 also can be collected in text files that are loaded and sent automatically at startup of a program.

Data sources and decision making
The decision-making process behind the autonomous capability of CORAL is implemented in a program called autocontrol.
Autocontrol is a rule-based system that seeks answers to questions such as: is it cloudy? Is the cloud layer solid (no lidar observations possible) or broken clouds (lidar observation possible, but signal degraded)? What is the probability for rain 275 within the next hour? The individual answers are then combined in logical connections to arrive at the yes/no decision to start or stop the lidar.
In order for autocontrol to find answers, we have to feed it with data. The current implementation uses five main data sources: the solar elevation angle, the local weather station, the cloud monitoring camera, European Center for Medium-Range Weather  Because CORAL can operate in darkness only, we use the elevation angle to restrict operation times to periods when the solar elevation is below -7 • . The weather station is used for monitoring precipitation and wind speed. A rain signal or the wind speed exceeding a threshold prevents the automatic start of the lidar or, in case the lidar is already running, triggers an immediate shutdown. The cloud monitoring camera is a 1.3 mega pixel monochrome CCD camera (Basler acA1300-30gm) combined with 285 a 1.4 mm f/1.4 fishy eye lens (Fujinon FE185C046HA-1). We use a blob finding algorithm to detect stars in long exposures, and stars are counted within a region extending from zenith to 50 • off-zenith. The star count is used by autocontrol to assess whether the sky is clear (large number of detected stars) or cloudy (low number of detected stars). An example image along with a map containing positions of detected stars is shown in Fig. 10.
Relying solely on star images to discern clear sky has the disadvantage that this information is only available when the sky 290 is sufficiently dark for stars to be seen (solar elevation angle <-11 • ). However, in order to facilitate early starts of the lidar and thus maximize the run time, we need information on sky condition already at twilight. This information is retrieved from ECMWF forecast data in the form of the parameters total cloud cover and total precipitation for the grid point nearest to the location of CORAL. Lidar start is allowed if the cloud fraction is below 0.5 and accumulated precipitation within the next 2 h is below 0.1 mm.

295
After the lidar is up and running, the strength of the lidar return signal is used as additional information for the assessment of clouds. If the signal strength is greater than 70 % of the expected maximum signal, the sky is classified as clear and lidar operation is allowed to continue even in case of ECMWF forecasting precipitation. The reasoning behind this rule is that the predicted occurrence of rain showers is often off by more than one hour and the effect of rain showers can be very localized in the surroundings and not necessarily at the precise location of CORAL. By allowing the lidar to continue observations when 300 the signal is good prevents unnecessary shutdowns. The idea here is that precipitation is preceded by a cloud layer that can be indirectly detected by the lidar as drop in the lidar return signal strength. Following that, the lidar is stopped in case the signal drops below 70 % and ECMWF forecasts >0.1 mm of precipitation. But even if no precipitation is forecasted, the clouds may thicken enough that continuing the lidar operation is not worthwhile anymore because of the low lidar signal. For this case we implemented a 15-min count down timer that is started when the lidar signal drops below 20 %, and the lidar is stopped when 305 the counter reaches zero. In order to let the lidar continue its observations in broken clouds, the counter is reset to 15 min every time the signal increases beyond the 20 % threshold. A final rule introduces a mandatory a wait period of 30 min following a shutdown triggered by low signal. This rule was implemented after we discovered that light scattered off dust particles on Figure 11. (a-f) Example data used by autocontrol to make start/stop decisions and (g) retrieved temperature profiles. Red areas mark periods with violated conditions and beige areas indicate actual instrument run times.
. the optical dome covering the all-sky camera is sometimes misinterpreted as stars. In some cases, the high number of artificial stars lead to a constant startup-shutdown cycle even though the sky was overcast and no meaningful lidar observations could be 310 obtained. The implementation of the wait period reduces the number of start-attempts to a level that does not cause excessive wear.
The current state of the lidar is tracked in a global state machine where violations of the rules described above trigger state changes. Rules are evaluated once per second, though data tables may be updated at different intervals depending on the data source and how often new data become available.  Figure 11 shows the data used by autocontrol to make start/stop decisions on the night of 23-24 August 2020. The ECMWF cloud fraction (Fig. 11b) is below 0.4 during the whole night, indicating to autocontrol that no significant cloudy periods are to be expected. Start-up of the lidar is blocked until the solar elevation angle (Fig. 11a) . 11c), the measured wind speed is below the threshold of 110 (equivalent to approximately 15 m s −1 ), and the rain sensor does not detect any rain. No conditions are violated and autocontrol initates the starting sequence of the instrument. Data collection begins approximately 5 min later with photon count rates averaged between 50 km and 60 km altitude reaching about 340 kHz (Fig. 11f). At 23:08 UTC a fault protection routine within autocontrol detects the crash of the experimental data acquisition software we were testing at that time, and triggered a shutdown of the instrument. The crash is evident in the 325 photon count rate being constant, indicating that a key metric of the data acquisition software is not updated any more. At the same time, the ECMWF precipitation forecast exceeds the threshold of 0.1 mm and thus prevents autocontrol from restarting the instrument until two hours later, though the sky remains mostly cloudless as indicated by the high number of detected stars (Fig. 11e). Finally, at 02:15 UT, a simultaneous decrease in photon count rate and number of detected stars suggest the appearance of clouds. Lidar measurements continue until about 30 min later when the wind speed crosses briefly the threshold 330 and autocontrol triggers another shutdown of the instrument. The number of detected stars remains zero while a short rain event is detected at 03:20 UTC. Although the star count increases shortly after, the start-up of the lidar is blocked by the 30 min wait period following a shutdown. This is a safety mechanism as it is not clear whether the nonzero star count is due to real stars being detected (cloudless sky) or due to light scattered off rain droplets on the camera dome. Half an hour later, the star count goes to zero, indicating clouds. When the star count increases again at about 04:00 UTC, autocontrol initiates the start-up of the 335 instrument. Data collection continues until four hours later when the photon count rate and the star count reach low values. At 09:00 UTC the sky clears off again and autocontrol restarts the lidar, which then runs until the solar elevation angle increases beyond -7 • .

Example
The example shown in Fig. 11 is representative of an observation that would have kept a human operator busy throughout the night. Instead, the CORAL instrument took all decisions on its own and even recovered from a software crash without 340 human intervention. About 2 h of data were lost due to the crash, as high photon count rates normally take precedence over the ECMWF precipitation forecast and, in this case, would have allowed the observation to continue.

Temperature retrieval
Our implementation of the temperature retrieval is based on the integration method developed by Hauchecorne and Chanin (1980). The basic preparatory steps are: binning of the photon count data to a 100 m vertical grid and a desired temporal res-345 olution, correction of detector dead-time effects, subtraction of the background which is estimated from photon count profiles between 130 km and 200 km altitude, correction of the two-way Rayleigh extinction, range-correction by multiplication with the range squared, and vertical smoothing to 900 m effective vertical resolution to improve the signal-to-noise ratio (SNR).
After performing these steps, in the absence of aerosols, the resulting profiles are proportional to atmospheric density. Assuming that the atmosphere is in hydrostatic equilibrium, these density profiles can be integrated from top to bottom to retrieve 350 atmospheric temperature using the ideal gas law and a start or "seed" value at the top of the profiles. This process is repeated independently for each detector channel. The question is now, where do we get the seed value from? We start off with the nightly mean profile of the far-channel which we seed with an approximately co-located SABER (Sounding of the Atmosphere with an upper channel, we can then seed the retrieval of the mid-channel temperature profile with a temperature value from the far-channel. In a similar way, both the low-channel and Raman-channel are seeded with a value taken from the mid-channel temperature profile. The altitude where the integration starts and the seed value is taken is determined by the SNR N * / √ N where N is the number of detected photons per 100 m bin and N * the desired signal (background subtracted). We define the seed altitude as the maximum altitude with SNR > 4 (far-channel) and SNR > 15 (all other channels). The individual temper-360 ature profiles are then merged into a single continuous profile. In order to guarantee a smooth transition from one profile to another, we compute a weighted average in the overlapping region using the weighting function w (z) = cos (π (z − z 0 ) /∆z) within the transition region starting at altitude z 0 and vertical extent ∆z. The bottom of the upper of the two profiles is typically chosen as z 0 and ∆z = 2 km. Figure 8 shows an example of individually retrieved temperature profiles and overlapping regions. Note the large discrepancy between the Raman temperature profile (channel 4) and the elastic temperature profile 365 (channel 3) at about 20 km altitude, which is caused by stratospheric aerosols. We mitigate the impact of stratospheric aerosols by transitioning to Raman temperatures below 32 km altitude when merging profiles.
In order to achieve higher temporal resolutions, we implemented the iterative approach sketched in Fig. 12a. After retrieving the nightly mean profile seeded with SABER or MLS data, we bin the photon count data to overlapping 120 min wide bins, which are offset by 30 min. Temperature profiles are then retrieved from these binned data using seed values taken from the 370 nightly mean profile. This works because the SNR of the 120 min binned photon count profiles is always lower (or equal) to the SNR of the nightly mean profile for the same altitude. The result of such a coarse temperature retrieval is shown in Fig.   12b. Having completed the 120 min retrieval, we bin the photon count data to 60 min resolution using 15 min offsets from one bin to the next bin and start the process over again. This time the seed values are taken from the 120 min temperature profiles. In the next iteration, the temporal resolution is increased to 30 min using seed values taken from the 60 min profiles.

375
Iteration by iteration, a pyramid with ever increasing resolution is built up until the desired resolution is reached and at which https://doi.org/10.5194/amt-2020-418 Preprint. Discussion started: 26 October 2020 c Author(s) 2020. CC BY 4.0 License. point the algorithm stops. In Fig. 12b,c we show an example to demonstrates the effect of increasing resolution on temperature profiles. Where the 120 min retrieval reveals only large-scale structures, in this case signatures of an internal gravity wave with a period of 5-7 h, the high-resolution retrieval (Fig. 12c) yields a multitude of fine details including smaller-scale waves.
The implementation of our retrieval also allows increasing the vertical resolution to e.g. 500 m and 300 m in regions where 380 the SNR is sufficient. A high vertical resolution is especially important for retrieving accurately the large vertical temperature gradients induced by large-amplitude waves that are on the verge of becoming convectively unstable. Due to the SNR required, generally, these very high-resolution retrievals are limited to altitudes of 30-70 km.
A common way for estimating the uncertainty of retrieved temperatures T (z) is computing the error propagation in the hydrostatic integration of the density profiles. Here, the assumed errors of the density profiles are the photon count uncertainties 385 N (z) scaled accordingly. In our implementation we use a different approach. Starting with the photon count profile N (z) and its uncertainty N (z), we perform a set of 200 Monte Carlo experiments for each profile. In these experiments, the number of detected photons per bin N is replaced with N + α √ N , with α being random numbers drawn from a Gaussian distribution with a standard deviation of one and zero mean. Then we apply the data reduction steps described above and run the retrieval separately for each of the 200 synthetic photon count profiles. In a last step, the final temperature profile is 390 computed as the mean of all 200 retrieved profiles and its uncertainty is given by the standard deviation.
The Monte Carlo method has the big advantage that all data reduction steps are included in the assessment of temperature uncertainties ∆T (z) in a completely natural way. That also applies to the initial seed temperatures taken from the SABER or MLS profile during the first iteration i.e. retrieval of the nightly mean profile. Of course, the seed temperature is also fraught with uncertainty due to true measurement errors, but also because the SABER or MLS measurements may have been acquired 395 up to 1500 km away from the location of CORAL. In order to include the impact of variations in seed temperature, we generate a set of seed profiles of the form T seed (z) + α∆T (z), one for each of the 200 synthetic photon count profiles, with α being again random numbers that are different for each z and have a standard deviation of one and zero mean. In case of the SABER or MLS profile ∆T (z) is assumed constant with a value of 20 K, whereas for subsequent iterations we use the uncertainty of the temperature profile retrieved in the previous iteration. This scheme ensures that the initialization error caused by the 400 SABER or MLS profile is passed on to all lidar temperature profiles, resulting in robust uncertainty estimates for retrieved profiles.

Discussion
The CORAL instrument is the first middle atmosphere lidar that is capable of operating fully autonomously for extended periods. By putting computer software in charge and not relying on human operators to start, monitor and stop the instrument,

405
CORAL is destined to acquire atmospheric profiles whenever weather conditions allow for optical soundings. This not only maximizes the data return, but also minimizes potential sampling biases. As demonstrated in Fig. 11, CORAL also operates in marginal weather and records data during short windows with gaps in the cloud layer, an opportunity normally not seized by conventional lidars because of the waste of time of the human operator. We believe that probing the atmosphere as often as possible is critical to capturing the true state of the atmosphere, in particular with regard to atmospheric gravity waves. There 410 is a longstanding and ongoing discussion as to whether lidars in general underestimate wave activity because, being optical instruments, lidars are typically run during stable weather and clear skies conditions. However, for example, it is reasonable to assume that strong forcing of mountain waves occurs in stormy weather conditions, which are often accompanied by clouds.
In contrast to conventional lidars, CORAL may operate under these conditions and thus capture strong wave responses not previously observed by other lidars. A study trying to quantify this potential "nice weather" bias is in preparation.

415
On the other hand, frequent observations-even if they are short-can reveal new insights in the evolution of gravity wave events and the question about their intermittency. Kaifler et al. (2020)  Forrest, Germany CORAL also was able to capture a rare mid-latitude Noctilucent Cloud event .
The above examples clearly demonstrate the scientific value of autonomous lidar systems. However, we also note that site 430 selection plays an important role in the data return of an instrument, as even the most powerful lidars can't operate if there is a constant thick cloud layer above. Based on our experience, sites in the lee of mountains are good places for setting up optical instrumentation. Figure 13 shows nightly mean profiles acquired by CORAL at Rio Grande, southern Argentina, in the lee of the southern Andes. Over the 12-month period CORAL conducted observations on 243 nights, which equals about two out of three nights or 66.4 %. To our knowledge, no other lidar instrument achieved a similar high cadence over such a long period. with CORAL observations (66 %) shows the extraordinariness of the CORAL data set.
From an operational point of view, after the completion of the testing phase, CORAL exceeded all expectations. The in-440 strument has been collecting data on a routine basis for the last 13 months without requiring any on-site service, and is still operating normally as of October 2020. That not only demonstrates the robustness of the system, but also proved to be very important for the continuation of the long-term observations given the ongoing travel restrictions due to the COVID-19 pandemic. The performance of the lidar is slowly degrading due to buildup of dust on the telescope mirror and laser turning mirror.
However, the lidar system has enough performance reserves to continue observations for another year before cleaning will be necessary. The other limiting factor is the lifetime of the deionization cartridge in the primary cooling loop of the laser, which normally lasts about one year. Accepting a higher risk of failure, based on our experience the laser can be operated with the same cartridge for up to two years. The addition of a conductivity meter for monitoring of the coolant is planned as part of a larger upgrade of the lidar instrument.
Most of the teething problems in the early days of CORAL were caused by or related to software problems. For example, 450 a race condition in the software of one of the two MDMs resulted in the telescope hatch not closing during an approaching rain shower, causing flooding of the telescope compartment. In another incident, a configuration error prevented the successful transfer of authority from one MDM to the other when the first MDM was disabled by a faulty power supply. As a result, environmental control was lost, and freezing of the primary cooling loop of the laser lead to permanent damage and made replacement necessary. These examples show that quality assurance in software development is of similar criticality for the 455 success of an instrument like CORAL as the design of the hardware. Whereas most of the hardware comprises off-the-shelf components, the software that empowers CORAL to make autonomous observations is unique. The same applies to the beam tracking system described in section 2.3.1, which to our knowledge is the first application of the conical scan method to middle atmosphere lidars. Again, the hardware is rather simple and straight forward to implement in lidars, and it is the software that represents a major advancement in technology.

460
Based on the above examples, we argue that, in the past, the software was an often overlooked and underappreciated aspect in the development of lidar technologies. That even may have been a natural consequence given that most lidars are built by physicists and engineers who usually are no trained software developers. In order to facilitate the development of new technologies including advances in hardware and software, we propose to include trained software developers in lidar teams.
Furthermore, we encourage the lidar community to share algorithms and software. Based on our experience with CORAL, it 465 takes considerable efforts and resources to develop software and test it. In our opinion it is a waste of resources if every group has to start from scratch developing more or less the same set of tools.
This work has described a new autonomous middle atmosphere temperature lidar that is capable of performing fully automatic observations over extended periods, potentially years. This capability represents a major advancement over conventional lidars 470 that are operated only during campaigns or during certain days per week. Not only does the automatic system result in significantly reduced operating costs as no personnel is needed to run the lidar, but the high cadence of the observations also enables new scientific studies. Thus, the CORAL system is a valuable tool to the scientific community and its success may prompt the development and installation of a whole new class of middle atmosphere lidars that can be used for a broad range of scientific studies e.g. atmospheric gravity wave research, climate monitoring, and satellite data validation. In order to facilitate scientific 475 progress and seed the development of CORAL-type lidars, we will make the CORAL software available to the community.
Code availability. The CORAL software is available to the community upon request. It may be placed in a public software repository in future.
Data availability. Quicklook plots and real-time status information are available on the instrument web site http://extern05.pa.op.dlr.de/coral.
Author contributions. BK designed the CORAL system and wrote the manuscript. NK and BK developed the CORAL software. NK con-
Competing interests. The authors declare that they have no conflict of interest.
Acknowledgements. The authors thank Christian Büdenbender (laser modification) and Philipp Roßi (