SEARCH · Search NASA

Results for “command process”

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.

SourceResearch connectionFrom yearThrough year

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

At least 1,063 records · Page 59

All sources NASA NTRS DOE OSTI

NASA NTRS2008

Enabling and Enhancing Space Mission Success and Reduction of Risk through the Application of an Integrated Data Architecture

The engineering phases of design, development, test, and evaluation (DDT and E) and subsequent planning, preparation, and operation (Ops) of space vehicles in a complex and distributed environment requires massive and continuous flows of information across the enterprise and across temporal stages of the vehicle lifecycle. The resulting capabilities at each subsequent stage depend in part on the capture, preparation, storage, and subsequent provision of information from prior stages. The United States National Aeronautics and Space Administration (NASA) is currently designing a fleet of new vehicles that will replace the Space Shuttle and expand space operations and exploration capabilities. This includes the 2 stage human rated lift vehicle Ares 1 and its associated crew vehicle the Orion, and a service module; the heavy lift cargo vehicle, Ares 5, and an associated cargo stage known as the Earth Departure Stage; and a Lunar Lander vehicle that contains a descent stage, and ascent stage, and a habitation module. A variety of concurrent assorted ground operations infrastructure including software and facilities are also being developed, assorted technology and assembly designs and development for equipment such as EVA suits, life support systems, command and control technologies are also in the pipeline. The development is occurring in a distributed manner, with project deliverables being contributed by a large and diverse assortment of vendors and most space faring nations. Critical information about all of the components, software, and procedures must be shared during the DDT and E phases and then made readily available to the mission operations staff for access during the planning, preparation, and operations phases, and also need to be readily available for system to system interactions. The Constellation Data Systems Project (CxDS) is identifying the needs, and designing and deploying systems and processes to support these needs. This paper details the steps and processes that NASA is applying within the Constellation Program to manage this data and information, and to insure that the correct information is available, correctly annotated, and can be provisioned digitally to enhance response times, and support engineering analysis and anomaly resolution.

Brummett, Robert C.↗

NASA NTRS2006

Real-Time Diagnosis of Faults Using a Bank of Kalman Filters

A new robust method of automated real-time diagnosis of faults in an aircraft engine or a similar complex system involves the use of a bank of Kalman filters. In order to be highly reliable, a diagnostic system must be designed to account for the numerous failure conditions that an aircraft engine may encounter in operation. The method achieves this objective though the utilization of multiple Kalman filters, each of which is uniquely designed based on a specific failure hypothesis. A fault-detection-and-isolation (FDI) system, developed based on this method, is able to isolate faults in sensors and actuators while detecting component faults (abrupt degradation in engine component performance). By affording a capability for real-time identification of minor faults before they grow into major ones, the method promises to enhance safety and reduce operating costs. The robustness of this method is further enhanced by incorporating information regarding the aging condition of an engine. In general, real-time fault diagnostic methods use the nominal performance of a "healthy" new engine as a reference condition in the diagnostic process. Such an approach does not account for gradual changes in performance associated with aging of an otherwise healthy engine. By incorporating information on gradual, aging-related changes, the new method makes it possible to retain at least some of the sensitivity and accuracy needed to detect incipient faults while preventing false alarms that could result from erroneous interpretation of symptoms of aging as symptoms of failures. The figure schematically depicts an FDI system according to the new method. The FDI system is integrated with an engine, from which it accepts two sets of input signals: sensor readings and actuator commands. Two main parts of the FDI system are a bank of Kalman filters and a subsystem that implements FDI decision rules. Each Kalman filter is designed to detect a specific sensor or actuator fault. When a sensor or actuator fault occurs, large estimation errors are generated by all filters except the one using the correct hypothesis. By monitoring the residual output of each filter, the specific fault that has occurred can be detected and isolated on the basis of the decision rules. A set of parameters that indicate the performance of the engine components is estimated by the "correct" Kalman filter for use in detecting component faults. To reduce the loss of diagnostic accuracy and sensitivity in the face of aging, the FDI system accepts information from a steady-state-condition-monitoring system. This information is used to update the Kalman filters and a data bank of trim values representative of the current aging condition.

