The Engineering Design of the REXIS Solar X-ray

Monitor and Risk Management Considerations for

Resource Constrained Payload Development

Michael P. Jones, Rebecca A. Masterson, David W. Miller

May 2015 SSL# 7-15

1

2

The Engineering Design of the REXIS Solar X-ray

Monitor and Risk Management Considerations for

Resource Constrained Payload Development

Michael P. Jones, Rebecca A. Masterson, David W. Miller

May 2015 SSL# 7-15

This work is based on the unaltered text of the thesis by Michael P. Jones submitted to the

Department of Aeronautics and Astronautics in partial fulfillment of the requirements for

the degree of Master of Science at the Massachusetts Institute of Technology.

3

4

The Engineering Design of the REXIS Solar X-ray Monitor and

Risk Management Considerations for Resource Constrained

Payload Development

by

Michael P. Jones

Submitted to the Department of Aeronautics and Astronauticson May 21, 2015, in partial fulfillment of the

requirements for the degree ofMaster of Science in Aeronautics and Astronautics

Abstract

The REgolith X-ray Imaging Spectrometer (REXIS) is a student collaboration instrumentaboard the NASA New Frontiers Program’s OSIRIS-REx spacecraft. Set to launch in 2016OSIRIS-REx will travel to, survey, and return a sample from the near-earth asteroid Bennu.One of five hosted payloads, REXIS images the asteroid in the soft x-ray spectrum. TheREXIS science goals are to classify Bennu among the meteorite groups and spatially mapsurface elemental distributions. To accomplish this, REXIS carries 4 CCID-41 detectorssensitive from 0.5 keV to 7.0 keV, in order to observe fluoresced x-rays from the surfaceof the asteroid. Fluoresced x-rays are dependent on the incident solar x-rays; therefore,REXIS includes a secondary detector to image the solar spectrum simultaneous with REXISobservations of Bennu. This secondary detector, the Solar X-ray Monitor (SXM), consists ofa silicon drift diode (SDD) that faces the sun while the REXIS detectors face the asteroid.The SXM provides an energy histogram of x-ray events between 0.6 keV and 6.0 keV that isfit to known solar spectral data to provide accurate knowledge of the incident x-ray spectrumat Bennu.

As a student collaboration, the REXIS instrument is classified as a high-risk and low-costpayload. The high level requirements for REXIS mission success are to provide studentsexperience in engineering design and project execution, and to do no harm to the hostspacecraft. In addition the REXIS project is highly resource constrained in budget, schedule,and personnel. The higher risk posture adopted by the REXIS mission is evidenced in theSXM design. The SDD is a commercial, off-the-shelf (COTS) component, and the SXMleverages design heritage from other missions. As an independent subassembly within theREXIS instrument that incorporates many aspects of the REXIS risk posture, includingCOTS components and design heritage, the SXM can provide insights into the applicationof risk management to high-risk payload development in general.

This thesis presents the engineering design of the REXIS SXM. Overviews are givenof structural and thermal components, electronics hardware, and software elements of thedesign. Additionally this thesis explores the difficulties inherent in creating a balanced

5

risk posture for highly-constrained payload development. First, background on current riskmanagement techniques and applications to high-risk missions are discussed, especially in thecontext of NASA. Examples of difficulties in high-risk missions are drawn from the REXISSXM, especially its use of COTS parts and design heritage from other missions. Finally,some conclusions about the risk management of highly constrained missions and suggestionsfor future work towards a more balanced risk approach are presented.

Thesis Supervisor: Rebecca A. MastersonTitle: Research Engineer, Department of Aeronautics and Astronautics

Thesis Supervisor: David W. MillerTitle: Hunsaker Professor of Aeronautics and Astronautics

6

Acknowledgments

This work was funded by NASA Goddard Space Flight Center (GSFC) under NASA contract

#NNG12FD70C (Origins Spectral Interpretation Resource Identification Security Regolith

Explorer (OSIRIS-REx) REgolith X-ray Imaging Spectrometer (REXIS), Phases B/C/D).

The author gratefully thanks GSFC for the generous support that enabled this research.

7

Disclaimer: The views expressed in this thesis are those of the author and do not reflect

the official policy or position of the United States Air Force, the United States Department

of Defense, or the United States Government.

8

Contents

List of Figures 13

List of Tables 17

1 Introduction 19

1.1 OSIRIS-REx Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2 REXIS Background and Design Overview . . . . . . . . . . . . . . . . . . . . 23

1.3 Risk Management for High-risk Missions . . . . . . . . . . . . . . . . . . . . 29

1.4 Thesis Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2 Risk Background 33

2.1 Defining Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2 The NASA Approach to Risk . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2.1 Evolution of NASA RM . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2.2 Current NASA RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.3 NASA RM Documentation Structure . . . . . . . . . . . . . . . . . . 43

2.3 Risk Management Applied to High-Risk Missions . . . . . . . . . . . . . . . 46

2.3.1 High-risk, Resource Constrained Missions . . . . . . . . . . . . . . . . 47

2.3.2 Difficulties of High-risk, Resource Constrained RM . . . . . . . . . . 48

2.3.3 Considerations for RM of High-risk, Resource Constrained Payloads . 49

3 The SXM Design 51

3.1 SXM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2 SXM Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

9

3.2.1 Purpose and Necessity of the SXM Measurements . . . . . . . . . . . 51

3.2.2 SXM Science Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.2.3 SXM Design Heritage . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3 SXM Top Level Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.4 Structural and Thermal Design of the REXIS SXM . . . . . . . . . . . . . . 60

3.5 Electrical Design of the REXIS SXM . . . . . . . . . . . . . . . . . . . . . . 66

3.5.1 The Amptek SDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.5.2 SXM Electronics Board . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 SXM Electronics, Software, and FPGA Design on the MEB 75

4.1 SXM Electronics Circuitry on the MEB . . . . . . . . . . . . . . . . . . . . . 75

4.1.1 Power, TEC, and High Voltage Circuitry . . . . . . . . . . . . . . . . 75

4.1.2 Shaping and Amplification . . . . . . . . . . . . . . . . . . . . . . . . 81

4.1.3 Trigger and Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.2 The SXM FPGA Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.2.1 The REXIS FPGA Architecture . . . . . . . . . . . . . . . . . . . . . 84

4.2.2 The SXM Core Inputs and Outputs . . . . . . . . . . . . . . . . . . . 85

4.2.3 The SXM Core Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.2.4 Tuning the SXM Core . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.3 SXM Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.4 Interpreting the SXM Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5 SXM Risk Management and Conclusions 101

5.1 REXIS Risk Classification and RM Approach . . . . . . . . . . . . . . . . . 101

5.2 Lessons Learned Applying RM to the SXM . . . . . . . . . . . . . . . . . . . 104

5.2.1 The COTS SDD as a Risk Mitigation . . . . . . . . . . . . . . . . . . 105

5.2.2 Unbalanced Risk in the SXM Avionics Design . . . . . . . . . . . . . 106

5.2.3 Unbalanced Risk in the SXM Structural Design . . . . . . . . . . . . 107

5.2.4 SXM Risk Management Conclusions . . . . . . . . . . . . . . . . . . 109

5.3 Future Work in High-risk, Highly Constrained RM . . . . . . . . . . . . . . . 110

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

10

6 Bibliography 113

A SXM Users Guide 121

A.1 Nominal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

A.1.1 SXM Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

A.1.2 Going into Science Mode . . . . . . . . . . . . . . . . . . . . . . . . . 122

A.1.3 Powering Down the SXM . . . . . . . . . . . . . . . . . . . . . . . . . 124

A.2 Getting the right histogram: Choosing LLD and ULD . . . . . . . . . . . . . 125

A.3 Getting the right histogram: Choosing the Update Period . . . . . . . . . . . 127

A.4 Hard Coded Parameter Adjustments . . . . . . . . . . . . . . . . . . . . . . 128

A.5 The SXM Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

A.6 Debugging Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

B SXM Assembly Procedure 135

B.1 Notes About the Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

B.2 Required Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

B.3 Assembly Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

B.4 Fastener and Torque Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

C SXM to MEB Safe-to-mate Procedure 149

C.1 Notes About the Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

C.2 Required Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

C.3 Safe-to-Mate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

11

12

List of Figures

1-1 OSIRIS-REx Spacecraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1-2 The REXIS instrument with the SXM . . . . . . . . . . . . . . . . . . . . . 26

1-3 The REXIS Detector Assembly Mount . . . . . . . . . . . . . . . . . . . . . 27

1-4 REXIS Electronics Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1-5 Engineering Model SXM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2-1 The CRM Circle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2-2 Example Risk Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2-3 The three parts of RIDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2-4 The integration of RIDM and CRM . . . . . . . . . . . . . . . . . . . . . . . 42

2-5 Risk mitigation over time with a probabilistic performance measure . . . . . 43

2-6 NASA agency level risk documentation structure . . . . . . . . . . . . . . . . 44

3-1 Engineering Model SXM without cable or mounting bracket . . . . . . . . . 52

3-2 Solar spectra as a function of energy for quiescent and flare states. . . . . . . 53

3-3 SXM data flow block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3-4 The REXIS Requirements documentation flow . . . . . . . . . . . . . . . . . 57

3-5 The FM SXM Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3-6 A cross section of the SXM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3-7 SDD housing temp vs. SXM interface temp . . . . . . . . . . . . . . . . . . 64

3-8 NICER radiation test results . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3-9 SXM Front View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3-10 An overview of the SXM electrical design . . . . . . . . . . . . . . . . . . . . 68

13

3-11 The Amptek XR-100SDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3-12 XR-100SDD Resolution vs. Peaking Time . . . . . . . . . . . . . . . . . . . 70

3-13 NICER Resolution vs. Tempearture test data for XR-100SDD . . . . . . . . 71

3-14 Qunatum Efficiency of the XR-100SDD . . . . . . . . . . . . . . . . . . . . . 72

3-15 The EM SXM Electronics Board . . . . . . . . . . . . . . . . . . . . . . . . . 72

3-16 Wires and solder joints between SMA connector and PCB . . . . . . . . . . 74

3-17 Preamp output voltage spike due to 55Fe . . . . . . . . . . . . . . . . . . . . 74

4-1 An overview of the SXM electronics on the REXIS MEB . . . . . . . . . . . 76

4-2 REXS Power Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4-3 TEC current draw from EM testing . . . . . . . . . . . . . . . . . . . . . . . 79

4-4 SDD temp vs TEC voltage from EM testing . . . . . . . . . . . . . . . . . . 80

4-5 An Oscilloscope trace of the EM TEC PWM signal . . . . . . . . . . . . . . 81

4-6 The SDD reset signal as seen at the SXM output . . . . . . . . . . . . . . . 81

4-7 Oscilloscope trace of shaping circuit outputs . . . . . . . . . . . . . . . . . . 82

4-8 SXM Trigger Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4-9 The Modes and states of the SXM core state machine . . . . . . . . . . . . . 89

4-10 Jitter in the falling edge of Zp . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4-11 Jitter in the rising edge of LLD . . . . . . . . . . . . . . . . . . . . . . . . . 91

4-12 Oscilloscope traces showing LLD and VLLD . . . . . . . . . . . . . . . . . . 92

4-13 A block diagram of the SXM data processing function . . . . . . . . . . . . . 95

4-14 EM Histogram showing 55Fe exposure . . . . . . . . . . . . . . . . . . . . . . 98

4-15 Oscilloscope trace of SDD reset . . . . . . . . . . . . . . . . . . . . . . . . . 99

4-16 SDD Reset Rate vs SDD Temperature . . . . . . . . . . . . . . . . . . . . . 100

4-17 Oscilloscope trace of 55Fe decay . . . . . . . . . . . . . . . . . . . . . . . . . 100

5-1 Current REXIS Risk Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

A-1 A histogram showing just SDD resets and no events. . . . . . . . . . . . . . 127

A-2 A histogram showing 55Fe peaks . . . . . . . . . . . . . . . . . . . . . . . . . 128

A-3 A Matlab based GUI for testing the SXM . . . . . . . . . . . . . . . . . . . 132

14

B-1 Bottom View of the Preamp case with SXM Electronics board installed . . . 139

B-2 Bulkhead mounted SMA connector and PCB showing ground wires and signal

wire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

B-3 Wires and solder joints between SMA connector and PCB . . . . . . . . . . 141

B-4 Another view of the Solder Pads showing wires for ground and signal . . . . 142

B-5 The EM SXM preamp case with CHO-THERM installed . . . . . . . . . . . 143

B-6 The SXM SDD in preamp case showing proper orientation . . . . . . . . . . 144

B-7 The preamp case with MDM connector installed (note SDD is missing) . . . 145

B-8 The SXM preamp case with collimator installed . . . . . . . . . . . . . . . . 146

B-9 The SXM grounding lug on preamp case with proper orientation . . . . . . . 147

B-10 The SXM preamp case on bracket with proper orientation . . . . . . . . . . 148

15

16

List of Tables

1.1 OSIRIS-REx Instruments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 SXM Requirements from REXIS Level 3 Requirements Document . . . . . . 58

3.2 SDD Quantum Efficiency Requirements . . . . . . . . . . . . . . . . . . . . . 58

3.3 SXM Requirements from REXIS Level 4 Requirements Document . . . . . . 60

3.4 SDD pin-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.5 SXM Electronics Board MDM pin-out . . . . . . . . . . . . . . . . . . . . . 73

4.1 SXM FPGA core pin descriptions . . . . . . . . . . . . . . . . . . . . . . . . 85

4.2 SXM Parameters updateable by command . . . . . . . . . . . . . . . . . . . 95

4.3 SXM Telemetry Packet Fields and Byte Offsets . . . . . . . . . . . . . . . . 96

5.1 The current list of most significant REXIS risks . . . . . . . . . . . . . . . . 104

A.1 SXM Parameters update-able by command . . . . . . . . . . . . . . . . . . . 122

A.2 SXM Telemetry Packet Fields and Byte Offsets . . . . . . . . . . . . . . . . 125

B.1 Fasteners needed for SXM Assembly . . . . . . . . . . . . . . . . . . . . . . 148

B.2 Fastener torque values for SXM assembly . . . . . . . . . . . . . . . . . . . . 148

17

18

Chapter 1

Introduction

The purpose of this thesis is first to set forth a detailed design overview of the Solar X-ray

Monitor (SXM). The SXM is a secondary detector on the REgolith X-ray Imaging Spec-

trometer (REXIS) instrument, a student payload aboard the NASA OSIRIS-REx mission

to the asteroid Bennu. The SXM consists of a solar facing x-ray detector in a separate sub-

assembly located away from the main REXIS instrument. The science goal of the SXM is

to characterize the Solar x-ray spectrum at Bennu in order to aid in interpreting the REXIS

data. This thesis will present the SXM structural components that protect the electronics,

collimate the input solar x-rays, and provide a safe thermal environment for the detector.

Interfaces with the spacecraft and with the main REXIS instrument are also detailed. The

electronics hardware design, as well as the software that interacts with and controls the SXM

are discussed. Engineering model test data is presented and comments made on the testing

and operation of the flight SXM.

As a student collaboration, NASA classifies the REXIS instrument as a high-risk and

low-cost payload. The high level requirements for REXIS mission success are to provide an

educational experience to students, and to do no harm to the host spacecraft. In addition, the

REXIS project is resource constrained in budget, schedule, and personnel. The higher risk

posture adopted by the REXIS mission is evidenced in the SXM design. As an independent

subassembly within the REXIS instrument that incorporates many aspects of the REXIS

risk posture, including COTS components and design heritage, the SXM can provide insights

into the application of risk management to high-risk payload development in general. This

19

thesis explores some of the difficulties of creating a balanced risk posture in the context

of a high-risk mission with attention paid to the application of NASA risk management

guidelines. The balance of this Chapter introduces the OSRIS-REx mission and the REXIS

instrument, including a short design overview of REXIS. An overview of the motivation for

high-risk mission risk management is discussed next, and the chapter concludes with an

outline of the rest of the thesis.

1.1 OSIRIS-REx Background

Origins Spectral Interpretation Resource Identification Security Regolith Explorer (OSIRIS-

REx) is an asteroid sample return mission [1, 2]. The spacecraft is a part of the NASA

New Frontiers Program and is managed out of the NASA Goddard Spaceflight Center. The

mission’s principal investigator is from the Lunar and Planetary Laboratory at the University

of Arizona and the bus, shown in Figure 1-1, is being built by Lockheed Martin. Scheduled

for launch in September 2016, the prime mission of OSIRIS-REx is to return a sample from

Bennu, a near-earth asteroid formerly known as 1999 RQ36. Bennu is a small asteroid, with

a diameter of around 575 meters, and it sits in an elliptical orbit with a semi-major axis of

1.12 AU. A primitive solar system object, Bennu holds clues about the early formation of the

planets. As a carbonaceous asteroid, with possible organic compounds and volatiles, Bennu

could also yield insights into the sources of earth’s organic compounds. These organics,

combined with its relative proximity to earth, make Bennu a prime candidate for a sample

return mission [3]. In addition, as a near-earth object Bennu has some chance of a collision

with earth, particularly in the late 22nd century [4], and the knowledge gained by OSIRIS-

REx will improve models of the asteroid, thus better assessing this threat.

After launch, scheduled for September of 2016, OSIRIS-REx begins a two year outbound

cruise to the asteroid. Upon arrival around August of 2018, OSIRIS-REx will slowly approach

and then begin to orbit the asteroid. The instruments on board will study Bennu closely until

late 2018, when the sample collection is scheduled. Instead of landing on the asteroid, whose

low gravity would make that maneuver difficult, OSIRIS-REx will very slowly approach the

surface of Bennu and extend an arm that will make a brief (about five seconds) contact with

20

Figure 1-1: Rendering of the OSIRIS-REx satellite with asteroid sample arm extended

the surface. The arm will then retract and stow the sample in a capsule for safe transport

back to earth. After the sample collection, the spacecraft will resume orbit around Bennu

for continued science observations until early 2021, when it will turn back to earth. The

sample, which will consist of at least 60 grams of pristine regolith, will arrive back on earth

in 2023 [5, 6].

While the primary mission is the sample return, there is much to be gained scientifically

by imaging the asteroid in various spectra before and after the sample collection. In addition

to the sampling arm and storage capsule, OSIRIS-REx will host five instruments to study

Bennu, as shown in Table 1.1. The survey of the asteroid pre-sample will allow for better

characterization of potential sample sites, and provide orbital information necessary to make

the sampling approach. Post-sample observations will allow for close observation of where

the sample attempt has disturbed the surface of Bennu, potentially providing more insights

into what lies beneath the surface.

The OSIRIS-REx Camera Suite (OCAMS) is a set of three visible spectrum cameras

21

Table 1.1: OSIRIS-REx Instruments

Instrument Description Science Objective

REXIS X-ray SpectroscopyGlobal and local elementalabundance ratios

OCAMS Visible ImagingDetailed visual maps withthree cameras

OVIRS Visible + Infrared SpectroscopyGlobal and local spectralmapping, sample site char-acterization

OTES FTIR SpectroscopyMineral and temperaturedata, sample site character-ization

OLA Scanning Laser AltimeterGlobal and localized topo-graphic mapping

that will provide detailed imagery of Bennu. Each camera has a different focal length to

provide images at different mission phases. PolyCam is an 8”telescope that will take the

first resolved images of Bennu while the spacecraft is approaching the asteroid. It will be

refocused later to provide high resolution images of the sample site once the spacecraft is very

close to Bennu. MapCam will provide four color filter mapping of Bennu and SamCam will

provide 1 Hz frames of the actual sample capture procedure [7]. The OSIRIS-REx Visible

and near-Infrared Spectrometer (OVIRS), is a narrow field of view spectrometer sensitive

to light from 0.4 to 4.3 µm in wavelength to provide global and localized mineralogical

maps [8]. The OSIRIS-REx Thermal Emission Spectrometer (OTES) is a Fourier transform

infrared spectrometer (FTIR) sensitive to light from about 5 to 50 µm in wavelength. It

will measure thermal flux and surface mineralogy. OTES will study the Yarkovsky effect on

Bennu, the orbital disturbances caused by differential heating from the sun on a rotating

body [9]. Provided by the Canadian Space Agency, the OSIRIS-REx Laser Altimeter (OLA)

is a scanning light detection and ranging (LIDAR) instrument. With a range resolution of

less than 4 cm, OLA will help refine global shape and mass models as well as provide more

detailed topographical maps, especially at candidate sample sites [10].

Finally, the Regolith X-ray Imaging Spectrometer (REXIS) is a student collaboration

with the Massachusetts Institute of Technology Space Systems Laboratory and the Harvard

College Observatory [11]. As a student collaboration the REXIS top level requirements are to

22

educate engineering students and to do no harm to the host spacecraft, other instruments,

or the asteroid sample. Scientifically, REXIS seeks to classify Bennu among the major

meteorite groups and map elemental abundance ratios of with 200 m spatial resolution.

REXIS observes Bennu in the 0.5-7.0 kEV soft x-ray band for 420 hours during two separate

observation phases of the OSIRIS-REx mission. The REXIS instrument is composed of two

separate assemblies, a spectrometer that observes the asteroid, and the SXM that observes

the sun. The next section give a design overview of REXIS and the SXM.

1.2 REXIS Background and Design Overview

As a student collaboration, students are responsible for the design, integration, testing, and

operations of REXIS, under the guidance of the faculty mentors. The REXIS Level 1 require-

ment is to educate by directly engaging students in the conception, design, implementation,

and operation of a space flight instrument. As such, fulfillment of the REXIS science ob-

jectives are not necessary for OSIRIS-REx mission success. The REXIS team has included

students ranging from first year undergraduates through doctoral candidates. As of May

2015, over 45 undergraduate and 15 graduate students have contributed to the project. Fac-

ulty support is provided by the Instrument Manager, along with the Principal Investigator

and Instrument Scientists. In addition, as with any instrument, subcontractors are employed

in several key areas.

The REXIS design has followed a prototype to engineering model (EM) to flight model

(FM) design process in conjunction with major design reviews to ensure a mature and well

tested flight design. Prototype models were constructed and tested prior to the Preliminary

Design Review (PDR) in January of 2013. The engineering model was built and tested

during the 2013 - 2014 academic year, and the Critical Design Review (CDR) was held in

February of 2014. The flight model is being constructed during the spring of 2015, and the

Pre-Environmental Review (PER) is scheduled for June of 2015. The anticipated delivery

of REXIS to spacecraft integration is late summer of 2015.

The scientific goals of REXIS are to classify Bennu among the meteorite groups and

map surface elemental distribution through observation of fluorescent x-rays from Bennu

23

in the 0.5-7 keV soft x-ray band. REXIS is the first wide-field coded aperture imaging

instrument. REXIS builds on the heritage of past wide field x-ray spectrometers such as the

X-ray/Gamma-ray Spectrometer system (XGRS) on the Near Earth Asteroid Rendezvous

(NEAR) mission as well as coded aperture imaging systems such as the Burst Alert Telescope

(BAT) on the Swift Midex mission [12, 13]. REXIS gathers data from a 1 km radius orbit

around Bennu for a period of 420 hours during the the OSIRIS-REx mission. To accomplish

the first science objective, REXIS must measure the global elemental abundance ratios of

Fe/Si, Mg/Si and S/Si to an accuracy of ≤25%. This measurement is accomplished using

global imaging information taken over the whole course of the REXIS mission. To accomplish

the second science objective, REXIS utilizes a random pattern coded aperture mask with an

open fraction of approximately 50% to enable the reconstruction of high resolution images

on the asteroid surface. A shadowgraph is collected on the detector plane at 4 s intervals

and deconvolved in order to produce a sky image. A map of Bennu is produced by co-adding

each sky image as OSIRIS-REx orbits around Bennu, and Bennu rotates on its own axis.

REXIS can reveal the enhancement of iron in the regolith to within a factor of 4 with 50 m

spatial resolution. More information of the science goals of REXIS can be found in Allen et

al. [14].

In order to correctly interpret the CCD data from the REXIS spectrometer, the incident

x-ray spectrum at Bennu must be known. The sun is the source of x-ray illumination for

the REXIS measurements, and the solar x-ray flux and spectrum vary as functions of time.

Changes in total flux as well as spectral shape occur during solar flares over timescales as

short as minutes [15]. Both overall flux and spectral shape ultimately drive the x-ray spec-

trum of Bennu and affect REXIS’s ability to both spatially resolve spectrally-distinct regions

on Bennu’s surface as well as derive bulk elemental abundance ratios for its regolith [16].

As a result of the solar variability, knowledge of the incoming solar spectrum is necessary to

properly interpret the fluorescent line data collected from Bennu. To obtain this solar state

knowledge, REXIS includes the secondary sensor on the SXM to collect solar x-ray spectra

while asteroid data are collected. The SXM observes the solar x-ray spectrum and allows

indirect measurement of the solar coronal temperature. Calibration curves are produced

during ground processing using models of the solar x-ray spectrum as a function of solar

24

temperature. To account for variations in the solar x-ray spectrum, these curves correctly

scale the count rate in the spectral lines of interest to the weight percent of the elements of

interest in the regolith. Measuring the solar coronal temperature with the SXM allows the

effects of solar variation to be removed from the asteroid data.

The REXIS spectrometer and SXM are depicted in Figure 1-2. The spectrometer consists

of the Detector Assembly Mount (DAM), the truss assembly, the coded aperture mask,

the radiation cover, and the electronics box. At the top of the spectrometer is the coded

aperture mask that casts a shadow pattern on the detectors below. During the cruise to the

asteroid, a one-time deployable cover over the mask aperture protects the CCDs from the

harsh radiation environment. The cover is opened upon arrival at Bennu. The truss panels

mounted on the Detector Assembly Support Structure (DASS) support the mask frame and

