ICESat-2/ATLAS Onboard Flight Science Receiver Algorithms: Purpose, Process, and Performance.

The Advanced Topographic Laser Altimetry System (ATLAS) is the sole instrument on the Ice, Cloud, and land Elevation Satellite 2 (ICESat-2). Without some method of reducing the transmitted data, the volume of ATLAS telemetry would far exceed the normal X-band downlink capability or require many more ground station contacts. The ATLAS Onboard Flight Science Receiver Algorithms (hereinafter Receiver Algorithms or Algorithms) control the amount of science data that is telemetered from the instrument, limiting the data volume by distinguishing surface echoes from background noise, and allowing the instrument to telemeter data from only a small vertical region about the signal. This is accomplished through the transfer of the spacecraft's location and attitude to the instrument every second, use of an onboard Digital Elevation Model, implementation of signal processing techniques, and use of onboard relief and surface type reference maps. Extensive ground testing verified the performance of the Algorithms. On-orbit analysis shows that the Algorithms are working as expected from the ground testing; they are performing well and meeting the mission requirements. ©2020. The Authors. Earth and Space Science published by Wiley Periodicals LLC on behalf of American Geophysical Union. This article has been contributed to by US Government employees and their work is in the public domain in the USA.

Introduction

Over the last few decades, the Earth has experienced unprecedented changes in climate—especially in the polar regions where glaciers are rapidly melting and sea ice is thinning. The ICESat mission, which operated from 2003–2009 (Schutz et al., 2005; Zwally et al., 2002), was the first satellite lidar altimeter to accurately measure the height of the Earth's ice sheets, land topography, and vegetation. Its main objective was to characterize how the glaciers, sea ice, and ice sheets were responding to a rapidly changing climate by measuring their change in elevation. ICESat used a single 40 Hz laser beam operating at 1064 nm and analog waveform detection. The ICESat‐2 mission (Markus et al., 2017; Neumann, Martino, et al., 2019) is a follow‐on to the ICESat mission, with many of the same objectives as ICESat but using more advanced technology. ICESat‐2 employs six laser beams from a 10 kHz laser operating at 532 nm and single‐photon‐counting detectors to markedly increase the horizontal resolution, spatial coverage, and accuracy of the altimetry measurement. Although the high‐resolution measurements of ice sheets, glaciers, and sea ice are the mission's main scientific objectives, ICESat‐2 collects additional valuable scientific data globally. As did its predecessor mission, the data ICESat‐2 collects also allow monitoring of global topography and vegetation, inland water, ocean height, and atmospheric structure.

The ICESat‐2 satellite carries a single scientific instrument, ATLAS. The instrument was designed, built, and tested at the Goddard Space Flight Center (GSFC) (Markus et al., 2017; Martino et al., 2019; Neumann, Martino, et al., 2019). The design of ATLAS is such that it can count nearly every photon that it receives but it is impossible to downlink all of the data due to bandwidth limitations. Because of the large volume of data ATLAS can collect, sophisticated onboard algorithms are required to find and capture the signal around the surface in real time.

To mitigate the impact of the high background noise rates relative to the surface echo signal return rates, both a very narrow band‐pass filter (centered about the laser wavelength) and a temporal detector gate are used to reduce the noise. Even with those noise reduction techniques, the noise rates remain high relative to the signal during daylight period, and onboard processing must be employed to determine when and where signal is present. The signal processing method chosen for ICESat‐2/ATLAS follows from the successful algorithms developed by members of the ATLAS Algorithms team for the Mercury Laser Altimeter (Cavanaugh et al., 2007) and the Lunar Observer Laser Altimeter (Smith et al., 2010). The idea of an onboard database of Earth elevations, used in support of the Algorithms placement of the detector gate, is borrowed from the ICESat/GLAS onboard algorithms (Abshire et al., 2005). The ICESat‐2/ATLAS Algorithms are the result of decades of NASA Laser Altimeter instrument signal processing and telemetry selection techniques and represent the current state of the art for NASA Laser Altimeter systems.

