Search NASA⌕ Search

SEARCH · Search NASA

Results for “control 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 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

Charter for Systems Engineer Working Group

This charter establishes the International Space Station Program (ISSP) Mobile Servicing System (MSS) Systems Engineering Working Group (SEWG). The MSS SEWG is established to provide a mechanism for Systems Engineering for the end-to-end MSS function. The MSS end-to-end function includes the Space Station Remote Manipulator System (SSRMS), the Mobile Remote Servicer (MRS) Base System (MBS), Robotic Work Station (RWS), Special Purpose Dexterous Manipulator (SPDM), Video Signal Converters (VSC), and Operations Control Software (OCS), the Mobile Transporter (MT), and by interfaces between and among these elements, and United States On-Orbit Segment (USOS) distributed systems, and other International Space Station Elements and Payloads, (including the Power Data Grapple Fixtures (PDGFs), MSS Capture Attach System (MCAS) and the Mobile Transporter Capture Latch (MTCL)). This end-to-end function will be supported by the ISS and MSS ground segment facilities. This charter defines the scope and limits of the program authority and document control that is delegated to the SEWG and it also identifies the panel core membership and specific operating policies.

Suffredini, Michael T.↗
NASA NTRS1992

Design and testing of the U.S. Space Station Freedom primary propulsion system

The primary propulsion system (PPS) for the Space Station Freedom is discussed in terms of salient design characteristics and key testing procedures. The rocket engine modules contain reboost and attitude control thrusters, and their designs are illustrated showing the mounting structures, thruster solenoid valves, and thrust chambers. The propellant tank assembly for storing gaseous N pressurant and hydrazine propellant is described as are the system avionics, thruster solenoid valves, and latching isolation valves. PPS testing conducted on the development systems includes the use of a propulsion-module development unit, a development test article, and system qualification testing. Specific test articles include functional heaters, mass/thermal simulated components, flight-quality structures, and software control operations.

Morano, Joseph S.↗
NASA NTRS2012

Autonomous Rover Traverse and Precise Arm Placement on Remotely Designated Targets

This software controls a rover platform to traverse rocky terrain autonomously, plan paths, and avoid obstacles using its stereo hazard and navigation cameras. It does so while continuously tracking a target of interest selected from 10 20 m away. The rover drives and tracks the target until it reaches the vicinity of the target. The rover then positions itself to approach the target, deploys its robotic arm, and places the end effector instrument on the designated target to within 2-3-cm accuracy of the originally selected target. This software features continuous navigation in a fairly rocky field in an outdoor environment and the ability to enable the rover to avoid large rocks and traverse over smaller ones. Using point-and-click mouse commands, a scientist designates targets in the initial imagery acquired from the rover s mast cameras. The navigation software uses stereo imaging, traversability analysis, path planning, trajectory generation, and trajectory execution. It also includes visual target tracking of a designated target selected from 10 m away while continuously navigating the rocky terrain. Improvements in this design include steering while driving, which uses continuous curvature paths. There are also several improvements to the traversability analyzer, including improved data fusion of traversability maps that result from pose estimation uncertainties, dealing with boundary effects to enable tighter maneuvers, and handling a wider range of obstacles. This work advances what has been previously developed and integrated on the Mars Exploration Rovers by using algorithms that are capable of traversing more rock-dense terrains, enabling tight, thread-the-needle maneuvers. These algorithms were integrated on the newly refurbished Athena Mars research rover, and were fielded in the JPL Mars Yard. Forty-three runs were conducted with targets at distances ranging from 5 to 15 m, and a success rate of 93% was achieved for placement of the instrument within 2-3 cm of the target.

Nesnas, Issa A.↗
NASA NTRSDate not supplied

Solar Sail Torque Model Characterization for the Near Earth Asteroid Scout Mission

