Search NASA⌕ Search

SEARCH · Search NASA

Results for “instrument data processing software”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

Intelligent assistance in scientific data preparation

Scientific data preparation is the process of extracting usable scientific data from raw instrument data. This task involves noise detection (and subsequent noise classification and flagging or removal), extracting data from compressed forms, and construction of derivative or aggregate data (e.g. spectral densities or running averages). A software system called PIPE provides intelligent assistance to users developing scientific data preparation plans using a programming language called Master Plumber. PIPE provides this assistance capability by using a process description to create a dependency model of the scientific data preparation plan. This dependency model can then be used to verify syntactic and semantic constraints on processing steps to perform limited plan validation. PIPE also provides capabilities for using this model to assist in debugging faulty data preparation plans. In this case, the process model is used to focus the developer's attention upon those processing steps and data elements that were used in computing the faulty output values. Finally, the dependency model of a plan can be used to perform plan optimization and run time estimation. These capabilities allow scientists to spend less time developing data preparation procedures and more time on scientific analysis tasks.

Chien, Steve↗
DOE OSTI2021

UNH TDP - Concurrent Measurements of Inflow, Power Performance, and Loads for a Grid-Synchronized Vertical Axis Cross-Flow Turbine Operating in a Tidal Estuary

This data was collected between October 12 and December 15 of 2021 at the University of New Hampshire (UNH) and Atlantic Marine Energy Center (AMEC) turbine deployment platform (TDP). This data set includes over 29 days of grid connected turbine operation during this 65 day time frame. The priority for this measurement campaign was to collect data while the turbine was electrically connected to the grid by means of a rectifier and inverter. The Fall_2021_UNH_Measurement_Timeline.png highlights when each instrument was functioning and the Fall_2021_UNH_Test_Log.jpg indicates the four main regions for analysis available from this measurement campaign. The TDP is a floating structure moored on the Portsmouth facing side of Memorial Bridge pier #2, which spans the Piscataqua River between Portsmouth, NH and Kittery, ME. The Piscataqua River connects the Great Bay Estuary to the Gulf of Maine and the river currents are dominated by tidal forcing with water velocities exceeding 2.5 m/s during spring ebb tides at this site which were previously characterized by Kaelin Chancey (Assessment Of The Localized Flow And Tidal Energy Conversion System At An Estuarine Bridge - UNH MS Thesis 2019). The turbine under test was a modified New Energy Corporation (Calgary, CA) model EVG-025 4-blade H-Darrius type vertical axis cross flow turbine that rotates in the clockwise direction with a rotor diameter of 3.2m and blade length of 1.7m. The hydro-foil profile was a NACA 0021 with a 10 inch chord length and a blade preset pitch angle of +4deg with a positive angle corresponding with the toe in direction. The standard EVG-025 has a rotor diameter of 3.4m and its rated power output is 25kW at 3 m/s. The rotor diameter was reduced to accommodate the size of the existing TDP moon-pool. This project was pursued to quantify device performance for cross flow turbines operating in a marine environment. Accurate physical models, to characterize cross flow turbine performance, require real operational data sets due to the complexity of blade fluid interactions. This data can help support model development which will help predict turbine performance when analyzing perspective project locations in the future. Instrumentation was deployed to measure; water speed/direction, electrical power output, turbine shaft speed, turbine thrust force, and platform motion. Concurrent measurements of these parameters allow for correlations (cause and affect) to be inferred, allowing for characterization of device performance over a range of operating conditions. Water currents were measured using Acoustic Doppler Current Profilers (ADCP's) and Acoustic Doppler Velocimeters (ADV's) directly upstream and downstream of the turbine for inflow, wake and turbulence measurements. Electrical power output was measured using the Voltsys rectifier and the Shark power meter. Shaft speed was calculated based on the Voltsys measurements of the permanent magnet three phase generator AC generation frequency, coupled directly to the cross flow turbine under test (i.e., no gear box). Platform motions were captured using a Yost IMU (inertial measurement unit). Turbine thrust loading was measured using a reaction arm about the turbine deployment platform spanning beam, where two bi-directional load cells were connected to the system via a pinned connection. This submission includes zipped folders for each instrument containing quality controlled (QC'd) data in daily .csv files for the relevant duration specific to each instrument, along with separate .csv file that contains the units for each variable. Some instrument daily files are quite large and can pose a challenge for a visual spreadsheet editor to open. A processing software like MATLAB or Python is recommended. Note the degree of QC varied between each instrument due to time constraints. Particular time and attention was given to perform quality control tests on the acoustic based instruments that are particularly suscep...