The majority of ATLAS data contributing to the telemetry volume is the time of arrival of each photon. Background noise into the ATLAS detector during the day can exceed rates of 10 MHz while signal rates range from 0 to 20 photons per fire, depending on the reflectivity of the surface. Although temporal gating of the detector reduces the noise further, for a 10 μs temporal gate with a 10 MHz background rate, there are still one million noise events per second captured by the ATLAS detector. This is approximately 10 times what can currently be sustained by the mission over a day, and without the onboard knowledge to correctly place the detector gate, the noise counts per second would be 10 million.

Early in the mission planning the ICESat‐2 team made the decision to reduce the data collected via onboard processing rather than increase ground station contacts or use higher bandwidth communication methods such as laser communications. This decision was made prior to the Algorithms team joining the mission and so is not discussed in this paper.

The mission requirements and scientific priorities were taken into account when designing the onboard Algorithms, so all possible paths through the Algorithms are flexible, with parameters easily changeable on‐orbit, to optimize the science return while adhering to the telemetry data volume constraint. The purpose of this paper is to describe the Algorithms that are used onboard the spacecraft to capture and process the data and to show results that demonstrate the Algorithms are working successfully.

The driving requirements for the Algorithms are as follows:

Keep the average daily science telemetry data volume below 577.4 Gb/day.

Use the real‐time spacecraft position and attitude information to set the signal search region with a geolocation accuracy of 2 km and a range accuracy of 250 m, for all spacecraft nadir and off‐nadir pointing angles ≤5°.

Select the photon returns from the Earth's surface at least 90% of the time (90% probability of detection) for regions where the clouds are not optically dense, under various day/night, clear/cloudy, surface roughness, and reflectivity conditions.

Section 2 gives a brief description of the ATLAS instrument, and section 3 explains the purpose and function of the onboard Receiver Algorithms. Section 4 discusses ground testing of the instrument Algorithms prior to launch, and section 5 presents statistics on the performance of the Algorithms after launch and during science operations. The summary and conclusions are given in section 6.

ATLAS Instrument

The ATLAS instrument is a single‐photon‐sensitive 532 nm lidar system with a laser Pulse Repetition Frequency (PRF) of 10 kHz and a temporal transmit pulse width of ~1.5 ns. The laser pulse is split into six beams by a diffractive optical element prior to leaving the instrument. The beams are separated by 5–7 mrad in angle, which gives ~2.5 to 3.5 km separation of the spots on the surface. The six spots are grouped into three pairs with two spots each. The laser energy is divided unequally between the spots in a pair, with one (the strong spot) having about four times the transmit laser energy of the other (the weak spot).

The instrument records the roundtrip travel time of each returned photon. Some of the photons may be reflected off of aerosols or clouds in the atmosphere, and, unless the clouds are optically dense, some of the photons are reflected from the Earth's surface and vegetation. Figure 1 is a simplified diagram showing this process from laser fire to the ATLAS capture of received photon events. The data of scientific interest are the distribution of photon returns from the atmosphere and the roundtrip time of flight (TOF) of laser photons reflected from the Earth's surface and from the atmosphere very near to the Earth's surface. The TOF values are generated during ground processing, but the onboard electronics associates return events with their corresponding laser fire times and generates coarse ranges that are used to produce histograms of photon arrival times needed by the Receiver Algorithms.

Figure 1

Example of how the surface echoes (signal), solar background noise, and clouds echoes fall within the range window for a single laser fire. The light from the ATLAS laser penetrates the clouds, reflects off the Earth's surface, and returns to the instrument. There are multiple laser fires in flight at any given time, so each surface echo comes from a laser fire that occurred approximately 33 fires ago. Solar background noise and some of the laser light scattered from the clouds also reflect back to the instrument. Photons captured by ATLAS are shown in the range window, which provides a temporal noise gate. The green line represents the time the surface echo (signal) arrives while the black lines represent solar background and instrument noise arrival times. The shorter blue line represents the arrival time of a laser reflection off of a cloud. The range window location is moved by the Algorithms every 0.02 s relative to the laser fire and will occasionally overlap a laser fire, as shown in this example.