Kobayashi, Takahisa↗

NASA NTRS2014

The CCSDS Next Generation Space Data Link Protocol (NGSLP)

The CCSDS space link protocols i.e., Telemetry (TM), Telecommand (TC), Advanced Orbiting Systems (AOS) were developed in the early growth period of the space program. They were designed to meet the needs of the early missions, be compatible with the available technology and focused on the specific link environments. Digital technology was in its infancy and spacecraft power and mass issues enforced severe constraints on flight implementations. Therefore the Telecommand protocol was designed around a simple Bose, Hocquenghem, Chaudhuri (BCH) code that provided little coding gain and limited error detection but was relatively simple to decode on board. The infusion of the concatenated Convolutional and Reed-Solomon codes5 for telemetry was a major milestone and transformed telemetry applications by providing them the ability to more efficiently utilize the telemetry link and its ability to deliver user data. The ability to significantly lower the error rates on the telemetry links enabled the use of packet telemetry and data compression. The infusion of the high performance codes for telemetry was enabled by the advent of digital processing, but it was limited to earth based systems supporting telemetry. The latest CCSDS space link protocol, Proximity-1 was developed in early 2000 to meet the needs of short-range, bi-directional, fixed or mobile radio links characterized by short time delays, moderate but not weak signals, and short independent sessions. Proximity-1 has been successfully deployed on both NASA and ESA missions at Mars and is planned to be utilized by all Mars missions in development. A new age has arisen, one that now provides the means to perform advanced digital processing in spacecraft systems enabling the use of improved transponders, digital correlators, and high performance forward error correcting codes for all communications links. Flight transponders utilizing digital technology have emerged and can efficiently provide the means to make the next leap in performance for space link communications. Field Programmable Gate Arrays (FPGAs) provide the capability to incorporate high performance forward error correcting codes implemented within software transponders providing improved performance in data transfer, ranging, link security, and time correlation. Given these synergistic technological breakthroughs, the time has come to take advantage of them in applying them to both on going (e.g., command, telemetry) and emerging (e.g., space link security, optical communication) space link applications. However one of the constraining factors within the Data Link Layer in realizing these performance gains is the lack of a generic transfer frame format and common supporting services amongst the existing CCSDS link layer protocols. Currently each of the four CCSDS link layer protocols (TM, TC, AOS, and Proximity-1) have unique formats and services which prohibits their reuse across the totality of all space link applications of CCSDS member space agencies. For example, Mars missions. These missions implement their proximity data link layer using the Proximity-1 frame format and the services it supports but is still required to support the direct from Earth (TC) protocols and the Direct To Earth (AOS/TM) protocols. The prime purpose of this paper, is to describe a new general purpose CCSDS Data Link layer protocol, the NGSLP that will provide the required services along with a common transfer frame format for all the CCSDS space links (ground to/from space and space to space links) targeted for emerging missions after a CCSDS agency-wide coordinated date. This paper will also describe related options that can be included for the Coding and Synchronization sub-layer of the Data Link layer to extend the capacities of the link and additionally provide an independence of the transfer frame sub-layer from the coding sublayer. This feature will provide missions the option of running either the currently performed synchronous coding and transfer frame data link or an asynchronous coding/frame data link, in which the transfer frame length is independent of the block size of the code. The benefits from the elimination of this constraint (frame synchronized to the code block) will simplify the interface between the transponder and the data handling equipment and reduce implementation costs and complexities. The benefits include: inclusion of encoders/decoders into transmitters and receivers without regard to data link protocols, providing the ability to insert latency sensitive messages into the link to support launch, landing/docking, telerobotics. and Variable Coded Modulation (VCM). In addition the ability to transfer different sized frames can provide a backup for delivering stored anomaly engineering data simultaneously with real time data, or relaying of frames from various sources onto a trunk line for delivery to Earth.