16 TIDAL AND WAVE POWER↗
DOE OSTI2022

Designing a Magnetic Measurement Data Acquisition and Control System With Reuse in Mind: A Rotating Coil System Example

Accelerator magnet test facilities frequently need to measure different magnets on differently equipped test stands and with different instrumentation. Designing a modular and highly reusable system that combines flexibility built-in at the architectural level as well as on the component level addresses this need. Specification of the backbone of the system, with the interfaces and dataflow for software components and core hardware modules, serves as a basis for building such a system. The design process and implementation of an extensible magnetic measurement data acquisition and control system are described, including techniques for maximizing the reuse of software. The discussion is supported by showing the application of this methodology to constructing two dissimilar systems for rotating coil measurements, both based on the same architecture and sharing core hardware modules and many software components. The first system is for production testing 10 m long cryo-assemblies containing two MQXFA quadrupole magnets for the high-luminosity upgrade of the Large Hadron Collider and the second for testing IQC conventional quadrupole magnets in support of the accelerator system at Fermilab.

43 PARTICLE ACCELERATORS↗
NASA NTRS2022

Science Autonomy for Ocean Worlds Astrobiology: A Perspective

Astrobiology missions to ocean worlds in our solar system must overcome both scientific and technological challenges due to extreme temperature and radiation conditions, long communication times, and limited bandwidth. While such tools could not replace ground-based analysis by science and engineering teams, machine learning algorithms could enhance the science return of these missions through development of autonomous science capabilities. Examples of science autonomy include onboard data analysis and subsequent instrument optimization, data prioritization (for transmission), and real-time decision-making based on data analysis. Similar advances could be made to develop streamlined data processing software for rapid ground-based analyses. Here we discuss several ways machine learning and autonomy could be used for astrobiology missions, including landing site selection, prioritization and targeting of samples, classification of “features” (e.g., proposed biosignatures) and novelties (uncharacterized, “new” features, which may be of most interest to agnostic astrobiological investigations), and data transmission.

ocean worlds↗
NASA NTRS2012

Software Reuse in the Planetary Context: The JPL/MIPL Mars Program Suite

Reuse greatly reduces development costs. Savings can be invested in new/improved capabilities Or returned to sponsor Worth the extra time to "do it right" Operator training greatly reduced. MIPL MER personnel can step into MSL easily because the programs are familiar. Application programs much easier to write. Can assume core capabilities exist already. Multimission Instrument (Image) Processing Lab at MIPL Responsible for the ground-based instrument data processing for (among other things) all recent in-situ Mars missions: Mars Pathfinder Mars Polar Lander (MPL) Mars Exploration Rovers (MER) Phoenix Mars Science Lab (MSL) Responsibilities for in-situ missions Reconstruction of instrument data from telemetry Systematic creation of Reduced Data Records (RDRs) for images Creation of special products for operations, science, and public outreach In the critical path for operations MIPL products required for planning the next Sol s activities

Software Design↗
NASA NTRS2019

NASA’s Orbital Debris JAO/ES-MCAT Optical Telescope Facility on Ascension Island

The NASA Orbital Debris Program Office has a long-standing optical program begun over three and a half decades ago in 1984, designed to observe the Earth-orbiting environment with optical telescopes. Photometrically calibrated optical data provides a statistical sample for input to NASA models of the debris population for understanding the current and future debris environment around the Earth. Tracked objects and orbits allow for analysis of break-up events. Both known (correlated target in the SSN catalogue, or CT) and unknown (uncorrelated target, or UCT) objects are of interest to better understand how to protect current spacecraft and design more robust future operational satellites, and advise on how policies and practices can lead to protecting the environment itself for future generations. In 2015, a joint NASA JSC – Air Force Research Labs (AFRL) project culminated in the installation of the 1.3-meter Eugene Stansbery Meter Class Autonomous Telescope, ES-MCAT (a.k.a. MCAT) on Ascension Island. This DFM Engineering designed telescope provides nearly five-times greater light-collecting power than its predecessor, the 0.6-m MODEST telescope, and faster tracking capabilities by both the telescope and the 7-m ObservaDome. This allows for all orbital regimes to be easily within reach, ranging from low Earth to geosynchronous orbits. Extensive testing and commissioning activities of this custom system led to successfully reaching Initial Operational Capability in 2018, and the facility is currently on track to reach Full Operational Capability. The John Africano Observatory (JAO) comprises the primary 1.3-m ES-MCAT facility, the adjacent tower platform with a 0.4-m telescope, a sophisticated suite of weather instruments, and custom software by Euclid Research for autonomously running the entire system, including monitoring the weather and hardware, tasking all components, and collecting, processing, and analyzing the data. The mission of JAO and MCAT will be discussed, including survey and tracking tasking, a full discussion of data calibration, and both optics and weather-dependent performance.

