Search NASA⌕ Search

SEARCH · Search NASA

Results for “linux”

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 235 records · Page 13

NASA and Blue Origin’s Flight Assessment of Precision Landing Algorithms Computing Performance

NASA’s Safe and Precise Landing - Integrated Capabilities Evolution (SPLICE) project continues NASA’s work in the development and testing of technologies for Precision Landing and Hazard Avoidance (PL&HA). This paper presents results characterizing how SPLICE flight software utilizes the shared computing resources of the Descent Landing Computer (DLC), one of the PL&HA technologies under development. The SPLICE technologies are being tested as an integrated payload on Blue Origin’s New Shephard suborbital vehicle. The results presented in this paper are measured by applications running in and with the flight software both in flight, and in a high-fidelity Hardware-in-the-Loop (HWIL) simulation environment. Linux utilities to measure performance are also executed from the command line in the HWIL configuration. Performance measurements of the SPLICE workloads executing on the DLC provide insight on how efficiently the software is utilizing the DLC resources. Examples of how these measurements have guided improvements in the flight code are presented. In addition, the DLC uses a commercial processor as a surrogate for NASA’s High Performance Spaceflight Computing (HPSC) processor. This work provides insight on how an HPSC system may perform delivering PL&HA capabilities on a future mission. The measurements also can be used to infer architectural requirements for PL&HA capabilities, informing the HPSC project and other flight computer development efforts. Examples of the measurements collected include processor utilization, I/O bandwidth, cache and branch misses, and application profiles.

Precision Landing and Hazard Avoidance↗

NASA and Blue Origin’s Flight Assessment of Precision Landing Algorithms Computing Performance

NASA’s Safe and Precise Landing - Integrated Capabilities Evolution (SPLICE) project continues NASA’s work in the development and testing of technologies for Precision Landing and Hazard Avoidance (PL&HA). This paper presents results characterizing how SPLICE flight software utilizes the shared computing resources of the Descent Landing Computer (DLC), one of the PL&HA technologies under development. The SPLICE technologies are being tested as an integrated payload on Blue Origin’s New Shepard suborbital vehicle. The results presented in this paper are measured by applications running in and with the flight software both in flight, and in a high-fidelity Hardware-in-the-Loop (HWIL) simulation environment. Linux utilities to measure performance are also executed from the command line in the HWIL configuration. Performance measurements of the SPLICE workloads executing on the DLC provide insight on how efficiently the software is utilizing the DLC resources. Examples of how these measurements have guided improvements in the flight code are presented. In addition, the DLC uses a commercial processor as a surrogate for NASA’s High-Performance Spaceflight Computing (HPSC) processor. This work provides insight on how an HPSC system may perform delivering PL&HA capabilities on a future mission. The measurements also can be used to infer architectural requirements for PL&HA capabilities, informing the HPSC project and other flight computer development efforts. Examples of the measurements collected include processor utilization, I/O bandwidth, cache and branch misses, and application profiles.

Precision Landing↗

Rapid Spacecraft Payload Development: In-Orbit Demonstration of Flight Software Reuse, Scalability, and Dependability

As space mission design trends towards shared, multi-mission platforms and high-performance onboard computing architectures, the number of spacecraft launched into operation is also steadily rising. Through ridesharing, spacecraft miniaturization, and other cost-reduction measures, the barriers to space are lowering, resulting in compounded growth in the amount of flight software being deployed. To meet the needs of both the growing quantity and evolving nature of spacecraft, flight software design must accordingly adapt to support more efficient development, solutions to computational resource-sharing, and software reusability. This paper focuses on a software payload demonstrating several core technologies that improve the state-of-the-art in these identified areas. Launched into low-earth orbit in January 2022, our software payload was conceived, designed, and delivered in a span of merely two months. It was developed on top of the NASA core Flight System (cFS) framework and the Distributed Spacecraft Autonomy (DSA) Comm cFS application, which translates cFS software bus messages across a Data Distribution Service (DDS) network. The flight software, packaged in Linux container images, was deployed as one of 18 flight applications managed through the Unibap SpaceCloud Framework. The applications were run on a Unibap iX5-102 radiation-tolerant payload computer, hosted on the D-Orbit SCV-004 spacecraft as part of an ESA-sponsored in-orbit technology test. Our payload, referred to as the DSA D-Orbit software, demonstrates the reusability of the DSA Comm app in a substantially different context and purpose as its original mission. Comm’s original design goal was to reliably distribute messages between spacecraft swarms of arbitrary size and dynamic network topology. However, we leverage this same functionality to introduce redundancy and opportunistic parallel data processing in the context of a representative onboard image processing workload. This adaptive mission architecture was enabled in part by the SpaceCloud Framework’s use of container virtualization as the payload integration interface. By using a base container image with common high-level language runtimes and libraries, we were able to rapidly design, develop, and validate our image processing application without many of the technological barriers common to flight software development. We present details the goals, approach, results, and lessons learned through this technology demonstration experiment and contextualize those observations against present and future challenges in spacecraft software development.