Kazz, Greg J.↗

NASA NTRSDate not supplied

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗

NASA NTRSDate not supplied

Emulation of Core Flight System Applications for Flight Software Development and Validation

Cody Wheeler↗

NASA NTRSDate not supplied

Distributed Spacecraft Autonomy - Development of Swarm Autonomy Capability and Scalability for Spacecraft

The Distributed Spacecraft Autonomy project is developing a suite of software tools that enable an operator to command and receive data from a swarm as a single entity, enable a swarm to autonomously coordinate its actions via distributed decision making and reactive closed-loop control, and model swarm behavior in the presence of anomalies or failures. Our use case is the mapping of the electron density of the ionosphere using radio tomography by coordinating the selection of appropriate GPS channels, and by recording Total Electron Count (TEC) measurements. DSA will be demonstrated onboard the NASA Ames Starling mission – a swarm of four small, LEO spacecraft, scheduled to launch in 2021. We will also perform a ground demonstration with simulated and hardware-in-the-loop elements, to validate the tools for controlling swarms of up to 100 assets. The capability to communicate autonomously between the swarm satellites is demonstrated via a sophisticated simulation architecture. Historical Plasmasphere TEC data obtained via dual-band Novatel GPS Receivers are utilized as a representative input dataset for the swarm. The representative TEC data and GPS satellite observability information is fed to the autonomous software package in place of a true real-time ground data collection process. The swarm satellites actively share status updates amongst one another and utilize multi-agent decision making to optimally identify regions of interest in the TEC distribution. The software, aware of the bandwidth limitations of the swarm satellites, prioritizes explorative measurements, which define the range of observability for the satellites, as well as exploitative measurements, which focus on maximizing the observance potential of regions with prolonged, elevated TEC density. The science of this study can ultimately be used to determine the dynamics and coupling of Earth’s magnetosphere, ionosphere, and atmosphere and their response to solar and terrestrial inputs. The findings can be applied to the imaging of critical, transient phenomena in the magnetosphere in later missions. Meanwhile, the swarm autonomy capabilities have far reaching potential in future satellite missions. As an experimental demonstration of the autonomous capabilities of the network, a message is first printed within a core Flight Executive (cFE) application. Two cFE applications that communicate with one another within the same core Flight System (cFS) are shown. Communication between mission applications on the internal cFE bus is extended to utilize Data Distribution Service (DDS) for vehicle-to-vehicle networking. The DDS middleware provides reliable delivery, routing, and topic subscription features over User Datagram Protocol (UDP). Leveraging Linux containerization, a networked set of satellite instances are generated by script to simulate swarm behavior. Swarm commanding and synchronization through the network is demonstrated under various topologies and data-loss conditions. Finally, autonomous swarm scalability from 2 satellites to 100 satellites is shown.

Distributed Autonomy↗

NASA NTRS1972

Fourier plane filters

An electrically addressed liquid crystal Fourier plane filter capable of real time optical image processing is described. The filter consists of two parts: a wedge filter having forty 9 deg segments and a ring filter having twenty concentric rings in a one inch diameter active area. Transmission of the filter in the off (transparent) state exceeds fifty percent. By using polarizing optics, contrast as high as 10,000:1 can be achieved at voltages compatible with FET switching technology. A phenomenological model for the dynamic scattering is presented for this special case. The filter is designed to be operated from a computer and is addressed by a seven bit binary word which includes an on or off command and selects any one of the twenty rings or twenty wedge pairs. The overall system uses addressable latches so that once an element is in a specified state, it will remain there until a change of state command is received. The drive for the liquid crystal filter is ? 30 V peak at 30 Hz to 70 Hz. These parameters give a rise time for the scattering of 20 msec and a decay time of 80 to 100 msec.

Oliver, D. S.↗

NASA NTRS1989