The photons from each spot are collected by the ATLAS optical system and delivered to the detector associated with that spot. The ATLAS Photon Counting Electronics (PCE) measure the laser fire and photon receive times (or photon time tags) and do much of the low‐level calculations for the Algorithms, including separating received events into histogram bins. After the flight software uses the histograms to identify bins that may contain surface signal, the histograms are used to determine the background photon rate and to estimate if the clouds are too thick to get a surface return. Much of this work must be done in the PCE hardware because of the high laser PRF and the speed at which processing is required. Each of the three PCEs handles the strong and weak spots for one pair.

Hardware limitations make it impossible to examine the entire stream of photon events. For each transmitted beam, a segment of the stream up to 6 km long can be used to capture photon events centered about the expected position of the Earth's surface. This segment, called the range window (RW), is then searched by the Algorithms for signal. Events outside of this RW are not captured. How the RW location and length are calculated is explained in section 3.

ATLAS also records atmospheric histograms, or profiles, which start ~14 km above the Earth surface and extend down ~14 km toward the Earth's surface with 30 m vertical resolution. Atmospheric histograms are generated for each of the six spots, with data integrated over 200 fires. Two consecutive 200‐fire histograms are combined to make a 400‐fire histogram. Alternate 400‐fire strong spot histograms are downlinked; weak spot histograms are generally not telemetered.

Description of the Receiver Algorithms

The ATLAS Receiver Algorithms are implemented partly in software and partly in hardware. The surface search region (RW) is constrained based on the spacecraft location and attitude, and information in the onboard Digital Elevation Model (DEM) which contains minimum and maximum heights relative to the WGS84 ellipsoid. The surface type, specified by an onboard Surface Reference Mask (SRM), determines how the signal processing and the subsequent telemetry downlink are handled. The Algorithms use four Earth surface types: ocean, land, sea ice, and land ice, defined by the SRM (coastal and vegetated regions are also indicated in the database). An onboard Digital Relief Map (DRM), with both 140 and 700 m length‐scale relief, provides topographic relief information needed to set the telemetry band extents. The onboard databases were developed by the University of Texas‐Center for Space Research (Leigh et al., 2015) and were independently verified by the ATLAS/ICESat‐2 Science Receiver Algorithms team.

The Receiver Algorithms use position, velocity, and attitude information, transferred from the spacecraft to the ATLAS flight software in real time at 1 s intervals, to predict the ground locations of the laser spots and the ranges to the Earth ellipsoid. Given these locations and ranges, the Algorithms access the onboard DEM to determine the location of the RWs. Because time is needed for the hardware to set up the RW, the ground locations (and hence RWs) are extrapolated forward in time for up to 1.5 s.

Because ATLAS is a photon‐counting instrument, with very few photons returned from any given fire (nominally 1–10), and with generally more noise photon returns during daylight than surface events, the determination of which photons are surface events must be done statistically. The Algorithms must combine data from multiple fires to accumulate a statistically significant sample to search for and find the ground return segments in the photon stream. The hardware processes data in groups of 200 fires, which is about 0.02 s, corresponding to a distance of approximately 140 m along‐track. This grouping is called a major frame (MF).

Once all data for a MF have been received, the instrument hardware generates, for each laser spot, two histograms from the received events, with an integration time of one MF (200 fires):

An altimetric histogram covering the RW with a vertical bin size of 20 ns (approximately 3 m): The maximum length of this histogram is 2,000 bins (approximately 6 km). This histogram is used by the onboard Algorithms to perform the signal search and is not downlinked except when diagnostic packets are requested.

An atmospheric histogram covering just under 14 km in height with a bin size of 200 ns (approximately 30 m): This histogram is then added to the atmospheric histogram for the previous MF to generate a 400 fire histogram that is the atmospheric product downlinked every other MF.

Figure 2 shows the relationship between the atmospheric histogram, the RW where the search for the signal occurs, and the downlink band. The ends of the atmospheric and altimetric histograms farthest from the spacecraft coincide in this example, as is normally the case. The telemetry band for each spot is nominally centered about the location of the detected ground signal but can be offset using an Algorithms parameter.