hold it in alignment with the detectors. At the base of the spectrometer in the electronics box

that houses three printed circuit boards: the Main Electronics Board (MEB), the Interface

Board, and the Video Board. The electronics box is bolted to the spacecraft deck to couple

REXIS both mechanically and thermally to OSIRIS-REx. The SXM is located separately

from the spectrometer on the sun-facing side of the spacecraft. It is comprised of a Silicon

Drift Diode (SDD) manufactured by Amptek Inc. and a small SXM electronics board (SEB)

that conditions the signal from the SXM.

Detectors and Detector Assembly Mount

The REXIS detector array consists of 4 MIT Lincoln Laboratory back illuminated CCID-41

charge coupled devices (CCDs) in a 2x2 array that collect photons from Bennu [17]. Each

CCD consists of a 1024 by 1024 imaging array accompanied by a non-imaging framestore.

Each pixel on the imaging array is 24 µm x 24 µm. Combined, the detector array has an area

of over 24 cm2. To reject optical light, a 220 nm thick aluminum layer termed the optical

blocking filter (OBF), is directly deposited on the CCD surface. Heritage OBF designs on

instruments such as ACIS and XIS feature an OBF suspended above of the imaging portion of

the CCDs[18, 19]. REXIS is the first instrument to fly these CCDs with a directly deposited

optical blocking filter. A flexible circuit board cable electrically connects each CCD to the

Video Board. Each CCD is mounted on an alumina substrate that connects the CCD to the

25

Figure 1-2: The REXIS instrument with the SXM

detector assembly mount (DAM).

The DAM aligns, calibrates, and protects the detector array [18]. The DAM base-plate

serves as the common alignment interface for all four CCDs. Once the CCDs are mounted

and aligned in the DAM sub assembly, the DAM is mounted and aligned within the truss

assembly. To monitor and calibrate the performance of the CCDs, several 55Fe sources are

mounted in the DAM illuminating small portions of each CCD. Figure 1-3 shows a view

of the flight model DAM shortly after assembly. A thermal strap runs from the bottom of

the DAM to a radiator to passively cool the detectors. Two thermal isolation layers (TIL),

one between the electronics box and the DASS and one between the DASS and the DAM,

support a thermal gradient between the warm electronics box and the cold detectors. The

first TIL is made of four titanium standoffs, the second from four Torlon standoffs.

Electronics Box

The electronics box contains the REXIS avionics stack: the Main Electronics Board (MEB),

the Video Board, and the Interface Board. The MEB interfaces with the spacecraft, converts

and regulates power for the instrument, and contains the main processing unit, a Xilinx

26

Figure 1-3: The REXIS Detector Assembly Mount

Virtex 5 FPGA. The Virtex 5 controls the operation of REXIS, processes the raw CCD

images, and communicates with the spacecraft [20]. The MEB also contains the power

regulation and distribution system and the SXM analog signal processing electronics. The

Video Board and Interface Board together are known as the Detector Electronics (DE). The

Video Board receives and digitizes the raw CCD data before passing the data to the Interface

board. The Interface Board converts the digitized data from the Video Board to Camera

Link format for transmission to the MEB and controls the housekeeping data collection for

the CCDs. The electronics box provides a benign structural and thermal environment for the

boards and shields them from radiation. Figure 1-4 shows an exploded view of the electronics

box along with pictures of the engineering model MEB, Interface Board, and Video Board.

Mask Assembly and Radiation Cover

The mask assembly consists of the coded aperture mask, mask frame and radiation cover.

The coded aperture mask contains a 9.84 cm diameter circular pattern of 1.536 mm square

pixels on a substrate of 100 µm thick stainless steel. The mask pattern is random with an

open fraction of 50%. The mask assembly includes a radiation cover to protect the detectors

from excessive radiation damage during the cruise to Bennu. The cover is an aluminum

plate sized, in concert with the truss thickness, to reduce the radiation flux received by the

detectors to acceptable levels. Upon arrival at Bennu, the cover is actuated by a one-time

release TiNI Aerospace FD04 Frangibolt actuator [21]. The bottom of the radiation cover

also contains an 55Fe source that illuminates the entire CCD array. While the cover is closed,

27

Figure 1-4: Exploded view of the Electronics Box showing the avionics stack

this source allows calibration over the entire detector and when the cover opens, the source

is removed from the detector’s field of view, permitting uncluttered data collection from

Bennu.

Solar X-ray Monitor

The SXM is a subassembly separate from the REXIS spectrometer. The engineering model of

the SXM, with its mounting bracket to the spacecraft is shown in Figure 1-5. It is mounted

on a gusset of OSIRIS-REx that faces the sun during observations of Bennu. The SXM

interfaces mechanically with the spacecraft through an aluminum mounting bracket. The

SXM interfaces electrically with the REXIS main electronics board through a cable routed

along the spacecraft deck. The heart of the SXM is an Amptek XR-100SDD silicon drift

diode (SDD). The SDD is mounted on a small SXM electronics board (SEB) that conditions

the analog signal before it is sent to the REXIS MEB for processing. The MEB SXM

electronics bins x-rays in a histogram according to incident energy. The resulting histogram

is transmitted back to the ground where it is used to determine the solar x-ray spectrum.

The SXM design is treated in detail in Chapter 3.

28

Figure 1-5: Engineering Model SXM

1.3 Risk Management for High-risk Missions

Space missions, whether for science, exploration, or industrial purposes are notoriously time

consuming and expensive. The largest satellites, such as the currently under development

James Webb Space Telescope (JWST), can take decades and billions of dollars to complete.

The failure of such a large national mission as JWST would be an immense loss for science,

not to mention the political ramifications of losing a large public expenditure. Even failures

of less expensive projects are costly as most space missions are one-time opportunities for

which a satellite failure carries large negative implications. It is not surprising then, that the

concepts of risk and risk management (RM) are important aspects of space mission devel-

opment. Indeed, the idea of risk as a property of a complex system relevant to the engineer

came about around the time of the first space systems, emerging with the formalization of

systems engineering in the years following World War II. Nevertheless, the application of

consistent and precisely defined risk management techniques to space missions is a relatively

recent phenomenon. The idea of risk as quantifiable, and therefore subject to quantitative

analysis and mitigation grew in the 1980’s [22]. NASA introduced formal risk management

to its engineering design process in the 1990’s. It wasn’t until 2008 that the NASA docu-

mentation incorporated risk informed decision making and probabilistic risk assessment into

a single cohesive standard for mission risk management.

29

Though RM is now standard for NASA space programs, there is a shortage of published

literature on the practical application of RM to real missions in the context of the latest

NASA guidlines. Part of this shortage is due to the fact that NASA’s most recent RM

guidelines were only published in 2008, and there has yet to be a significant amount of

literature addressing the application of the new RM techniques on NASA missions, whether

successes or failures. Most of what is about applied RM published focuses on failed missions.

Nevertheless, there are several missions that, though failures, present a good indication of

how risk management is actually carried out. For example, highly publicized mission failures

in the 1990’s caused a surge of activity in RM thinking applied to space missions in an

attempt to diagnose what went wrong, and where improvements could be made. Several

investigations cited poor risk management and communication of risk as a contributing

factor to the failures [23, 24, 25, 26].

While space missions are traditionally expensive, one-time, monolithic enterprises, there

is a growing trend towards smaller and lower-cost space missions. This trend is combined with

a lowering of the cost to reach space and the mass and power requirements for much of the

necessary functionality of satellites. The result is the growth of high-risk, low-cost missions

where some failure rate is deemed acceptable. NASA includes categories and guidelines

for such high-risk missions in its risk classifications [27]. Cubesats in particular are an

example of a small form-factor, low-cost satellite that is growing in popularity. The number

of cubesats built and flown is set to increase to hundreds per year in the next few years as

new ride-share programs and deployment mechanisms ease access to launches [28]. REXIS

is an example of a student collaboration mission, where a student built payload is flown

on a host spacecraft. Like with cubesats, a higher risk posture is accepted on REXIS, but

the interface with the lower risk host adds some caveats. Though higher-failure rates are

acceptable for cubesats and other high-risk missions, that does not mean that a thoughtful

application of RM throughout the project lifetime is not necessary or useful. In fact, applying

a balanced risk posture to a high-risk mission takes as more careful application of RM

techniques than a uniformly low-risk mission. Discerning where to spend valuable schedule

and budget resources against performance margins and allowable risk is a delicate equation

in a highly-constrained, high-risk payload. Despite the difficulties, carefully applied RM is

30

critical for high-risk low-cost space projects. When high-risk missions are considered, the

gap in publication of RM application becomes even more obvious. The gap is likely due to

several factors. First, risk management is easily neglected in high-risk missions. It is easy to

assume that a risk-tolerant or high-risk posture means that no risk management is necessary

for the project at all. The preponderance of such a view is emphasized not just by the

lack of publications on RM, but also the confusion surrounding the application of guiding

documents to high-risk missions, especially in the context of NASA Class D missions. More

information on the NASA guidelines and directives is presented in Section 2.2.3.

High-risk missions are also usually highly constrained in other areas, including personnel

and time. There are few resources available to carry out, or publish the results of, a careful

RM strategy throughout the mission life. Many high-risk missions are conceived and built

in an uncertain management environment. Since they are often ’expendable’ or ’nice-to-

have’ rather than mission critical, high-risk payloads are often canceled, requirements are

changed, or objectives are de-scoped. These conditions make it difficult to implement a

thoughtful risk posture that remains consistent throughout the project lifetime. Some of

these concerns are demonstrated well in the LCROSS and DART missions. Both are high-risk

NASA missions, and two of the few high-risk missions that have published papers specifically

regarding their risk and posture and RM techniques [29, 30]. DART in particular experienced

budget changes, project leadership changes, and varying political environments from three

different NASA administrators during the project lifetime. All of these issues affected the

ability of the project team to put forward a consistent risk posture.

1.4 Thesis Roadmap

This chapter has outlined the background of the REXIS instrument and the OSIRIS-REx

mission. The SXM has been introduced, as have the broad outlines of its design. The

following chapters will go through background on risk management especially in the context

of NASA space missions. The SXM design will be presented, both in hardware and software.

REXIS risk management will be explored in the context of the SXM, and the conclusion

will draw some lessons learned about the application of risk management to the highly

31

constrained payload development. The main goal of this thesis is to present the design

of the REXIS Solar X-ray Monitor, but it also seeks to explore some of the difficulties of

applying a balanced approach to risk management in the context of a high-risk, low-cost

space missions.

Chapter 2 presents a background on risk. Risk and risk management are defined to

allow for more coherent and precise discussion. Current approaches to risk management

are presented with an emphasis on NASA guidelines and documents. The NASA

mission categories and the guidelines that apply to each are noted. Specifically, high-

risk missions are discussed in the context of the NASA risk categories. The current

trend towards more high-risk missions, and some of the difficulties that accompany

such applying risk management to such missions are presented.

Chapter 3 moves into the SXM design. SXM background and heritage are discussed,

as well as the REXIS requirements that lead to the SXM. The high-level requirements

are presented before moving into details of the SXM design. The SXM structural and

thermal design is presented first, followed by the SXM electrical design.

Chapter 4 describes the electrical hardware and software on the REXIS spectrometer

that support the SXM subassembly. The helping circuitry that provides power and

housekeeping to the SXM is discussed first, followed by the signal processing circuitry.

Then the FPGA core is presented including signal processing logic, the FPGA to

hardware interface, and the FPGA to software interface. The SXM software design is

described next, and the Chapter ends with a discussion of how to interpret the SXM

histogram.

Chapter 5 explores how the REXIS risk approach affected the SXM design outcomes

and the difficulties of creating a balanced risk posture in a high-risk, low-cost envi-

ronment. The thesis concludes with a summary of lessons learned, and questions for

future work in applying a balanced risk approach to highly constrained space missions.

32

Chapter 2

Risk Background

This chapter provides a brief background on risk and an risk management, especially with

respect to high-risk and low-cost payload development in NASA missions. Background

of the definitions of risk and risk management is given and some of the history of risk

management at NASA is presented. The current NASA risk management philosophy is also

presented in the context of the guiding documentation. High risk missions are introduced and

the application of risk management to high-risk, resource constrained missions is discussed.

Finally, the fundamental difficulties of applying a balanced, comprehensive RM approach to

high-risk, resource constrained missions are presented.

2.1 Defining Risk

The concept of risk as applied to an engineered system can be hard to define. It is not an

action that can occur, nor is it thing that can exist on its own. Because of its abstractness,

people often mean very different things when speaking about risk, even within the same

field. For example, in engineering design risk is often spoken of interchangeably with safety.

To make the two concepts equivalent conflates the desire to avoid harm with the desire to

meet performance requirements. Often those two objectives are very closely linked, but a

perfectly safe system need not perform well at all. While a hazard or danger (the objects

of concern to safety) often contribute to risk, not all hazards affect the performance goals of

the system under consideration. In addition, defining a danger by itself is useless without

33

information that relates the danger and its likelihood of occurring to its consequences for

the system. Similarly, risk can be confused with uncertainty. Though uncertainty about

a performance objective is one aspect of risk, not all uncertainty is related to performance

goal. Uncertainties and hazards by themselves are not the whole picture when it comes to

risk.

Risk, in the context of engineered systems, is the combination of danger and uncertainty,

with respect to a desired goal. There are some additional characteristics which help define

risk. First, a risk should include both severity of impact on the system goal(s) and likelihood

of occurrence. In engineering, one deals with designed, physical systems. Any designed

system has a goal or set of goals for which it is designed, and of course any physical system

must obey the physical laws. Therefore one can say that anytime a system’s goal is not met,

a scenario which caused it not to be met will have occurred. This causal assumption allows

an escape from the negative definition of something that doesn’t occur (not meeting a goal)

to a positive definition which can be expressed quantitatively and studied (the risk scenario).

The risk of not meeting a system’s goals can be defined more explicitly, then, as a function

of the scenarios which result in a goal not being met, the probability of any of those scenarios

occurring, and the consequence to the system objectives should one of those scenarios occur.

A quantitative definition of risk, making use of the scenario/likelihood/consequence triplet

was set forth by Kaplan and Garrick in 1981 in the inaugural edition of the journal Risk

Analysis [22] and is given here in Equation 2.1.

R = < Si, Li, Xi > (2.1)

Note that the risk scenarios are discretized. Now some assumptions must be made about

the set of scenarios Sα. While any infinite number of scenarios are possible (S), an infinite

subset of which could lead to a risk (Sα), a finite number must be considered in order to

practically work with the set. With Haimes in Risk Modeling, Assessment, and Analysis [31]

the working subset of risk scenarios Si is here defined as finite, as complete as possible

(⋃

(Si) ≈ Sα), and disjoint (no Si = Sj for all i 6= j). Note also that Haimes adds a time

domain to risks to aid in the analysis and management of specific risks. In the context

34

of this thesis, temporal information relating to specific risks is not necessary as a part of

the definition of risk itself since the RM techniques being discussed include time sensitive

information in the decision making process.

Risk in an engineered system can be technical or programmatic. Technical risk refers to

the subset of risk scenarios that have a direct technical cause such as a component failure or

a design failure. A programmatic risk refers to the subset of risk scenarios whose proximate

cause is not technical, such as a failure to meet schedule or a failure to meet personnel and

staffing needs. An example technical risk scenario could be a component failure that prevents

a system from meeting performance requirements. On REXIS, for instance, a low voltage

from the MEB could prevent the actuator on the radiation cover that protects the CCDs

from opening the cover. A failure to open the cover would prevent the imaging array from

ever receiving x-rays from the asteroid. The consequence of that risk scenario is high: to

not meet the REXIS science requirements. This consequence can be quantified by judging

it relative to the other risks on the mission. The likelihood of this risk scenario is dependent

on the engineering design of the system, and the likelihood of the voltage regulator failing

combined with the likelihood of failure of related electrical components. The likelihood of a

particular risk at any given time during the project development is affected by the maturity

of the design, the level of testing accomplished, and other factors. Higher likelihoods must

be assigned to untested designs, while flight heritage or environmental testing tend to reduce

the likelihood of technical risk scenarios.

An example of a programmatic risk could be the risk that a personnel shortage on the

avionics team leading to a failure to implement all the desired requirements in the flight

software. While the likelihood and consequence of technical risks can be assessed by analysis

or test of a physical system, the likelihood and consequence of programmatic risks can be

more difficult to determine. The consequence of this risk scenario occurring might be only a

partial failure, or a degradation in the final science product. The likelihood of this risk can

be determined by close communication with the avionics team members and good estimation

of the complexity and completeness of the software as the project progresses.

Both technical and programmatic risk scenarios have a direct effect on the ability of

the system to meet requirements; both types of risk scenarios have technical consequences.

35

Since programmatic risks are tied to technical consequences they are often highly related

to a complementary technical risk. For example, the personnel risk described above could

be expressed as a technical risk of software failure to meet a given requirement. Technical

risks are often expressed in terms of programmatic risks early in a project’s design. By

holding risks as programmatic, the risk can be more easily quantified in terms of available

programmatic resources. Risks stemming from personnel and schedule are cast in terms of

concrete technical risks once programmatic means of dealing with them are exhausted. In

other words, spending programmatic resources such as time and money to ensure that the

avionics team is well staffed comes first. Later in the project, if it becomes clear there is still

a risk of not meeting software requirements, the risk scenario is expressed in technical terms

of software failure rather than in terms of staffing failure.

Risk Management (RM) utilizes the triplet definition of risk set forth above to asses

and mitigate the risks to a system. There are several methodologies for understanding and

managing risks to a system, both in aerospace and other industries [31, 32, 33]. There are

many approaches to RM, but all address three main areas. The first is to understand the the

system and determine what risk scenarios exist. The second is to assess the risk scenarios

with respect to consequence and likelihood. The third is to attempt to mitigate the risks.

The mitigation function of RM should also include some iterative method of reassessing risks

to judge the effectiveness of the previously implemented mitigations. These three functions

contribute to all comprehensive RM methodologies. This thesis will focus on RM with

respect to space missions, in particular with respect to NASA missions. By describing risk

mathematically, the discussion of risk can be carried out more rigorously, the risk state of a

system can be determined to within a known uncertainty, and the mitigation of risk can be

measured. Such a quantitative definition of risk forms a necessary groundwork for modern

RM.

36

2.2 The NASA Approach to Risk

2.2.1 Evolution of NASA RM

RM at NASA has evolved to become an integral component of the project development

and management process. While RM in some form has always been a part of complex

system design, early space missions were focused on safety rather than RM as such. The

manned space program was integral in developing such concepts as fault tree analysis and

failure modes effects analysis which formed the basics of safety and mission assurance for

space programs throughout NASA’s first few decades [32]. Safety, however, is not the whole

picture. A safe mission will not have a mishap that damages personnel or property, but it

also might carry many performance risks that may cause failures that are not addressed from

a safety perspective. A safe mission is one thing, but a mission with a well-balanced risk

posture is something else. The desire for a more holistic view of risk led to the application

of risk management methodologies to NASA projects in the 1990’s.

Formal RM was introduced to NASA as Continuous Risk Management (CRM). Developed

by the Software Engineering Institute (SEI) at Carnegie Mellon, CRM is a largely qualitative

method of addressing risks throughout the implementation phase of a program [34]. CRM

centers on clearly stating risk scenarios, ranking which risks deserve more engineering at-

tention, and working to mitigate them throughout the project’s life cycle. Figure 2-1 shows

the original CRM method with its strong emphasis on communication. Surrounding com-

munication in the middle of the figure are five functions: identify, analyze, plan, track, and

control. Nominally each risk scenario goes through each of the five functions sequentially,

though the process is implemented continuously, and multiple risk scenarios are addressed in

parallel. Risks are evaluated iteratively throughout the project’s design and operations. The

evaluations are largely qualitative and the method relies on heavily on engineering judgment

combined with procedural control and documentation.

This original CRM method succeeded in bringing more focus to the idea of risk man-

agement as an important project management function. Under DRM risks are tracked in a

document that contains a formal risk statement for each identified risk. CRM also introduced

the risk-matrix to NASA projects which is still a familiar method for characterizing project

37

Figure 2-1: The actions of the CRM model surrounding the central theme of communication.

risks. A sample risk matrix is in Figure 2-2. Note that it utilizes the triplet definition of risk:

each discrete scenario S is plotted on a graph of likelihood versus consequence (K and L).

As indicated by the coloring, the scales on likelihood and consequence are from 1 to 5, with

5 being more severe or more likely. The arrows indicate trend lines, and no arrow indicates

the risk has not changed since the last analysis. The risk scenario numbered 39, for example,

may represent risk of a certain hardware failure. It’s likelihood is measured a 4, meaning

that it is the most likely of the risks shown to occur. The consequence of this risk scenario

is a 3, meaning it is the least damaging to the overall mission of the risks listed. Specific

definitions of what a 3, 4 risk means to the system and what mitigations would be pursued

vary somewhat depending on the specific project and that project’s risk tolerance. The risk

matrix captures several aspects of the CRM model. The results of Identify and Analyze are

displayed in a manner that aids Planning and Tracking, ideally leading to Control of the

system risks. The continuity of CRM is captured in the trend arrows on the graph.

However, CRM as a comprehensive RM method has some shortcomings. CRM tends to

focus on individual risks, which are mitigated in isolation of each other. While it provides

a useful framework for helping engineers think about risks, in the end the method relies

38

Figure 2-2: Example risk matrix showing risk plotted on map of likelihood versus conse-quences with arrows indicated trends

wholly on qualitative engineering judgment. There is no mechanism in the CRM system

for exploring the full impact of a design decision with respect to risk. The selection of

a risk mitigation activity, a test for example, can be assessed with respect to individual

risks but not easily compared with other risk mitigation activities against aggregate system

risk. There is no method in the CRM framework for assessing risk with respect to top level

performance requirements from the full set of risk scenarios.

While NASA was developing its RM approach, it was also going through changes in its

broader engineering philosophy. In 1992, NASA adopted a Faster, Better, Cheaper (FBC)

initiative which emphasized low and cost and short schedule goals in addition to mission

performance. The idea behind FBC was to constrain mission resources in an effort to spur

innovation and promote efficient design. The goal was to launch missions in shorter periods

of time with smaller budgets. While FBC did lead to lower costs and shortened mission

timelines [35], it also led to several highly publicized failures. In particular the Mars Climate

Orbiter, Mars Polar Lander, and the Deep Space 2 probes all failed in 1999 [23, 24]. These

failures triggered an independent investigation and an Inspector General investigation of the

FBC philosophy. While neither of the final reports disparaged FBC out of hand, they both

recommended many changes for NASA policies [25, 26]. These recommendations included

39

providing better communication of guiding NASA directives and improving risk manage-

ment tools. In the years since FBC, NASA has done much to continue to develop its RM

philosophy. While the FBC experiment didn’t last long, the experience of risk management

in highly constrained missions can be seen as analogous to the current high-risk low-cost

mission environment.

2.2.2 Current NASA RM

At NASA, RM and CRM were synonymous until 2008 when NASA expanded its definition

of risk management to include both CRM and risk informed decision making (RIDM). The

addition of RIDM is focused on giving a quantitative rigor to the functions of the CRM circle.

RIDM feeds back into the CRM circle, augmenting the CRM process but not replacing it.

NASA published a RIDM handbook in 2010 [36]. In 2011 NASA published a new RM

Handbook that completed the integration of RIDM with a refocused CRM that makes use of

the quantitative results of RIDM [32]. At a high level, RIDM is a quantitative guide to aid

the decision making process. It consists of three phases, Identification of Alternatives, Risk

Analysis of Alternatives, and Risk Informed Alternative Selection, as shown in Figure 2-3.

Figure 2-3: The three parts of RIDM from the NASA RIDM Manual [36]

The RIDM methodology emphasizes quantitative assessments, with the impact on the

high level performance requirements in mind. The first phase of RIDM is Identification of

Alternatives. Alternative decisions are identified qualitatively, but each is expressed in terms

40

of quantitative performance objectives and associated performance measures. For example,

if minimizing cost is an objective, the estimated cost of an alternative is the performance

measure. A thorough understanding of the project’s performance objectives is therefore nec-

essary to the Identification of Alternatives step. RIDM emphasizes communication between

the various functional members of the project, the stakeholders in the project, and the engi-

neer carrying out the analysis in order ensure a correct list of project performance objectives

and measures. In the second step, Risk Analysis of Alternatives, the performance measures

of each alternative are quantified, taking into account uncertainty in performance estimates,

resulting in a probability density function over each performance measure for each alterna-

tive. The results are summarized in a document called the Technical Basis for Deliberation.

This document is updated and improved every iteration of the RIDM process. The third

part of RIDM is Risk Informed Alternative Selection. This begins as a discussion between

the stakeholders and the decision maker and ends with either a decision to implement one

of the alternatives, to go back to the first step and identify different alternatives, or to go

back to the second step to carry out more analysis. In the end the decision is made based

on engineering judgment, informed by the quantitative risk analysis but not dictated by it.

The union of RIDM and CRM begins with an initial RIDM assessment early in the mission

design phases. The CRM process is kicked off with the results of the first RIDM assessment,

and then an iterative loop is established, as shown in Figure 2-4. The RIDM steps shown

here are expanded from the three main steps listed in Figure 2-3 in order to better show

how they interact with the different CRM functions. As shown, RIDM interacts with all

five of the CRM functions. Notice also that document was added to communicate in the

center of the CRM circle. The CRM method’s reliance on documentation and procedures

is what allows the implementation of the RIDM results into the overall risk management

process. RIDM is used to crunch the numbers and CRM ensures that communication and

documentation are consistent and that the risk posture of the system at large is maintained.

