Search NASA⌕ Search

SEARCH · Search NASA

Results for “open source hardware”

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 55 records · Page 3

Nuclear Thermal Rocket Emulator for a Hardware-in-the-Loop Test Bed

To support NASA’s mission to use nuclear thermal rockets for future Mars missions, an instrumentation and control test bed has been built at Oak Ridge National Laboratory. The system is designed as a hardware-in-the-loop test bed for testing control elements and autonomous control algorithms for nuclear thermal propulsion rockets. The mock reactor system consists of a modular and scalable framework, using inexpensive components and open-source software. The hardware system consists of a two-phase flow loop and a mock reactor with six control drums. A single-board computer (NVIDIA Jetson) handles reactor core emulation and hosts a message queuing telemetry transport broker that allows user-deployed control algorithms to interact with the system hardware. The reactor emulator receives sensor data from the hardware and provides the simulated performance of the reactor under steady-state, transient, and fault conditions. The emulator uses a reactivity lookup table and the point kinetics equations to solve for the reactor dynamics in real time. Emulated reactor dynamics and sensor input inform the autonomous control algorithm’s decision-making in a closed-loop manner. The current system is capable of operating at 10 Hz, but faster cycle rates are an area of ongoing research. This test bed will enable NASA and other space vendors to rigorously test their autonomous control systems for NTP rockets under transient (reactor startup and shutdown), steady-state, and fault conditions to reduce development time and risk for autonomous control systems in future missions.

autonomous control↗

Tutorial: Machine-Learning-Based CREASE-2D Analysis of 2D SAXS Profiles to Characterize Anisotropic Nanostructures in Soft Materials

We present a tutorial to guide users on how to extend the Computational Reverse Engineering Analysis of Scattering Experiments-2D (CREASE-2D) framework to interpret their experimental two-dimensional small-angle scattering (SAS) data from soft materials (e.g., polymers, peptide amphiphiles, biomolecular fibrils). Unlike most traditional SAS analysis approaches, which typically rely on azimuthally averaged onedimensional (1D) profiles, CREASE-2D utilizes the complete 2D scattering profile to reveal information about anisotropy in the structure. In past applications, CREASE has provided insights into complex structural features, including the cross-sectional shapes of assembled nanostructures and dispersity in these features, which are difficult to discern with existing analytical models. While (1D- ) CREASE has been applied to SANS and SAXS data, this tutorial shares the steps for implementing CREASE-2D using an example of a dipeptide solution system, for which we have SAXS data. We present details for these steps involved in using CREASE-2D to interpret SAXS profiles: how to preprocess SAXS data, define relevant structural features, generate three-dimensional real-space structures for specific values of these features, train a machine learning (ML) surrogate model to predict scattering profiles for given structural features, and optimize these features using genetic algorithms (GA). Then, we use these steps to interpret complex 2DSAXS data collected from dipeptide solutions that, in microscopy images, exhibit nanoscale structures that could be elliptical tubes/ flat tapes/cylinders or a combination of these cross sections. Open-source codes, computational hardware, and software requirements, as well as the strengths and limitations of this protocol, are also presented. We expect researchers working with (soft) biomaterials, peptide amphiphiles, amphiphilic polymer solutions, polymer nanocomposites, and blends of particles/polymers will find this CREASE-2D method and this tutorial of use.

CREASE↗

MODAQ 2.0 (Modular Ocean Data AcQuisition System v2.0) [SWR-24-138]

MODAQ 2.0 is the continuation of the Modular Ocean/Offshore Data AcQuisition system which offers new benefits of being based on generally available hardware and open-source development tools. The MODAQ 2.0 project is the amalgamation of ROS packages, tools, and guidance for developing data acquisition and control applications for marine energy devices using a ROS2 based architecture. The MODAQ 2.0 Reference Design includes several packages that are targeted for the marine energy sector and allow most developers with a basic background in programming to spin up a high-quality DAQ and control system. It is comprised of multiple software repositories which can be found at the MODAQ2 GitHub Organization: https://github.com/NREL-MODAQ2

Nichols, Casey↗

