SEARCH · Engineering Papers

Results for “Control setting and logic”

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 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS1989

A predictive guidance algorithm for Mars entry

This report presents the derivation, logic, and performance of a Mars entry guidance algorithm for the Mars Rover Sample Return Mission. This algorithm guides the Mars entry vehicle along an equilibrium glide trajectory designed to satisfy a set of equality and inequality constraints at chute deploy. An equilibrium glide assumption permits analytic prediction of terminal state conditions and eliminates the need for determining numeric state sensitivities. Trajectory deviations due to dispersions or uncertainties in Martian atmosphere, vehicle aerodynamics, or entry interface conditions are accommodated simply by predicting the compensating equilibrium glide profile and achieving this profile with the available lift control. This Mars Predictive Equilibrium Glide guidance scheme was tested on a range of vehicle configurations with a variety of aerodynamic, atmosphere, and trajectory dispersions with a high degree of success.

Tigges, M. A.↗

NASA NTRS1991

Adaptive control with an expert system based supervisory level

Adaptive control is presently one of the methods available which may be used to control plants with poorly modelled dynamics or time varying dynamics. Although many variations of adaptive controllers exist, a common characteristic of all adaptive control schemes, is that input/output measurements from the plant are used to adjust a control law in an on-line fashion. Ideally the adjustment mechanism of the adaptive controller is able to learn enough about the dynamics of the plant from input/output measurements to effectively control the plant. In practice, problems such as measurement noise, controller saturation, and incorrect model order, to name a few, may prevent proper adjustment of the controller and poor performance or instability result. In this work we set out to avoid the inadequacies of procedurally implemented safety nets, by introducing a two level control scheme in which an expert system based 'supervisor' at the upper level provides all the safety net functions for an adaptive controller at the lower level. The expert system is based on a shell called IPEX, (Interactive Process EXpert), that we developed specifically for the diagnosis and treatment of dynamic systems. Some of the more important functions that the IPEX system provides are: (1) temporal reasoning; (2) planning of diagnostic activities; and (3) interactive diagnosis. Also, because knowledge and control logic are separate, the incorporation of new diagnostic and treatment knowledge is relatively simple. We note that the flexibility available in the system to express diagnostic and treatment knowledge, allows much greater functionality than could ever be reasonably expected from procedural implementations of safety nets. The remainder of this chapter is divided into three sections. In section 1.1 we give a detailed review of the literature in the area of supervisory systems for adaptive controllers. In particular, we describe the evolution of safety nets from simple ad hoc techniques, up to the use of expert systems for more advanced supervision capabilities.

Sullivan, Gerald A.↗

NASA NTRS2009

A Method for Determining the Nominal Occular Hazard Zone for Gaussian Beam Laser Rangers with a Firmware Controlled Variable Focal Length

LIDAR systems that maintain a constant beam spot size on a retroreflector in order to increase the accuracy of bearing and ranging data must use a software controlled variable position lens. These systems periodically update the estimated range and set the position of the focusing lens accordingly. In order to precisely calculate the r NOHD for such a system, the software method for setting the variable position lens and gaussian laser propagation can be used to calculate the irradiance at any point given the range estimation. NASA s Space Shuttle LIDAR, called the Trajectory Control Sensor (TCS), uses this configuration. Analytical tools were developed using Excel and VBA to determine the radiant energy to the International Space Station (ISS) crewmembers eyes while viewing the shuttle on approach and departure. Various viewing scenarios are considered including the use of through-the-lens imaging optics and the window transmissivity at the TCS wavelength. The methodology incorporates the TCS system control logic, gaussian laser propagation, potential failure mode end states, and guidance from American National Standard for the Safe Use of Lasers (ANSI Z136.1-2007). This approach can be adapted for laser safety analyses of similar LIDAR systems.

Picco, C. E.↗

NASA NTRS1996

SAM-FS: LSC's New Solaris-Based Storage Management Product