Adding RIDM to the CRM process addresses some of the biggest problem of the pure

CRM methodology. CRM focuses qualitatively on individual risk scenarios, referring here

to specific chains of events which can lead to a failure to meet a requirement. A component

failure leading to a decrease in an overall performance metric, for example is an individual

41

Figure 2-4: The integration of RIDM and CRM [37]

risk. CRM could address both technical and programmatic risks in this way. Because of

its qualitative approach, there was no real way to rigorously treat risk in the aggregate

with respect to high level performance requirements. The new NASA RM is more holistic.

Performance risks still meet the triplet definition of risk set out earlier, but the scenario

can be more broadly defined. Instead of a specific chain of causal events, the scenario can

be not meeting a performance requirement based on a probabilistic assessment of all the

discrete risk scenarios that affect that requirement. To accomplish this RIDM makes some

use of Probabilistic Risk Assessment (PRA) [38] in the second RIDM step, Risk Analysis of

Alternatives. PRA came from the safety field rather than the risk field, and has been used

at NASA since the Challenger accident. The idea of PRA is to incorporate uncertainties

into performance and risk modeling in order to create a probability distribution of expected

performance for each performance outcome. Risk tolerance is expressed as a probability

of not meeting the requirement. RM throughout a project life cycle seeks to minimizing

risk by make choices that increase the mean of the distribution and decrease its variance.

Increase the mean is accomplished through better design choices. Decreasing the variance

is accomplished through risk mitigation activities such as testing and analysis. Figure 2-5

shows how the risk of not meeting the requirement on performance measure X decreases

throughout the project life by showing the modeled distribution of performance at three

42

different project milestones. In between milestones, some risk mitigation activities have

occurred which increased knowledge of how the system will perform, decreasing the variance

and therefore the risk.

Figure 2-5: The risk of not meeting performance measure X at three project milestones [38]

2.2.3 NASA RM Documentation Structure

The current NASA RM philosophy, described above, is set out in a NASA RM Handbook [32].

However, this handbook is guidline for NASA missions and is not prescriptive. Implementa-

tion of NASA guidlines follows from a set of governing documents, at both the Agency and

Center levels. Agency level documents set policy and requirements for all of NASA; how-

ever, each center is responsible for determining how to implement the agency level directives.

Towards that end each center develops their own set of documents. Figure 2-6 shows the

structure of NASA agency level documentation related to risk. At the top are NASA Policy

Directives (NPD) which set the foundation for agency level policy. At the next level NPD

7120.4 [39] is NASA’s engineering and program/project management policy. NPD 7120.4

gives rise to three NASA Procedural Requirements documents that break NASA program

up by functionality, including NPR 7120.5 [40], the guiding program management document

for space missions.

To complement the functionally oriented project management documentation, are disci-

plined oriented documents. NPR 7123.1 [41] is the NASA Systems Engineering Process and

Requirements document which gives rise the NASA SE Handbook [42]. This handbook is

43

Figure 2-6: NASA agency level risk documentation structure [36]

meant as a guidance rather than a prescriptive document and provides an example imple-

mentation from an SE perspective of the 7120 series documents. NPD 8700.1 describes the

overarching NASA mission assurance policy and NPR 8000.4 describes RM procedural re-

quirements. Finally, NPR 8705.4: Risk Classification for NASA Payloads [27] is the agency

level document, that provides a risk classification of the space missions covered by NPR

7120.5.

NPR 8705.4 breaks payloads up into four risk classes, A through D. Class A designates the

least risk tolerant classification, and Class D designates the most risk tolerant classification.

Evey payload is assigned a risk classification based on several factors including its impact

to NASA strategic level goals, national significance, cost, and others. Since a mission or

even a single satellite may have multiple functions and goals with different levels of impact,

individual spacecraft may host payloads in any of the four risk categories. An example of a

current Class A mission is the James Webb Space Telescope. The OSIRIS-REx sample return

is a Class B payload. Recommendation are provided for each risk class to demonstrate how

44

to apply increasing risk tolerance to specic design areas. For example, NPR 8705.4 describes

how to approach prototype / engineering model / flight model harware as shown below:

Class A: Engineering model hardware for new or modified designs. Separate prototype

and flight model hardware. Full set of assembled and tested “flight spare” replacement

units.

Class B: Engineering model hardware for new or significantly modified designs.

Protoflight hardware (in lieu of separate prototype and flight models) except where

extensive qualification testing is anticipated. Spare (or refurbishable prototype) hard-

ware as needed to avoid major program impact.

Class C: Engineering model hardware for new designs. Protoflight hardware permitted

(in lieu of separate prototype and flight models). Limited flight spare hardware (for

long lead flight units).

Class D: Limited engineering model and flight spare hardware.

Note that NPR 8705.4 only applies to the missions that are managed under NPR 7120.5.

While traditionally this applies to most space missions, it does not cover technology demon-

stration or research projects managed under NPR 7120.8. Some cubesats, and ISS borne

research payloads for example fall under 7120.8 rather than 7120.5. For these missions, there

is no Agency level risk classification document.

At the Goddard Space Flight Center (GSFC), the managing center for the OSIRIS-REx

mission, a separate documentation structure has been created to implement the agency level

procedures. Relevant risk documents include GPR 7120.4 [37] and a forthcoming GPR

8705.4. The former details how GSFC projects will implement NPR 7120.4 and the latter

does the same for NPR 8705.4. NPR 8705.4 is high level in its recommendations, such as the

EM/FM hardware recommendations above. GPR 8705.4 provides more specific guidance

such as which standards printed circuit boards must be fabricated to, and what inspection

criteria need to be used on harnesses and cables. The Goddard 8705.4 also provides more

specificity on how to categorize projects, adding four other risk categories. The NPR 8705.4

applies only to projects that fall under NPR 7120.5, which covers most spaceflight programs.

45

However there are many applications which do not fall under NPR 7120.5 which benefit from

a clear risk classification. Goddard identifies these other classifications as:

Ground System Class: Hardware, software, or othe assests that are used on the

ground in support spacecraft operations. Distinct from Ground Support Equipment

(GSE). Follows the overall mission risk posture.

NPR 7120.8 Class: Missions, primarily for technology demonstration, that are not

covered by 7120.5. Sounding rocket payloads, some cubesats and some ISS hosted

payloads fall into this category. Technical risk is expected to be high.

Do No Harm (DNH) Class: Technical risk is very high. The only high level

requirement for these missions is not cause a safety concern to the hosting platform.

No mishap is declared if a DNH payload does not meet its secondary science objectives.

Hosted Payload Class (host requirements): This refers to the host platform

requirements, usually the spacecraft bus. Meant to cover exceptions to the Class A-

D requirements that arise from commercially sourcing the bus from an established

contractor.

2.3 Risk Management Applied to High-Risk Missions

The NASA RM structure is comprehensive. The application of CRM and RIDM to a project,

with PRA applied to the more important performance metrics is a thorough way to manage

risk throughout a missions life cycle. However, not all missions employ the full spectrum

of tools to RM. High-risk, resource constrained missions often do not have the resources

to devote to the documentation and procedure intensive aspects of RM. The application of

NASA guidelines to high-risk missions, especially those with tight resource constraints can

be challenging.

46

2.3.1 High-risk, Resource Constrained Missions

Describing a mission as high-risk or low-risk does not necessarily refer to the actual level of

risk present in the system. Rather, a mission’s risk posture refers to the risk-tolerance, or

level of risk which the mission is willing to accept. There are many reasons why a high-risk

or low-risk posture is adopted, and a diverse set of missions fall into both categories. High-

risk missions are often small, low cost satellites such as cubesats. Academic institutions

in particular have be putting more and more small satellites on orbit in recent years in

an attempt not only to further research, but also to provide hands-on space experience to

students [28]. Especially in an academic setting where education is often the first goal,

these missions are willing to accept higher risks in the design and testing process. Student

satellites are often also high-risk because of a low budget and the need to meet a launch

schedule based on ride-shares.

However, high-risk does not necessarily equate to a small spacecraft or payload, larger

projects can be high-risk as well. The form factor of the mission does not dictate risk

tolerance. Similarly, the high-risk mission is not necessarily simple or low budget. A complex

mission with a large budget could have a high-risk tolerance in order to more quickly develop

a new technology or reach a one time launch window on short notice. The LCROSS mission,

for example, was a Class D mission that used an entire ESPA ring as its bus, had a $79M

budget, and an ambitious mission to search for lunar water [29]. It’s high risk tolerance was

due to its short development timeline, 31 months from conception to launch, its relatively

small budget for the scope of the project, and because it was a secondary payload on a more

important launch.

Risk tolerance is not necessarily related to size or budget; however, it is linked to overall

resource constraints. A mission that has large margins on development resources such as

personnel, budget, and schedule rarely has reason to be treated as high-risk (except in the

case of high technical risk due to untested technology). Low-risk missions are often also

subject to tight-resource constraints, and even these missions have to acknowledge that such

constraints will drive up the amount of risk that must accepted. So, while not all resource

constrained missions are high-risk, all high-risk missions are resource constrained. Being

47

resource constrained means that less personnel,budget and schedule are available for the

project, and for risk management. However, high-risk tolerance should not equate to a lack

of risk management. In fact, risk management can help a high-risk project understand what

risk it is accepting and where to spend its valuable resources.

In the NASA structure, high-risk missions do not apply many of the more resource

intensive aspects of RM. For example, only the lowest risk categories, Class A and some

Class B missions, are required to carry out detailed PRA. For Class C and Class D missions,

a detailed Technical Basis for Deliberation document with quantized performance measures is

not required. What is required is usually negotiated between the payload and the managing

Center early in the project development. Often, and as is the case on REXIS, only a risk

matrix and formal risk statements document is required. Efforts are typically not made

to quantitatively address the holistic risk state of the system or evaluate design decisions

explicitly in terms of risk. Guidelines such as NPR 8705.4 are followed and details are

negotiated with the project management or NASA center.

2.3.2 Difficulties of High-risk, Resource Constrained RM

Many difficulties are inherent to implementing risk management on high-risk and resource

constrained missions. Some problems stem from the diversity of high-risk missions from

student projects to cubesats to an interplanetary mission like REXIS. The diversity of the

high-risk category leads to difficulties crafting guidance that not too general to be of any

real use, or too specific to be broadly applicable. GSFC is attempting answer this concern

with definitions and ambiguous guidance by implemented more specific high-risk categories

in the forthcoming GPR 8705.4.

High-risk projects are often hosted payloads or in some other way interfaced with a

lower risk project. This leads to difficulties beyond just defining the risk classification of the

project itself. Many times, the host requirements will cause the payload to spend valuable

resources on risk reduction in an area of the design that is not important to the payload’s

performance measures. For example, the REXIS cover actuator presents more of a risk to

OSIRIS-REx than to REXIS, and REXIS has spent more time testing the actuator than

necessary if viewed purely from REXIS performance goals. Especially with hosted payloads,

48

such imbalances in risk posture may be dictated by requirements beyond the project itself.

Another difficulty in applying risk to high-risk payloads is making choices about which

risk mitigation activities to pursue. Ambiguous guidance combined with a lack of quantita-

tive knowledge of the holistic risk state of a project can lead to an unbalanced application of

risk mitigations. For example, two different tests may be under consideration for a project,

but there are only resources for one. Picking which test to carry out affects the overall risk

state of the mission. Some risks will be mitigated, but other may arise or be affected more

or less, depending on the system. The engineer could benefit from a quantitative analysis of

the performance measures of the system as affected by each test.

High-risk mission RM tends to focus on individual risks with little knowledge of the

aggregate risk state of the mission. There is no quantitative assessment of the risk state with

respect to high-level performance measures. Risk mitigation techniques are applied without a

quantitative analysis of which risk mitigation activities are more important towards reducing

the overall system risk. Chapter 5 discusses further some of the challenges of applying a

balanced RM approach, specifically to the REXIS SXM.

2.3.3 Considerations for RM of High-risk, Resource Constrained

Payloads

The application of risk management from Class A down through DNH should be seen as a

continuous spectrum. There is no discontinuity between Class A and DNH where the ideas

behind RM must change. The philosophy of dealing with risk should be the same, though

the resources available change the dynamics of the decision making process.

It must also be noted that risk tolerance need not be defined only at the project level,

or at the payload level. Especially in a high-risk mission it is useful to understand which

aspects of a system may be treated as high-risk and which must be alloted less risk tolerance.

This is especially helpful for hosted payloads, which often must meet external requirements

in excess of what is necessary for the payload itself. For example, if the payload is Class D,

but interacts in any way with a Class B instrument, then the Class D mission has aspects

of its design which must be treated as Class B. Even if the mission is uniformly Class D,

49

such as a free flying cubesat, there is still the question of which aspects of the design can be

accepted with higher-risk and which might need more attention. For a cubesat, for example,

an emphasis on radiation protection for EEE parts is not well-founded since the mission

lifetime of most cubesats is too short to get major radiation damage. Instead risk mitigation

could be spent payload, or the software, or on some other area that may have a large impact

on the high-leve system performance.

Knowledge of how different risk mitigations affect the overall system risk, is especially

important to resource constrained projects that need to optimize their cost and schedule

resources. Such knowledge only comes from a comprehensive RM. Without a clear structured

approach to RM, high-risk missions are left with trying to qualitatively implement the written

guidance. This can leads to unnecessary risks and an imbalanced posture. Some areas of the

design will have a lower final risk than necessary, and some will have more final risk than is

necessary.

50

Chapter 3

The SXM Design

3.1 SXM Overview

The Solar X-ray Monitor is a sub-assembly separate from the main REXIS spectrometer.

It is mounted on a gusset of the OSIRIS-REx bus that will face the sun while the REXIS

spectrometer observes Bennu. The SXM interfaces mechanically with the spacecraft through

an aluminum mounting bracket. The SXM interfaces electrically with the REXIS main

electronics board (MEB) through a cable routed along the spacecraft deck. The heart of the

SXM is an Amptek XR-100SDD silicon drift diode (SDD). The SDD is mounted on a small

PCB, the SXM electronics board (SEB, also called the preamp) that conditions the analog

signal before it is sent to the REXIS MEB for processing. The MEB’s SXM electronics

bin x-rays events in a histogram according to incident energy. The resulting histogram is

transmitted back to the ground where it is used to determine the solar x-ray spectrum.

Figure 3-1 is a photo of the REXIS engineering model SXM.

3.2 SXM Background

3.2.1 Purpose and Necessity of the SXM Measurements

The REXIS mission measures fluoresced x-rays from the asteroid Bennu. Florescence occurs

when an incident photon’s energy is absorbed by an electron, forcing the electron into a

51

Figure 3-1: Engineering Model SXM without cable or mounting bracket

higher energy orbital. The electron may decay from this excited state by emitting a photon

whose energy is the difference between the electron’s energy in the excited state and the

decayed ground state. Since electron energy levels are the same for each element and different

between elements, the energy of fluoresced radiation can be used to determine which element

emitted the photon. While exceptions and other decay modes also exist, fluoresced radiation

generally occurs in well defined energy lines.

Since fluorescence is dependent on the real-time incident x-ray spectral distribution and

magnitude, knowledge of the incident spectrum is necessary to interpret the REXIS data.

Simply observing the asteroid and finding bright or dim areas at the energies of specific

elements is not enough to determine the elemental abundances of Bennu. A bright image

at a certain energy could be the result of an actual abundance of a certain element, or it

could be the result of an unusually high incident flux at an energy that can excite that

element. With the exception of relatively low levels of cosmic x-rays, the incident spectrum

at Bennu can be said to come only from the sun. So a solar facing x-ray monitor mounted

to OSIRIS-REx can be said to be observing the whole of the incident x-ray spectrum.

As a result of solar variability, local, real time knowledge of the incoming solar spectrum

is necessary to properly interpret the fluorescent line data collected from Bennu. Changes

in total solar flux as well as spectral shape occur across the solar surface and during active

52

states over timescales as short as minutes [15]. Figure 3-2, shows an example of the energy

variability of the solar spectrum. The blue line shows the Sun in a quiet state (∼A state),

and the red line shows the solar spectrum in a strong flare state (∼X state). Note both the

variability in overall flux as well as the difference in spectral features between the various

lines. Both overall flux and spectral shape ultimately drive the x-ray spectrum of Bennu

and affect REXIS’s ability to both spatially resolve spectrally-distinct regions on Bennu’s

surface as well as derive bulk elemental abundance ratios for its regolith [16].

Figure 3-2: Solar spectra as a function of energy for quiescent and flare states.

There is detailed, timely knowledge of the solar x-ray spectrum at earth. Imaging solar

x-rays is difficult from the earth’s surface, as the atmosphere is almost completely opaque in

the x-ray spectrum [15]. Above the atmosphere, several on-orbit observatories provide up-to

date knowledge of the solar x-ray state at the earth with excellent resolution. In particular,

Geostationary Operational Environmental Satellites (GOES) 12-15 each carry sun pointing

x-ray telescopes that observe two bands; 3 to 25 keV and 1.5 to 12 keV. However, the solar

x-ray state is highly variable in both time and location. The heliocentric angle between

the earth and Bennu during observations will be large enough (around 30 deg) that earth

based solar observations would not provide accurate knowledge of the local, incident x-ray

spectrum at Bennu. A local measurement of the solar state is necessary.

53

3.2.2 SXM Science Data

In order to determine the magnitude and shape of the incident x-ray spectrum at Bennu, the

SDD measure incident x-rays in the energy range of the REXIS CCDs, but with a smaller,

lower quality detctor. The solar detector need not be as large in area or as low in resolution

as the CCDs, since a detailed solar spectrum can be simulated with well characterized data

sets and lower quality measurements. While the solar state changes with time and location,

it does follow patterns that are well characterized and cataloged. Similar curves to what

are seen in Figure 3-2 can be generated as a function of solar coronal temperature. Specif-

ically, REXIS will employ CHIANTI spectral simulations, a commonly used astrophysical

database for x-ray astronomy [43, 44]. Figure 3-2 gives lines for 4, 7, 15, and 18 MK coronal

temperatures. By fitting SXM data to known curves, a solar temperature can be identified

and the established database can be used to fill in the rest of the x-ray spectrum with better

resolution.

Figure 3-3 is a block diagram of the SXM science data flow from the actual solar spectrum

to the estimated spectrum that will be integrated with the REXIS data. The input solar

photons create a charge cloud in the SDD that is amplified and output from the SXM to the

MEB. The MEB detects peaks in the voltage signal from the SXM and samples the analog

input with an ADC to create an x-ray event histogram. The x-ray histogram is packaged

into SXM telemetry by the flight software (FSW) and downlinked to the ground. The

histogram are taken simultaneously with the REXIS CCD images of the asteroid. While the

CCD images will integrate for 4 sec, the the SXM histogram is formed over a slightly longer

period, nominally 32 sec. The longer integration allows for a smaller SXM detector area,

but is short enough to ensure that the histogram is still provides timely spectral information

about the CCD data packets. The histograms and CCD packets are time tagged so that the

CCD data can be synced up with the histogram that was taken while each CCD data packet

was gathered. After downlinking, the histogram is fit to curves from the CHIANTI spectra to

estimate the solar coronal temperature. This temperature is in turn used to generate spectra

from the CHIANTI database. These spectra are considered the incident flux at Bennu for

the CCD data packets gathered during the histogram’s exposure.

54

Figure 3-3: SXM data flow block diagram

3.2.3 SXM Design Heritage

The SXM design is based on the Amptek XR-100SDD, which has spaceflight heritage. Pre-

vious versions of Amptek x-ray detectors have flown on two other space missions. The Solar

X-ray Spectrometer (SOXS) operated from 2003 to 2011 aboard the Indian geostationary

satellite GSAT-2. The SOXS experiment incorporated multiple detectors to study the solar

spectrum over a large range (4 keV to 10 MeV). Four Amptek XR-100CR detectors were

used to image the solar x-ray spectrum from 4 keV to 25 keV [45]. The Solar Photome-

ter in X-rays (SphinX) was flown in 2009 aboard a Russian solar orbiting observatory called

CORONAS-Photon [46]. SphinX utilized three XR-100CR detectors to image the solar spec-

trum with high resolution in both energy and time. The XR-100CR detector from Amptek is

the predecessor to the XR-100SDD that REXIS uses. The XR-100CR and the XR-100SDD

both use a very similar sealed, evacuated metal can with a beryllium (Be) window and 12

pins for the electrical interface. However, the XR-100CR detector is a PIN photodiode rather

than a silicon drift diode. They are both solid state detectors with similar operations, but

the SDD can achieve better resolution and higher count rates than the PIN. Both Amptek

models rely on internal Peltier Effect coolers to achieve low detector temperatures. The

mechanical and electrical similarities of the devices help lend some confidence to utilizing

55

the XR-100SDD in space, even though that specific device has no direct flight heritage.

The SXM also has design heritage in both structures and electronics from the Neutron

star Interior Composition ExploreR (NICER) project. NICER is an International Space

Station (ISS) mounted x-ray spectrometer launching in late 2016 to observe neutron stars

in the 0.2 to 12 keV band [47]. As with OSIRIS-REx, the managing NASA center for the

NICER project is the Goddard Spaceflight Center. In addition, the MIT Kavli institute,

which holds the NICER contract, is located at on the MIT campus, and one of the REXIS

co-investigators is an Associate Director of the Kavli Institute. The REXIS team is fortunate

to be able to work closely with the NICER team, and the SXM engineering design borrows

many elements from NICER. The detector array for NICER utilizes 56 Amptek SDDs. The

NICER SDD was originally the same XR-100SDD that REXIS uses. In an effort to decrease

rise time and increase temporal resolution, NICER has since moved to a CMOS detector,

also from Amptek. Nevertheless, the design work that NICER did with the XR-100 SDD

laid the groundwork for the REXIS SXM design. In particular, the NICER preamplifier

board and housing informed the design of the SXM Electronics Board and SXM preamp

case. Additionally, the SXM pulse shaping, trigger and timing circuitry were based on John

Doty’s early design of the NICER measurement and power unit [48].

While many aspects of the NICER mission were helpful to the REXIS team, the missions

also have some key differences that caused the SXM design to diverge from NICER. First,

the NICER mission requires accurate timing information and a very quick signal rise time,

REXIS is not interested in resolving timing. The differences in timing simplify the REXIS

trigger and timing circuitry as compared to the NICER design. The REXIS SXM must

withstand a long cruise to Bennu and a difficult radiation environment while NICER remains

in the relative safety of the low ISS orbit. Such environmental factors influence the SXM

structural and thermal designs. Finally, REXIS has need of a different collimator to restrict

the solar flux into the SXM and allow for a greater range of solar states.

56

3.3 SXM Top Level Requirements

REXIS requirements are split into 4 levels, and flow from the ORSIRIS-REx mission require-

ments, as well as NASA documentation. Figure 3-4 shows the REXIS requirements docu-

mentation structure, from higher level requirements at the top in level 1 to lower level, more

specific requirements at the bottom in level 4. Levels 1 and 2 consist mainly of ORSIRIS-

REx documentation and NASA agency level and center level standards. Level 3 contains the

REXIS to spacecraft interface control documents and the REXIS mission assurance imple-

mentation plan (MAIP), as well as high level REXIS technical requirements. The 4th level

of requirements contains specific, technical requirements for the REXIS instrument.

Figure 3-4: The REXIS Requirements documentation flow

The driving SXM science requirement is captured in the REXIS Level 2 requirement

REX-7 which states, “REXIS shall measure solar coronal temperature to within 0.1 MK

every 50 sec while observing Bennu in Phase 5B assuming a single temperature model”.

From this requirement are derived 10 more level 3 and level 4 requirements that relate

specifically to the SXM. The Level 3 requirements are related to SDD detector functionality,

and the Level 4 requirements deal with environment and operations requirements. The SXM

specific Level 3 and Level 4 requirements are given in Table 3.1, Table 3.2, and Table 3.3.

57

In addition, there are 21 software requirements relating to the SXM and several interface

requirements with the spacecraft that also relate to the SXM. The spacecraft Environmental

Requirements Document (Level 2) and Interface Control Document (Level 3) are the source

of requirements relating to launch load environment and interface temperatures that inform

the REXIS structural and thermal designs.

Table 3.1: SXM Requirements from REXIS Level 3 Requirements Document

ID No. Title Description

REX-73 Spectral ResolutionThe SXM shall have a spectral resolu-tion (FWHM) that is less than 200 eVfrom 0.6 to 6 keV

REX-74 Quantum EfficiencyThe SXM shall detect x-ray events from0.6 to 6.0 keV with quantum efficienciesas given in Table 3.2

REX-75 Field of View

The SXM shall have a full width zerointensity (FWZI) FOV of no greaterthan 60 deg full cone and a full widthfull intensity (FWFI) FOV of no lessthan 10 deg full cone

REX-225 Integration TimeThe SXM shall integrate counts for 320.1 seconds (nominally) to form a spec-trum

Table 3.2: SDD Quantum Efficiency Requirements

Range (keV) QE0.62 - 0.7 > 0.010.7 - 0.8 > 0.030.8 - 1.2 > 0.091.6 - 2.8 > 0.652.8 - 4.1 > 0.856.0 - 7.0 > 0.9

The resolution requirement is given in REX-73 over the range of interest to the SXM,

0.6 keV to 6 keV. The driving factor for the SXM to meet REX-7 is the spectral resolution

of the final histogram. Several factors contribute to a degradation of resolution including

inherent detector noise, thermally induced detector noise, electrical noise in the pulse pro-

cessing circuitry, quantization error from the ADC and uncertainties in reconstructing the

spectrum from CHIANTI data. The maximum theoretical resolution of the SDD is limited

58

by the fano noise inherent to the detector’s silicon wafer. The fano limit is well below the