Near Earth Asteroid Scout (NEA Scout) was a mission to test solar sail propulsion for orbital transfer from cislunar space to flyby and image an asteroid. Had it succeeded, one of the mission goals was to characterize the solar torque on the sail to ensure successful attitude control for the orbit transfer and imaging the asteroid. The simulation used to develop the flight attitude control software uses the generalized model for solar sails, a tensor equation of the forces and torques on sails of arbitrary shape. Rios-Reyes and Scheeres developed a general process to update the torque tensor coefficients using estimates of sail torque over a range of directions to the sun. Their process was adapted and implemented for the specific case of NEA Scout using spacecraft telemetry collected during sail characterization maneuvers in combination with simulation models and parameters. The NEA Scout maneuvers were limited to the operating range of the mission and constraints of the control hardware and allowed safe testing of each attitude before proceeding to the next. The NEA Scout reaction wheel speeds are used to measure accumulated momentum, while the Active Mass Translator (AMT) position is used to subtract out the torque from the center of mass crossed with the sail force and isolate the torque from only the sail shape. The process was tested by running attitude control simulations of the characterization maneuvers, generating simulated telemetry, estimating the solar torques, then using a least squares estimating the solar torque coefficients using least-squares and then performing a least-squares fit to the solar torque tensor coefficients. These estimated coefficients were tested by evaluating the solar torques under the same conditions as the simulated telemetry and comparing to the true simulated torques. Solar force model updates can be performed separately by observing the effect of the sail on the trajectory, and the torque model can be refined using those solar force updates. This process met the needs of the NEA Scout mission and can be adapted to characterize the solar torque for other missions with different sails.

solar sail↗
NASA NTRSDate not supplied

Solar Sail Torque Model Characterization for the Near Earth Asteroid Scout Mission

Near Earth Asteroid Scout (NEA Scout) was a mission to test solar sail propulsion for orbital transfer from cislunar space to flyby and image an asteroid. One of the goals of the mission was to characterize the solar torque on the sail to ensure successful attitude control for the orbit transfer and imaging the asteroid. The simulation used to develop the flight attitude control software uses the generalized model for solar sails, a tensor equation of the forces and torques on sails of arbitrary shape. Rios-Reyes and Scheeres developed a general process to update the torque tensor coefficients using estimates of sail torque over a range of directions to the sun. Their process was adapted and implemented for the specific case of NEA Scout using spacecraft telemetry collected during sail characterization maneuvers in combination with simulation models and parameters. The NEA Scout maneuvers were limited to the operating range of the mission and constraints of the control hardware and allowed safe testing of each attitude before proceeding to the next. The NEA Scout reaction wheel speeds are used to measure accumulated momentum, while the Active Mass Translator (AMT) position is used to subtract out the torque from the center of mass crossed with the sail force and isolate the torque from only the sail shape. The process was tested by running attitude control simulations of the characterization maneuvers, generating simulated telemetry, estimating the solar torques, then using a least squares estimating the solar torque coefficients using least-squares and then performing a least-squares fit to the solar torque tensor coefficients. These estimated coefficients were tested by evaluating the solar torques under the same conditions as the simulated telemetry and comparing to the true simulated torques. Solar force model updates can be performed separately by observing the effect of the sail on the trajectory, and the torque model can be refined using those solar force updates. This process met the needs of the NEA Scout mission and can be adapted to characterize the solar torque for other missions with different sails.

solar sail↗
NASA NTRS2013

Thermal Performance of ATLAS Laser Thermal Control System Demonstration Unit