The flight telerobotic servicer Tinman concept: System design drivers and task analysis

A study was conducted to develop a preliminary definition of the Flight Telerobotic Servicer (FTS) that could be used to understand the operational concepts and scenarios for the FTS. Called the Tinman, this design concept was also used to begin the process of establishing resources and interfaces for the FTS on Space Station Freedom, the National Space Transportation System shuttle orbiter, and the Orbital Maneuvering vehicle. Starting with an analysis of the requirements and task capabilities as stated in the Phase B study requirements document, the study identified eight major design drivers for the FTS. Each of these design drivers and their impacts on the Tinman design concept are described. Next, the planning that is currently underway for providing resources for the FTS on Space Station Freedom is discussed, including up to 2000 W of peak power, up to four color video channels, and command and data rates up to 500 kbps between the telerobot and the control station. Finally, an example is presented to show how the Tinman design concept was used to analyze task scenarios and explore the operational capabilities of the FTS. A structured methodology using a standard terminology consistent with the NASA/National Bureau of Standards Standard Reference Model for Telerobot Control System Architecture (NASREM) was developed for this analysis.

Andary, J. F.↗

NASA NTRS1998

Intelligent Systems and Advanced User Interfaces for Design, Operation, and Maintenance of Command Management Systems

Historically Command Management Systems (CMS) have been large, expensive, spacecraft-specific software systems that were costly to build, operate, and maintain. Current and emerging hardware, software, and user interface technologies may offer an opportunity to facilitate the initial formulation and design of a spacecraft-specific CMS as well as a to develop a more generic or a set of core components for CMS systems. Current MOC (mission operations center) hardware and software include Unix workstations, the C/C++ and Java programming languages, and X and Java window interfaces representations. This configuration provides the power and flexibility to support sophisticated systems and intelligent user interfaces that exploit state-of-the-art technologies in human-machine systems engineering, decision making, artificial intelligence, and software engineering. One of the goals of this research is to explore the extent to which technologies developed in the research laboratory can be productively applied in a complex system such as spacecraft command management. Initial examination of some of the issues in CMS design and operation suggests that application of technologies such as intelligent planning, case-based reasoning, design and analysis tools from a human-machine systems engineering point of view (e.g., operator and designer models) and human-computer interaction tools, (e.g., graphics, visualization, and animation), may provide significant savings in the design, operation, and maintenance of a spacecraft-specific CMS as well as continuity for CMS design and development across spacecraft with varying needs. The savings in this case is in software reuse at all stages of the software engineering process.

Mitchell, Christine M.↗

NASA NTRS2009

Probabilistic Risk Assessment for Decision Making During Spacecraft Operations

Decisions made during the operational phase of a space mission often have significant and immediate consequences. Without the explicit consideration of the risks involved and their representation in a solid model, it is very likely that these risks are not considered systematically in trade studies. Wrong decisions during the operational phase of a space mission can lead to immediate system failure whereas correct decisions can help recover the system even from faulty conditions. A problem of special interest is the determination of the system fault protection strategies upon the occurrence of faults within the system. Decisions regarding the fault protection strategy also heavily rely on a correct understanding of the state of the system and an integrated risk model that represents the various possible scenarios and their respective likelihoods. Probabilistic Risk Assessment (PRA) modeling is applicable to the full lifecycle of a space mission project, from concept development to preliminary design, detailed design, development and operations. The benefits and utilities of the model, however, depend on the phase of the mission for which it is used. This is because of the difference in the key strategic decisions that support each mission phase. The focus of this paper is on describing the particular methods used for PRA modeling during the operational phase of a spacecraft by gleaning insight from recently conducted case studies on two operational Mars orbiters. During operations, the key decisions relate to the commands sent to the spacecraft for any kind of diagnostics, anomaly resolution, trajectory changes, or planning. Often, faults and failures occur in the parts of the spacecraft but are contained or mitigated before they can cause serious damage. The failure behavior of the system during operations provides valuable data for updating and adjusting the related PRA models that are built primarily based on historical failure data. The PRA models, in turn, provide insight into the effect of various faults or failures on the risk and failure drivers of the system and the likelihood of possible end case scenarios, thereby facilitating the decision making process during operations. This paper describes the process of adjusting PRA models based on observed spacecraft data, on one hand, and utilizing the models for insight into the future system behavior on the other hand. While PRA models are typically used as a decision aid during the design phase of a space mission, we advocate adjusting them based on the observed behavior of the spacecraft and utilizing them for decision support during the operations phase.