REXIS in the energy range of interest, as shown in Figure 3-12. Thermally influenced noise

is reduced as the temperature of the detector decreases, hence the active cooler packaged

with the SDD and the derived, Level 4, temperature requirement in REX-229.

The quantum efficiency requirement in REX-74 dictates the efficiency of the SDD, and

therefore the amount of exposure time needed to gather sufficient photons for a histogram.

The required integration time is given in the requirement, REX-225. The quantum efficiency

of the SDD is a measure of the transmission efficiency of photon energy through the Be

window and the silicon wafer to the charge collected by the diode. This requirement ensures

that the integration time required of the SXM is reasonable. If the integration time is on

the order of minutes or longer, it becomes much more difficult to use the SXM to calibrate

individual CCD images, which each have an integration time of 4 seconds. The SDD’s QE

is driven by the design of SDD itself and has been characterized by Amptek for this device.

The integration time for the SXM is nominally 32 sec, but is updatable by command from

the user.

The field of view requirement in REX-75 is given to restrict the SXM from viewing parts

of the OSIRIS-REx spacecraft that could reflect or fluoresce x-rays into the detector. It also

ensures a large enough full intensity solid angle that the expected variations in the pointing

of the SXM towards the sun do not have an effect on flux into the detector. Since the SDD

is a COTS component, Amptek provided data was important in evaluating whether the XR-

100SDD would meet the needs of REXIS. More details on the performance of the Amptek

device with respect to these requirements are given in Section 3.5.1

From these Level 3 requirements, six Level 4 requirements are derived, and presented in

Table 3.3. These requirements deal mostly with environmental temperature limits that the

SEB and SDD must meet to fulfill the resolution requirement or to avoid component failure.

The SXM health and operation time requirements, REX-78 and REX-79, express the need

for the SXM to operate as long as the REXIS spectrometer is gathering data.

59

Table 3.3: SXM Requirements from REXIS Level 4 Requirements Document

ID No. Title Description

REX-76 Preamp Survival TempThe temperature of the SXM preampshall always be greater than -55 Candless than 85 C

REX-77 Preamp Operating TempThe temperature of the SXM preampshall be greater than -40 Cand lessthan 85 Cwhile operating

REX-78 SXM HealthThe SXM shall survive and remain op-erational through the end of Phase 8

REX-79 SXM Operation TimeThe SXM shall be capable of operating24 hours/day

REX-228 SDD Survival TempThe temperature of the SDD shall al-ways be greater than -65 Cand lessthan 150 C

REX-229 SDD Operating TempThe temperature of the SDD shall beless than -30 Cand greater than -70 C

3.4 Structural and Thermal Design of the REXIS SXM

Structural Overview

This section will describe the structural and thermal elements of the SXM design. The

assembly procedure for the SXM is given in Appendix B. A CAD rendering of the flight

model SXM design is shown in Figure 3-5. The SXM structure is relatively simple, consisting

of only three main pieces, the Collimator,the Preamp Case (also called the Housing), and

the Bracket. The SXM structural pieces are custom machined from 6061 T6 aluminum

alloy. The structure is coated with a passivation layer to avoid corrosions and enhance

thermal properties. The passivation is irridite for all surfaces that need electrical conductivity

including all screw holes. The other surface areas that are iridited are the preamp case steps

which contact the PCB and a small area around the grounding lug hole on the bracket.

Where an electrical connection is not required the sufrace of the aluminum is anodized.

The anodization is useful for thermal purposes because it has a low absorptivity and low

emissivity that helps heat flow away from the SEB and SDD. The whole assembly weighs

approximately 200 g, not including the wiring harness.

The SDD and SEB are encased in an aluminum housing and collimator that restricts the

60

Figure 3-5: The FM SXM Assembly

SXM field of view as shown in Figure 3-6. The housing is bolted to the mounting bracket,

and the bracket is attached to the spacecraft gusset. The bracket’s face is angled with respect

to the spacecraft deck in order to face the SDD towards the sun, as shown in Figure 3-5.

The SXM preamp case holds both the SEB and the SDD while providing a thermal sink and

radiation shielding for both. A cross section of SXM assembly in Figure 3-6 shows how the

SDD and SEB mate with respect to the preamp case. The collimator on top of the SDD

limits the solar flux available to the SDD.

Collimator Design

The collimator restricts the field of view fo the SDD to ensure that it meets REXIS require-

ments on SDD Full Width Full Intensity (FWFI) and Full Width Zero Intensity (FWZI) field

of view (FOV). For the REXIS requirements, the FWFI FOV is a measure of the maximum

angle of SDD off-pointing at which the SDD maintains a view of the sun with any portion

of the SDD detector (assuming the sun is a point source). The FWZI FOV is defined as

the maximum angle of SDD off-pointing for which the center of the SDD still views the sun

(again assuming the sun is a point source). The top of the SDD’s silicon sits 0.147”from the

bottom of the collimator, giving a full width full intensity (FWFI) FOV of 15.11, ±0.08.

61

Figure 3-6: A cross section of the SXM showing the SDD and collimator mounted to thepreamp case

The sides slope away giving a full width zero intensity (FWZI) angle of 42.32 +0, -1.

This design meets the requirement, REX-75, for both FWFI and FWZI angles with ample

margin.

The collimator also restricts the SDD detector’s effective area to allow the SXM to

function in higher activity solar states. To ease manufacturing, the hole in the middle of

the collimator has a diameter of 0.039”, the diameter of a standard number 61 drill bit.

The drawing allows for ±1 mil variation in the diameter. The full area of the detector is

25 mm2. An internal collimator restricts the effective area of the SDD to 21.5 mm2. The

SXM external collimator acts a pinhole and further restricts this effective area. The final

detector effective area is 0.79 mm2, assuming a collimated solar input, or up to 1.63 mm2 if

the solar input comes from a wide input angle. The reduction in effective area ensures that

the SDD will not be overwhelmed by high count rates during periods of high solar activity.

It is also large enough to ensure that the SDD will gather enough counts during quiescent

solar states to continue to provide a solar spectrum estimate for the CCDs.

Thermal Considerations

A good thermal connection between the SDD and the spacecraft is critical to allow the

TEC to effectively cool the SDD. Low detector temperature is important for optimal SDD

62

performance; and the TEC provides active cooling of the detector itself. However, the

TEC operation also creates heat that must be conducted away from the SDD. Therefore, a

thermally conductive layer is used at the mechanical interfaces between the SDD and the

SEB, as well as between the SXM bracket and the spacecraft. Because the pins of the SDD

extend from the baseplate of the SDD through small holes in the case, there is a danger

that the gap filler that is used for the thermal connection will touch one or more of the pins.

Therefore the gap filler needs to be electrically insulating. In order to allow for replacement

of the SDD should it or the SEB break during testing, a dry gap filler is used rather than

a hard drying liquid. CHOT-THERM 1671 meets these criteria. A thin, white material

with the texture of a fabric. CHO-THERM can easily be cut to fit a given a mechanical

footprint. One piece of CHO-THERM is placed at the interface between the SDD and the

housing and another between the bracket and the spacecraft deck. These precautions at

important thermal interfaces maximize the efficiency of the spacecraft as a heat sink for the

SDD [49]. Note that since the CHO-THERM is not conductive, the SDD case is no longer

a ground point to the preamp case. Three of the 12 SDD pins are connected to ground on

the SEB including one pin that is also connected to the SDD case; therefore, a good ground

connection is still achieved between the SDD and the PCB.

The thermal design was validated with tests on the engineering model SXM. Details of

the extensive thermal testing carried out on the EM SXM can be found in Kevin Stout’s

thesis [49]. One goal of the testing was to characterize the TEC performance over the

expected range of interface temperatures between the spacecraft and the SXM. Good thermal

coupling between the SXM and spacecraft is important to allow the TEC to effectively cool

the detector and dissipate the heat the TEC will generate. The EM test setup was flight-like

except that the interface between the SXM bracket the ’spacecraft’ or chamber interface

plate used CHO-THERM rather than a wet RTV. The temperature difference between the

SDD housing and the interface plate shows the thermal coupling achieved between the SDD

and the spacecraft. Results are shown in Figure 3-7. The more power dissipated by the

TEC, the higher the temperature difference between the SDD housing and the spacecraft

interface.

The difference in temperature increases with increased TEC power draw and with de-

63

Figure 3-7: The SDD housing temperature is plotted against the interface plate temperaturefor five different interface temperatures.

creased interface plate temperature. The interface temperatures expected on flight are be-

tween -30 Cand 50 C. The set point for the FM TEC voltage is 3.5 V (see Section 4.1.1).

So the maximum expected difference between interface plate and SDD housing temperatures

is between 4 Cand 10 C, depending on the interface temperature. In order to help reduce

the 4 Cdivergence in the hot case, the footprint of the preamp case around the screws that

attach the preamp case to the bracket was increased. This increases the surface area of the

preamp case which contacts the bracket, increasing thermal conductivity.

Radiation Considerations

Another function of the collimator and preamp case is to provide radiation protection to the

SDD. The Amptek device is a COTS component, and as such is not specifically designed

to resist damage by high energy radiation or energetic particle impact. The SXM does not

have a cover to protect the SDD from radiation and instead remains exposed to potential

damage for the duration of the transit to the asteroid.

Radiation damage to the silicon itself causes incomplete charge collection and increases

the charge transfer inefficiency, both of which degrade spectral resolution and cause more

frequent resets of the detector. In addition, the circuitry inside the SDD (which includes a

JFET, the TEC temperature diode, and the TEC itself) could be damaged by radiation and

64

cause the SXM to fail. The detector reset is necessary to clear charge from the detector to

allow continued functionality. The reset signal is handled by the SEB, and is discussed more

in Section 3.5.2. A radiation damaged detector will experience more frequent resets, so the

reset rate at a given temperature is a useful proxy for measuring radiation damage during

testing.

The expected REXIS dose is roughly calculated to be on the order of 1 krad. This number

comes from a rough, if conservative estimate assuming a equal radiation environment from all

angles (not counting structural attenuation from the spacecraft) and a conservative radiation

environment. In order to interpret this estimate, the effect of radiation on the SDD must be

known. The NICER program subjected several Amptek devices to radiation doses in the Fall

of 2013. Functional tests before and after the radiation dose show that reset rate increases

and resolution is degraded [50]. The NICER results are shown in Figure 3-8. The figure

shows an increase of over an order of magnitude in the frequency of resets over a similar range

of detector temperatures before and after testing. The dose in this case was about 600 rads.

The NICER data shows that we can expect a significant increase in reset frequency due to

radiation damage. However, it also shows that the detectors did not catastrophically fail at

600 rads, and the TEC was still able to actively cool the SDD to well below the REXIS SDD

temperature requirement.

In order to reduce radiation seen by the SDD, as much of the SDD as possible is enclosed

by the preamp case and the collimator. The preamp case also protects the electrical com-

ponents on the SEB. The bulkhead mounted SMA connector allows for a completely closed

structure around that connector. Though the MDM connector is not bulkhead mounted,

the Preamp case and collimator close off much of the line-of-sight access to the SEB from

that connector interface. Figure 3-9 shows a view of the SXM towards the MDM connector.

The metal piece underneath the MDM blocks much of the line of sight to the SEB, but also

means that the MDM must be installed after the SEB is integrated into the the preamp

case (see Appendix B for assembly steps). The collimator on top of the preamp case also

has a piece which extends over the MDM connector in order to further block line of sight

and provide extra radiation protection. The collimator’s small aperture provides additional

protection for the SDD’s silicon and other components from radiation damage.

65

Figure 3-8: Results from irradiation of three SDD detectors to 600 rads. Time betweenresets are plotted before and after irradiation for various temperatures.

3.5 Electrical Design of the REXIS SXM

The overall SXM electronics design is separated into the SXM subassembly and the SXM

electronics on the MEB. This section discusses the SXM subassembly including the Amptek

SDD and the SXM Electronics Board. The interface with the MEB will also be discussed.

Details of the MEB support electronics, FPGA, and software that interact with the SXM

will be discussed in Chapter 4. A functional block diagram of the SXM electronics design

including both hardware and software is shown in Figure 3-10.

3.5.1 The Amptek SDD

The Amptek SDD, shown in Figure 3-11 [51], is a silicon drift detector with an effective

area of about 21.5 mm2. A two stage thermo-electric cooler (TEC) is directly below the

detector, enclosed in the SDD housing. The TEC is a Peltier effect active cooling device,

providing up to a 90 Ctemperature difference between the detector and the XR-100SDD

base [51]. Also on top of the TEC is a temperature diode to provide feedback about the TEC

performance. The TEC and detector are packaged within a Ni housing that holds in a place

a 25 m2, 0.5 mil thick beryllium window. This Be window is brazed to the Ni housing to

66

Figure 3-9: Front view of the SXM showing efforts to reduce line of sight around the MDMconnector

provide an airtight seal. The inside of the packaging is evacuated to allow for better thermal

performance of the TEC and to avoid attenuating incoming photons. The Be window blocks

light in the visible spectrum to reduce noise in the detector. The nickel housing sits on

a Kovar base-plate with 12 gold plated pins that provide the electrical interface between

the XR-100SDD and the SEB. A mounting stud secures the Kovar baseplate to the SXM

housing, ensuring a strong mechanical connection as well as a good thermal path between

the SDD and the SXM housing. The SDD temperature limits for operations and survival

meet the requirements listed in REX-228 and REX-229.

Electrically, the input photon impacts the silicon of the SDD and creates a charge cloud

in the silicon. The detector is negative biased, and the electrons are drawn towards the anode

of the diode, resulting in a current flow across the diode. The current causes a corresponding

voltage spike at the input to the SEB preamplifier. The SEB output is sent over a coax cable

to the MEB for signal processing. The pinout for the 12 pins which leave the SDD is given

in Table 3.4. Looking at the base of the SDD with the orientation feature (see Figure B-6)

in the top right, pin 1 is the top right, and pins 2 - 12 run sequentially, counter clockwise.

The SDD must achieve a FWHM resolution of <200 eV during operations in order to

meet requirement REX-73. According to the Amptek data sheets such a resolution should

be very possible given the SXM’s peaking time of 4 µs. Figure 3-12 shows the performance

67

Figure 3-10: An overview of the SXM electrical design

68

Figure 3-11: The Amptek XR-100SDD, CAD mock-up and photograph without Be windowand Ni housing

Table 3.4: SDD pin-out

Pin Signal Pin Signal1 - TEC 7 output2 Temp 8 reset3 + TEC 9 GND4 NC 10 -5 V5 Feedback 11 GND6 Drain 12 -HV

of the XR-100SDD for various peaking times over a large energy range. Also plotted is the

detector’s fano limit, the theoretical minimum resolution of the detector. The SXM peaking

time gives a resolution of around 150 ev. But peaking time is not the only parameter to affect

the resolution, the detector temperature is also important. NICER carried out resolution

testing with the XR-100SDD at various temperatures and found the data shown in Figure 3-

13. This test was carried out with an unknown peaking time, but from Figure 3-12 it appears

to be near 4 µs. The SDD reaches the REXIS required resolution at only -5 C. There is a

clear ‘knee’ in the data that shows diminishing returns for temperatures lower than about

-10 C. Nevertheless, the temperature requirement, REX-229, calls for a maximum SDD

operating temperature of -30 Cto provide margin for the resolution requirement of the

SXM. This margin is necessary to account for added elctrical noise on the flight system and

potential radiation damage over the long flight to the asteroid.

The quantum efficiency (QE) of the detector is a measure of how efficiently incident en-

ergy of the photon is transfered into electrical energy by the diode. Detectors with low QE

69

Figure 3-12: The resolution vs. energy curve for the Amptek XR-100SDD at various peakingtimes

require longer observation time to achieve the same results as a higher QE detector. Longer

integration times are not ideal for the REXIS because of the potential for short time scale

variability in the solar spectrum. The QE of the SDD must meet the requirements laid out

in REX-74 and Table 3.2. For the Amptek SDD, QE is driven by transfer through the Be

window, which is 0.0005”thick and the Si wafer, which is 500 microns thick. The data in

Figure 3-14 is from Amptek and shows expected QE for the XR-100SDD. Beryllium essen-

tially acts as a high-pass filter for the solar spectrum; the window is opaque to light at lower

energies. The left side of the curve in the Amptek plot is dominated by the transmissivity

of the Be window. Visible light has energy ¡10 eV, and the opacity of Be in the visible

spectrum is important to SDD performance because it limits extra noise from corrupting the

x-ray data. The right side of the figure is dominated by the transmissivity of the Si wafer.

Si of 500 um thickness is opaque to light in low energies up until about 10 keV. Opacity of

the Si means that it will absorb the whole of the photon energy rather than letting it pass

through. The Amptek QE plot shows that the SXM meets QE requirements over all the

energy ranges specified in REX-74.

70

Figure 3-13: The resolution vs. SDD temperature curve for the Amptek XR-100SDD fromNICER test results

3.5.2 SXM Electronics Board

The SXM electronics board (SEB) , shown in Figure 3-15, is a preamplifier for the SXM

analog signal. The SEB sends the raw diode output from the SDD through an op-amp and

a capacitor before the signal is transmitted over a coaxial line to the SXM electronics on

the MEB. The SEB also provides feedback to the diode and handles the reset signal. The

reset signal occurs when the SDD has saturated with charge. If the SDD saturates, incoming

photons will not cause a corresponding spike in the output. In order to correct this the diode

is flushed of charge and then rebiased. The whole process takes about 120 µs. In addition to

handling the detector and the reset, the SEB passes back two temperature readings, one from

the TEC mounted temp diode near the detector, and one from a PCB-mounted temperature

diode. It also provides power to the SDD and TEC, and the high voltage bias signal to the

detector. The SEB design has heritage from Amptek’s own preamplifier board, as well as

early versions of the NICER preamplifier.

The SEB is a four layer printed circuit board, with top and bottom signals layers that

overlay two internal planes. The two internal planes are a ground plane, and a split power

plane for the + and - 5 V power lines. The internal planes are constructed with 1 oz copper

to reduce noise. The four structural screws that mount the SEB to the SXM structure

are plated, grounded holes, with top and bottom layer ground pads surrounding the holes,

ensuring that the screws provide a good ground connection to the structure. For this reason,

71

Figure 3-14: The QE of the Amptek SDD showing tramsissivity plotted against incidentphoton energy

Figure 3-15: The EM SXM Electronics Board with MDM connector in place

the structure is coated with an iridite finish where the SEB mounts, as opposed to the

anodize finish used elsewhere for thermal purposes. Also, the four tapped holes that accept

the SEB mounting screws contain heli-coil inserts so that a staking compound (which could

negatively impact the ground connection) is not needed. The SEB is populated with mainly

COTS components, though the doides in the output signal chain are automotive quality.

The operating and survival temperature limits of all the parts on the board are within the

limits set in REX-76 and REX-77. COTS components in this application have a higher risk

of failure due to environmental factors such as radiation or temperature than a qualified

component would have. While COTS components are not typically used for space missions,

72

the high-risk posture of the REXIS, combined with the cost and schedule savings to be

gained by not procuring space quality parts is worth the added risk of flying COTS parts.

The SEB interfaces with other components using three separate connectors. J1 is a 9

pin micro-miniature D style connector mounted to the PCB. J2 is a structurally mounted

coaxial cable SMA connector. J3 is a set of 12 sockets that receives the SDD pins. The

pinout for J3 is given in Table 3.4 The pinout for J1 is given here in Table 3.5. The SEB

requires three separate power signals in order to function, 5 V, -5 V, and TEC power. The

TEC power signal is two wires, + TEC and - TEC, and the differential voltage is what drives

the TEC; it does not reference the common SXM ground. The large hole in the middle of

the SEB ensures that the SDD’s structural mounting stud is able to pass through the board.

A hex-standoff is used to secure the SDD to the board without having to reach a nut driver

past the SEB. The ability to secure the SDD to the SEB with post installation in the preamp

case allows for the SDD to be removed and replaced without disassembling the SEB from

the preamp case.

Table 3.5: SXM Electronics Board MDM pin-out

Pin Signal Pin Signal1 +5 V 6 -5 V2 GND 7 TEC Temp3 SEB Temp 8 -TEC4 +TEC 9 GND5 -HV

The output of J2 is an analog signal carried on a double shielded coaxial cable through

the bulkhead mounted SMA connector. For an SMA connector, the body of the connector,

including in this case the structural components that connect it to the SXM structure, is

the signal ground. This signal ground is connected to shielding that covers the signal wire.

Structurally, the connector is secured with two silver plated 2-56 socket head cap screws.

These screws are inserted into threaded through holes in the structure. Wires soldered to

the silver plated screws are connected to ground pads on the SEB to ensure a good ground

connection between the SMA cable and the board. The threaded holes in the structure

are iridite as opposed to anodize to provide a ground connection point to the structure.

Figure 3-16 shows how the ground and signal pads are connected to the SMA output.

73

Figure 3-16: Wires and solder joints between SMA connector and PCB

Figure 3-17 shows the output of the preamplifier due to an x-ray from a 55Fe decay. The

kα decay of 55Fe gives a 5.89 keV photon depositing charge in the diode. The capacitor

in the output chain acts as a charge to voltage converter, resulting in a spike in the raw

signal to the MEB of only about 40 mV. The rise time of the pulse is quick, but it tails

off slowly; the whole pulse lasts 50 µs. If the shaped signal fed to the ADC took 50 µs for

each pulse, throughput would be capped at 20 kHz. Additionally the ADC resolution over a

few 10’s of mV is poor since it needs at least a +2.7 V reference. The small amplitude and

long duration of the SEB output are some of the driving factors behind the MEB’s shaping

circuitry discussed in Section 4.1.2 below.

Figure 3-17: Preamp output voltage spike due to 55Fe

74

Chapter 4

SXM Electronics, Software, and

FPGA Design on the MEB

The SXM is a subassembly to the REXIS instrument. It interfaces mechanically with the

OSRIS-REx spacecraft, but relies on the REXIS spectrometer for power, data processing,

and telemetry interface with the spacecraft. The SXM interfaces with the Main Electronics

Board (MEB) through an MDM connector that carries power and telemetry as well as

an SMA connector that carries the analog SXM output. The division between the SXM

subassembly and the REXIS spectrometer is shown Figure 3-10, including relevant Section

numbers in this chapter. Details of the electronics, both hardware and software, that support

the SXM on the MEB are shown Figure 4-1. The MEB handles all of the power conversions

from the spacecraft, and the data processing for the SXM. On the software side, the SXM

data is integrated with the rest of the REXIS telemetry packets and downlinked to the user.

4.1 SXM Electronics Circuitry on the MEB

4.1.1 Power, TEC, and High Voltage Circuitry

The REXIS power supply comes from OSIRIS-REx as a 28 - 32 V DC power line. The raw

spacecraft power is filtered before entering the MEB circuitry. The input filter removes high

frequency noise in the supply, and also supplies a new, quiet circuit ground that is separate

75

Figure 4-1: An overview of the SXM electronics on the REXIS MEB

76

from the spacecraft power supply ground, called EMI Common. A third ground, chassis

ground, is also present in the system as the metal structure to which the REXIS boards are

grounded. Chassis ground has no active circuits and should experience little to no current

flow; it is tied to circuit ground through two diodes to keep it from floating. After passing

through the filter, the spacecraft power is converted down to the various voltages that the

REXIS hardware needs to function. The FPGA, for example requires 3.3 V, 2.5 V, and 1.0 V

inputs. The power flow showing the various converters and regulators is shown in Figure 4-2.

The SXM subassembly requires five power lines, +5 V, -5 V, -HV, and +TEC, and -TEC.

Since the TEC voltage is derived from the unfiltered spacecraft voltage, it requires its own

return, -TEC, rather than using the circuit ground. The +5 V power line comes to the

SXM from the +5 V converter on the MEB. The +5 V converter also powers other REXIS

circuitry. However, a dedicated FPGA line acts as a switch that turn the +5 V line on and

off. The -5 V line is derived from the -12 V converter on the MEB, meaning that it can only

be powered on when the -12 V line is also on. The 12 V lines are used to power the DE;

they will be powered on anytime that REXIS is in Science mode. The DAC’s and ADC for

the SXM run off 3.3 V power, which is powered on whenever REXIS is on.

The HV signal is necessary in order to bias the detector. The SDD can accept a range

of bias voltages. In keeping the Amptek and NICER designs the REXIS HV line biases

the SDD to -110 V. The HV signal is generated with a Cockroft-Walton voltage generator

(CW), essentially a series of voltage doublers. In this case 6 stages are used to step up a

+24 V input signal. A CW needs a varying voltage input in order to function. The varying

voltage for this circuit is supplied by a square wave generated by a switching output on

the FPGA. This square wave with a constant duty cycle creates a pulse width modulated

(PWM) signal for the CW. The CW is run with a nominal PWM of 32.5 kHz and a 50%

duty cycle. The inverted HV is more negative than the -110 V required by the SXM. A DAC

with an adjustable output is used to tune the HV to the desired output. The higher the

DAC output, the closer the HV value to its unattenuated maximum. The lower the DAC

output, the closer the HV line is to 0 V.

The TEC signal is also in need of a PWM generated by the FPGA. In the case of the

TEC, the device on the SXM is fed a PWM with a frequency such that the TEC ‘sees’ a

77

Figure 4-2: The power flow in the REXIS MEB from the spacecraft, including external powerinterfaces

DC voltage value equal to the average voltage of the signal. By using a PWM, adjusting

the duty cycle of the signal adjusts the apparent DC voltage to th TEC. The PWM used

for the TEC has a default frequency of 200 kHz and duty cycle of 20%. This produces a