SAM-FS is a full featured hierarchical storage management (HSM) device that operates as a file system on Solaris-based machines. The SAM-FS file system provides the user with all of the standard UNIX system utilities and calls, and adds some new commands, i.e. archive, release, stage, sls, sfind, and a family of maintenance commands. The system also offers enhancements such as high performance virtual disk read and write, control of the disk through an extent array, and the ability to dynamically allocate block size. SAM-FS provides 'archive sets' which are groupings of data to be copied to secondary storage. In practice, as soon as a file is written to disk, SAM-FS will make copies onto secondary media. SAM-FS is a scalable storage management system. The system can manage millions of files per system, though this is limited today by the speed of UNIX and its utilities. In the future, a new search algorithm will be implemented that will remove logical and performance restrictions on the number of files managed.

Angell, Kent↗

NASA NTRS2005

SCB Quantum Computers Using iSWAP and 1-Qubit Rotations

Units of superconducting circuitry that exploit the concept of the single- Cooper-pair box (SCB) have been built and are undergoing testing as prototypes of logic gates that could, in principle, constitute building blocks of clocked quantum computers. These units utilize quantized charge states as the quantum information-bearing degrees of freedom. An SCB is an artificial two-level quantum system that comprises a nanoscale superconducting electrode connected to a reservoir of Cooper-pair charges via a Josephson junction. The logical quantum states of the device, .0. and .1., are implemented physically as a pair of charge-number states that differ by 2e (where e is the charge of an electron). Typically, some 109 Cooper pairs are involved. Transitions between the logical states are accomplished by tunneling of Cooper pairs through the Josephson junction. Although the two-level system contains a macroscopic number of charges, in the superconducting regime, they behave collectively, as a Bose-Einstein condensate, making possible a coherent superposition of the two logical states. This possibility makes the SCB a candidate for the physical implementation of a qubit. A set of quantum logic operations and the gates that implement them is characterized as universal if, in principle, one can form combinations of the operations in the set to implement any desired quantum computation. To be able to design a practical quantum computer, one must first specify how to decompose any valid quantum computation into a sequence of elementary 1- and 2-qubit quantum gates that are universal and that can be realized in hardware that is feasible to fabricate. Traditionally, the set of universal gates has been taken to be the set of all 1-qubit quantum gates in conjunction with the controlled-NOT (CNOT) gate, which is a 2-qubit gate. Also, it has been known for some time that the SWAP gate, which implements square root of the simple 2-qubit exchange interaction, is as computationally universal as is the CNOT operation.

Williams, Colin↗

NASA NTRS2000

Optical Circuit Switched Protocol

The present invention is a system and method embodied in an optical circuit switched protocol for the transmission of data through a network. The optical circuit switched protocol is an all-optical circuit switched network and includes novel optical switching nodes for transmitting optical data packets within a network. Each optical switching node comprises a detector for receiving the header, header detection logic for translating the header into routing information and eliminating the header, and a controller for receiving the routing information and configuring an all optical path within the node. The all optical path located within the node is solely an optical path without having electronic storage of the data and without having optical delay of the data. Since electronic storage of the header is not necessary and the initial header is eliminated by the first detector of the first switching node. multiple identical headers are sent throughout the network so that subsequent switching nodes can receive and read the header for setting up an optical data path.

Monacos, Steve P.↗

NASA NTRS1998

The Design and Development of the SMEX-Lite Power System

This paper describes the design and development of a 250W orbit average electrical power system electronic Power Node and software for use in Low Earth Orbit missions. The mass of the Power Node is 3.6 Kg (8 lb.). The dimensions of the Power Node are 30cm x 26cm x 7.9cm (11 in. x 10.25 in x 3.1 in.) The design was realized using software, Field Programmable Gate Array (FPGA) digital logic and surface mount technology. The design is generic enough to reduce the non-recurring engineering for different mission configurations. The Power Node charges one to five, low cost, 22-cell 4 AH D-cell battery packs independently. The battery charging algorithms are executed in the power software to reduce the mass and size of the power electronic. The Power Node implements a peak-power tracking algorithm using an innovative hardware/software approach. The power software task is hosted on the spacecraft processor. The power software task generates a MIL-STD-1553 command packet to update the Power Node control settings. The settings for the battery voltage and current limits, as well as minimum solar array voltage used to implement peak power tracking are contained in this packet. Several advanced topologies are used in the Power Node. These include synchronous rectification in the bus regulators, average current control in the battery chargers and quasi-resonant converters for the Field Effect Transistor (FET) transistor drive electronics. Lastly, the main bus regulator uses a feed-forward topology with the PWM implemented in an FPGA.