Lederer, S. M.↗
NASA NTRS2004

Software Processes SAR Motion-Measurement Data

Motion Measurement Processor (MMP) is one of three computer programs that are used together in the operation of a terrain-mapping dual-frequency interferometric synthetic-aperture-radar (SAR) system. The other two programs - Jurassicprok and Calibration Processor - are described in the two immediately preceding articles. MMP acquires all the motion and attitude data collected by onboard instrumentation systems, including radar, laser and camera metrology, inertial navigation systems, and Global Positioning System (GPS) receivers. MMP combines all this information and processes it into all the trajectory information needed to run Jurassicprok, which performs the interferometric processing and mapping functions. MMP includes several Kalman filters for combining and smoothing aircraft motion and attitude data, and least-squares inversion and filtering software tools for solving for interferometric baseline lengths. MMP synchronizes the motion and radar data. It combines the various measurement data into a unified, seven-dimensional reference system and puts out the resulting filtered trajectory and attitude data along with instructions for use of the data by Jurassicprok, as well as the command files used to operate Jurassicprok.

Freedman, Adam↗
NASA NTRS2015

Spacecube: A Family of Reconfigurable Hybrid On-Board Science Data Processors

SpaceCube is a family of Field Programmable Gate Array (FPGA) based on-board science data processing systems developed at the NASA Goddard Space Flight Center (GSFC). The goal of the SpaceCube program is to provide 10x to 100x improvements in on-board computing power while lowering relative power consumption and cost. SpaceCube is based on the Xilinx Virtex family of FPGAs, which include processor, FPGA logic and digital signal processing (DSP) resources. These processing elements are leveraged to produce a hybrid science data processing platform that accelerates the execution of algorithms by distributing computational functions to the most suitable elements. This approach enables the implementation of complex on-board functions that were previously limited to ground based systems, such as on-board product generation, data reduction, calibration, classification, eventfeature detection, data mining and real-time autonomous operations. The system is fully reconfigurable in flight, including data parameters, software and FPGA logic, through either ground commanding or autonomously in response to detected eventsfeatures in the instrument data stream.

reconfigurable computing↗
NASA NTRS1993

Real-time on-board orbit determination with DORIS

A spaceborne orbit determination system is being developed by the French Space Agency (CNES) for the SPOT 4 satellite. It processes DORIS measurements to produce an orbit with an accuracy of about 50O meters rms. In order to evaluate the reliability of the software, it was combined with the MERCATOR man/machine interface and used to process the TOPEX/Poseidon DORIS data in near real time during the validation phase of the instrument, at JPL and at CNES. This paper gives an overview of the orbit determination system and presents the results of the TOPEX/Poseidon experiment.

Berthias, J.-P.↗
NASA NTRS2007

Using Selection Pressure as an Asset to Develop Reusable, Adaptable Software Systems

The Goddard Earth Sciences Data and Information Services Center (GES DISC) at NASA has over the years developed and honed several reusable architectural components for supporting large-scale data centers with a large customer base. These include a processing system (S4PM) and an archive system (S4PA) based upon a workflow engine called the Simple Scalable Script based Science Processor (S4P) and an online data visualization and analysis system (Giovanni). These subsystems are currently reused internally in a variety of combinations to implement customized data management on behalf of instrument science teams and other science investigators. Some of these subsystems (S4P and S4PM) have also been reused by other data centers for operational science processing. Our experience has been that development and utilization of robust interoperable and reusable software systems can actually flourish in environments defined by heterogeneous commodity hardware systems the emphasis on value-added customer service and the continual goal for achieving higher cost efficiencies. The repeated internal reuse that is fostered by such an environment encourages and even forces changes to the software that make it more reusable and adaptable. Allowing and even encouraging such selective pressures to software development has been a key factor In the success of S4P and S4PM which are now available to the open source community under the NASA Open source Agreement

