ASTRO-E Project Data Management Plan

ASTRO-E Project Data Management Plan ASTRO-E Guest Observer Facility code 662, NASA/GSFC, Greenbelt, MD 20771, USA, and Institute of Space and Astronautical Science Yoshinodai, Sagamihara, Kanagawa, 229 Japan version 1.3 January 20, 2000 Comments and questions to

[email protected]

Version History

v0.0 (November 11, 1997) | Internal distribution within ASTRO-E GOF. v0.1 (December 4, 1997) | Internal distribution within GSFC. v0.2 (December 23, 1997) | Internal distribution within GSFC. Add XRS telemetry and FRF descriptions (section 4.3.2). HXD chapter is rewritten with additional telemetry information (chapter 6). Modify description on the satellite scheduling softwares (section 10.1). A lot of minor modications in Chapters 8 and 9 taking accounts of comments from GSFC ASTRO-E software team members. v0.21 (January 16, 1998) | Minor modications in Chapters 6 to 10. Correct typos. Distribute to ASTRO-E software team members in Japan. v1.0 (September 18, 1998) | The rst \ocial" version after the agreement is made between ISAS and ASTRO-E GOF. v1.1 (March 9, 1999) | Reorganized chapters related to mission operation and software. v1.2 (April 8, 1999) | Minor changes in Chapters 7 through 11 in accordance with the understanding at the software meeting and science working group meeting at ISAS in March 1999. First public release version. v1.3 (January 20, 2000) | Add appendixes for ASTRO-E coordinates and FTOOLS development guideline. Updated the ASTRO-E FTOOLS list. XIS 2x2 mode telemetry structure is explained in detail. Many minor updates to reect the latest status of the software development to date. v1.3 (January 20, 2000) | Current version.

Contents 1 Introduction 1.1 1.2 1.3 1.4

Mission Overview : : : : : : : : : : : : : The ASTRO-E Guest Observer Facility About This Document : : : : : : : : : : Related Documents : : : : : : : : : : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

2.1 The Satellite : : : : : : : : : : : : : : : : : : 2.2 Launch, Orbit and Operation : : : : : : : : : 2.3 On-board Data System : : : : : : : : : : : : : 2.3.1 Data Processor (DP) : : : : : : : : : : 2.3.2 Data Recorder (DR) : : : : : : : : : : 2.3.3 Communication with Ground System 2.4 ASTRO-E Telemetry : : : : : : : : : : : : : : 2.4.1 CCSDS Packets : : : : : : : : : : : : : 2.4.2 Telemetry Data Transfer : : : : : : : : 2.4.3 SIRIUS Database : : : : : : : : : : : : 2.5 Sub-Instruments : : : : : : : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

2 The ASTRO-E Mission

3 X-ray Telescopes (XRT)

3.1 Mirrors : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3.2 Method of Fabrication : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3.3 Thermal Shield : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

4 X-ray Spectrometer (XRS)

4.1 XRS Instrument : : : : : : : : : : : : : 4.1.1 Calorimeter Array : : : : : : : : 4.1.2 Cryogenics and Refrigerator : : : 4.1.3 Blocking Filters : : : : : : : : : : 4.1.4 Calibration Sources : : : : : : : 4.1.5 Filter Wheel : : : : : : : : : : : 4.2 On Board Data Processing : : : : : : : : 4.2.1 Outline : : : : : : : : : : : : : : 4.2.2 Pulse Detection : : : : : : : : : : 4.2.3 Pulse Height Determination : : : 4.3 XRS Telemetry Structure : : : : : : : : 4.3.1 XRS APIDs : : : : : : : : : : : : 4.3.2 Contents of the XRS Telemetry : 4.4 CDP Science Data Structure : : : : : : 4.4.1 PHA Block : : : : : : : : : : : : 4.4.2 Auxiliary Blocks : : : : : : : : : 1

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : :

7

7 7 8 8

11

11 11 11 17 17 17 17 17 18 18 21

23 23 23 25

27

27 27 27 30 30 30 30 30 31 31 32 32 33 33 33 34

2

CONTENTS

5 X-ray Imaging Spectrometer (XIS)

5.1 XIS Hardware : : : : : : : : : : : : : 5.2 On-board Data System : : : : : : : : 5.2.1 CCD Data Transfer : : : : : 5.2.2 Pulse Height Determination : 5.2.3 On-board Event Analysis : : 5.2.4 Hot Pixels : : : : : : : : : : : 5.3 Data Processing Modes : : : : : : : 5.3.1 Clock Modes : : : : : : : : : 5.3.2 Window and Burst option : : 5.3.3 Editing Modes : : : : : : : : 5.4 Event and Telemetry Structure : : : 5.4.1 Observation Modes : : : : : : 5.4.2 Diagnostic Modes : : : : : : : 5.4.3 XIS APID : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : :

7.1 Observation Program : : : : : : : : : : : : : 7.1.1 Denition of the Mission Phases : : 7.2 Type of the Observations : : : : : : : : : : 7.2.1 Observatory Time : : : : : : : : : : 7.2.2 IOC Observations : : : : : : : : : : 7.2.3 SWG Observations : : : : : : : : : : 7.2.4 GO Observations : : : : : : : : : : : 7.2.5 Calibration Observations : : : : : : 7.2.6 Target of Opportunity Observations 7.2.7 Time Constraint Observations : : : 7.2.8 HXD TPU Observations : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

6 Hard X-ray Detector (HXD)

6.1 Sensor : : : : : : : : : : : : : : : : 6.1.1 BGO Shields : : : : : : : : 6.1.2 GSO Sensors : : : : : : : : 6.1.3 PIN Diodes : : : : : : : : : 6.1.4 Passive Fine Collimaters : : 6.2 Electronics : : : : : : : : : : : : : 6.2.1 HXD-AE : : : : : : : : : : 6.2.2 HXD-DE : : : : : : : : : : 6.3 On-board Data Processing : : : : : 6.3.1 Pulse Shape Discrimination 6.3.2 Anti Coincidence : : : : : : 6.3.3 Pseudo Event : : : : : : : : 6.3.4 PI Program : : : : : : : : : 6.4 TPU Observations : : : : : : : : : 6.4.1 Transient data : : : : : : : 6.4.2 Gamma-ray burst data : : : 6.4.3 Position determination : : : 6.5 HXD Telemetry Structure : : : : : 6.5.1 HXD APID : : : : : : : : : 6.5.2 WPU main data : : : : : : 6.5.3 WPU sub data : : : : : : : 6.5.4 TPU data : : : : : : : : : : 6.5.5 HK data : : : : : : : : : : : 6.5.6 Status Packets : : : : : : : 6.5.7 Dump Packets : : : : : : :

7 Mission Operations

: : : : : : : : : : : : : : : : : : : : : : : : :

37

37 37 37 38 40 40 40 40 41 41 42 42 44 45

47

47 47 47 47 48 48 48 48 50 50 50 50 51 52 52 52 52 53 53 53 54 55 55 55 55

57

57 57 59 59 60 60 60 60 60 61 61

CONTENTS 7.3 Proprietary Period : : : : : : : : : : : : : : : : 7.4 Satellite Operations : : : : : : : : : : : : : : : 7.4.1 Scheduling the Observations : : : : : : : 7.4.2 Operating the Satellite : : : : : : : : : : 7.5 Data Flow : : : : : : : : : : : : : : : : : : : : : 7.5.1 Data Retrieval and Raw Data Archives 7.5.2 Data Processing at ISAS and GSFC : : 7.5.3 Data Delivery to ASTRO-E Observers : 7.5.4 ASTRO-E Archives : : : : : : : : : : :

3 : : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

8.1 General Software Design Principles : : : : : : : : : 8.2 ASTRO-E Specic Design Principles : : : : : : : : 8.3 ASTRO-E Software Standards : : : : : : : : : : : 8.3.1 Languages : : : : : : : : : : : : : : : : : : : 8.3.2 Coding Rules and Compiler Requirements : 8.3.3 Systems Supported : : : : : : : : : : : : : : 8.3.4 Coordination and Version Control : : : : : 8.3.5 Documentation : : : : : : : : : : : : : : : : 8.4 ASTRO-E FTOOLS Global Development Scheme :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