computer programming↗

Flight Software for the LOFTID Re-Entry Vehicle

NASA’s Low-Earth Orbit Flight Test of an Inflatable Decelerator, or LOFTID, demonstrated re-entry from low-Earth orbit of a 6-meter aeroshell designed to be used as a heat shield that is larger than the rocket shroud, enabling the return of much greater mass. The LOFTID Flight Software was developed in-house and consists of three components: the Power Distribution software, the Data Recorder software, and the Camera Controller software, along with the Ground Software used for testing, operations, data integrity, and data processing. This presentation will discuss issues found in developing the Power Distribution software in cFS on a non-Linux POSIX platform, designing an efficient architecture for recording of high bandwidth data, controlling over a dozen cameras in-flight, and creating the ground support tools to verify data integrity and support the post-processing of flight data.

Paul Brewster↗

Benchmarking Planning Applications on the Qualcomm Snapdragon

We benchmark several space planning/scheduling applications on the Qualcomm Snapdragon 855 Handheld Development Kit (HDK), a high performance embedded processor used in many mobile phones.We are flying 2 Snapdragon HDKs onboard the International Space Station (ISS) where they are hosted by the the Spaceborne Computer-2 by Hewlett Packard Enterprise linked by USB and 12V power delivery. We run computational benchmarks using three planner/ schedulers that are used for several space missions: Multi- Mission Executive (MEXEC), Compressed Large-scale Activity Scheduling and Planning (CLASP), and M2020 Ground Scheduler (Surrogate). We compare the Snapdragon performance to a performance baseline on Linux workstations. In addition, we are currently working on benchmarking the same applications on other space flight processors, such as the LEON4 Processor on the Sabertooth card, the LEON3 Processor on the Sphinx card, and the RAD750 processor.

Chien, Steve↗

Testing Mars 2020 Flight Software and Hardware in the Surface System Development Environment

The Mars 2020 (M2020) Perseverance Rover is NASA's most advanced planetary rover mission to date. It includes a novel Sample Caching Subsystem (SCS) which will collect rock cores for possible future return to Earth, as well as an improved mobility system with enhanced autonomous navigation which will enable it to traverse faster and farther than prior rovers. The development of both systems required extensive flight software and flight hardware testing. To support this testing, we developed the Surface System Development Environment (SSDEV) and used it for a wide variety of testing. SSDEV is a bundled subset of M2020 Flight Software which runs on commercially available Linux computers and can be combined with multiple backend options for simulation and hardware control. The SSDEV architecture enabled our teams to perform much more testing of flight software and flight hardware than would have otherwise been possible. As a secondary benefit, the SSDEV-based test campaigns also helped our teams enter the operations phase of the mission with greater readiness of operations products and tools. In this paper, we summarize the motivation for SSDEV, provide an overview of the SSDEV architecture, list several examples of how SSDEV was used, and summarize lessons learned. SSDEV is not a substitute for integrated testing with flight-like avionics, but it enabled substantially more testing than would have otherwise been possible and also provided some unique benefits. We recommend architectures like SSDEV to future projects that need to perform extensive hardware and software testing using a limited set of flight-like avionics.

Wai, Dennis↗

Innovative Features of NASA's Celestial Mapping System to Support Exploration in the Lunar South Pole