Berrick, Stephen↗
NASA NTRS2017

The Joint Polar Satellite System (JPSS) Program's Algorithm Change Process (ACP): Past, Present and Future

The Joint Polar Satellite System (JPSS) Program Office is the supporting organization for the Suomi National Polar Orbiting Partnership (S-NPP) and JPSS-1 satellites. S-NPP carries the following sensors: VIIRS, CrIS, ATMS, OMPS, and CERES with instruments that ultimately produce over 25 data products that cover the Earths weather, oceans, and atmosphere. A team of scientists and engineers from all over the United States document, monitor and fix errors in operational software code or documentation with the algorithm change process (ACP) to ensure the success of the S-NPP and JPSS 1 missions by maintaining quality and accuracy of the data products the scientific community relies on. This poster will outline the programs algorithm change process (ACP), identify the various users and scientific applications of our operational data products and highlight changes that have been made to the ACP to accommodate operating system upgrades to the JPSS programs Interface Data Processing Segment (IDPS), so that the program is ready for the transition to the 2017 JPSS-1 satellite mission and beyond.

Joint Polar Satellite System↗
NASA NTRS2019

New Features in the SPOC Pipeline Release 4.0

The Science Processing Operations Center is in the process of testing and deploying Release 4.0 of the codebase in the March 2019 timeframe. This paper describes the new features of the software and their likely impact on the quality of the TESS science data products. The major goals of Release 4.0 are to improve the extraction of photometry from the pixels in light of the non-uniform pointing performance and the identification of instrumental signatures from the light curves. We also describe modifications to the FFI pipeline to allow the generation of FFI light curves, correction of the instrumental systematics therein, and planet searches, primarily for the purpose of validating the 2-min pipeline against the FFI pipeline, but also to be able to provide cotrending basis vectors (CBVs) derived directly from the FFIs to the public to aid them in their extraction and correction of photometry. We also discuss the improvements in photometric performance of the pipeline and its various components.The lapse in funding experienced between 22 December 2018 and 27 January 2019 significantly delayed our ability to conduct integration testing as planned for late December/early January, delaying the start of V&V by one month to the end of February 2019.The TESS Mission is funded by NASA's Science Mission Directorate as an Astrophysics Explorer Mission.The Science Processing Operations Center is in the process of testing and deplo!"ing Release 4.0 of thecodebase In the March 2019 tlmeframe. This paper describes the new features or the software and theirlikely impact on the quality of the TESS science data products. The major goals or Release 4.0 are to Imtheidentification of instrumental signatures from the light cuNes. We also describe modifications tothe FFI pipeline to allow the generation of FFI light curves, correction of the instrumental systematicstherein, and planet searches, primarily for the purpose of validating the 2-min pipelineagainst the FFI pipeline, but also to be able to provide cotrending basis vectors (C3Vs) ,,.~,.;.derived directly from the FFls to the public to aid them in their extractbn and correction , :-; ~'-'\'.'.of photometry. We also discuss the Improvements In photometric performance• of ~~\":;:•the pipeline and its various components. :,;.-.;The lapse In funding experienced between 22 December 2018 and 27January 2019 significantly delayed our ability to conduct Integrationtesting as planned for late December/early January, delaying thestart of V&V by one month to the end of February 2019.The TESS Mission is funded by NASA's Science Mission Directorateas an Astrophysics Explorer Mission.o.iu.c...,.....~~New Features in SPOC 4.01. Use of quatemions In photometry and centroiding.2. Use of quaternions to Identify high-motion cadences and exclude same.3. Use of the TPS detections to deemphasize pathological cadences ("skyline flattenlng"I.4. Improved CAL calculations for black and smear correction.5. PA brightness metric calculation improvements (induo'e crowding in calrulation)./ • 6. Improved POC spike goodness metric.•~• 7. Improved handling of gaps and momentum duni:>S in POC.8. Improved tuning of POC., 9. Improved attitude tweak correction in PDC.10. Improvements in PDC introduced noise and correlation goodness metrics11. Using the improved spike goodness metric to minimize overlitting in the spikeremover ' • :,''l./ 12. Enable FFI processing through planet search.,,. ,• • "« ,;,,,•.~'A , 13.1 D4.V S mtreinaim-relipnoinrgts d aartcah irveetrdie tvoa Ml aAnSdT p ersistence to database 15. Improved management of jobs on the NAS Pleiadss supercomputer