Figure 2

Relationship between the Atmospheric Histogram, Range Window (Altimetric Histogram), and Telemetry Band. The Earth's surface is the boundary between the gray and blue regions. The start of the RW, histogram, and telemetry band is defined as that part closest to the spacecraft.

At the request of the software, the hardware generates a second (“software”) altimetric histogram by rebinning the hardware histogram with a larger bin size that depends on the surface type. This new bin size is chosen to try to put most of the ground return into one bin. This software histogram is searched by the Algorithms for the ground signal, and the Algorithms use this and the information in the DRM and SRM to determine the size and location of the telemetry bands; a second telemetry band may be defined if there is a second strong peak in the software histogram. To improve the chance of finding data under cloudy conditions or when the ground return is hard to find for other reasons, the Algorithms also look at data across five consecutive MFs (called a “super frame” or SF) and can generate a telemetry band based on this.

The generation of the telemetry bands is controlled by the parameters in the onboard parameter files defined for each PCE. These parameters control the paths taken through the Algorithms and determine how the information from the onboard databases is used. The parameters are used to fine‐tune the performance, adapt the Algorithms, and accommodate changing mission priorities without having to change the Flight Software (FSW). Updates to the parameters can be made easily on‐orbit by uploading the new parameter files. Updates to the databases are also possible.

A small fraction of the outgoing beams for two of the strong spots (Spots 1 and 3) is picked off by a partially reflecting mirror and fed into the receiver channel as a way of recording the shape of the outgoing laser pulse. This transmit pulse pickoff is called the Transmitted Echo Pulse (TEP), and its location is fixed relative to the time the laser transmit pulse was generated (time of fire). The TEP is only captured by the Algorithms and telemetered when the TEP falls within the RW, and the onboard parameters are set to telemeter it down to the ground.

For a complete description of the ATLAS Receiver Algorithms, see McGarry et al. (2019).

Ground Testing

Thorough testing of the Receiver Algorithms prior to launch was essential to ensure they work correctly on‐orbit. To that end, a software Receiver Algorithms Simulator was developed to test the Algorithms and to verify the FSW implementation. The Simulator integrates a series of modules that simulate the ATLAS instrument hardware, the spacecraft orbit and attitude, the environment (atmosphere conditions and surface characteristics), and the laser beam interaction with the environment, with modules that implement the Receiver Algorithms. This program simulates the journey of a laser pulse transmitted from ATLAS through the atmosphere to the Earth's surface and back to the instrument. Solar background photons are also simulated. Both laser and solar photons flow through the simulated receiver. The data from the simulated receiver are combined with simulated spacecraft data and fed into the Algorithms team's implementation of the Receiver Algorithms. The output of this Simulator was analyzed to check the Algorithms and ensure their correct implementation. The Simulator also produced data files, called Embedded Simulator files, that were used as input to the Bench Check Equipment (BCE), a fundamental hardware system used for ground testing of the instrument. The BCE is described below.

The Simulator served as a platform to test the Algorithms rigorously and provided us with the ability to start this testing, using hardware specifications, before the instrument hardware was built. In addition, it allowed independent coding of the Algorithms to verify the Flight Software team's onboard software implementation. Lastly, it was used to perform controlled experiments under conditions that could be duplicated, to follow all major Algorithms paths, simulating all conditions likely to be encountered on‐orbit, and to perform experiments on the Algorithms that would have been impossible during any ground testing of the instrument. Figure 3 shows a flowchart of the Receiver Algorithms Simulator as implemented.

Figure 3

Receiver Algorithms Simulator Flow Diagram. The Simulator was developed completely in software and was one of the fundamental tools used in the building and testing of the Algorithms. The left side of the figure describes the Instrument and Environment Simulator modules, while the right side of the figure shows the processing flow of the Algorithms operating on the photon returns to identify the signal and select the telemetry bands for science ground processing.