The second Ice, Cloud, and Land Elevation Satellite mission currently planned by National Aeronautics and Space Administration will measure global ice topography and canopy height using the Advanced Topographic Laser Altimeter System {ATLAS). The ATLAS comprises two lasers; but only one will be used at a time. Each laser will generate between 125 watts and 250 watts of heat, and each laser has its own optimal operating temperature that must be maintained within plus or minus 1 degree Centigrade accuracy by the Laser Thermal Control System (LTCS) consisting of a constant conductance heat pipe (CCHP), a loop heat pipe (LHP) and a radiator. The heat generated by the laser is acquired by the CCHP and transferred to the LHP, which delivers the heat to the radiator for ultimate rejection. The radiator can be exposed to temperatures between minus 71 degrees Centigrade and minus 93 degrees Centigrade. The two lasers can have different operating temperatures varying between plus 15 degrees Centigrade and plus 30 degrees Centigrade, and their operating temperatures are not known while the LTCS is being designed and built. Major challenges of the LTCS include: 1) A single thermal control system must maintain the ATLAS at 15 degrees Centigrade with 250 watts heat load and minus 71 degrees Centigrade radiator sink temperature, and maintain the ATLAS at plus 30 degrees Centigrade with 125 watts heat load and minus 93 degrees Centigrade radiator sink temperature. Furthermore, the LTCS must be qualification tested to maintain the ATLAS between plus 10 degrees Centigrade and plus 35 degrees Centigrade. 2) The LTCS must be shut down to ensure that the ATLAS can be maintained above its lowest desirable temperature of minus 2 degrees Centigrade during the survival mode. No software control algorithm for LTCS can be activated during survival and only thermostats can be used. 3) The radiator must be kept above minus 65 degrees Centigrade to prevent ammonia from freezing using no more than 135 watts of heater power. 4) The LHP reservoir control heater power is limited to 15 watts with a 70 percent duty cycle. 5) The voltage of the power supply can vary between 26 volts direct current and 34 volts direct current during the spacecraft lifetime. A design analysis shows that a single LTCS can satisfy these requirements. However, shutdown of· the LHP is particularly challenging and the shutdown heater must be wired in series with two reservoir thermostats and two CCHP thermostats at different set points. An LTCS demonstration unit has been tested to verify these performance characteristics experimentally prior to proceeding to the final LTCS design and fabrication. Test results showed that the LHP shutdown scheme would be able to shut down the LHP as designed and the reservoir control heater can maintain the ATLAS mass simulator within the plus or minus 1 degrees Centigrade accuracy under various combinations of the heat load, sink temperature, and power supply voltage.

Ku, Jentung↗
NASA NTRS1983

Digitally controlled sonars

Sonars are usually designed and constructed as stand alone instruments. That is, all elements or subsystems of the sonar are provided: power conditioning, displays, intercommunications, control, receiver, transmitter, and transducer. The sonars which are a part of the Advanced Ocean Test Development Platform (AOTDP) represent a departure from this manner of implementation and are configured more like an instrumentation system. Only the transducer, transmitter, and receiver which are unique to a particular sonar function; Up, Down, Side Scan, exist as separable subsystems. The remaining functions are reserved to the AOTDP and serve all sonars and other instrumentation in a shared manner. The organization and functions of the common AOTDP elements were described and then the interface with the sonars discussed. The techniques for software control of the sonar parameters were explained followed by the details of the realization of the sonar functions and some discussion of the performance of the side scan sonars.

Hansen, G. R.↗
NASA NTRS1996

A Digital Control Algorithm for Magnetic Suspension Systems

An ongoing program exists to investigate and develop magnetic suspension technologies and modelling techniques at NASA Langley Research Center. Presently, there is a laboratory-scale large air-gap suspension system capable of five degree-of-freedom (DOF) control that is operational and a six DOF system that is under development. Those systems levitate a cylindrical element containing a permanent magnet core above a planar array of electromagnets, which are used for levitation and control purposes. In order to evaluate various control approaches with those systems, the Generic Real-Time State-Space Controller (GRTSSC) software package was developed. That control software package allows the user to implement multiple control methods and allows for varied input/output commands. The development of the control algorithm is presented. The desired functionality of the software is discussed, including the ability to inject noise on sensor inputs and/or actuator outputs. Various limitations, common issues, and trade-offs are discussed including data format precision; the drawbacks of using either Direct Memory Access (DMA), interrupts, or program control techniques for data acquisition; and platform dependent concerns related to the portability of the software, such as memory addressing formats. Efforts to minimize overall controller loop-rate and a comparison of achievable controller sample rates are discussed. The implementation of a modular code structure is presented. The format for the controller input data file and the noise information file is presented. Controller input vector information is available for post-processing by mathematical analysis software such as MATLAB1.

Britton, Thomas C.↗
NASA NTRSDate not supplied

Stochastic Verification by Analysis for Autonomous Systems Management Architecture (ASMA)