dynamic fault trees↗

NASA NTRS2020

Distributed Spacecraft Autonomy (DSA): Development of Swarm Autonomy Capability and Scalability for Spacecraft

The Distributed Spacecraft Autonomy project is developing a suite of software tools that enable an operator to command and receive data from a swarm as a single entity, enable a swarm to autonomously coordinate its actions via distributed decision making and reactive closed-loop control, and model swarm behavior in the presence of anomalies or failures. Our use case is the mapping of the electron density of the ionosphere using radio tomography by coordinating the selection of appropriate GPS channels, and by recording Total Electron Count (TEC)measurements. DSA will be demonstrated on board the NASA Ames Starling mission a swarm of four small, LEO spacecraft, scheduled to launch in 2021. We will also perform a ground demonstration with simulated and hardware-in-the-loop elements, to validate the tools for controlling swarms of up to 100 assets.The capability to communicate autonomously between the swarm satellites is demonstrated via a sophisticated simulation architecture. Historical Plasma sphere TEC data obtained via dual-band Novatel GPS Receivers are utilized as a representative input data set for the swarm. The representative TEC data and GPS satellite observability information is fed to the autonomous software package in place of a true real-time ground data collection process. The swarm satellites actively share status updates amongst one another and utilize multi-agent decision making to optimally identify regions of interest in the TEC distribution. The software,aware of the bandwidth limitations of the swarm satellites, prioritizes explorative measurements,which define the range of observability for the satellites, as well as exploitative measurements,which focus on maximizing the observance potential of regions with prolonged, elevated TEC density. The science of this study can ultimately be used to determine the dynamics and coupling of Earth's magnetosphere, ionosphere, and atmosphere and their response to solar and terrestrial inputs. The findings can be applied to the imaging of critical, transient phenomena in the magnetosphere in later missions. Meanwhile, the swarm autonomy capabilities have far reaching potential in future satellite missions.As an experimental demonstration of the autonomous capabilities of the network, a message is first printed within a core Flight Executive (cFE) application. Two cFE applications that communicate with one another within the same core Flight System (cFS) are shown.Communication between mission applications on the internal cFE bus is extended to utilize Data Distribution Service (DDS) for vehicle-to-vehicle networking. The DDS middle ware provides reliable delivery, routing, and topic subscription features over User Data gram Protocol (UDP).Leveraging Linux containerization, a networked set of satellite instances are generated by script to simulate swarm behavior. Swarm commanding and synchronization through the network is demonstrated under various topologies and data-loss conditions. Finally, autonomous swarms calability from 2 satellites to 100 satellites is shown.

Fugate, Jason↗

NASA NTRS1991

Geostationary Meteorological Satellite-5 (GMS-5)

The Geostationary Meteorological Satellite (GMS-5), which is being developed by the National Space Development Agency of Japan (NASDA), is the fifth geostationary, spin stabilized, weather satellite. Its purposes are to observe cataclysmic events such as hurricanes, typhoons, and regional weather phenomena; to relay meteorological data from surface collection points to the Data Processing Center in Japan; and to transmit processing imaging data for facsimile reproduction. The satellite will be launched from the Tanegashima Space Center (TaSC) in Japan by a type H-II launch vehicle. The Deep Space Network (DSN) will support the transfer and drift orbit mission phases. The coverage will consist of the 26-m antennas as prime and the 34-m antenna at Madrid as backup support for launch through drift orbit. Maximum support will consist of two 8-hour tracks per station for a seven day period, plus 23 days of contingency support from all complexes. Information is given in tabular form for DSN support, frequency assignments, telemetry, command and tracking station responsibility.