We developed and documented over 30 test cases that were used to test and later verify that the Algorithms met the requirements. These tests covered as many anticipated situations as possible, including (1) systematically checking the probability of detection over many combinations of background noise and signal strength, (2) testing over a complete nominal orbit, (3) looking at the performance over the mission's Round The World (RTW) and Ocean Scan (OS) calibration maneuvers, (4) determining the performance of the Algorithms over abrupt and rapidly varying terrain heights, and (5) testing various extreme cases (e.g., multiple signal locations, decisions paths with no or minimal signal, and maximum nutation), where extreme combinations of environment, terrain, and parameters push the capability to select the best telemetry band region for downlink. Testing was performed in both day and night conditions, with a range of background noise rates (0 to 13 MHz), return signal energy (0.1 to 8 photoelectrons per fire), and various cloud conditions ranging from cloud‐free to dense clouds that prevented surface returns from reaching the instrument. All of the critical Instrument Science Design Cases (McGarry et al., 2019, Appendix D) defined by the Science Team and used by the Instrument Team were tested, and various configurations of parameter files were used during different tests. Table S1 in the supporting information gives a descriptive list of the Receiver Algorithms test cases.

All of the Simulator tests were run through the ATLAS FSW by the Flight Software team in a simulated environment in the laboratory using the FSW computers. The results were compared to the Simulator results and used to find and correct errors in both the Simulator and the FSW implementations of the Algorithms.

The entire Simulator was written by the Receiver Algorithms Team, including the code for Receiver Algorithms themselves. This allowed independent comparison testing with the flight code generated by the ATLAS Flight Software team who coded only from the ATLAS Flight Science Receiver Algorithms Document (McGarry et al., 2019).

As a necessary time savings, and because we had verified the Flight Software extensively at the component level, only a subset of the Simulator tests were then used during ATLAS Integration and Testing (I&T). The I&T tests were performed with the FSW loaded into the ATLAS instrument. The spacecraft position and attitude were simulated through the Spacecraft Interface Simulator (SIS), which was supplied by the spacecraft manufacturer, Orbital ATK (now Northrop Grumman). The SIS used the same orbits as those used in the Simulator testing.

The surface response and atmosphere were simulated during I&T by the BCE. As mentioned previously, for each test case, the Simulator generated an Embedded Simulator output file containing background noise rates, signal return energy, pulse spreading due to surface roughness, range to the surface, number of returns, and pulse separation, all time‐tagged relative to the UTC start of the test. The Embedded Simulator file for each test was then input by the BCE and followed based on the time tags. The BCE, SIS, and ATLAS instrument were synchronized by a GPS provided UTC time that was set at the start of the test to be the shared T0 (the beginning of the simulation test time). Figure 4 shows a block diagram of the BCE setup during ground testing with the ATLAS instrument.

Figure 4

Block diagram showing the BCE setup during ground testing with the ATLAS instrument. The top part of this diagram shows the setup during ground testing of the Algorithms with the ATLAS instrument. Shown is the BCE, the Spacecraft Interface Simulator (SIS), the ATLAS instrument, the Ground Support Equipment (GSE), and the interfaces between these. Details of the ATLAS instrument and BCE are given in the bottom part of the diagram, where ATLAS (a) and BCE (b) components have been expanded in more detail.

Careful calibration of the BCE laser power was required before every Algorithms test was performed. This was crucial to a successful performance of the Algorithms tests. Calibration was done for the lasers that produced the simulated Earth surface and cloud returns as well as the laser that generated the background noise levels.

Mission Observatory testing involved a subset of the I&T Receiver Algorithms testing. It also used the BCE to simulate the Earth, following the Simulator output files and the ATLAS test scripts. The actual spacecraft computers and interfaces replaced the SIS; the spacecraft was able to simulate the same orbits as the SIS had during ATLAS Instrument I&T.

Performing the same tests through the various test phases made it possible to confirm that the Simulator results matched the instrument performance in I&T and at Observatory level and to check that the performance of the Receiver Algorithms consistently met the requirements at all levels of simulation. The test setup at I&T and Observatory levels with the BCE allowed testing of the FSW implementation of the Algorithms within the ATLAS instrument in conditions as close as possible to “test as we fly,” contributing to the ATLAS successful on‐orbit performance.