The Gateway Vehicle Systems Manager (VSM) is the top-level of a distributed, hierarchical software control system. VSM is data-driven and will make decisions related to mission, fault, resource management and vehicle control. These attributes combined with a high degree of autonomy make it susceptible to emergent behavior. In order to achieve the high level of confidence needed in this critical system, the VSM team has developed a multifaceted verification strategy employing traditional verification techniques, simulation, model checking, and runtime verification. Individual algorithms are verified using conventional testing and model checking using assume-guarantee contracts. A discrete event-based simulation approach is being developed to verify timelines. This presentation describes an enhancement to the verification approach using analysis to enhance system robustness by detecting and resolving the potential for emergent behavior. The verification by analysis employs a Software in the Loop (SITL) environment with real flight software executing on emulated processors, simulations of vehicle subsystems, flight dynamics, and human inputs. Since the possible input space and configuration data set are too large for exhaustive testing, a Monte Carlo approach is used to cover feasible scenarios, augmented with corner cases and known higher-risk scenarios. A key problem in using Monte Carlo-based system verification is evaluating test results to ensure that system behavior is correct. The presentation describes the approach the VSM team uses to monitor behavior for compliance with predetermined boundaries and to identify anomalous behavior for further analysis. This presentation describes the multi-level systems approach to verification, and the simulation-based layer that covers the feasible state space: 1. Overview of the Gateway VSM 2. Special challenges due to heterogeneous, hierarchical architecture 3. Modeling and simulation environment using flight software and system simulations 4. Developing input sets to ensure state-space coverage 5. Developing model and data configuration sets to ensure model coverage 6. Interpreting results without predetermined outcomes 7. Lessons learned and future work

Verification and Validation↗
NASA NTRS1987

Off-line programming motion and process commands for robotic welding of Space Shuttle main engines

The off-line-programming software and hardware being developed for robotic welding of the Space Shuttle main engine are described and illustrated with diagrams, drawings, graphs, and photographs. The menu-driven workstation-based interactive programming system is designed to permit generation of both motion and process commands for the robotic workcell by weld engineers (with only limited knowledge of programming or CAD systems) on the production floor. Consideration is given to the user interface, geometric-sources interfaces, overall menu structure, weld-parameter data base, and displays of run time and archived data. Ongoing efforts to address limitations related to automatic-downhand-configuration coordinated motion, a lack of source codes for the motion-control software, CAD data incompatibility, interfacing with the robotic workcell, and definition of the welding data base are discussed.

Ruokangas, C. C.↗
NASA NTRS2006

Multiuser Collaboration with Networked Mobile Devices

In this paper we describe a multiuser collaboration infrastructure that enables multiple mission scientists to remotely and collaboratively interact with visualization and planning software, using wireless networked personal digital assistants(PDAs) and other mobile devices. During ground operations of planetary rover and lander missions, scientists need to meet daily to review downlinked data and plan science activities. For example, scientists use the Science Activity Planner (SAP) in the Mars Exploration Rover (MER) mission to visualize downlinked data and plan rover activities during the science meetings [1]. Computer displays are projected onto large screens in the meeting room to enable the scientists to view and discuss downlinked images and data displayed by SAP and other software applications. However, only one person can interact with the software applications because input to the computer is limited to a single mouse and keyboard. As a result, the scientists have to verbally express their intentions, such as selecting a target at a particular location on the Mars terrain image, to that person in order to interact with the applications. This constrains communication and limits the returns of science planning. Furthermore, ground operations for Mars missions are fundamentally constrained by the short turnaround time for science and engineering teams to process and analyze data, plan the next uplink, generate command sequences, and transmit the uplink to the vehicle [2]. Therefore, improving ground operations is crucial to the success of Mars missions. The multiuser collaboration infrastructure enables users to control software applications remotely and collaboratively using mobile devices. The infrastructure includes (1) human-computer interaction techniques to provide natural, fast, and accurate inputs, (2) a communications protocol to ensure reliable and efficient coordination of the input devices and host computers, (3) an application-independent middleware that maintains the states, sessions, and interactions of individual users of the software applications, (4) an application programming interface to enable tight integration of applications and the middleware. The infrastructure is able to support any software applications running under the Windows or Unix platforms. The resulting technologies not only are applicable to NASA mission operations, but also useful in other situations such as design reviews, brainstorming sessions, and business meetings, as they can benefit from having the participants concurrently interact with the software applications (e.g., presentation applications and CAD design tools) to illustrate their ideas and provide inputs.