Introduction: NASA's Celestial Mapping System (CMS) is developed to address the need for 3D tools for planetary science investigations, mission planning, in-situ operations, in a 3D-first design constructed around a unified view of a planetary globe. At present CMS provides many critical functionalities that include 1) Equipment planning and optimized placement on Lunar surface 2) Line of sight (visibility ) analysis 3) Powerful measurement tools based on 3D terrain with realistic 3D models to represent rovers, astronauts and equipment 4) Visualization of de-rived mapping products (e.g. resource maps), and 5) Data engine for hosting new observations that are not available in other contemporary lunar data tools. CMS is built on the foundation of powerful NASA WorldWind globe engines. In near future, users will be able to simultaneously deploy CMS onto multiple hardware configurations and platforms such as Windows, Linux, iOS and Android. The users will also have the flexibility to update to the latest imagery and terrain datasets as they are being acquired (in real time) before and/or during the exploration mission. CMS is also capable of consumption and analysis of data from locally hosted and external sources. It supports Open Geospatial Consorti-um (OGC) data and file standards, with current integrations of datasets from the Astrogeology Science Center of USGS which include global and local data acquired from NASA (LRO, Clementine, Lunar Orbiter) and JAXA (SELENE/Kaguya) with the capability of integrating more datasets. With development experience in both the end-user application and planetary engine side, CMS is also able to adapt to newer Lunar cartography standards as they develop and become recognized by international geospatial panels. Overcoming Polar Distortions: 3D geospatial applications traditionally suffer from significant distortion of imagery at the poles due to following reasons – 1) distortions in the source imagery 2) Incompatible tessellation algorithm on the poles 3) map projections. In the lunar context, with the focus on the South pole, this is not acceptable. The CMS team is researching ways to address polar distortion of imagery with new tessellation algorithms and by reprojecting the data using projections that are more accurate in polar scenarios. Figure1 shows the potential error introduced by different tessellation methods, represented by the red and green circles for Shoemaker crater. There is ~2 Km difference in the placement of the crater. Line of Sight Analysis and Traverse Planning: We have developed a built-in line of sight analysis (LOS) tool in CMS that analyzes the terrain profile and obstructions and provides the visibility of a given terrain for a remote observer. Figure 2 shows the viewshed analysis on the PSR in Nobile region. The PSR was created with help of HORUS generated images. The yellow pin shows the observer location outside the PSR. The yellow area shows the visible part of PSR. The obstructed area with no visibility for the observer is shown in red. This analysis was ex-tended further to set different heights for various observers and then perform the viewshed analysis. Combining the different visibility profiles can help designing improved traverses within the crater.

Geospatial Mapping↗

Innovative Features of NASA's Celestial Mapping System to Support Exploration in the Lunar South Pole

Introduction: NASA's Celestial Mapping System (CMS) is developed to address the need for 3D tools for planetary science investigations, mission planning, in-situ operations, in a 3D-first design constructed around a unified view of a planetary globe. At present CMS provides many critical functionalities that include 1) Equipment planning and optimized placement on Lunar surface 2) Line of sight (visibility ) analysis 3) Powerful measurement tools based on 3D terrain with realistic 3D models to represent rovers, astronauts and equipment 4) Visualization of de-rived mapping products (e.g. resource maps), and 5) Data engine for hosting new observations that are not available in other contemporary lunar data tools. CMS is built on the foundation of powerful NASA WorldWind globe engines. In near future, users will be able to simultaneously deploy CMS onto multiple hardware configurations and platforms such as Windows, Linux, iOS and Android. The users will also have the flexibility to update to the latest imagery and terrain datasets as they are being acquired (in real time) before and/or during the exploration mission. CMS is also capable of consumption and analysis of data from locally hosted and external sources. It supports Open Geospatial Consorti-um (OGC) data and file standards, with current integrations of datasets from the Astrogeology Science Center of USGS which include global and local data acquired from NASA (LRO, Clementine, Lunar Orbiter) and JAXA (SELENE/Kaguya) with the capability of integrating more datasets. With development experience in both the end-user application and planetary engine side, CMS is also able to adapt to newer Lunar cartography standards as they develop and become recognized by international geospatial panels. Overcoming Polar Distortions: 3D geospatial applications traditionally suffer from significant distortion of imagery at the poles due to following reasons – 1) distortions in the source imagery 2) Incompatible tessellation algorithm on the poles 3) map projections. In the lunar context, with the focus on the South pole, this is not acceptable. The CMS team is researching ways to address polar distortion of imagery with new tessellation algorithms and by reprojecting the data using projections that are more accurate in polar scenarios. Figure1 shows the potential error introduced by different tessellation methods, represented by the red and green circles for Shoemaker crater. There is ~2 Km difference in the placement of the crater. Line of Sight Analysis and Traverse Planning: We have developed a built-in line of sight analysis (LOS) tool in CMS that analyzes the terrain profile and obstructions and provides the visibility of a given terrain for a remote observer. Figure 2 shows the viewshed analysis on the PSR in Nobile region. The PSR was created with help of HORUS generated images. The yellow pin shows the observer location outside the PSR. The yellow area shows the visible part of PSR. The obstructed area with no visibility for the observer is shown in red. This analysis was ex-tended further to set different heights for various observers and then perform the viewshed analysis. Combining the different visibility profiles can help designing improved traverses within the crater.