nominal voltage across the TEC of 3.5 V. To achieve this voltage, the PWM must be used to

modulate a signal with a higher voltage than just the FPGA output pin. In the case of the

TEC, the raw spacecraft power is used instead of a filtered power line from one of the REXIS

power converters. The TEC uses an isolated return, therefore and is fairly immune to noise

in the system. Therefore using unfiltered power will not cause performance problems. Using

spacecraft power instead of MEB power decreases the demand on the REXIS EMI filter and

power converters. The TEC can draw up to 0.63 A in the worst case thermal condition for

TEC power draw. Such a large draw would stress any of the available filtered lines on the

MEB. A current limiter on the MEB in the TEC circuitry ensures that the output will be cut

if the TEC draws more than 0.8 A. Figure 4-3 shows current draws during EM testing of the

TEC for a series of constant SXM interface plate temperatures. The current draws at the FM

78

TEC setpoint of 3.5 V are highlighted with circles. Notice that assuming a constant 3.5 V

yields a changing current draw. The variations in current draw imply that the impedance of

the TEC changes, increasing with increasing temperature. Therefore, while the setpoint is

nominally 3.5 V, some variation is to be expected as the temperature of the SDD changes.

Figure 4-3: SDD temperature plotted against TEC power draw for several constant SXMinterface temperatures, with expected FM results highlighted

The goal of the TEC is to regulate the SDD temperature, as required by REX-229.

The EM SXM underwent extensive thermal testing to characterize the TEC performance.

The plot in Figure 4-4 shows SDD temperature plotted against voltage across the TEC for

the same constant interface temperatures as in Figure 4-3. The FM voltage setpoint is also

marked. Note that the flight interface temperatures range from -30 Cto +50 C. At +50 Cit

appears that REX-229 is met given a TEC voltage of +2.5 V or higher. In order to account

for protoflight testing levels of +60 Cand to provide some margin for flight, the set point

for flight is 3.5 V. Note also that REX-229 requires the SDD to remain above -70 C. This

constraint is violated in the coldest expected interface temperatures, as seen in Figure 4-3.

However, EM testing showed that temperatures in the -80 Crange did not cause any issues

for the TEC. Power draw is not a concern since the spacecraft supply is used rather than

the filtered REXIS supply, and the overall REXIS power use remains below the spacecraft

mandated power budget. A current limiter protects against short circuits, so there is little

79

incentive to chose a low setpoint. If the setpoint were much higher than 3.5 V the TEC

would actually generate more heat and instead of cooling the detector; it will warm up as

voltage increases.

Figure 4-4: SDD temperature plotted against TEC voltage for several constant SXM interfacetemperatures, with expected FM results highlighted

The load on REXIS power regulators is less because the TEC uses spacecraft power,

but using spacecraft power also adds complications to the MEB design. The raw spacecraft

voltage references EMI common, not the circuit ground that the rest of the instrument

references. Since the TEC is isolated from the rest of the SDD circuitry, it is no problem

if the -TEC line is not connected to circuit ground. In this case -TEC is connected to

EMI common. However, other circuitry involved in the TEC signal generation, including

the PWM signal from the FPGA references circuit ground. To get around the mismatched

grounds, opto-couplers are used to propagate the PWM signal onto the EMI common section

of the board. A filter on the TEC will eliminate some noise from the raw spacecraft voltage

if necessary. However, the TEC itself is not particularly sensitive to noise. The oscilloscope

trace in Figure 4-5 shows the PWM signal from the EM MEB with a frequency of 200 kHz

and a duty cycle of 15%. Note that the peak to peak voltage is over 10 V, but this PWM is

equivalent to a DC voltage of 2.5 V across the TEC.

80

Figure 4-5: An Oscilloscope trace of the EM TEC PWM signal

4.1.2 Shaping and Amplification

The signal from the SXM to the REXIS MEB is fed to a shaping and amplification circuit

before peak detection and analog to digital conversion is carried out. The raw input signal

is biased to about 3.3 V. When the SDD resets, the signal drops to 0 V before coming back

up to 3 V, as shown in Figure 4-6. The reset process takes almost 120 µs to complete. X-ray

events impacting the SDD cause voltage steps above that 3 V bias, as in Figure 3-17.

Figure 4-6: The SDD reset signal as seen at the SXM output

First, the MEB circuitry amplifies the signal. Next it passes the signal through a low

pass filter to remove any high frequency noise imparted on the signal by the preamplifier

during transmission over the coax cable. The signal is passed through a capacitor which

81

smooths out noise and yields a step function whose slope is proportional to the photon

energy at the detector [48]. Then the circuit must pass a signal to the ADC to sample and

provide some method of detecting the peak, so that the ADC can be sampled at the correct

time. The easiest way to accomplish this in hardware is with time derivatives of the signal.

Since the slope of the signal is proportional to the input energy, the first derivative of the

input will yield a pulse whose peak height is also proportional to the input energy. The

second derivative will cross zero at exactly the same time the first derivative peaks. The first

derivative is sent to the ADC to be measured, and a zero-crossing monitor on the second

derivative is used to determine when the sample should be taken. The first derivative is

given the name outu and second derivative is called outb. Figure 4-7 shows how a pulse

from a function generator is processed by the shaping circuitry. Note that is a pulse from

a function generator used to test and demonstrate the the circuit. The actual SXM input

signal is somewhat different, a sample of the SXM signal can be seen in Figure 4-17. The top

line, in blue, is the function generator input. The middle line, in green, is the 1st derivative,

outu. The lowest line, in yellow, is the second derivative, outb. The final step in the shaping

and amplification circuit is to subtract the bias from outu before it is passed along to the

ADC to be sampled. About 3 V of the bias is subtracted out, leaving just a 0.3 V bias in

the signal. This last 1/3 volt ensures that the signal, now named outu1, never goes negative.

This is useful as the ADC reading outu1 is not rated to accept negative input voltages.

Figure 4-7: Oscilloscope trace of the shaping and amplification circuit input and two outputs,outu (green) and outb (yellow)

82

4.1.3 Trigger and Timing

After the shaping and amplification circuitry is complete, the trigger and timing circuitry

takes over. The triggering function is taken care of by a combination of the FPGA’s resources

and actual hardware on the MEB. Triggering the ADC to read is handled by a state machine

in the FPGA that uses the output of two comparators to look for a peak in outu. These

comparators inform the state machine by tracking outb against reference voltages. The

first comparator’s output is called LLD, and it watches for outb to rise above an adjustable

voltage, VLLD, as shown in equation 4.1. This threshold voltage can be set above the

outb bias voltage plus the noise floor in order to avoid spurious triggers due to noise in the

outb signal. When outb rises above VLLD, the output LLD goes high and the FPGA state

machine is primed to trigger the ADC.

LLD = outb− V LLD (4.1)

The second comparator is activated to look for the peak of outu1. This peak is given

when the second derivative signal outb falls below its bias voltage Vb. The output of this

comparator is called Zp, and it follows Equation 4.2. The comparator also has a latch input,

a line from the FPGA that can be used to freeze the comparator state. This latch is called

ZLE. When outu reaches its peak, its derivative will have a zero crossing, or in this case a

Vb crossing. The falling edge of Zp causes the state machine to go from a waiting state to a

trigger state where the ADC chip select signal is low. This begins the ADC conversion. The

comparator outputs are shown in Figure 4-8, along with the analog signals and the ADC

chip select signal for reference.

Zp = outb− V b (4.2)

83

Figure 4-8: SXM Trigger Timing Diagram

4.2 The SXM FPGA Core

4.2.1 The REXIS FPGA Architecture

The REXIS Main Electronics Board (MEB) utilizes a Xilinx Virtex 5 field programmable

gate array (FPGA). The FPGA is essentially an array of configurable logic blocks that are

programmable in order to create specific circuit designs: a programmable application specific

integrated circuit (ASIC). The FPGA allows the designer to create and edit circuit designs

using a hardware description language such as verilog or VHDL instead of actual schematics.

The FPGA allows for much more flexibility in the design process, easy debugging of a design,

and reduces complexity by abstracting the design of some circuitry into a programming lan-

guage. Additionally, modern FPGA’s have built in functionality for processors and memory

management. REXIS uses a Microblaze soft-core processor instantiated on the FPGA to

run its software. The software uses block RAM internal to the FPGA as well as an external

84

SDRAM chip. The FPGA also hosts several IP core hardware peripherals. These cores are

interfaced with the software on one side and the rest of the MEB circuitry on the other

side. For example the UART ports which handle serial communications between the FPGA

and OSIRIS-REx are Xilinx provided IP cores. The SXM utilizes a custom FPGA core

which contains the necessary logic circuits to carry out peak detection from the comparator

outputs, sample the ADC, bin the histogram, and interface with the software.

4.2.2 The SXM Core Inputs and Outputs

The SXM core on the FPGA is written in a combination of verilog and VHDL. It is instan-

tiated on the FPGA when it is programmed, though it needs an sxm on signal from the

software to begin its logical operations. The SXM core is assigned 14 pins on the FPGA as

inputs and outputs. The pins assigned to the SXM core are described in Table 4.1. Four

pins control the ADC, three control the DACs for the TEC and HV, three are comparator

inputs or outputs, two generate PWM signals for the TEC and HV, and one each turns on

the 5 V power line and enables the TEC. The FPGA operates on a 3.3 V logic. The PWM

signals are generated by switching the pin from 3.3 V to ground on a set frequency. The

SXM core runs on the FPGA clock, which is 100 MHz on the flight model and 125 MHz on

the engineering model MEB. The SXM ADC (which is the same on both the flight model

and the engineering model) takes a maximum clock frequency (ADC SPCK) of 16 MHz.

The SXM core uses a Xilinx generic driver to interact with the ADC. The driver must use

integer division from the FPGA to reach twice the desired ADC clock frequency. The clock

is divided by 4 ∗ 2 to reach 12.5 MHz.

Table 4.1: SXM FPGA core pin descriptions

Net Description Net Description5V SXM ON Enable 5 V line to SXM ADC CNV ADC chip select

ZLE Latch enable for Zp comparator ADC MOSI ADC channel selectZp Output of Zp comparator ADC MISO ADC read value

LLD Output of LLD comparator ADC SPCK ADC clockTEC enable Enable to TEC power DAC SYNC N DAC chip selectTEC PWM PWM output to TEC DAC MOSI DAC channel selectCW PWM PWM output to CW DAC SPCK DAC clock

85

The pins in Table 4.1 interface the SXM core with MEB hardware circuits external to the

FPGA. To interface with the software running on the Microblaze, the SXM core has access

to two dedicated memory spaces. The Xilinx synthesis tool will generate a linker script and a

parameters file called x parameters.h which documents the location of these memory spaces

with respect to the software memory, allowing the software access to the SXM memory core.

Both memory locations are 4 byte addressed, and any memory location is 4 bytes. This is

because the bus which handles reads and writes between the software and the SXM core

works in 4 byte data widths only. Therefore, even though the control registers often only use

one bit, they are written to 4 byte memory locations. The first memory location is 64 bytes,

labeled sxm core and contains 8 control registers, each separated by 32 bits, that the software

uses to control the SXM core. The software maps to the registers using a structure of eight

32 bit integers. Writing to the registers follows the descriptions below. Reading from the

registers will return the last value written to that register. The registers are described here:

REG TRIGGER RESET: This registers only the least significant bit. A ’1’ indicates

that the SXM core state machine is in reset, a ’0’ indicates that the SXM core state

machine is ready to read from the ADC and bin histograms or gather housekeeping

data.

REG TRIGGER ENABLE: This registers only the least significant bit. A ’1’ indicates

that the SXM core state machine is in histogram mode. The state machine will look

for and bin peaks from the outu1 line and increment the histogram counters. A ’0’

indicates that the SXM core state machine is in housekeeping mode and will read from

the preamp temp, TEC temp and HC housekeeping ADC lines.

REG THRESHOLD: This register uses the 8 least significant bits. Valid inputs are

from 0 to 255. The value is used to set the level of VLLD, which is the output of the

DAC labeled in the MEB schematic as U25.

REG THRESHOLD ENABLE: This registers only the least significant bit. A ’1’ in-

dicates that the threshold register is read/write enabled. A ’0’ indicates that the

threshold register cannot be written to or read from.

86

REG DAC SELECT: This registers only the least significant bit. A ’1’ indicates the

HV DAC is selected. This is the DAC that controls the High Voltage level. A ’0’

indicates that the VLLD DAC is selected. This is the DAC that controls the VLLD

threshold level.

REG SXM EN: This registers only the least significant bit. A ’1’ indicates that the

SXM core is not in reset and the control registers are read/write enabled. A ’0’ indicates

that the SXM core is in reset. The control registers are not read/write enabled, the

state machine is in reset and the ADC will not be read.

REG HIST MIN: This register uses the 16 least significant bits. Valid inputs are from

0 to 4095. The value is used to set the lowest value, in adu, which will be included in

the lowest bin of the histogram.

REG HIST MAX: This register uses the 16 least significant bits. Valid inputs are from

0 to 4095. The value is used to set the highest value, in adu, which will be included in

the highest bin of the histogram.

The second memory space which the SXM core utilizes is 4000 bytes wide, labeled

sxm core mem0. This memory location includes the 512 bins, each of 2 bytes, in the SXM

histogram. These memory location are readable and writable by software. The software can

clear the histogram by writing zeros to all 512 bin locations. After the histogram bins are

stored 3 counters and 3 housekeeping values are included. Zeros can be written to the three

counter memory locations to the clear their values, similar to way the histogram bins are

cleared. The registers used to store the ADC values from channels 5, 6, and 7 however, are

not writable except by the ADC. These locations can only be read by software. The SXM

core memory map is given below.

Bytes 0 to 2044: The histogram bins, each 2 bytes but stored 4 bytes apart.

Byte 2048: The underflow events counter: A 2 byte counter of the number of peaks

detected that are below the minimum histogram value.

Byte 2052: The overflow event counter: A 2 byte counter of the number of peaks

detected that are above the maximum histogram value.

87

Byte 2056: The total events counter (LSB): A 2 byte counter of the least significant

bits of the 4 byte total events counter.

Byte 2060: The total events counter (MSB): A 2 byte counter of the most significant

bits of the 4 byte total events counter.

Byte 2064: Empty

Byte 2068: The preamp temperature in adu. This is a 12 bit value from the ADC

channel 5.

Byte 2072: The TEC temperature in adu. This is a 12 bit value from the ADC channel

6.

Byte 2076: The high voltage housekeeping in adu. This is a 12 bit value from the ADC

channel 7.

4.2.3 The SXM Core Logic

Functionally, the SXM core has three objectives, first to detect and read peaks in the outu1

signal, second to bin those peaks into a histogram, and finally to read the three relevant

housekeeping voltages. These three goals are implemented using a state machine. Figure 4-9

shows the different states and the general functionality of each.

The parameters that accompany each of the state machine’s states are given in the list

below. The machine is held in reset when the signal trigger reset is high. When in reset,

the machine is essentially off. ZLE is held high and the ADC is never read. When the

trigger reset signal is brought low, the state machine goes into either histogram mode or

housekeeping mode. If the state machine is in housekeeping mode, the ADC is read three

times. The first two reads are temperatures, the first is from the SEB and the second is from

the temperature diode on the SDD itself. After the reads are complete and the three data

points are recorded, the state machine waits to be commanded back into reset or histogram

mode. If in histogram mode, the default state is IDLE to wait for an event. The rising LLD

signals a peak is coming and triggers ZLE to be brought low. States Zp Hi and ZP Low

88

Figure 4-9: The Modes and states of the SXM core state machine

ensure that Zp has time to reset and state machine awaits the falling edge of Zp, signaling a

peak. On Zp’s falling edge the machine triggers a read of the ADC by bringing hold n low.

In state DONE the machine waits for the ADC to finish converging and reading the value

by monitoring trigger reset n. When the ADC is finished trigger reset n goes high and the

machine transitions back to state IDLE to wait for another high LLD.

1. State: RESET

ZLE: = 1

hold n = 1

trigger reset = 1

Action: If trigger reset is 0, go to state IDLE

2. State: IDLE

ZLE: = 1

hold n = 1

89

Action: If LLD is high, go to state Zp Hi

3. State: Zp Hi

ZLE: = 0

hold n = 1

Action: If ZP is high, go to state Zp Low

4. State: Zp Low

ZLE: = 0

hold n = 1

Action: If Zp is low, go to state SAMPLE

5. State: SAMPLE

ZLE: = 1

hold n = 0

Action: If trigger reset n is low, go to state DONE

6. State: DONE

ZLE: = 1

hold n = 1

Action: If trigger reset n is high, go to state IDLE

The transitions of the comparators are not instantaneous or perfectly clean. The compara-

tor’s propagation delay is 4.5 ns and the rise/fall time of the signal is an additional 2.3 ns, for

a total switching time of almost 7 ns. With the FM clock frequency of 100 MHz, the FPGA

logic will operate with a period of 10 ns. So if the comparator switched perfectly every time,

it could be treated as a synchronous signal with respect to the FPGA logic. However, if the

signals to be compared are noisy, the output can bounce or give a rough rising or falling

edge. Any bouncing or roughness in the output will delay the final stable comparator state,

possibly well beyond the 10 ns clock cycle period. Therefore, the LLD and Zp comparator

outputs must be treated as asynchronous signals with respect to the FPGA. The falling edge

of Zp (in pink) in Figure 4-10 shows some jitter around the mid-piont of the falling signal.

In the Figure it takes about 100 ns for Zp to settle out.

90

Figure 4-10: Jitter near the midpoint of the falling edge of Zp (in pink)

Figure 4-11: Jitter on the rising edge of LLD reaching all the way back to the midpoint ofthe comparator output

4.2.4 Tuning the SXM Core

To correct for jitter the Zp signal has a 3 clock cycle register associated with it. For Zp’s

falling edge to actually trigger the state machine to go to another state, Zp must register

low on three successive clock cycles (for 30 ns). This method of accounting for Zp adds

another 30 ns to the minimum read time for the ADC, but also helps avoid spurious reads

due to potential fluctuations in Zp from noise. LLD can also be a noisy signal as seen in the

rising edge of LLD in Figure 4-11. However, LLD has the potential to be much nosier than

Zp. VLLD will likely be kept very low for flight, very close to the value of Vb, in order to

reach signals with as low an energy as possible. When VLLD is close to Vb there is more

of a chance of noise causing LLD to go high. When a pulse does drive LLD high, there is

also more of a chance of LLD going back low due to noise. To correct for the poor behavior

91

of LLD, a counter is implemented in the FPGA code such that the state machine will not

use the LLD signal unless LLD has remained high for a specified number of clock cycles.

Currently that number is set to 20 cycles, which yields a delay of about 200 ns. Unlike Zp,

delays in LLD will not adversely affect the ADC read since the timing for that is all done

off Zp. If this counter is set too high, it could keep the state machine from reading lower

energy peaks in a similar way that VLLD keeps the noise out of the measurements. However,

with a 4 µs peaking time, the LLD pulse should be about 2 µs and a 200 ns delay is not a

problem. Figure 4-12 shows VLLD (in pink) set to a value slightly above Vb. As outb rises

past VLLD, LLD (in yellow) is triggered. The LLD pulse lasts for about 2 µs and then falls

as outb (in blue) passes VLLD.

Figure 4-12: A low VLLD triggers LLD on the rising side of outb. Outu is also shown forreference.

Since the ADC conversion doesn’t begin until several clock cycles after the peak of outu1,

and it takes some time for the ADC to get the value, there is a delay between the actual

peak and the measured value of outu1. Furthermore, since the pulse shape varies somewhat

with different input amplitudes and frequencies, the amount of error, even for a fixed time

delay, will differ with changing inputs. There are two ways to mitigate this problem. The

first is to keep the time delay as short as possible. The ADC’s maximum clock is 16 MHz

and it takes 3 clock cycles to acquire the signal, so the minimum possible time from falling

edge of Zp to signal acquisition is 192 ns. To this number must be added the time necessary

92

to register Zp falling and send CS low, which is a few clock cycles of the FPGA clock, which

are 10 ns each. After looking at the code and testing the triggering, the minimum time is

found to be about 220 ns.

The second method of reducing ADC read error is to decrease the slope of outu1 around

the peak. Obviously this is best accomplished by stretching out the whole shaped pulse.

The length of the pulse is given by the group delay of the shaping and amplification circuit

described above. Initial testing with a 1 µs group delay showed significant drop off in the

200 ns or so that the ADC took to read. Testing with a function generator, the ADC read

error was found to be between 100 mV and 500 mV for the three sample amplitudes tested. A

4 µs group delay was found to have much better results, dropping the error to less than 5 mV

for all tested input amplitudes and frequencies. Not only is the error less for each sample

input, the difference in error is not noticeable between different inputs. This is important as

it greatly simplifies the calibration that must be applied to the histogram data. Adjustments

to the group delay are made by changing the capacitance of 8 key capacitors in the shaping

and amplification circuit. Increasing capacitance will stretch out the pulse and decreasing it

would speed it up. The circuit is linear with respect to this capacitance, at least in the range

of values that produced group delays between 1 µs and 4 µs. Therefore to change from 1 µs

to 4 µs, the capacitance of those 8 key capacitors is simply multiplied by a factor of four.

See John Doty’s documentation for this circuit [48] to gain more insight into calculating and

adjusting the group delay.

4.3 SXM Software Design

The main responsibility of the SXM software is to interface with the SXM hardware module

on one hand, and the user interface functions such as processing commands and delivering

downlinked data, on the other hand. The FPGA core takes care of most of the heavy lifting

in terms of computations and data processing that the SXM requires. The bulk of the

SXM software functionality is housed in four main functions, sxm initialize, turn on sxm,

turn off sxm, and sxm process data. The initialization routine runs as REXIS is powering

on and initializing the software. It sets up pointers to the SXM FPGA core’s memory space

93

and control registers, and initializes the SXM core’s parameters to default settings. The

turn on function zeros out the software’s counters and internal variables as well as the SXM

core memory space. It then powers on ±5 V lines, sets up and enables the TEC, the HV

PWM signals, and the HV DAC, and enables the SXM FPGA core. The turn off function

does exactly the opposite, and in the reverse order. It disables the SXM state machine,

turns off the FPGA core, disables the HV, then the TEC, and powers off the ±5 V lines.

Note that the turn on function does not start the state machine and begin binning data;

that happens at the end of the sxm process data function. Therefore, no data will be taken

until the second integration period. During this time the SDD is not yet cooled, and science

telemetry is not turned on, so no data is lost in that first integration period.

After REXIS and the SXM are initialized and the instrument is running in Safe Mode, it

will eventually be commanded to go to Science Mode. At this point, the turn on sxm runs

and the SXM data flag is flipped by an interrupt every SXM update period (nominally 32 s).

Since the main loop takes longer than the ISR loop and is variable depending on what the

software is doing, it is important that the SXM update period is not dependent on the main

loop. The ISR loop will send the state machine form histogram mode to housekeeping mode

as soon as the update period timer expires, ensuring that the integration time is accurate

with respect to the desired period and consistent across packets. The data flag lets the

main SW loop know to run the sxm process data function the next time it runs through

its loop. The sxm process data function first waits for 15 µs in order to be sure that the

ADC has finished reading the HK values. Then the histogram is copied to a local variable

so what data processing is left can be carried out without delaying the next integration

period. The state machine is restarted and the data flag is set to zero, while the counters

and HK data are extracted and the event rate is calculated. Then the telemetry packet is

formed, if downlinking is enabled; otherwise, the function returns. Figure 4-13 describes the

functionality of the SXM software in Science Mode.

Several REXIS parameters are present within the software to fine tune the SXM func-

tionality. Three are updateable by command, and the others are hard-coded in the software

or FPGA code. The software updateable parameters and valid ranges are shown in Ta-

ble 4.2. SXM LLD and SXM ULD are the limits in ADU of the histogram. SXM Lower

94

Figure 4-13: A block diagram of the SXM data processing function

Level Discriminator (LLD) sets the lowest adu value which the SXM core will include in the

histogram. SXM Upper Level Discriminator (ULD) represents the highest adu value which

the SXM core will include in the histogram. The histogram will automatically scale the 512

bins evenly across the space bounded by LLD and ULD, meaning that histogram resolution

is not static. The SXM update period is the time, in seconds, for which the state machine

is active in histogram mode, per data packet.

Table 4.2: SXM Parameters updateable by command

Parameter Default Min Max Command to set Output PacketSXM LLD 0 (adu) 0 (adu) 4095 (adu) 2-byte Param Param SettingsSXM ULD 4095 (adu) 0 (adu) 4095 (adu) 2-byte Param Param Settings

SXM Update 32 (s) 1 (s) 4095 (s) 2-byte Param Housekeeping

Three telemetry packets display SXM data. The first is the SXM telemetry packet that

is downlinked every SXM update period. This packet contains the SXM update period,

95

counters for events above ULD, below LLD, and total events, as well as the full 512 bin

histogram. The structure of the SXM telemetry packet is shown in Table 4.3. The REXIS

housekeeping packet is generated on a separate housekeeping period. It downlinks vital

health and telemetry about the REXIS instrument. Included in the housekeeping packet are

two temperature measurements from the SXM. The SXM preamp temp is from a thermistor

on the SEB, and the SXM TEC temp is from the diode on the cold side of the TEC.

The former is isothermal with the SDD baseplate. The latter is isothermal with the SDD

detector itself. The housekeeping packet also includes the HV housekeeping signal which is

an ADC measurement of the HV line after passing through a voltage divider which brings it

into range for the ADC. The parameter setting packet displays the three updateable SXM

parameters, LLD, ULD, and update period. The commands to update parameters and the

request parameter settings command will only be processed in Safe Mode.