Jenkins, Jon M.↗
NASA NTRS2005

Encryption for Remote Control via Internet or Intranet

A data-communication protocol has been devised to enable secure, reliable remote control of processes and equipment via a collision-based network, while using minimal bandwidth and computation. The network could be the Internet or an intranet. Control is made secure by use of both a password and a dynamic key, which is sent transparently to a remote user by the controlled computer (that is, the computer, located at the site of the equipment or process to be controlled, that exerts direct control over the process). The protocol functions in the presence of network latency, overcomes errors caused by missed dynamic keys, and defeats attempts by unauthorized remote users to gain control. The protocol is not suitable for real-time control, but is well suited for applications in which control latencies up to about 0.5 second are acceptable. The encryption scheme involves the use of both a dynamic and a private key, without any additional overhead that would degrade performance. The dynamic key is embedded in the equipment- or process-monitor data packets sent out by the controlled computer: in other words, the dynamic key is a subset of the data in each such data packet. The controlled computer maintains a history of the last 3 to 5 data packets for use in decrypting incoming control commands. In addition, the controlled computer records a private key (password) that is given to the remote computer. The encrypted incoming command is permuted by both the dynamic and private key. A person who records the command data in a given packet for hostile purposes cannot use that packet after the public key expires (typically within 3 seconds). Even a person in possession of an unauthorized copy of the command/remote-display software cannot use that software in the absence of the password. The use of a dynamic key embedded in the outgoing data makes the central-processing unit overhead very small. The use of a National Instruments DataSocket(TradeMark) (or equivalent) protocol or the User Datagram Protocol makes it possible to obtain reasonably short response times: Typical response times in event-driven control, using packets sized .300 bytes, are <0.2 second for commands issued from locations anywhere on Earth. The protocol requires that control commands represent absolute values of controlled parameters (e.g., a specified temperature), as distinguished from changes in values of controlled parameters (e.g., a specified increment of temperature). Each command is issued three or more times to ensure delivery in crowded networks. The use of absolute-value commands prevents additional (redundant) commands from causing trouble. Because a remote controlling computer receives "talkback" in the form of data packets from the controlled computer, typically within a time interval < or =1 s, the controlling computer can re-issue a command if network failure has occurred. The controlled computer, the process or equipment that it controls, and any human operator(s) at the site of the controlled equipment or process should be equipped with safety measures to prevent damage to equipment or injury to humans. These features could be a combination of software, external hardware, and intervention by the human operator(s). The protocol is not fail-safe, but by adopting these safety measures as part of the protocol, one makes the protocol a robust means of controlling remote processes and equipment by use of typical office computers via intranets and/or the Internet.

Lineberger, Lewis↗
NASA NTRS2007

Imaging Sensor Flight and Test Equipment Software

The Lightning Imaging Sensor (LIS) is one of the components onboard the Tropical Rainfall Measuring Mission (TRMM) satellite, and was designed to detect and locate lightning over the tropics. The LIS flight code was developed to run on a single onboard digital signal processor, and has operated the LIS instrument since 1997 when the TRMM satellite was launched. The software provides controller functions to the LIS Real-Time Event Processor (RTEP) and onboard heaters, collects the lightning event data from the RTEP, compresses and formats the data for downlink to the satellite, collects housekeeping data and formats the data for downlink to the satellite, provides command processing and interface to the spacecraft communications and data bus, and provides watchdog functions for error detection. The Special Test Equipment (STE) software was designed to operate specific test equipment used to support the LIS hardware through development, calibration, qualification, and integration with the TRMM spacecraft. The STE software provides the capability to control instrument activation, commanding (including both data formatting and user interfacing), data collection, decompression, and display and image simulation. The LIS STE code was developed for the DOS operating system in the C programming language. Because of the many unique data formats implemented by the flight instrument, the STE software was required to comprehend the same formats, and translate them for the test operator. The hardware interfaces to the LIS instrument using both commercial and custom computer boards, requiring that the STE code integrate this variety into a working system. In addition, the requirement to provide RTEP test capability dictated the need to provide simulations of background image data with short-duration lightning transients superimposed. This led to the development of unique code used to control the location, intensity, and variation above background for simulated lightning strikes at user-selected locations.

Freestone, Kathleen↗
NASA NTRS1998