10.1 Observation Planning Software : : : : : : : : : : : : : : 10.1.1 TAKO (Timeline Assembler, Keyword Oriented) 10.1.2 MAKI : : : : : : : : : : : : : : : : : : : : : : : : 10.2 Simulation Software : : : : : : : : : : : : : : : : : : : : 10.2.1 Counting Rate Simulation { PIMMS : : : : : : : 10.2.2 Spectral Simulation { XSPEC : : : : : : : : : : : 10.2.3 XRT Ray-tracing Package { xrrt : : : : : : : : : 10.2.4 Detector Simulators : : : : : : : : : : : : : : : : 10.2.5 End-to-End Simulator { xrssim : : : : : : : : : : 10.2.6 ASTRO-E Simulator and Data Analysis : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

: : : : : : : : : :

11.1 Overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11.2 Stage 0 { Satellite Specic Calibration at ISAS : : : : : : : : : 11.2.1 Orbit Determination : : : : : : : : : : : : : : : : : : : : 11.2.2 Attitude Determination : : : : : : : : : : : : : : : : : : 11.2.3 Create RPT les from the SIRIUS Database : : : : : : 11.3 Stage 1 { Conversion of the Telemetry to the First FITS Files : 11.3.1 First Stage Software { mk1stts : : : : : : : : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

8 Software Principles

9 ASTRO-E Function Libraries

9.1 ASTRO-E Specic Tasks (astetool) : : : : : : : : 9.1.1 Time Conversion : : : : : : : : : : : : : : 9.1.2 Coordinate Conversion : : : : : : : : : : : 9.1.3 Energy Calibration : : : : : : : : : : : : : 9.1.4 Data Access Layer (DAL) functions : : : 9.1.5 HK Information Acquisition : : : : : : : : 9.1.6 Other Tasks : : : : : : : : : : : : : : : : : 9.2 Attitude and Orbit Related Tasks (atFunctions) 9.2.1 Attitude Information : : : : : : : : : : : : 9.2.2 Orbit Information : : : : : : : : : : : : : 9.2.3 Attitude and Orbit Information : : : : : : 9.3 Ray-tracing function library (xrrt) : : : : : : : :

10 Planning and Simulation Software

11 Data Analysis and Processing Software

: : : : : : : : : : : :

61 61 61 61 62 62 62 62 63

65

65 65 66 66 67 67 67 67 67

71

71 71 71 71 72 72 72 72 72 72 73 73

75

75 75 75 77 77 77 77 78 78 79

81

81 81 81 82 82 83 83

4

CONTENTS 11.3.2 First FITS File Names : : : : : : : : : : : : : : : : : : 11.4 Stage 2 { Apply Instrument Specic Calibration : : : : : : : 11.4.1 Stage 2-1 { Preprocessing : : : : : : : : : : : : : : : : 11.4.2 Stage 2-2 { Rene the First FITS event les : : : : : : 11.4.3 Stage 2-3 { Apply Calibration and Fill Columns : : : 11.4.4 Stage 2-4 { Rening Calibrated FITS Files : : : : : : 11.5 Stage 3 { Data Analysis : : : : : : : : : : : : : : : : : : : : : 11.5.1 Stage 3-1 { Data Screening : : : : : : : : : : : : : : : 11.5.2 Stage 3-2 { Extract Scientic Products : : : : : : : : : 11.5.3 Stage 3-3 { Generate Observation Specic Responses : 11.5.4 Stage 3-4 { Scientic Analysis and Consideration : : : 11.6 Pipe-line Processing System : : : : : : : : : : : : : : : : : : :

12 Calibration

12.1 Documentation : : : : : : : : : : : : : : : 12.2 Calibration Software : : : : : : : : : : : : 12.3 Calibration Database (CALDB) : : : : : : 12.3.1 Structure and Organization : : : : 12.3.2 Time-dependent Calibration Files : 12.3.3 Calibration File Name : : : : : : : 12.3.4 Version Control : : : : : : : : : : : 12.4 Important Calibration Files : : : : : : : : 12.4.1 General : : : : : : : : : : : : : : : 12.4.2 XRT : : : : : : : : : : : : : : : : : 12.4.3 XRS : : : : : : : : : : : : : : : : : 12.4.4 XIS : : : : : : : : : : : : : : : : : 12.4.5 HXD : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : :

13 Guest Observer Support 13.1 13.2 13.3 13.4 13.5 13.6

On-line Service and Help : : : : : : : : : : : Proposal Support : : : : : : : : : : : : : : : Observation Planning : : : : : : : : : : : : Pipe-line Processing and Data Distribution Data Analysis Support : : : : : : : : : : : : Community Oversight : : : : : : : : : : : :

14 ASTRO-E Database and Archives

14.1 ASTRO-E Databases : : : : : : : : 14.1.1 Data Access : : : : : : : : : 14.1.2 Proposal Database : : : : : 14.1.3 Observation Database : : : 14.1.4 Processing Database : : : : 14.1.5 Archive Database : : : : : : 14.1.6 Product Database : : : : : 14.2 ASTRO-E Archives : : : : : : : : : 14.2.1 Policy and Responsibilities 14.2.2 Contents : : : : : : : : : : 14.2.3 Archival Access : : : : : : :

A Acronym

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : :

84 85 87 87 88 89 89 89 90 91 92 92

95

95 96 96 96 96 97 97 97 97 98 98 99 99

101

101 101 102 102 102 102

103

103 103 103 103 105 105 105 105 105 105 106

107

CONTENTS

5

B De nition of the Coordinate System used for ASTRO-E B.1 Denition of the Coordinates : : : : : : B.2 Implementation to the FITS Event Files B.2.1 Names of the Columns : : : : : : B.2.2 Type and Range of the Columns

C Ftool developers guideline C.1 C.2 C.3 C.4 C.5

Items to be Delivered Source codes : : : : : Parameters : : : : : : Makeles : : : : : : : Documents : : : : : :

: : : : :

: : : : :

: : : : :

: : : : :

D Important Internet Addresses

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

: : : : :

111

111 112 112 112

115

115 115 116 116 116

119

D.1 HTTP addresses : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 119 D.2 FTP addresses : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 120 D.3 E-mail addresses : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 120

Index Bibliography

121 125

6

CONTENTS

Chapter 1

Introduction 1.1 Mission Overview ASTRO-E will be the fth Japanese X-ray astronomical satellite launched by the Institute of Space and Astronautical Science (ISAS)1 . Following ASCA, which was launched in 1993, ASTRO-E is the second ISAS astronomy satellite built in close collaboration with NASA. The current launch date for ASTRO-E is February/March in 2000. ASTRO-E carries three sets of instrumentation: an X-ray micro-calorimeter (X-ray Spectrometer XRS), four X-ray CCD cameras (X-ray Imaging Spectrometers XIS), and a Hard X-ray Detector (HXD). The XRS is developed by NASA/GSFC, ISAS and Tokyo Metropolitan University the XIS by MIT, Kyoto University and Osaka University and the HXD by Tokyo University, ISAS, RIKEN and KEK. The XRS and XIS detectors are put at the foci of X-ray Telescopes (XRT) fabricated by NASA/GSFC and Nagoya University. XRS and XIS cover the soft energy band (0.4 { 10 keV). XRS has the highest energy resolution, E 12 eV (FWHM), covering a 4
2 FOV by 32 bi-linear pixels. XIS has a FOV of 18
18 with a moderate energy resolution E 120 eV at 6 keV. The XRT spatial resolution is about 1.5 arcmin (HPD). HXD is a low background collimated detector in the energy band 10 to 700 keV with spectral resolutions of 9 % (at 662 keV) to 30 % (at 10 keV). All the instruments operate simultaneously and point the same direction. Thus, ASTRO-E will study X-ray and soft
-ray properties of the celestial sources with superior energy resolution and sensitivity. XRS carries a cryogenic system comprising liquid helium and solid neon. The time for all the solid neon ( 100 liter) to completely melt down determines the mission life of XRS this is expected to be about two years. Thus XRS will be the primary instrument for the rst two year of the mission, during which the observation time is shared by the ASTRO-E team members and Guest Observers (GO). After the initial XRS phase, the ASTRO-E observation time will be fully open to US and Japanese Guest Observers (see chapter 7 for the observation programs). XIS and HXD have longer lives, though they may suer some degradation due to radiation damage. It is expected that ASTRO-E will produce up to 1.2 G-bytes of raw data daily (section 2.2). Therefore, total amount of the raw data per year will be 440 G-bytes. Even after the 2-yr XRS mission life is nished, the amount of the telemetry data may not be reduced since XIS and HXD can be allocate to use more telemetry instead of XRS (section 2.4). 0

0

0

0

1.2 The ASTRO-E Guest Observer Facility The ASTRO-E Guest Observer Facility (GOF) located at NASA's GSFC will be responsible for the US Guest Observer support. This includes the following tasks:  Supporting GO's proposal preparation 1 It is a custom for Japanese satellites to be given new names after the launch (for example, ASTRO-D was named ASCA). ASTRO-E is also expected to be given a new name after the launch.

7

8

CHAPTER 1. INTRODUCTION

    

Receiving, validating, processing, archiving and distributing the data Providing documentations and on-online materials Providing data analysis software and calibrations Providing expert help to GOs Populating the US ASTRO-E archive at the HEASARC ASTRO-E GOF WWW home page is located at http://heasarc.gsfc.nasa.gov/docs/astroe/astroegof.html

.

ASTRO-E GOF belongs to the Oce of Guest Investigator Programs (OGIP) at NASA/GSFC. Besides the ASTRO-E GOF, OGIP contains High Energy Astrophysical Science Archive Research Center (HEASARC) and similar GOFs for other major high energy missions. HEASARC is a data center responsible for archiving data from past high energy astrophysical missions and constructing a user-friendly data analysis environment. ASTRO-E GOF will carry out its tasks in accordance with HEASARC.

1.3 About This Document This document denes the ASTRO-E data processing and software system which is eective after the data is delivered to the ASTRO-E science team at ISAS. We shall explain the ASTRO-E project and data management plan from the view point of the end users. The data management plan proposed in this document has been agreed by ISAS, the ASTRO-E GOF, the GSFC Astrophysics Data Facility (ADF), and HEASARC. Expected readers of this document are program managers at ISAS, NASA HQ and GSFC, scientists and programmers working on the ASTRO-E project, and ASTRO-E users. Readers should be reminded that this document does not serve as the original source for the technical information such as instrumental specication and telemetry formats, or high-level political agreements such as allocation of the observation time between Japan and US. These technical and/or political issues are dened and documented in the original documents maintained by ISAS and/or NASA. Description in this document on these issues is based on the original documents, which are often written in Japanese. In particular, most of the technical information described through chapter 2 to 6 is taken from the \ASTRO-E Interim Report" 1] published by ISAS in July 1998 (in Japanese). In chapter 2, general aspects of the ASTRO-E satellite are explained. In chapter 3 through 6, the ASTRO-E scientic instruments are explained. In chapter 7, how ASTRO-E is operated and the observations are performed shall be explained. ASTRO-E software design principles and agreements are presented in chapter 8. ASTRO-E software tasks required in the data processing and other aspects of the project are dened in chapter 9. Important issues regarding the calibration are given in chapter 12. Tasks regarding the Guest Observer support are shown in chapter 13, and ASTRO-E archives are explained in chapter 14. In appendix A, acronyms often used in the ASTRO-E project are explained. Important ASTRO-E related Internet addresses are summarized in appendix D.

1.4 Related Documents Other important issues which cannot be covered in this document will described in separated documents. The document sets will at least include the following issues:  ASTRO-E FITS File Formats | FITS Formats of the ASTRO-E HK and event les, calibration les and other important les (e.g., attitude les and orbit les) are explained.

ASTRO-E PDMP v1.3 (January 20, 2000)

9

 ASTRO-E Calibration | How ASTRO-E instruments and data are calibrated is explained.

See 12.1 for details.  Data analysis manual { Explains ASTRO-E Observers how to analyze ASTRO-E data using software tools supplied by GOF2 . In addition, ASTRO-E GOF will publish the ASTRO-E Newsletter from time to time, which will provide up to date information on all mission issues, including calibrations, software, mission status and publications3.

2 This will be similar to the ASCA Data Reduction Guide (ABC Guide) provided by ASCA GOF, which is available both electronically and as paper copy. See http://heasarc.gsfc.nasa.gov/docs/asca/abc/abc.html for the electronic version. 3 From the launch of ASCA in February 1993 to April 1997, ASCA GOF published ve issues of \ASCA Newsletter", which is available both electronically and as a paper copy. See http://heasarc.gsfc.nasa.gov/docs/asca/newsletters.html . for the electronic version.

10

CHAPTER 1. INTRODUCTION

Chapter 2

The ASTRO-E Mission 2.1 The Satellite Figure 2.1 is a drawing of the ASTRO-E satellite. The ASTRO-E will weigh about 1,600 kg. The ve X-ray Telescopes (XRT), one for XRS and four for XIS are put on the top of the Extensible Optical Bench (EOB) (gure 2.2). EOB is extended after the launch, and the total length of the satellite will be 7.1 m after the extension. Figure 2.3 shows a schematic side-view of the ASTRO-E instruments. The focal length of the XRT-S (XRT for XRS) is 4.5 m and those of the XRT-I0, I1, I2, I3 (XRT for XIS) are 4.75 m. The ve telescope point the same direction (+Z direction), and HXD, which collimates hard X-rays but does not have a mirror, also points the same direction. All the instruments, namely, XRS, four XIS, and HXD, are put on the octagonal base-plate (gure 2.4). Eight rectangular side panels surround the baseplate and compose the spacecraft. Denition of the satellite coordinate system is indicated in gure 2.4. The pointing direction is dened as the +Z direction, and the solar array paddle, which supplies the power 1.5kW, faces the +Y direction. Note that XRS is put furthest from the Sun to avoid the heat.

2.2 Launch, Orbit and Operation The ASTRO-E will be launched in February 2000 by the fourth M-V rocket 1 from the ISAS/Kagoshima Space Center (KSC), located at the east longitude 131. 0848 and the latitude +31. 2474. The ASTRO-E orbit will be circular with the altitude 550 km and the inclination 31 degree. ASTRO-E will be operated exclusively at KSC commands are sent from KSC and the data are retrieved at KSC during the ground contacts. Unlike ASCA, other ground stations such as NASA DSN (Deep Space Network) stations will not be used to download the data, since DSN may not provide fast enough downlinks (see below). ASTRO-E orbits the earth 15 times a day, and KSC can contact the satellite usually ve times a day, each for up to 15 minutes. Note that the capacity of the Data Recorder (DR) will be 6 Gbits, and the telemetry rate of the data downlink of the X-band will be 4 Mbps (see the next section). Hence it would take 25 minutes to retrieve the entire data stored in DR this is not possible within a single ground contact which is at most 15 minutes. Thus, eective operation programs should be invented to make the maximum use of the DR. Typical amount of the data which can be retrieved during a ground contact is 2 Gbits, which takes 512 seconds to reproduce. Therefore, total amount of the raw data for one day observation will be 2 Gbits/contact
5 contacts = 10 Gbits  1.2 Gbytes.





2.3 On-board Data System In gure 2.5, we show an outline of the ASTRO-E on-board data system. Explanations of the XRS, XIS and HXD systems are found in the chapters 4,5 and 6, respectively. 1

ASCA was launched by the M-III rocket which is smaller than M-V.

11

12

CHAPTER 2. THE ASTRO-E MISSION

Figure 2.1: The ASTRO-E satellite. Unit of the scale is mm.

ASTRO-E PDMP v1.3 (January 20, 2000)

13

Figure 2.2: The ASTRO-E Extensible Optical Bench (EOB). The gure shows the conguration after the extension. EOB is shrunk during the launch, and extended after the launch in orbit.

14

CHAPTER 2. THE ASTRO-E MISSION

Figure 2.3: A schematic side-view of the ASTRO-E instrument conguration. All the instruments point toward top of the satellite, which is dened as the satellite +Z direction.

ASTRO-E PDMP v1.3 (January 20, 2000)

15

Figure 2.4: A top-view of the ASTRO-E baseplate. Unit of the scale is mm. Solar panels are installed on the +Y side of the satellite body. XIS0, 1,2 and 3 are located in the order of decreasing X-coordinate.o

PCU

DHU

CMD

...

Real-time data

Reproduced data

Commands

Sub-systems

ACS

S-band Antenna

X-band Antenna

DR

DP

XRS

XIS

MPU

HXD

CDP

PPU23

PPU01

HXD-DE

ACHE

CAP

AE/TCE-23

AE/TCE-01

HXD-AE

FDE

XRS-S

XIS-S3

XIS-S2

XIS-S1

XIS-S0

HXD-S

FW

XRT-S

XRT-I3

XRT-I2

XRT-I1

XRT-I0

16 CHAPTER 2. THE ASTRO-E MISSION

Figure 2.5: Outline of the ASTRO-E on-board system block diagram.

ASTRO-E PDMP v1.3 (January 20, 2000)

17

2.3.1 Data Processor (DP)

The Data Processor (DP) handles most on-board data processing. DP receives scientic data from XRS, XIS and HXD, and housekeeping data from Data Handling Unit (DHU). DHU is the link between the DP and sub-systems such as the Attitude and Orbit Control System (AOCS) and the Power Control Unit (PCU). There are four data rates with which the instruments and DP produce the telemetry SuperHigh rate (maximum 524 kbps), High rate (262 kbps), Medium rate (131 kbps) and Low rate (32 kbps) 2. DP receives the data from XRS, XIS, HXD and DHU in the form of the variable CCSDS (Consultative Committee for Space Data Systems) packets. DP embeds these data into the xed length telemetry frame. The amount of the data DP receives from sub-systems can be variable with commands. For example, after the mission life of XRS is nished, DP can quit receiving data from XRS and instead increase amount of the data to receive from other instruments. On the ground station, the xed telemetry frame data is de-packeted to reproduce the variable CCSDS packets. The ASTRO-E telemetry format is explained in section 2.4 in more detail.

2.3.2 Data Recorder (DR)

After the processing, DP sends the data to the real-time telemetry during the ground contact, or to the Data Recorder (DR) during out of the contact. The data stored in DR are reproduced and sent to the ground station via DP during the ground contact. The capacity of the DR is 6 Gbits. Maximum rate of the data recording is 512 kbps and that of reproducing is 4 Mbps.

2.3.3 Communication with Ground System

ASTRO-E uses two dierent wave-bands and antennas for the communication with the KSC ground station. X-band has the telemetry rate 4 Mbps, and is mostly used to downlink the reproduced data from the DR (gure 2.5). S-band, whose maximum telemetry rate is 262 kbps, is mainly used to receive commands and for real-time communication (gure 2.5). Command signals from the ground station are received by the S-band receiver on the satellite, then decoded by the Command Decoder (CMD), and sent to the DHU. DHU distributes the commands to each instrument through Peripheral Interface Modules (PIM) attached to each instrument. Real time commands can be sent from the ground station to each instrument in real-time. Also, DHU can hold programmed command sequences, and the commands can be sent to each instrument from DHU sequentially after the ground contact. This is called Organized Operation. The basic unit of the Organized Operation is called OG (Operational Group). Sequence of the OG is named Operational Program (OP).

2.4 ASTRO-E Telemetry 2.4.1 CCSDS Packets

ASTRO-E adopts the CCSDS packet telemetry. Before being sent to the DP, the XRS, XIS and HXD data are edited and made into the CCSDS packets by DP/XRS-DE, XIS-MPU (Main Processing Unit) and HXD-DE, respectively 3. DHU converts the data from other non-scientic instruments into the CCSDS packets. The process to convert the data into the CCSDS packets comprises the \segmentation" (divide data into pieces) and the \encapsulation" (add headers to each piece). 2 XIS will take most of the scienti c data. For typical observations, XIS will require 100 kbps, and for bright sources (like Crab nebula) it will take 400 { 500 kbps. Housekeeping data, which are handled by DHU, take up to 32kbps. 3 XRS-CDP (Calorimeter Digital Processor) does not have a capability to edit the CCSDS packet, hence a part of the DP takes care of converting the XRS data into the CCSDS packets this part of the DP is named DP/XRS-DE.

18

CHAPTER 2. THE ASTRO-E MISSION

A single CCSDS packet consists of the 6 byte primary header, 4 byte secondary header, and the user data with a variable length of 0 to 65532 bytes. User data of the XRS, XIS and HXD CCSDS packets can be variable from 0 to 65532 bytes. User data of the CCSDS packets generated by DHU have the xed length 426 bytes. Figure 2.6 shows the CCSDS packet format4. The 11-bit Application Process ID, or APID, tells data types in the CCSDS packet. The rst two bits tell the data type (science data, housekeeping data or memory/dump data), the following four bits are for the instrument/subsystem ID, and the last 5-bit data type ID depends on the instrument/subsystem (gure 2.6). Explanation of the data type ID will be given in later chapters for each instrument (sections 4.3.1 and 6.5.1). The 32-bit secondary header tells the satellite time (Time Counter TI), in which the LSB is 1/4098 sec.

2.4.2 Telemetry Data Transfer

CCSDS packets are edited by DP and embedded in the x format telemetry frames. First, variable CCSDS packets having the same Virtual Channel ID (VCID) are divided or concatenated to form a 8048 bit Multiplexing Protocol Data Unit (MPDU)(gure 2.7). A single MPDU packet has a 16 bit header and a 8048 bit MPDU. The least signicant 11 bits of the header tell location of the rst CCSDS header in the MPDU. A Virtual Channel Data Unit (VCDU) packet is made by adding a 48 bit VCDU primary header and a 48 bit VCDU trailer to the beginning and end of a single MPDU packet. The 6 bit Virtual Channel ID (VCID) in the VCDU header describes the content of the VCDU (gure 2.7). The VCDU trailer consists of the 32 bit Command Link Control Work (CLCW) and the 16 bit Cyclic Redundancy Code (CRC). These are used to detect any data transmission errors. A 32 bit sync maker (Attached Sync Maker, ASM) is attached to the beginning of a VCDU packet, and a single 1024 byte ASTRO-E telemetry data unit is made. This is the telemetry data transmission unit from the satellite to the KSC ground station.

2.4.3 SIRIUS Database

When the telemetry data is received, a 32-byte telemetry header is attached at the ground station (gure 2.7). Information such as data receive time, orbital pass number, communication radio band (S-band or X-band), satellite and antenna ID etc are written in the header. The telemetry data received at KSC is sent to ISAS by a proprietary network, and permanently stored in the ISAS database named \SIRIUS" after minimum data processing. The SIRIUS database stores raw telemetry data of all the past ISAS missions. Procedure of the data processing to store the telemetry data into the SIRIUS database is the following: 1. Obtain the telemetry data, and identify them as S-band real, X-band real, or X-band playback data. 2. Separate these data by dierent VCID. 3. Merge S-band real and X-band real data with the same VCID. 4. Merge real data and X-band playback data with the same VCID, and reset the VCID to the real one. The original VCID is kept in the 32-byte SIRIUS header (gure 2.7). Now, there will be ve les for a single sequence5 corresponding to the VCID 1 to 5 (gure 2.7). 5. Copy the TI of the rst CCSDS packet in the telemetry data to the SIRIUS header after adding upper 16 bits. The 48 bit time counter thus made is called Extended Time counter (ETI). See gures on p.711 to p.718 in 1] for details. Unit of a single SIRIUS sequence is rather arbitrary, and not necessarily corresponding to the observational sequence. 4 5

00

11 10 01

Figure 2.6: The CCSDS packet format.

DHU: Data Handling Unit AOCU: Attitude and Orbit Control Unit TCI: Telemetry Command Interface HCE: Heater Control Electronics DIST: Power Distributer DP: Data Processor

DHU AOCU TCI HCE Depends on DIST the subsystem DP XRS XIS HXD HK

subsystem ID data type ID 4 bits 5 bits

Reserved 0001 Housekeeping 0010 Memory data 0011 or Dump data 0100 Science and 0101 other data 0110 0111 1000 1001 1010

common use 2 bits

1 bit/1

14 bits 16 bits

Data is complete in a single packet

The last segment of the divided data

10 11

The first segment of the divided data

A part of the divided data (not first nor last)

2 bits

01

00

11 bit

LSB is 1/4096 sec

4 bytes

0~65532 bytes

Secondary Header User Data Type Sec. Header Application Sequence Sequence Packet (Time Counter; TI) Flag Process ID flag Count length

length/value(if constant) 3 bits/000 1 bit/0

Version

Primary Header (6 bytes = 48 bits)

ASTRO-E PDMP v1.3 (January 20, 2000) 19

Figure 2.7: The ASTRO-E telemetry data frame structure.

satellite repromanagement duced data science data

science data 000011 000100 000101 100001 100010 100011 100100 100101 XRS data XIS data HXD data

XIS data HXD data common inst. status,AOCS data DP,XRS,XIS, HXD status

XRS data

6 bits

24 bits

00000000

Not used (8bit)

VCDU packet (8160 bits)

Virtual Channel Data Unit (VCDU) CLCW CRC (8064 bits) (32 bits) (16 bits)

VCDU trailer

CCSDS packet

Telemetry Data (8192 bits)

SIRIUS data format

Telemetry Header SIRIUS Header (256 bits) (256 bits)

A single Astro-E telemetry data unit (8192 bits=1024 bytes)

Attached Sync Maker (32 bits) 1ACFFC1Dh

00000101

Category VCID Meaning time assignment DP and DHU time 000000 real000001 common inst. status,AOCS data time satellite data management 000010 DP,XRS,XIS, HXD status

01

CCSDS packet

Multiplexing Protocol Data Unit (MPDU) (8048 bits)

CCSDS packet .....

VCDU primary header (48 bits) Version Spacecraft VCID VCDU No.(2bits) ID counter

Not used first CCSDS packet 00000 header pointer(11 bits)

MPDU header(16 bits)

CCSDS packet

Each CCSDS packet length is variable (80 to 65612 bytes)

20 CHAPTER 2. THE ASTRO-E MISSION

ASTRO-E PDMP v1.3 (January 20, 2000)

21

The SIRIUS database may be accessed only within ISAS. The ISAS ASTRO-E team will regularly access the SIRIUS database to create the First FITS Files, which will be the start point of all the instrumental calibration and scientic data analysis (chapter 8 and 9). Simultaneously, the Raw Packet Telemetry (RPT) FITS les are created and sent to GSFC for a backup of the raw telemetry les (chapter 9).

2.5 Sub-Instruments Names and their abbreviations of ASTRO-E sub-instruments which are not directly related to the scientic observations are summarized here.

Power Supply Sub-Systems Solar Array Paddle Power Control Unit Battery Charge Control Unit Battery Shunt Dissipater Power Distributer Power Supply Unit

Communication Sub-Systems S-band Antenna X-band Antenna S-band Duplexer S-band Switch

S-band Transmitter X-band Transmitter S-band Receiver X-band Power Amplier

Data Handling Sub-Systems Command Decoder Data Handling Unit Peripheral Interface Module Telemetry Command Interface Data Processor Data Recorder Housekeeping

Launch Operation Sub-Systems Instrument-Satellite Ignition Power System

SAP PCU BCCU BAT SHNT DIST PSU SANT XANT SDIP SSW SHYB XHYB TMS TMX S-BCN SBR XPA CMD DHU PIM TCI DP DR HK EPT-SA INS IGPS

Attitude and Orbit Control Sub-Systems Attitude and Orbit Control Unit Drive Magnetic Torquer Momentum Wheel Star Tracker

AOCU DRV MTQ MW STT

22 Non-spinning Sun and Aspect Sensor Geomagnetic Aspect Sensor Inertial Reference Unit Accelerometer

Propulsion Sub-Systems Reaction Control System

Thermal Sub-Systems

Heater Control Electronics

CHAPTER 2. THE ASTRO-E MISSION NSAS GAS IRU ACM RCS HCE

Chapter 3

X-ray Telescopes (XRT) 3.1 Mirrors ASTRO-E X-ray telescopes (XRT) consists of nested conical thin-foil mirrors which share similar design concepts with ASCA XRT 2], but with several improvements (3],4]). ASTRO-E carries ve XRTs four identical ones for four XISs (XRT-I) and one for XRS (XRT-S). In table 3.1, characteristics of ASCA and ASTRO-E XRT are compared. Each mirror unit consists of two layers the top layer is the primary mirror and the bottom layer is the secondary mirror. Each layer is divided into quadrants, hence each mirror unit is composed of eight identical quadrants. The half power-diameter (HPD) is better than ASCA XRT by about a factor of two, which is mainly due to improved surface smoothness (section 3.2). Compared to ASCA XRT, the ratio of the focal length over the diameter is smaller, thereby incident angles of the X-rays to the mirror surface are smaller (table 3.1). This leads to better reectivity in the high energy band above 5 keV. Reective mirror surface is coated by gold for XRT-I or by platinum for XRT-S. Platinum has a higher electron density than gold, since its density (21.4 g cm 3) is higher than that of gold (19.3 g cm 3) while their atomic numbers are similar (78 and 79 for platinum and gold, respectively). Thereby XRT-S will have higher X-ray reectivity in high energies. This will compensate the shorter focal length of the XRT-S (gure 2.3), and the XRT-S and XRT-I will have comparable eective areas at the higher energies (table 3.1). ;

;

3.2 Method of Fabrication Although both ASCA and ASTRO-E mirrors employ conical aluminum substrate and gold (or platinum) surface, method of the fabrication is dierent. The ASCA mirrors are made by shaping aluminum foils into the desired conical shapes, then dipped in a \lacquer" to impart a 10m acrylic layer which smoothes surface defects on a scale of 100 m or smaller. Then a 500 A gold is vacuum deposited over the acrylic layer 2]. The focusing blurriness of ASCA XRT, HPD 3 arcmin, which is seven times the theoretical limit allowed by the conical approximation of the reecting surface, is mainly attributed to mid-frequency ( mm) surface roughness (3],4]). To circumvent this eect, \surface replication" is adopted for the fabrication of ASTRO-E XRT. In this method, by putting very thin ( 13m) epoxy layer between a rough conical aluminum substrate and a smooth \mandrel", then separating the two at the mandrel surface, characteristics of the smooth mandrels are transferred onto the mirror surface1 . A gold layer loosely adhering to the mandrel acts both as the release agent as well as the reecting surface of the replicated mirror 3]. The ASTRO-E mirror, thus made, is achieving the 2 arcmin HPD image size goal, halving 1 Instead of using pre-made substrate, the mirror substrate may be electro-formed on the mandrel. This method is used for SAX and XMM mirrors.

23

24

CHAPTER 3. X-RAY TELESCOPES (XRT)

ASCA

ASTRO-E XRT-S XRT-I Acrylic coating Surface Replication 3.5m 4.5 m 4.75 m 4 1 4 Aluminum Aluminum 127 m 155 m Au Pt Au 500 A > 1000 A Acrylic lacquer nish (10 m) Epoxy coupling layer (13 m) 120 mm 119 mm 118 mm 345 mm 400 mm 399 mm 100 mm 101.6 mm 120 168 175 0.24 -0.70 0.19 -0.63 0.18 -0.60 9.84 kg 18.0 kg 558 cm2 887 cm2 873 cm2

Production Method Focal Length Number of telescopes Substrates Substrate Thickness Reecting Surface Thickness of the Surface Other Structure Inner Diameter Outer Diameter Mirror Length No. of Foils to Nest (for one quadrant)a Primary incident angle Weight/telescope Geometry Area/telescope Filed of View 1 keV 7 keV Eective Area/telescope 1.5 keV 6 keV Half Power Diameter a: Number of foils per mirror is eight times.
















24 16

19 19

300 cm2 150 cm2 3 arcmin

450 cm2 250 cm2 < 2 arcmin

0 0

0

0

Table 3.1: Comparison of ASCA and ASTRO-E XRT. Taken from the table in 1] (p. 790). The ASTRO-E HPD value is updated based on the recent ground calibration.




ASTRO-E PDMP v1.3 (January 20, 2000)

25

the discrepancy between the ASCA XRT focusing performance and the theoretical limit allowed by the conical approximation 4].

3.3 Thermal Shield It is undesirable that the telescope cools much rapidly than the satellite body this could lead to degradation of the performance through deformation of the telescope structure, and absorption of the out-gas from the satellite on the mirror surface. Therefore, a thermal shield is put on the top of each XRT to prevents the heat from escaping through the telescope aperture. In addition, the thermal shield prevents oxygen atoms in orbit from bombarding the mirror surface. The XRT thermal shield is made of PET (C10 H8O4  Toray Lumirror 2) coated with the aluminum surface. Thickness of the thermal shield and the aluminum coating is 0.2 m and 0.03 m respectively, and their densities are 1.41 g cm 3 and 2.69 g cm 3. The thermal shield is supported by a mesh structure made of stainless wires of the 0.1 mm width. Thickness of the thermal shield is 0.15 mm and the cell size is 3mm. ;

2

The same material as Dupont Mylar.

;

26

CHAPTER 3. X-RAY TELESCOPES (XRT)

Chapter 4

X-ray Spectrometer (XRS) 4.1 XRS Instrument The ASTRO-E XRS will be the rst X-ray microcalorimeter own on an orbiting observatory 1. The X-ray microcalorimeters, the Adiabatic Demagnetization Refrigerator (ADR) and the liquid helium tank are supplied by GSFC. The solid neon tank surrounding the helium tank is built by ISAS, and the Filter Wheel (section 4.1.5) is developed at Tokyo Metropolitan University. XRS will have an unprecedented energy resolution of 10 eV (FWHM) over the 0.4 { 10 keV energy band. The eciency is nearly unity over the entire bandpass, which is about an order of magnitude better than dispersive spectrometers such as X-ray gratings.

4.1.1 Calorimeter Array

X-ray calorimeters measure energy of the incident X-ray photon by determining temperature of the absorbing material, which has to be suciently opaque to X-rays. Energy resolution of the calorimeter is higher for lower heat capacity of the absorber. In ASTRO-E XRS, mercury telluride (HgTe) was chosen as the absorber to satisfy these requirements. The calorimeter array has 2
16 pixels (gure 4.1). Each pixel size is 1.23 mm
0.32 mm and the 32 staggered pixels cover 4
2 on the sky. On each pixel, the HgTe absorber is attached on the monolithic silicon substrate in which the thermistor is ion-implanted. The thermistor changes its resistance with the temperature in the range of 10{50 mega-ohms, and as a result the temperature increase is detected as a change of the voltage across it. Signal from each thermistor is picked up by the JFET and sent to the Calorimeter Analogue Processor (CAP) (gure 4.2). CAP provides power to the detector and amplies the signals by a factor of 20,000. CAP has 32 channels, each of which handles data from a single calorimeter pixel. The detector assembly will have to be kept at 65 mK within accuracy of tens of micro-Kelvins to operate at the maximum performance. The rise time of the temperature is a few millisecond, and the total recovery time is about 80 ms, which determines the maximum counting rate of the observable sources. Beneath the calorimeter array, a silicon PIN anti-coincidence detector is put in order to detect background particles which penetrate the calorimeter array. XRS events which are simultaneously detected with the anti-coincidence detector are agged (section 4.4.1) and may be rejected in later data analysis. 0

0

4.1.2 Cryogenics and Refrigerator

The instrument is contained in the insulated dewar, which consists of nested shells. At the center of the dewar is the helium tank lled with 25 liter liquid helium whose temperature is about 1.5 Details of the XRS instrument are explained on the WWW page maintenanced by the XRS team at . Description in this chapter is largely owing to this WWW page and the XRS section in 1]. 1

http://lheawww.gsfc.nasa.gov/docs/xray/astroe/ae/xrs.html

27

28

CHAPTER 4. X-RAY SPECTROMETER (XRS)

Figure 4.1: XRS bilinear pixel conguration on the detector plane (in the DETECTOR coordinates (appendix B.1), looking up the sky). K. It is surrounded by the neon tank which is lled with 120 liter solid neon at a temperature of about 17 K. The time required for all the solid neon to completely melt determines the life-time of XRS, which is expected to be about two years. Inside the helium tank, the XRS detector assembly (named Front End Assembly { FEA) is put and thermally connected to the Adiabatic Demagnetization Refrigerator (ADR), which cools the FEA down to 65 mK. The ADR works rst by aligning the magnetic moments (electron spins) of the molecules in the salt-pill by superconducting magnet (gure 4.2). Then the salt-pill is connected to the liquid helium bath via the heat switch, allowing it to cool down to the liquid helium temperature. Once it has reached the equilibrium, the heat switch is opened, and at this point the magnetic eld is reduced to nearly zero. The spins of the salt molecules are thereby allowed to ip in random directions to reach a high entropy state (adiabatically demagnetized). The heat to increase the entropy is absorbed from the salt-pill, thus the salt-pill, and the detector, is cooled. The ASTRO-E ADR can keep the detector at the desirable temperature for 20 hours. Eventually, all the magnetic spins get completely random, and no more heat can be absorbed. Then the magnetic eld is increased again. The \recharge" of the refrigerator, typically lasting about 60 minutes2, will be performed once every 20 hours. This is called the Gross Cycle Control (GCC). The recharge process will be carried out when observing targets are occulted by the Earth so as not to interrupt the observations. The temperature is maintained at the desired level within tens of micro-Kelvins, by carefully adjusting the magnetic eld change cycles via a feedback loop. ADR is controlled by the ADR Control and Housekeeping Electronics (ACHE). ACHE cycles the ADR and control the ADR temperature at the desirable level. 2 The magnetic current is gradually increased to 2 A (ramp up), kept at that level, and gradually decreased close to the level at the normal operation(ramp down). Each process will take 20 min.

Adiabatic Demagnetization Refrigerator

Superconducting Magnet

Electrical Lead /Thermal Link

Silicon substrate /Implanted Thermistor

Attachment

X-ray Absorber (HgTe)

Dewar

Blocking Filters

Salt Pill

Figure 4.2: A schematic diagram of XRS. Ne Tank

He Tank

Heat Switch

Filter Wheel

X-rays

JFET

Master Card Master Card

DP/XRS-DE

CDP-B (16 channels)

CAP-B (16 channels)

ADR Control and Housekeeping Electronics

CDP-A (16 channels)

Calorimeter Digital Processor

CAP-A (16 channels)

Calorimeter Analog Processor

Calorimeter array, which in reallity has 32 sensors.

Filter Wheel Drive Electronics

ASTRO-E PDMP v1.3 (January 20, 2000) 29

30

CHAPTER 4. X-RAY SPECTROMETER (XRS)

4.1.3 Blocking Filters

There are ve blocking lters made of extremely thin sheets of aluminized polyimide, which are put at the entrance window of each shell of the dewar, and shield the detector from the space. They are named as, from outside to inside, DMS (Dewar Main Shell) lter, IVCS (Inner Vapor Cooled Shell) lter, Neon Filter, FEA (Front End Assembly) lter, and CTS (Calorimeter Thermal Sink) lter. CTS is the part attached to the cold end of the ADR, and the CTS lter is directly on the lid of the detector box. The blocking lters let the X-rays through to the detector, but keep out other radiations which can be a source of the heat or noise. The lter transmission determines the lowest observable energy by XRS. It is expected that XRS will have a high enough throughput down to 0.4 keV.

4.1.4 Calibration Sources

Ca and 55Fe calibration sources are attached in the detector box for the energy calibration purposes. They are expected to illuminates all the calorimeter pixels uniformly. 41 20Ca decays to 41K by electron capture and emits the K and K (3.3138 keV and 3.3111 keV) and K (3.5896 1 2 19 keV) lines3 . Line energies of 55 Fe (! 55 Mn) is 5.899 and 5.888 keV (K1 and K2) and 6.490 keV (K). XRS gain is expected to be variable, and pulse-heights of the calibration peaks will be used to create the XRS gain history les (section 11.4).

41

4.1.5 Filter Wheel

XRS has a rather large deadtime of 80 msec. Consequently, in order to observe bright sources with XRS, the X-ray ux is desirable to be reduced to avoid event pile-up. The Filter Wheel is put in front of the XRS to this end. The Filter Wheel is a circular plate made of aluminum with six windows. One window is completely open, which is the default. Two of the windows are covered with beryllium, one is 100 micron and the other is 300 micron. Three windows covered with molybdenum are for the neutral density lters, such that they are mechanically drilled to allow fractions (5 %, 10 %, and 25 %) of X-rays to go through (molybdenum is opaque to X-rays in the XRS band). Depending on the dierent source ux and spectrum, appropriate windows are chosen and put in front of the XRS. The Filter Wheel Drive Electronics (FDE) rotates the Filter Wheel using stepping motors.

4.2 On Board Data Processing 4.2.1 Outline

When an X-ray photon is detected, the microcalorimeter generates a pulse signal, which is amplied by the JFET. Furthermore, CAP amplies the signals by a factor of 20,000 so they can be transmitted to CDP (Calorimeter Digital Processor). Both CAP and CDP have two independent sides named Side-A and B. Each side has 16 channels, and the 32 channels and the detector pixels have one-to-one correspondence. There are two Master Cards in CDP for Side-A and Side-B. CDP communicates with the spacecraft Data Processor (DP/XRS-DE) through the Master Cards. The job of the CDP is to extract X-ray events from large amount of the raw signals, determine the event arrival times and energies, and send compressed event packets to the spacecraft Data Processor (DP/XRS-DE). Each channel of CDP consists of an antialiasing lter (or low-pass lter), A/D converter and Digital Signal Processor (DSP). The antialias lter cuts o the frequency above 2 kHz. DSP samples and digitizes the data at a rate of 12288 Hz with 14-bit resolution. For High Resolution mode (see the next section), 2048 samples are required to analyze a single pixel. Therefore, the amount of raw data in a single pulse is 2048 samples
14 bits/sample= 28672 bits. DSP determines the pulseheight and arrival time, and outputs the event packet along with other 3

The half life is 102,000 year.

ASTRO-E PDMP v1.3 (January 20, 2000)

31

information. A single event packet to output is 64 bits in length, which favorably compares to the amount of the raw data. Telemetry limit for XRS is 10240bits/sec for the total 32 pixels, which corresponds to 160 events/s/32 pixels, as a single event XRS consumes 64 bits. Also there is a hardware limit of the XRS counting rate, which is 50 counts/s/pixel.

4.2.2 Pulse Detection

The rst job of the DSP/CDP is to detect X-ray pulses in the data stream. To do this, DSP calculates smoothed derivative of the data. The initial pulses are detected when the derivative exceeds a xed threshold. It will be easy to detect initial pulses, but the harder part is to nd secondary pulses which might be superposed on the tails of the initial pulses. If a secondary pulse is not recognized as one, this may aect the determination of the pulse heights of the initial pulses. Hence it is important for DSP/CDP to detect secondary pulses even if they are much smaller than the initial pulses. To search for the secondary pulses, DSP/CDP compares the smoothed derivative with a template of the single-pulse derivative shape, which the CDP software maintains. The derivative shape template is subtracted from the measured derivative by scaling the peak values to form the adjusted derivative . If the adjusted derivative rises above a threshold and then falls below within a specied length of time (corresponding to the recovery time, 80 msec), the secondary pulses are detected. The secondary pulses are agged so that they can be discriminated from initial pulses (section 4.4). Once an initial pulse has been detected, CDP begins counting down the length of a Hi-resolution data record. If the pulse-height reaches zero without detecting any secondary pulses within 2048 samples (=2048/12288=167 msec), the event is agged as a Hi-res record (see next section). If a secondary pulse does occur, the initial pulse will be proceeded as either a Mid-res or Low-res event, and the counter will reset to the full Hi-res length.

4.2.3 Pulse Height Determination

It is one of the most important tasks for CDP to get the best possible estimate of the height of each pulse. The zeroth-order pulse-height is the peak value of the pulse minus the baseline value, but this is not a good measure because of noise. In order to determine the pulse height value as precisely as possible using all the samples in the pulse, optimal
ltering technique is adopted. In this technique (named Hi-res mode), noise is reduced by averaging all the samples in the pulse. The Hi-res mode is usable only when there is a single pulse in the block of 2048 samples. To create the optimal lter, time series of the average pulse (2048 samples in 167 msec) is Fourier transformed, and in the Fourier space it is divided by the power spectrum of the noise, then inverse Fourier transformed. In order to estimate accurate noise power spectrum, a relatively large number (100{200) of individual noise power spectra, each of which is made from a single noise record of 2048 samples, are running-averaged. The average pulse is made by running-averaging similar pulses which fall in a limited range on the pulse-height vs rise-time plane. The optimal ltering template in the Hi-res mode thus has 2048 samples in time space. The optimal pulse height is calculated by multiplying the data and optimal lter by sample-by-sample and adding them up. This procedure cancels out the interference of the noise component in the pulse. The above method of the pulse-height calculation in the Hi-res mode cannot be used when there are two or more events in the chunk of 2048 samples. If two pulses are closer than 2048 samples but not \too close", a shorter optimal ltering template, typically 512 samples long, is used. This method of the pulse hight calculation is called Mid-res mode (gure 4.3). In general shorter templates are less eective to determine and reject the interference of the noise at particular frequencies. If there are no noises, the Mid-res pulses will approximately give the same resolution as the Hi-res mode. When pulses are too close even for the Mid-res mode, pulse heights are determined simply measuring the heights of the peak over the baseline level this will be the Low-res mode (gure

32

CHAPTER 4. X-RAY SPECTROMETER (XRS)

LowMidSecondary Secondary

High

LowMidSecondary Secondary

Mid

LowLowSecondary Secondary

Low

142ms

t2 35.3ms

35.3ms

142ms

t1

Figure 4.3: Denition of the event grade for an event separated in time by t1 from the preceding event and by t2 from the subsequent event on the same pixel. 4.3). The baseline is measured by taking average of typically eight samples right before the start of the pulse. Each XRS event has a ag which tells either of the three methods of the pulse height determination is used (section 4.4). Hi-res event mode provides a resolution that is limited by the detector and amplier electronics, and this can be as good as 7 eV (FWHM) in laboratory. Mid-res mode provides better than 8 eV if there are no noises. The Low-res mode gives a resolution around 20 {30 eV. In gure 4.3, denition of the event grade is indicated.

4.3 XRS Telemetry Structure 4.3.1 XRS APIDs

In XRS, the last 5-bit data type ID in the APID (section 2.4.1 gure 2.6) takes the following values: The rst three bits: 000 { ACHE 001 { CAP-A 010 { CAP-B 011 { CDP-A 100 { CDP-B

The last two bits: 00 { Auto data 10 { Telecommand data (11 { Only used for the ACHE Data Memory Dump)

The Auto data continuously comes out to the telemetry responding to the autonomous request commands from DP/XRS-DE4, while the Telecommand data comes out discretely responding to particular Telecommands sent to the instruments from ground. In theory, the number of possible distinct APIDs is 30 (ve instruments and three data types science, housekeeping, memory dump], both in Auto or Telecommand forms), but in practice only the following 16 APIDs will be used for XRS: 4

Hz.

Frequency of the request commands for the science Auto data is 50 Hz, and that for the HK Auto data is 0.125

ASTRO-E PDMP v1.3 (January 20, 2000)

33

Data Type: CDP-A/B Science

Auto

APID: 00 0111 011/100 00

CDP-A/B CAP-A/B ACHE

HK HK HK

Auto Auto Auto

10 0111 011/100 00 10 0111 001/010 00 10 0111 000 00

CDP-A/B CAP-A/B ACHE

HK HK HK

Telecommand Telecommand Telecommand

10 0111 011/100 10 10 0111 001/010 10 10 0111 000 10

CDP-A/B ACHE ACHE

Memory Dump Telecommand Memory Dump (code) Telecommand Memory Dump (data) Telecommand

01 0111 011/100 10 01 0111 000 10 01 0111 000 11

4.3.2 Contents of the XRS Telemetry

The CDP science data, whose format is explained below, include the XRS event information as well as important auxiliary information regarding CDP status. All the \auto" HK streams of CDP, CAP and ACHE are output every 8 seconds. The CDP auto HK includes the anti-coincidence rates and the master status information. The CAP auto HK stream includes the CAP digital status and various voltages and temperatures from the CAP. The ACHE auto HK includes the magnet current and various temperatures from the ACHE. The telecommand HK packets for CDP, CAP and ACHE include command echoes which will show destination of the commands sent to the instruments. Each Mastercard in CDP (gure 4.2) has two kinds of ROMs, link-programmed ROM (permanent) and EEPROM (rewritable), both of which store initial programs and data to be sent to the individual processor cards. The Mastercard can be set to boot the processors from either ROMs, but EEPROM is planned to be used all of the time unless something fails, in which case the programmed ROM will be used. Contents of the EEPROM are output in the CDP Memory Dump streams when requested by a command. ACHE Memory Dump packets include the contents of the ACHE on-board memory.

4.4 CDP Science Data Structure CDP science data includes the XRS events and associated information for scientic data analysis. Unit of the CDP science data is a 64-bit \block", and there are six types of blocks PHA, Data Dump, Reply, Error, Housekeeping5 and Rates. An XRS event information makes up a single PHA block. Other types of blocks are for auxiliary information (section 4.4.2). The rst two bits of the 64-bit tells the kind of data in the packet00 for event, 01 for Data Dump, 11 for other auxiliary information. Regardless of the kinds of the data packets, the third bit tells the Side in CAP/CDP, either A (0) or B (1), and the following 4 bits tell the pixel, from 0 to 15. Meaning of the rest 57 bits depends on the block types.

4.4.1 PHA Block

The PHA block for an XRS event has a parity bit and the block has even parity.

Event Flags

If none of the following bits are set, this event is a Hi-res event. 5 This should not be confused with the housekeeping information having the separate HK APID (the rst two bits of the APID is 10).

34

CHAPTER 4. X-RAY SPECTROMETER (XRS)

 Secondary (1 bit) { This is the secondary pulse occurred on the tail of another pulse (see     

gure 4.3). Mid-res (1bit) { The short optimal ltering template is used. Lo-res (1bit) { No optimal ltering is done. Mid-res+Lo-res means the maximum number of lags was exceeded without nding a peak. baseline (1 bit) { This pulse is a baseline (noise) pulseheight. antiCo (1 bit) { The anticoincidence detector is red at the beginning of the pulse. clipped (1 bit) { The input voltage exceeded the upper limit of the A/D during this pulse.

Pulse Quality bits

The Pulse Quality is expressed with four bits and takes values from 0 to 15. This represents the mean-square dierence between the observed pulse shape and the average pulse, after scaling the average pulse to the same peak height as the measured pulse. 0 is the least error and 15 is the most.

Physical Information  Pulse Height (15 bits)  Rise Time (8 bits)  Tick Counter (4 bits) { The low 4 bits of the 32-bit tick counter. This wraps around every

16 seconds.  Time (sample count) (15 bits) { The number of samples since the last tick.  Time Vernier (4 bits) { This is the nest time division, and is only valid for hi-res and mid-res pulses. This is a signed number in the range of -8 to +7 with units of 1/16 of the sample period.

4.4.2 Auxiliary Blocks

There are ve kinds of auxiliary information Data Dump, Rates, Housekeeping, Reply, and Error. These are not output automatically, but come out to the telemetry only when requested by commands.

Data Dump

Data Dumps contain important variables related to the on-board data processing and have 14 types as shown below. Only one Data Dump type can be active at any time. A Dump message consists of many (up to several hundred) blocks. 1. Fixed length Dumps:

 Sweep-length (2048 items6) dumps: { Pulse record { Noise record { Sample record { The last 2048 samples received { Non-pulse record 6 Some of the items come from 14-bit quantities, and some from 16 bits. However, when they are expanded, they will become all 16-bit words.

ASTRO-E PDMP v1.3 (January 20, 2000)

35

{ Template { The optimal ltering template { Average pulse { The average pulse used to construct template

 Other xed-length dumps: { Short template { The short optimal ltering template for the Mid-res mode { Noise spectrum { Noise spectrum used to construct template { Input parameters { All the modiable parameters { Output parameters { All the unmodiable parameters 2. Variable-length Dumps:

 Human table { The table used for compression  CDP Memory dump7 { A memory dump of one of the 32 RAMs (corresponding to the 32 pixels), as requested by DumpMemory command  Deriv histogram { Histogram of the derivative values  RT/PH { Risetime/Pulseheight data from template generation

Rates, Housekeeping, Reply and Error

Rates are 3 blocks long and primarily give event rates for certain accumulation periods. House-

keeping messages are 3 blocks long and give mostly software status. Some of the Housekeeping information is used to tie the tick count to spacecraft time. Rates and Housekeeping blocks are output regularly at rates set by the rate interval and hk interval input parameters respectively. Reply messages are usually sent in response to a command. Error messages are generated automatically when an error is detected.

7 This should not be confused with the CDP Memory Dump stream which has the Memory Dump APID (starting with 01) and holds contents of the Mastercard EEPROM (section 4.3.2).

36

CHAPTER 4. X-RAY SPECTROMETER (XRS)

Chapter 5

X-ray Imaging Spectrometer (XIS) 5.1 XIS Hardware The XIS has four identical X-ray CCD sensors, named XIS-S0, S1, S2 and S3, each of which is combined with an X-ray Telescope for XIS (XRT-I0, XRT-I1, XRT-I2 and XRT-I3, respectively). One CCD camera has a single front-side CCD chip with 1024
1024 pixels, and covers a 18 arcmin
18 arcmin region on the sky. Each pixel is a 24 m square, and the size of the CCD is 25 mm
25 mm. The XIS is developed at MIT, Kyoto Univ., Osaka Univ. and ISAS. The XIS-Sensor and AE/TCE are made at MIT, and DE is developed in Japan. TCE (TEC Control Electronics, where TEC stands for Thermal Electric Cooler) controls the temperature of the sensors, and keeps them at around ;90 C during observations. The Analogue Electronics (AE) drives CCD clocks, reads and data from CCDs and to Digital Electronics (DE). AE and TCE are in the same housing, and thus they are called AE/TCE together. XIS has two AE/TCE AE/TCE01 takes care of XIS-S0 and S1, and AE/TCE23 takes care of XIS-S2 and S3. DE consists of two Pixel Processing Units (PPU) and one Main Processing Unit (MPU). Corresponding to the two AE/TCE, there are two PPUs, PPU01 and PPU23. PPU receives the raw data from AE, carries event detection, and sends event data to MPU. MPU edits and packets the event data, and sends them to the satellite DP. Optical Blocking Filter (OBF) is put in front of the CCD to intercept incoming optical lights. OBF is made of aluminized polyimide with a thickness of 1000 A. Each XIS sensor has an 55Fe calibration source for energy calibration purpose which illuminates a corner of the CCD chip. Installation of XIS-0 and XIS-3 on the baseplate are aligned, whereas XIS-1 and XIS2 are 90 degree rotated relative to them, in opposite directions respectively (gure 5.1). In gure 5.1, locations of the 55Fe calibration sources are also indicated. This gure also indicates the relasion between the XIS DET coordinates and ACT coordinates (appendix B.1).


5.2 On-board Data System 5.2.1 CCD Data Transfer

Figure 5.2 describes a schematic view of each XIS on-board system. X-rays focused by XRT are accumulated at the Exposure Area for a certain exposure period, and the data are transfered to the Frame Store Area after each exposure. Data stored at the Frame Store Area are read-out sequentially by AE, and sent to PPU. The data are put into the memory named Pixel RAM in PPU. A single XIS CCD chip consists of four Segments (marked A, B, C and D in gure 5.2) and correspondingly has four separate read-out gates. Pixel data on each Segment are read-out from the corresponding read-out gate and sent to the Pixel RAM. In the Pixel RAM, pixels are given RAWX and RAWY coordinates for each Segment in the order of the read-out, such that RAWX 37

38

CHAPTER 5. X-RAY IMAGING SPECTROMETER (XIS) ACTX

ACTY

ACTX

A ACTY

B A

B

C

ACTX

ACTY

A ACTX

D

XIS-0 DETX

C

D C

DETY

D

XIS-1

B

C

D

B A

ACTY

XIS-2

XIS-3

Figure 5.1: Conguration of the XIS sensors in the DETECTOR coordinates (looking up the sky). Note that XIS-0 and XIS-3 installations are aligned, whereas XIS-1 and XIS2 are 90 degree rotated relative to them, in opposite directions respectively. Characters \A" to \D" indicate the Segment ID, and corner areas to expect 55Fe calibration source photons are indicated with the fan-shaped shades. Segment A of XIS-3 has a hardware problem, and may not be usable for observations. values are from 0 to 255 and RAWY values are from 0 to 1023. These physical pixels are named Active pixels. In the same Segment, pixels closer to the read-out gate are read-out earlier and stored in the Pixel RAM earlier. Hence, the order of the pixel read-out is the same for the Segment A and C, and for the Segment B and D, but dierent between these two Segment pairs, because of the dierent locations of the read-out gates. In gure 5.2, numbers 1, 2, 3 and 4 marked on each Segment and Pixel RAM indicate order of the pixel read-out and the storage to the Pixel RAM. In addition to the Active pixels, Pixel RAM stores the Copied pixels, Dummy pixels and HOver-Clocked pixels (gure 5.2). At the borders between two Segments, two columns of pixels are copied from each Segment to the other. Thus these are named Coped pixels. On both sides of the outer Segments, two columns of empty Dummy Pixels are attached. In addition, 16 columns of H-Over-Clocked pixels are attached to each Segment. Actual pixel locations on the chip are calculated from the RAW XY coordinates and the Segment ID. The coordinates to describe the actual pixel location on the chip are named ACT X and ACT Y coordinates (gure 5.2 see also appendix B.1).

5.2.2 Pulse Height Determination

When a CCD pixel receives an X-ray photon, the X-ray is converted to an electric pulse, whose pulse-height is proportional to the X-ray energy. In order to determine the true pulse-height corresponding to the input X-ray energy, it is necessary to subtract Dark Levels and correct possible optical light leaks. Dark Levels are non-zero pixel pulse-heights caused by dark currents of CCDs when there are no input signals. In the case of ASCA SIS, dark levels of a large number of pixels were sampled and their average was calculated for every exposure. Then the same average Dark Level was used to determine the pulse-height of each pixel in the sample. After the launch of ASCA, it was found that the Dark Levels of dierent pixels are actually dierent, and its distribution around the average does not necessarily follow the Gaussian. The non-Gaussian distribution has evolved with time (referred to as Residual Dark-current Distribution or RDD), and resulted in degradation of energy resolutions due to wrong Dark Levels. To avoid the RDD problem, Dark Levels are determined for every pixel in the case of ASTRO-E XIS. PPU calculates the Dark Levels in the Dark Initial mode (section 5.3.3), and they are stored in the Dark Level RAM. Dark data are taken with the Dark Initial modes, and the number of the frames can be chosen from 4, 8, 16 and 32. The average Dark Level is determined for each pixel, and if the dark level is higher than the hot-pixel threshold, this pixel is determined as a hot pixel (section 5.2.4). Dark Levels can be updated by the Dark Update mode, and sent to the telemetry

ASTRO-E PDMP v1.3 (January 20, 2000)

39 XIS-Sensor

1024 pixels

A

B

C

1024 pixels

Exposure Area (no physical boundaries between segments)

D

Act Y

XIS-AE/TCE

Act X control temperature drive CCD read-out data send data to DE

256 256 pixels pixels

256 256 pixels pixels

256 or 64 pixels

Optional Window

Read-out gates

3 1

4 2

4 2

3 1

3 1

4 2

4 2

1024 pixels

Frame Store Area

Read-out gates

3 1

Read-out (through AE)

Satellite Data Processor (DP)

XIS-DE

1

2

1

2

1

2

1

2

3

4

3

4

3

4

3

4

H-OverClocked Pixels (16 columns) Memory (Pixel RAM)

Raw Y (0-1023)

Active Pixels (256 columns)

Active Pixels (256 columns)

Active Pixels (256 columns)

Active Pixels (256 columns) Event Detection

Raw X

Dummy pixels (two columns)

Raw X

Raw X

Raw X

Dummy pixels (two columns) Copied Pixels (two columns)

Data Edit Main Processing Unit (MPU)

Event RAM Pixel Processing Unit (PPU)

Figure 5.2: A schematic diagram of the XIS on-board data system and the data transfer for one CCD. In practice, there are four CCD sensors (XIS-S0 to S3), two AE/TCUs (AE/TCE01 and 23 )and two PPUs (PPU01 and PPU23). Each AE/TCU takes care of two CCDs, so does each PPU. XIS-DE consists of two PPUs and one MPU. See section 5.1 and 5.2 for details.

40

CHAPTER 5. X-RAY IMAGING SPECTROMETER (XIS)

by the Dark Frame mode (section 5.3.3). Unlike ASCA, Dark Levels are not determined for every exposure, but the same Dark Levels are used for many exposures unless they are initialized or updated. When there are optical-light leaks in the sensor, CCDs may receive optical photons and produce pseudo pulse-heights which are not related to X-rays. PPU estimates amounts of the optical-light leaks and correct them when the pixel pulse-heights are determined.

5.2.3 On-board Event Analysis

PPU carries out event analysis on all the 5
5 square pixel groups (for Normal Clock mode) or three horizontal pixel groups (for Parallel Sum Clock mode) for each Segment (see section 5.3.1 for Clock modes). The Copied pixels and Dummy pixels are made so that the event analysis is enabled on the pixels at the edges of each Segment.1 When an X-ray photon is absorbed in a pixel, the photoionized electrons can spread exceeding the pixel size, hence pulse-heights may be detected not only from that pixel but also from adjacent two or more pixels. An event is recognized when the pulse-height of the central pixel among the 3
3 square pixels (or 3 horizontal pixels for Parallel Sum Clock mode) is the highest and between the Event Lower Threshold and Upper Threshold. The RAW XY coordinates of the central pixel are considered as the event location. Pulse-heights of the adjacent 5
5 square pixels (or 3 horizontal pixels) are analyzed, and the pulse-height information (which depends on the Editing mode) is sent to the Event RAM as well as the pixel location. For example, all the 25 pulse-heights are sent to the telemetry in the 5
5 mode. On the other hand, in the 3
3 or 2
2 modes, only the ags which tell if pulse-heights of the outer pixels exceed some threshold or not is output. Inner Split Threshold is used for the central 3
3 pixels and Outer Split Threshold is used for the surrounding 16 (3
3 mode) or 8 (2
2 mode) pixels. See sections 5.3.3 and 5.4.1 for details.

5.2.4 Hot Pixels

Hot pixels are pixels which always output high enough pulse-heights even without input signals. Hot pixels are not usable for observation, and have to be removed for scientic analysis. In the case of ASCA SIS, hot pixels are not identied on-board, and all the hot pixel data are telemetered they are removed during data analysis procedure. Number of hot pixels has increased with time, and eventually occupied signicant parts of the telemetry. In the case of ASTRO-E XIS, hot pixels are detected on-board by Dark Initial mode, and their positions and pulse-heights are stored in the Hot-pixel RAM and sent to the telemetry. Thus, hot pixels can be recognized on-board, and it is possible to specify by command not to send hot pixel events to the telemetry. It is also possible to specify to output hot pixel events, if necessary.

5.3 Data Processing Modes There are two dierent kinds of XIS on-board data processing modes. The Clock modes describe how the CCD clocks are driven, and determine the exposure times and time resolutions. The Clock modes are determined by the AE. The Editing modes specify how detected events are edited, and determine the formats of the XIS data telemetry. Editing modes are determined by the DE. Note that the four XIS sensors operate separately. Therefore it is possible to choose dierent Clock and/or Edit modes for dierent sensors.

5.3.1 Clock Modes  Normal Mode

If Window option (see below) is not specied, exposure time is 8 seconds, and all the pixels on the CCD are read out every 8 seconds. This can be combined with either of the 5
5,

1 In the case of Parallel Sum Clock mode, only inner one of the two columns of Copied or Dummy pixels on each side of the Segment is necessary and used.

ASTRO-E PDMP v1.3 (January 20, 2000)

41

3
3, and 2
2 Editing modes.

 Parallel Sum Mode

Pixel data from plural rows are combined in the Y-direction, and the sum is put in the Pixel RAM as a single row. Number of rows to combine is chosen by command from 64, 128 and 256. Parallel Sum mode can be used only with the Timing Editing mode (see below), and the Y coordinate is used to determine the event arrival time. No spatial resolution in the Y-direction. Time resolution is 7.8125 msec.

5.3.2 Window and Burst option

For the Normal Clock mode, Window and Burst option can modify the eective area and exposure time, respectively. The two options are independent, and may be used simultaneously. These options cannot be used with the Parallel Sum Clock mode.  Burst Option All the pixels are read out every 8 seconds (if Window option is not specied), but exposure time can be chosen arbitrarily (with 1/32 second step) within the read-out interval. This option may be used to avoid the event pile-up when observing bright sources. The burst option introduces a dead time every 8 sec. For example, if the exposure is t sec, the dead time will be about 8-t sec.  Window Option This option allows shorter exposure times using only a part of CCD to expose. Only a part of the chip in the Y-direction specied by the commandable Window is used for exposure (gure 5.2). The Window width in the Y-direction is either 256, 128 or 64 pixels, and its position is arbitrary. When the Window width is 256 pixels, the exposure time becomes a quarter of that without the Window option, and the Pixel RAM is lled with the data from four successive exposures. Similarly, when the Window width is 128 or 64 pixels, the exposure time becomes 1/8 or 1/16 of that without the Window option respectively, and the Pixel RAM is lled with the data from 8 or 16 successive exposures. The following table indicates how the eective area and exposure time are modied by the Burst and Window options. Normal Mode Burst Option without options Eective Nominal Nominal Area (25
25 mm2) Exposure Time

8 sec

#

Window Option

# (1/4,1/8 or 1/16) 2 sec
4 exposures, 1 sec
8 exposures 0.5 sec
16 exposures

Burst & Window

# #

5.3.3 Editing Modes Observation Modes  5
5 mode

All the pulse heights of the 25 pixels centering at the event center are sent to the telemetry. This is used with the Normal Clock mode.  3
3 mode Pulse heights of the 9 pixels centering at the event center are sent to the telemetry with other information on the event distribution (see section 5.4.1). This is used with the Normal Clock mode.

42

CHAPTER 5. X-RAY IMAGING SPECTROMETER (XIS)

 2
2 mode

Pixel heights of the 2
2 square pixels which includes the center pixel are sent to the telemetry with other information on the event distribution (see section 5.4.1). This is used with the Normal Clock mode.  Timing mode Pulse heights of the three pixels in the X-direction are summed if they are over the Inner Split Threshold, and sent to the telemetry. In addition, Grades of the events are determined and output. This is used only with the Parallel Sum Clock mode. Window and Burst Options are not available in the Timing mode.

Diagnostic Modes  Dark Initial mode

Determine the initial Dark Levels of all the pixels, and store them in the Dark Level RAM. After the initialization, addresses and pixel-levels of the hot pixels are sent to the telemetry. This mode can be used with either Normal Clock mode (with or without Burst and Window options) or Parallel Sum Clock mode.  Dark Update mode Update the Dark Levels of all the pixels in the Dark Level RAM. After the update, addresses and pixel-levels of the hot pixels are sent to the telemetry. This mode can be used only with Normal Clock mode (with or without Burst and Window options).  Frame mode Pixel levels of all the pixels in the Pixel RAM are dumped to the telemetry. The exposure time is commandable and either of 8 sec, 32 sec and 128 sec. This mode can be used with either Normal Clock mode (with or without Burst and Window options) or Parallel Sum Clock mode.  Dark Frame mode Dark Levels are output and sent to the telemetry. This mode works independently of the Clock modes.

5.4 Event and Telemetry Structure 5.4.1 Observation Modes

The event information and the size of a single event for each observation mode are summarized below. The event sizes are those appeared in the telemetry after the data compression by MPU. Note that RAWX value is from 0 to 255 (8 bits), and RAWY value is from 0 to 1023 (10 bits), since events are processed individually for each Segment. The pixel-level (pulse-height) takes values from 0 to 4095, thus it can be expressed in 12 bits. However, MPU may also use 8 or 16 bits for pixel-levels (byte compression) depending on the pixel-level values.

5
5 Mode

The event size is variable from 28 bytes to 52 bytes in length, depending on the pixel-level values.  RAWX (8 bits) and RAWY (10 bits) Raw XY coordinates of the center pixel of the event.  25 Pixel Levels (12 bits for the central pixel and 8 or 16 bits for the rest) Pulse-heights of the 5
5 pixels centering at the event center pixel. The central pixel level is output as it is, and the rests will be output after byte compression.

ASTRO-E PDMP v1.3 (January 20, 2000)

43

3
3 Mode

The event size is variable from 15 bytes to 23 bytes in length, depending on the pixel-level values.

 RAWX (8 bits) and RAWY (10 bits)

Raw XY coordinates of the center pixel of the event.  9 Pixel Levels (12 bits for the central pixel and 8 or 16 bits for the rest) Pulse-heights of the 3
3 pixels centering at the event center pixel. The central pixel level is output as it is, and the rests will be output after byte compression.  pOuterMost (16 bits) A 16 bit pattern which tells which pixels among the Outermost Pixels exceed the Outer Split Threshold. The Outermost Pixels are the 16 pixels surrounding the central 3
3 pixels (gure 5.3).  sumOuterMost (10 bits) Sum of the pixel-levels among the 16 Outermost Pixels which do not exceed the outer-split threshold2 . The lowest 10 bits are output.

2
2 Mode

The event size is variable from 8 bytes to 11 bytes in length, depending on the pixel-level values.

 RAWX (8 bits) and RAWY (10 bits)

Raw XY coordinates of the center pixel of the event.  4 Pixel Levels (12 bits for the central pixel and 8 or 16 bits for the rest) The central pixel level is output as it is, and the rest three pixel levels will be output after byte compression. The 2
2 pixels whose pixel heights are output are determined as follows (gure 5.3): 1. Among the four pixels which are contiguous to the center pixel, choose the pixel which has the highest pulse height. 2. Discard the pixel which is in the opposite side of the pixel chosen above. From the remaining two pixels, choose the one which has the higher pulse height. 3. Determine the 2
2 pixel region which includes the center pixel and the two pixels chosen by the procedure above.

 2x2pos (2 bits)

Indicates relative location of the 2
2 pixel region within the 3
3 region centering at the event. See gure 5.3 for the denition.  pAdjacent (8 bits) A 8 bit pattern which tells which of the eight Adjacent pixels exceeds the Outer Split Threshold. See gure 5.3 for the denition of the Adjacent pixels.

Timing Mode

A single event is 4 bytes in length.  RAWX (8 bits) and RAWY (10 bits) Raw XY coordinates of the center pixel of the event. The event is searched for in the three contiguous pixels parallel to the RAWX direction. 2 This is mainly used to correct the DFE level, so those which do not exceed the threshold are more important than those which do exceed.

44

CHAPTER 5. X-RAY IMAGING SPECTROMETER (XIS)

E

Outermost Pixels

3

2

2

1

1 E 2 4

3 E 4 1

4 E 3 1

4 E 2 3

2

3

4

3

1 E 3 4

1 E 4 2

3 E 2 1

2 E 1 4

V-address

H-address

E

E

E

E

2x2pos=0

2x2pos=1

2x2pos=2

2x2pos=3

Figure 5.3: Top Left: Denitions of the Outermost Pixels for the 3
3 mode. The pixel marked with 'E' is the event center. Top Right: Some examples of the 2
2 pixel region in the 2
2 mode. Numbers on the pixels indicate order of the pulse heights among the four pixels attached to the center. Bottom: Denition of the Adjacent pixels and the 2x2pos ag for the 2
2 mode. The 2
2 pixel region is dark-shaded, and the eight Adjacent pixels are light-shaded.

 One Pixel Level (12 bits)

Sum of the pixel levels from the center pixel and other pixels which exceed the Inner Split Threshold.  Grade (2 bits) Either of 0, 1, 2 and 3, which tells the split pattern of the event among the three horizontal pixels. Grade 0 is the single event (no split), grade 1 and 2 are the leading and trailing split events respectively, in which either of the leading or trailing pixel exceeds the Inner Split Threshold. Grade 3 means the double split in which both leading and trailing pixels exceed the Inner Split Threshold.

5.4.2 Diagnostic Modes

Dark Initial Mode and Dark Update Mode

When these modes are invoked, the positions and pulse-heights of all the hot-pixels are output only once, and the mode returns to the previous observation mode. Each hot-pixel information is 5 bytes in length.  RAWX (9 bits) and RAWY (10 bits) of hot pixels Addresses of the hot pixels. RAWX coordinates of the hot pixels can be from 0 to 259 in the Normal Clock mode, since hot pixels may be on the Copied and Dummy pixels. Hence 9 bits are used. In the Parallel Sum Clock mode, the RAWX coordinates of the hot pixels are from 0 to 257 (see footnote on page 40).  Pulse Height (16 bits) Raw pulse height of the hot pixel.

ASTRO-E PDMP v1.3 (January 20, 2000)

45

Frame Mode  Raw Frame Data

Pixel levels of all the pixels in the Pixel RAM are dumped. These pixels consist of Active pixels, Copied pixels, Dummy pixels and H-Over-Clocked pixels. Therefore total number of the pixels in the Pixel RAM is (2 + 256 + 2 + 16)
1024=282,624 pixels per segment (gure 5.2).

Dark Frame Mode  Dark Level

Dark Levels stored in the Dark Level RAM for all the pixels are output. Both Dark Levels for the Normal mode (260 rows
1024 lines) and Parallel Sum mode (258 rows
1 line) are output. Note that Dark Levels exist not only for the Active pixels but also for the Copied and Dummy pixels.

5.4.3 XIS APID

Dierent kinds of the XIS data have dierent APID (section 2.4). Note that the subsystem ID (the third to sixth bits) is 1000 for XIS. Following APID values are used for XIS. Data Type: XIS HK

APID: 10 1000 00000 10 1000 00001 ... 10 1000 11111

XIS Memory Dump

01 1000 00000 01 1000 00001 ... 01 1000 01111

XIS Observation Data 00 1000 00000 00 1000 00001 00 1000 00010 00 1000 00011 00 1000 00100 00 1000 00101 ... 00 1000 01110 00 1000 01111 XIS I/O Dump, PPU Memory Dump, AE Read Data

00 1000 10000 00 1000 10001 ... 00 1000 11100

XIS0, Segment A XIS0, Segment B XIS0, Segment C XIS0, Segment D XIS1, Segment A XIS1, Segment B XIS3, Segment C XIS3, Segment D

46

CHAPTER 5. X-RAY IMAGING SPECTROMETER (XIS)

Chapter 6

Hard X-ray Detector (HXD) 6.1 Sensor The ASTRO-E Hard X-ray Detector (HXD) covers the wide energy band of 10 { 700 keV in combination of the GSO well-type phoswich counters (> 50 keV) and the silicon PIN diodes (< 50 keV). The HXD is characterized by the low background of 10 5 cts/s/cm2 /keV, which has made the HXD the most sensitive instrument ever in this energy range. The nominal FWHM spectral resolution of HXD is 9 % (at 662 keV) to 30 % (at 10 keV). The HXD is jointly developed at University of Tokyo, ISAS, RIKEN, and National Laboratory for High Energy Physics (KEK). Find references 5] and 6] for details of the HXD. ;

6.1.1 BGO Shields Figure 6.1 shows schematic views of the HXD assembly. The total weight of the assembly will be 200 kg including the electronic part (not shown in the gure). The HXD consists of 4
4=16 identical detector units. The ve sides of the detector are completely covered by the thick BGO background shield 20 anti-counters surround the four sides, and the bottom of each unit is also made of BGO. The anti-counters will be used not only to reject background, but also to observe persistent and transient hard X-ray/
-ray sources (section 6.4).

6.1.2 GSO Sensors Each detector unit is furthermore divided into four deep wells by the BGO active shields. The detector does not have imaging capability, and the eld of view is limited to 4:3
4:3 by the well having the 320 mm depth and 25 mm
25 mm area. At the bottom of each well, a GSO crystal, which deposits X/
-rays above 50 keV, is glued on BGO. The size of each GSO crystal is 24 mm
24 mm and the thickness is 5 mm. Those events which are detected by the GSO but not by the surrounding or underlying BGO are considered good X/
-ray events (\clean hit" events). The GSO scintillator emits optical lights when they absorbed X/
-ray photons. The optical lights are detected by photo-multiplier attached below the bottom BGO part of each well-detector, and signals are read through the pre-ampliers (gure 6.1). Total photon collecting area by GSO is 330 cm2.





6.1.3 PIN Diodes On the GSO crystal, two layers of the PIN diodes, which are sensitive to X-rays between 10 and 50 keV, are put. Each layer has the 2 mm thickness and the 20 mm
20 mm area. HXD carries 128 PIN diodes in total, achieving the photon collecting area 230 cm2. 47

48

CHAPTER 6. HARD X-RAY DETECTOR (HXD) Well Unit

Passive Fine Collimator

Side Anti Unit

Corner Anti Unit

BGO

32cm

38cm

34cm PIN GSO

34cm Photomultiplier + pre-Amplifier 34cm

Figure 6.1: The HXD assembly cross-section and the top-view. The housing and electronics part are not shown.

6.1.4 Passive Fine Collimaters

Inside of each well, passive ne collimaters made of phosphor bronze sheet (50 m thick) are placed to limit the eld of view for soft X-rays (< 100 keV) down to 17
17 arcmin2. This eld of view is comparable to those of XRS and XIS. The ne collimaters are also expected to reduce the cosmic diuse X-ray background, which otherwise might be a signicant background source for the PIN diodes.

6.2 Electronics The on-board electronics consists of the HXD-AE (Analog Electronics) and HXD-DE (Digital Electronics) (gure6.2).

6.2.1 HXD-AE

HXD-AE consists of the Analog Control Unit (ACU), Well Processing Units (WPU) and Transient Processing Units (TPU). There are four WPU boards (WPU0-3) and four TPU boards (TPU0-3). Each WPU handles PMT and PIN events from adjacent four well-counters. Each TPU processes events detected by adjacent ve anti-counters (gure 6.3). ACU supplies high voltage to AE, and collects housekeeping data such as voltage and temperature and sends them to DE.

6.2.2 HXD-DE

HXD-DE receives signals from HXD-AE, edits them into the CCSDS packets (section 2.4), and sends them to the satellite DP. Also, DE received commands from DP through Peripheral Interface Module (PIM) and sends them to AE.

ASTRO-E PDMP v1.3 (January 20, 2000)

49 128kbps

Sensor Signal Well type phowich W00 Well type phowich W01 Well type phowich W02 Well type phowich W03 HV-W0 HV-P0 Well type phowich W10 Well type phowich W11 Well type phowich W12 Well type phowich W13 HV-W1 HV-P1 Well type phowich W20 Well type phowich W21 Well type phowich W22 Well type phowich W23 HV-W2 HV-P2 Well type phowich W30 Well type phowich W31 Well type phowich W32 Well type phowich W33 HV-W3 HV-P3

WPU adapter #0

CPU Module

WPU0 Sensor Power

#1

Sensor Signal

Command I/F adaptor

#2

WPU1 Sensor Power

#3

Telemetry I/F adaptor

Sensor Signal

WPU2 Sensor Power

DP I/F adaptor Sensor Signal

System Bus

WPU3 Sensor Power

TPU adapter Sensor Signal BGO Anti Counter T00 BGO Anti Counter T01 BGO Anti Counter T02 BGO Anti Counter T03 BGO Anti Counter T04 HV-T0 BGO Anti Counter T10 BGO Anti Counter T11 BGO Anti Counter T12 BGO Anti Counter T13 BGO Anti Counter T14

#0

TPU0 #1

Sensor Power Sensor Signal

#2

TPU1 #3

Sensor Power

HV-T1 BGO Anti Counter T20 BGO Anti Counter T21 BGO Anti Counter T22 BGO Anti Counter T23 BGO Anti Counter T24 HV-T2 BGO Anti Counter T30 BGO Anti Counter T31 BGO Anti Counter T32 BGO Anti Counter T33 BGO Anti Counter T34 HV-T3

Sensor Signal

TPU2 Sensor Power Sensor Signal

TPU3 Sensor Power WPU/TPU Power Control Data Time

HV Unit Power HV Monitor

ACU

ACU adapter

Status

Sensor Calibration Control Signal Temperature

HXD-S

HXD-AE

HXD-DE

Figure 6.2: HXD-sensor, HXD-AE and HXD-DE on-board data processing system diagram.

50

CHAPTER 6. HARD X-RAY DETECTOR (HXD) TPU0

WPU1

WPU0

T00

T01

T02

T03

T33

W00

W01

W10

W11

T10

T32

W03

W02

W13

W12

T11

T31

W30

W31

W20

W21

T12

T30

W33

W32

W23 W22

T13

T23

T22

T34 TPU3

T24

T21

T20

T04

TPU1

T14

P0 P1 P3 P2

PIN 構成

TPU2

WPU3

WPU2

Figure 6.3: Identication for each segment of the HXD-sensor, and the processing units to process individual parts.

6.3 On-board Data Processing 6.3.1 Pulse Shape Discrimination

The point of using two dierent types of scintillators for the active shield (BGO) and X/
-ray sensors (GSO) is that they have dierent decay times for uorescence: 353 ns for BGO and 86 ns for GSO. Each well-detector detects signals from both GSO (mostly X/
-ray events) and BGO (mostly background events) with the same photo-multiplier and pre-amplier, but the two types of events can be discriminated by the dierence of the pulse decay time. The same signal is shaped in WPU by two ampliers with dierent shaping times. Thus two pulse-heights are obtained from a single event: \Fast" pulse-heights and \Slow" pulse-heights. The Pulse Shape Discriminater (PSD), a semi-custom made LSI chip, carries out the discrimination of the two pulse-heights. On the two-dimensional Fast vs Slow pulse-heights plane, the GSO events, in which most celestial X-ray/
-ray events are included, can be separated from the BGO events and other background events (gure 6.4).

6.3.2 Anti Coincidence

The 20 BGO anti-counters surrounding the GSO well-detectors are used to monitor the \hit pattern" of the event. TPU continuously monitors the signals from the anti-counters, and tells WPU if each anti-counter detected an event simultaneously with one of the well-detector. The hit pattern is recorded and telemetered for each WPU event (section 6.5.2), and used to select pure X-ray/
-ray events in the data analysis (section 6.3.4).

6.3.3 Pseudo Event

ACU generates \Pseudo events" to be used for deadtime correction at a regular rate which is variable by command. The Pseudo events are processed equally as the real GSO events, except the Pseudo events have the ag to be identied so (section 6.5.2). The real counting rate of a target

ASTRO-E PDMP v1.3 (January 20, 2000)

51

7

7

6

6 ts

SO

t.

at

m

Co

re

3

re

fast trig. cutoff

G

pu

4

3

1

---

1

ev

2

---

2

SO

G

pu

pu re B

GO

4

sc

en

5 Slow (Volt)

ev en ts

n

o pt

ev

---

Slow (Volt)

ts

en

5

0

0

1

2

3 . FAST

4 (Volt)

5

6

7

0

0

1

2

3

4

5

6

7

. (Volt) FAST

Figure 6.4: An example of the Pulse Shape Discrimination based on the dierence between the decay times of GSO (for X-rays/
-rays) and BGO (background shield) scintillators. may be estimated with the following formula:
Number of produced P seudo events Real Counting Rate  Number of detected Pseudo events
Observed Counting Rate:

6.3.4 PI Program

Complex on-board data processing is handled by a set of C-functions named PI program. PI program carries out the following tasks for the WPU data processing:  Accumulate 2-d histograms on the Fast/Slow diagram On the Fast/Slow diagram (gure 6.4), 2-dimensional histograms are accumulated. The histograms may be made for either 16
16 regions for the 16 units or 64
64 regions for a single unit. Accumulation time can be chosen.  Event selection on the Fast/Slow diagram On the Fast/Slow diagram, a trapezoidal region is specied for the event selection. Minimum and maximum Fast values of the allowed region, and for each of them, the lowest and highest Slow values are specied.  t cut Continuous events whose intervals are less than the preset t value are rejected. This is to avoid continuous triggers which may be caused be high-Z cosmic rays.  Hit-pattern Anticoincidence with other WPU or TPU is checked, and only \clean hit' events are selected (section 6.1.2).  Check trigger pattern, ag pattern Trigger patterns and ag patterns are checked, and only events which coincide with some particular patterns may be selected or rejected.

52

CHAPTER 6. HARD X-RAY DETECTOR (HXD)

Mode 1 2 3 4

TH PH Burst memory coverage 1/64 s 1/2 s 64 sec (pre 8s/post 56s) 1/32 s 1 s 128 sec (pre 16s/post 112s) 1/16 s 2 s 256 sec (pre 32s/post 224s) 1/8 s 4 s 512 sec (pre 64s/post 448s)

Table 6.1: Time resolution of the TPU TH (Time History) and PH (Pulseheight History) data for dierent modes. Mode 2 is the default.

6.4 TPU Observations Besides the primary purpose of the background rejection, TPU data from the anti-counters, in conjunction with the WPU data from the bottom BGO part of the well-detectors, can be used for scientic observations too. Each TPU board combines and accumulates events from the ve anti-counters, and produces two kinds of the histograms named TH (Time History) and PH (Pulse-height History) from the same data. TH has a shorter accumulation time with 4 pulse-height channels, whereas PH has a longer accumulation time with 64 pulse-height resolutions. Time resolution of the TH and PH can be variable as shown in table 6.1.

6.4.1 Transient data The PH histograms from each board are continuously output to the telemetry. This is named the \Transient data" (section 6.5.4). Transient data (contrary to the name) may be used to monitor the persistent hard X-ray/gamma-ray sources (section 6.4.3).

6.4.2 Gamma-ray burst data Each TPU board has a ring buer of a capacity of 64 kbytes on which TH data and PH data are continuously recorded. The ring buer can store the latest 128 sets of the PH histograms and 4096 sets of the TH histograms the actual durations of the data stored in the ring buer are variable, as shown in table 6.1. The TH stream is continuously monitored by a gamma-ray burst determination circuit, which ags when a gamma-ray burst(-like) event is detected. When the gamma-ray burst is triggered, the ring buer is frozen, and the TH and PH data shortly before and after the burst trigger are kept (table 6.1). The gamma-ray burst data are sent to the DP (then to DR) when HXD pauses normal operation such as during SAA (section 6.5.4).

6.4.3 Position determination Although each unit of the anti-counters does not constrain the photon arrival direction, crude direction of a celestial source may be determined if one can compare the numbers of the source photons detected by the orthogonal groups of the detectors. This position determination method will be feasible for the Gamma-ray burst data, since there will be virtually a single outstanding source at a time. Position determination of persistent sources in the Transient data will be more problematic, since multiple sources are observed simultaneously. It is planned to apply the earth occultation technique similar to what has been adopted by BATSE to separate and identify the individual persistent sources in the Transient data.

6.5. HXD TELEMETRY STRUCTURE

53

6.5 HXD Telemetry Structure 6.5.1 HXD APID The HXD telemetry data comprises the HK data, WPU main data, WPU sub data, TPU data, status packets, and memory dump packets. They are distinguished with dierent APIDs as follows (section 2.4.1). Note that the VCID of HXD is 05h (real data) or 25h (reproduced data), and third to sixth bits of APID is 1001 for HXD. Instrument: data type: WPU Well Main data

Meaning: WPU-0 Event WPU-1 Event WPU-2 Event WPU-3 Event

APID: 00 1001 10000 (130h) 00 1001 10001 (131h) 00 1001 10010 (132h) 00 1001 10011 (133h)

WPU

Monitor data

Scalar

00 1001 00100 (124h)

WPU WPU WPU

Well Event Histogram Coarse Well Event Histogram Fine Well Event Histogram Reserve

00 1001 01001 (129h) 00 1001 01010 (12Ah) 00 1001 01011-01110 (12Bh-12Eh)

TPU

Transient data

00 1001 00010 (122h)

TPU

Gamma-ray burst

00 1001 00110 (126h)

HK data

DHU HK data HXD HK data ROM mode HK data

01 0001 00000 (220h) VCID=1 10 1001 00000 (520h) VCID=2 10 1001 10000 (530h) VCID=2

Status

DE System Status ACU-HK data PI program Status

00 1001 00001 (121h) 00 1001 00011 (123h) 00 1001 00101 (125h)

Dump data I/O dump ECC dump AE parameter dump ROM mode I/O dump ROM mode ECC dump Memory dump

00 1001 11001 (139h) 00 1001 11010 (13Ah) 00 1001 11011 (13Bh) 00 1001 11101 (13Dh) 00 1001 11110 (13Eh) 01 1001 11000 (338h)

6.5.2 WPU main data Either PMT, PIN or Pseudo events trigger the data acquisition system of WPU. When a trigger is issued, the analog outputs of the corresponding phoswich unit, Slow shaper, Fast shaper, and the four diode shapers, are digitized. Then a single WPU event is recorded and output as a 128 bit length record. WPU events from each board have separate APID as shown above. Explanations of the WPU event record are the following:

 Length Check (1 bit) { A ag to tell if the event record has the correct length. Should be always 1, unless DE found the data length is wrong when the bit is ipped to 0.

54

CHAPTER 6. HARD X-RAY DETECTOR (HXD)

 Event time (19 bits) { Arrival time of the event measured with either 122 (Normal mode),                

61.0 (Fine mode) or 30.5 (Super-ne mode)  sec tick1. The Fine mode will be used as default. PIN Peak Hold Status (1 bit) { Tells if the PIN pulse height peak is correctly held (1) or not (0). This ag should be On (1) for a good event. PIN Double Trigger (1 bit) { During a process of an event, if another event is detected, this ag becomes On (1). Those \double events" may be removed in the data screening process later. PIN UD (1 bit) { Tells if the PIN upper discriminater is hit (1) or not (0). Channel ID (2 bits) { ID of the sensor (0 to 3) within the WPU. Note that WPU ID is not output explicitly, since this is known from the APID. Trigger Pattern (6 bits) { The six bits correspond to the PMT anode (1 bit), four PIN sensors (4 bits) and Pseudo trigger (1 bit section 6.3.3). Each bit tells if the trigger is made by the corresponding sensor (1) or not (0). PMT Peak Hold Status (1 bit) { Tells if the PMT pulse height peak is correctly held (1) or not (0). This ag should be On (1) for a good event. PMT Double Trigger (1 bit) { During a process of an event, if another event is detected, this ag becomes On (1). Those \double events" may be removed in the data screening process later. PMT UD (1 bit) { Tells if the PMT upper discriminater is hit (1) or not (0). PSD (1 bit) Out { Output of the Pulse Shape Discriminater (PSD): 1 for a GSO event, 0 for a BGO event. Hit Pattern (36 bits) { Each bit tells if each of the 36 detectors (16 sensors and 20 anticounters) detected this event (1) or not (0). PMT Fast Pulse Height (12 bits) { PMT pulse height with Fast shaping time. PMT Slow Pulse Height (12 bits) { PMT pulse height with Slow shaping time. PIN0 (8 bits) { Pulse height of PIN0. PIN1 (8 bits) { Pulse height of PIN1. PIN2 (8 bits) { Pulse height of PIN2. PIN3 (8 bits) { Pulse height of PIN3.

6.5.3 WPU sub data Well monitor data

The \Scalar packets" include various monitor counting rates such as numbers of the events which hit the Lower Discriminater and Upper Discriminater for each unit. Monitor counts are summed over each board and also output in the HXD-HK packets (section 6.5.5).

Histogram data

In addition to that each WPU event is output to the telemetry, two-dimensional histograms can be produced for the Fast vs Slow pulse-heights distribution (section 6.3.4), and output as the \Histogram packets". 1

These modes correspondto the HXD WPU CLK RATE HK parametervalues of 0 (Normal), 1 (Fine) or 2 (Super-Fine).

ASTRO-E PDMP v1.3 (January 20, 2000)

55

6.5.4 TPU data Transient data

The PH histograms (section 6.4.1) are continuously sent from AE to the telemetry. The upper 16 energy channel of the PH are binned by two, thus the number of spectral channels becomes 56. One 144 byte-length \block" contains a 56 channel PH histogram for a single time bin. For the default time resolution of one second, one block is output every second. Dierent boards have the same APID and are discriminated by the board ID in the telemetry. In addition to the TPU PH histograms, the block includes the number of events which hit lower discriminater (LD-hits) of the anti-counters. One block contains LD-hit rates of the ve anti-counters belonging to that TPU board, and the LD-hit rates of the four underlying anticounters belonging to a WPU. PH histogram data are condensed for each board and also output in the HXD-HK packets (section 6.5.5).

Gamma-ray burst data

The upper 16 energy channel of the PH are binned by two, thus the number of spectral channels becomes 56. One set of the gamma-ray burst data includes 128 sets of the 56 channel PH histograms and 4096 sets of the 4 channel TH histograms (table 6.1). In addition, the same LD-hit rates of the anti-counters as in the Transient data are included. The gamma-ray burst data requires 64 1024-byte blocks to output for each board.

6.5.5 HK data

DHU HK is the HK data DHU accumulates through HXD-PIM, independently of the DP. HXD HK data is the main HK data edited by HXD-DE. This includes the ACU HK data, condensed monitor data and transient data (sections 6.5.3 and 6.5.4), and HK information of the DE itself. ROM mode HK data is edited by DE when DE is in the ROM mode, and this includes only the DE data.

6.5.6 Status Packets

DE System status and PI program status show the setting and status of the DE system software and the PI program (section 6.3.4) respectively. ACU-HK data is diagnostic information of the AE/ACU module.

6.5.7 Dump Packets

Contents of the on-board memories are dumped depending on the DE status.

56

CHAPTER 6. HARD X-RAY DETECTOR (HXD)

Chapter 7

Mission Operations In this chapter, we briey explain how the ASTRO-E mission is operated, observation program is conducted, and the data is processed. Figure 7.1 is a owchart illustrating various processes in the ASTRO-E observation program from GOs' proposal submission to the data reception. Important issues for individual processes outlined in this chapter are explained in more details in later chapters.

7.1 Observation Program

7.1.1 Denition of the Mission Phases Since XRS lifetime is limited, observation program in the early stage of the mission shall be designed to maximize XRS capabilities and performances. This period, which is expected to be 2 years, is called Phase 1 (gure 7.2). Phase 1 is further divided into Phase 1-A, which is the rst six months, Phase 1-B, the next 9 months, and Phase 1-C, the rest 9 months. After the XRS cryogen is exhausted, Phase 2 will start, during which only XIS and HXD will carry out observations. During Phase 1, certain portion of the observation time is guaranteed to the ASTRO-E Science Working Group (SWG), which consists of the ASTRO-E hardware teams, software teams and several invited researchers. The Phase 1-A is entirely for the SWG observations, and the Guest Observations, selected through competitive process, starts at Phase 1-B (gure 7.2). Phase 2 will be completely open to the Guest Observers. Key dates by the end of Phase 1 are shown in table 7.1.

Phase 1-A The rst 0.1 year of Phase 1-A will be spent to establish the satellite and instrumental operation this period may be called In Orbit Check-out (IOC) phase. The remaining 0.4 year will be primarily used for the verication of the instrumental performance and data handling system. Some scientic results are expected during this 0.4 year. All the observation time of Phase 1-A is alloted to the SWG.

Phase 1-B and 1-C In Phase 1-B, Guest Observer observations will start, such that 34 % of the time is allocated to SWG, and 66 % is for GOs (gure 7.2). In Phase 1-C, 20 % of the time is given to SWG, and 80 % is for GOs. The GO time will be equally divided to the Japanese and US communities. A small portion of the Japanese time may be reserved for GOs from ESA (European Space Agency) member countries. 57

KSC

Figure 7.1: Overview of the ASTRO-E mission operation and observation program. Satellite

Data

Mirrored

Commands

Quick Look

Operation Reports

Operation Center

Orbit Determination (NASDA)

Data Acquisition

Raw Packet Telemetry (RPT)

FITS Conversion (backup)

Observation Database

Pipe-line Processing

Calibration Database

Mirrored

Calibration Database

Archival Database

Processed Products

Astro-E archives

Processed Products

GSFC

Japanese Guest Observers

US Guest Observers

ISAS

Proposals

Proposals

Pipe-line Processing

Selection in Japan

Selection in USA

Proposal Database

First FITS Files

Orbit Files

Attitude Files

Orbit Files

First FITS Files

Attitude Files

Merging

Delivery Raw Packet Telemetry (RPT)

FITS Conversion

Attitude Determination

Calibration

Astro-E Team

Astro-E Science Working Group

Telemetry Database (SIRIUS)

GO Observations (after Phase 1-B)

TOO Observations

Calibration Observations

Observation Database

Operation

Commands

Scheduling

Proposal Database

SWG Observations (only Phase1)

58 CHAPTER 7. MISSION OPERATIONS

ASTRO-E PDMP v1.3 (January 20, 2000) Phase 1

In Orbit Check-out

Phase 1-A

0.1 year

Phase 1-B

SWG SWG

GO (AO1)

33%

0.4 year

Japan

GO (AO2)

20%

GO 60%

40%

Japan

Japan

40% US

US

0.75 year

Phase 2

Phase 1-C

SWG

34% 33%

59

15% Japan-US 25%

US

~0.75 year

Figure 7.2: Denition of the ASTRO-E mission phase and observing time allocation. Note that the spare Observatory Time ( 5 % throughout the mission life) is not indicated. Selection of SWG targets for Phase 1-A and 1-B periods AO1 NRA release with SWG target list AO1 deadline AO1 proposal review Phase 1-A and 1-B period observation schedule determined

1999 June 1999 June 1999 September 1999 November 1999 December

ASTRO-E Launch

2000 January

Phase 1-A observation starts Phase 1-B observation starts Selection of SWG targets for Phase 1-C period AO2 NRA release with SWG target list AO2 deadline AO2 proposal review Phase 1-C period observation schedule determined Phase 1-C observation starts End of Phase 1 (XRS nish)

2000 March 2000 August 2000 November 2000 November 2001 February 2001 April 2001 May 2001 May 2002 January

Table 7.1: Key dates by the end of Phase 1 Details of the ASTRO-E Guest Observer program will be fully described in the ASTRO-E NASA Research Announcement (NRA), which is published toward US researchers by NASA. There will be two AO periods AO1 corresponds to Phase 1-B, and AO2 corresponds to Phase 1-C.

Phase 2

In Phase 2, all the observation targets are selected based on the proposals from US and Japanese Guest Observers. The GO time will be divided between Japanese and US communities such that 60 % of the time is allocated to Japanese community, 25 % for US, and 15 % for Japan-US collaborative observations.

7.2 Type of the Observations 7.2.1 Observatory Time

Throughout the ASTRO-E mission life, approximately 5 % of the time will be spared for the Observatory Time maintained by the ASTRO-E team at ISAS. The Observatory Time will be spent, for example, for instrumental calibration, maintenance of the satellite, or to compensate

60

CHAPTER 7. MISSION OPERATIONS

unexpected observational/operational failure such as cancellation of the ground contacts due to bad weather. Target of opportunity (TOO) observations (section 7.2.6) may be also carried out using the Observatory Time.

7.2.2 IOC Observations

The rst 0.1 year of the mission life will be devoted to the In Orbit Check-out (IOC) by the ASTRO-E team. Although celestial X-ray targets may be observed, meaningful scientic results may not be expected.

7.2.3 SWG Observations

During Phase 1-A, most SWG observations will be selected considering not only the scientic merits, but also usefulness for instrumental calibration. In Phase 1-B, SWG observations will become more science oriented. SWG observations are planned and analyzed by SWG members. For each target, a target team composed of several SWG members will be organized and a team leader will be assigned. The team leader will serve eectively as a Principle Investigator (PI), and be responsible for coordination of the analysis and presentation of the result. SWG targets for Phase 1-A and the rst half of Phase 1-B (AO1 period) should be xed and announced by the time AO1 NRA is released (table 7.1). SWG targets for the second half of Phase 1-B (AO2 period) will be determined after the launch, taking account of possible feedback from results of the Phase 1-A observations the SWG target list should be announced by the release of AO2 NRA.

7.2.4 GO Observations

Targets are selected through a competitive process from observation proposals submitted by US and Japanese Guest Observers (GO). US GOs will submit proposals to NASA responding to the NASA Research Announcement (NRA). GOs may propose the same targets already on the SWG target lists. In this case, GOs will have to justify (e.g., dierent scientic motivations) the necessity of the additional observations. If proposals are accepted by the US review panel, the targets are put on the US target list. Similarly, Japanese researchers submit proposals to ISAS, and the Japanese target list is made through independent Japanese review process. The nal accepted target list is determined at the Japan-US merging meeting based on the Japanese and US target lists. In case there are identical targets on the Japanese and US target lists, and/or in order to adjust the time allocation between the two countries, the same target may be assigned a Japanese PI and a US PI. Proprietary data are sent to the PI(s) of the proposal. The PI(s) will lead the data analysis with some support from the ASTRO-E GOF as needed (chapter 13).

7.2.5 Calibration Observations

ASTRO-E team will regularly carry out calibration observations to monitor the performance of the instruments both in Phase 1 and Phase 2. Calibration observations will be carried out primarily using the Observatory Time.

7.2.6 Target of Opportunity Observations

Target of Opportunity (TOO) observations may be carried out responding to rare observational opportunities and considering their high scientic merits. For example, X-ray nova or supernovae, strong ares of known targets, and after-glows of Gamma-ray bursts may be considered as TOO targets. There will be TOO observations both in Phase 1 and Phase 2. Rules and procedures of the TOO observations will follow those of ASCA which have been in practice since 1997 July1 . To 1

See

.

http://heasarc.gsfc.nasa.gov/docs/asca/too/too.html

ASTRO-E PDMP v1.3 (January 20, 2000)

61

summarize these policies, anybody can propose TOO observations by contacting ASTRO-E project scientists at ISAS and GSFC. Once TOO observations are approved, observations will be carried out using the Observatory Time. The proposer will be the PI, and several ASTRO-E members will participate to the study as coinvestigators.

7.2.7 Time Constraint Observations

Some observations are required to be performed at specic periods. These include the time critical observation, such as simultaneous observations with other wavelengths or instruments, and the phase critical observation, such as observations of X-ray binary eclipses. Also, observation of extended targets may require specic roll-angles, which constrain observation windows in a year because of the solar condition. Number of time constraint observations will be limited so that the entire observation scheduling is not burdened too much.

7.2.8 HXD TPU Observations

Besides that HXD WPU supplies hard X-ray/
-ray spectral data of the target simultaneously observed with XRS and XIS, HXD TPU is capable of detecting gamma-ray bursts and monitoring persistent hard X-ray/
-ray sources from large region of the sky (sections 6.4.3 and 6.4). These TPU data will constitute precious all sky monitor datasets. It has yet to be determined how to handle TPU monitor data and gamma-ray burst data in terms of the data priority.

7.3 Proprietary Period Calibration data will be immediately public regardless of the mission phases. Proprietary period of the scientic data taken during Phase 1-A is 18 months for all the other data, proprietary period is one year. After the proprietary period is over, the public data are delivered to the ASTRO-E archives (section 7.5.4 chapter 14), so that interested researchers can obtain the data through Internet.

7.4 Satellite Operations

7.4.1 Scheduling the Observations

ISAS will be responsible for making observation schedules and operating the satellite. At the operation center at ISAS, a long term plan will be made at the beginning of each AO period and updated every few months to cover the targets in the observation database (section 14.1.3). Short term plans are made every couple of weeks based on the long term plan, taking account of contemporaneous changes such as TOO observations, troubles of the satellite or ground stations. Both long term and short term observation plans will be public, and immediately announced to ASTRO-E Observers. When short term plans are announced, ASTRO-E GOF contacts US GOs to conrm their observation plans, and the nal plans are sent to ISAS (section 13.3). Satellite command planning softwares similar to those used for ASCA will be used to make observation schedules with optimum conditions (see also section 10.1). In the case of ASCA, a technician employed by a NASA contractor is staying at ISAS to run the command planning softwares and help ISAS operation team determine the observation schedules. A similar US assistance in the satellite operation is expected for ASTRO-E as well.

7.4.2 Operating the Satellite

Duty scientists at ISAS and KSC will be responsible for the daily ASTRO-E operation. All Japanese ASTRO-E team members at universities and other institutions are expected to work as duty scientists from time to time either at ISAS or KSC. Duty scientists at ISAS operation center make the daily observation commands based on the observation plans conrmed by ASTRO-E

62

CHAPTER 7. MISSION OPERATIONS

Observers. The operation commands are daily sent to the Kagoshima Space Center (KSC), where the satellite is operated and the data are retrieved. At KSC, the satellite is contacted usually ve times a day, each 10{15 minutes2, during which period the operation commands are sent to the satellite, and the data are retrieved. Duty scientists at KSC may carry out quick look analysis to make sure if the observation was carried out correctly. Quick look results are sent to GOs through ISAS or GSFC to notify status of the observation. Duty scientists at KSC make daily operation reports, which will be archived at ISAS and GSFC. If any failure is found during the operations, that is immediately informed to ISAS, and proper countermeasures shall be taken.

7.5 Data Flow

7.5.1 Data Retrieval and Raw Data Archives The data is retrieved from the satellite only at KSC. Amount of the ASTRO-E data daily retrieved is 1.2 Gbytes (5 contacts
0.25 Gbytes/contact see section 2.2). Raw data are sent from KSC to ISAS through a dedicated network, and saved in the raw database named SIRIUS. The SIRIUS database at ISAS stores the raw telemetry data of all the past ISAS missions (see also section 2.4.2).

7.5.2 Data Processing at ISAS and GSFC The ASTRO-E data processing means conversion from the raw telemetry data to the high-level calibrated data deliverable to the ASTRO-E Observers. Details of the data processing are explained at section 11.1, and only an outline is given here (gure 7.1). At ISAS, telemetry les in the SIRIUS database are wrapped into portable Raw Packet Telemetry (RPT) FITS les, being added a minimum set of FITS keywords. Routinely, ISAS will process RPT les to produce First FITS Files, which conform to high level FITS standards. Attitude of the satellite is calculated at ISAS, and the satellite orbit is determined3 . The First FITS Files, attitude les and orbit les constitute a complete data package for each observational sequence. These packages are archived at ISAS, and the identical copies are delivered to GSFC regularly. The RPT les are also delivered to GSFC for archival and back-up purposes, so that the First FITS Files may be produced at GSFC if necessary. The same Pipe-line Processing runs on the First FITS Files at ISAS and GSFC, to apply the calibration information and produce the high-level processing products (section 11.6).

7.5.3 Data Delivery to ASTRO-E Observers

The processing products are delivered to Guest Observers and SWG members. US ASTRO-E Observers will receive data from GSFC, and Japanese Observers will receive from ISAS. The delivery medium will be CD-ROM or DVD. The proprietary data might be also put on-line so that ASTRO-E Observers may obtain the data promptly using a secure data transfer protocol such as the PGP encryption. ASTRO-E Observers will be able to conduct scientic analysis immediately from the processing products. The analysis software and user support are provided by the ASTRO-E GOF (see chapter 8, 9 and 13). 2 Occasionally, the time of the ground contacts conicts with other satellites operated at KSC. According to circumstances, some of the ve ASTRO-E ground contacts may have to be canceled. This will limit the number of commands sent to the satellite, as well as amount of the data to be downloaded (section 7.5.1) 3 In fact, the satellite orbit is monitored at ground stations of NASDA. NASDA determines the ASTRO-E orbit, and delivers the orbit les to ISAS regularly.

ASTRO-E PDMP v1.3 (January 20, 2000)

7.5.4 ASTRO-E Archives

63

All the ASTRO-E data will be delivered to and archived at the HEASARC, and may be at the ISAS data center too. Access to the proprietary data is only allowed to ASTRO-E Observers through a secure data transfer protocol. After the proprietary period is over, the data is made public, so that users are able to obtain exactly the same datasets as the original Gust Observers have received. From time to time, contents of the archives will be updated, being reprocessed with the latest softwares and calibrations. Details of the ASTRO-E archives are explained in chapter 14.

64

CHAPTER 7. MISSION OPERATIONS

Chapter 8

Software Principles In this chapter, we present the ASTRO-E software principles and agreements, which all the software developers need to follow throughout the ASTRO-E project.

8.1 General Software Design Principles ASTRO-E data analysis system should share the same design principles with all the other projects conducted under OGIP. These design principles may be summarized as follows: 1. Standard and portable data format | FITS (Flexible Image Transport System) format is adopted for all the binary les. System dependent binary les will never be used. Moreover, the existing OGIP conventions should be followed wherever possible, and new conventions should be submitted to HEASARC FITS Working Group to check for consistencies with other missions. Use of ASCII format is allowed for small les. 2. Universal and unique software | There should not be multiple channels of the data analysis. Software releases are controlled, and the same routines used for the instrumental calibrations by hardware teams are used for the scientic data analysis by Guest Observers. 3. Designed for multimission analysis | Already written software infrastructures will be made use of as much as possible. Users will be able to analyze ASTRO-E data with standard high-level X-ray data analysis packages such as XSPEC, XIMAGE, XRONOS, etc. 4. Easy to install and use | The softwares will be easy to install and use, and extensive help, support and documentation will be provided. ASTRO-E specic softwares for low-level tasks are distributed in the standard FTOOLS package, providing user friendly interface on most standard platforms (section 8.3.3). 5. Free and public software | Users will not have to purchase any commercial software packages (such as IDL), and all the source codes will be open and easily available at free of charge. Users will not have to worry about license issues, and software authors shall not claim any privileges or credits. Users may modify and distribute ASTRO-E softwares freely on their responsibility.

8.2 ASTRO-E Specic Design Principles In addition to the general design principles above, ASTRO-E GOF and ISAS propose the following design principles for the ASTRO-E software/data processing system. Experience from the ASCA software project is reected here. 65

66

CHAPTER 8. SOFTWARE PRINCIPLES 1. The raw telemetry will be converted to FITS format before distribution. There is only one set of software (mk1st
ts section 11.3.1) to access and interpret the raw telemetry data and to convert them to the FITS format (First FITS Files section 11.3). Mk1stts, as well as other processing softwares, has to be fully tested and ready before the launch of the satellite. 2. All the calibration and data processing should start from the First FITS Files. To that end, the First FITS Files should reect the original structure of the raw telemetry as much as possible. 3. All the scienti c analysis starts from the standard calibrated FITS les. The First FITS Files are further processed by the standard softwares with instrumental calibration information, and the Calibrated FITS Files (section 11.3) are produced. Scientic outputs are produced always from the ocial Calibrated FITS Files, and there should not be other routes for scientic analysis. 4. The same processing system to calibrate the First FITS les should run at GSFC and ISAS. Thereby, US and Japanese ASTRO-E Observers shall receive the identical Calibrated FITS Files. 5. Important calibration tools/softwares should be made promptly available to GOs. At a time, there shall be always a single version of the ocial instrument calibration les and softwares controlled by the ASTRO-E GOF and instrument teams. 6. ASTRO-E softwares will be written by the ASTRO-E software and hardware teams at GSFC, ISAS and other institutions in Japan. Tasks which require deep understanding of the ASTRO-E instruments, spacecraft and telemetry formats will be mainly written by the members of the hardware teams and ISAS. On the other hand, higher level tasks, in which user-friendliness, standardization and conformity with other high energy missions should have a high priority, will be mainly written by the software team at GSFC. 7. All the softwares for public release will be delivered to ASTRO-E GOF before the release. ASTRO-E GOF will ensure that the softwares follow the rules presented in this chapter, and will package them in a form which is suitable for general release. ASTRO-E GOF will be responsible for releasing and maintaining the packages. When softwares are required to be modied or xed, ASTRO-E GOF will be responsible for the x and the rerelease, contacting the original authors as needed. When signicant changes are necessary, ASTRO-E GOF will always consult the original authors in advance. 8. Tasks required for the Pipe-line processing should run in scripts. In the automated pipe-line processing system (section 11.6), series of data processing tasks are run as background jobs by scripts. Therefore, all the processing tasks including those which make use of GUI are required to run in scripts.

8.3 ASTRO-E Software Standards 8.3.1 Languages

ASTRO-E software will be mainly written in C. The use of C++ is allowed, but not encouraged. C++ will not be adopted throughout the project, but may be used within some small independent packages (e.g., ray-tracing program). Fortran77 is allowed, but Fortran90 shall not be used. In the scripting tasks, use of system independent environments such as Perl or Tcl/Tk is recommended. Use of the shell languages (such as csh, bsh and tcsh) which do not run beside UNIX environment is forbidden.

ASTRO-E PDMP v1.3 (January 20, 2000)

67

8.3.2 Coding Rules and Compiler Requirements

Portable coding practices shall be adhered to, including the isolation of system-dependencies. The ANSI C standards shall be adhered for C-programming, and so is the OGIP Fortran standards (Mukai 1993) 1 for Fortran programming. The system-independence test for C shall be that the code can be compiled by gcc on the several supported architectures (see section 8.3.3), and so is by g77 for Fortran. The cfortran package shall be used to combine C and Fortran routines when necessary. To write and read FITS les, ctsio (in C) or tsio (in Fortran) should be used. The obsolete tsio C-wrappers, which were developed to call fortran tsio routines from C-codes, should not be used.

8.3.3 Systems Supported

All the ASTRO-E softwares intended to distribute shall run on the most popular systems of ASTRO-E users. It is dicult to predict now which systems will be most important around 2000. However they are likely to include Sun/Solaris, DEC/Alpha, SGI/Irix, HP, Linux, and Windows NT.

8.3.4 Coordination and Version Control

The Software Coordination Group consisting of members from each hardware team, ISAS, and the GOF shall meet regularly (at least twice a year until and soon after the launch) to ensure software coordinations. In addition, the GOF shall have one person attached to each hardware team with responsibility to help coordinate software development. The software coordination group shall also be responsible for ensuring consistency of FITS keyword naming across teams. The 1st Stage Software (section 11.3) is maintained by ISAS. GSFC keep master copies of all the softwares except the 1st Stage Software under a control system. This control system shall ensure that a given le is only edited by one person at a time and also that previous versions are archived and can be recovered. The practical way that ASTRO-E FTOOLS will be developed and maitained gloably is explained in section 8.4.

8.3.5 Documentation

All the softwares intended for distribution should be fully documented in English. Comments in the source codes should be written in English, but Japanese translation might be added for convenience and may not have to be stripped when distributed. All subroutines/programs of general use shall contain a standard header. The GOF will provide a script to strip out these headers and make them available over the Web. The GOF will also provide template routines containing the standard header. The FITS le format of ASTRO-E related les is fully explained in a separate document maintained by the ASTRO-E GOF.

8.4 ASTRO-E FTOOLS Global Development Scheme Many scientists and programmers in the United States and Japan are involved in the ASTRO-E FTOOLS development. Also, ASTRO-E FTOOLS users are located not only in the two countries, but also in Europe and other places. Therefore, version control will be very important so that no dierent avors of the same FTOOLS be developed and proliferated. 1 See http://heasarc.gsfc.nasa.gov/docs/journal/ogip fortran3.html . This is ANSI Fortran77 with some extensions. The extension includes the following: (1) Both upper and lower case letter are allowed. (2) END DO are allowed. (3) DO WHILE loops are allowed. (4) INCLUDE statements are allowed. (5) INTEGER*2 data type is allowed. (6) Variable can be up to 31 character long. (7) IMPLICIT NONE is allowed.

68

CHAPTER 8. SOFTWARE PRINCIPLES

Official ftools release (once or twice a year)

GSFC Test

Develop Ftools Test

ASTRO-E Users in US and Europe

Release Ftools

Build weekly

ASTRO-E add-on

Test

GOF

anonymous ftp

Repository

Build ASTRO-E ftools as needed

Ftools team

ADF

Used for analysis anonymous ftp

ASTRO-E Users

pipe-line processing system

Processing Ftools XRS team at GSFC

XRS team in Japan

XRS team

Deliver new codes

Software Development Coordinator

Mirrored as needed

Processing Center

Check Consistency

pipe-line processing system

Processing Ftools

Mirrored Daily

Release Ftools

ftp

ASTRO-E add-on

ASTRO-E Users in Japan

Used for analysis Test

ASTRO-E Users

XIS team Test

HXD team Test

ISAS

Figure 8.1: ASTRO-E FTOOLS global development and version control scheme.

ASTRO-E PDMP v1.3 (January 20, 2000)

69

In the early stage of the mission, as understanding of the instruments deepens and new data analysis techniques are getting established, it will be necessary to update and release the ASTRO-E FTOOLS promptly. We should be ready for the release cycle of a few weeks or less. To accommodate both requirements of the rigorous version control and prompt release, the following scheme, which is illustrated in gure 8.1, has been proposed and will be practised for the ASTRO-E FTOOLS development, version control, and release. 1. At GSFC, the FTOOLS team maintains the FTOOLS \Repository", for which only the team members are granted the write permission. The FTOOLS team receives original source codes from the \Contact" groups (through ISAS when the Contact groups are in Japan see 6 below), and put the codes in the Repository, after minimal programmatic changes if necessary. The codes in the Repository should be considered the genuine copy of the latest ocial FTOOLS. 2. The entire FTOOLS directory tree is built weekly from the Repository. This FTOOLS is called \Develop" FTOOLS, and only available inside GSFC. The Develop FTOOLS are tested at GSFC, and the codes will be xed if any problems are found, and put in the Repository again. Note that the Develop FTOOLS reect updates of all the FTOOLS including ASTROE. 3. From time time, the entire FTOOLS package is released to public. This package is called the \Release" FTOOLS. Frequency of the release is typically once or twice a year. 4. In order to catch up with short development cycle, whenever ASTRO-E FTOOLS in the Repository are updated, the FTOOLS team will build the ASTRO-E FTOOLS against the Release FTOOLS, and install the \ASTRO-E add-on". Interval of the ASTRO-E add-on build will be as short as one week (= Develop FTOOLS build cycle). The Release FTOOLS with the ASTRO-E add-on is the one ASTRO-E users will use for their data analysis. The ASTRO-E add-on package will be promptly released toward ASTRO-E users, so that they can install it on their own Release FTOOLS. 5. The Release FTOOLS with the ASTRO-E add-on will be mirrored daily to ISAS, and will be used for ASTRO-E data analysis at ISAS. Japanese ASTRO-E users outside of ISAS may obtain the original package from GSFC or mirrored one from ISAS. 6. Instrument teams in Japan will test and modify the source codes in the ASTRO-E add-on package to reect the latest calibration, and they will deliver the new codes to the Software Development Coordinator at ISAS. The Software Development Coordinator will make sure that the codes from dierent groups are consistent and can be built cleanly using gcc. After that, he or she will deliver the codes to the FTOOLS team at GSFC (go back to step 1). Note that some of the XRS FTOOLS will be released through the ISAS Software Development Coordinator, while other XRS FTOOLS will be directly delivered to the FTOOLS team. 7. The Processing team at ADF will obtain the Release FTOOLS with the ASTRO-E add-on, which will become the base of the pipe-line processing. However, the processing team will need its own installation of FTOOLS ("Processing" FTOOLS) which should be completely shielded from other versions of FTOOLS. This will ensure robustness of the processing system, and endorse processing team's privilege to modify or x the standard FTOOLS, which is often necessary to timely accomplish the demanding data processing tasks. The Processing FTOOLS, as well as the pipe-line processing scripts, will be mirrored to the ISAS processing center from ADF, so that the data centers at ADF and ISAS use the identical system to produce standard ASTRO-E data products. 8. As of writing this document (January 2000), the Release ftool (v4.2) is too old, and the next release (v4.3) is around the corner (med-January 2000). On the other hand, we should start testing the ASTRO-E FTOOLS conguration paradigm proposed here as soon as possible. Therefore, only until the v4.3 release, the Release FTOOLS in the diagram above will be

70

CHAPTER 8. SOFTWARE PRINCIPLES replace with the "Baseline" FTOOLS, which will be an interim release of a stabilized Develop FTOOLS snapshot.

Chapter 9

ASTRO-E Function Libraries There will be software functions which are repeatedly used in various stages of the ASTRO-E mission, from the satellite operation to the scientic data analysis. In order to avoid overhead and inconsistency, functions supposed to be used by two or more software modules will be included in the ASTRO-E function libraries. There will be at least three such function libraries for ASTRO-E astetool, which includes functions for ASTRO-E specic tasks, atFunctions, which includes functions for generic attitude and orbital related tasks1 , and xrrt, which is for XRT ray-tracing. They are implemented in the FTOOLS package as libastetool.a, libatFunctions.a, libxrrt.a, respectively2 .

9.1 ASTRO-E Specic Tasks (astetool) 9.1.1 Time Conversion

Routines to carry out conversion between ASTRO-E time and other time systems will be necessary. ASTRO-E time will be dened as the elapsed time from the beginning of year 2000 in UTC 3 . The leap second table is referenced to take into account the leap seconds. For the calibration data taken in 1999 and earlier, negative values of the ASTRO-E time may be used.

9.1.2 Coordinate Conversion

Since XIS and XRS are imaging instruments, the coordinates to which XIS images and XRS events are referenced have to be dened. Functions to carry out conversion between these coordinates will be necessary (e.g., when making observation plans and calibrating FITS event les), and will be put in the astetool.

9.1.3 Energy Calibration

ASTRO-E instruments convert X-ray photon energy into a pulse-height signal, of which raw pulseheight is called PHA (Pulse Height Analyzer). Although PHA is proportional to the input energy, it can vary with several conditions such as time, location on the detector, temperature, etc. After correcting these eects, we may dene Pulse Invariance (PI), which should be perfectly proportional to the energy. We will need to calculate PI from PHA for all the three instruments to ll the PI columns in the event FITS les (section 11.4). The routines to calculate PI from PHA should be put in the astetool. These routines need to access calibration les to get calibration information (chapter 12). 1 2 3

atFunctions has been used also for ASCA. On the Unix platforms. For other platforms (such as Windows), the names will be dierent. Test data taken in 1998 or before will have negative values of the ASTRO-E time.

71

72

CHAPTER 9. ASTRO-E FUNCTION LIBRARIES

9.1.4 Data Access Layer (DAL) functions

All the ASTRO-E les will have denitive FITS format, and many ASTRO-E softwares will read/write event les or calibration les with the same FITS formats. In order to facilitate the FITS le access, there shall be a set of Data Access Layer (DAL) functions, which is suppose to take care of the FITS le interface by calling lower level tsio functions. All the ASTRO-E softwares are expected to call DAL functions to access FITS les instead of calling lower level tsio functions directly. Thus, once FITS formats are changed, only the DAL functions are required to be modied, without any changes at at higher levels.

9.1.5 HK Information Acquisition

The HK FITS les (sections 7.5.2 and 11.3) will include all the complex satellite and instrument HK parameters, thus can become huge. However, only small parts of the HK parameters will be actually required for scientic data processing. In order to facilitate the HK le access, HK le access routines should be provided in astetool. Note that HK access routines need to be built with eciency in mind. HK parameters in the telemetry are digitized and come out discretely, thus astetool routines may have to convert them to physical values, and interpolate or smooth them as needed. For example, we may require an astetool routine which gives instrument temperatures in degrees continuously by interpolating discretely measured temperatures in digitized units. Parameters for conversion from the digitized HK telemetry to the physical units are stored in the multimission database named Satellite Information Base (SIB) located at ISAS. Although SIB itself is not portable, ASTRO-E related information in SIB will be necessary to interpret HK parameters in the telemetry. Therefore, essential parts of the SIB will be extracted and put in the calibration les (section 12.4.1).

9.1.6 Other Tasks

Functions for other tasks will be put in astetool as needed. For example, a random number generation function will be required so that the same random numbers are always obtained from the same seeds.

9.2 Attitude and Orbit Related Tasks (atFunctions) The attitude and orbit related functions in atFunctions will be used in various purposes such as command planning, assign SKY coordinates to events (section 11.4), creating the Filter les (section 11.4.1), calculate the exposure maps, and carry out barycentric corrections (section 11.5.3). They may require either or both of the attitude les and orbit les (section 11.2). The following are examples of the tasks in atFunctions.

9.2.1 Attitude Information

 Obtain q-parameters and/or Euler angles for given ASTRO-E time inputs.  Determine the pointing direction of each telescope/sensor for given ASTRO-E time inputs.

9.2.2 Orbit Information

 Obtain satellite orbital position for given ASTRO-E time inputs.  Obtain magnetic cut-o rigidity for given ASTRO-E time inputs.  Determine if the satellite is in day (sun-lit) or dark (not sun-lit) for given ASTRO-E time inputs. Also obtain the elapsed time after the last day-to-dark or dark-to-day transitions.

ASTRO-E PDMP v1.3 (January 20, 2000)

73

 Determine if the satellite is in the South Atlantic Anomaly or not for given ASTRO-E time inputs. Also obtain the elapsed time after the last SAA passage.  Obtain sidereal direction of the magnetic eld line for given ASTRO-E time inputs.

9.2.3 Attitude and Orbit Information

 Output the angles from the earth rim and sun-lit part of the earth for given ASTRO-E time inputs.  Determine if the pointing direction is blocked by earth or not. If it is, determine if the earth is sun-lit or not.

9.3 Ray-tracing function library (xrrt) The ASTRO-E ray-tracing package named xrrt has been written in C++, and is available as a function library. This library provides function to load mirror, obstruction, and reection tables from FITS les, and then to trace photons through the mirror sets and collect statistics about the results. See section 10.2.3 for detail.

74

CHAPTER 9. ASTRO-E FUNCTION LIBRARIES

Chapter 10

Planning and Simulation Software In this chapter, ASTRO-E softwares used for observation planning and simulation are explained.

10.1 Observation Planning Software

10.1.1 TAKO (Timeline Assembler, Keyword Oriented)

A planning software package named \TAKO" (for Timeline Assembler, Keyword Oriented) is developed for ASTRO-E by GSFC based on the methods used for ASCA and XTE. This package is designed to accommodate ASTRO-E specic constraints. These constraints are determined in cooperation of ISAS and GSFC instrument and operations teams. Post-launch changes will be handled in a similar fashion. As has been the case for ASCA, a technician is expected to be hired by GSFC to stay at ISAS to take care of running TAKO to produce regular observation schedules. TAKO will be used not only by satellite operators and command planners at ISAS but also by general ASTRO-E Observers. Users input observation time, target position and optionally the satellite aspect, then they will get observation conditions such as values of the magnetic cut-o rigidity, times of the ground contacts, earth eclipses, and SAA passages. Either ASCII dump or graphical output (such as that by ASCA \DP10"gure 10.1), will be available, so that users could easily see the Good Time Intervals (GTI) of the observations. TAKO will be accessible through Web interface.

10.1.2 MAKI

MAKI is developed at GSFC for ASTRO-E and future multimission planning1. As its name stands, users may run MAKI through a Web browser (users will need to obtain and install the \LHEA Plug-In" 2 ). Users may place dierent satellite elds of view on a sky image to plan out observation (Euler angles are automatically calculated). These FOVs may be rotated, and MAKI will indicate if the roll is allowed or not by dierent colors for a given time period. Users can also view the sun angle visibility limits for several missions, as well as adding phase constraints. MAKI is expected to replace the ASCA command planning program \adcongra" which had similar but more primitive functions. MAKI accepts a sky image le from \SkyView" 3 , or almost any FITS image les. It also lets users save the results, and reload them. In gure 10.2, an example of MAKI output is shown. See the MAKI home page http://heasarc.gsfc.nasa.gov/Tools/maki/maki.html for detail. The LHEA Plug-In is developed at LHEA at NASA/GSFC. It is a web plug-in for Netscape or Explorer that lets users use interactive astronomy tools via the simple interface of users' browser. 3 SkyView is a \Virtual Observatory" on the Net generating images of any part of the sky at wavelengths in all regimes from Radio to Gamma-Ray. See http://skyview.gsfc.nasa.gov/skyview.html for details. MAKI can launch from the SkyView output page if \Advanced" interface is selected. 1 2

75

76

CHAPTER 10. PLANNING AND SIMULATION SOFTWARE

Figure 10.1: An example of the ASCA DP10 plot. TAKO is supposed to produce a similar plot for ASTRO-E.

Figure 10.2: An examples of the MAKI plot. An XRS eld of view is displayed on an optical image obtained from SkyView.

10.2. SIMULATION SOFTWARE

77

10.2 Simulation Software ASTRO-E simulation softwares will have the following purposes. First, simulation softwares will be used to study technical feasibility of planned observations. Second, they will be used to determine instrumental responses in order to simulate and understand physical processes in the instruments. Third, they may be used in data analysis when instrument responses are dicult to determine and Monte Carlo approach is considered more eective. Finally, simulated data sets will be used to verify softwares for data analysis and processing.

10.2.1 Counting Rate Simulation { PIMMS When planning observations, the rst thing needed is to estimate the expected counting rates. For such a purpose, PIMMS (Portable, Interactive, Multi-Mission Simulator) has been developed at GSFC and already widely used in the community Users will be able to estimate the expected counting rates for XRS, XIS and HXD by inputting the source ux and the spectral form. The source ux can be a physical unit (ergs s 1 cm 2) or counting rates from other satellites/instruments. As of early 1999, PIMMS already calculate expected counting rate for ASTRO-E. See details at http://heasarc.gsfc.nasa.gov/docs/software/tools/pimms.html 4. ;

;

10.2.2 Spectral Simulation { XSPEC The XSPEC spectral tting package has a capability to simulate instrument dependent pulse-height spectra for given input photon spectra5 . To that end, XSPEC requires not only the eective area and eciency (ARFs { Ancillary Response Files), but also the response matrices (RMF { Redistribution Matrix Files). GOF has released a suite of the ASTRO-E response functions for spectral simulation purposes. See, http://heasarc.gsfc.nasa.gov/docs/astroe/aehp prop tools.html for details.

10.2.3 XRT Ray-tracing Package { xrrt The ray-tracing package, named \xrrt", is developed at GSFC ADF (Astrophysics Data Facility code 631) in cooperation with ISAS, Nagoya University and GSFC mirror team (cod 662). The package is written in C++. It is available as stand-alone FTOOLS, xrrtrt and xrrtray (table 11.3), or as a function library (section 9.3) for use by other FTOOLS such as xrssim (section 10.2.5). xrrtrt creates reection tables for use by xrttray. These tables give surface reectivity as a function of surface type, energy, and incident angle. xrrtray traces photons using the xrrt library through dened thin-foil mirror sets. It then creates FITS les with the results of the ray trace, which can be focal plane images, complete results for each photon traced, and/or a statistical summary. The ray-tracing package will be used to determine physical parameters of the mirrors which are dicult to measure (e.g., surface densities), by comparing the actual data and simulations. XRT responses such as point spread functions and eective areas will be determined through iterations of the ray-tracing simulations and actual calibration data. The ray tracing package is also useful to simulate observations when making plans or analyzing data. For example, if there are bright sources outside of the eld of view, amounts of the stray-lights can be estimated through the ray-tracing simulations. 4

The WWW version of PIMMS, W3PIMMS is also developed and available at . The WWW version of the XSPEC spectral simulation, WebSpec, is available at

http://heasarc.gsfc.nasa.gov/Tools/w3pimms.html 5

http://heasarc.gsfc.nasa.gov/webspec/webspec.html.

78

CHAPTER 10. PLANNING AND SIMULATION SOFTWARE

Figure 10.3: An example of the XRS event simulator, xrssim output. The source is the supernova remnant Cas-A, and the expected XRS pixel count distribution is shown on the simulated contour map.

10.2.4 Detector Simulators

The detector responses shall be made based on the pre- and post-launch calibrations. In the course of determining the detector responses, response generators will be developed to understand physical processes taking place in the detectors. The response generators are easily converted into detector simulators. The only dierence will be that while response generators calculate bulk properties of the instrument responses (e.g, response matrices for the entire energy band), detector simulators should be able to output a single pulse-height signal corresponding to a single input photon with arbitrary parameters. The detector simulators will be used to construct the end-to-end simulator (see below) combined with the XRT ray-tracing package. The XRS and XIS spectral simulators, xrsspecsim and xisspecsim, respectively, will be made available as FTOOLS. The full detector simulators can be enormous in size to fully simulate the physical process taking place in the detector6 . However, such big software packages may not be suitable for distribution and not necessary for most Guest Observers. In such a case, ASTRO-E GOF will provide simplied versions of the simulator for general use, which should be more compact but equipped with most functionalities of the full simulator. This may be done, for example, by precalculating detector response matrices with the full-simulator, so that the simplied simulator can refer to the precalculated response matrices to calculate expected pulse heights for input photons.

10.2.5 End-to-End Simulator { xrssim

One can build the end-to-end ASTRO-E simulator by combining the ray-tracing package and the detector simulators. The end-to-end ASTRO-E simulator will read input photon lists having 6 For example, HXD team is planning to build a full detector simulator by incorporating the generic libraries for high energy physics (developed at CERN) to simulate the particle interactions taking place in the detector.

ASTRO-E PDMP v1.3 (January 20, 2000)

79

arbitrary spatial and energy distribution, and outputs simulated event lists, fully simulating the paths of the X-ray events from the telescope openings to the detector electronics. The rst ASTRO-E end-to-end simulator, xrssim has been released as an FTOOL. This reads a photon event list created by the mkphlist FTOOL, and produce a simulated XRS event list. The output event list may be analyzed standard analysis tools such as xselect. xrssim will be useful to simulate observations of extended sources. Also, xrssim has a capability to simulate the XRS event grades (sections 4.2.2 and 4.2.3), hence will be used to see eects of the event pile-up in bright source observations. In gure 10.3, we show an example of the xrssim output. Similar to xrssim, the XIS event simulator, xissim, is also being developed as an FTOOL.

10.2.6 ASTRO-E Simulator and Data Analysis

End-to-end simulators will be also used for data analysis when the instrument response functions are dicult to determine. For example, it will be laborious to determine spatial structures and temperature distributions of clusters of galaxies from XIS data, since XRT PSF has signicant spatial dependences. In such a case, the ASTRO-E simulator may be used to create simulated images and spectra of clusters of galaxies with dierent values of the physical parameters (e.g., temperature and -parameter) through Monte Carlo simulations. By comparing the simulated data with actual observations, one may choose the most likely cluster parameters to mimic the observed data.

80

CHAPTER 10. PLANNING AND SIMULATION SOFTWARE

Chapter 11

Data Analysis and Processing Software In this chapter, ASTRO-E software tasks are dened and explained. These tasks are required for the data processing from the data acquisition at ISAS to the delivery to ASTRO-E Observers, and for the data analysis by ASTRO-E Observers.

11.1 Overview Figure 11.1 illustrates an overview of the ASTRO-E data ow, which we conventionally divide into four Stages, from satellite specic calibration at ISAS (Stage 0) to the scientic data analysis by ASTRO-E Observers (Stage 3). In general, software tools used in the earlier stages are not required to be portable (i.e., run only at ISAS and/or GSFC), but have to be stable enough so that the data do not have to go through these stages repeatedly. On the other hand, softwares in the later stages have to be more portable and exible, so that ASTRO-E Observers can reprocess/reanalyze their data repeatedly by themselves. All the softwares to be used in Stage 2 and Stage 3 are distributed to ASTRO-E Observers. In particular, it is important to distribute the softwares for calibration so that ASTRO-E Observers can re-calibrate their data when new calibration information is made available. All the distributable ASTRO-E softwares are included in the FTOOL package. The ASTRO-E FTOOLS are summarized in table 11.3.

11.2 Stage 0 { Satellite Specic Calibration at ISAS This is the stage to carry out satellite specic calibration/corrections. This stage is performed only at ISAS, thus softwares to accomplish these tasks are not required to be portable. Inputs to this stage are satellite raw telemetry and other satellite specic (e.g., orbit and clock) information. Outputs are the Raw Packet Telemetry (RPT) les, attitude les, and orbital les. These les, as well as the First FITS Files (section 11.3), are regularly sent from ISAS to GSFC (gures 7.1 and 11.1).

11.2.1 Orbit Determination The ASTRO-E orbit will be determined by NASDA, and orbit les will be regularly sent to ISAS. ASTRO-E orbit les will have the same FITS format as that of the ASCA orbit les. 81

82

CHAPTER 11. DATA ANALYSIS AND PROCESSING SOFTWARE Astro-E Satellite

Kagoshima Space Center

Raw Telemetry Stage 0

Satellite Specific Corrections

ISAS

Raw Packet Telemetry (RPT) Files Attitude Files Orbit Files Stage 1 FITS Conversion

GSFC

First FITS Files Stage 2

Calibration Processing products

Stage 3

Data Analysis GOAL Presentation Publication

Guest Observers

Figure 11.1: Overview of the ASTRO-E data ow.

11.2.2 Attitude Determination

The attitude determination software will be developed exclusively by an ISAS contractor (presumably NEC), as has been the case for GINGA and ASCA. Technicians will be hired at ISAS who will work full-time on the ASTRO-E attitude determination. The same FITS format as the ASCA attitude les may be also used for ASTRO-E.

11.2.3 Create RPT les from the SIRIUS Database

The telemetry database at ISAS is named SIRIUS, in which all the telemetry les of past ISAS missions are stored (sections 2.4.3 and 7.5.1). The ISAS data center, which is suppose to take care of all the ISAS mission data, puts the ASTRO-E data sent from KSC into the SIRIUS database. SIRIUS database is available on the UNIX workstations for ASTRO-E1 . Format of the SIRIUS les will be similar to the original ASTRO-E telemetry format (section 2.4.3). The ISAS ASTRO-E team shall access the raw telemetry les in the SIRIUS database via the depacketer and create Raw Packet Telemetry (RPT) FITS les, in which original telemetry formats are conserved. RPT les may be considered as the original telemetry les, just being wrapped by FITS headers. Satellite clock correction and correct time assignment may be carried out at this stage. RPT les are portable, and regularly sent to GSFC for a back-up purpose. There will be one RPT le per observation sequence (section 2.4.2). RPT les have three columns, for the TIME when the packet was created (in ASTRO-E time section 9.1.1), the APID, and the CCSDS packet. RPT les have names like, (

aeYYYYMMDD HHMM HHMM.rpt ae19981016 1918 2029.rpt 1

Until ASCA, SIRIUS was mounted only on the main-frame computers.

is an example),

ASTRO-E PDMP v1.3 (January 20, 2000)

83

to indicate starting time of year, month, date, hour, minute, and ending hour and minute.

11.3 Stage 1 { Conversion of the Telemetry to the First FITS Files ISAS shall further process the RPT le, using the 1st Stage Software, to create the First FITS Files, which should conform to the FITS standard dened by HEASARC. The First FITS Files will be composed of the event les and HK les. There shall be no loss of information from telemetry (RPT) to the First FITS Files. All information in the original telemetry shall be preserved, including low level instrument specic data that require special knowledge to be understood2 . In addition, columns for the physical quantities to be derived from these low levels values should be already present in the First FITS Files3 . Access to the RPT les is limited only to when creating the First FITS Files at ISAS. Routine data processing for scientic data analysis shall start from the First FITS Files. Hardware teams shall also start from the First FITS Files for calibration works. There are two exceptions to the above rule:  Hardware teams can access the RPT les for the purpose of testing and debugging the 1st Stage Software.  When revisions are made to the 1st Stage Software, GSFC processing team shall generate new version of the First FITS Files from the RPT les. ISAS shall routinely transfer the RPT and the First FITS Files to GSFC, the former as a back-up, all on an on-going basis, and the 1st Stage Software and related les as necessary.

11.3.1 First Stage Software { mk1stts

First Stage Software consists of the following components: mkcom1stfits { binary executable for Common instruments (only create HK les) mkxrs1stfits { binary executable for XRS mkxis1stfits { binary executable for XIS mkhxd1stfits { binary executable for HXD mk1stfits { script to drive the executables above Each executable reads a single RPT le, and output many First FITS Files, for dierent kinds of science and HK data and observation modes (see below). Tasks of the 1st Stage Software may include: time assignment, reformatting of event data into standard FITS binary tables, conversion of raw digital readout to physical units for housekeeping data, and splitting of event data when such major mode changes occur that requires signicant le-format changes. The 1st Stage Software is developed by the instrument teams, ISAS, and GSFC. It will not be distributed to the community, and therefore need not conform to the highest standard of portability. However, the 1st Stage Software shall be able to run both at ISAS and GSFC on some specic machines. Some of the columns in the First FITS Files may remain unpopulated and/or populated with preliminary values, as calibration information is not applied yet, Also, the First FITS Files need not be modally split for such minor mode changes that do not require FITS format changes4 , need not contain the full set of keywords necessary for analysis, and the GTI table may be preliminary5. 2 Examples are the PHAS column in the XIS 5x5 event les for the 25 pixel values, and the 4 separate integer columns from which XRS event arrival time will be calculated. 3 Corresponding to the examples above, PI and GRADE columns for the former, and the TIME column for the latter shall be present. 4 The \minor" mode change requires referring to the house-keeping data to be identi ed. For example, using XRS Filter Wheel (section 4.1.5) or XIS Window option is considered such minor observation modes. 5 GTI in the First FITS Files should correspond to the time intervals when the telemetry exists, regardless of the instrumental status or observational conditions (see section 11.4.2 and 11.5.1).

84

CHAPTER 11. DATA ANALYSIS AND PROCESSING SOFTWARE Instrument Mode name XRS: None XIS: 5x5,5x5 bst 3x3,3x3 bst 2x2,2x2 bst

timing frameNNN frameNNN bst frameNNN psum darkframeNNN darkinit darkinit bst darkinint psum darkupdata darkupdate bst wel trn bst NNN

,

,

,

,

,

,

HXD: , , (NNN is the sequential number within the RPT)

Table 11.1: Observation mode names used for event First FITS Files. Within a single RPT le, science data taken with the same \major"6 instrumental mode will be put in the same First FITS le, even if there are time-gaps within it. For example, if XIS is switched from the 5x5 mode to 3x3 mode then back to the 5x5 mode, the rst and later 5x5 mode event data shall be combined into a single First FITS File. In other words, mk1stfits separates the input RPT le into dierent \major" observation modes, and creates FITS event les for each major mode. Major modes are determined only by looking at the science packet, while knowing minor modes will need HK packet information (gure 2.6). Therefore, separating the event FITS les into subminor modes will be carried out in the next Stage by referring to the HK ts le (section 11.4.2).

11.3.2 First FITS File Names

First FITS Files consist of event les (science les) and HK les for each instrument. For both of event and HK les, the root name of the RPT le name from which First FITS Files have been produced is inherited. For example, if the RPT le name is ae19981016 1918 2029.rpt, the First FITS File names always start with ae19981016 1918 2029.

Event Files (Science Files)

After the RPT root name, an instrument name and a major mode name will follow with underscores (\ ") between them. The instrument name is either xrs, xis0, xis1, xis2, xis3 or hxd. Sux will be \.fff". The major mode names are listed in table 11.1. On XIS, the major mode names correspond to all the possible combinations of the Clock modes and Edit modes (bst and psum means Burst option and Parallel Sum mode, respectively see section 5.3). The three HXD major modes correspond to the WPU main event data, TPU Transient data, and TPU gamma-ray burst data (sections 6.5.2 and 6.5.4). Examples of the First FITS File names are shown below: ae19981017 ae19981019 ae19981017 ae19981017 ae19981019 ae19981019

1045 1019 1045 1045 1019 1019

1918 1954 1918 1918 1954 1954

xrs.fff xis0 5x5.fff xis1 3x3.fff xis2 2x2.fff hxd bst.fff hxd trn.fff

6 \Major" modes de ne the event formats (such as the XIS 5x5, 3x3 and 2x2 modes). Observational modes which do not change the event formats are considered minor modes (such as the XIS Window option).

ASTRO-E PDMP v1.3 (January 20, 2000) Instrument HK identier COM: com XRS: xrs 8s

xrs cdp xrs dump xrs echo xrs error xrs mem xrs rates xrs reply xis0,xis1,xis2,xis3 hxd hxd tbl

XIS: HXD:

hxd dmp hxd hst hxd scl

85

Meaning common instrument HK HK items which come out every 8 sec CDP HK Dump HK Echo Error Memory dump HK CDP Rates Reply XIS HK for each sensor HK data, system status, ACU-HK, ROM-HK Status monitor, PI program parameters, PI program statistics AE parameter table (SC/HC) Memory dump, I/O dump, ECC dump, ROM I/O dump ROM ECC dump Histograms, Slow-Fast (SF) Coarse, SF Fine (1), SF Fine (2) PMT spectrum, PIN spectrum, Delta-T Scaler HK

Table 11.2: HK identier names for HK First FITS Files and their meanings. ae19981019 1019 1954 hxd wel.fff

HK Files

Instrument names are the same as the event les, except that com is used for the common HK le. Sux of the HK les is \hk". The HK identiers and their meanings are shown in table 11.2. Examples of the HK le names are shown below. ae19981019 ae19981019 ae19981019 ae19981019 ae19981019 ae19981019 ae19981019 ae19981019

1019 1019 1019 1019 1019 1019 1019 1019

1954 1954 1954 1954 1954 1954 1954 1954

com.hk xrs 8s.hk xrs cdp.hk xis1.hk hxd.hk hxd tbl.hk hxd dmp.hk hxd hst.hk

11.4 Stage 2 { Apply Instrument Specic Calibration The First FITS Files shall be further processed into the Calibrated FITS Files by the 2nd Stage Softwares. The 2nd Stage Softwares are developed by the hardware teams in conjunction with the GOF, and distributed to public within the FTOOL package (table 11.3). Populating the columns for physical quantities (such as pulse invariant values and sky coordinates) is the major task in this Stage. The formats of the First FITS event les and Calibrated event FITS les shall be as close to

86

CHAPTER 11. DATA ANALYSIS AND PROCESSING SOFTWARE

Name

Function

astemkehk

Create attitude and orbit Extend HK (EHK) les

makelter

Create a Filter le from HK and EHK les

astearf astescreen asteexpo astetimeconv

Generate XRS and XIS ARFs for spectral analysis Carry out standard data screening of the event les Create exposure maps for XIS and XRS image analysis Carry out barycentric correction

mkphlist

Create a photon-list le for xrssim or xissim simulations

xrrtrt xrrtray

Create ray-tracing table to be used for xrrtray Perform XRT ray-tracing

xrsmkgainhist xrspi xrscoord xrscrosstalk xrsrti xrsrmg xrsimage xrsspecsim xrssim

Create XRS gain history le Fill the PI column of the XRS event le using the gain history le Fill the coordinate columns in the XRS event le Find and ag the cross-talk events Calculate Rise Time Invariance (RTI) from Rise Time Generate XRS spectral response averaging dependency on pixels Calculate XRS pixel pattern (= image) projected onto the sky Simulate the physical process and on-board processing of the detector From a photon-list, generate a simulated XRS event list

xismkgainhist xispi xiscoord xistime xisrmg xisclean xisat xisspecsim xissim

Create XIS gain history le Fill the XIS GRADE, PHA and PI columns of the XIS event les Fill the coordinate columns of the XIS event le Time assignment for Burst mode, P-sum mode or Window option Generate XIS RMF for spectral analysis Remove hot pixels Correction of light leak, DFE, zero peak extent Simulate the physical process and on-board processing of the detector From a photon-list, generate a simulated XIS event list

hxdtime hxdmkgainhist hxdpi hxdgrade hxdrsp hxdarf hxdmkbgd hxdscltime

Fill TIME column of the Well event le Create the HXD-well gain history le Fill the PI column of the event le using the gain history le Fill the GRADE column of the event le Merge RMFs and ARFs to create RSPs Create the HXD-Well ARFs Model and Estimate the HXD-well background Time assignment for Scaler HK data

hxdtrntime hxdtrnbintbl hxdmktrngainhist hxdtrnpi

Fill TIME column of the Transient data le Create the Transient data Binning table Create the HXD-transient data gain history le Calculate the PI for the HXD-transient data using the Binning table

hxdbsttime

Fill TIME column of the gamma-ray burst event les

Attitude/Orbit Common/Processing Common/Analysis

Common/Simulation XRT

XRS

XIS

HXD-WPU

HXD-TPU

HXD-TPU (burst)

Table 11.3: ASTRO-E FTOOLS list

ASTRO-E PDMP v1.3 (January 20, 2000)

87

identical as possible. Any calibration softwares that run on the First FITS Files must also be able to run on the Calibrated FITS Files. New columns may be added but existing columns shall not be removed. This ensures that recalibration is possible on the Calibrated FITS les, not required to start from the First FITS les. This Stage will be run both at ISAS and GSFC in the pipe-line processing (section 11.6). When recalibration is necessary for already distributed data, Guest Observers also shall be able to run this Stage on their data using distributed FTOOLS (gure 11.1).

11.4.1 Stage 2-1 { Preprocessing  Produce a Filter File

While the entire satellite and instrument HK information can be enormous, the HK information actually needed for the data processing will be limited. Therefore, it is convenient to extract only necessary HK items for later processings and put them in a separate Filter
le to distribute to Guest Observers. The Filter le is made with the FTOOL makefilter from the First FITS les and Extended HK les (see below). 7 A single Filter le will made from a single observation sequence. Counting rates of the instruments and/or BGD monitors are also used for deadtime correction (section 11.5.3). Instrument specic items, such as the elapsed time after recharging the ADR for XRS (section 4.1.2) will be also included in the Filter le.

 Create Extended HK (EHK) Files

The makefilter can read HK les, in which HK items are tabulated as a function of time. The astemkehk task will create \Extended HK (EHK) Files" which has the same format as the HK les, from attitude and orbit les. Attitude and orbit information are thus implemented in the Filter le.

 Determine the Average Pointing Directions

From the attitude le, average pointing direction is determined, which is used later as a reference point to assign sky coordinates to each XRS and XIS event. The FTOOL attitude will be used.

 Create Time Dependent Calibration Files

Time dependent calibration les, such as the XRS and HXD gain history les to be used for later processing, are created from the First FITS Files. XRS and HXD gains are likely to be variable within a single observation. The XRS gain history le will be created with the FTOOL xrsmkgainhist using the calibration source peaks (section 4.1.4). The hxdmkgainhist will create the HXD gain history le. When long term instrument performance change is signicant, time dependent calibration les may be created not only from a single sequence, but also from many sequences covering a long period8 . Such calibration les covering a long time-period may be put in the Calibration Database (CALDB see chapter 12) and also used to correct long term performance variations of the instruments.

11.4.2 Stage 2-2 { Rene the First FITS event les  Separate event les for minor observation modes

7 Examples of the items to be included in the Filter le are the following temperatures of the detectors, particle monitor counting rates, attitude and orbital information such as (in)stability of the pointing direction, magnetic cut-o rigidity, and times of the South Atlantic Anomaly passages. 8 In the case of ASCA, long term changes of the GIS temperature{gain coecients and SIS charge transfer ineciency are such examples. They are respectively recorded in the calibration les gis temp2gain.fits and sisph2piddmmyy.fits (where dd, mm and yy are date, month and year of the release respectively).

88

CHAPTER 11. DATA ANALYSIS AND PROCESSING SOFTWARE XIS has minor observation modes which may be known only by referencing the HK parameters. Presence of the Window option, the width and location of the Windows (section 5.3.2), and number of lines to add in the Parallel Sum mode (section 5.3.1) are such examples. The XIS HK items to distinguish minor modes are in the Filter le or HK les, and using maketime, a set of GTIs corresponding to individual minor observation modes is created. The extractor or fcopy FTOOLS will separate the input First FITS event le according to the GTI thus calculated. Another example of the minor mode on which First FITS event les are separated is the HXD time resolution, which is variable and may be known by looking at the corresponding HK parameters (p. 54). The separated event le names will have the minor mode and the sequence number attached to the original le name. For example, if there are two dierent Window options in the First FITS File ae19981019 1019 1954 xis0 5x5.evt, they will be named as ae19981019 1019 1954 xis0 5x5 win00.evt and ae19981019 1019 1954 xis0 5x5 win01.evt.  Calculate GTI and update the GTI extension in the event le GTI extensions in the FITS Files are preliminary, and correct GTI calculation may require cross-referencing several HK items. This task is carried out in this Stage with the FTOOL maketime, by referencing First HK FITS les or Filter le. It is assumed that all the necessary HK items to calculate GTI are included in the First HK FITS les or Filter le. An example of such GTI update is to exclude the GCC (Gross Cycle Control) period (section 4.1.2) from the XRS GTI, as the scientic data do not come out during that period. The GCC status may be known by looking at the corresponding HK parameter in the XRS HK le. GTI calculated in this Stage corresponds to the time intervals when observational data exist, regardless of the observational conditions (such as the high background rates). Calculation of the GTI suitable for scientic data analysis will be made in a later Stage (see section 11.5.1).

 Flag XRS cross-talk events, sort events in time order

By cross-correlating XRS event arrival times, nd and ag cross-talk events, which are false events due to cross-talk of the on-board event processing system. Also, sort events in time order, since in the telemetry some of the events output by CDP may not be in time order. These tasks are carried out with the FTOOL xrscrosstalk.  Calculate event arrival time using RAWY values in the XIS Timing mode In the XIS Timing mode, there is only one dimensional position information, and the RAWY values represent relative event arrival times (sections 5.3.1 and 5.3.3). A special tool will be necessary which reads Timing mode event les and overwrite the TIME column, calculating the event arrival times from the RAWY values. Location of the source on the detector will be necessary. This task is carried out by the FTOOL xistime.

11.4.3 Stage 2-3 { Apply Calibration and Fill Columns

Instrument specic calibration is performed and corresponding event le columns are lled. Observation specic, instantaneous calibration information should be extracted in advance at Stage 2-1. Other general calibration information is taken from CALDB (chapter 12). Following tasks will be performed.  Calculate PI from PHA PI values are calculated from PHA values for all the three instruments. The astetool functions will be used (section 9.1.3) in conjunction with appropriate calibration les (such as XRS gain history le). This task is carried out with the FTOOLS xrspi, xispi and hxdpi for XRS, XIS and HXD respectively.

ASTRO-E PDMP v1.3 (January 20, 2000)

89

 Calculate SKY Coordinates (XRS and XIS)

When the First FITS Files are created, only the coordinate columns to indicate locations on the detector are lled. Photon arrival direction on the sky is calculated for each event, and the coordinate columns to tell the sky positions are lled. To that end, instrument alignments, described in calibration les, and satellite attitude information, taken from the attitude le, are necessary. The FTOOLS xrscoord and xiscoord will be used for XRS and XIS respectively.

11.4.4 Stage 2-4 { Rening Calibrated FITS Files

Further processing of the Calibrated FITS Files, such as splitting the les by minor mode for the distribution to Guest Observers, may be carried out, as required. For example, the hardware teams may need to look at the XRS data during when the Filter Wheels are changing in order to check the instrumental performance. On the other hand, for scientic data analysis by Guest Observers, it will be more convenient that the event les are split according to the Filter Wheels used. Just like the minor mode operation task for XIS (section 11.4.2), combination of the FTOOLS maketime and extractor will do the necessary task. After the renements in this Stage, the Unscreened event
les are made for the distribution to Guest Observers. The Unscreened event les have all the necessary keywords, correct GTI extensions, and are split by instrumental modal parameters. They are ready for extraction of the scientic data products, except that they still include \noises" such as particle background events.

11.5 Stage 3 { Data Analysis The Unscreened event les and lter les are distributed to ASTRO-E Observers, and ready for data analysis. This Stage is primarily carried out by ASTRO-E Observers, but the standard data screening, extraction, and corresponding response generation may eventually be implemented in the Pipe-line processing, as the processing system is getting improved9.

11.5.1 Stage 3-1 { Data Screening

Data have to be screened to reject background before extracting scientic products. Data screening criteria are applied to the Unscreened event les, and the Screened event
les will be output.

Create Good Time Intervals using the Filter le GTI suitable for scientic analysis is calculated based on the HK parameters in the Filter le, by excluding time intervals when, for example, BGD is high, temperature of the instrument is not appropriate, elevation from the earth rim is too low, or satellite pointing direction is not stable. The generic maketime FTOOL can be used for this task, and GTI les are made. The GTI les are used to extract Screened event les or other scientic products such as images, spectra and light curves.

Filtering XIS data based on the Frame or Exposure XIS events in the telemetry come out in the discrete \frames", and one frame can have two or more \exposures" (section 5.3.2). Choosing or rejecting a batch of events in the same frame or exposure will be necessary, when, for example, telemetry saturation happened in particular frames. XIS event le has the frame extension to store the frame related parameters such as the frame saturation ag. 9 In the case of ASCA, implementation of the automated data screening, extraction and response generation into the pipe-line processing has required almost 4 years of study.

90

CHAPTER 11. DATA ANALYSIS AND PROCESSING SOFTWARE

Filtering Events

Event-by-event data selection is often necessary for all the three instruments using some kinds of event quality ags.

 XRS, XIS and HXD event selection based on event ags

In the XRS event FITS le, each event record carries six-bit event ags which tell quality of the event (section 4.4.1). For example, only the Hi-res events may be chosen for the best energy resolution by choosing the only events with all the event-ag bits being zero. Each XIS event has event Grade which is similar to the event quality ag. Usually, X-ray events have only certain Grade values 10, and events with other grades have to be discarded. HXD events may be also attached similar quality ags, as an output of the on-board event processing (section 6.3.4). The fselect FTOOL will be used for event selection based on the event quality ags.  Remove XIS hot-pixels XIS has an on-board hot-pixel detection algorithm and can send event lists without hot pixels (section 5.2.4). However, in order to conrm the on-board algorithm and to remove possible hot-pixels or ickering pixels, a program to remove hot-pixels will be necessary. The xisclean FTOOL, which will be analogous to the cleansis FTOOL for ASCA SIS, will be used.  HXD event selection on the Fast vs. Slow decay-time plane Pure GSO X-ray/gamma-ray events will fall onto a narrow region on the two dimensional Fast vs. Slow decay-time plane (section 6.3.1 gure 6.4). The on-board PSD is expected to discriminate and ag the GSO events (section 6.5.2). However, in order to check the onboard algorithm and to furthermore narrow the region to reduce background, a software task is necessary to lter only events falling on a particular region on the Fast vs. Slow decay-time plane. The flookup FTOOL is expected to be used 11 .  Separate HXD PIN and GSO events HXD WPU main data include the events which hit only GSO or PIN, or both. Data analysts may choose one of them according to their purposes. This may be done with the fselect FTOOL using event ags (section 6.5.2).

Data Screening Script { astescreen

Data screening tasks described above will be (semi-)automatically carried out with the astescreen script, which will be written in Perl and spawn several necessary FTOOL tasks. astescreen will be implemented in the Pipe-line processing (section 11.6) for standard data screening, and also used by Guest Observers to screen data with their own criteria.

11.5.2 Stage 3-2 { Extract Scientic Products

Scientic products, such as images, spectra, light curves, are extracted from the Screened event les, or from the Unscreened event les applying the GTI les created in the previous Stage. No calibration information is needed here, and generic software tools will be mostly used. Data analysts may apply their own data extracting criteria such as sky regions, time intervals, or energy ranges. The xselect FTOOL, in conjunction with extractor, will be mostly used. Scientic products to be created in this Stage should retain information on the conditions with which these products are extracted. These information will be used to generate instrumental responses and apply necessary corrections in the next Stage. For example, when an XRS spectrum In the case of ASCA SIS, it is customary to use only Grade 0, 2, 3 and 4 events. This is similar to the ASCA GIS screening on the two-dimensional PHA vs. Rise Time plane (gisclean), for which flookup is used. 10 11

ASTRO-E PDMP v1.3 (January 20, 2000)

91

is extracted from multiple pixels, the spectral le will have to keep the number of events from each pixel selected. xselect and/or extractor may need to be modied to implement such ASTRO-E specic requirements.

11.5.3 Stage 3-3 { Generate Observation Specic Responses

Observation specic instrumental responses are generated, and necessary corrections are performed. Inputs to this Stage are products created in the previous Stage, and outputs are observation specic responses or corrected products.

Response Generation for Spectral Analysis

To carry out spectral analysis, spectral responses are necessary which consists of RMF (Redistribution Matrix File) and ARF (Ancillary Response File). RMFs are two dimensional matrices which describe relationships between the input X-ray energies and output pulse-heights. ARF describes the telescope eective area or collimater transmission corresponding to the extracted energy spectra. Instrumental eciency may be included either in RMF or ARF.  Generate RMF If RMFs are invariable with time and observation conditions, they can be put in CALDB (as is the case for ASCA GIS). In general RMFs are specic to each observation and have to be created with RMF generators (like sisrmg for ASCA SIS). Inputs to the RMF generators are spectral les created in the previous Stage and calibration les from CALDB, outputs are observation specic RMF. The FTOOLS xrsrmg and xisrmg will be used for XRS and XIS respectively12 .  Generate ARF The XIS and XRS spectral le should keep the information on the event distribution on the chip/pixels, which is combined with the XRT response les (section 12.4.3) to calculate the ARFs. For XRS, in order to calculate ARFs for selected pixels, the pixel sizes, shapes and congurations are necessary, which are taken from the XRS pixel map (section 12.4.3). For HXD, ARF is calculated from source position in the FOV using HXD collimater responses (section 12.4.5). The astearf FTOOL will be used to create ASTRO-E ARFs for XRS and XIS, and hxdarf will be used for HXD.

Create Exposure maps and Vignetting maps

For each pixel of the XIS and XRS celestial images, exposure time is calculated and put in the corresponding exposure maps. Exposure map is necessary when obtaining counting rates of the sources and making a mosaic from multiple images. Attitude les will be necessary, as exposure maps are usually made in the SKY coordinate. The hot-pixel lists will also be necessary for XIS to correct pixels which are not used in creating the images. The vignetting maps describe the telescope vignetting and optionally instrumental eciency for given celestial images. Vignetting map is necessary to correct telescope vignetting and obtain source uxes through image analysis. XRT calibration les in CALDB will be necessary (section 12.4.2). The exposure maps and vignetting maps are made with the aeexpo FTOOL both for XRS and XIS.

Apply Corrections  Deadtime correction

The instrument deadtime is corrected for light curves, spectra and images. This is necessary for XRS and HXD to determine the correct exposure times and X-ray uxes for bright sources.

12

HXD GSO and PIN RMFs are expected to be time-invariable.

92

CHAPTER 11. DATA ANALYSIS AND PROCESSING SOFTWARE The FTOOLS xrsdtcor and hxddtcor are used for XRS and HXD respectively, using the Filter le created in Stage 2-5.  Barycentric correction The event arrival times on the satellite are converted to the arrival times expected at the barycenter of the solar system. This is necessary for precise timing analysis. The orbital le will be necessary. The timeconv FTOOL for ASCA is expected to be used with minimal modication for ASTRO-E too.

Generate Background Files

Background data will be necessary for precise spectral and image analysis. Because of the small FOV and extended XRT PSF, it will be dicult for XRS to take simultaneous background data in the same FOV, so will be for XIS when observing extended sources. Therefore, it is desirable to take blank sky data and night earth data in an early stage of the mission, and make the background database immediately available to Guest Observers. Background spectra and images are extracted using xselect from these blank sky or night earth background database. For HXD, non X-ray background will be calculated and reproduced based on some empirical models. The hxdbackest FTOOL will be used for this purpose.

11.5.4 Stage 3-4 { Scientic Analysis and Consideration

Scientic analysis is conducted using the scientic products and responses created in the previous two Stages. Observers make scientic consideration and judgment on their data analysis results. According to their needs, they may re-extract scientic products (back to Stage 3-2) and/or change data screening criteria (back to Stage 3-1). They may even go back to Stage 2 if they need to recalibrate the data or recreate the Filter le. In any case, they will never go back to Stage 1 (gure 11.1). Mostly, instrument independent generic data analysis packages, such as XSPEC for spectral analysis, XIMAGE for image analysis, and XRONOS for timing analysis, will be used in this Stage. ASTRO-E specic data analysis tools are explained below.

Image Analysis  Display XRS image, and superpose images or FOV of the three instruments

Since XRS is not a full image instrument and its pixel shapes and congurations are peculiar, a special tool is required to display XRS images on the sky. The xrsimage FTOOL will project the XRS pixel conguration on the sky, taking account of attitude wobbling. It will allow to overlap the XIS image and HXD FOV too. The XRS pixel map in CALDB (section 12.4.3 and 12.4.4) will be used to handle the XRS pixel shape and conguration. The HXD transmission map is also used (section 12.4.5).

11.6 Pipe-line Processing System At GSFC and ISAS, signicant parts of the data processing tasks described in the previous sections will be carried out automatically by running specially developed scripts. We call this automated system the Pipe-line processing. In the case of ASCA, the Pipe-line processing scripts have been developed at GSFC ADF. It contains over 14,000 lines of ksh code and is running only at GSFC. The ASTRO-E Pipe-line processing scripts is primarily developed at ADF, and written in Perl. The same processing script will run at ISAS, with the same versions of the calibration les and softwares. A particular care should be taken so that exactly the same processing scripts run at GSFC and ISAS (see section 8.2).

ASTRO-E PDMP v1.3 (January 20, 2000)

93

The Pipe-line processing mainly handles tasks in Stages 1 and 2 described in the previous section (gure 11.1). After Stage 2, data are delivered to ASTRO-E Observers, who are supposed to carry out most tasks at Stage 3, However, some tasks in Stages 3 may be also automated and implemented in the Pipe-line processing. As the calibration and softwares are updated, the Pipe-line processing system will be revised, and the same data will be reprocessed with the new system. The new products will be shipped to ASTRO-E Observers if the new processing is done within the proprietary period. The new products also replace the old ones in the ASTRO-E archives (chapter 14). To distinguish dierent versions of the Pipe-line processing system, they may be called REV0, REV1, REV2 and so on, for revision 0, 1, 2 and so on respectively. The REV0 pipe-line products are put under the HEASARC archive directory, ftp://legacy.gsfc.nasa.gov/astroe/data/rev0. All the ASTRO-E observations (including the ground test and calibration data) will be given unique sequence numbers, and each product is put in the directory named after the sequence number. For example, the sequence 90000450 is a ground test data (thermal vacuum test) taken at ISAS on September 3, 1999. That data is found at ftp://legacy.gsfc.nasa.gov/astroe/data/rev0/9/90000450, and there are the following sub-directories: aux/

calib/

fff/

hk/

unfiltered/

The aux directory includes the Filter le and other auxiliary les. calib includes the calibration les used to calibrate the event First FITS Files which locate in the fff directory. hk has the HK First FITS Files. Calibrated les (\unltered les") are in the unfiltered directory. Eventually, we are going to have filtered directory in which standard \ltered" event les will be put.

94

CHAPTER 11. DATA ANALYSIS AND PROCESSING SOFTWARE

Chapter 12

Calibration It is instrument teams' responsibility to calibrate instruments, release the results, and deliver to the calibration database (CALDB section 12.3). Products of the calibration activities are to be materialized in the forms of documents, softwares or calibration les. ASCA GOF is responsible for obtaining the calibration products from the instrument teams and providing them to GOs in either of the three forms.

12.1 Documentation In cooperation with the instrument teams and the OGIP CALDB team, ASTRO-E GOF will provide a set of documents which describe the ASTRO-E calibration. These documents should be public and available on-line in either of the text, postscript or HTML format. The document set should cover at least the following subjects:  Explain ground and in-orbit calibration ASTRO-E GOF will help the hardware teams to document the calibrations. It will be necessary to document when and how the ground and in-orbit calibrations are conducted, and which parameters are determined. Conguration of the calibration experiments should be illustrated.  Explanations of the calibration les The origins, formats, meanings, and usages of the calibration les stored in the CALDB (section 12.3 and 12.4) are explained.  Algorithms of building responses and making corrections Explain the algorithms to construct instrumental responses and perform instrument specic corrections using calibration les and softwares. For example, it should be explained how RMFs and ARFs are created from spectral les, and how exposure maps are made from event les and attitude les.  Summarize important calibration parameters Important satellite and instrument parameters determined through calibration are summarized. These parameters include, for example, positions of the optical axis for each sensor.  Calibration uncertainty Unexplainable systematic uncertainties of the latest responses are described so that data analysts are warned. It is instrument teams' responsibility to dene such calibration uncertainties. The latest calibration uncertainty information is distributed to Guest Observers with their data. News articles regarding the latest calibration issue shall appear in the ASTRO-E Newsletter, which is published by ASTRO-E GOF, from time to time. 95

96

CHAPTER 12. CALIBRATION

12.2 Calibration Software Calibration softwares are primarily written by the instrumental teams, and will be incorporated into the function libraries (section 9), simulation softwares (section 10.2) or response generators (section 11.5.3). ASTRO-E GOF will make the calibration softwares conform to the ASTRO-E software conventions (chapter 8). When constructing instrumental responses or carrying out instrument specic corrections, it is important that algorithms and parameters be separated as much as possible. The calibration softwares should dene parameter independent algorithms, whereas instrumental parameters should be put in the calibrations les. Thereby, when either of the algorithms or parameters are changed due to new calibration, only calibration softwares or les need to be changed. It will be also possible to make dierent test responses by changing only algorithms or parameters.

12.3 Calibration Database (CALDB) ASTRO-E calibration les shall be put in the HEASARC Calibration Database (CALDB)1 , which also contains calibration les for other high energy missions. All the calibration les in CALDB should conform to the OGIP standard FITS format.

12.3.1 Structure and Organization The master copy of the CALDB is located at GSFC under the anonymous ftp directory, ftp://legacy.gsfc.nasa.gov/caldb/. There are two sub-directories docs and data for documents and data respectively, and those for a particular mission are stored in docs/mission and data/mission, where mission is the name of the mission. There are instrument directories data/mission/instrument for each instrument, and each directory contains three sub-directories, pcf, bcf and cpf, which respectively stands for the primary calibration
les, basic calibration
les and calibration product
les. Primary calibration les are raw or almost-raw calibration data, and will not be directly used to construct instrument responses. Ground calibration data will be archived and regarded as Primary calibration data. Calibration les used to perform instrument specic corrections or to construct responses are called basic calibration les. Responses themselves or calibration les used in the Stage 8 data analysis (section 11.5.4) are called calibration product les. In the case of ASCA, we did not have primary calibration les. The GIS and SIS teldef
les, which carry important instrumental parameters such as dimensions, misalignments and positional gain variations of the sensors, are examples of the basic calibration les. SIS and GIS RMFs are calibration product les and put under the cpf directory. In the case of ASTRO-E, we have a plan to archive ground calibration data, which will be put under pcf. Most of the important calibration les listed below (section 12.4) are considered basic calibration les.

12.3.2 Time-dependent Calibration Files Some calibration les will be time-dependent. If timescale of the variation is long enough (> a couple of months) to include many observations, the time-variable calibration les may be put in CALDB to be used for the observations within the period. If the timescale is as short as the length of a single observation, the calibration les will be created in the pipe-line processing and used only for that particular observation (section 11.4). The XRS gain history le will be such an example, as well as the GIS gain history le for ASCA GIS, as XRS gain is expected to be variable within a single observation. These short timescale calibration les will not have to be put in CALDB. 1

See

http://heasarc.gsfc.nasa.gov/docs/heasarc/caldb/caldb intro.html.

ASTRO-E PDMP v1.3 (January 20, 2000)

97

12.3.3 Calibration File Name

Calibration les should be given unique names to indicate their contents and dates of the release, and a le name and the physical le should have one-to-one correspondence hence symbolic links should not be used. The calibration les must have the mandatory CALDB keywords which describe the nature of the les and are referenced by CALDB softwares (see below). Recommended naming convention for the ASTRO-E calibration les is the following: inst kind yyyy-mm-dd.ext

, or inst kind version.ext,

where inst is the name of the instrument 2 , kind is brief description of the le, yyyy, mm and dd are year, month and day of the release, respectively3 , version is the version, and ext is the le extension which can be fits or any other letters to describe the nature of the le (e.g., rmf or arf). The kind and version may include hyphens ('-') periods ('.') may not be used anywhere except just before ext. For example, the XRS pixel map (section 12.4.3) released on November 6 in 2000 may have a name like xrs pixel-map 2000-11-06.fits. Files may be named with the \version" scheme, such as hxd col transmission v1-0.fits. However, once les are named either in \yyyy-mmm-dd" scheme or \version" scheme, the same naming convention should be followed for the same kind of les, so that names in the two schemes are not mixed.

12.3.4 Version Control

Control of the version and release of the calibration les is very important. ASTRO-E GOF and instrument teams should establish the standard procedure to deliver the les to CALDB and release them. For each calibration le, there shall be a contact person in the instrument team and one in GOF, and after they checked the validity of the le and agreed to release, the le will be shipped to CALDB. CALDB already has an established scheme of the version control. Each instrument directory (/caldb/data/mission/instrument) has the index le named caldb.indx which contains brief descriptions for all the calibration les included in this directory and the sub-directories. These information are taken from the mandatory CALDB keywords in each calibration le. Also in the caldb.indx le are quality and validity ags of all the calibration les which are to be judged by ASTRO-E GOF and instrument teams. A package of the CALDB access softwares to choose appropriate calibration les referencing caldb.indx is provided by the CALDB team. The identical CALDB tree is mirrored to ISAS regularly, although the primary copy of the CALDB is maintained at GSFC. Guest Observers also can obtain and install the entire CALDB on their sites, or they may get only necessary les for their analysis.

12.4 Important Calibration Files ASTRO-E GOF and the instrument teams will determine which kinds of calibration les are necessary, and x their formats. Although it is not possible at this stage to dene all the necessary calibration les, important calibration les which will be denitely needed are listed below.

12.4.1 General

 Telescope denition les

Alignments between the telescopes and instruments are described. In addition, parameters of the instruments and the coordinate systems, such as focal lengths and detector pixel sizes are written. There may be separate telescope denition les for dierent detectors.

Either xrs, xis, xis-0, xis-1, xis-2, xis-3, hxd or aste (for general les). It is likely that the period of the calibration le release will spread over the year 2000. Therefore 4 digits will be desirable to denote years. So that les are sorted in chronicle order, year, month and date are put in this order. 2 3

98

CHAPTER 12. CALIBRATION

 Satellite Information Base (SIB)

Parameters for conversion from the digitized HK telemetry to the physical units are stored in the multimission database named Satellite Information Base (SIB) located at ISAS. Essential parts of the SIB will be extracted and put in the calibration les. These calibration les are used to interpret HK parameters in the telemetry(section 9.1.5).

12.4.2 XRT

 Eective area

XRT eective area corresponding to a certain encircled radius is given as a function of energy for dierent o-axis and azimuthal angles. Separate les are made for XRT-I and XRT-S. If eective areas for the four XRT-Is are dierent, there shall be more than one le for XRT-I. These les are made from calibration measurements and ray-tracing simulations (section 10.2.3), and used to calculate ARFs and vignetting maps (section 11.5.3).

 Point spread functions

Although point spread functions can be created from ray-tracing simulations, it will be convenient to have a set of ready-made point spread functions for dierent o-axis and azimuthal angles. If there is energy dependence, the point spread functions have to be made for dierent energies. Point spread functions are necessary when making ARFs (section 11.5.3) and for image analysis such as image tting and image deconvolution (section 11.5.4).

 Files for the ray-tracing simulations

The ray-tracing program (section 10.2.3) requires two calibration les describing the telescope parameters, one for reectivity and the other geometrical structure of the foils.

12.4.3 XRS

 XRS pixel map

The XRS pixel map indicates XRS pixel sizes, shapes, and congurations. This le will be used to calculate XRS ARFs for spectral les extracted from any combinations of the pixels, and to overlay the XRS FOV on the XIS images in the SKY coordinates.

 XRS pixel parameter le

Important XRS parameters required to build spectral responses are written. The parameters will include, for example, thickness and heat capacity of each HgTe absorber.

 Gain history le

The XRS gain, which is likely to be variable within a single observation, is written as a function of time. This le is created for individual observations at Stage 2 in the pipe-line processing and used to calculate PI from PHA (section 11.4).

 Blocking Filter parameters

Thickness and transmission for each Blocking Filter should be in a calibration le (section 4.1.3).

 Filter Wheel parameters

Thickness and transmission for each Filter Wheel window should be in a calibration le (section 4.1.5).

ASTRO-E PDMP v1.3 (January 20, 2000)

99

12.4.4 XIS

 XIS hot-pixel map

Positions of the hot-pixels. May slowly vary with time.  Time invariable XIS parameter le Important time invariable XIS parameters required to build spectral responses are written. The parameters will include, for example, thickness of the depletion layer for each CCD chip.  Time variable XIS calibration les Variable instrumental parameters required to calculate PI from PHA and to build spectral responses are written as functions of time. Gain history (pulse-peak of the calibration source) and Charge Transfer Ineciency (CTI) will be such examples. 4

12.4.5 HXD

 HXD collimater transmission map

Energy dependent collimater transmission is written as a function of the pointing vectors on the satellite frame. The direction which gives the maximum transmission becomes the bore-site. This le will be necessary to make HXD ARFs.  HXD detector parameter le Important detector parameters required to build responses are written. These parameters should include, e.g., dimensions of the GSO crystals, silicon PIN diodes and the detector assembly. This le will be necessary to make HXD RMFs.  HXD background parameter le The HXD background is expected to be empirically modeled (section 11.5.3). Model parameters necessary to construct HXD background will be in the calibration le.

In the case of ASCA SIS, RDD (Residual Dark-current Distribution) and echo parameters are also variable, and time history of these parameters are also saved in the individual calibration les. RDD is expected to be negligible for XIS (section 5.2.2). 4

100

CHAPTER 12. CALIBRATION

Chapter 13

Guest Observer Support In this chapter, we describe ASTRO-E GOF's primary tasks to support Guest Observers (GOs). The GOs whom ASTRO-E GOF mainly targets are professional astronomers located in the United States who submit ASTRO-E proposals and analyze ASTRO-E data. Support of the ASTRO-E Observers in Japan and other countries and the ASTRO-E archives users all over the world is also envisioned. In order to perform the following GO support tasks, ASTRO-E GOF in cooperation with ADF and other groups under OGIP will develop infrastructures such as softwares, documents and database systems. Also ASTRO-E GOF will give accounts for the GO support issues to the user community in occasions, and will provide personal assistance to GOs visiting GSFC.

13.1 On-line Service and Help ASTRO-E GOF release most updated information through WWW at the ASTRO-E GOF home page, http://heasarc.gsfc.nasa.gov/docs/astroe/astroegof.html . On-line e-mail help desk is available at [email protected], to which GOs can ask any questions regarding ASTRO-E. Recipients will be the ASTRO-E GOF members and some members of ADF. ASTRO-E GOF shall have a rota system with which one of GOF members by turns keeps track of the questions to make sure they are answered within reasonable time. There shall be extensive ASTRO-E on-line databases with which GOs can retrieve various ASTRO-E information as well as the archival data. Details on the ASTRO-E database and archives are explained in the next chapter.

13.2 Proposal Support NASA will ocially release the ASTRO-E NRA (NASA Research Announcement) to announce the GO opportunity of the ASTRO-E program. ASTRO-E GOF will be responsible for preparing NRA including instrumental specs required for GOs to prepare proposals. The in-depth instrumental descriptions will be supplied as NRA appendices. ASTRO-E GOF will supply simulation tools (section 10.2) and observation planning tools (section 10.1) which are intended to be used by GOs when preparing proposals. GO proposals will be submitted electronically through the Remote Proposal Submission system (RPS). RPS has been developed at OGIP and already commonly used for the current GO programs of other missions. The same RPS system will be used in US and Japan. The proposal database named ARGUS oversees the proposal processing status, like which proposals are submitted and accepted and if observations are scheduled, performed, processed or archived (section 14.1.2). 101

102

CHAPTER 13. GUEST OBSERVER SUPPORT

13.3 Observation Planning ASTRO-E GOF will give expert advice to GOs how to plan their observations, such as best instrumental modes, observational constraints, pointing directions, roll angles and so on. Preliminary observational plans should be given in the proposals, and the nal plans have to be conrmed by GOs prior to the observations (section 7.4.1). The procedure is that GOF members contact GOs when the short term observation schedule is released, and ask GOs if there might be any changes from the observations plans in the proposals. If necessary, GOs may make small changes at this stage (e.g., slight change of the roll-angle) consulting GOF advice. ASTRO-E GOF conveys the nal GO observation plans to ISAS, and the ISAS satellite operation team incorporates the nal plans into the command stream. When the observation is performed, the operation team at KSC briey describes the status of the observation in the daily operation reports, which will be immediately archived at ISAS and GSFC so that GOs can see the status of their observations. Quick look analysis may be done by the operation team at KSC in order to make sure the observation is correctly done. Rough light curves, images and energy spectra may be made, and plots of these products will be promptly sent to GOs through ISAS and/or GSFC.

13.4 Pipe-line Processing and Data Distribution ASTRO-E GOF and ADF receive the data from ISAS and process them by adding calibration information so that the processed data are ready to be extracted scientic information (section 11.1). The softwares for processing will be mainly developed by ASTRO-E GOF in cooperation with the instrument teams (section 11.1). The US GOs receive the processed data from GSFC. The distribution media will be CD-ROM as default, and optionally tape. DVD (Digital Versatile Disk) may become available. The proprietary GO data may be encrypted and put on-line using some reliable encryption protocol such as PGP. Thereby only GOs who are given the key can retrieve the data on-line and decode them.

13.5 Data Analysis Support It is prospected that GOs would obtain data analysis softwares from OGIP/ASTRO-E GOF through Internet, install them, and use them to analyze their data on their sites. The analysis softwares will be developed and supplied by ASTRO-E GOF and OGIP, and should be easy enough to install and use (section 8.1). Extensive documents and on-line help should be provided to assist software installation and use, and a standard and thorough data analysis manual should be written by ASTRO-E GOF. Whenever GOs had questions, they can inquire to the GOF by e-mail or they may call GOF members in an emergency. GOs may visit GSFC to analyze ASTRO-E data, if they need expert advice or tutoring, or they do not have sucient computing resources, or they need directly access the ASTRO-E/HEASARC database to retrieve huge amount of data. ASTRO-E GOF will have a rota system such that one of the members by turns takes care of a visiting GO.

13.6 Community Oversight An ASTRO-E Users Group will be established in order to provide advise on the ASTRO-E Guest Observer Facility services. The ASTRO-E Users Group and ASTRO-E GOF will have regular meetings to discuss guest observer support issues.

Chapter 14

ASTRO-E Database and Archives 14.1 ASTRO-E Databases ASTRO-E GOF will maintain a cluster of the on-line ASTRO-E databases to facilitate the GO support tasks. By accessing these databases, GOs will be able to browse and obtain ASTRO-E public information and archival data. Figure 14.1 indicates the structure of the ASTRO-E database cluster. These databases will be primarily developed at GSFC where the original copies will be located. The observation database may be primarily maintained at ISAS instead (section 14.1.3), and other databases may be mirrored to ISAS too.

14.1.1 Data Access

At HEASARC, astronomical catalogs and archival databases are may be accessed using the \W3Browse" interface. By inputting target names or coordinates on the W3Browse graphical interface, users can browse the databases and retrieve archival data for the desired targets.

14.1.2 Proposal Database

US GO proposals are submitted to and maintained at GSFC, while ISAS handles Japanese proposals separately. Both US and Japanese proposals are submitted electronically through RPS and all the accepted proposals are put in the proposal database. The proposal abstracts and other information such as observational modes and constraints will be public for the accepted proposals. The multi-mission proposal database named ARGUS oversees all the aspects of the proposals and observations, from their acceptance to the nal resting place in the public archives. W3Browse can be also used to browse proposal abstracts and other information. Using ARGUS or W3Browse, GOs can, for example, easily check if interested targets have been already proposed or not. Observation plans of the accepted proposals are copied to the observation database to make command plans.

14.1.3 Observation Database

The observation database keeps observation plans and the observation log. This database will be required both for the satellite operation at ISAS and the GO support at GSFC, hence will be located at both sites. Identical databases will be maintained at ISAS and GSFC. All the GO observations, IOC observations, TOO observations and calibration observations (section 7.1), are given unique sequence numbers, and their observation plans such as dates and time, instrumental modes and pointing directions are put in the observation database. At ISAS, the command planning softwares access the observation database to construct observation schedules and actual command streams to be sent to the satellite. After observations have been done, the observation database is used to check the completion of the observations at ISAS, and the observation log is made and stored. Status of the early stages of 103

Satellite

processed data

accepted proposals

Figure 14.1: Structure of the ASTRO-E database.

ADF

Processing Database

Pipe-line Processing

Data

Command Planning Software

ISAS

RPS

proposals

Guest Observers

HEASARC

Astro-E Archives

Observation Database

Observation Log

Observation Plans

Proposal Database

ARGUS

Archive Database

W3browse

104 CHAPTER 14. ASTRO-E DATABASE AND ARCHIVES

ASTRO-E PDMP v1.3 (January 20, 2000)

105

the data processing should be also recorded in the observation database, so that it is readily seen if the telemetry data are received and archived at ISAS, gone through the Stage 1 and 2 processing, and shipped to GSFC (section 11.1).

14.1.4 Processing Database

At ADF/GSFC, each step of the pipe-line processing (section 11.6), from the data reception to the shipment to GOs, is documented and recorded in the processing database. Processing database tells when and with which processing systems the data are processed. By accessing the processing database, GOs will be able to browse and retrieve their proprietary data through some encryption protocol (section 13.4), and anybody can browse and retrieve the public data. Since purpose of the processing database is dierent from other ASTRO-E databases, the processing database will be developed and maintained by ADF separately from those managed under W3Browse (gure 14.1).

14.1.5 Archive Database

After proprietary period is over, all the ASTRO-E data will be public (section 14.2). The archive database lists the observation sequences which have been made public. The archive database is driven by W3browse and connected to the ASTRO-E archives, so that users can browse and retrieve contents of the ASTRO-E archives using the W3Browse interface.

14.1.6 Product Database

There will be a separate database for the scientic products created in the pipe-line processing. Images, light curves and spectra of the sources of all the instruments will be generated (section 11.6). This database will be particularly useful to cross-correlate the sources detected with ASTROE and the sources listed in other catalogs or detected by other missions. For example, it will be possible to check if sources in the ROSAT All Sky Survey catalog are detected with ASTRO-E and to obtain their energy spectra and light curves. The product database is connected to the product archives (section 14.2.2), so that products can be retrieved through the W3Browse interface.

14.2 ASTRO-E Archives

14.2.1 Policy and Responsibilities

It is agreed that all the ASTRO-E data taken by XRS, XIS and HXD (including the TPU gammaray burst data section 6.5.4 and 7.2.8) should be made public after the proprietary periods. The High Energy Astrophysics Science Archive Research Center, HEASARC, which belongs to OGIP supports multi-mission X-ray and gamma-ray archival research. The ASTRO-E GOF, in cooperation with ADF, is responsible for creating the ASTRO-E archives and delivering it to the HEASARC. The HEASARC will then maintain the archives, while the ASTRO-E GOF will support archival research while the mission is still alive. At the end of the mission, the HEASARC takes over the archival user support responsibility.

14.2.2 Contents

The outputs of the pipe-line processing are immediately copied to the HEASARC as well as sent to GOs and kept encrypted until the end of the proprietary periods, when the data are decrypted (section 11.6). The products produced in the pipe-line processing will be put in subdirectories of each observation sequence. In addition, there will be a separate product archives for the catalogs as well as spectra and light curves of each source.

106

14.2.3 Archival Access

CHAPTER 14. ASTRO-E DATABASE AND ARCHIVES

The ASTRO-E archives will be put under the HEASARC anonymous ftp directory, ftp://legacy.gsfc.nasa.gov/data . There will be no restriction on the data access so that any user may access and retrieve the data through anonymous FTP. The data will be sorted by the observation sequence numbers, and users may directly go to the desired directories if they know the sequence numbers. However, we anticipate that most users will access the archives through the W3Browse interface by inputting source names or coordinates (section 14.1.5).

Appendix A

Acronym Acronyms often used in the Astro-E project are summarized with their full-names and related items.

Acronym Full Name

Related Item

ACHE ACM AOCS ACU ADF ADR AE AO AOCU APID ASC ASM AXAF

ADR Control and Housekeeping Electronics Accelometer Attitude and Orbit Control System Analogue Control Unit Astrophysics Data Facility Adiabatic De-magnetization Refrigerator Analogue Electronics Announcement of Opportunities Attitude and Orbit Control Unit Application Process ID AXAF Science Center Attached Sync Maker The Advance X-ray Astrophysics Facility

XRS

BAT BGO BCCU

Battery Bi4Ge3 O12 Battery Charge Control Unit

CAB CALDB CAP CCSDS CDP CLCW CMD CAB CRC CTI CTS

Command Answer Back Calibration Database Calorimeter Analogue Processor Consultative Committee for Space Data Systems Calorimeter Digital Processor Command Link Control Word Command Decoder Command Answer Back Cyclic Redundancy Code Charge Transfer Ineciency Calorimeter Thermal Sink

DAL DE DHU DIST

Data Access Layer Digital Electronics Data Handling Unit Power Distributer

HXD GSFC XRS

telemetry HXD

107

XRS XRS

XIS, ASCA SIS XRS

108

APPENDIX A. ACRONYM

DMA DMS DP DR DRV DSN DSP DVD DWR

Direct Memory Access Dewar Main Shell Data Processor Data Recorder Drive Deep Space Network Digital Signal Processor Digital Versatile Disk Dewar

EEPROM EOB EPT-SA ESA ETI

Electronically Erasable Programmable ROM Extensible Optical Bench

FDE FEA FTP FITS FOV FW

Filter wheel Driver Electronics Front End Assembly File Transfer Protocol Flexible Image Transport System Field of View Filter Wheel

GAS GCC GO(s) GOF GSFC GSO GTI GUI

Geomagnetic Aspect Sensor Gross Cycle Control Guest Observer(s) Guest Observers Facility Goddard Space Flight Center Gd2 SiO5 Good Time Intervals Graphic User Interface

HPD HCE HK HTML HTTP HXD

Harf Power Diameter Heater Control Electronics Housekeeping Hyper Text Makeup Language Hyper Text Transfer Protocol Hard X-ray Detector

IGPS INS IOC IRU ISAS IVCS

Ignition Power System Instrument-Satellite In Orbit Check-out Inertial Reference Unit Institute of Space and Astronautical Science Inner Vapor Cooled Shield

KEK KSC

Japanese acronym for National Laboratory for High Energy Physics Kagoshima Space Center

HXD

LHEA LSB

Laboratory for High Energy Astrophysics Least Signicant Bit

GSFC

MIT

Massachusetts Institute of Technology

XRS NASA XRS XRS XRS

European Space Agency Extended Time Counter XRS XRS XRS XRS HXD

XRS

109 MPDU MPU LSB MTQ MW

Multiplexing Protocol Data Unit Main Processing Unit Most Signicant Bit Magnetic Torquer Momentum Wheel

NASA NASDA NRA NSAS

National Aeronautics and Space Administration National Space Development Agency of Japan NASA Research Announcement Non-spinning Sun and Aspect Sensor

OG OGIP OP

Operational Group Oce of Guest Investigator Programs Operational Programs

PCU PGP PSF PHA PI PI PIM PIMMS PPU PSD PSU PV

Power Control Unit Pretty Good Privacy Point Spread Function Pulse Height Analyzer Pulse Invariance Principle Investigator Peripheral Interface Module Portable, Interactive, Multi-Mission Simulator Pixel Processing Unit Pulse Shape Discriminator Power Supply Unit Performance Verication

RAM RCS RDD RIKEN

Random Access Memory Reaction Control System Residuals of Dark Distribution Japanese acronym for Institute of Physics and Chemical Research Read Only Memory Remote Proposal Submission system Raw Packet Telemetry

ROM RPS RPT SANT SAP SBR S-BCN SDIP SHNT SHYB SI SIB SSW STT SWG

S-band Antenna Solar Array Paddle S-band Receiver

TAKO TBD TCE TCI

Timeline Assembler, Keyword Oriented To Be Determined TEC Control Electronics Telemetry Command Interface

XIS

HXD

ASCA SIS

S-band Duplexer Shunt Dissipater Scientic Instruments Satellite Information Base S-band Switch Star Tracker Science Working Group Astro-E planning XIS

110

APPENDIX A. ACRONYM

TEC TI TMS TMX TOO TPU

Thermal Electric Cooler Time Counter S-band Transmitter X-band Transmitter Target Of Opportunities Transient Processing Unit

XIS

VCS VCDU

Vapor Cooled Shields Virtual Channel Data Unit

XRS

WCS WDN WPU WWW

World Coordinate System

XANT XHYB XIS XPA XRS XRT

X-band Antenna

Well Processing Unit World Wide Web X-Ray Imaging Spectrometer X-band Power Amplier X-Ray Spectrometer X-Ray Telescope

HXD

HXD

Appendix B

Denition of the Coordinate System used for ASTRO-E B.1 Denition of the Coordinates The following coordinates are dened to describe event locations in the telemetry, on the detector, or on the sky. All the coordinates are written in the ASTRO-E event les.

 RAW coordinates:







 1 2

Original digitized values in the telemetry to identify pixels of the events. May not reect physical locations of the pixels on the sensor. For example, XIS RAW X and Y coordinates will have values from 0 to 255 on each Segment1. For XRS, the pixel ID, from 0 to 31, will represent the RAW coordinates. ACT coordinates: ACT is dened only for XIS. The ACT X and Y values are dened to represent actual pixel locations in the CCD chips. ACT XY will take 0 to 1023 to denote the 1024
1024 pixels in the chip. The XIS RAW to ACT conversion depends on the observation modes (such as Window Options) and will require housekeeping information.The XIS ACT coordinates is dened by looking-down the sensors. DET coordinates: Physical positions of the pixels within each sensor. Misalignments between the sensors are not taken into account. The DETX/Y coordinates are dened by looking up the sensor, such that the satellite +Y direction2 becomes the -DETY direction (the same as ASCA convention). The DET X and Y values take 1 to 256 for XRS, and 1 to 1024 for XIS. For XRS, the DET X/Y represents position of the center of each XRS pixel in the same unit as that of XIS. FOC coordinates: Focal plane coordinate common to all the sensors in unit of arcmin. Misalignments between the sensors as well as the dierence of the focal length are taken into account so that the FOC images of dierent sensors (both XRS and XIS) can be superposed. FOC is calculated from DET by linear transformation to represent the instrumental misalignment, i.e., the oset and the rotation angle, and the focal length of the XRT. Information of these misalignment and the focal length are written in the teldef les. SKY coordinates: Positions of the events on the sky. The conversion from FOC to SKY is made using the

Each of the four XIS sensors has a single CCD chip, and a single chip is divided into four Segment. Satellite Z-axis points the telescope direction, and +Y direction is toward the solar paddle.

111

112 APPENDIX B. DEFINITION OF THE COORDINATE SYSTEM USED FOR ASTRO-E satellite attitude in the attitude le and the alignment matrix (3
3) written in the teldef le. For each XIS event, the equatorial coordinates of the pixel center projected on a tangential plane are given3. For each XRS event, the equatorial coordinates of the pixel center as well as the roll angle of the pixel are given. The roll angle is necessary since the XRS pixel size is nite. In this scheme, it is important that the conversion from RAW to DET does not depend on the misalignments between the sensors. Therefore, DET XY, as well as RAW XY, can be written in the event FITS les without having the calibration information. The DET to FOC conversion requires information of the focal length and the misalignment between the sensors. The same routines/functions can be used for FOC to SKY conversions for dierent sensors not depending on the individual characteristics.

B.2 Implementation to the FITS Event Files B.2.1 Names of the Columns XIS XRS HXD SENSOR SENSOR { SENSOR RAW SEGMENT, RAWX, RAWY PIXEL { ACT ACTX, ACTY { { DET DETX, DETY DETX, DETY { FOC FOCX, FOCY FOCX, FOCY { SKY X, Y X, Y, ROLL {

B.2.2 Type and Range of the Columns XIS Type Minimum Maximum Origin Size of the Pixel SENSOR Integer 0 3 { { SEGMENT Integer 0 3 { { RAWX/Y Integer 0 255/1023 { { ACTX/Y Integer 0 1023 { 0.024 mm DETX/Y Integer 1 1024 512.5 0.024 mm FOCX/Y Integer (1 1536)a 768.5 0.0174 arcmin X/Y Integer (1 1536)a 768.5 0.0174 arcmin a : Default image region. The X and Y values can be outside of the region. The DETXY pixel sizes correspond to the physical pixel size of the XIS CCD. The XY pixel size corresponds to the angular size of a single XIS CCD pixel. To allow rotation of the image and some pshift of the pointing direction during the observation, the XY range is taken slightly bigger than 2
1024. There are several projection methods, such as -TAN, -SIN, -ARC and -STG. See http://www.cv.nrao.edu/fits/documents/wcs/wcs.all.ps for detail. The tangential projection (-TAN) is widely used, and will be adopted for ASTRO-E event les too. 3

B.2. IMPLEMENTATION TO THE FITS EVENT FILES

113

XRS

Type Minimum Maximum Origin Size of the Pixel PIXEL Integer 0 31 { { DETX/Y Integer 1 256 128.5 0.02274 mm FOCX/Y Integer 1 1536a 768.5 0.0174 arcmin X/Y Integer (1 1536)a 768.5 0.0174 arcmin ROLL Real 0.0 360.0b { { a : Default image region. The X and Y Values can be outside of the region. b : An angle of FOCY-axis from north (usually SKY Y-axis) when projected on the sky, measured to the counter clockwise direction in degree. To make the comparison of the XRS and XIS images easier, the same pixel sizes are used for the both sensors for FOCX/Y and X/Y, and the XRS DETXY pixel size is dened as (XIS pixel size)
(XRS focal length) / (XIS focal length).

HXD

Type Minimum Maximum Origin Size of the Pixel SENSOR Integer 0 15 { { HXD is not an imaging instrument and will not have coordinate columns. The average pointing direction may be written in the event FITS le header.

114 APPENDIX B. DEFINITION OF THE COORDINATE SYSTEM USED FOR ASTRO-E

Appendix C

Ftool developers guideline Here is a guideline by the GSFC ftools team for the programmers developing ASTRO-E ftools. This guideline is particularly aimed for Japanese instrument members who are developing in the ANL environment and going to convert ANL modules into ftools.

C.1 Items to be Delivered The delivery to the GSFC ASTRO-E GOF/ftools team should include the Software and test example(s).  Softwares { Source Codes { Parameter les (default) { Makele { Documents: in plain ASCII text and IRAF \lro" format.  Examples: { Relevant input les and resulted output les. { Test parameter les or test script.

C.2 Source codes

 You can nd useful informations in the URLS.

http://heasarc.gsfc.nasa.gov/ftools/others/develop/develop.html

(Ftools developer's guide, slightly outdated).

http://olegacy.gsfc.nasa.gov/docs/software/fitsio/c/c user/cfitsio.html

(CFITSIO manual for C programmer ) and

http://olegacy.gsfc.nasa.gov/docs/software/fitsio/c/c user/fitsio.html

   

(CFITSIO manual for Fortran programmer) Use the languages of ANSI C, ANSI C++ and FORTRAN 77 only. For scripts, use Perl 5.0 or Tcl/Tk 8.0. Comply with the standards of ANSI C, ANSI C++ or Fortran 77, don't use the systemdependent extensions or features. For codes of mixing FORTRAN and C(i.e, C calls Fortran and Fortran calls C), use cfortran.h from CERN. 115

116

APPENDIX C. FTOOL DEVELOPERS GUIDELINE

 For C or FORTRAN ftools, use the cdummyftool and fdummyftool as templates. They can          

be found in src/examples/src in FTOOLS release. Subroutine or function name must be unique. This is a requirement of packaging the ftools. Don't use the hard-coded \scanf" or command line options to read in the parameter in C or Fortran codes. Use XPI parameter interface. The routines are documented in ple.h for the C ftools. Don't directly write the message to stdout, use the fcecho or fcerr routines in cftools and xpi library. Put messages into the stdout directly will prevent the ftool to be used in a pipe line. If you don't want to use the fcecho/fcerr in your environment, as a compromise, you should use a centralized output routine and use it everywhere when you need \printf". Provide the English translations for the important comments written in other languages. For handling of Fitsle, use ctsio. Don't try to read/write the les by yourself. In C ftools, don't use the obsolete fc tsio routines, which are the wrapped Fortran tsio routines, which are the wrapped ctsio routines. Before calling the ctsio routine, make sure the error status is set to zero, otherwise, the routine returns immediately. After calling the ctsio routine, make sure that the error status still stays to zero. If not, provide the error handling and return gracefully. CFITSIO routine \open" automatically handles the lename parsing, le existing tests etc. Don't use any parsing routine or le open routines before open. It can hinder the abilities of ctsio to open a network le or compressed le. Finally, don't be fancy and clever, don't reinvent the wheel, and KISS (Keep It Simple, Stupid).

C.3 Parameters It is well documented in URL: http://heasarc.gsfc.nasa.gov/ftools/others/ples.html

C.4 Makeles We use \hmake", which is the \make" utility developed locally for the HEASARC software. We don't required developer to write the \hmake" style make le. However, we do appreciate the developer to provide a makele in one of the popular Unix platforms (OSF, Solaris, SunOS, HPUX, Linux or SGI). It helps us to learn the software and understand the dependencies between modules.

C.5 Documents The help le should be provided in a plain ASCII text le with the extension .txt. and a le with the IRAF \lro" format and extension .hlp. The \lro" format is quite similar to the UNIX nro/tro. You can nd it in any .hlp les in ftools distribution. The help le should include the following sections:

 Name: Name plus a one sentence description.  Usage: Synnopsis of the tool  Description: Detailed description of the tools.

C.5. DOCUMENTS

    

117

Parameters: Descriptions for each parameters. Examples: Examples of using the tool. Bugs: Known bugs or features of the tool. See Also: References to other relevant tools. Author: Authorship, credits and e-mail address for questions and bug reports (It is usually [email protected] or the help desk of the mission).

118

APPENDIX C. FTOOL DEVELOPERS GUIDELINE

Appendix D

Important Internet Addresses D.1 HTTP addresses Astro-E GOF at NASA/GSFC:

http://heasarc.gsfc.nasa.gov/docs/astroe/astroegof.html

ISAS X-ray Astronomy Group:

http://www.astro.isas.ac.jp/xray/mission/astroe/astroeE.html

ADF at GSFC:

http://hypatia.gsfc.nasa.gov/adf/adf.html

Astro-E page maintained by LHEA at NASA/GSFC:

http://lheawww.gsfc.nasa.gov/docs/xray/astroe/astroe.html

OGIP at GSFC:

http://heasarc.gsfc.nasa.gov/docs/lhea/668.html

HEASARC at GSFC:

http://heasarc.gsfc.nasa.gov

CALDB page:

http://heasarc.gsfc.nasa.gov/docs/heasarc/caldb/caldb intro.html

ARGUS page:

http://heasarc.gsfc.nasa.gov/cgi-bin/argus/argus.pl

RPS page:

http://heasarc.gsfc.nasa.gov/rps/

W3Browse page:

http://heasarc.gsfc.nasa.gov/W3Browse/

Skyview page:

http://skyview.gsfc.nasa.gov/skyview.html

119

120

APPENDIX D. IMPORTANT INTERNET ADDRESSES

D.2 FTP addresses Anonymous FTP address at NASA/GSFC:

ftp://legacy.gsfc.nasa.gov

D.3 E-mail addresses Astro-E on-line help desk {

[email protected]

Index cleansis 90 Clock modes 40 Command Decoder 17 Command Link Control Work (CLCW) 18 Copied pixels 38 CRC 18 cryogenics 27 cut-o rigidity 72 Cyclic Redundancy Code (CRC) 18 Dark Frame mode 42,45 Dark Initial mode 42,44 Dark Level RAM 42 Dark Levels 38 Dark Update mode 42,44 DARTS system 63 Data Access Layer (DAL) 72 Data Dump 33 Data Handling Unit 17 Data Processor (DP) 17,30 data rate 17 Data Recorder (DR) 11 Data Recorder 17 Delta-t cut 51 detector simulators 78 Dewar Main Shell (DMS) 30 DHU 55 Digital Signal Processor (DSP) 30 downlink 11 dp10 75 DSN (Deep Space Network) 11 DVD (Digital Versatile Disk) 102,62 echo 99 Editing modes 40 eective area 98 ESA (European Space Agency) 57 Euler angles 72 Event Lower Threshold 40 Event Upper Threshold 40 Exposure Area 37 exposure map 91 Extended HK (EHK) les 87 Extended Time counter (ETI) 18 Extensible Optical Bench 11 Filter le 87 Filter Wheel Drive Electronics (FDE) 30

1st Stage Software 83 2
2 mode 40 2nd Stage Softwares 85 3
3 mode 40 5
5 mode 40 ACHE 28 Active pixels 38 ADF (Astrophysics Data Facility) 77 Adjacent Pixels 43 adjusted derivative 31 ADR 28 Analog Control Unit (ACU) 48 anti coincidence 50 anticoincidence detector (XRS) 27 AO (Announce of Opportunities) 59 APID (Application Process ID) 18,32 ARF (Ancillary Response File) 91 ARF (Ancillary Response Files) 77 ARGUS 101 ASCII 65 ASTRO-E archives 61 ASTRO-E GOF 7 ASTRO-E Newsletter 95 ASTRO-E simulator 78 ASTRO-E time 71 ASTRO-E Users Group 102 Attached Sync Maker (ASM) 18 Attitude and Orbit Control System (AOCS) 17 Barycentric correction 92 basic calibration les 96 BGO 47 Blocking Filters 30 Burst option 41 byte compression 42 C++ 66,77 Calibration Database (CALDB) 96 calibration product les 96 Calorimeter Digital Processor (CDP) 30 Calorimeter Thermal Sink (CTS) 30 capacity { of the DR 11 CCSDS packets 17,18 CCSDS 17 CD-ROM 62 clean hit events 47,51 121

122 Filter Wheel 30 First FITS Files 62,66,83 First Stage Software 83 FITS (Flexible Image Transport System) 65 tsio 72 ookup 90 Fortran77 66 Fortran90 66 Frame mode 42,45 Frame Store Area 37 fselect 90 FTOOLS 65 g77 67 gamma-ray bursts 61 gcc 67 gisclean 90 Good Time Intervals (GTI) 75 Grade (XIS events) 42 Grade 44 Gross Cycle Control (GCC) 28 GSO 47 H-Over-Clocked pixels 38 HEASARC (High Energy Astrophysics Science Archive Research Center) 105,8 HgTe 27 Hi-res event 31 Histogram packets 54 hot pixel threshold 38 hot pixels 38 Hot-pixel RAM 40 Human table 35 HXD-PIN 55 In Orbit Check-out (IOC) phase 57 Inner Split Threshold 40,44 Inner Vapor Cooled Shield (IVCS) 30 KSC (Kagoshima Space Center) 11 ksh 92 leap second 71 Low-res event 31 Lumirror 25 Main Processing Unit (MPU) 37 maketime 89 MAKI 75 Mid-res event 31 mk1stts 83 mkcom1stts 83 mkhxd1stts 83 mkphlist 79 mkxis1stts 83 mkxrs1stts 83 MPDU 18 NASA Research Announcement (NRA) 60 NASDA (National Space Development Agency of Japan) 62

INDEX NASDA 81 NRA (NASA Research Announcement) 101,59 Observatory Time 60 OGIP 65 Optical Blocking Filter (OBF) 37 optimal lter 31 optimal pulse height 31 Outer Split Threshold 40,43 Outermost Pixels 43 Peripheral Interface Module 17 Perl 66,92 PGP encryption 102,62 PH (Pulse-height History) 52 PHA 88 PI (Pulse Invariance) 71 PI Program 51 PIMMS (Portable, Interactive, Multi-Mission Simulator) 77 PIN diodes 47 pipe-line processing 92 Pixel Processing Unit (PPU) 37 Pixel RAM 37 PI 88 point spread functions 98 Power Control Unit 17 primary calibration les 96 Principle Investigator (PI) 60 Pseudo events 50 Pulse Shape Discriminater (PSD) 50 q-parameters 72 Raw Packet Telemetry (RPT) les 81 ray-tracing package 77 RDD (Residual Dark-current Distribution) 38,99 response generators 78 RMF (Redistribution Matrix Files 77 RMF (Redistribution Matrix File 91 RPS (Remote Proposal submission System) 101 RPT (Raw Packet Telemetry) 62 RPT les (Raw Packet Telemetry les) 21,82 S-band 17 Satellite Information Base (SIB) 72,98 Science Working Group (SWG) 57 SIRIUS database 18,62,82 SIRIUS 82 South Atlantic Anomaly (SAA) 73 South Atlantic Anomaly 87 Split Threshold 42,44 subinstruments 21 TAKO (Timeline Assembler, Keyword Oriented) 75 TCE (TEC Control Electronics) 37 Tcl/Tk 66 TEC (Thermal Electric Cooler 37

INDEX teldef les 96 telemetry limit (XRS) 30 telemetry rate 11 TH (Time History) 52 Thermal Shield 25 Time Counter (TI) 18 timeconv 92 Timing mode 43 TPU (Transient Processing Units) 61 Transient Data 52,55 Transient Processing Units (TPU) 48 Unscreened event les 89 VCDU packet 18 VCID 18 vignetting map 91 Virtual Channel Data Unit (VCDU) 18 W3Browse 103 WebSpec 77 Well Processing Units (WPU) 48 Window option 41 X-band 11,17 XRS pixel map 98 xrssim 79 XRS 27 XSPEC 77

123

124

INDEX

Bibliography 1] \The Scientic Satellite Astro-E Interim Report" (\Kagaku Eisei Astro-E Chuukan Houkokusho"), ISAS, 1998, in Japanese 2] Serlemitsos, P. J. et al. 1995, PASJ, 47 105 3] Serlemitsos, P. J. and Soong, Y. 1996, Astrophys. Sp. Sci., 239, 177 4] Serlemitsos, P. J. 1997, \The Next Generation of X-ray Observatories", p. 123 5] Kamae, T. et al. 1996, SPIE, vol. 2806, 314 6] Takahashi, T. et al. 1996, A&A, 120, 645 7] Mukai, K. 1993, in Legacy, p. 65, ( http://heasarc.gsfc.nasa.gov/docs/journal/ogip fortran3.html )

125