Table 4.3: SXM Telemetry Packet Fields and Byte Offsets

Protocol Field Byte Offset Byte Width DescriptionIP IP header 0 20 Header

UDP UDP header 20 8 HeaderCIP CIP header 28 8 HeaderIDP IDP header 36 24 HeaderIDP SXM Period 60 2 Histogram integration timeIDP Total Events 62 4 Total events counterIDP Underflow 66 2 Events below LLD counterIDP Overflow 68 2 Events above ULD counterIDP Bin 0 70 2 Events in Bin 0 counterIDP . . . . . . . . . . . .IDP Bin 511 1092 2 Events in Bin 511 counterIDP Padding 1094 2 Zero Padding

The TEC PWM frequency and duty cycle can be controlled by software. A closed loop

control could have been implemented to vary the PWM frequency and optimize the SDD

temperature. However, the REXIS team decided that an open loop control set point of

3.5 V across the TEC would meet requirements and reduce system complexity. Figure 4-4

shows that a voltage across the TEC of 3.5 V will meet the -30 Crequirement for all expect

interface temperatures with at least 10 Cof margin.

96

4.4 Interpreting the SXM Data

This section will briefly explore how to interpret the SXM telemetry based on EM testing

results and expected flight values. EM testing has focused on SDD response to 55Fe x-rays

and how the TEC responds to different thermal environments. There is no way to easily

simulate the solar x-ray spectrum for environmental level testing with the SXM, so testing

the SDD over an accurate solar spectrum is not feasible. Therefore calibration of the SXM

will really take place on orbit through careful data reduction. Good documentation of the

EM test results will be critical to correctly interpreting on-orbit data. Every time a histogram

is taken, the data will be affected by the temperature of the SDD, the incident x-ray flux,

the threshold VLLD level, and the hard coded signal registers and delays. The histogram

parameters will affect the output resolution as well. All of these factors must be documented

in order to correctly compare multiple histograms from different testing sessions.

Figure 4-14 shows a histogram from the EM SXM under exposure to 55Fe for 10 min.

The histogram core was set to bin data from the whole of the ADC range (LLD = 0 and

ULD = 4095). The ADC reads data from 0 to 3.3 V with a 16 bit resolution. That

gives an output range from 0 to 4095. Given a 512 bin histogram then, the bin width is

3300/512 = 6.45 mV/bin. Additionally, each bin is 4096/512 = 8adu wide. Therefore, in

the absence of any other factors, the histogram results in a factor of 8 resolution loss from

the ADC, if the histogram remains the full width of the ADC output. This is one of the

reasons that the minimum and maximum adu fo the histogram is scalable by command.

The lowest and highest triggers are the result of the SDD reset signal. The typical rest

signal after the MEB shaper and amplification circuitry is shown in Figure 4-15. The green

trace at the top of the Figure shows the outu1 signal that the ADC is sampling. The blue

trace in the middle shows the outb signal whose zero-crossing trigger the sample. The yellow

trace at the bottom shows the LLD comparator output and the red line shows the location of

the VLLD threshold with respect to outb. Notice that outb crosses the VLLD threshold level

twice during the reset, once when outu1 is low and a second time when outu1 is high. Notice

also that both result in clear LLD pulses and subsequent outb zero-crossings. Therefore this

reset results in two ADC reads. The low spikes in the histogram at around the 45th and

97

Figure 4-14: An EM Histogram showing 55Fe exposure for 10 min with a VLLD level of 130over the full range of the ADC

329th bins represent the low and high reads from the SDD reset signals. The 45th bin (given

the LLD and ULD parameters used for this data) is about 0.3 V, which is the level of the

outu1 bias voltage and the 329th bin is about 2.1 V, which is consistent with the top of

the outu1 spike seen in Figure 4-15. The low height of these spikes indicate that the reset

frequency is relatively low, and summing the counts in either of the reset spikes and dividing

by the integration time gives an indication of reset rate of the SDD.

The reset rate varies with temperature. A warm detector will have more dark current

buildup saturating the diode and causing more frequent resets. The reset rate in Hz is

plotted against SDD temperature from the EM SDD as it cools down in Figure 4-16. The

number of resets follow an exponential decay as the detector cools until it reaches about

1 Hz at temperatures less than -40 C. The high end of the figure shows a reset rate of about

1000 Hz. Following the trend line to room temperature yields a rate of 12 kHz. However,

the maximum reset rate is about 8000 Hz, at which point the 120 µs rest pulse is continuous

and there is no time in which the detector can actually gather x-rays.

The 55Fe isotope’s two most active emissions are at 5.89 keV and 6.49 keV. These account

98

Figure 4-15: An oscilloscope trace of an SDD reset showing, from top to bottom, the outu1,VLLD, outb, and LLD signals

for the two main spikes in the histogram. The ability to differentiate the two spikes clearly

shows that the resolution of the system is less than about 0.6 keV. The absence of Si escape

peaks is troubling. The spike at the left is at about 1.74 keV, which is the Si kα line. A

resolution will not be extracted from this histogram since it is limited by the bin resolution,

not the ADC resolution. However, more details on interpreting the SXM histogram and

its resolution are found in Appendix A. The 55Fe kα spike is at an ADC voltage of about

600 mV. Figure 4-17 shows the outu1 scope trace of an 55Fe kα decay in green. The peak

is at 600 mV as expected from the histogram. The red line superimposed over the blue line

shows the VLLD threshold level over the outb signal. The yellow trace shows the LLD signal.

Notice that the LLD signal goes high as the outb signal crosses the threshold, as expected.

Notice also that the outb signal does not exceed the threshold by more than about 100 mV.

This means that if VLLD were set 100 mV higher, the 55Fe spike would be missed by the

trigger circuitry. The outb signal due to a 55Fe decay is about 500 mV peak to peak, with a

positive side peak of 250 mV. This 250 mV range is the operative range of VLLD.

99

Figure 4-16: SDD reset rate plotted against the SDD temperature for warm temperatures.An exponential fit is also shown.

Figure 4-17: SXM signals outu1, VLLD, outb, and LLD during an 55Fe decay

100

Chapter 5

SXM Risk Management and

Conclusions

This chapter discusses the practical application of risk management to the REXIS SXM.

Challenges applying a balanced risk posture to the SXM are explored, as well as successful

aspects of the REXIS team’s approach to risk. Suggestions for future work in exploring the

application of a comprehensive and balanced risk posture to high-risk payload development

are also set forth. Finally, the chapter concludes with a summary of some of the main points

of this thesis.

5.1 REXIS Risk Classification and RM Approach

The REXIS instrument is a hosted payload on OSIRIS-REx, a NASA risk Class B mission.

In the OSIRIS-REx Program Level Requirements document, as well as the Mission Require-

ments Document (MRD), the REXIS instrument is specified as a “Class D payload per NPR

8705.4 Appendix B”. The OSIRIS-REx Mission Requirements Document also states that

the high-level requirement on REXIS is to do no harm to the spacecraft. The quote below

is from the OSIRIS-REx MRD Revision H [52]:

MRD-520: REXIS is a student instrument and is not required to achieve the

baseline science mission. Meeting Class D requirements ensures a REXIS failure

101

will not impact the spacecraft or other instruments.

The definition of the top level REXIS rqeuirement as to do no harm to the spacecraft

is inconsistent with the NPR 8705.4 definition of a Class D mission. Under the NPR,

Class D missions are required to meet minimum science requirements or performance goals.

However, there is no formal risk category for a Do No Harm (DNH) mission the agency level

requirements documentation. At the time the OSIRIS-REx MRD was baselined (2012) there

was no clear Goddard Space Flight Center interpretation of how to formally categorize such

a mission. In 2013, the Goddard In House Constitution for Class D Missions [53] took a

step towards formalizing a DNH risk category by mentioning a ‘Simplified Class D’ mission.

In an effort to rectify the discrepency between documentation and actual missions such

as REXIS, GSFC is planning to publish a call Goddard Procedural Requirements (GPR)

8705.4. This document will address the Center level implementation of NPR 8705.4 and

formalize high-risk categories beyond the NPR Class D definition. For more on GPR 8705.4

see Section 2.2.3. The confusion in nomenclature is important to mention here, since the

documentation is meant to help guide both the NASA engineers and the REXIS team in

executing the project. Conflicting documentation hinders clear communication of goals and

requirements and prevents a smooth implementation of RM.

The formal REXIS RM approach centers on maintaining a document that tracks all

identified risks. Each risk is defined with a risk statement that contains the risk scenario

and its effect on the system. Each risk is then assigned a consequence and likelihood between

0 and 5, with 0 being not likely and of low consequence, and 5 being highly likely and of high

consequence. The risks are then plotted on a risk matrix. The latest REXIS risk matrix is

given in Figure 5-1 and the risks plotted are listed in Table 5.1.

The risk matrix also helps to rank the relative severity of risks. The risks farther up and

to the right in the risk matrix are more important and should be mitigated before the risks

to lower left. The risk matrix is updated for the monthly instrument status review, and

changes to the risk matrix are tracked. Finally, each risk is assigned a mitigation plan and

status. A decision is made on what risk mitigations should be pursued, or if a risk should be

accepted. If a risk reaches 0 likelihood or 0 consequence the risk is considered closed and no

more mitigation is necessary. Though REXIS is not required to meet science performance

102

Figure 5-1: The current REIS risk matrix showing risk plotted on map of likelihood versusconsequences

goals, risks to the REXIS science mission are included in the REXIS risk matrix. Currently

there are three open risks regarding the SXM tracked by REXIS. Two of these risks are

technical risks stemming from possible radiation to the TEC or the SDD, REX 14 and REX

28. The third is a programmatic risk stemming from the possibility of a schedule slip that

impacts REXIS delivery, this no longer a significant and is not shown in the risk matrix.

The only formal RM required on REXIS by the project is to track risk in a document

and create the the risk matrix. In application, the REXIS team updates the table monthly

as required, but does not use it as the sole or even primary source of risk information and

decision making. Instead, given the small size of the REXIS team and the collaborative

nature of the SSL’s academic environment, REXIS RM in practice is based on discussions

and communication between the project members whenever risks are involved. Meetings at

which design decisions are made involve representation from all major aspects of the REXIS

design, structures, thermal, avionics, systems engineering, integration and test. Often the

entirety of the REXIS team is present for such discussions. The qualitative nature of the

REXIS team’s collaboration with respect to risk complements the qualitative nature of the

risk matrix based RM, but also ensures that communication is not lost in documentation.

The risk status of REXIS is not just updated every month in the risk matrix, but is a topic

of communication for the decisions that are made throughout the month.

103

Table 5.1: The current list of most significant REXIS risks

Risk ID Trend Risk Title

REX 39 ⇒ Lincoln Labs cannot accommodate nominal environ-mental testing schedule

REX 14 ⇒ SXM thermoelectric cooler fails

REX 28 ⇒ Radiation damage causes the SDD to exceed its spectralresolution requirement

REX 34 ⇑ Detector Electronics schedule slips and delays deliveryof REXIS to LM

REX 35 ⇑ MEB schedule slips and delays delivery of REXIS to LM

REX 41 ⇒ Loading from harnesses causes board mounted connec-tors to fail vibe

REX 4 ⇒ Radiation cover fails to open

REX 16 ⇒ REXIS detector electronics fails on orbit due to radia-tion damage

REX 6 ⇒ Flight CCD is broken during ground testing

REX 19 ⇒ Nonvolatile memory fails and the FPGA cannot be con-figured on startup

5.2 Lessons Learned Applying RM to the SXM

The SXM design provides several good examples for discussion of the lessons learned from

applying RM to the REXIS mission, or any high-risk, resource constrained payload develop-

ment. The SXM was not explicitly required in the initial proposal for REXIS. As the need

for local, real-time information on the solar x-ray spectrum became apparent, the SXM was

formally added to the REXIS design. As a later addition to the design, it is understood that

the SXM could be de-scoped from the instrument if necessary to preserve design resources

for the main spectrometer. In fact, that possibility was tracked as a risk in the REXIS

risk matrix. Eventually that particular risk was closed as a maturing REXIS design showed

enough margin in mass, power, and cost to allow for the SXM. Nevertheless, the SXM is in

some respects a higher-risk portion of the REXIS design than the spectrometer.

The following sections present three examples of RM application to the SXM design.

The first shows the risk reductions that can be reaped from using a COTS component and

leveraging design heritage. The second example shows the converse, and explains some of the

risks incurred on the SXM design due to COTS and re-use. The final example shows how lack

of information to properly characterize makes it difficult to apply a balanced RM approach.

104

The second two examples highlight some of the challenges faced in the application of RM to

a high-risk, resource constrained payload, and highlight the deficiencies of the current RM

approach.

5.2.1 The COTS SDD as a Risk Mitigation

The decision to use a COTS detector for the SXM significantly reduced the overall risk state

of the SXM design. The initial need to add the SXM was to address the technical risk of

not knowing the input flux at the asteroid. Howver, added the SXM, while reducing that

technical risk, added programmatic risk due to the design and schedule resources that the

SXM development requires. Discussion of a COTS SDD began very early in the design

process as a way to mitigate the programmatic risk to design resources and schedule. In

addition to using a COTS SDD, the SXM makes use of several aspects of the NICER design.

The combination of COTS and design heritage allows for less of the REXIS resources to be

diverted to the SXM than would be necessary if a custom solar monitor was designed. The

resource savings from COTS and heritage was an important consideration in determining

whether or not it would be feasible to add the SXM to REXIS in the first place.

The Amptek SDD is an example of how flying a COTS component can serve to reduce

risk as opposed to designing a custom part. Even though the Amptek SDD is COTS, and

has not flown in space before, Amptek detectors with similar designs have flown on several

missions, as mentioned in Section 3.2.3. This heritage reduces the risk associated with flying

a COTS part. In addition, though NICER is not flight heritage, the SXM design leverages

advantage from the parallel development of the NICER project. Not only was the NICER

design valuable for the SEB and Preamp Case hardware, but NICER also tested several of the

same Amptek SDD’s that the SXM uses, and let REXIS use the test data to help determine

if the Amptek SDD would meet requirements. This data further reduced technical risk

for the SDD and schedule risk due to testing. In addition, the Amptek detector is readily

available, with a short lead time of about 3 weeks. A custom detector would have much

more uncertainty in delivery date. Overall, the Amptek SDD is an excellent example of how

utilizing a COTS part can and similar design work from a concurrent project can reduce risk

and save design resources.

105

5.2.2 Unbalanced Risk in the SXM Avionics Design

The decision to use a COTS detector and leverage ongoing NICER design work created an

imbalance in the overall risk state of the SXM. To assume that a COTS component and

heritage or borrowed design work will be easily applicable to a new application incurs risk.

Even though the NICER and REXIS design both used the same detector, differences in

the application that were not immediately apparent added unforeseen sources of risk as the

designs developed. The NICER project switched to a faster CMOS detector from the XR-

100SDD in the Fall of 2013, which caused continued detector testing and preamplifier board

development to no longer be relevant to REXIS. The NICER switch lead to unexpected work

from the REXIS design team, in particular to bring the SEB to a flight ready state without

the benefit of continued NICER design work. The NICER project’s scientific goals differ

greatly from REXIS, and therefore the NICER support electronics for measuring the signals

also differ. While most of the SXM circuitry from the MEB was taken directly from an early

NICER design, much work was necessary to integrate this circuitry into the REXIS MEB.

More important than avionics hardware though, are the differences in software and FPGA

design. The triggering circuitry necessary to capture the peaks of the input SXM waveform

on the MEB was poorly understood at the beginning of the SXM design. At various points

there were plans to have the trigger implemented in software, in FGPA code, or in hardware

based latch logic. The final design is an FPGA based state machine in conjunction with

comparators, as described in Section 4.1.3 and Section 4.2.3. REXIS had to develop from

scratch the FGPA core to interact with and control the SXM circuitry as well as the software

to interface the FPGA core and SXM data with the REXIS FSW. The resources required,

especially for the FPGA core development, were not well understood at the outset of the

SXM design. Avionics development for the SXM became an unanticipated cost to REXIS

resources.

The addition of unanticipated resource requirements for SXM avionics development re-

sults in both programmatic and technical risk to REXIS. The additional avionics develop-

ment pushed the SXM schedule and added a schedule risk that the SXM will cause a delay

in delivery. This particular risk is tracked in the REXIS risk matrix as a 2 likelihood (10%

106

- 25% for programmatic risks) and 3 consequence (moderate impact to critical path).

The avionics design delay also translates to a technical risk. Delays in development can

either cause delays in delivery, or testing can be cut short in order to gain back schedule.

Testing is a very useful risk mitigation, and to cut short testing leaves a technical risk that

the SXM will not perform well enough to meet requirements. Some testing has already been

foregone. To date there has not been a full end-to-end test of the EM SXM system, in

conjunction with the MEB and utilizing REXIS FSW. All portions of the design have been

tested, but there has been no fully integrated end-to-end test. This test certainly could have

been carried out had the avionics design been completed earlier. There is an imbalance in

the overall risk state of the SXM. Some risks were mitigated by choosing the COTS detector;

however, other risks were incurred.

5.2.3 Unbalanced Risk in the SXM Structural Design

The structural and thermal design of the SXM is very robust and low-risk with respect

to the mechanical and thermal environment. Structural and thermal analyses of the SXM

assembly prior to EM testing showed positive margins. These predictions were borne out

in extensive EM testing. The EM SXM underwent thermal balance testing that exercised

the full range of potential thermal interface environments, with some margin added. This

testing was done without functioning avionics, but the TEC was powered on and tested over

its full expected range of voltages, with some margin added. (The thermal test results are

discussed in Section 3.4 as well as Stout [49].) Vibration testing was completed on the EM

SXM with the SDD and SEB present. Functional tests pre and post vibe confirmed that the

SXM was not damaged. There were very few updates necessary from the EM structure to

the FM structure. Many risk mitigation practices were followed with the structure that are

common to custom machined parts for space. These practices include locking features on all

fasteners, mil-spec coatings, and certificates of conformance for all materials.

While the structural and thermal design for the SXM is robust with respect to mechanical

loading and thermal environments, there is risk in the design with respect to the radiation

environment. Since structural blocking is one of the only mitigation options for radiation

when dealing with a COTS component, radiation risks are treated within the context of

107

the broader structural design. Two risks tracked in the REXIS risk matrix are related to

radiation damage of the SXM. The first is the risk that the SDD will be damaged due to

radiation and its spectral resolution will degrade below the requirement. The second risk

that the TEC will fail to cool the SDD below the required temperature. Both risks are

listed a 3 likelihood (15% - 25% for technical risks) and 4 consequence (major impact to

performance requirements, minimum success still achievable). A 3, 4 rating makes these

the second and third most significant risks on the REXIS instrument. A third risk that is

not tracked in the risk matrix is the risk of damage to the components on the SEB due to

radiation.

Unlike the avionics risks described above, the radiation risk to the SDD has been known

and tracked throughout the SXM design. However, the risk is difficult to characterize because

little is known about the radiation environment that the SDD will experience, and little is

known about how the SDD will react to a given radiation dose. While NICER was able to

test some XR-100SDD’s (see Section 3.4), the conservative estimate of the REXIS radiation

environment is over twice the dose that NICER applied. While NICER’s SDD experience

degradation, it is unclear how this maps to REXIS requirements of SDD resolution, even for

the same dose.

More knowledge of the SDD and environment is necessary to fully characterize this risk,

and therefore to mitigate it properly. Several updates to the SXM design were made with

the explicit intention of reducing the radiation dose that the SDD and components on the

SEB will experience. The external collimator extends over the MDM connector to reduce

line of sight to the SEB. A board mounted SMA connector was replaced with a bulkhead

mounted SMA connector in order to further reduce line of sight. A piece of metal on the SXM

preamp was extended below the MDM connector and the SDD was recessed slightly further

into the preamp case. However, the effect of these measures in reducing the risks to SXM

performance is unknown. Similarly unknown is if more effort spent on radiation hardening

the SXM would have been worth the personnel and design resources. For example, resources

could have been diverted from the structural or thermal design of the SXM to switch the

MDM to a bulkhead mounted connector. A bulkhead mount would close off the preamp

completely, in order to further reduce line of sight to the SEB. It is unclear if the time,

108

effort, and mass budget spent on making that change would have improved the risk posture

of the SXM.

5.2.4 SXM Risk Management Conclusions

The REXIS SXM exhibits imbalances in its risk posture. While some risk was mitigated by

choosing a COTS SDD and utilizing the NICER avionics design, other risks were incurred

that were not discovered until much later in the project. Similarly while some aspects of

the SXM structural design are very low-risk, the risks due to radiation damage of the SXM

electrical components are high. Both avionics and structures have examples of unbalanced

risks for the SXM, but each example stems from a different cause. The avionics risk imbalance

results form lack of knowledge of the risk implications of design decisions made early in the

project. The consequence is programmatic risk of schedule slip. There is also now technical

risk due to missed testing as mitigation for the schedule risk. In the structures example on

the other hand, the risk was known from the beginning, but it was not characterized well

and its consequences for high-level REXIS goals are not well understood. Because the risk

of radiation damage was not well characterized, there was little incentive to divert resources

to mitigate the risk. The lessons learned with respect to RM from the SXM include:

Using a COTS component can significantly reduce both technical and programmatic

risks by providing timely delivery of a well characterized and functional unit

Using a COTS component for space and re-using design work from heritage or a con-

current project incurs risk, usually in schedule, because unanticipated design work will

be necessary to integrate the borrowed components into the new application

Thorough characterization of risk, with respect to high-level performance goals is nec-

essary to be able to properly allocate design resources to ensure risks are mitigated

when needed

The second two examples in the previous section are presented to point out room for

improvements in the currently accepted methods of applying RM to a high-risk, resource

constrained payload. The purely qualitative approach to RM taken on missions such as

109

REXIS does not provide enough information to the REXIS team. Risks are assessed and

mitigated individually, and not necessarily with respect to impact on the high-level project

performance goals. There is no method of addressing the risk state of the system as a whole

in a meaningful way. The SXM avionics example emphasizes the importance of having a

method of evaluating the risk implications of design decisions with regard to both technical

and programmatic risks before those decisions are made. The structures example emphasizes

the importance of having a method to quantitatively address the risk state of a design and

the effects of possible risk mitigations. The final risk state of the SXM is left imbalanced

and with significant unknowns.

5.3 Future Work in High-risk, Highly Constrained RM

Future work is needed to further investigate the application of comprehensive and well bal-

anced RM to high-risk, resource constrained missions. This future work should focus on

a practical application of quantitative RM. Currently, high-risk missions do not implement

the most thorough NASA RM techniques in favor of a more qualitative and less robust ap-

proach. Full RM is foregone for mostly because it is too resource intensive for a constrained

mission to accomplish. However, quantitative RM can provide benefits to high-risk missions

in ways that current qualitative methods cannot. Specifically, current high-risk RM fails to

address the holistic risk state of a design, and does not evaluate design decisions in terms of

high-level performance goals. High-risk tolerance grants the project engineers a new design

currency, in the form of risk, that can be spent in different areas of the design as needed to

meet constraints. Resource constrained design teams are left with no guidance as to how and

where to spend their risk tolerance. Future work should focus on creating a RM framework

than can provide such support in a rigorous and quantitative manner.

To create such a framework in a way that is practicably usable to the engineer, without

encumbering documentation and procedural overhead, it should be based on viewing risk as

a design currency and utilize model based systems engineering (MBSE) techniques. MBSE

is a tool for developing and evaluating a system design. MBSE aids the engineer by holding

information about a system in a model centric instead of document centric framework. The

110

model allows better communication of the relationships between design elements, and the

effects of design decisions on the whole system. A study of the application of MBSE based

design to REXIS suggests that the application of MBSE to the REXIS instrument could have

saved valuable resources by giving REXIS access to information leading to a more mature

design earlier in the design process (see Chodas 2013 [54]). Risk as a currency has history

in the RM field at least as far back as the early 2000’s [55]. However, combined with MBSE

and modern RM it could now be used to form a framework that can be practically applied

to programmatic and design decisions on real missions.

By treating risk as a currency that can be spent, risk is applied to the system model in

the same way as cost. The cost is a model output, and the budget is a constraint. Risk

state is a model output and risk tolerance a constraint. The engineer is able to observe

the risk on each performance measure and spend risk in areas that need to be less risk

tolerant while accepting more risk in other areas. The engineer uses the risk available and

distributes it where needed, just like the other design resources. The currency of risk can

be quantified in terms of risk available to spend on individual risk scenarios, as well as

performance requirements for the overall system. Such a method then provides the engineer

with the ability to asses the risk implications of a design decision with respect to the whole

system. For the REXIS SXM at least, just such information is lacking from the current RM

approach.

5.4 Conclusion

This thesis discusses the design of the REgolith X-ray Imaging Spectrometer’s Solar X-ray

Monitor, as well as providing background and commentary on the application of risk manage-

ment to high-risk, resource constrained payload development. The first chapter introduces

the OSIRIS-REx mission, and the REXIS instrument as a high-risk student payload. The

second chapter provides background on risk and risk management (RM). The evolution of

RM at NASA is presented, as well as the current NASA approach to RM. The application

of RM to high-risk missions, especially in the context of NASA’s guiding documentation is

discussed. The third chapter presents the SXM design, beginning with its science goals and

111

driving requirements. The SXM subassembly is discussed including electrical and structural

design elements and the Amptek SDD. Test results are presented in relation to the REXIS

Level 3 and Level 4 requirements. Chapter four discusses the SXM support electronics on

the REXIS Main Electronics Board. The electrical hardware design is described as well as

FPGA and software designs. The chapter ends with some notes on interpreting the SXM