The Software Design for the Wide-Field Infrared Explorer Attitude Control System

The Wide-Field Infrared Explorer (WIRE), currently scheduled for launch in September 1998, is the fifth of five spacecraft in the NASA/Goddard Small Explorer (SMEX) series. This paper presents the design of WIRE's Attitude Control System flight software (ACS FSW). WIRE is a momentum-biased, three-axis stabilized stellar pointer which provides high-accuracy pointing and autonomous acquisition for eight to ten stellar targets per orbit. WIRE's short mission life and limited cryogen supply motivate requirements for Sun and Earth avoidance constraints which are designed to prevent catastrophic instrument damage and to minimize the heat load on the cryostat. The FSW implements autonomous fault detection and handling (FDH) to enforce these instrument constraints and to perform several other checks which insure the safety of the spacecraft. The ACS FSW implements modules for sensor data processing, attitude determination, attitude control, guide star acquisition, actuator command generation, command/telemetry processing, and FDH. These software components are integrated with a hierarchical control mode managing module that dictates which software components are currently active. The lowest mode in the hierarchy is the 'safest' one, in the sense that it utilizes a minimal complement of sensors and actuators to keep the spacecraft in a stable configuration (power and pointing constraints are maintained). As higher modes in the hierarchy are achieved, the various software functions are activated by the mode manager, and an increasing level of attitude control accuracy is provided. If FDH detects a constraint violation or other anomaly, it triggers a safing transition to a lower control mode. The WIRE ACS FSW satisfies all target acquisition and pointing accuracy requirements, enforces all pointing constraints, provides the ground with a simple means for reconfiguring the system via table load, and meets all the demands of its real-time embedded environment (16 MHz Intel 80386 processor with 80387 coprocessor running under the VRTX operating system). The mode manager organizes and controls all the software modules used to accomplish these goals, and in particular, the FDH module is tightly coupled with the mode manager.

Anderson, Mark O.↗
DOE OSTI2022

Reimagining Codesign for Advanced Scientific Computing: Report for the ASCR Workshop on Reimagining Codesign

In March 2021, the U.S. Department of Energy’s Advanced Scientific Computing Research program convened the Workshop on Reimagining Codesign. The workshop, also known as ReCoDe, was organized around discussions on eight topic areas: (1) codesign for traditional high-performance computing workloads; (2) codesign of memory/storage systems; (3) codesign of machine learning, neuromorphic, quantum, and other non-von Neumann accelerators; (4) codesign for edge computing and processing at experimental instruments; (5) codesign for security and privacy; (6) hardware design tools and open-source hardware for high-productivity codesign; (7) tools, software stack, and programming languages for high-productivity codesign; and (8) quantitative tools and data collection for modeling and simulation for codesign. The panels identified four Priority Research Directions from these deliberations: (1) breakthrough computing capabilities with targeted heterogeneity and rapid design; (2) software and applications that embrace radical architecture diversity; (3) engineered security and integrity, from transistors to applications; and (4) design with data-rich processes.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2012

The Algorithm Theoretical Basis Document for Level 1A Processing

The first process of the Geoscience Laser Altimeter System (GLAS) Science Algorithm Software converts the Level 0 data into the Level 1A Data Products. The Level 1A Data Products are the time ordered instrument data converted from counts to engineering units. This document defines the equations that convert the raw instrument data into engineering units. Required scale factors, bias values, and coefficients are defined in this document. Additionally, required quality assurance and browse products are defined in this document.

Jester, Peggy L.↗
NASA NTRS2019

Analysis of Mercury Laser Altimeter Crossovers with Improved Mercury and MESSENGER Ephemerides

Based on previous applications of laser altimetry to planetary geodesy at GSFC [Mazarico et al. (2014),(2016)] and taking advantage of new accurate Mercury and MESSENGER orbits by [Genova et al. (2019)], we analyze altimetric crossovers from the MESSENGER (Mercury Surface, Space Environment, Geochemistry and Ranging) Laser Altimeter (MLA) to solve for orbital and geodetic parameters (e.g., rotation and orientation). We present our results based on a new Python software package recently developed at GSFC that can simulate and process altimetry data in a closed-loop. Realistic simulations of MLA data, including an appropriate range noise from the instrument and realistic terrain roughness, are performed in order to fully characterize the robustness of the solution. The simulation results are then applied to our analysis of the full dataset acquired by the MLA instrument.

Bertone, Stefano↗