Rakow, Glenn P.↗

NASA NTRS2005

Apex Reference Manual 3.0 Beta

Apex is a toolkit for constructing software that behaves intelligently and responsively in demanding task environments. Reflecting its origin at NASA where Apex continues to be developed, current applications include: a) Providing autonomous mission management and tactical control capabilities for unmanned aerial vehicles including an autonomous surveillance helicopter and a simulation prototype of an unmanned fixed-wing aircraft to be used for wildfire mapping; b) Simulating human air traffic controllers, pilots and astronauts to help predict how people might respond to changes in equipment or procedures; and c) Predicting the precise duration and sequence of routine human behaviors based on a human-computer interaction engineering technique called CPM-GOMS. Among Apex s components are a set of implemented reasoning services, such as those for reactive planning and temporal pattern recognition; a software architecture that embeds and integrates these services and allows additional reasoning elements to be added as extensions; a formal language for specifying agent knowledge; a simulation environment to facilitate prototyping and analysis; and Sherpa, a set of tools for visualizing autonomy logic and runtime behavior. In combination, these are meant to provide a flexible and usable framework for creating, testing, and deploying intelligent agent software. Overall, our goal in developing Apex is to lower economic barriers to developing intelligent software agents. New ideas about how to extend or modify the system are evaluated in terms of their impact in reducing the time, expertise, and inventiveness required to build and maintain applications. For example, potential enhancements to the AI reasoning capabilities in the system are reviewed not only for usefulness and distinctiveness, but also for their impact on the readability and general usability of Apex s behavior representation language (PDL) and on the transparency of resulting behavior. A second central part of our approach is to iteratively refine Apex based on lessons learned from as diverse a set of applications as possible. Many applications have been developed by users outside the core development team including engineers, researchers, and students. Usability is thus a central concern for every aspect of Apex visible to a user, including PDL, Sherpa, the Apex installation process, APIs, and user documentation. Apex users vary in their areas of expertise and in their familiarity with autonomy technology. Focusing on usability, a development philosophy summarized by the project motto "Usable Autonomy," has been important part of enabling diverse users to employ Apex successfully and to provide feedback needed to guide iterative, user-centered refinement.

Freed, Michael A.↗

NASA NTRS2008

Scripting Module for the Satellite Orbit Analysis Program (SOAP)

This add-on module to the SOAP software can perform changes to simulation objects based on the occurrence of specific conditions. This allows the software to encompass simulation response of scheduled or physical events. Users can manipulate objects in the simulation environment under programmatic control. Inputs to the scripting module are Actions, Conditions, and the Script. Actions are arbitrary modifications to constructs such as Platform Objects (i.e. satellites), Sensor Objects (representing instruments or communication links), or Analysis Objects (user-defined logical or numeric variables). Examples of actions include changes to a satellite orbit ( v), changing a sensor-pointing direction, and the manipulation of a numerical expression. Conditions represent the circumstances under which Actions are performed and can be couched in If-Then-Else logic, like performing v at specific times or adding to the spacecraft power only when it is being illuminated by the Sun. The SOAP script represents the entire set of conditions being considered over a specific time interval. The output of the scripting module is a series of events, which are changes to objects at specific times. As the SOAP simulation clock runs forward, the scheduled events are performed. If the user sets the clock back in time, the events within that interval are automatically undone. This script offers an interface for defining scripts where the user does not have to remember the vocabulary of various keywords. Actions can be captured by employing the same user interface that is used to define the objects themselves. Conditions can be set to invoke Actions by selecting them from pull-down lists. Users define the script by selecting from the pool of defined conditions. Many space systems have to react to arbitrary events that can occur from scheduling or from the environment. For example, an instrument may cease to draw power when the area that it is tasked to observe is not in view. The contingency of the planetary body blocking the line of sight is a condition upon which the power being drawn is set to zero. It remains at zero until the observation objective is again in view. Computing the total power drawn by the instrument over a period of days or weeks can now take such factors into consideration. What makes the architecture especially powerful is that the scripting module can look ahead and behind in simulation time, and this temporal versatility can be leveraged in displays such as x-y plots. For example, a plot of a satellite s altitude as a function of time can take changes to the orbit into account.

Carnright, Robert↗

