Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Ethernet”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

The High Definition Earth Viewing (HDEV) Payload

The High Definition Earth Viewing (HDEV) payload enables long-term experimentation of four, commercial-of-the-shelf (COTS) high definition video, cameras mounted on the exterior of the International Space Station. The payload enables testing of cameras in the space environment. The HDEV cameras transmit imagery continuously to an encoder that then sends the video signal via Ethernet through the space station for downlink. The encoder, cameras, and other electronics are enclosed in a box pressurized to approximately one atmosphere, containing dry nitrogen, to provide a level of protection to the electronics from the space environment. The encoded video format supports streaming live video of Earth for viewing online. Camera sensor types include charge-coupled device and complementary metal-oxide semiconductor. Received imagery data is analyzed on the ground to evaluate camera sensor performance. Since payload deployment, minimal degradation to imagery quality has been observed. The HDEV payload continues to operate by live streaming and analyzing imagery. Results from the experiment reduce risk in the selection of cameras that could be considered for future use on the International Space Station and other spacecraft. This paper discusses the payload development, end-to- end architecture, experiment operation, resulting image analysis, and future work.

Muri, Paul↗
NASA NTRS2017

Critical Software for Human Spaceflight

The NASA Orion vehicle that will fly to the moon in the next years is propelled along its mission by the European Service Module (ESM), developed by ESA and its prime contractor Airbus Defense and Space. This paper describes the development of the Propulsion Drive Electronics (PDE) Software that provides the interface between the propulsion hardware of the European Service Module with the Orion flight computers, and highlights the challenges that have been faced during the development. Particularly, the specific aspects relevant to Human Spaceflight in an international cooperation are presented, as the compliance to both European and US standards and the software criticality classification to the highest category A. An innovative aspect of the PDE SW is its Time- Triggered Ethernet interface with the Orion Flight Computers, which has never been flown so far on any European spacecraft. Finally the verification aspects are presented, applying the most exigent quality requirements defined in the European Cooperation for Space Standardization (ECSS) standards such as the structural coverage analysis of the object code and the recourse to an independent software verification and validation activity carried on in parallel by a different team.

Preden, Antonio↗
NASA NTRS2017

Remote Advanced Payload Test Rig (RAPTR) Portable Payload Test System for the International Space Station (ISS)

The RAPTR was developed to test ISS payloads for NASA. RAPTR is a simulation of the Command and Data Handling (C&DH) interfaces of the ISS (MIL-STD 1553B, Ethernet and TAXI) and is designed to facilitate rapid testing and deployment of payload experiments to the ISS. The ISS Program's goal is to reduce the amount of time it takes a payload developer to build, test and fly a payload, including payload software. The RAPTR meets this need with its user oriented, visually rich interface. Additionally, the Analog and Discrete (A&D) signals of the following payload types may be tested with RAPTR: (1) EXPRESS Sub Rack Payloads; (2) ELC payloads; (3) External Columbus payloads; (4) External Japanese Experiment Module (JEM) payloads. The automated payload configuration setup and payload data inspection infrastructure is found nowhere else in ISS payload test systems. Testing can be done with minimal human intervention and setup, as the RAPTR automatically monitors parameters in the data headers that are sent to, and come from the experiment under test.

Calvert, John↗
NASA NTRS2016

Deploying a Route Optimization EFB Application for Commercial Airline Operational Trials

