the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
| 12 Aug 2026
WaggleDop: Autonomous event characterization and adaptive scanning using Doppler LiDAR systems
Abstract. Adaptive scanning plays a key role in balancing observational strategies to address diverse scientific objectives while maximizing data collection for weather phenomena of interest. Current adaptive scanning capabilities for pulsed Doppler LiDARs (model Streamline XR), aimed at probing the streamwise velocity of atmospheric boundary layer flows, are limited to predefined scans based on wind directions derived from short-term wind profiles measured by the same instrument. As a result, high data rejection rates characterize the post-campaign phase due to excessive wind direction misalignment. To expand the Streamline LiDAR’s adaptive scanning capabilities, we designed a novel WaggleDop instrument. WaggleDop is an edge computing-enabled system for adaptive scan that supports external inputs and multi-LiDAR configurations via cloud-native infrastructure. In this paper, we test the WaggleDop-LiDAR setup by studying 20 low level jet events and 19 wind reversal events resolved during two U.S. Department of Energy (DOE)-funded field campaigns. We demonstrate that WaggleDop successfully captured these events through adaptive scanning strategies that could not be implemented via classic standalone LiDAR setup, resulting in a substantial enhancement in data availability of up to 90 %. The results shown here demonstrate the importance of more sophisticated scan adaptations to probe complex atmospheric boundary layer flows.
- Preprint
(13019 KB) - Metadata XML
- BibTeX
- EndNote
Status: final response (author comments only)
- RC1: 'Comment on egusphere-2026-2568', Anonymous Referee #1, 20 Oct 2026
-
RC2: 'Comment on egusphere-2026-2568', Anonymous Referee #2, 21 Oct 2026
This manuscript describes a method to change Doppler Lidar scan strategies based on measurements collected by that specific Doppler Lidar, or from measurements made by other instruments at another location. The adaptive scanning methodology is based on pre-defined thresholds that trigger a change in operating parameters. No user is involved in manually changing the operating parameters.
High-level view.
Is this paper supposed to be a science paper (discussing the benefits of adaptive scanning) or a user manual (discussing how to implement adaptive scanning with Streamline Doppler Lidars)? The manuscript does not do either very well. Let’s look at both cases.
Is the manuscript a Science Paper?
The biggest argument against using adaptive scanning is that the pre-conditions before a particular regime are not sampled. This means that modelers cannot learn from observations the conditions that precede a particular regime. As written, this manuscript supports the argument that adaptive scanning is not a good strategy to understand the precursors before a regime. I do not think that was the intent of this manuscript. Let us examine an example from the manuscript. A special scan strategy is implemented when the low level jet (LLJ) nose velocity exceeds 10 m/s and comes from a particular direction (see lines 195 and 196). When these conditions are met, the special hemispherical range height indicator (HSRHI) scan is performed in a specific azimuth angle (line 200). When either the 10 m/s threshold or the wind direction conditions are no longer met, the HSRHI scan is stopped. This adaptive scan strategy does not provide any information on the pre-conditions or post-conditions that would help modelers learn more about LLJ physics. The following sentence is in the Discussion and Challenges section and is on lines 282-283, “Therefore, WaggleDop’s ability to process wind profiles from other LiDARs and determine the LLJ noise can be used to track the LLJ throughout its entire lifecycle.” This sentence is not correct and is not supported in this manuscript because the LLJ lifecycle is not measured.
Is the manuscript a User Manual?
Section 3 describes the steps needed to implement the adaptive scanning and is full of minutiae. Read the first paragraph of Section 3 (lines 111-117). This paragraph reads like a trouble shooting guide or FAQ page (for example, line 116, “Finally, OpenSSH must be enabled on the DL in order for the Waggle Node to communicate with the DL via a Secure File Transfer Protocol (SFTP).” If the manuscript is going to provide this much user manual detail, then focus on the implementation and include more details about the hardware, like a BOM so that a reader can implement the WaggleDop on their networks. If the manuscript wants to be a science paper, then reduce the amount of user manual details.
As written, the manuscript is neither a science paper nor a user manual. It is a cross between the two and therefore, is not useful for an AMT reader. I encourage the manuscript to be refocused as either a science paper or a how-to paper focused on implementing the WaggleDop hardware/software.Comments (intended not to be critical, but to improve the manuscript from a reader’s point-of-view)
1. Title. The words “Autonomous event characterization” only appear together in the title. The word “Autonomous” appears only in the title. The word ‘characterization” appears in the title and on line 15. What does “Autonomous event characterization” mean?
2. Figure 1. What is the purpose of Fig. 1? It does not support the manuscript’s objectives and is not discussed later in the manuscript.
3. Figure 2. What is the purpose of Fig. 2? It looks like Fig 2a is a photograph of just a gray box on a tripod with two cameras. However, Fig. 2b and 2c show gray boxes along with lidars. Thus, can conclude that there was not a lidar deployed at the site photographed in Fig. 2a? Figure 2b, what is the purpose of the tripod without any instruments on it?
4. Figure 2. What is the purpose of the downward facing fish-eye camera? A reader would be interested in knowing what is learned from this view.
5. Line 80. Text states that DL locations are listed in Table 1. However, the locations are not listed in Table 1. Where is ‘CACO’? Describe the location in the table and not hidden in the text. Maybe use lat and lon to describe the site locations? Or, make the map in Fig. 2 readable.
6. Table 1. Why does the reader need to know about the ‘Lidar ID’?
7. Table 1. If you are going to spell lidar as LiDAR, then be consistent throughout.
8. Table 1. The scan strategy description is not useful. What does “Continuous VAD scans (~0.1 Hz)” mean? Does it mean that the lidar completes a VAD in ~0.1 Hz? That is fast! Provide more details about the scan strategies in Table 1.
9. All Figures. The image quality is very poor in all figures. I cannot read their contents.
10. Line 95 and Table 1. Is the “LEAFF” site listed in Table 1 located in the state of Virginia or in the state of Washinton? Line 96 states that the WaggleDop was installed at WREF. But WREF is not listed in Table 1.
11. Line 100 and Table 1. The text states, “At WREF, a ZX300 profiling LiDAR and a DL were installed…” Are these two lidars, or one lidar? Table 1 states that there was only one lidar at the LEAFF site (assuming WREF == LEAFF). Please clarify in the manuscript.
12. Lines 103-104 and Figure 4. Section 2 is the Experiment Sites section (line 78). It is not appropriate to show examples of observations in this section. Move Fig. 4 to a Data or Observation section and discuss how the image supports the objective of adaptive scanning. Currently, Fig. 4 does not support the manuscript objective.
13. Line108 and Figure 4. The text states, “These three-dimensional complex flow features, and the associated rapid wind direction changes justify the necessity of real-time-adaptive scan strategy at WREF.” The two snapshots shown in Figure 4 are separated by 4 hours and would not be considered “rapid wind direction changes”.
14. Line 136. The text is, "The DL operates in two modes. One mode of operation ..." I do not see where the text describes the second mode of operation.
15. Line 139. The text states, "In addition, if an operator wants to operate all scans in order continuously, they set them to operate every 65535 seconds." What is the reader supposed to do with this information?
16. Line 145. The text is, "All of the User-type scans can be provided in two different formats, ..." Then, on the next line (line 146), the line starts with, "The first mode, ...". Should the “first mode" mentioned on line 146 really be called the “first format” mentioned on line 145? Or are these modes the modes discussed in the previous paragraph (see line 136 which says the DL operates in two modes)? This text sure is confusing.
17. Line 206 and Figure 6. The text is, "During this time period, 5 events were detected by WaggleDop from 05:00 LDT on 28 July 2025 until 5:00 LDT on 29 July 2025." The 5 events shown in gray in Fig. 6 do not correspond to this time interval. The gray shading in Fig. 6 starts near hour 1 on 29 July and ends near hour 19 on 29 July. Why does the text not agree with Fig. 6?
18. Figure 7. Which site collected the data shown in Fig. 7? The caption is not providing enough information.
19. Line 221-225 and Fig. 7. Is fig. 7 supposed to show that the wind speed changed during this 6-hour interval? The 11 panels look the same to me. Plotting the mean and anomalies would show the change in wind over the 6-hour period.
Citation: https://doi.org/10.5194/egusphere-2026-2568-RC2
Viewed
| HTML | XML | Total | BibTeX | EndNote | |
|---|---|---|---|---|---|
| 210 | 133 | 25 | 368 | 22 | 30 |
- HTML: 210
- PDF: 133
- XML: 25
- Total: 368
- BibTeX: 22
- EndNote: 30
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
Summary: The authors present a system integrating Doppler lidars (Halo Photonics Streamline) with a Waggle edge-computing node to perform adaptive scanning during low-level jet (LLJ) events and to study valley flows. While the engineering appears functional, the manuscript currently lacks sufficient scientific motivation and fails to demonstrate why the proposed architecture is superior to, e.g., a standard embedded control PC, a raspberry, or maybe even an additional small software installed on the Doppler lidar itself.
Major Comments:
Scientific justification - The paper focuses heavily on the technical architecture (Waggle, Beehive) but does not address a specific atmospheric science question. What specific measurement is enabled by this system that could not be achieved by a standard, pre-programmed scanning schedule? The authors could state a clear atmospheric research driven hypothesis (e.g., "we aim to capture the turbulent kinetic energy budget during LLJ breakdown") that necessitates this reactive scanning capability.
Why an "ordinary PC" is not used - The decision algorithm (detecting a wind speed threshold and switching scanning modes) is a standard logic operation. A standard embedded PC connected to the lidar via ethernet could perform this task. The authors must provide a quantitative comparison (latency, data throughput, cost) demonstrating that the Waggle edge node provides a significant advantage. Without this, the "adaptive scanning" claim is merely "automation" and the paper’s relevance to the atmospheric community is questionable. I would assume Waggle has been developed for image and video processing, an process that must be faster than a data transfer to a central server could allow. Calculating VAD Wind speeds and finding wind speed maximum and direction sounds like a pretty easy task nowadays. Maybe spectral processing and adaptive FFT length, multiple peak finding etc, spectral data compression, would be applications.
Application of this technical approach - the statement that lidars 100km apart from each other can "interact" in a way is not based on Waggle in this case but on the fact that the systems are connected to "the internet". Also, it seems questionable to assume that the LLJ direction in the costal region is the same at the two distant locations. So why would one Doppler lidar 100km away need to determine the scanning of the other Doppler lidar.
Case studies - The two case studies, as presented, appear to only validate the system’s functionality (i.e., it successfully switched modes). They do not provide new physical insight into the LLJ structure or turbulence. How do these measurements improve our understanding of valley winds or coastal LLJs beyond standard observational campaigns?
Therefore, I was tempted to suggest to reject this publication at first in its current form, but I can imagine that a major revision can lead to a publication valuable for AMT. To publish this paper, the authors would need to focus on the lidar control and why the edge computing is really needed. I also would refrain from the - what sounds to the reader a bit like - marketing language (WaggleDop/Beehive), etc. Maybe one could state that it uses existing infrastructure like the Waggle nodes (because that’s already DOE infrastructure), and that should be all that is relevant here. Also prove e.g., that the latency of the edge computing is critical to capturing a micro-scale phenomenon (e.g., a gust front) that is missed by regular scanning. Or, expand the study to show how this capability allows for a long-term, unattended climatology study in a remote location where standard power/internet is not a given (this is where edge computing actually makes sense for an individual instrument at least).
Minor comments:
-The title states "autonomous event characterization." But if I am not mistaken the "events" are specifically the occurrence of LLJs. Or are there other events targeted? The title also states "using Doppler lidar systems". However, the manuscript only mentions Streamline systems and no other type/brand of Doppler lidar. In that sense the title would be more correct like: Autonomous characterization/tracking of LLJs with a network of distributed Streamline Doppler lidars.
-Since AMT is an international journal, please also state the country in the affiliations.
-L16: Language: "Low level jets ... are complex flows...that require observational planning...". A coherent observation scheme of LLJs requires planning.
-L31: high-resolution wind measurements. What means "high resolution" in this context?
-The introduction cites mostly US publications. What about airborne approaches to study coastal or valley winds with high resolution in other places of the world like, e.g., https://journals.ametsoc.org/view/journals/atot/34/6/jtech-d-17-0021.1.xml, https://amt.copernicus.org/articles/16/5495/2023/, https://www.kitcube.kit.edu/english/589.php)
-Fig.1 is not required at all, for the argumentation line of the paper. Therefore, I suggest to skip it.
-Fig.3: some station names are not readable, just place them in the blue areas
-L126. The link with "my-jobs" does not help, as the reader does not have the specific login.
-Sec 3.1 and Sec 3.2 reads somewhat like a user manual of the Streamline device. Maybe some facts are required for future argumentation, but the fact with 65535 seconds and User1 to User4 configurations are too specific for a scientific publication. I suggest to condense 3.1,2,3 into the most important facts and distance from the Streamline specific settings (or focus the paper specifically on the Streamline instruments).
-L144: zenith pointing scan should be replace by zenith-pointing measurement. The lidar is not scanning while staring to the zenith.
-Fig.7: It should be elaborated stronger in the text, what actually can be learned from this figure. To me personally, most graphs seem rather similar (except the last, where most likely turbulence over the ocean causes more scatter in the mean flow direction). Also, has the projection of the radial velocity to the downstream velocity be calculated correctly? It seems that the horizontal wind speed increases generally not homogeneously with height, but also with distance to the lidar. Is this in fact, true? Then, a convergence or divergence would be right at the lidar (red colors are in a V-shape).
-Ch 4.1. There is a chapter 4.1 but no 4.2 (which is possible chapter 5).
-Ch 4.1. One question arises here: The adaptive RHI scanning is in the direction of the mean flow at 150 m height. But what happens if the wind direction turns with altitude? Should the RHI scan also be tilted if you present U-values in Fig.7? This fact should be evaluated somewhat more in detail.
-Ch 5 from L.246 and Fig.8: How would the figure look different from just performing VAD scans and deriving the horizontal wind speed classically? A comparison with a 2nd instrument using a classical scan strategy would be the best to show the potential benefits. But since such an instrument was most likely not deployed in addition, could you derive it from a reduced data set? Such a comparison would somehow help the argumentation line. Also, out of curiosity from the reversal event: Did the wind just calmed down and then moved the other direction, or did the wind clearly rotate over a period of 15 min as indicated by Fig.8b from the rotated scanning plane?
-L.258: Fig.9 shows RHI scans. Probably just a typo.
-Fig.9: At first, the plots seem to have captured turbulent structures. But since these are hourly averages of multiple RHI scans, how should the fluctuations in the plots be interpreted? Are they meaningful in a physical sense?
-Maybe another a major comment: The discussion need to elaborate a more clearly on what has been improved over already existing approches. Doppler lidars and Dual/Multiple Doppler approaches, also in combination with LES models (another possible use of the edge computing technique?) to obtain turbulent 3D wind fields, and aircraft studies have been published since more than two decades. What are the new facts and how do they compare with existing or proposed setups? The mere statement, that scans can be performed faster is not convincing enough.
-Last point, and I hope I am not overstepping: As a non-native speaker I learned that sentences like "This is..." or "This requires..." without the use of a subject is considered bad style. Some of these occasions in the manuscript could be rewritten.