telemetry packet. The fifth chapter examines the REXIS risk posture and the application of

RM to the SXM design. The challenges encountered in creating a well balanced risk posture

for the SXM are discussed, and suggestions are made for future RM of high-risk, resource

constrained payloads.

112

Chapter 6

Bibliography

[1] Dante Lauretta. OSIRIS-REx Asteroid Sample-Return Mission. Handbook of Cosmic

Hazards and Planetary Defense, page 544, 2015.

[2] D. Lauretta and OSIRIS-REx Team. An Overview of the OSIRIS-REx Asteroid

Sample Return Mission. Lunar and Planetary Institute Science Conference Abstracts,

2012.

[3] D. S. Lauretta, M. J. Drake, R. P. Binzel, H. Campins, S. R. Chesley, B. E. Clark,

M. Delbo, J. P. Emery, C. A. Hergenrother, M. C. Nolan, D. J. Scheeres, , and

OSIRIS-REx Team. Asteroid (101955) 1999 RQ36: Optimum Target for and Asteroid

Sample Return Mission. 73rd Annual Meteoritical Society Meeting, 2010.

[4] NASA JPL. Near Earth Object Program: Earth Impact Risk Summary 101955 Bennu

(1999 RQ36), March 2014. URL: http://neo.jpl.nasa.gov/risk/a101955.html;

Accessed 14 March, 2015.

[5] K. Berry, B. Suttler, A. May, K. Williams, B. Barbee, M. Beckman, and B. Williams.

OSIRIS-REx Touch-And-Go (TAG) Mission Design and Analysis. 36th Annual AAS

Guidance and Control Conference, February 2013.

[6] Jonathan Gal-Edd and Allan Cheuvront. The OSIRIS-REx Asteroid Sample Return:

Mission Operations Design. 13th International Conference on Space Operations, May

2014.

113

[7] P. Smith, B. Rizk, E. Kinney-Spano, C. Fellows, C. d’Aubigny, and C. Merrill. The

OSIRIS-REx Camera Suite (OCAMS). 44th Lunar and Planetary Science Conference,

2013.

[8] A. A. Simon-Miller and D. C. Reuter. OSIRIS-REx OVIRS, A Scalable Visible to

Near-IR Spectrometer for Planetary Study. 44th Lunar and Planetary Science

Conference, 2013.

[9] V. Hamilton and P. Christensen. The OSIRIS-REx Thermal Emissions Spectrometer.

EGU General Assembly 2014, April 2014.

[10] C. S. Dickinson, M. Daly, O. Barnouin, E. Bierhaus, D. Gaudreau, J. Tripp,

M. Ilnicki, and A. Hildebrand. An Overview of the OSIRIS-REx Laser Altimeter -

OLA. 43rd Lunar and Planetary Science Conference, 2012.

[11] Michael Jones, Mark Chodas, Matthew J. Smith, and Rebecca A. Masterson.

Engineering design of the Regolith X-ray Imaging Spectrometer (REXIS) instrument:

an OSIRIS-REx student collaboration. In Space Telescopes and Instrumentation 2014:

Ultraviolet to Gamma Ray, volume 9144 of Proceedings of SPIE, pages

914453–914453–16, 2014.

[12] J. Goldsten, R. McNutt, R. Gold, S. Gary, E. Fiore, S. Schneider, J. Hayes,

J. Trombka, S. Floyd, W. Boynton, S. Bailey, J. Bruckner, S. Squyres, L. Evans,

P. Clark, and R. Starr. The X-ray/Gamma-ray Spectrometer on the Near Earth

Asteroid Rendezvous Mission. Space Science Reviews, 82:169–216, 1997.

[13] S. Barthelmy, L. Barbier, J. Cummings, E. Fenimore, N. Gehrels, D. Hullinger,

H. Krimm, C. Markwardt, D. Palmer, A. Parsons, G. Soto, M. Suzuki, T. Takahashi,

M. Tashiro, and J. Tueller. The Burst Alert Telescope (BAT) on the SWIFT Midex

Mission. Space Science Reviews, 120:143–164, 2005.

[14] B. Allen, J. Grindlay, J. Hong, R. Binzel, R. Masterson, N. Inamdar, M. Chodas,

M Smith, M. Bautz, S. Kissel, J. Villasenor, M. Oprescu, and N. Induni. The

REgolith X-Ray Imaging Spectrometer (REXIS) for OSIRIS-REx: Identifying

114

Regional Elemental Enrichment on Asteroids. In M. Kahan and M. Levine, editors,

Optical Modeling and Performance Predictions VI, volume 8840 of Proceedings of the

SPIE, pages M–1 – M–17, 2013.

[15] Delores Knipp. Understanding Space Weather and the Physics Behind It. Learning

Solutions. McGraw Hill, Boston, Massachusetts, 2011.

[16] Niraj K Inamdar, Richard P Binzel, Jae Sub Hong, Branden Allen, Jonathan Grindlay,

and Rebecca A Masterson. Modeling the expected performance of the REgolith X-ray

Imaging Spectrometer (REXIS). In SPIE Optical Engineering+ Applications, pages

922207–922207. International Society for Optics and Photonics, August 2014.

[17] H. Clark K. Ryu, B. Burke et al. Development of CCDs for REXIS on OSIRIS-REx.

Proc. SPIE Astronomical Telescopes and Instrumentation, June 2014.

[18] H. Bralower. Mechanical Design, Calibration, and Environmental Protection of the

REXIS DAM. Master’s thesis, Massachusetts Institute of Technology, September 2013.

[19] S. Kitamoto, T. Kohmura, N. Yamamoto, H. Saito, H. Takano, K. Suga, E. Ozawa,

K. Suzuki, R. Kato, Y. Tachibana, Y. Tsuji, K. Koganei, K. Hayashida, H. Katayama,

H. Enoguchi, Y. Nakashima, and T. Shiroshouji. Soft X-ray Transmission of Optical

Blocking Filters for the X-ray CCD Cameras on Astro-E2. volume A-505 of Nuclear

Instruments and Methods in Physics Research, 2003.

[20] F. Schmidt. Fault Tolerant Design Implementation on Radiation Hardened By Design

SRAM-Based FPGAs. Master’s thesis, Massachusetts Institute of Technology, May

2013.

[21] D.Carte, N.Inamdar, M. Jones, and R. Masterson. Design and Test of a Deployable

Radiation Cover for the REgolith X-ray imaging Spectrometer. In Proceedings of the

42nd Aerospace Mechanisms Symposium, 2014.

[22] Kaplan, Stanley, and B. John Garrick. On the quantitative definition of risk. Risk

Analysis, 1(1):11–27, 1981. URL:

http://dx.doi.org/10.1111/j.1539-6924.1981.tb01350.x.

115

[23] JPL Special Review Board. Report on the Loss of the Mars Polar Lander and Deep

Space 2 Missions. NASA JPL Public Release, March 2000.

[24] MCO Investigation Board. Mars Climate Orbiter Mishap Investigation Board Phase I

Report. NASA Public Release, November 1999.

[25] NASA Office of Inspector General. Faster Better Cheaper: Policy, Strategic Planning,

and Human Resource Alignment. NASA IG Audit Report, March 2001.

[26] Tony Spear and NASA FBC Task Force. NASA FBC Task Force Final Report. NASA

Public Release, March 2000.

[27] NASA Office of Safety and Mission Assurance. Risk Classification for NASA Payloads.

NASA Public Release.

http://nodis3.gsfc.nasa.gov/npg_img/N_PR_8000_004A_/N_PR_8000_004A_.pdf.

[28] M. Swartwout. Cheaper by the dozen: The avalanche of rideshares in the 21st century.

In Aerospace Conference, 2013 IEEE, pages 1–12, March 2013.

[29] Daniel Andrews. Lcross lunar impactor: Pioneering risk-tolerant exploration in a

search for water on the moon. International Planetary Probe Workshop 2010; 12-18

Jun. 2010; Barcelona; Spain, 2010. URL:

http://ntrs.nasa.gov/search.jsp?R=20100028141.

[30] Human Exploration and Operations Mission Directorate. DART Risk Management

Case Study. NASA Public Release.

[31] Yacov Y. Haimes. Risk Modeling, Assessment, and Management. John Wiley and

Sons, Inc., Hoboken, New Jersey, third edition, 2009.

[32] Office of Safety and Mission Assurance, NASA Headquarters. NASA Risk

Management Handbook, 2011. NASA/SP-2011-3422-Version-1.0, HQ-STI-11-205 URL:

http://ntrs.nasa.gov/.

[33] S.L. Cornford, M.S. Feather, and K.A. Hicks. Ddp: a tool for life-cycle risk

management. Aerospace and Electronic Systems Magazine, IEEE, 21(6), June 2006.

116

[34] Audrey Dorofee, Julie Walker, Christopher Alberts, Ronald Higuera, Richard Murphy,

and Ray Williams. Continuous Risk Management Guidebook. Software Engineering

Institute, Carnegie Mellon University, 1992.

[35] Larry J. Paxton. faster, better, and cheaper at nasa: Lessons learned in managing and

accepting risk. Acta Astronautica, 61(10), 2007.

[36] Office of Safety and Mission Assurance, NASA Headquarters. NASA Risk-Informed

Descision Making Handbook, April 2010. NASA/SP-2010-576-Version-1.0, URL:

http://ntrs.nasa.gov/.

[37] Code 300/Safety and Mission Assurance Directorate. Goddard Procedural

Requirement 7120.4: Risk Management. Pbulished by: NASA Goddard Spaceflight

Public Release.

[38] NASA Headquarters. Probabilistic Risk Assessment Procedures Guide for NASA

Managers and Practitioners, December 2011. NASA/SP-2011-3421 Second Edition,

URL: http://ntrs.nasa.gov/.

[39] Office of the Chief Engineer, NASA Headquarters. NASA Engineering and

Program/Project Management Policy. NASA Public Release.

http://www.hq.nasa.gov/office/codeq/doctree/71204.htm.

[40] Office of the Chief Engineer, NASA Headquarters. NASA Space Flight Program and

Project Management Requirements, October 2014. NASA 7120.5, URL:

http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7120_005E_/N_PR_7120_005E_.pdf.

[41] Office of the Chief Engineer, NASA Headquarters. NASA Systems Engineering

Process and Requirements, April 2013. NPR 7123.1, URL:

http://nodis3.gsfc.nasa.gov/npg_img/N_PR_7123_001B_/N_PR_7123_001B_.pdf.

[42] Office of the Chief Engineer, NASA Headquarters. NASA Systems Engineering

Handbook, December 2007. NASA/SP-2007-6105, URL: http://ntrs.nasa.gov/.

117

[43] K P Dere, E Landi, H E Mason, B C Monsignori Fossi, and P R Young. Chianti - an

atomic database for emission lines. A and A Supplement series, 125:149–173, October

1997. CHIANTI is a collaborative project involving George Mason University, the

University of Michigan (USA) and the University of Cambridge (UK).

[44] K P Dere, E Landi, H E Mason, G Del Zanna, and P R Young. Chianti—an atomic

database for emission lines. xiii. soft x-ray improvements and other changes. The

Astrophysical Journal, 763, February 2013.

[45] Rajmal Jain, Hemant Dave, A.B. Shah, N.M. Vadher, VishalM. Shah, G.P. Ubale,

K.S.B. Manian, ChiragM. Solanki, K.J. Shah, Sumit Kumar, S.L. Kayasth, V.D.

Patel, JayshreeJ. Trivedi, and M.R. Deshpande. Solar x-ray spectrometer (soxs)

mission on board gsat2 indian spacecraft: The low-energy payload. Solar Physics,

227(1):89–122, 2005. URL: http://dx.doi.org/10.1007/s11207-005-1712-3.

[46] J. Sylwester, S. Kuzin, Yu.D. Kotov, F. Farnik, and F. Reale. Sphinx: A fast solar

photometer in x-rays. Journal of Astrophysics and Astronomy, 29(1-2):339–343, 2008.

URL: http://dx.doi.org/10.1007/s12036-008-0044-8.

[47] Keith C Gendreau, Zaven Arzoumanian, and Takashi Okajima. The Neutron star

Interior Composition ExploreR (NICER): an Explorer mission of opportunity for soft

x-ray timing spectroscopy. Proc. SPIE 8443, Space Telescopes and Instrumentation

2012: Ultraviolet to Gamma Ray, September 2012.

[48] John Doty. NICER MPU Hardware Manual. Internal Project Documentation; contact

Becky Masterson (becki@mit.edu) or Rick Foster (rickf@mit.edu) for more details.,

May 2013.

[49] K. Stout and R. Masterson. Thermal Design and Performance of the REgolith X-ray

Imaging Spectrometer (REXIS) Instrument. Proc. SPIE Astronomical Telescopes and

Instrumentation, June 2014.

118

[50] Gregory Progozhin. Proton Irradiation of SDD’s. Internal Project Documentation for

NICER, August 2014. Contact Rick Foster (rickf@mit.edu) for more details., Aug

2014.

[51] Amptek. Manual for the Silicon Drift Detector (SDD) Element, 2013. URL:

http://www.amptek.com/drift.html; Accessed 5 May, 2014.

[52] OSRIS-REx Project. Mission Requirements Document OSIRIS-REx-RQMT-0001

Revision H. NASA GSFC Project Documentation, February 2015.

[53] NASA Goddard Space Flight Center. Constitution for In-House NASA Goddard Space

Flight Center Class D Projects, Revision A, March 2013.

[54] Mark Chodas. Improving the Design Process of the REgolith X-Ray Imaging

Spectrometer with Model-Based Systems Engineering. Master’s thesis, Massachusetts

Institute of Technology, May 2013.

[55] S.L. Cornford, J. Dunphy, and M.S. Feather. Optimizing the design of end-to-end

spacecraft systems using risk as a currency. In Aerospace Conference Proceedings,

2002. IEEE, volume 7, 2002.

[56] Alan Huber. Personal Communication. Email exchange with Amptek President Alan

Huber on 18 July, 2014. Contact Michael Jones (michaeljns89@gmail.com) for more

details., July 2014.

119

120

Appendix A

SXM Users Guide

A.1 Nominal Operations

This section will describe nominal SXM operations through the REXIS flight software

(FSW). On orbit and in ATLO, REXIS ops will be conducted through the flight software

only, abstracting away some information which may be important to proper operation of

the instrument, especially in an off-nominal situation. This section will attempt to explain

the nominal operations of the SXM while noting relevant information that may not be ob-

vious from knowledge of just the FSW commands. Such information should prove useful in

understanding how to properly and confidently operate the SXM. This section focuses on

operations. For engineering design details see Chapter 3.

A.1.1 SXM Initialization

When REXIS is powered on, it comes up in a safe mode. In this mode, the SXM memory

space and control registers are initialized, but no power is applied to the SXM ±5 V, TEC

or HV lines, and the state machine remains in a safe reset state. Without power to the

SXM, there are no input pulses to the ADC. Even if noise in the system did cause a voltage

spike, the FPGA will never trigger the ADC to read in this state. The first SXM commands,

before the command is given to go to science mode, should be to initialize the SXM histogram

lower level discriminator and upper level discriminator (SXM ULD, SXM LLD), as well as

121

the SXM update period. These three parameters can all be set via the 2-byte parameter

update command, which is only accepted in safe mode. The LLD and ULD parameters

are set in adu from 0 to 4095. Any ADC values recorded below LLD or above ULD will

not be binned. Therefore the LLD and ULD values effectively scale the 512 bin histogram

to any desired portion of the ADC output. The current values of ULD and LLD can be

requested via the parameter settings command, and the SXM update period can be viewed

in the Housekeeping packet. Table A.1 shows the default, min and max values for the SXM

parameters.

Table A.1: SXM Parameters update-able by command

Parameter Default Min Max Command to set Output PacketSXM LLD 0 (adu) 0 (adu) 4095 (adu) 2-byte Param Param SettingsSXM ULD 4095 (adu) 0 (adu) 4095 (adu) 2-byte Param Param Settings

SXM Update 32 (s) 1 (s) 4095 (s) 2-byte Param Housekeeping

A typical power on sequence for the SXM may look like:

1. Power on REXIS

2. Observe SXM initialization success in boot up event messages

3. Observe SXM update period in HK packet

4. Set 2-byte Parameter Update to update SXM period to desired number, in seconds

5. Observe new period in next HK packet

6. Request Parameter Setting packet, observe default SXM LLD and SXM ULD

7. Send 2-byte Parameter Updates commands to set new SXM LLD and SXM ULD

values, in adu

8. Request Parameter Setting packet, observe new SXM LLD and SXM ULD

A.1.2 Going into Science Mode

When REXIS is sent the command to ’Go to Science Mode’, the SXM is automatically

turned on and begins taking data. The histogram and counter memory space is zeroed out.

122

Power is applied to the ±5 V lines, as well as the +TEC line to cool the SDD, and the

negative high voltage (HV) line switched on to bias the detector. The SXM state machine

in the FPGA is brought out of reset and begins looking for peaks in the SXM output signal

to bin in the histogram. Because the HV line is turned on when the SDD is still relatively

warm, there is initially a lot of noise in the detector output. A warm detector does not give

usable data, and dark current inherent to the warm detector causes the SDD to reset more

frequently. The SDD is in reset almost continually at first, and less frequently as the SDD

cools until the reset signal frequency reaches about 1 Hz. Each reset takes approximately

120 µs to complete during which time the detector does not give usable data. The increased

current draw on the HV line at higher temperatures may also cause sagging in the HV line

while the detector is cooling. The SDD will take a couple of minutes to cool down depending

on the interface temperature (about 100 sec from 25 Cto -30 C). However, while the SDD

is cooling REXIS is gathering and calculating a bias map. Bias map generation takes 10

frames at 4 s/frame plus about 3 min to calculate the median of each pixel. After bias map

generation is complete the command to turn on telemetry must be processed before any SXM

telemetry is down linked. After bias map generation is complete and telemetry is turned

on about 4 minutes will have passed and the SDD should be sufficiently cooled to provide

usable data. The requirement on resolution for the SXM translates to a SDD temperature

requirement of < −30 C, which at a room temperature interface and with a 2.5 V TEC

power line takes about 2 min. Note that none of the SXM histograms taken during bias map

generation are available to the user.

The transition to Science Mode and downlinking of data nominally follows the following

outline:

1. Send Command Go to Science Mode

DE power turned on, which turns on ±5 V lines

TEC PWM setup and enabled, +TEC line turned on

HV PWM setup and enabled, -HV line turned on

SXM histogram and counters cleared

123

SXM data flag set every SXM update period

2. Bias Map generation begins (takes about 3 minutes)

SDD begins to cool, takes about 3 minutes

After the first SXM update period, the SXM data flag is serviced for the first time

and the SXM On command sent to FPGA core, enabling the state machine

3. SXM data is processed every SXM update period

(a) The sate machine is held in reset and no new data is binned

(b) The histogram and counters are copied to a buffer

(c) The histogram and counter memory space is zeroed out

(d) The sate machine is enabled and the new histogram is begun

(e) The counters are extracted from the buffer and the event rate is calculated

4. After bias mapping is complete, send command Telemetry On

The counters, event rate, and histogram are packaged into the SXM data packet

and downlinked

The SXM telemetry packet begins to be downlinked after REXIS accepts the Telemetry

On command in science mode. One SXM packet is generated and downlinked every SXM

update period. The REXIS Command and Telemetry Handbook goes through the packet in

detail, but Table A.2 also shows the structure of the packet.

A.1.3 Powering Down the SXM

When the REXIS instrument is done taking data it transitions back into Safe Mode. The

steps to go to safe mode are essentially the reverse of the steps used to go to Science Mode.

The FPGA core state machine is put into reset, and no new data is binned. The HV line is

powered off and the HV PWM disabled, then the +TEC line is powered off and the TEC

PWM disabled. Then the ±5 V lines are powered off. When the TEC is powered off the

124

Table A.2: SXM Telemetry Packet Fields and Byte Offsets

Protocol Field Byte Offset Byte Width DescriptionIP IP header 0 20 Header

UDP UDP header 20 8 HeaderCIP CIP header 28 8 HeaderIDP IDP header 36 24 HeaderIDP SXM Period 60 2 Histogram integration timeIDP Total Events 62 4 Total events counterIDP Underflow 66 2 Events below LLD counterIDP Overflow 68 2 Events above ULD counterIDP Bin 0 70 2 Events in Bin 0 counterIDP . . . . . . . . . . . .IDP Bin 511 1092 2 Events in Bin 511 counterIDP Padding 1094 2 Zero Padding

SDD will begin to warm up. The order of power on and off is important. Specifically, the

±5 V lines should be on before the HV line and off after the HV line. A REXIS soft reset will

cause the software to be reloaded while the FPGA core is not reset, meaning that the state

machine could be running (as if in Science Mode) while the software initializes to Safe Mode.

To account for this, when REXIS is initialized, it includes a call to set the SXM On signal to

the FPGA to 0, sending the state machine into reset. In addition, SXM update period and

the histogram minimum and maximum values will be reset to defaults. Parameter adjust

commands will have to be used to change them back to previous values before going back

into Science Mode. If both the FPGA and the software reinitialize, then the SXM core will

come up in reset and be initialized as from a normal power up.

A.2 Getting the right histogram: Choosing LLD and

ULD

It is important to set the hist min and max values properly to get the correct histogram.

The MEB utilizes a 12 bit ADC, giving it a range of 0 to 4095 to represent it’s input range

of 0 to + 3.3 V. This gives 0.81 mV/adu. A 4096 bin histogram could represent this exactly,

but the data budget limits the SXM to a 512 bin histogram. If that histogram includes the

entire range of the ADC, then the resolution of the ADC degraded by a factor of 8; each

125

histogram bin represent 8 possible adu values. However, the SDD’s output range is not from

0 to 3.3 V, so the whole range of the ADC is not needed, and the histogram can be effectively

zoomed in on a specific region of the ADC output to get back this resolution without loosing

any important information. The energy range of interest to the SXM is 0.6 to 6 keV. A

signal of 0.6 keV gives an ADC reading of about 0.34 V (417 adu). An input of 6 keV gives

an ADC input of about 0.66 V (824 adu). Therefore default histogram minimum value is set

to to 400 and the default histogram maximum is set to 900, to cover the range of interest,

with some margin. (The default high value also captures the kβ peak of 55Fe which is useful

for ground testing.) This default range results in a resolution of 0.97 adu/bin ensuring that

no resolution is lost in the binning process. The conversion from bin to adu for a 512 bin

histogram is given by Equation A.1 where LLD and ULD are the histogram bounds in adu

(set by the software) and X is a bin number from the output histogram. The conversion from

adu to eV is more difficult, and will require detailed calibration of the actual unit sent to

flight. From EM testing thus far, it appears the conversion factor will be around 14 eV/adu,

assuming a linear detector response over the spectrum of interest. Sometimes it may be

useful to observe other areas of the ADC output, including the SDD resets. The SDD signal

that is connected to the ADC (outu1 ) is biased to 0.33 V. So anything from 0 to 0.33 V (0

adu to 400 adu) will not show any actual events. The SDD reset signal signal causes both

high and low triggers. It may be useful to expand the histogram to view these triggers to

get a better idea of how many resets are taking place. Figure A-1 shows a histogram of just

SDD resets expanded over the whole ADC output. Figure A-2 shows a histogram of the EM

SXM under 55Fe exposure for 1 min with a VLLD level of 1.3 V and histogram bounds of

475 and 1000 adu.

Y(adu) = (ULD − LLD)/512×X ± (ULD − LLD)/1024 (A.1)

126

Figure A-1: A histogram showing just SDD resets and no events.

A.3 Getting the right histogram: Choosing the Up-

date Period

Several factors are involved in choosing the SXM Update period. First, to ensure that the

histogram remain in sync with the CCD data, the SXM update period should be an integer

multiple of the CCD integration period, which is 4 sec. Each bin is represented by a 16 bit

word, so the maximum value that any bin can contain is 65,536. High solar activity or a long

integration time could cause an overflow. At the time of this writing there is no overflow

protection in the software. If a bin overflows the counter will roll over to 0 and begin again.

If multiple bins overflow the data becomes obscured and it is difficult to identify features in

the spectrum. The only way to cope with significant overflow is to shorten the integration

time such that no more bins will overflow. However, this requires sending a command, and

therefore is may not be responsive enough to catch quickly changing solar states. The SXM

collimator decrease the effective area of the SDD in an effort to decrease count rates, but

only estimates of the probable count rates are available at this time. It is likely that the

optimal SXM update period will be determined after on-orbit calibrations have taken place,

and real data about the SDD count rate in both a quiescent and an active sun has been

obtained.

127

Figure A-2: A histogram showing 55Fe exposure with peaks at 1.74 keV, 5.89 keV, and6.49 keV.

A.4 Hard Coded Parameter Adjustments

While three SXM parameters are update-able by command (SXM update period, LLD, and

ULD) there are several other parameters within the code that have been hard coded. These

may be changed by changing the code at any until delivery to ATLO, and potentially between

ATLO and launch should a need arise.

The VLLD signal is a DAC signal which sets the point at which a rising outb (the input

signal’s second derivative) primes the state machine to trigger on a peak. By increasing the

VLLD set point, low energy peaks and noise can be eliminated. Figure 4-8 shows VLLD in

the context of the SXM state machine trigger. On the EM MEB, VLLD is the output of an 8

bit DAC with a 2.5 V reference. On the FM MEB, VLLD is the output of a 12 bit DAC with

a 3.3 V reference, giving finer control of the VLLD set point. Since outb is biased to 1.21

volts, a VLLD of around 1.21 will cause triggers due to small noise variations in the input

signal. In addition, since the comparator which compares outb and its reference will alway be

128