Geospatial Mapping↗

Autonomous Ocean World Exploration: Advancement of a Virtual Testbed

The search for life (extinct or extant) and potentially habitable bodies in our solar system and beyond is one of the 12 priority science questions outlined in the National Acadamies’ 2022 decadal survey [5]. Extraterrestrial destinations containing liquid water present an opportunity to search for life as we know it, and in recent years an increasing number of such locations have been discovered within our solar system. Several Jovian moons—Europa, Ganymede, and Callisto [10]—and the Saturnian moons Enceladus [8] and Titan [9] are known or suspected to harbor massive subsurface oceans. Of these "ocean worlds", Europa is the focus of at least one planned NASA orbiter mission, Europa Clipper [4], and an early lander mission concept, the Europa Lander [2, 3]. Whereas most robotic missions to the Moon and Mars (e.g. orbiters, rovers, landers) to date have had ground controllers on Earth tightly involved in mission operations, missions to more distant worlds will require a high degree of onboard autonomy due to long communication lags and blackouts, harsh environments (radiation, cold), and more limited battery and hardware life. The past decade has seen great advances in both AI technologies and computing scalability and performance that offer promising solutions for spacecraft autonomy and motivate the software system and research programs described in this paper. The Ocean Worlds Autonomy Testbed for Exploration, Research, and Simulation (OceanWATERS) [1], which has been in development at the NASA Ames Research Center since 2018, is a virtual environment for testing lander autonomy solutions. It is built on the Robot Operating System (ROS), runs on consumer-grade Linux workstations, and was released as open source in 2020. OceanWATERS provides a physical and visual simulation of a prototypical lander in a Europa-like environment (Figure 1). The lander was modeled after requirements and specifications made in JPL’s Europa Lander Study of 2016 [3]. Simulated lander systems include stereo cameras and spotlights mounted on an antenna mast that pans and tilts, a 6 degrees of freedom (DoF) robotic arm with a force-torque sensor and two interchangeable end effectors, and a battery pack power system. The environment consists of multiple terrain models including a highly detailed model sourced from the FROST dataset [11], simulation of surrounding planetary bodies based on an ephemeris model, and lighting from the sun with associated surface illumination, reflectance, and shadows. Operations supported by OceanWATERS include panoramic and directed imaging of the environment and lander workspace, Cartesian and joint-level arm commanding, grinding of the terrain surface (e.g. digging a trench), and scooping of ground material (Figure 2) which can be discarded or collected as science samples in a receptacle that can be emptied (science operations themselves are not simulated). These operations are realized as ROS Actions and are complimented by a wide selection of telemetry that is continually produced by each lander subsystem. The power system model is driven by the open-source Generic Software Architecture for Prognostics (GSAP) [11] that predicts the battery’s remaining useful life and other characteristics. As a testbed for high-level autonomy, OceanWATERS provides an execution framework based on PLEXIL [12], an open-source plan specification language and execution engine developed largely at Ames. NASA's initial development of OceanWATERS, as well the Ocean Worlds Lander Autonomy Testbed (OWLAT) [6], a complimentary physical testbed developed at JPL, was the first step in a plan for realizing candidate onboard autonomy solutions for such planetary landers. In 2020 NASA solicited applications for its Autonomous Robotics Research for Ocean Worlds (ARROW) program, and in 2021 the similar Concepts for Ocean worlds Life Detection Technology (COLDTech) program. Collectively six research teams, based in universities and companies across the United States, were awarded grants to develop and demonstrate autonomy solutions on OceanWATERS and OWLAT. These 1–2-year projects have now finished or are nearing completion, and a wide variety of autonomy challenges in ocean world surface missions were addressed. Prototyped and demonstrated solutions have included autonomous discovery, response and adaptation to system faults and unexpected environmental events, world model synthesis through perception, plan synthesis using learned models, methods to optimize sample target selection and prioritize science data transmission, extension of PLEXIL for stochastic decision-making, and an integration of a model of JPL’s mission-ready COLDArm [7]. Technologies used in these projects include many forms of machine learning, causal reasoning, automated planning, Markov decision processes, formal methods, and other advanced techniques. A more detailed summary of the ARROW and COLDTech projects is given herein. OceanWATERS has had significant enhancements since its open-source release in 2020. Many of its new features were driven or shaped by feedback from the ARROW and COLDTech teams and requirements of their projects. In support of enabling autonomous adaptation to spacecraft faults (a specific capability solicited by both programs), a fault injection and detection framework was developed that supports a wide and growing range of fault types such as locked joints, image loss, and battery failures. The power system model was completed and integrated into the simulator, starting as a single-cell battery model and later upgraded to a multi-cell model with associated faults such as cell disconnection. Arm/terrain interaction was improved by adding a force-torque sensor and associated faults, and an analytic dig force model based on the Balovnev bucket force equations. Environment fidelity was increased by modeling terrain deformation resulting from digging and scooping; visual improvements were made in textures, lighting, and shadows. To facilitate interoperation with OWLAT, a unified command and telemetry interface between the testbeds was developed at the ROS level, along with a PLEXIL interface. The number of lander operations was greatly expanded (e.g. with Cartesian-based arm and antenna movement), and a framework was designed for users to build their own lander actions. A GUI for PLEXIL plan selection was created (Figure 3), and an expansive set of plans were added, such as those that illustrate patterns for fault handling. This paper provides a self-contained high-level description of OceanWATERS, focusing on more detailed coverage of the aforementioned enhancements. It provides a high-level summary of the projects undertaken by participants in the ARROW and COLDTech programs and how these efforts have helped shape OceanWATERS. Finally, potential future work and directions for the testbed are listed, as likely informed by the recent planetary science decadal survey [5].