ground operations↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRS2005

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗
NASA NTRS2016

James Webb Space Telescope Integrated Science Instrument Module Thermal Vacuum Thermal Balance Test Campaign at NASA's Goddard Space Flight Center

The James Webb Space Telescope is a large infrared telescope with a 6.5-meter primary mirror, designed as a successor to the Hubble Space Telescope when launched in 2018. Three of the four science instruments contained within the Integrated Science Instrument Module (ISIM) are passively cooled to their operational temperature range of 36K to 40K with radiators, and the fourth instrument is actively cooled to its operational temperature of approximately 6K. Thermal-vacuum testing of the flight science instruments at the ISIM element level has taken place in three separate highly challenging and extremely complex thermal tests within a gaseous helium-cooled shroud inside Goddard Space Flight Centers Space Environment Simulator. Special data acquisition software was developed for these tests to monitor over 1700 flight and test sensor measurements, track over 50 gradients, component rates, and temperature limits in real time against defined constraints and limitations, and guide the complex transition from ambient to final cryogenic temperatures and back. This extremely flexible system has proven highly successful in safeguarding the nearly $2B science payload during the 3.5-month-long thermal tests. Heat flow measurement instrumentation, or Q-meters, were also specially developed for these tests. These devices provide thermal boundaries o the flight hardware while measuring instrument heat loads up to 600 mW with an estimated uncertainty of 2 mW in test, enabling accurate thermal model correlation, hardware design validation, and workmanship verification. The high accuracy heat load measurements provided first evidence of a potentially serious hardware design issue that was subsequently corrected. This paper provides an overview of the ISIM-level thermal-vacuum tests and thermal objectives; explains the thermal test configuration and thermal balances; describes special measurement instrumentation and monitoring and control software; presents key test thermal results; lists problems encountered during testing and lessons learned.

JWST ISIM Thermal↗
NASA NTRS1982

Development of the Galileo Attitude and Articulation Control Subsystem flight software

The ongoing design and implementation of the Project Galileo Attitude and Articulation Control Subsystem (AACS) flight software is outlined, as well as the more important problems that were experienced in the development of this software. The important characteristics of the Galileo spacecraft are described, as are the major requirements driving the software design. The important features of the design are stated and discussed, and a modes and tasks transition diagram is presented. The AACS software implementation is covered, and the algorithms active in each task are shown. Finally, some of the design and management techniques used in the course of the software development are discussed.

Krasner, S. M.↗
NASA NTRS1992

Differential phase acoustic microscope for micro-NDE

A differential phase scanning acoustic microscope (DP-SAM) was developed, fabricated, and tested in this project. This includes the acoustic lens and transducers, driving and receiving electronics, scanning stage, scanning software, and display software. This DP-SAM can produce mechanically raster-scanned acoustic microscopic images of differential phase, differential amplitude, or amplitude of the time gated returned echoes of the samples. The differential phase and differential amplitude images provide better image contrast over the conventional amplitude images. A specially designed miniature dual beam lens was used to form two foci to obtain the differential phase and amplitude information of the echoes. High image resolution (1 micron) was achieved by applying high frequency (around 1 GHz) acoustic signals to the samples and placing two foci close to each other (1 micron). Tone burst was used in this system to obtain a good estimation of the phase differences between echoes from the two adjacent foci. The system can also be used to extract the V(z) acoustic signature. Since two acoustic beams and four receiving modes are available, there are 12 possible combinations to produce an image or a V(z) scan. This provides a unique feature of this system that none of the existing acoustic microscopic systems can provide for the micro-nondestructive evaluation applications. The entire system, including the lens, electronics, and scanning control software, has made a competitive industrial product for nondestructive material inspection and evaluation and has attracted interest from existing acoustic microscope manufacturers.

Waters, David D.↗
NASA NTRS2017