primed to look for a peak, it’s output (LLD) will end up switching at a very high frequency.

This can cause noise which can propagate through other parts of the system. Therefore, the

software always initializes VLLD before enabling the state machine. EM testing found that

a VLLD of 1.4 or higher eliminated most triggers due to noise in the output and provided

a clean LLD pulse when tested with the function generator. Most EM testing was done

with a VLLD of 1.42 V. To change VLLD in the software, change the #define definition of

SXM THRESHOLD DEFAULT found in sxm.h.

The TEC power is determined by a PWM signal generated by a DAC. The duty cycle of

the PWM determines how much “DC” voltage the TEC experiences, and therefore the power

draw. Since the impedance of the TEC changes somewhat with temperature it is hard to say

exactly what the TEC power draw is given just the PWM signal. However, the large amount

of EM testing provides ample data for determining TEC response given a large range of inter-

face temperatures and voltages. The default TEC PWM is set to a frequency of 200 kHz and

a duty cycle of 20 %. This gives a voltage of 3.5 V across the TEC when the SXM interface is

at about 25 C. To change the TEC PWM frequency or duty cycle, change the #define def-

initions for SXM TEC PWM FREQ DEFAULT and SXM TEC PWM DUTY DEFAULT

found in sxm.h. The HV signal is generated by a Cockroft-Walton high voltage generator

fed by a PWM signal from a 12 bit DAC. The -HV line is set by default to give a voltage

out of -110 V. However, the detector may be biased anywhere from -100 to -200 V. All the

REXIS EM and ETU testing was done with a bias voltage of -110 to -120 V. The DAC is a To

change the HV PWM, change the #define definitions for SXM HV PWM FREQ DEFAULT

and SXM HV PWM DUTY DEFAULT found in sxm.h. The DACs for both the HV and

TEC PWM signals on the FM MEB are 12 bit, rail to rail output DACs with a 3.3 V

reference voltage.

There are also a few parameters hard coded into the FPGA core that may need to be

changed in the future. The state machine which looks for triggers is the most likely aspect of

the SXM core to require a change. The state machine has several values which are tunable

to provide better functionality. First, in order to avoid spurious state transitions due to a

bouncing comparator output, Zp is registered for three clock cycles before the state machine

will act on it’s falling edge. Similarly a counter on LLD places a delay between the rising

129

edge of LLD and the corresponding state transition in order to avoid triggers due to noise

when VLLD is set too low. This counter is set at 24 clock cycles this corresponds to 200 ns

on the EM MEB (clock at 125 MHz) and 240 ns on the FM MEB. Adjusting these counters

higher will decrease bad trigger due to noise, but adjusting them lower could allow for better

reading of low energy events. Both of these values are set in the state machine code at the

end of user logic.v. Additionally, the number of bins int the histograms as well as the size

of each bin is set in the file user logic.v. However, in order to change these values, changes

must also be made in the histogram.vhd and bram.vhd files.

A.5 The SXM Test Program

A Matlab based GUI was developed to assist in ETU an EM testing of the SXM. The GUI

gives greater control of the SW parameters that affect the SXM, allowing for easy testing

without having to recompile the full FSW project every time a change is made. Figure A-3

shows a screen shot of the GUI. This section will explain how to use this tool to test the

SXM. This GUI is set up to run in conjunction with the SXM Test software project and the

MEB HW configuration. The Matlab GUI will communicate with the SXM Test program

over either the Side A or Side B UART using the serial connection setting specified in the

BSP. Outputs from the MEB will be displayed in the Matlab command window. SXM Test

is program that waits to see characters sent over the serial port and then has a switch/case

statement to do a different task based on what character is sees. For example, a ’+’ character

causes the software to ask the FPGA core to increment the VLLD DAC value by one. The

following list shows how to nominally start up the test program and take a histogram.

1. Power on MEB, program with appropriate bitstream

2. Launch SXM Test project on the board

3. Run SXM ETU Control GUI from Matlab

4. Setup Serial Connection

Click Clear Serial Ports

130

Click Select Serial Port

Select the appropriate COM port from the list

Click Flush Serial Buffer until no more bytes are available

5. Turn on the SXM

Click DE On to power on the -5 V power line

Set the TEC PWM frequency and duty cycle and click update

Click TEC PWM Enable to turn on the +TEC power line

Set the HV PWM frequency and duty cycle and click update

Set the HV PWM DAC level (for the EM about 220 yields -110 V) and click Send

HV Level

Click Send HV Enable to turn on the HV power line

6. Take Histogram

Set Threshold to desired value and hit return

Set duration to desired value in seconds and hit return

Click Run to enable the state machine for Duration and plot a histogram

Type in file name and location and click Save Hist to save data

7. Power Off SXM

Click Disable HV to turn on HV line

Click TEC PWM Disable to turn off TEC power line

Click DE Off to turn on -5 V power line

Click Clear Serial Port to disconnect from the serial port

Click the red box on Xilinx SDK to stop the program on the board

Power off the MEB

131

The DE power on and DE power off buttons will toggle the -5 V line on the EM. on the

FM board they will toggle both the -5 V line and the +5 V line. If the serial port gets out

of sync first attempt to flush the buffer and see if that fixes the problem. Otherwise the

program will likely have to be stopped and restarted. The Thresh ++ and Thresh – buttons

simply increment or decrement the current threshold value. A histogram can be taken more

manually by clicking on the Trig reset 0 button to enable the trigger and the Trig reset 1

button to hold the state machine in reset. Then Get Hist and Plot can be used to download

the histogram and clear hist can be used to zero out the histogram memory space. The Trig

Enable and Trig Disable commands have been deprecated and do not do anything.

Figure A-3: A Matlab based GUI for testing the SXM

A.6 Debugging Issues

There are a couple of known issues with the SXM. First, the REXIS fault evaluation will

interrupt the SXM Update Period and the integration time of an interrupted period will be

shorter than the set integration time. This will likely happen once every Fault Eval period.

132

The affected SXM telemetry packets can be backed out on the ground in post processing

and adjusted for.

Overflow of the histogram bins has the potential to be a big issue on flight, and care

must be taken in choosing the right SXM Update Period. The ideal period will get enough

counts in a quiescent sun to provide a proper spectrum, but also have the dynamic range to

not overflow in a relatively high solar state.

Faults on the ground related to the SDD temperature will likely be caused by one of two

issues. First, if a problem is seen getting the SDD down to temperature (or if there are an

usually high number of resets) at ambient temperature, it is probable that there is a leak in

the SDD can. The SDD is meant to be evacuated to facilitate better cooling of the SDD.

If this is the case, it is possible that the SDD will perform better in environmental testing

and on orbit where the ambient pressure is a high vacuum. The other reason could be a

problem with the TEC circuity, or that the TEC itself is drawing too much current. If the

number of resets is too high but the SDD temperature is not a problem, then there may be

problem with the HV bias line. Try changing the parameters of the HV DAC to see if it

helps. Otherwise, the detector itself is likely at fault.

It is important never to short together pins 2 and 3 on the SDD itself. Pin 2 is the

diode anode and pin 3 is the +TEC voltage. Even a very small amount of current flow

between these two pins could cause the SDD to break. There are three wire bonds which

can easily break if the SDD is mishandled. Two connect the diode anode to pin 2 and one

connects the diode cathode to pin 6. The cathode connection can be checked by measuring

the resistance between pins 6 (cathode, substrate ground) 7 (JFET drain). The resistance

should be 100-200 Ω. The diode itself can be tested on pins 6 and 12 (HV bias), which

should give a forward voltage reading of about 0.5 V [56].

133

134

Appendix B

SXM Assembly Procedure

B.1 Notes About the Assembly

The assembly should be documented with a printed copy of the procedure. Date and per-

sonnel involved should be noted. Before the assembly begins, read the entire procedure

thoroughly. Read all sub-bullets for a particular step before performing step to ensure the

entire step is understood. Each step with fasteners indicate the type of locking mechanism

necessary. Note the steps that call for Arathane, as that will have to be prepared separately,

and has a limited working time before it sets. Torque values are listed above running torque

unless otherwise noted.

B.2 Required Materials

The following lists of materials will be used in the SXM assembly:

SXM Structure:

(1x) SXM Preamp Case, REX-SXM-021

(1x) SXM Bracket, REX-SXM-010

(1x) SXM Collimator, REX-SXM-022

135

(1x) SXM Electronics Board, REX-SXM-102

(1x) SXM SMA Connector, ACX1850-ND

(1x) SXM MDM Connector, M83513/13-A02NP

(1x) SXM SDD, Amptek XR-100 SDD

(1x) CHO-THEM 1671 sheet (at least 3x 5to work with)

(3x) 26 AWG silver-plated copper wire (about 1/4ea.)

(1x) Flight quality MDM 9 pin connector saver and jack-screws

(1x) Flight quality SMA connector saver

Fasteners:

(1x) 4-40 through-hole female threaded, 11/32length, 3/16hex standoff

(3x) SCREW, SOCKET HEAD, 2-56 X 3/8

(4x) SCREW, SOCKET HEAD, 4-40 X 1/4

(1x) SCREW, PAN HEAD, 4-40 X 1/4, Phillips

(2x) SCREW, SOCKET HEAD, 6-32 X 5/8(NAS1352N06-10)

(2x) SCREW, SOCKET HEAD, 6-32 X 3/4(NAS1352N06-12)

(2x) SCREW, SOCKET HEAD, 2-56 X 5/16, silver plated (NAS1352N02-5s)

(2x) SCREW, SOCKET HEAD, 2-56 X 1/2(NAS1352N02-8)

(2x) Nut, Self Locking, Hexagon-Low height, Light weight,

2-56 Thread (NAS1291C02)

136

Tools, GSE, EGSE:

(1x) ETU SXM Test setup (3 channel PS, HV PS, O-scope, ETU test harness,

multimeter, small bread board)

(1x) Calibrated Torque “dial” wrench (used for measuring running torque)

(1x) Calibrated “Set value” torque wrench (use for final torque installation)

(1x) Phillips and hex bits for torque wrenches

(1x) steel pin (0.063diameter) to punch holes in CHO-THERM

(1x) Number 35 drill bit

(1x) ETU Amptek SDD for fit check

(1x) Calibrated soldering iron

(1x) Wire strippers / wire cutter tool

(1x) Spool of eutectic solder (63/37 Sn/Pb) with RMA flux core

(1x) X-Acto knife

(1x) Clean Isopropanol

(several) clean, lint free wipes

B.3 Assembly Steps

1. Preparing the CHO-THERM:

(a) The CHO-THERM should be prepared before the rest of the assembly begins.

(b) Place a large piece of CHO-THERM over the preamp case. The preamp case will

serve as a die from which the CHO-THERM can be cut. Ideally this will be done

before the Preamp case is cleaned so that particulates generated by the cutting

process will not contaminate the piece.

137

(c) Use an X-Acto knife to cut out a circle the same diameter as the counter-bore.

(d) Use the steel pin to punch out the 12 small hole pattern.

(e) Use a no. 35 drill bit to punch through the center hole

(f) Clean the CHO-THERM with a nitrogen air gun and then wipe with clean wipe

wetted with isopropanol. Let it air dry and bag until the rest of the FM assembly

begins.

(g) Two pieces of CHO-THERM will be required for the two flight assemblies. At

least three pieces should be made so that a spare is available.

2. Attach the SXM Electronics Board (REX-SXM-102) to the SXM Preamp Case

(REX-SXM-021) with four 4-40 X 1/4socket head cap screws.

(a) The locking features are helicoils in the threaded holes of REX-SXM-021

(b) Torque to 62 in-oz above running torque.

(c) Best approach is to fit ETU Amptek SDD into preamp case and secure with hex

standoff before placing board in case to ensure that the board is in proper position

before tightening screws. Torque in a star pattern with the ETU SDD in place.

(d) 2.4. Orient preamp so that MDM and SMA footprint face as shown in Figure B-1.

3. Attach the SMA connector to the Preamp case using two 2-56 X 5/16, silver

plated, socket head cap screws.

(a) 5/16screws may not be available, use 3/8or 1/4as necessary

(b) Orient the SMA connector such that the solder cup is facing away from the Preamp

Case to facilitate soldering of wire from SMA connector to the PCB. (See Figure

B-2 for detail of SMA connector and proper orientation.)

(c) Arathane will be used as the locking feature. Be cautious to keep Arathane away

from the end of the screw where solder will need to be applied and away from the

head of the screw which will provide the ground path from the SMA case to the

screw.

138

Figure B-1: Bottom View of the Preamp case with SXM Electronics board installed

(d) Silver plated screws are used to facilitate soldering of ground wires to PCB.

4. Solder three wires between the SMA connector and the PCB using 26 AWG silver

plated copper wire, with no insulating layer and 63/37 solder with RMA flux.

(a) One wire each will go between the silver plated 2-56 X 5/16screws which secure

the SMA connector to the preamp case, and the ground pads on the PCB.

(b) One wire will go between the Signal pin from the SMA connector and the PCBs

signal pad.

(c) See Figure B-3 for a picture of the Assembled EM SXM showing the solder and

wires.

(d) See Figure B-4 for another view of the same connections.

(e) Work involving soldering to the PCB must follow all the applicable specs and

notes called out in the REXIS SXM drawing package and be carried out by a

certified technician.

(f) Install the SMA connector saver to the SMA connector.

139

Figure B-2: Bulkhead mounted SMA connector and PCB showing ground wires and signalwire

5. Install the piece of dry gap filler, CHO-THERM 1671 into the counter-bored

mount for the SDD.

(a) The 13 holes in the CHO-THERM should match the hole pattern in the preamp

case such that the SDD pins and mounting studs will properly pass through the

holes as shown in Figure B-5.

(b) Ensure that the CHO-THERM lies flat on the preamp before proceeding.

6. Install the Amptek SDD into the preamp case and secure with the 3/16 hex

standoff.

(a) The SDD must be treated with ESD precautions. While the manufacturer docu-

mentation is not specific as to the ESD class of the device, REXIS will treat the

SDD as a Class 1 device.

(b) After SDD integration, the whole SXM assembly should be treated as a Class 1

ESD sensitive device.

140

Figure B-3: Wires and solder joints between SMA connector and PCB

(c) The SDD must be carefully cleaned prior to assembly. Remove the red plastic

cap and gently wipe with clean wipes and isopropanol. The window on the top

of the SDD may be cleaned with gentle wiping if necessary. Clean the red cap as

well. Allow both to dry and replace the cap before assembly. The cap will remain

on the SDD until the collimator is installed.

(d) Ensure that the orientation feature on the base of the SDD lines up with the

matching feature on the preamp case, as shown in Figure B-6.

(e) Place the SDD in the counter-bore and gently push downward so that the SDD

pins are inserted into the pin receptacles on the PCB. Proper pin alignment and

pin length is necessary. Visually observe the pin alignment through the position

in the preamp case where the MDM connector will go. It may take some force to

insert the pins, do not apply significant pressure until alignment is visual verified.

(f) The pins were cut to the correct size by Amptek and the base of the SDD should

rest securely, flat against the CHO-THERM.

(g) The standoff is secured after the SDD pins have been inserted successfully. A jig

which can hold the SXM in place while the standoff is attached is recommended.

(h) The standoff will be hand-tightened. No staking will be used until the first func-

141

Figure B-4: Another view of the Solder Pads showing wires for ground and signal

tional test is completed, then the standoff will be staked with Arathane and hand

tightened.

7. Install the MDM Connector (M83513/13-A02NP) into the PCB using two 2-56

X 1/2socket head cap screws (NAS1352N02-8) and two 2-56 nuts (NAS1291C02).

(a) The nuts are self-locking, no Arathane or helicoils are necessary.

(b) Torque to 30 in-oz.

(c) The screws are to be installed so that the head of the screw is on the board below

the MDM and the nut rests on the top of the MDM connector.

(d) The orientation of the MDM connector is shown in Figure B-7.

(e) After the mounting screws are in place solder the pins using 63/37 solder with

RMA flux.

(f) Work involving soldering to the PCB must follow all the applicable specs and

notes called out in the REXIS SXM drawing package and be carried out by a

certified technician.

142

Figure B-5: The EM SXM preamp case with CHO-THERM installed

(g) Install the MDM connector saver and secure with the supplied jack-screws.

8. Carry out a preliminary functional test before completing assembly.

(a) The SDD is a COTS component and should be tested prior to final integration. By

testing at this point in the assembly, the SDD can be easily replaced if necessary,

without removing any fasteners staked with Arathane.

(b) Leave the red cap in place.

(c) Use a multimeter to test the power supplies for proper voltages and record the

measured values.

i. +5 V (+/- 0.1 V), measure wrt PS ground:

ii. -5 V (+/- 0.1 V), measure wrt PS ground:

iii. +TEC (+2.5, +/- 0.1 V), measure wrt -TEC ground:

iv. -TEC (0, +/- 0.1 V), measure wrt PS ground:

v. -HV (-120, +/- 2 V), measure wrt PS ground:

(d) Ensure that power is off and connect the ETU SXM wiring harness to the power

143

Figure B-6: The SXM SDD in preamp case showing proper orientation

supply lines through the small bread board. Use the schematic REX-SXM-101 to

check the pin out.

(e) Connect the o-scope to the SMA connector output.

(f) Power on the + and 5 V lines and record the current draw displayed on the power

supply.

i. +5 V current:

ii. -5 V current:

(g) Power on the +TEC supply line and record the current draw displayed on the

power supply:

(h) Wait 2 minutes after the +TEC line is powered on to allow the SDD to cool.

(i) Turn on the HV power supply and observe the output on the o-scope.

i. Look for the output signal voltage with the o-scope set to DC coupling (should

be 3.2 +/-0.1 V):

144

Figure B-7: The preamp case with MDM connector installed (note SDD is missing)

ii. Switch the o-scope to AC coupling and inspect the output signal (Vpp should

be ¡100 mV):

iii. Set the trigger to normal and trigger level to about 2.5 V; look for the SDD

reset signal. Record roughly how many resets are seen per second (should be

1/sec):

(j) Power Off HV line by removing alligator clip (toggling the output switch can

cause the ground to drift).

(k) Power off the +TEC line.

(l) Wait 2 minutes for the SDD to warm up.

(m) Power off the +/- 5 V line.

(n) Disconnect the ETU harness and o-scope.

9. Remove the SDD standoff, stake with Arathane and reattach. Hand tighten.

10. Install the SXM Collimator (REX-SXM-022) with three 2-56 X 3/8 socket head

cap screws.

145

(a) Remove the red SDD cap.

(b) Torque to 30 in-oz.

(c) Stake with Arathane.

(d) Figure B-8 shows the installed collimator in the SXM assembly.

Figure B-8: The SXM preamp case with collimator installed

11. Attach the grounding lug to the SXM preamp case with one 4-40 X 1/4 Phillips,

pan head screw.

(a) Insert the screw through the ground lug hole as through a washer.

(b) Stake with Arathane and torque to 62 in-oz.

(c) Orient the ground lug so that the long end of the lug is parallel with the long

edge of the preamp case, as shown in Figure B-9.

(d) The ground connection is achieved through the surface contact of the ground lug

with the preamp case, which has a 0.25diameter iridite finished section around

the hole for this purpose.

146

Figure B-9: The SXM grounding lug on preamp case with proper orientation

12. Attach the SXM Preamp Case (REX-SXM-021) to the SXM Bracket (REX-SXM-

010) with two 6-32 X 3/4and two 6-32 X 5/8socket head cap screws.

(a) The 5/8screws are installed on the side of the preamp case with the collimator

and the MDM connector. The 3/4holes are installed on the other side as shown

in Figure B-10.

(b) Orient the SXM on the bracket such that the MDM connector is on the top side

of the bracket. Proper orientation is shown in Figure B-10.

(c) Torque to 117 in-oz and stake with Arathane.

B.4 Fastener and Torque Tables

147

Figure B-10: The SXM preamp case on bracket with proper orientation

Table B.1: Fasteners needed for SXM Assembly

Description Locking NAS QuantitySCREW, SOCKET HEAD, 2-56 X3/8

Arathane N/A 3

SCREW, SOCKET HEAD, 4-40 X1/4

Helicoils N/A 4

SCREW, PAN HEAD, 4-40 X1/4, Phillips

Arathane N/A 1

SCREW, SOCKET HEAD, 6-32 X5/8

Arathane NAS1352N06-10 2

SCREW, SOCKET HEAD, 6-32 X3/4

Arathane NAS1352N06-10 2

SCREW, SOCKET HEAD, 2-56 X5/16, silver plated

Arathane NAS1352N02-5s 2

SCREW, SOCKET HEAD, 2-56 X1/2

Lockingnut

NAS1352N02-8 2

Nut, Locking, Hexagon Low-height, 2-56

Lockingnut

NAS1291C02 2

4-40 x 11/32long 3/16hex stand-off

Arathane N/A 1

Table B.2: Fastener torque values for SXM assembly

Screw Size-threads/in Torque (in-oz)2-56 304-40 626-32 117

148

Appendix C

SXM to MEB Safe-to-mate Procedure

C.1 Notes About the Assembly

The safe-to-mate procedure described below is for the initial MEB to SXM mating. During

ATLO, the safe-to-mate procedure will be much shorter, essentially a simple ESD safety

check before plugging in the SXM harness. This safe-to-mate should be documented on

a printed copy of the procedure. Date and personnel involved should be noted. Before

beginning, read the entire procedure thoroughly. Read all sub-bullets for a particular step

before performing step to ensure the entire step is understood.

C.2 Required Materials

(1x) MEB (REX-AS-112)

(1x) SXM assembly with bracket (REX-SXM-001)

(1x) Computer with Xilinx and Matlab

(1x) SXM test software and Matlab interface tool SVN 3-SubSystems\ 3.8-SXM\

3.8.3-Testing\ ETU Testing\ SXM ETU Control GUI.m

(1x) USB-JTAG cable

(1x) USB-RS422 cable

149

(1x) Bench-top power supply, for 28 V line to MEB

(1x) Oscilloscope, with two 10x probes

(1x) ESD mat and grounded GSE

(1x) SXM harness (REX-SXM-030)

(1x) Breakout Harness (MDM 15 to leads)

C.3 Safe-to-Mate

1. Power on the MEB

(a) Power on MEB power supply and connect JTAG

(b) Load ETU testing FPGA bitstream and SW onto MEB with Xilinx ISE,

ensure that SW STDIO is set to either side A or side B serial port which Matlab

can access, not the JTAG

(c) Start Matlab and run SXMETUtestingGUI.m

(d) Plug in USB-RS422 adapter and connect to proper serial port with Matlab

(clear serial ports and then select serial ports)

(e) Plug in breakout cable to SXM MDM-15 port on the MEB

2. Verify power lines on MEB

(a) With O-scope probe on breakout harness leads, verify the following power

supplies to the SXM are steady at the desired voltage. Look for noise over all

frequencies and note any periodic noise with obvious peaks above the noise floor.

Record peak to peak voltage noise:

i. + 5 V line:

ii. - 5 V line:

150

(b) On the breakout harness, place a 10 ohm resistor across the TEC power

lines and command the board to TEC PWM 200 kHz at 15% duty cycle. Record

voltage with respect to ground and Vpp:

i. + TEC:

ii. - TEC:

iii. Change to 25% duty cycle

iv. + TEC:

v. - TEC:

(c) Observe +/-5 V power lines for noise again while TEC PWM is on, record

Vpp:

i. + 5 V line:

ii. - 5 V line:

(d) Disable TEC PWM and enable HV PWM with default values (32.5 kHz at

50% duty cycle)

(e) Observe HV signal for noise and carefully note any periodic peaks above the

noise floor. Observe Vpp on 5 V power lines as well:

i. HV line:

ii. + 5 V line:

iii. - 5 V line:

(f) Re-enable TEC PWM to 15% duty cycle (with 10 ohm resistor still in place)

(g) Observe noise on all lines with probe on test leads from breakout harness:

i. + TEC:

ii. - TEC:

iii. HV line:

iv. + 5 V line:

v. - 5 V line:

vi. TEC temp:

151

vii. Ground:

(h) Disable TEC PWM and HV PWM

(i) Unplug breakout cable from SXM MDM-15 on MEB

(j) Voltages should be within +/- 0.2 Vavg of expected value. Vpp should be

<0.5 V over all time scales. If this is the case then proceed to the next section.

3. Mate SXM to the MEB

(a) Verify that all voltages are zero (+/- 0.01 V) between power lines/HV/Coax

and ground

(b) Ensure SXM is properly mounted on Bracket and on an ESD mat grounded

to the same reference as the MEBs ESD protective mat.

(c) Plug SXM harness into SXM MDM9 and coax line into SXM coax out

(d) Plug SXM harness into MEB

(e) Plug SXM coax out into MEB

4. Observe the SXM output

(a) Plug SXM Coax out cable into O-scope

(b) Enable TEC to begin cooling

(c) Monitor Temp-out diode with O-scope probe on temp out line from SXM

harness

(d) When temp readout reached 610 mV on O-scope enable HV with default

settings

(e) Observe signal out on O-scope

i. Look for decreasing reset frequency as SDD cools:

ii. Observe noise in signal-out, record Vpp:

(f) Probe HV line and compare HV noise to signal-out noise:

(g) Expose 55Fe source to SDD and look for 55Fe pulses in signal-out

152

(h) If pulses are identified, take screen shot and save

5. Triggering and Histogram Control

(a) Connect coax out to MEB instead of scope

(b) Set LLD and ULD to 0 and 4095

(c) Probe out-u, out-b, and reset lines with no source exposed to SDD

(d) Take histogram of background (no source on SDD)

(e) Probe out-u, out-b, and reset lines with source exposed to SDD

(f) Take histogram with source exposed to SDD

153