K Michael Dalal↗

FRAAME Version 1.0 User Manual

The code for Forced Response Aeromechanics Analysis in a MATLAB-based (The MathWorks, Inc.) Environment (FRAAME Version 1.0) was developed for internal use in aeromechanics efforts undertaken at the NASA Glenn Research Center for computing turbomachine component forced response and Goodman diagrams via modal summation method. The main working script (FRAAMEv1.m) allows users to input case-specific manual inputs while the triple-nested loop invokes functions to compute forced response per blade, per nodal diameter, and per mode. Secondly, forced response values are applied to modal stresses to compute complex Von Mises stress values and generate Goodman diagrams per blade, per nodal diameter, and per mode using a linear modal summation method. Currently, this code functions in the Windows (Microsoft Corporation) operating system using MATLAB Version R2023a, but it can be adapted for use in the Linux (Linus Torvalds) operating system by changing the appropriate file path structure in the main script, as well as functions that call external results files.

Aeromechanics↗

3D Scanning System to Assess Gravity-Dependent Body Shape Changes

The human body shows unique morphological changes when exposed to different gravity conditions, including muscle atrophy, fluid shift, and spinal elongation. Such changes need to be incorporated for human-system integration in the vehicle habitat, garment, and spacesuit designs, as inaccurate body measurements can result in suboptimal crew protection that can potentially decrease injury tolerance. However, measurement tools have not been available for accurate assessments of body shape changes. This work aimed to develop a prototype 3-D body scanning system with the configuration and performance optimized for in-flight crewmember body scanning. A scan hardware system was developed using Intel RealSense commercial off-the-shelf 3D sensors. The sensor parameters were iteratively optimized and tested to obtain the performance level needed for body scanning. A scan booth structure was fabricated, with the overall size 4 x 4 x 8 feet. The specific number of sensors and mounting positions were determined by iterative simulations, which indicated that 16 cameras can capture 94% and 96% of body surface area from the 1st percentile female and 99th percentile male crew population subject. The mounted sensors were linked through a mix of USB-C and USB-3 cables and operated for data acquisition from a Linux laptop computer. A software prototype was developed using Python and Tkinter graphical user interface toolkit. A calibration procedure was also built using a panel of QR codes. A computer vision tool detected and decoded the unique ID and pattern locations of the QR codes. The calibration information determined the position and orientation of the 3D sensors with respect to each other. The scanner performance was assessed using a set of 3D printed custom manikins. The manikin size and shape were derived from the previous ISS study, which measured the crewmembers’ anthropometry changes across the different flight phases. The average anthropometric measurements at the pre-flight and flight day 15 were sampled and projected onto the 1st percentile female and 99th percentile male body shapes. Another pair of manikins were also 3D printed to simulate the neutral body posture, estimated from ISS microgravity environments. A preliminary analysis assessed the performance of the newly developed scanner against the reference scanner, which has been used at the NASA JSC for crew and test subject anthropometry. Although the new scanner data showed several artifacts and missing geometries in the occluded body areas such as armpits and crotch, overall shape matched with the reference scan. When the manikin surface coordinates were compared, a root mean square error of 1.3 cm was observed from the manikin torso segment. Linear measurements including the stature, knee height and circumference measurements at the chest and calf showed differences from the reference scan measurements, ranging between 0.3 and 0.9 cm. Overall, this work demonstrated a development framework for an in-flight scanner with design and operation optimized for crewmember body scanning. Further improvement can potentially provide previously unavailable anthropometric data from different gravitational environments, including 0-g, 1/6-g, and 1-g. Such data can improve suit fit, habitat design, exercise efficacy quantification and sizing of orthostatic intolerance garments.