Tabletop Testing for EV Charging Ecosystem PKI (Project T34PKI Final Report)

To test the communications and cybersecurity functionality, Electric Vehicle and charging station vendors have had to ship their products to in-person testing events. This is cumbersome, expensive, inefficient, and an impediment to rapid time-to-deployment. In this project Sandia used COTS hardware and Open-Source Software to develop and demonstrate a more agile, productive approach: testing low-voltage controllers independently from high-voltage power delivery sub-systems. This approach allows communications controllers to be transported easily (e.g. shipped at low cost, checked as airline baggage); set up on a table-top (“bench testing”); and use ordinary 120 VAC outlets to conduct agile testing. Table-top platforms become end nodes that can connect to laboratory and cloud-based servers to test communications and cybersecurity, specifically Public Key Infrastructure (PKI) functionality and interoperability, separately from EV battery charging (power/energy transfer) functionality.

33 ADVANCED PROPULSION SYSTEMS↗

hls4ml: An Open-Source Codesign Workflow to Empower Scientific Low-Power Machine Learning Devices

Accessible machine learning algorithms, software, and diagnostic tools for energy-efficient devices and systems are extremely valuable across a broad range of application domains. In scientific domains, real-time near-sensor processing can drastically improve experimental design and accelerate scientific discoveries. To support domain scientists, we have developed hls4ml, an open-source software-hardware codesign workflow to interpret and translate machine learning algorithms for implementation with both FPGA and ASIC technologies. We expand on previous hls4ml work by extending capabilities and techniques towards low-power implementations and increased usability: new Python APIs, quantization-aware pruning, end-to-end FPGA workflows, long pipeline kernels for low power, and new device backends include an ASIC workflow. Taken together, these and continued efforts in hls4ml will arm a new generation of domain scientists with accessible, efficient, and powerful tools for machine-learning-accelerated discovery.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Are Fibre Channel SANs a Commodity?

The goal of this work is to evaluate the feasibility of putting together a Fibre Channel Storage Area Network with heterogeneous hardware running both open-source and commercial operating systems. Adherence to the Fibre Channel Specification is supposed to guarantee interoperability in such an environment. We also want to evaluate how difficult it might be to put together a SAN using open-source components. While all the commercial vendors provide Fibre Channel support, this comes at a cost, e.g., not only O/S and drivers, but usually an expensive support contract. The open-source model could lower the cost of building and maintaining a SAN. Of course, for this to be the case, the open-source platforms would have to provide the functionality to construct a SAN. We are assembling a Fibre Channel SAN from heterogeneous hardware (i386, alpha, sparc) running *BSD, Linux, Tru64, NT and Solaris operating systems. We are running several tests to investigate the level of Fibre Channel support provided by each OS. Our current testbed is specified in the table below. Currently, it only contains open-source platforms. We plan to add a PC running OpenBSD, as well as the following commercial systems: Sun Ultra 1/Solaris, DEC AlphaServer 4000/Tru64 Unix, Pentium Pro PC/Windows NT.

Becker, Jeff↗

Detector Interface for Streaming, Control, and Open-source integration (DISCO) v1.0.0

This suite consists of a multi-package ecosystem featuring detector emulators, EPICS areaDetector drivers, and remote server frameworks designed for the Advanced Light Source (ALS). Engineered for high-bandwidth devices—including VFCCD, Timepix3, Timepix4, and related pixel detectors—the software simulates hardware, wraps vendor SDKs into remote-callable servers, and integrates with open-source control systems. Key Capabilities: Distributed SDK Architecture: Server packages wrap hardware-specific SDKs, allowing areaDetector drivers to execute remote framework calls. This isolates proprietary libraries from the EPICS IOC, enhancing stability and enabling distributed computing across beamline networks. Device Support: Custom drivers for VFCCD, the Timepix family, and similar sensors optimize the data path from hardware control to high-speed transport. Full-Stack Emulation: Sophisticated emulator packages allow end-to-end pipeline testing and software development without requiring physical hardware or beam time. Integrated Workflows: Supports high-bandwidth streaming for real-time analysis and robust, metadata-rich file-based workflows (e.g., HDF5/NeXus). By standardizing interfaces across heterogeneous hardware, this suite reduces technical debt. It provides the ALS with a scalable, open-source solution to manage massive data rates within a unified control environment.