The Traffic Aware Planner (TAP), developed for NASA Langley Research Center to support the Traffic Aware Strategic Aircrew Requests (TASAR) project, is a flight-efficiency software application developed for an Electronic Flight Bag (EFB). Tested in two flight trials and planned for operational testing by two commercial airlines, TAP is a real-time trajectory optimization application that leverages connectivity with onboard avionics and broadband Internet sources to compute and recommend route modifications to flight crews to improve fuel and time performance. The application utilizes a wide range of data, including Automatic Dependent Surveillance Broadcast (ADS-B) traffic, Flight Management System (FMS) guidance and intent, on-board sensors, published winds and weather, and Special Use Airspace (SUA) schedules. This paper discusses the challenges of developing and deploying TAP to various EFB platforms, our solutions to some of these challenges, and lessons learned, to assist commercial software developers and hardware manufacturers in their efforts to implement and extend TAP functionality in their environments. EFB applications (such as TAP) typically access avionics data via an ARINC 834 Simple Text Avionics Protocol (STAP) server hosted by an Aircraft Interface Device (AID) or other installed hardware. While the protocol is standardized, the data sources, content, and transmission rates can vary from aircraft to aircraft. Additionally, the method of communicating with the AID may vary depending on EFB hardware and/or the availability of onboard networking services, such as Ethernet, WIFI, Bluetooth, or other mechanisms. EFBs with portable and installed components can be implemented using a variety of operating systems, and cockpits are increasingly incorporating tablet-based technologies, further expanding the number of platforms the application may need to support. Supporting multiple EFB platforms, AIDs, avionics datasets, and user interfaces presents a challenge for software developers and the management of their code baselines. Maintaining multiple baselines to support all deployment targets can be extremely cumbersome and expensive. Certification also needs to be considered when developing the application. Regardless of whether the software is itself destined to be certified, data requirements in support of the application and user interface elements may introduce certification requirements for EFB manufacturers and the airlines. The example of TAP, the challenges faced, solutions implemented, and lessons learned will give EFB application and hardware developers insight into future potential requirements in deploying TAP or similar flight-deck EFB applications.

Roscoe, David A.↗
NASA NTRS2017

SCaN Transportable Communication Platform (STCP)