K H Kim↗

SULI Project Report: Mu2e otsdaq Documentation and Analytics

This report outlines the history of the CLFV puzzle, gives an overview of the Mu2e Experiment, and details the results of the DOE (Department of Energy)-funded SULI (Science Undergraduate Laboratory Internship) research completed over the summer 2024 on site at Fermilab. The project focused on the otsdaq software responsible for data acquisition. The project included drafting updated documentation for new users, including new procedures relevant for the Alma- Linux 9 operating system update, and the UPS package managing system replacement with Spack (scientific software package manager). A new art module (ReadTriggerCounts) to track trigger rates was created, with compatibility to be displayed via a Grafana server. The author also assisted in calorimeter cable installation in the detector hall.

Saarinen, Talia↗

Forensic Analysis of SOHO Router Binaries

Small Office/Home Office (SOHO) routers are used by millions of consumers across the United States, and are commensurately vulnerable. Forensic analysis of SOHO router firmware helps to understand and mitigate those vulnerabilities. This poster focused particularly on analysis of BusyBox executables, a software suite that provides several Unix utilities in a single file. Three main tools were used to analyze the binaries. BinWalk was used to extract the files, but also to build entropy graphs, extract Linux kernel images, and identify CPU architectures; WiiBin processed the binaries to find endianness, architecture, the percent compressed/encrypted, and compiler data; and @DisCo, a machine learning tool used to determine function similarity in disassembled binaries, analyzed similarities and determined versions of extracted BusyBox files from each router. These tools found that venders from all five routers utilized the same version of the BusyBox software across different firmware updates, demonstrating the importance of constant firmware scrutiny to protect against security vulnerabilities.

24 POWER TRANSMISSION AND DISTRIBUTION↗

A Single-Board Fermilab Timing Pipeline on the Xilinx KR260: Decode, Timestamp, Publish, Mirror