NASA NTRS2003

Improved Autoassociative Neural Networks

Improved autoassociative neural networks, denoted nexi, have been proposed for use in controlling autonomous robots, including mobile exploratory robots of the biomorphic type. In comparison with conventional autoassociative neural networks, nexi would be more complex but more capable in that they could be trained to do more complex tasks. A nexus would use bit weights and simple arithmetic in a manner that would enable training and operation without a central processing unit, programs, weight registers, or large amounts of memory. Only a relatively small amount of memory (to hold the bit weights) and a simple logic application- specific integrated circuit would be needed. A description of autoassociative neural networks is prerequisite to a meaningful description of a nexus. An autoassociative network is a set of neurons that are completely connected in the sense that each neuron receives input from, and sends output to, all the other neurons. (In some instantiations, a neuron could also send output back to its own input terminal.) The state of a neuron is completely determined by the inner product of its inputs with weights associated with its input channel. Setting the weights sets the behavior of the network. The neurons of an autoassociative network are usually regarded as comprising a row or vector. Time is a quantized phenomenon for most autoassociative networks in the sense that time proceeds in discrete steps. At each time step, the row of neurons forms a pattern: some neurons are firing, some are not. Hence, the current state of an autoassociative network can be described with a single binary vector. As time goes by, the network changes the vector. Autoassociative networks move vectors over hyperspace landscapes of possibilities.

Hand, Charles↗

NASA NTRS2006

Preliminary Study Using Forward Reaction Control System Jets During Space Shuttle Entry

Failure or degradation of the flight control system, or hull damage, can lead to loss of vehicle control during entry. Possible failure scenarios are debris impact and wing damage that could result in a large aerodynamic asymmetry which cannot be trimmed out without additional yaw control. Currently the space shuttle uses aerodynamic control surfaces and Reaction Control System jets to control attitude. The forward jets are used for orbital maneuvering only, while the aft jets are used for yaw control during entry. This paper develops a controller for using the forward reaction control system jets as an additional control during entry, and assesses its value and feasibility during failure situations. Forward-aft jet blending logic is created, and implemented on a simplified model of the space shuttle entry flight control system. The model is validated and verified on the nonlinear, six degree-of-freedom Shuttle Engineering Simulator. A rudimentary human factors study was undertaken using the forward cockpit simulator at Johnson Space Center, to assess flying qualities of the new system and pilot workload. Results presented in the paper show that the combination of forward and aft jets provides useful additional yaw control, in addition to potential fuel savings and the ability to balance the use of the fuel in the forward and aft tanks to meet availability constraints of both forward and aft fuel tanks. Piloted simulation studies indicated that using both sets of jets while flying a damaged space shuttle reduces pilot workload, and makes the vehicle more responsive.

Restrepo, Carolina↗

NASA NTRS2005

Diagnosing Hybrid Systems: a Bayesian Model Selection Approach

In this paper we examine the problem of monitoring and diagnosing noisy complex dynamical systems that are modeled as hybrid systems-models of continuous behavior, interleaved by discrete transitions. In particular, we examine continuous systems with embedded supervisory controllers that experience abrupt, partial or full failure of component devices. Building on our previous work in this area (MBCG99;MBCG00), our specific focus in this paper ins on the mathematical formulation of the hybrid monitoring and diagnosis task as a Bayesian model tracking algorithm. The nonlinear dynamics of many hybrid systems present challenges to probabilistic tracking. Further, probabilistic tracking of a system for the purposes of diagnosis is problematic because the models of the system corresponding to failure modes are numerous and generally very unlikely. To focus tracking on these unlikely models and to reduce the number of potential models under consideration, we exploit logic-based techniques for qualitative model-based diagnosis to conjecture a limited initial set of consistent candidate models. In this paper we discuss alternative tracking techniques that are relevant to different classes of hybrid systems, focusing specifically on a method for tracking multiple models of nonlinear behavior simultaneously using factored sampling and conditional density propagation. To illustrate and motivate the approach described in this paper we examine the problem of monitoring and diganosing NASA's Sprint AERCam, a small spherical robotic camera unit with 12 thrusters that enable both linear and rotational motion.

McIlraith, Sheila A.↗

NASA NTRS1991

Methodology for object-oriented real-time systems analysis and design: Software engineering