On‐Orbit Performance

After launch, the Receiver Algorithms team reviewed on‐orbit data from the period November 2018 to October 2019 to verify that the Algorithms were meeting the requirements and to confirm the previous extensive prelaunch testing of the Algorithms. Results of the analysis for the early part of this period are presented in McGarry et al. (2018) and Carabajal et al. (2018). An internal Commissioning Report was also written focusing on March and April 2019, a period which was clear of other instrument testing and spacecraft issues. From the postlaunch analysis the Algorithms team concluded that the Receiver Algorithms, as implemented by the ATLAS Flight Software team, are performing well and that the on‐orbit requirements are being met. The ICESat‐2 Science Team and the Project Science Office are in agreement with the findings of this report. The results shown below are highlights taken from that report.

In addition to the review and analysis by the Receiver Algorithms team, the ICESat‐2 Science Team has been regularly evaluating the downlinked ATLAS science data and has not found any major issues with the Algorithms. The discipline‐specific members of the Science team recommended several changes to optimize the ATLAS data for their needs. These changes were easily and successfully handled by the uplink of a few modifications to the Algorithms parameters. No changes to any Algorithms FSW code were needed.

The section below presents examples showing that the Algorithms meet their three major on‐orbit requirements. The ATL03 and ATL04 products described below are the Level‐2A (L2A) global geolocated photon data product and uncalibrated atmospheric backscatter profiles. These data products are generated by the ICESat‐2 Project Science Office and are available to the science community from the National Snow and Ice Data Center (https://nsidc.org/data/icesat‐2). The documents describing these data are located online (at https://icesat‐2.gsfc.nasa.gov/science/data‐products).

Requirement (a): Downlinked Data Volume Must Be Limited

Without the onboard Receiver Algorithms the ATLAS daily telemetry data volume would be between 10 and 100 times the maximum daily value. Before launch, estimates indicated that the daily data volume with the Algorithms would be close to the allowed limit of 577.4 Gb/day. After launch the data stabilized at about 440 Gb/day, which was less than expected, leaving margin to modify the Algorithms parameters to downlink more data. At the request of the ICESat‐2 Science Team, the Receiver Algorithms v8 parameters were enabled on 3 September 2019 (DOY 246), at 13:30:00 UTC. These new parameters optimized the science data telemetered, ensuring that all strong spot telemetry bands over water were always sent, increasing the telemetry band padding for water, sea ice and land ice, and offsetting the telemetry bands for sea ice and land ice to capture blowing snow. The ATLAS downlinked data rate with v8 parameters increased to about 530 Gb/day. Figure 5 shows the daily data volume before and after the v8 parameter update.

Figure 5

Daily telemetry data volume for a period with Receiver Algorithms launch parameters (v6, black squares) and a period after the update to the v8 parameters (blue circles). The parameter switch occurred on 3 September 2019, so the first 2 days of September and part of the third were still with the v6 parameters. The data volume with the launch parameters (v6) is ~440 Gb/day. The data volume after the parameters were updated to v8 is ~530 Gb/day. The daily data volume varies significantly from day to day depending upon the surface conditions, the cloud cover, and the onboard activities being performed. Data volume information courtesy of the ICESat‐2 Instrument Support Facility (ISF).

Requirement (b): RW Must Be Correctly Set

The Algorithms add a 250 m margin to the top and bottom of the RW to allow for errors in pointing and geolocation and uncertainties in the DEM. We expect the signal to fall in these margins some of the time, especially when the RW is narrow and the instrument is pointed off nadir, but based on our error analysis, we expect to see very limited amounts of signal in those regions that are within 10% of the two RW edges. Table 1 shows combined data from one RTW scan, one OS, and one nadir pointing period. During the RTW scan and OS periods, the spacecraft attitude is nominally 5° off‐nadir. We estimated the signal locations as the centers of the telemetry bands, deleting telemetry bands associated with the TEP. The early columns refer to the period at the top of the RW (closest to the satellite), while the late columns refer to the period at the bottom of the RW (closest to the surface). The estimated signal falls into the 25 m edge regions of the RW a very small percentage of time, providing an indication that the RW margin is correctly set. Combined with the high surface signal detection rate shown in section 5.3 below, Table 1 implies correct placement of the RWs.

Table 1

Signal Near the Edges of the RW

	# TBs	# early 25 m	# late 25 m	Early 25 m	Late 25 m
Land	204,433	0	0	0%	0%
Land Ice	139,888	0	2	0%	0.001%
Ocean	504,983	399	545	0.079%	0.108%
Sea Ice	160,928	41	118	0.025%	0.073%

Note. Column 2 gives a count of the number of Telemetry Bands (TBs) used in each row's calculations. Early refers to the margin at the top of the RW (closest to the satellite). Late refers to the margin at the bottom of the RW (closest to the surface). Data from all spots and from three different data sets are combined. Ocean Scan data are from 1 March 2019 starting at 19:27:15 UTC for 22 min. RTW data are from 18 March 2019 starting at 8:07:25 UTC for 102 min. The nadir pointing data are from 4 March 2019 starting at 18:00:00 UTC for 100 min. Only data for which the ATL04 cloud flag indicated surface could be found were used. The percentage of returns near the RW edges is much less than 1%.

Figure 6 shows the RW and telemetry bands for an ocean and land ground track crossing Mauna Kea, Hawaii, at night. This is a pass where the instrument was pointed about 0.3° off‐nadir, which is the nominal orientation of the ATLAS instrument and is referred to on ATLAS as nadir pointing. A zoom into the high‐peak area shows that the RW fully captures the highest points of this pass. The ground returns remain within the RW even as the surface elevation varies by hundreds of meters over very short time periods. Also plotted are the flight times of the return events in the telemetry band selected by the Algorithms. The surface echoes can be clearly seen as the solid black line centered in the telemetry band.

Figure 6

Position of telemetry bands in Spot 3's RW during a pass over Mauna Kea on 2 November 2018. This is a nadir pointing pass. The start of the RW (closest to the spacecraft) is at the top, while the end of the RW (closest to the surface) is at the bottom. Gray background in the range window of the (a) and (b) plots indicates night‐time observations as does the gray bar across the bottom. The red vertical lines in the RW in (a) and (b) are the primary telemetry bands and the green are the secondary. The bars across the top of plots (a) and (b) show (1) the surface type (lower bar) and (2) results from the ATL04 cloud test (upper bar) indicating the likelihood of clouds being present. The middle plot (b) is a zoom into the box shown in the top plot (a). The lower plot (c) shows the time of flight events within the primary telemetry bands for a portion of the middle plot. The horizontal axis units are in relative MFs and seconds of day. The red line in the map inserted in plot (a) shows the global location of ICESat‐2 during the data collection.

Review of many Ocean Scans, RTW scans, and other nadir pointing data shows that the telemetry bands are normally well within the RW edges and that the Earth surface TOF events are well centered in the telemetry bands. Figures S1–S4 show the RW and telemetry bands over southern Africa, during both a full RTW and OS maneuver, and near Mount Everest.

Requirement (c): Probability of Detecting the Surface Must Be High

A separate postprocessing algorithm uses the downlinked atmospheric histograms to determine if the instrument should be able to see the surface returns. This algorithm is described in the ICESat‐2 ATL04 product Algorithm Theoretical Basis Document (Palm et al., 2019) and uses the atmospheric histogram and a Digital Elevation Model reference surface height associated with the location of this histogram, to set a search window around the surface height, looking for surface signals. It then generates a flag indicating if the surface was found or not. The results of this processing are included in the ATL04 products 25 times per second. We used this postprocessing information from the ICESat‐2 atmospheric products to check the onboard Receiver Algorithms performance in finding surface returns. For the 3+ hr of data in Table 2, when the ATL04 flag indicated that the surface should be detected, the Algorithms probability of signal detection was >90% in all nadir pointing cases, and >85% for off‐nadir pointing.

Table 2

Assessment of the Probability of Acquisition for ICESat‐2 Based on the ATL04 Surface Detection Flag

Sample	Surface	# MF	% found
RTW scan	Ocean	571,326	86.9
RTW scan	Land	59,325	88.7
RTW scan	Sea ice	223,496	95.6
RTW scan	Land ice	186,513	99.4
Nadir pointing	Ocean	399,543	92.7
Nadir pointing	Land	358,454	94.5
Nadir pointing	Sea ice	154,450	94.9
Nadir pointing	Land ice	155,759	97.1

Note. Round The World (RTW) scan data are 102 min on 18 March 2019 starting at 8:07:25 UTC. Nadir pointing data are 100 min on 4 March 2019 starting at 18:00:00 UTC. All spots were used for both data sets. The analysis is separated into surface type with data for all spots combined. For every MF in the data, the “# MF” column shows the count of MFs with ATL04 flag, indicating that the surface should be detected. The “% found” column gives the percentage of time the onboard Algorithms found surface signal for those MFs counted in “# MF” column.

Table 3 shows an independent assessment by the Science Team of the probability of detection. The statistics were generated using the ICESat‐2 ATL03 product confidence flag (Neumann, Brenner, et al., 2019). The ATL03 product includes a classification for each photon event as either a likely surface return or a background photon and provides a confidence assessment on these classifications. Histograms of the number of photon events are generated as a function of height, and a signal‐to‐noise threshold is calculated. The photon events in bins above that threshold are classified as signal, while other photon events are classified as background. With cloud cover at ~70% over the Earth, of which ~40% is transmissive, we would expect to see surface returns ~60% of the time. In fact, the percentage of high confidence events shown in Table 3 is often higher than this, implying that much of the cloud cover does not prevent surface signal from being detected for the strong spots and that the Algorithms are working as required.

Table 3

Assessment of the Probability of Detection of Surface Echoes for ICESat‐2 Based on ATL03 High‐Confidence Results for All Data During the Months of March and April 2019

Surface type	Spot 1, % strong	Spot 2, % weak	Spot 3, % strong	Spot 4, % weak	Spot 5, % strong	Spot 6, % weak
Ocean	81.0	51.3	80.8	53.3	81.4	51.7
Land	82.1	64.9	82.3	67.4	82.3	64.9
Sea Ice	77.7	66.3	77.8	67.4	78.0	66.3
Land Ice	82.6	69.2	82.7	70.7	82.9	69.4
Inland water	78.7	63.0	79.1	65.7	79.0	62.8

Note. Analysis is separated into surface type and spot. The column values are the percentage of photon events labeled as having a high confidence of being laser returns from the Earth's surface in the ATL03 data.

Summary and Conclusions

The onboard science Receiver Algorithms were developed to locate the laser pulse surface return consistently and limit the daily science data volume that is telemetered from the ATLAS instrument. To perform the required limitation, the onboard Algorithms had to accurately set temporal RWs based on the spacecraft location and orientation and on the surface heights of the six laser spots, distinguish surface signal from noise, and only telemeter a small band about the surface signal.

Testing of the Receiver Algorithms started with a software simulator of the instrument and environment and continued through ATLAS Instrument I&T and into mission testing. The performance of the Receiver Algorithms was consistent throughout all testing and remains consistent on‐orbit. There have been no major changes to the Algorithms required since launch. The flexibility provided by the Algorithms' design and the ability to upload updated Algorithms parameter files allow for updates to accommodate varying science requirements and possible instrument changes throughout the mission lifetime, while still maximizing the science return.

The Receiver Algorithms are meeting their requirements and working well. This has been demonstrated by analysis of the telemetry data by the Receiver Algorithms Team and from the Science Team's analysis and use of the data. Surface signal detection is averaging ~90% when the clouds are not optically thick enough to totally attenuate the laser pulse. The daily data volume average has remained under the required limit (577.4 Gb) since launch.

Supporting Information S1

Click here for additional data file.