Horii, M.↗

NASA NTRS1993

Superfluid Helium On-Orbit Transfer (SHOOT) flight demonstration

The Superfluid Helium On-Orbit Transfer (SHOOT) Flight Demonstration was an attached Shuttle payload mounted on a Hitchhiker cross-bay carrier which flew on STS-57 in June of 1993. SHOOT successfully demonstrated the handling and transfer of superfluid helium between two containers, called dewars, in low gravity. SHOOT was a class C payload and for the STS-57 mission was termed a complex secondary payload. The primaries were the retrieval of the EURECA carrier and a collection of modular experiments contained in SPACEHAB. Because the liquid helium was continuously boiling off, SHOOT's activities were scheduled for the first three days of the mission, concurrent with some SPACEHAB experiments, but well before the EURECA retrieval. Control of the SHOOT experiment was highly interactive and originated primarily from the Goddard Payload Operations and Control Center (POCC). Transfer and calibration activities required continuous command windows of up to 50 minutes duration and up to 80 minutes out of each orbit. Occasionally the crew controlled the experiment using the Payload General Support Computer (PGSC) when near-real time control and monitoring was required. SHOOT also placed considerable demands on the orbiter, including a pitch rotation of 3 deg./sec for 15 minutes, and translational burns using both the aft and forward RCS jets to generate accelerations up to 7 milli-g. The basis for these and other requirements are discussed. Interacion with the crew and timing of crew activity during the mission will be detailed. The processing flow of SHOOT at KSC is described with emphasis on the tradeoffs for vertical, as opposed to horizontal, installation in the orbiter. Finally, some lessons learned are presented that are relevant to future cryogenic and Hitchhiker payloads.

Shirron, Peter↗

NASA NTRS2008

Implementation Challenges for Multivariable Control: What You Did Not Learn in School

Multivariable control allows controller designs that can provide decoupled command tracking and robust performance in the presence of modeling uncertainties. Although the last two decades have seen extensive development of multivariable control theory and example applications to complex systems in software/hardware simulations, there are no production flying systems aircraft or spacecraft, that use multivariable control. This is because of the tremendous challenges associated with implementation of such multivariable control designs. Unfortunately, the curriculum in schools does not provide sufficient time to be able to provide an exposure to the students in such implementation challenges. The objective of this paper is to share the lessons learned by a practitioner of multivariable control in the process of applying some of the modern control theory to the Integrated Flight Propulsion Control (IFPC) design for an advanced Short Take-Off Vertical Landing (STOVL) aircraft simulation.

Garg, Sanjay↗

NASA NTRS2004

Readout of DSN Monitor Data

DSN Monitor Data Reader is a computer program that, as its name suggests, reads file of monitor data from the Deep Space Network (DSN). The monitor data constitute information on the status and performance of tracking, telemetry, command, and pointing equipment at the DSN antennas. The DSN has recently introduced a new, more advanced monitor data format, denoted 0158-Mon, that is based on the standard formatted data unit (SFDU) and compressed header data objects (CHDO) of the Consultative Committee for Space Data Systems (CCSDS). The 0158-Mon data format is a very flexible generic format that provides for specific variable-length formats and for self-identifying parameters that obviate the proprietary NASA Communications (NASCOM) bit-packed formats of the past. The monitor data SFDUs are also encapsulated in Standard DSN Blocks and routed to DSN customers for processing at their local mission control centers. This program helps a DSN customer to read and parse the monitor data to assess the statuses of the DSN stations in support of spacecraft flight operations.

Levister, Katherine↗

NASA NTRS1987

Programming methodology for a general purpose automation controller