Successful application of software engineering methodologies requires an integrated analysis and design life-cycle in which the various phases flow smoothly 'seamlessly' from analysis through design to implementation. Furthermore, different analysis methodologies often lead to different structuring of the system so that the transition from analysis to design may be awkward depending on the design methodology to be used. This is especially important when object-oriented programming is to be used for implementation when the original specification and perhaps high-level design is non-object oriented. Two approaches to real-time systems analysis which can lead to an object-oriented design are contrasted: (1) modeling the system using structured analysis with real-time extensions which emphasizes data and control flows followed by the abstraction of objects where the operations or methods of the objects correspond to processes in the data flow diagrams and then design in terms of these objects; and (2) modeling the system from the beginning as a set of naturally occurring concurrent entities (objects) each having its own time-behavior defined by a set of states and state-transition rules and seamlessly transforming the analysis models into high-level design models. A new concept of a 'real-time systems-analysis object' is introduced and becomes the basic building block of a series of seamlessly-connected models which progress from the object-oriented real-time systems analysis and design system analysis logical models through the physical architectural models and the high-level design stages. The methodology is appropriate to the overall specification including hardware and software modules. In software modules, the systems analysis objects are transformed into software objects.

Schoeffler, James D.↗

NASA NTRS2018

Sensor Data Quality and Angular Rate Down-Selection Algorithms on SLS EM-1

The NASA Space Launch System Block 1 launch vehicle is equipped with an Inertial Navigation System (INS) and multiple Rate Gyro Assemblies (RGA) that are used in the Guidance, Navigation, and Control (GN&C) algorithms. The INS provides the inertial position, velocity, and attitude of the vehicle along with both angular rate and specific force measurements. Additionally, multiple sets of co-located rate gyros supply angular rate data. The collection of angular rate data, taken along the launch vehicle, is used to separate out vehicle motion from flexible body dynamics. Since the system architecture uses redundant sensors, the capability was developed to evaluate the health (or validity) of the independent measurements. A suite of Sensor Data Quality (SDQ) algorithms is responsible for assessing the angular rate data from the redundant sensors. When failures are detected, SDQ will take the appropriate action and disqualify or remove faulted sensors from forward processing. Additionally, the SDQ algorithms contain logic for down-selecting the angular rate data used by the GNC software from the set of healthy measurements. This paper explores the trades and analyses that were performed in selecting a set of robust fault-detection algorithms included in the GN&C flight software. These trades included both an assessment of hardware-provided health and status data as well as an evaluation of different algorithms based on time-to-detection, type of failures detected, and probability of detecting false positives. We then provide an overview of the algorithms used for both fault-detection and measurement down selection. We next discuss the role of trajectory design, flexible-body models, and vehicle response to off-nominal conditions in setting the detection thresholds. Lastly, we present lessons learned from software integration and hardware-in-the-loop testing.

Park, Thomas↗

NASA NTRS2018

Sensor Data Quality and Angular Rate Down-Selection Algorithms on SLS EM-1

Park, Thomas↗

NASA NTRS2019

Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) Project: ACAS Xu HITL Overview