Full-width abstract \renewcommand{\maketitlehookd}{% \begin{abstract} \noindent Fermilab's accelerator timing links broadcast short event codes to thousands of devices at once, but the links themselves carry no absolute notion of time; that comes separately from a White Rabbit reference. This work builds the piece that ties the two together on a single board. On a Xilinx Kria KR260 (Zynq UltraScale+), the programmable logic decodes a real Fermilab TCLK link, stamps every event with an absolute White-Rabbit \{sec, ns\} UTC time, and reads the timestamped stream out over AXI4-Lite; a thin Linux process on the same die publishes each event into a Redis stream on the control network. To exercise the full chain on one board, the decoded events are re-encoded as gigabit ACLK, transmitted out an SFP+ optical port, looped back over a short fiber jumper, and decoded again on the same timeline, and are additionally mirrored as an ACLK-Lite Manchester waveform for benchtop probing. Across sustained, multi-day testing against real Fermilab TCLK, the pipeline has decoded, timestamped, and published hundreds of millions of events with practically zero loss, and folding the timestamped stream on the 60-second accelerator supercycle recovers the machine's periodic structure directly from the published data.

Rossel, Jacob [UC, Berkeley; Fermilab] (ORCID:0009↗

Graphical User Interface for a Biasing Board for the PSEC6

The PSEC6 is an application-specific integrated circuit (ASIC) designed for a readout system for a large area picosecond photodetector (LAPPD). The PSEC6 is currently in fabrication and pending testing. The testing system for the PSEC5, the previous iteration of the ASIC, required expensive and non-portable equipment, because the ASIC needs twelve adjustable reference voltages. The new testing system consists of an low-cost, open-source, cross-platform graphical user interface (GUI), a digital system, and a biasing board. The digital system is the interface between the GUI and biasing board, and can be implemented on a microcontroller or field-programmable gate array (FPGA). The biasing board contains twelve digital-to-analog converters (DACs) that are configurable via the GUI, which gives users the ability to write voltage values to all or specific DACs. The GUI was developed in C on Linux using the widget library GTK4 and cross-compiled for Windows compatibility. I2C and SPI protocols were implemented on an Adafruit Feather ESP32-S3 microcontroller to write commands to the DACs and PSEC6. A hardware implementation of the I2C protocol is in development on an FPGA. Since LAPPDs will be used by the Accelerator Neutrino Neutron Interaction Experiment (ANNIE) at Fermilab, the PSEC6 testing system in this internship project can potentially benefit future neutrino research. The project is relevant to the Department of Energy’s microelectronics mission, because the PSEC6 is an ASIC that will handle fast time signals arriving from the detector for readout. It also provided experience with building a cross-platform user interface, practicing digital design and implementation in hardware description language (HDL), and using simulations to inform new design iterations.

Guerrero, Sasha Camila [North Central Coll.]↗

System Administrator for LCS Development Sets

The Spaceport Command and Control System Project is creating a Checkout and Control System that will eventually launch the next generation of vehicles from Kennedy Space Center. KSC has a large set of Development and Operational equipment already deployed in several facilities, including the Launch Control Center, which requires support. The position of System Administrator will complete tasks across multiple platforms (Linux/Windows), many of them virtual. The Hardware Branch of the Control and Data Systems Division at the Kennedy Space Center uses system administrators for a variety of tasks. The position of system administrator comes with many responsibilities which include maintaining computer systems, repair or set up hardware, install software, create backups and recover drive images are a sample of jobs which one must complete. Other duties may include working with clients in person or over the phone and resolving their computer system needs. Training is a major part of learning how an organization functions and operates. Taking that into consideration, NASA is no exception. Training on how to better protect the NASA computer infrastructure will be a topic to learn, followed by NASA work polices. Attending meetings and discussing progress will be expected. A system administrator will have an account with root access. Root access gives a user full access to a computer system and or network. System admins can remove critical system files and recover files using a tape backup. Problem solving will be an important skill to develop in order to complete the many tasks.

Virtualizing in Linux↗

Detecting and Characterizing Semantic Inconsistencies in Ported Code

Adding similar features and bug fixes often requires porting program patches from reference implementations and adapting them to target implementations. Porting errors may result from faulty adaptations or inconsistent updates. This paper investigates (1) the types of porting errors found in practice, and (2) how to detect and characterize potential porting errors. Analyzing version histories, we define five categories of porting errors, including incorrect control- and data-flow, code redundancy, inconsistent identifier renamings, etc. Leveraging this categorization, we design a static control- and data-dependence analysis technique, SPA, to detect and characterize porting inconsistencies. Our evaluation on code from four open-source projects shows that SPA can detect porting inconsistencies with 65% to 73% precision and 90% recall, and identify inconsistency types with 58% to 63% precision and 92% to 100% recall. In a comparison with two existing error detection tools, SPA improves precision by 14 to 17 percentage points.

Semantic Errors↗

LaRC SmartLab Apps For Instrument Control and Data Processing: Laboratory Environment Monitor

The LaRC SmartLab applications are a series of software tools to greatly enhance researcher efficiency by streamlining and automating workflows. Python scripts and applications are increasingly being used in scientific workflows, including for instrument control and data processing. Interactive Python scripting environments such as JupyterLab provide powerful tools for using Python. In some use cases, the development of standalone applications with dedicated graphical user interfaces can enhance the utility of the code and open it up to more users, including non-programmers. Here, we describe a Python based application for communicating with, and displaying data from, iTHX Temperature, Humidity, and Dew Point probes. We discuss the set up and use of the application as well as its implementation. We also highlight the use of Simulated probes to enable users and developers to familiarize with or debug the application, even when they do not have access to the physical hardware in the laboratory.

LaRC SmartLab↗