Mahl, Johannes [Lawrence Berkeley National Laborat↗

Surrogate Neural Architecture Codesign Package (SNAC-Pack)

Neural architecture search (NAS) is a powerful approach for automating model design, but existing methods often optimize for accuracy alone or rely on proxy metrics such as bit operations (BOPs) that correlate poorly with hardware cost. This gap is particularly large for FPGA deployment, where cost is dominated by a multi-dimensional budget of lookup tables, DSPs, flip-flops, BRAM, and latency. We present the Surrogate Neural Architecture Codesign Package (SNAC-Pack), an open-source AutoML framework for hardware-aware neural architecture codesign and end-to-end FPGA deployment. SNAC-Pack runs a multi-objective global search with Optuna and NSGA-II, loading trials to a shared SQLite store that enables parallel workers across compute nodes. A hardware surrogate model outputs per-trial resource and latency estimates, avoiding the synthesis cost that would otherwise dominate the search loop. A local search stage then applies quantization-aware training (QAT) together with iterative magnitude pruning in a combined compression loop, after which the final model is synthesized to FPGA firmware via the hls4ml Python library. A YAML configuration and an optional agentic frontend let users run the pipeline on new datasets without modifying the framework. We demonstrate SNAC-Pack on jet classification at the Large Hadron Collider and superconducting qubit readout, discovering compact architectures that match or exceed strong baselines on the task metric while reducing FPGA resource utilization and, in the qubit readout case, reducing the design space exploration process from months of manual fine-tuning to hours of automated search.

Weitz, Jason [UC, San Diego]↗

Strengthening the Security of Operational Technology: Understanding Contemporary Bill of Materials

The evolution of cyber-physical infrastructure has made its security more challenging. The last few years have witnessed a convergence of hardware and software segments in various domains, including operational technology (OT) which is responsible for carrying out critical tasks such as monitoring and controlling power grids, nuclear plants, transportation, and emergency services. Both hardware and software encapsulate numerous open source and proprietary subcomponents, making it crucial for end-users to understand the composition of the products they are using. For example, wind turbines incorporate thousands of lines of code (software) used for the turbine's design, planning, operation, and analytics in addition to the numerous hardware subcomponents that construct it. Due to the highly complex nature of software and hardware, knowledge of the components and subcomponents is required to mitigate cyber vulnerabilities and defend against cyberattacks. There has also been a transformation from a traditional linear supply chain into a global, dynamic, diverse, and interconnected system. The digitization of the supply chain makes it easier to find and exploit vulnerabilities. Critical infrastructures (e.g., power grids, oil, natural gas, water, and wastewater) rely on OT to function, and if the OT is compromised, equipment damage and potential interruption of services could result. A significant security measure to protect OT systems from disruption is to develop a supply chain bill of materials (BoM) corresponding to the software and hardware used in OT, along with attestations amongst vendors and asset owners. A supply chain BoM is a proactive way to understand the inherent vulnerabilities in the system and mitigate them in advance of being exploited. BoMs bolster the trust placed in the digital infrastructure and enhance software supply chain security by sustaining the management of component obsolescence and compliance, along with the seclusion of unsafe segments of a specific product. Adopting BoM tools is becoming increasingly important across various government sectors, as evidenced by the recent U.S. executive order on cybersecurity (NIST 2021). This paper aims to classify BoMs based on structure, functionality, component type, and architecture. The work also discusses case studies to further highlight the benefits of BoMs. In addition, it identifies missing pieces in existing BoM implementations so that future research may identify bounds on where it could expect to make improvements and directly enable researchers to identify promising areas for exploration. Further, the authors provide valuable recommendations to tool developers, researchers, and standardizing organizations (policymakers), additionally benefitting critical infrastructure owners and government executives. This aids in paving a path for future work, thereby, providing suggestions to determine a tool for consumers that best suit their needs.

97 MATHEMATICS AND COMPUTING↗

OPET Hardware (Open PV Electrical Tool Hardware) [SWR-25-42]

OPET (Open-source Photovoltaic Electrical Tool) is used for performance measurements of solar photovoltaic (PV) devices in the field under natural sunlight or in the lab under artificial light. Its primary use is in research and development of solar cells and modules, specifically in reliability and durability research of PV devices. Some features and functions include: -IV curve measurements with linear or cosine distributed measurement points -PV device active loading at open circuit voltage (Voc), short circuit current (Isc) and maximum power point (Pmp) -Bias power supply to overcome series resistance in contact wires for Isc measurements and loading -PV voltage input in five ranges from 1V to 100V -PV current input ranges -Low current version, six current ranges from 1.1mA to 340mA -High current version, six current ranges from 50mA to 15A -IO ports for I2C and SPI temperature sensor Arduino extension boards -Integrated fan control This repository contains everything relating to the hardware of the OPET device. If you are looking for the firmware or software repositories, links are below: https://github.com/NREL/opet-firmware https://github.com/NREL/opet-control

McDanold, Byron [National Renewable Energy Laborat↗

Frame Decoder for Consultative Committee for Space Data Systems (CCSDS)

GNU Radio is a free and open source development toolkit that provides signal processing to implement software radios. It can be used with low-cost external RF hardware to create software defined radios, or without hardware in a simulation-like environment. GNU Radio applications are primarily written in Python and C++. The Universal Software Radio Peripheral (USRP) is a computer-hosted software radio designed by Ettus Research. The USRP connects to a host computer via high-speed Gigabit Ethernet. Using the open source Universal Hardware Driver (UHD), we can run GNU Radio applications using the USRP. An SDR is a "radio in which some or all physical layer functions are software defined"(IEEE Definition). A radio is any kind of device that wirelessly transmits or receives radio frequency (RF) signals in the radio frequency. An SDR is a radio communication system where components that have been typically implemented in hardware are implemented in software. GNU Radio has a generic packet decoder block that is not optimized for CCSDS frames. Using this generic packet decoder will add bytes to the CCSDS frames and will not permit for bit error correction using Reed-Solomon. The CCSDS frames consist of 256 bytes, including a 32-bit sync marker (0x1ACFFC1D). This frames are generated by the Space Data Processor and GNU Radio will perform the modulation and framing operations, including frame synchronization.

Reyes, Miguel A. De Jesus↗

ZHW hardware library

Hardware library implementation of the open source ZFP CODEC. ZHP provides a sub-set of the ZFP library compression and decompression functionality, but in the SystemC language rather than the C/C++ and Fortran languages used in the ZFP implementation.

Barrow, MichaelJ↗

Introducing the Video In Situ Snowfall Sensor (VISSS)

The open-source Video In Situ Snowfall Sensor (VISSS) is introduced as a novel instrument for the characterization of particle shape and size in snowfall. The VISSS consists of two cameras with LED backlights and telecentric lenses that allow accurate sizing and combine a large observation volume with relatively high pixel resolution and a design that limits wind disturbance. VISSS data products include various particle properties such as maximum extent, cross-sectional area, perimeter, complexity, and sedimentation velocity. Initial analysis shows that the VISSS provides robust statistics based on up to 10 000 unique particle observations per minute. Comparison of the VISSS with the collocated PIP (Precipitation Imaging Package) and Parsivel instruments at Hyytiälä, Finland, shows excellent agreement with the Parsivel but reveals some differences for the PIP that are likely related to PIP data processing and limitations of the PIP with respect to observing smaller particles. The open-source nature of the VISSS hardware plans, data acquisition software, and data processing libraries invites the community to contribute to the development of the instrument, which has many potential applications in atmospheric science and beyond.

54 ENVIRONMENTAL SCIENCES↗

NOS3: NASA Operational Simulator for Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of open-source software tools to aid in areas such as software development, integration & test (I&T), mission operations/training, verification and validation (V&V), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, operational interface/ground software, dynamics and environment simulations, and software-based hardware models. NOS3 has just recently been open-sourced by NASA and is available for immediate use. It enables the development of flight software (FSW) early in the project life cycle when hardware availability is limited. Small satellite development suffers from extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETUs). To alleviate the need to provide a hardware test-bed for each developer/tester, NOS3 hardware models are based upon characteristic data or manufacturer's data sheets for each individual component. The NOS3 hardware models' fidelity is such that FSW executes unaware that physical hardware is not present. This allows FSW binaries to be compiled for both the simulation environment and the flight computer without changing the FSW source code. For hardware models that provide data which is dependent upon the environment and spacecraft dynamics, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulator) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for V&V of larger missions such as James Webb Space Telescope (JWST). As hardware is selected and becomes available, drivers can be added to the NOS3 environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. NOS3 was actively used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat and the Lunar IceCube CubeSat. As NOS3 matures, hardware models have been added for common small satellite components such as GPS receivers, electrical power systems and batteries, and antenna systems.