This presentation provides an overview of a recently completed human-in-the-loop simulation, conducted as part of the Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) Project. This study examined how to present resolution advisories (RAs) issued by Airborne Collision Avoidance System (ACAS) Xu, which can be in the vertical dimension, the horizontal dimension, or both (i.e., "blended"). The study varied the location of the ACAS Xu traffic information - it was either presented within an 'integrated' display or a 'standalone' display, where the traffic information was separated from the vehicle control interfaces and navigational information. The presentation covers the test set-up, scenario design, and facilities utilized in this experiment. The primary dependent variables are listed, but no detailed results are included in this outbrief since data analysis is still underway. Goal: assess ACAS Xu Run 5 in a HITL setting to measure pilot & system performance – RWC alerting and guidance – RA alerting and guidance • Horizontal-only, vertical-only, and blended RAs • Strengthening RAs, reversals and added/removed RAs during blended maneuvers – Incorporate realistic sensor noise into the simulation environment – Compare pilot and DAA system performance back to NASA’s Phase 1 DAA MOPS V&V HITL • We leveraged the findings of an engineering analysis conducted in March to help inform how to implement the Xu logic – Part 1 focused on how to display horizontal-only, vertical-only and blended RAs – Part 2 focused on how to display automated RA responses Xu Engineering Analysis Results Part 1 objectives: – Characterize pilot responses to (canned) ACAS Xu RAs in a variety of display configurations • With vs. Without text accompaniment • Simple vs. ‘Advanced’ aural alerting • Results – Pilots struggled to meet 5 seconds initial response requirement • Particularly against horizontal and blended RAs – Pilots failed to respond more quickly to secondary RAs • Expected response time to subsequent RAs = 2.5 seconds No clear effect of the different alerting conditions on response times – Response times primarily driven by RA type • Pilots demonstrated high level of compliance with RAs and self-reported Xu alerting and guidance as being acceptable – 1/5 reported text as being necessary – 4/5 wanted the aural alert to retain the original RA sequence (i.e., issue a follow-on RA second rather than first) – 4/5 wanted to retain the “Maintain Heading/Vertical Speed” aural alert in the event that the pilot reached their target response at the time of secondary RA Based on these results, we decided on the following for the HITL experimental design: – Incorporated an ‘auto-fill’ feature in Vigilant Spirit that removes the need for pilots to manually enter a heading or altitude for RAs • Pilots only have to click ‘Send’ to upload the RA target heading/altitude – Did not include an RA ‘text box’ • The auto-fill feature largely replaces the purpose of the text box – Using a combination of the ‘Basic’ and ‘Advanced’ aural alerting • In case of blended maneuvers will issue “Maintain Heading/Vertical Rate” if pilot has reached 1st RA target at the time the 2nd RA is issued • Integration and testing with Xu Run 5 also resulted in us adding display logic to modify how horizontal RAs are presented – Target heading was shown to update at approx. 1 Hz making it difficult for pilots to implement – Display logic limited horizontal RA strengthening to once every 5 seconds • Did not impact timing of reversals, new RAs (i.e., blended), or CoC Engineering Analysis Results

human systems integration↗

NASA NTRS1990

Optimal stabilization of discrete event systems

An optimal stabilization problem for discrete event systems (DES) is addressed. A class of not necessarily finite state 'logical' DES models is utilized which can also model the costs for events to occur. Let P and A denote two such models. Suppose that P characterizes the valid behavior of a dynamical system and A represents certain design objectives which specify the allowable DES behavior which is 'contained in' the valid behavior. An optimal control problem for P and A is how to choose the sequence of inputs to P so that the DES behavior lies in A (i.e., it is allowable) and so that a performance index defined in terms of the costs of the events is minimized. Two solutions are provided to an optimal stabilization problem, i.e. how to find a sequence of inputs that results in an optimal state trajectory which cycles in a pre-specified set.

Passino, Kevin M.↗

NASA NTRS2007

Noise-Canceling Helmet Audio System

A prototype helmet audio system has been developed to improve voice communication for the wearer in a noisy environment. The system was originally intended to be used in a space suit, wherein noise generated by airflow of the spacesuit life-support system can make it difficult for remote listeners to understand the astronaut s speech and can interfere with the astronaut s attempt to issue vocal commands to a voice-controlled robot. The system could be adapted to terrestrial use in helmets of protective suits that are typically worn in noisy settings: examples include biohazard, fire, rescue, and diving suits. The system (see figure) includes an array of microphones and small loudspeakers mounted at fixed positions in a helmet, amplifiers and signal-routing circuitry, and a commercial digital signal processor (DSP). Notwithstanding the fixed positions of the microphones and loudspeakers, the system can accommodate itself to any normal motion of the wearer s head within the helmet. The system operates in conjunction with a radio transceiver. An audio signal arriving via the transceiver intended to be heard by the wearer is adjusted in volume and otherwise conditioned and sent to the loudspeakers. The wearer s speech is collected by the microphones, the outputs of which are logically combined (phased) so as to form a microphone- array directional sensitivity pattern that discriminates in favor of sounds coming from vicinity of the wearer s mouth and against sounds coming from elsewhere. In the DSP, digitized samples of the microphone outputs are processed to filter out airflow noise and to eliminate feedback from the loudspeakers to the microphones. The resulting conditioned version of the wearer s speech signal is sent to the transceiver.

Seibert, Marc A.↗