Sample Processor for Life on Icy Worlds (SPLIce): Design and Test Results

We report the design, development, and testing of the Sample Processor for Life on Icy Worlds (SPLIce) system, a microfluidic sample processor to enable autonomous detection of signatures of life and measurements of habitability parameters in Ocean Worlds. This monolithic fluid processing-and-handling system (Figure 1; mass 0.5 kg) retrieves a 50-L-volume sample and prepares it to supply a suite of detection instruments, each with unique preparation needs. SPLIce has potential applications in orbiter missions that sample ocean plumes, such as found in Saturns icy moon Enceladus, or landed missions on the surface of icy satellites, such as Jupiters moon Europa. Answering the question Are we alone in the universe? is captivating and exceptionally challenging. Even general criteria that define life very broadly include a significant role for water [1,2]. Searches for extinct or extant life therefore prioritize locations of abundant water whether in ancient (Mars), or present (Europa and Enceladus) times. Only two previous planetary missions had onboard fluid processing: the Viking Biology Experiments [3] and Phoenixs Wet Chemistry Laboratory (WCL) [4]. SPLIce differs crucially from those systems, including its capability to process and distribute L-volume samples and the integration autonomous control of a wide range of fluidic functions, including: 1) retrieval of fluid samples from an evacuated sample chamber; 2) onboard multi-year storage of dehydrated reagents; 3) integrated pressure, pH, and conductivity measurement; 4) filtration and retention of insoluble particles for microscopy; 5) dilution or vacuum-driven concentration of samples to accommodate instrument working ranges; 6) removal of gas bubbles from sample aliquots; 7) unidirectional flow (check valves); 8) active flow-path selection (solenoid-actuated valves); 9) metered pumping in 100 nL volume increments. The SPLIce manifold, made of three thermally fused layers of precision-machined cyclo-olefin polymer, supports all fluidic components (Figure 1) and integrated microchannels (125 x 250 m). Fluid is pumped by a stepper-motor-driven pump (Lee Co.). The functionality of the integrated MEMS pressure sensor (Honeywell) and passive check valves (Figure 2) were tested in conjunction with our newly designed integral bubble traps (Figure 3) and hydrophobic membrane-based concentrator (Figure 4). The concentrator (initially tested as a standalone component) demonstrated 5-fold vacuum-evaporative concentration. Polyethylene fused bead beds (PEFBBs; 50 porosity) store drylyophilized buffers, calibrants, and fluorescent dyes, and also promote mixing of sample with calibrant, dye, or H2O. Software-controlled automated tests demonstrated successful 1) fluid delivery to each component 2) valve and pump synchronization 3) sample aliquot delivery to instrument interface ports, and 4) rehydration of vacuum-dried fluorescent dye. In Figure 5, fluorescein on PEFBBs was rehydrated for 15 min using a pump-delivered water aliquot; it is displaced as H2O enters the bottom of the channel and pushes the dye into a check valve. Ultimately, SPLIce will fluorescently label amino acids in the sample for microchip-based electrophoretic (MCE) chiral separation and detection to seek and quantify key organic bio-signatures [5]; it will also deliver sample to a microfluidic version of WCL (mWCL) to measure soluble ions and redox-active species.

Life detection↗
DOE OSTI2025

HunStat2 – a simple and low-cost potentiostat with electrochemical impedance spectroscopy capability

We have developed a low-cost (30 USD), simple do-it-yourself (DIY) potentiostat with cyclic voltammetry (CV), open circuit potential (OCP) and electrochemical impedance spectroscopy (EIS) capability. The HunStat2 potentiostat is based on Analog Devices' AD5941 Analog Front End chip, which significantly simplifies the construction of potentiostats for both direct and alternating current (DC and AC, respectively) techniques. Interested readers are provided with circuit diagrams and a bill of materials to build the potentiostat on their own. In addition, control software is also provided free of charge. The software enables acquisition and visualization of data. In summary, HunStat2 introduces a simple and low-cost DIY potentiostat recommended for both analytical and educational purposes.

Vamos, Istvan [Lajos Petrik Vocational Chemistry S↗