Suder, Mark↗

Neuromorphic Computing for Autonomous Racing

Neuromorphic computing has many opportunities in future autonomous systems, especially those that will operate at the edge. However, there are relatively few demonstrations of neuromorphic implementations on real-world applications, partly because of the lack of availability of neuromorphic hardware and software, but also because of the lack of availability of an accessible demonstration platform. In this work, we propose utilizing the F1Tenth platform as an evaluation task for neuromorphic computing. F1Tenth is a competition wherein one tenth scale cars compete in an autonomous racing task; there are significant open source resources in both software and hardware for realizing this task. We present a workflow with neuromorphic hardware, software, and training that can be used to develop a spiking neural network for neuromorphic hardware deployment to perform autonomous racing. We present initial results on utilizing this approach for this small-scale, real-world autonomous vehicle task.

Patton, Robert↗

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗

SOAREX-8 Suborbital Experiments 2015 - A New Paradigm for Small Spacecraft Communication

In 2015 NASA plans to launch a payload to 280 Km altitude on a sounding rocket from the Wallops Flight Facility. This payload will contain several novel technologies that work together to demonstrate methodologies for space sample return missions and for nanosatellite communications in general. The payload will deploy and test an Exo-Brake, which slows the payload aerodynamically, providing eventual de-orbit and recovery of future ISS samples through a Small Payload Quick Return project. In addition, this flight addresses future Mars mission entry technology, space-to-space communications using the Iridium Short Messaging Service (SMS), GPS tracking, and wireless sensors using the ZigBee protocol. SOAREX-8 is being assembled and tested at Ames Research Center (ARC) and the NASA Engineering and Safety Center (NESC) is funding sensor and communications work. Open source Arduino technology and software are used for system control. The ZigBee modules used are XBee units that connect analog sensors for temperature, air pressure and acceleration measurement wirelessly to the payload telemetry system. Our team is developing methods for power distribution and module mounting, along with software for sensor integration, data assembly and downlink. We have demonstrated relaying telemetry to the ground using the Iridium satellite constellation on a previous flight, but the upcoming flight will be the first time we integrate useful flight test data from a ZigBee wireless sensor network. Wireless sensor data will measure the aerodynamic efficacy of the Exo-Brake permitting further on orbit flight tests of improved designs. The Exo-Brake is 5 sq m in area and will be stored in a container and deployed during ascent once the payload is jettisoned from the launch vehicle. We intend to further refine the hardware and continue testing on balloon launches, future sounding rocket flights and on nanosatellite missions. The use of standards-based and open source hardware/software has allowed for this project to be completed with a very modest budget and a challenging schedule. There is a wealth of hardware and software available for both the Arduino platform and the XBee, all low-cost or open-source. Along with the Exo-Brake hardware and deployment discussion, this paper will describe in detail the system architecture emphasizing the successful use of open source hardware and software to minimize effort and cost. Testing procedures, radio frequency interference (RFI) mitigation, success criteria and expected results will also be discussed. The use of Iridium short messaging capability for space-to-space links, standards-based wireless sensor networks, and other innovative communications technology are also presented.

aerobrake↗