The General Purpose Automation Controller is a multi-processor architecture for automation programming. A methodology has been developed whose aim is to simplify the task of programming distributed real-time systems for users in research or manufacturing. Programs are built by configuring function blocks (low-level computations) into processes using data flow principles. These processes are activated through the verb mechanism. Verbs are divided into two classes: those which support devices, such as robot joint servos, and those which perform actions on devices, such as motion control. This programming methodology was developed in order to achieve the following goals: (1) specifications for real-time programs which are to a high degree independent of hardware considerations such as processor, bus, and interconnect technology; (2) a component approach to software, so that software required to support new devices and technologies can be integrated by reconfiguring existing building blocks; (3) resistance to error and ease of debugging; and (4) a powerful command language interface.

Sturzenbecker, M. C.↗

NASA NTRS2019

Analysis of At-Altitude LTE Power Spectra for C2 Communications for UAS Traffic Management

The National Aeronautics and Space Administration’s (NASA) Unmanned Aircraft Systems Traffic Management (UTM) project works to develop tools and technologies essential for safely enabling civilian low-altitude small Unmanned Aerial Systems (sUAS, also known as drones) operations. This paper presents results of work completed in the paper [1] presented at the 2018 ICNS conference where proposed approaches were explored for evaluating and analyzing sUAS Command and Control (C2) links based on commercial cellular networks. This paper focuses on the UTM Project’s Technology Capability Level 3 (TCL-3) test results which address the communications portion identified within the same paper. A software defined radio (SDR) was flown as a sUAS payload to capture received signal spectrum in Long Term Evolution (LTE) frequency bands of interest. The purpose was to measure the RF environment at UTM altitudes to characterize the interference potential. The SDR payload was flown at various stationary altitudes where the LTE over-the-air complex (I/Q) samples were captured by the SDR and later post-processed. The SDR received inputs through an omnidirectional antenna. The complex samples captured were an aggregate of transmissions received from all line-of-sight (LOS) towers within the geographic area for the specific radio frequency bandwidth the SDR is programmed to capture. Using this approach, the complex samples captured do not distinguish between the various eNodeB's (Long Term Evolution (LTE) transmitting towers). The complex samples were post processed via a Discrete Fourier Transform (DFT) algorithm to view the captured spectrum along with the power levels across the captured LTE bandwidth. This SDR payload process of capturing complex samples was done at two different regions within the US: 1) NASA's Ames Research Center (ARC) in Moffett Field, CA, and 2) Griffiss Airfield in Rome, NY. The data capture at the ARC site was done at two physical locations within the Ames campus where many stationary altitude captures where done as high as 800 ft. above ground level (AGL). The data captured at the Griffiss Airport (also known as the NY Corridor Site) were acquired at one location with three specific stationary altitude levels – {Ground Level (GL), 300 ft., and 400 ft.}. The LTE spectrum power levels were captured for two LTE carriers, AT&T and Verizon, at both sites where their respective spectra and power levels were measured and compared at various altitudes. The overall results show that there is an increase in LTE spectrum power levels at higher altitudes for drones. A detailed analysis of this data and conclusions drawn from the results are presented in this paper.

Kerczewski, Robert J.↗

NASA NTRS2002

STS-112 Crew Interviews: Ashby

STS-112 Mission Commander Jeffrey Ashby is seen during this preflight interview, answering questions about his inspiration in becoming an astronaut and his career path and provides an overview of the mission. Ashby outlines his role in the mission in general, and specifically during the docking and extravehicular activities (EVAs). He describes the payload (S1 truss) and the importance that the S1 truss will have in the development of the International Space Station (ISS). Ashby discusses the delivery and installation of the S1 truss scheduled to be done in the planned EVAs in some detail. He touches on the use and operation of the Canadarm 2 robotic arm in this process and outlines what supplies will be exchanged with the resident crew of the ISS during transfer activities. He ends with his thoughts on the value of the ISS in fostering international cooperation.

Source record↗