NASA Glenn Research Center required a satellite communication trailer that served dual purposes; 24/7 Emergency Communication Services (ECS) in the event of a natural or manmade disaster that disrupted conventional communications, and a Ka Band NASA TDRS capability providing a research capability for over the air evaluations/characterizations. The trailer was to be field deployable, environmentally controlled and self-contained providing local area networks (LANs) and Wide Area Networks (WAN's) with user access both wired (Ethernet) and wireless (802.11) supporting VoIP, Internet Web access and Email. The TDRSS terminal included a 200W TWT amplifier mounted on the feed boom, individual up and down converters, and custom integrated waveguide and a supporting feed system. Other features such as a mast, generator, electrical, lighting, surveillance, and storage capabilities were also required. The Trailer was developed and demonstrated these original requested capabilities. New Requirements are defined and the trailer is now being evolved and upgraded to be a backup for the Near- Earth Network (NEN) Stations at KSC that will support the launch phase of EM-1. This paper presents the current and future capabilities of the trailer and additional options that will make it a valuable deployable asset to support remote operations from any launch from location.

Ka Band↗
NASA NTRS2009

Digital Beamforming Scatterometer

This paper discusses scatterometer measurements collected with multi-mode Digital Beamforming Synthetic Aperture Radar (DBSAR) during the SMAP-VEX 2008 campaign. The 2008 SMAP Validation Experiment was conducted to address a number of specific questions related to the soil moisture retrieval algorithms. SMAP-VEX 2008 consisted on a series of aircraft-based.flights conducted on the Eastern Shore of Maryland and Delaware in the fall of 2008. Several other instruments participated in the campaign including the Passive Active L-Band System (PALS), the Marshall Airborne Polarimetric Imaging Radiometer (MAPIR), and the Global Positioning System Reflectometer (GPSR). This campaign was the first SMAP Validation Experiment. DBSAR is a multimode radar system developed at NASA/Goddard Space Flight Center that combines state-of-the-art radar technologies, on-board processing, and advances in signal processing techniques in order to enable new remote sensing capabilities applicable to Earth science and planetary applications [l]. The instrument can be configured to operate in scatterometer, Synthetic Aperture Radar (SAR), or altimeter mode. The system builds upon the L-band Imaging Scatterometer (LIS) developed as part of the RadSTAR program. The radar is a phased array system designed to fly on the NASA P3 aircraft. The instrument consists of a programmable waveform generator, eight transmit/receive (T/R) channels, a microstrip antenna, and a reconfigurable data acquisition and processor system. Each transmit channel incorporates a digital attenuator, and digital phase shifter that enables amplitude and phase modulation on transmit. The attenuators, phase shifters, and calibration switches are digitally controlled by the radar control card (RCC) on a pulse by pulse basis. The antenna is a corporate fed microstrip patch-array centered at 1.26 GHz with a 20 MHz bandwidth. Although only one feed is used with the present configuration, a provision was made for separate corporate feeds for vertical and horizontal polarization. System upgrades to dual polarization are currently under way. The DBSAR processor is a reconfigurable data acquisition and processor system capable of real-time, high-speed data processing. DBSAR uses an FPGA-based architecture to implement digitally down-conversion, in-phase and quadrature (I/Q) demodulation, and subsequent radar specific algorithms. The core of the processor board consists of an analog-to-digital (AID) section, three Altera Stratix field programmable gate arrays (FPGAs), an ARM microcontroller, several memory devices, and an Ethernet interface. The processor also interfaces with a navigation board consisting of a GPS and a MEMS gyro. The processor has been configured to operate in scatterometer, Synthetic Aperture Radar (SAR), and altimeter modes. All the modes are based on digital beamforming which is a digital process that generates the far-field beam patterns at various scan angles from voltages sampled in the antenna array. This technique allows steering the received beam and controlling its beam-width and side-lobe. Several beamforming techniques can be implemented each characterized by unique strengths and weaknesses, and each applicable to different measurement scenarios. In Scatterometer mode, the radar is capable to.generate a wide beam or scan a narrow beam on transmit, and to steer the received beam on processing while controlling its beamwidth and side-lobe level. Table I lists some important radar characteristics

Rincon, Rafael F.↗
NASA NTRS2018

Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous

Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus – network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.

Hirsh, Robert L.↗
NASA NTRS2019

A Delay Tolerant Networking-Based Approach to a High Data Rate Architecture for Spacecraft

Historically, it has been the case that SWaP placed such severe constraints on radios that the links between spacecraft and the ground were relatively slow. This meant that the radio link was normally a significant bottleneck in returning scientific data. Over recent years, however, a combination of more efficient radio design, intelligent waveforms, and highly directed, high-frequency RF / optical systems have led to a rapid increase in the amount of data that can be pushed through radio and optical links. This has led to some cases where the radio links are capable of moving data much more quickly than the spacecraft and instruments are capable of actually generating it! In some instances, scientific data can therefore be lost not because the downlink is too slow to support the data rate, but instead because the spacecraft was not designed in a way that would let it fully utilize both the radio and the networking services available to it.The High Data Rate Architecture (HiDRA) project describes a packet-based approach to building modern, distributed spacecraft systems. It presents a means for spacecraft and other assets to participate in both present and future Delay Tolerant Networks (DTN), while simultaneously ensuring that the asset is able to fully utilize the new, high-speed links that have been seeing more widespread development and deployment in recent years. With this in mind, this paper begins with a discussion regarding HiDRA's evolution. Next, it discusses the capabilities and limitations of NASA's present DTN-enabled networks. Of particular note is the way in which principles of network design at the terrestrial level (e.g. use of programmable networks / software-defined networks, separation between data and control plane, infusion of COTS Ethernet switch chips, etc.) can all be translated into the space environment as well. After this, the paper discusses the design and implementation of a present prototype reference implementation of High-Rate DTN (HDTN), which is intended to demonstrate future high-rate networking concepts as part of a coherent demonstration on the International Space Station (ISS). The goal, of both the research and of this implementation, is to help develop a ready-made toolbox of ideas, approaches, and examples from which mission designers can draw when putting together new missions. Assuming all goes as planned, this should not only work to reduce the cost of individual mission design, but also improve the rate at which science data can be returned for mission participants to review.

Hylton, Alan↗
NASA NTRS2019

A Delay Tolerant Networking-Based Approach to a High Data Rate Architecture for Spacecraft

Historically, it has been the case that SWaP (Size, Weigh a lot, And consume Power) placed such severe constraints on radios that the links between spacecraft and the ground were relatively slow. This meant that the radio link was normally a significant bottleneck in returning scientific data. Over recent years, however, a combination of more efficient radio design, intelligent waveforms, and highly directed, high-frequency RF / optical systems have led to a rapid increase in the amount of data that can be pushed through radio and optical links. This has led to some cases where the radio links are capable of moving data much more quickly than the spacecraft and instruments are capable of actually generating it! In some instances, scientific data can therefore be lost not because the downlink is too slow to support the data rate, but instead because the spacecraft was not designed in a way that would let it fully utilize both the radio and the networking services available to it. The High Data Rate Architecture (HiDRA) project describes a packet-based approach to building modern, distributed spacecraft systems. It presents a means for spacecraft and other assets to participate in both present and future Delay Tolerant Networks (DTN), while simultaneously ensuring that the asset is able to fully utilize the new, high-speed links that have been seeing more widespread development and deployment in recent years. With this in mind, this paper begins with a discussion regarding HiDRA's evolution. Next, it discusses the capabilities and limitations of NASA's present DTN-enabled networks. Of particular note is the way in which principles of network designate the terrestrial level (e.g., use of programmable networks / software-defined networks, separation between data and control plane, infusion of COTS (Commercial Off-The-Shelf) Ethernet switch chips, etc.) can all be translated into the space environment as well. After this, the paper discusses the design and implementation of a present prototype reference implementation of High-Rate DTN (HDTN),which is intended to demonstrate future high-rate networking concepts as part of a coherent demonstration on the International Space Station (ISS). The goal, of both the research and of this implementation, is to help develop a ready-made toolbox of ideas, approaches, and examples from which mission designers can draw when putting together new missions. Assuming all goes as planned, this should not only work to reduce the cost of individual mission design, but also improve the rate at which science data can be returned for mission participants to review.

Hylton, Alan↗
NASA NTRS2019

Flight Readiness of Mochii S: Portable Spectroscopic Scanning Electron Microscope Facility on the International Space Station (ISS)

The ISS (International Space Station) currently lacks the capability to image and chemically analyze nano-to-micron scale particles from numerous engineering systems. To identify these particles, we must wait for a re-entry vehicle to return them from low earth orbit for ground-based SEM (Scanning Electron Microscope) / EDS (Energy Dispersive X-Ray Spectroscopy) analysis. This may take months, potentially delaying the affected system. Having an EDS-equipped SEM (Mochii S) aboard the ISS will accelerate response time thereby enhancing crew and vehicle safety by rapid and accurate identification of microscopic threats, especially in time-critical situations.The Mochii S payload will be stationed in the Japanese Experiment Module (JEM) powered by 120 VAC (Volts Alternating Current) inverter and connected to station Ethernet and WiFi (Fig. 1). To date the Mochii S payload has undergone testing for command and data handling, power quality, flight vibration, and radiation testing at Johnson Space Center (JSC). Mochii's high-RPM (Revolutions Per Minute) rotating vacuum pumps and high voltage systems have been reviewed to meet safety standards by JSC (Johnson Space Center) Engineering. Topology of the system in the JEM module has been baselined by ISS Safety and JAXA (Japan Space Exploration Agency). Digital controls to and from ISS over Joint Station LAN (Local Area Network) uplink have been simulated and the latencies and data rates have been found to be sufficient for successful operation of the payload from ground.Transporting sensitive electron optical instruments aboard a rocket that sustains 7G acceleration for 8 minutes and then operating it the unique microgravity (micro-g) environment is no trivial matter. To meet strict safety requirements and increase robustness for mission success, over 500 unique verifications must be completed before the payload is certified for spaceflight. Two of which will be discussed in detail are: vibroacoustic testing and magnetic susceptibility shielding and validation.

Mochii↗
NASA NTRS2019

The Space Debris Sensor Experiment

The Space Debris Sensor (SDS) is a NASA Class 1E technology demonstration external payload aboard the International Space Station (ISS). With approximately one square meter of detection area, the SDS is attached to the European Space Agency Columbus module facing the ISS velocity vector with minimal obstruction from ISS hardware. The SDS is the first flight demonstration of the Debris Resistive/Acoustic Grid Orbital NASA-Navy Sensor (DRAGONS) technology developed and matured over 10 years by the NASA Orbital Debris Program Office (ODPO), in concert with the DRAGONS consortium, to provide information on the sub-millimeter scale orbital debris environment. The SDS demonstrated the capacity to read 4 resistive grids at 1 Hz, 40 acoustic sensors at 500 kHz, and record and downlink impact data to the ground. Observable and derived data from the SDS could provide information to models that are critical to understanding risks the small debris environment poses to spacecraft in low Earth orbit. The technology demonstrated by the SDS is a major step forward in monitoring and characterizing the space debris environment. This paper will address the technical performance of the SDS during its operational lifetime and its realization of technical and scientific goals. The SDS was intended to operate for 3 years; however, the payload incurred multiple anomalies during its operational life. Subsequently termed “Anomaly #1,” the first was the symptomatic loss of low data rate 1553 channel command and telemetry. The second, Anomaly #2, was loss of all low- and medium-data rate (Ethernet) telemetry. Anomaly #2 proved to be unrecoverable, leading to loss of the payload after approximately 26 days on-board the ISS. Therefore, this paper also addresses the anomalies that occurred during operation of the SDS, their attribution, and their resolution. Lessons learned are described when relevant to anomaly identification, attribution, and resolution.

Anz-Meador, P.↗
NASA NTRS2019

Challenges Using the Linux Network Stack for Real-Time Communication

Starting in the early 2000s, human-in-the-loop (HITL) simulation groups at NASA and the Air Force Research Lab began using the Linux network stack for some real-time communication. More recently, SpaceX has adopted Ethernet as the primary bus technology for its Falcon launch vehicles and Dragon capsules. As the Linux network stack makes its way from ground facilities to flight critical systems, it is necessary to recognize that the network stack is optimized for communication over the open Internet, which cannot provide latency guarantees. The Internet protocols and their implementation in the Linux network stack contain numerous design decisions that favor throughput over determinism and latency. These decisions often require workarounds in the application or customization of the stack to maintain a high probability of low latency on closed networks, especially if the network must be fault tolerant to single event upsets.

Madden, Michael M.↗
NASA NTRSDate not supplied

Preparations for Tomographic Background-Oriented Schlieren Measurements in the 11-by 11-Foot Transonic Wind Tunnel

Efforts from a collaboration involving NASA’s Langley, Glenn, and Ames Research Centers to construct and test a tomographic background-oriented schlieren system in preparation for testing at the Ames 11-by 11-foot Transonic Wind Tunnel are discussed. To prepare for the test and to evaluate the probability of success, a mock-up of the tunnel test section was constructed at Langley. Schematics and renderings of the tunnel were used to place eight gigabit Ethernet CMOS cameras circumferentially around approximately 180° of the mock-up. Camera modules designed in-house were used to provide on-axis lighting to get maximum intensity return from the retroreflective backgrounds. A data acquisition system was designed to control the eight cameras and light sources with an acquisition rate of 4 Hz. A novel method for creation of the speckled background was developed for the test, enabling simple application and removal of the material on the tunnel walls. A tea light candle and a heat gun with two different nozzle shape attachments were used to provide an index of refraction gradient field to assess the quality of the 2D and tomographic results from the system. The heat gun was again used as an initial test article after the camera system had been set up at the Ames tunnel, giving similar results to those seen at the mock-up, and indicating a high probability of success for the testing campaign.

Joshua M. Weisberger↗
NASA NTRS1999

Climate Ocean Modeling on a Beowulf Class System

With the growing power and shrinking cost of personal computers, the availability of fast ethernet interconnections, and public domain software packages, it is now possible to combine them to build desktop parallel computers at a fraction of what it would cost to buy systems of comparable power from supercomputer companies.

Beowulf↗
NASA NTRS2017

Towards a Qualification Data Set: Expanded SEE Data on the P2020 Processor

Earlier P2020 SEE data are compared and expanded to a recent die revision, significantly increasing samples tested by protons by five devices, and by heavy ions by five devices. Earlier tested SEE types are found to be fairly similar in register, L1 cache, L2 cache, and CPU crashes. New test methods give SEE performance for the flash memory controller, watchdog circuit, and a built-in Ethernet port on the P2020 processor. Results from heavy ion and proton tests are presented, with data separated over a large number of specific error types and test programs.

Vartanian, Sargeh↗
NASA NTRS2019

A common platform for DSN receiver development

NASA's Deep Space Network is currently updating a number of sub systems within the Signal Processing Centers at its Deep Space Communication Complexes in order to modernize aging equipment in the downlink receivers for telemetry, tracking, radio science, and radio astronomy. To reduce development costs and increase commonality among these traditionally custom-built receivers, the implementation team has developed a flexible architecture built primarily around commercial off-the-shelf hardware compliant with the Micro Telecommunications Computing Architecture (uTCA) specification and commercial high speed 10Gbit Ethernet switches. Custom firmware and software are being developed to perform the required signal processing functions needed to replace the legacy systems in a phased implementation approach which establishes a new digital Intermediate Frequency (IF) signal distribution system first, followed by implementations of various receiver functions as dictated by need. The first of these new receivers, the Open Loop Receiver, will come online in the Fall of 2018. A description of the new architecture, referred to as the “Common Platform”, will be provided followed by an overview of the phased implementation approach and initial OLR performance results.

Navarro, Robert↗
NASA NTRSDate not supplied

Advancements in Force and Angle Measurement by the NFMTC

The National Force Measurement Technology Capability (NFMTC) is a nationwide partnership established in 2008 and sponsored by NASA’s Aeronautics Evaluation and Test Capabilities (AETC) project to maintain and further develop force and angle measurement capabilities primarily for NASA’s ground test facilities. One of the NFMTC’s primary objectives is to develop new force and angle measurement capabilities to meet the needs of researchers testing in NASA’s ground test facilities. This work will highlight several new capabilities that are either at or near operational readiness. A new six-component flow-through balance was designed and fabricated to support an upcoming retropropulsion test campaign at the NASA Langley Unitary Plan Wind Tunnel. The balance employs membranes in place of bellows, which have historically been used, and passes the flow through load bearing parts of the balance. Flow through the balance is optimized via the addition of flow guides, which are manufactured as separate parts, and attached to the balance. Calibration of this new flow-through balance demonstrates that it can suitably characterize the load and pressure ranges it was designed for, which provides aero researchers a new tool to directly measure retropropulsion performance of powered descent vehicles. Balances used in NASA’s ground test facilities are typically either single-piece balances or floating-frame balances. Historically, these two types of balances have generally used different front-end (model) attachments. Single-piece balances generally have a cylindrical front end that is forward of any measuring sections and at a reduced diameter relative to the balance outer diameter. Floating-frame balances generally have front end fits that extend over one or more measuring sections and that engage at the balance outer diameter. Recently, the NFMTC fabricated a single-piece balance with a front end fit that is compatible with the hardware used to calibrate floating-frame balances. Calibration results evaluating this front end fit will be presented. From a recent survey of angle measurement needs, the development of smaller angle measurement packages was identified as one area of improvement. Micro-electromechanical systems (MEMS) are continually being refined to provide high performance accelerometers that are a fraction of the volume of the quartz flexure based accelerometers that are standard in wind tunnels. A survey of commercial off-the-shelf MEMS accelerometers was conducted, and it identified the Safran Colibrys MS lines to be of adequate performance. Single-axis test boards and tri-axis rigid-flex production boards were designed and fabricated with a volume of approximately .18 cubic inches. The boards were designed to provide all the necessary conditioning for the MEMS accelerometers at levels to meet or exceed all requirements for the MS line sensors. Preliminary testing of these assembled sensor packages has demonstrated acceptable performance for wind-tunnel angle measurement. Several new rotating balances are at various stages of completion for NASA Glenn Research Center’s fan drive rigs. These balances provide direct measurement of thrust and torque of a driven fan or fan section to provide an estimate of fan efficiency and net thrust. Three two-component balances have been recently completed, and one six-component balance is in active development. A custom rotating telemetry system has been developed to support testing with these balances, and the telemetry system is integrated into the forward end of each one. The telemetry system is designed to remove mechanical sliprings by using an optical ethernet-based slipring for data transmission.

Force measurement↗