ASTR - 京都大学 · ASTR OE Pro ject Data Managemen t Plan ASTR OE Guest Observ er F acilit y co de NASAGSF C Green b elt MD USA and ... and Astronautical Science ISAS F ollo wing

ASTRO�E Project

Data Management Plan

ASTRO�E Guest Observer Facilitycode �� NASA�GSFC� Greenbelt� MD �� USA�

andInstitute of Space and Astronautical Science

Yoshinodai� Sagamihara� Kanagawa� �� Japan

version �January ��

Comments and questions to

astroehelp�athena�gsfc�nasa�gov

Version Historyv�� November �� Internal distribution within ASTROE GOF�v�� December � �� Internal distribution within GSFC�v�� December �� Internal distribution within GSFC� Add XRS telemetryand FRF descriptions �section �� HXD chapter is rewritten with additionaltelemetry information �chapter �� Modify description on the satellite schedulingsoftwares �section �� A lot of minor modi�cations in Chapters � and � takingaccounts of comments from GSFC ASTROE software team members�

v�� January � � �� Minor modi�cations in Chapters to �� Correct typos�Distribute to ASTROE software team members in Japan�

v�� September �� The �rst �o�cial� version after the agreement is madebetween ISAS and ASTROE GOF�

v�� March �� Reorganized chapters related to mission operation and software�v�� April �� Minor changes in Chapters � through �� in accordance with theunderstanding at the software meeting and science working group meeting at ISASin March �� First public release version�

v�� January �� Add appendixes for ASTROE coordinates and FTOOLS development guideline� Updated the ASTROE FTOOLS list� XIS �x� mode telemetry structure is explained in detail� Many minor updates to re�ect the latest statusof the software development to date�

v�� January �� Current version�

Contents

� Introduction �

�� Mission Overview � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� The ASTROE Guest Observer Facility � � � � � � � � � � � � � � � � � � � � � � � � �

�� About This Document � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Related Documents � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� The ASTRO�E Mission ��

�� The Satellite � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Launch� Orbit and Operation � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Onboard Data System � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Data Processor �DP� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Data Recorder �DR� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Communication with Ground System � � � � � � � � � � � � � � � � � � � � � ��

�� ASTROE Telemetry � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� CCSDS Packets � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Telemetry Data Transfer � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� SIRIUS Database � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� SubInstruments � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� X�ray Telescopes �XRT� ��

�� Mirrors � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Method of Fabrication � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Thermal Shield � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� X�ray Spectrometer �XRS� ��

�� XRS Instrument � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Calorimeter Array � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Cryogenics and Refrigerator � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Blocking Filters � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Calibration Sources � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Filter Wheel � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� On Board Data Processing � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Outline � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Pulse Detection � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Pulse Height Determination � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� XRS Telemetry Structure � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� XRS APIDs � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Contents of the XRS Telemetry � � � � � � � � � � � � � � � � � � � � � � � � � ��

� CDP Science Data Structure � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� PHA Block � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Auxiliary Blocks � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�

� CONTENTS

� X�ray Imaging Spectrometer �XIS� �� XIS Hardware � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Onboard Data System � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� CCD Data Transfer � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Pulse Height Determination � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Onboard Event Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Hot Pixels � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Data Processing Modes � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Clock Modes � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Window and Burst option � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Editing Modes � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Event and Telemetry Structure � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Observation Modes � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Diagnostic Modes � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� XIS APID � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

Hard X�ray Detector �HXD� �� Sensor � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� BGO Shields � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� GSO Sensors � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� PIN Diodes � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Passive Fine Collimaters � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Electronics � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� HXDAE � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� HXDDE � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Onboard Data Processing � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Pulse Shape Discrimination � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Anti Coincidence � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Pseudo Event � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� PI Program � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� TPU Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Transient data � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Gammaray burst data � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Position determination � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� HXD Telemetry Structure � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� HXD APID � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� WPU main data � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� WPU sub data � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� TPU data � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� HK data � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Status Packets � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Dump Packets � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� Mission Operations �� Observation Program � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� De�nition of the Mission Phases � � � � � � � � � � � � � � � � � � � � � � � � �� Type of the Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Observatory Time � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� IOC Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� SWG Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� GO Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Calibration Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Target of Opportunity Observations � � � � � � � � � � � � � � � � � � � � � � �� Time Constraint Observations � � � � � � � � � � � � � � � � � � � � � � � � � �� HXD TPU Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

CONTENTS �

�� Proprietary Period � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Satellite Operations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Scheduling the Observations � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Operating the Satellite � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Data Flow � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Data Retrieval and Raw Data Archives � � � � � � � � � � � � � � � � � � � � �� Data Processing at ISAS and GSFC � � � � � � � � � � � � � � � � � � � � � � �� Data Delivery to ASTROE Observers � � � � � � � � � � � � � � � � � � � � � �� ASTROE Archives � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

Software Principles �� General Software Design Principles � � � � � � � � � � � � � � � � � � � � � � � � � � � �� ASTROE Speci�c Design Principles � � � � � � � � � � � � � � � � � � � � � � � � � � �� ASTROE Software Standards � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Languages � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Coding Rules and Compiler Requirements � � � � � � � � � � � � � � � � � � � �� Systems Supported � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Coordination and Version Control � � � � � � � � � � � � � � � � � � � � � � � �� Documentation � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� ASTROE FTOOLS Global Development Scheme � � � � � � � � � � � � � � � � � � � �

� ASTRO�E Function Libraries �� ASTROE Speci�c Tasks �astetool� � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Time Conversion � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Coordinate Conversion � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Energy Calibration � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Data Access Layer �DAL� functions � � � � � � � � � � � � � � � � � � � � � � �� HK Information Acquisition � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Other Tasks � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Attitude and Orbit Related Tasks �atFunctions� � � � � � � � � � � � � � � � � � � � �� Attitude Information � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Orbit Information � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Attitude and Orbit Information � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Raytracing function library �xrrt� � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Planning and Simulation Software �� Observation Planning Software � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� TAKO �Timeline Assembler� Keyword Oriented� � � � � � � � � � � � � � � � �� MAKI � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Simulation Software � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Counting Rate Simulation � PIMMS � � � � � � � � � � � � � � � � � � � � � � �� Spectral Simulation � XSPEC � � � � � � � � � � � � � � � � � � � � � � � � � � �� XRT Raytracing Package � xrrt � � � � � � � � � � � � � � � � � � � � � � � � �� Detector Simulators � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� EndtoEnd Simulator � xrssim � � � � � � � � � � � � � � � � � � � � � � � � � �� ASTROE Simulator and Data Analysis � � � � � � � � � � � � � � � � � � � � ��

�� Data Analysis and Processing Software �� Overview � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Stage � � Satellite Speci�c Calibration at ISAS � � � � � � � � � � � � � � � � � � � � ��

�� Orbit Determination � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Attitude Determination � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Create RPT �les from the SIRIUS Database � � � � � � � � � � � � � � � � � ��

�� Stage � � Conversion of the Telemetry to the First FITS Files � � � � � � � � � � � � �� First Stage Software � mk�st�ts � � � � � � � � � � � � � � � � � � � � � � � � ��

CONTENTS

�� First FITS File Names � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Stage � � Apply Instrument Speci�c Calibration � � � � � � � � � � � � � � � � � � � ��

�� Stage �� Preprocessing � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Stage �� Re�ne the First FITS event �les � � � � � � � � � � � � � � � � � � ��

�� Stage �� Apply Calibration and Fill Columns � � � � � � � � � � � � � � � ��

�� Stage � � Re�ning Calibrated FITS Files � � � � � � � � � � � � � � � � � � ��

�� Stage � � Data Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Stage �� Data Screening � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Stage �� Extract Scienti�c Products � � � � � � � � � � � � � � � � � � � � � ��

�� Stage �� Generate Observation Speci�c Responses � � � � � � � � � � � � � ��

�� Stage � � Scienti�c Analysis and Consideration � � � � � � � � � � � � � � � ��

�� Pipeline Processing System � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Calibration ��

�� Documentation � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Calibration Software � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Calibration Database �CALDB� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Structure and Organization � � � � � � � � � � � � � � � � � � � � � � � � � � � �

�� Timedependent Calibration Files � � � � � � � � � � � � � � � � � � � � � � � � �

�� Calibration File Name � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Version Control � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Important Calibration Files � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� General � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� XRT � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� XRS � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� XIS � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� HXD � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Guest Observer Support ��

�� Online Service and Help � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Proposal Support � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Observation Planning � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Pipeline Processing and Data Distribution � � � � � � � � � � � � � � � � � � � � � � ��

�� Data Analysis Support � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Community Oversight � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� ASTRO�E Database and Archives ��

�� ASTROE Databases � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Data Access � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Proposal Database � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Observation Database � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Processing Database � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Archive Database � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Product Database � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� ASTROE Archives � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Policy and Responsibilities � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Contents � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�� Archival Access � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

A Acronym ��

CONTENTS �

B De nition of the Coordinate System used for ASTRO�E ��B�� De�nition of the Coordinates � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��B�� Implementation to the FITS Event Files � � � � � � � � � � � � � � � � � � � � � � � � ��

B�� Names of the Columns � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��B�� Type and Range of the Columns � � � � � � � � � � � � � � � � � � � � � � � � ��

C Ftool developers guideline ��C�� Items to be Delivered � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��C�� Source codes � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��C�� Parameters � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� C� Make�les � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� C�� Documents � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

D Important Internet Addresses ��D�� HTTP addresses � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��D�� FTP addresses � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��D�� Email addresses � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

Index ��

Bibliography ��

CONTENTS

Chapter �

Introduction

�� Mission Overview

ASTROE will be the �fth Japanese Xray astronomical satellite launched by the Institute of Spaceand Astronautical Science �ISAS�� Following ASCA� which was launched in �� ASTROE isthe second ISAS astronomy satellite built in close collaboration with NASA� The current launchdate for ASTROE is February�March in ��ASTROE carries three sets of instrumentation� an Xray microcalorimeter �Xray Spectrom

eter� XRS�� four Xray CCD cameras �Xray Imaging Spectrometers� XIS�� and a Hard XrayDetector �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 Xray Telescopes �XRT�fabricated by NASA�GSFC and Nagoya University�XRS and XIS cover the soft energy band �� keV�� XRS has the highest energy resolution�

�E � �� eV �FWHM�� covering a � �� FOV by �� bilinear pixels� XIS has a FOV of ��with a moderate energy resolution �E � �� eV at keV� The XRT spatial resolution is about�� arcmin �HPD�� HXD is a low background collimated detector in the energy band � �� to ��keV with spectral resolutions of � � � �at � keV� to � �� at �� keV�� All the instrumentsoperate simultaneously and point the same direction� Thus� ASTROE will study Xray 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 �� liter� to completely melt down determines the mission life of XRS� this isexpected to be about two years� Thus XRS will be the primary instrument for the �rst two yearof the mission� during which the observation time is shared by the ASTROE team members andGuest Observers �GO�� After the initial XRS phase� the ASTROE observation time will be fullyopen to US and Japanese Guest Observers �see chapter � for the observation programs�� XIS andHXD have longer lives� though they may su�er some degradation due to radiation damage�It is expected that ASTROE will produce up to �� Gbytes of raw data daily �section ��

Therefore� total amount of the raw data per year will be � � Gbytes� Even after the �yr XRSmission life is �nished� the amount of the telemetry data may not be reduced since XIS and HXDcan be allocate to use more telemetry instead of XRS �section ��

�� The ASTRO�E Guest Observer Facility

The ASTROE Guest Observer Facility �GOF� located at NASA�s GSFC will be responsible forthe US Guest Observer support� This includes the following tasks�

� Supporting GO�s proposal preparation�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�

�

� CHAPTER �� INTRODUCTION

� Receiving� validating� processing� archiving and distributing the data� Providing documentations and ononline materials� Providing data analysis software and calibrations� Providing expert help to GOs� Populating the US ASTROE archive at the HEASARC

ASTROE GOF WWW home page is located at

http��heasarc�gsfc�nasa�gov�docs�astroe�astroegof�html �

ASTROE GOF belongs to the O�ce of Guest Investigator Programs �OGIP� at NASA�GSFC�Besides the ASTROE GOF� OGIP contains High Energy Astrophysical Science Archive ResearchCenter �HEASARC� and similar GOFs for other major high energy missions� HEASARC is a datacenter responsible for archiving data from past high energy astrophysical missions and constructinga userfriendly data analysis environment� ASTROE GOF will carry out its tasks in accordancewith HEASARC�

�� About This Document

This document de�nes the ASTROE data processing and software system which is e�ective afterthe data is delivered to the ASTROE science team at ISAS�We shall explain the ASTROE projectand data management plan from the view point of the end users� The data management planproposed in this document has been agreed by ISAS� the ASTROE GOF� the GSFC AstrophysicsData Facility �ADF�� and HEASARC� Expected readers of this document are program managersat ISAS� NASA HQ and GSFC� scientists and programmers working on the ASTROE project�and ASTROE users�Readers should be reminded that this document does not serve as the original source for

the technical information such as instrumental speci�cation and telemetry formats� or highlevelpolitical agreements such as allocation of the observation time between Japan and US� Thesetechnical and�or political issues are de�ned and documented in the original documents maintainedby ISAS and�or NASA� Description in this document on these issues is based on the originaldocuments� which are often written in Japanese� In particular� most of the technical informationdescribed through chapter � to is taken from the �ASTROE Interim Report� �� published byISAS in July �� in Japanese��In chapter �� general aspects of the ASTROE satellite are explained� In chapter � through

� the ASTROE scienti�c instruments are explained� In chapter �� how ASTROE is operatedand the observations are performed shall be explained� ASTROE software design principles andagreements are presented in chapter �� ASTROE software tasks required in the data processingand other aspects of the project are de�ned in chapter �� Important issues regarding the calibrationare given in chapter �� Tasks regarding the Guest Observer support are shown in chapter �� andASTROE archives are explained in chapter ��In appendix A� acronyms often used in the ASTROE project are explained� Important

ASTROE related Internet addresses are summarized in appendix D�

�� Related Documents

Other important issues which cannot be covered in this document will described in separateddocuments� The document sets will at least include the following issues�

� ASTROE FITS File Formats � FITS Formats of the ASTROE HK and event �les� calibration �les and other important �les �e�g�� attitude �les and orbit �les� are explained�

ASTRO�E PDMP v�� January ��

� ASTROE Calibration � How ASTROE instruments and data are calibrated is explained�See �� for details�

� Data analysis manual � Explains ASTROE Observers how to analyze ASTROE data usingsoftware tools supplied by GOF��

In addition� ASTROE GOF will publish the ASTRO�E Newsletter from time to time� whichwill provide up to date information on all mission issues� including calibrations� software� missionstatus and publications��

�This will be similar to the ASCA Data Reduction Guide �ABC Guide� provided by ASCA GOF� which isavailable both electronically and as paper copy� See http��heasarc�gsfc�nasa�gov�docs�asca�abc�abc�html forthe electronic version�

�From the launch of ASCA in February �� to April �� ASCA GOF published ve is�sues of ASCA Newsletter�� which is available both electronically and as a paper copy� Seehttp��heasarc�gsfc�nasa�gov�docs�asca�newsletters�html � for the electronic version�

�� CHAPTER �� INTRODUCTION

Chapter �

The ASTRO�E Mission

�� The Satellite

Figure �� is a drawing of the ASTROE satellite� The ASTROE will weigh about �� kg� The�ve Xray Telescopes �XRT�� one for XRS and four for XIS are put on the top of the ExtensibleOptical Bench �EOB� ��gure �� EOB is extended after the launch� and the total length of thesatellite will be �� m after the extension� Figure �� shows a schematic sideview of the ASTROEinstruments� The focal length of the XRTS �XRT for XRS� is �� m and those of the XRTI�� I��I�� I� �XRT for XIS� are �� m� The �ve telescope point the same direction ��Z direction�� andHXD� which collimates hard Xrays 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 baseplate

��gure �� Eight rectangular side panels surround the baseplate and compose the spacecraft�De�nition of the satellite coordinate system is indicated in �gure �� The pointing direction isde�ned as the �Z direction� and the solar array paddle� which supplies the power ��kW� faces the�Y direction� Note that XRS is put furthest from the Sun to avoid the heat�

�� Launch� Orbit and Operation

The ASTROE will be launched in February �� by the fourth MV rocket � from the ISAS�KagoshimaSpace Center �KSC�� located at the east longitude �� and the latitude �� TheASTROE orbit will be circular with the altitude � �� km and the inclination � �� degree�ASTROE 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 NASADSN �Deep Space Network� stations will not be used to download the data� since DSN may notprovide fast enough downlinks �see below�� ASTROE orbits the earth �� times a day� and KSCcan contact the satellite usually �ve times a day� each for up to � �� minutes�Note that the capacity of the Data Recorder �DR� will be Gbits� and the telemetry rate of

the data downlink of the Xband will be Mbps �see the next section�� Hence it would take � ��minutes to retrieve the entire data stored in DR� this is not possible within a single ground contactwhich is at most � �� minutes� Thus� e�ective operation programs should be invented to makethe maximum use of the DR� Typical amount of the data which can be retrieved during a groundcontact is � Gbits� which takes �� seconds to reproduce� Therefore� total amount of the raw datafor one day observation will be � Gbits�contact � � contacts �� Gbits � �� Gbytes�

�� On�board Data System

In �gure �� we show an outline of the ASTROE onboard data system� Explanations of theXRS� XIS and HXD systems are found in the chapters �� and � respectively�

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

��

�� CHAPTER �� THE ASTRO�E MISSION

Figure �� The ASTROE satellite� Unit of the scale is mm�


Figure �� The ASTROE Extensible Optical Bench �EOB�� The �gure shows the con�gurationafter the extension� EOB is shrunk during the launch� and extended after the launch in orbit�

� CHAPTER �� THE ASTRO�E MISSION

Figure �� A schematic sideview of the ASTROE instrument con�guration� All the instrumentspoint toward top of the satellite� which is de�ned as the satellite �Z direction�


Figure �� A topview of the ASTROE baseplate� Unit of the scale is mm� Solar panels areinstalled on the �Y side of the satellite body� XIS�� and � are located in the order of decreasingXcoordinate�o

� CHAPTER �� THE ASTRO�E MISSION

XR

T-I

3

XR

T-I

2

XR

T-I

1

XR

T-I

0

DP

XIS

-S0

XIS

-S1

XIS

-S2

XIS

-S3

AE

/TC

E-0

1

AE

/TC

E-2

3

PPU

01

PPU

23

MPU

HX

D-D

EH

XD

-AE

HX

D-S

XR

S-S

CA

PC

DP

AC

HE

FW

XR

T-S

FDE

XR

S

XIS

HX

D

DR

X-b

and

Ant

enna

Rep

rodu

ced

data

S-ba

ndA

nten

naC

omm

ands

Rea

l-tim

e da

ta ...A

CS

PCUD

HU

CM

D

Sub-

syst

ems

Figure �� Outline of the ASTROE onboard system block diagram�


�� Data Processor �DP�

The Data Processor �DP� handles most onboard data processing� DP receives scienti�c data fromXRS� XIS and HXD� and housekeeping data from Data Handling Unit �DHU�� DHU is the linkbetween the DP and subsystems such as the Attitude and Orbit Control System �AOCS� and thePower Control Unit �PCU��There are four data rates with which the instruments and DP produce the telemetry� Super�

High rate �maximum �� kbps�� High rate �� kbps�� Medium rate �� kbps� and Low rate ��kbps� ��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 �xedlength telemetry frame� The amount of the data DP receives from subsystems can be variablewith commands� For example� after the mission life of XRS is �nished� DP can quit receiving datafrom XRS and instead increase amount of the data to receive from other instruments� On theground station� the �xed telemetry frame data is depacketed to reproduce the variable CCSDSpackets� The ASTROE telemetry format is explained in section �� in more detail�

�� Data Recorder �DR�

After the processing� DP sends the data to the realtime telemetry during the ground contact� orto the Data Recorder �DR� during out of the contact� The data stored in DR are reproduced andsent to the ground station via DP during the ground contact� The capacity of the DR is � Gbits�Maximum rate of the data recording is �� kbps and that of reproducing is Mbps�

�� Communication with Ground System

ASTROE uses two di�erent wavebands and antennas for the communicationwith the KSC groundstation� Xband has the telemetry rate Mbps� and is mostly used to downlink the reproduceddata from the DR ��gure �� Sband� whose maximum telemetry rate is � � kbps� is mainly usedto receive commands and for realtime communication ��gure �� Command signals from theground station are received by the Sband receiver on the satellite� then decoded by the CommandDecoder �CMD�� and sent to the DHU� DHU distributes the commands to each instrument throughPeripheral Interface Modules �PIM� attached to each instrument� Real time commands can besent from the ground station to each instrument in realtime� Also� DHU can hold programmedcommand sequences� and the commands can be sent to each instrument from DHU sequentiallyafter the ground contact� This is called Organized Operation� The basic unit of the OrganizedOperation is called OG �Operational Group�� Sequence of the OG is named Operational Program�OP��

�� ASTRO�E Telemetry

�� CCSDS Packets

ASTROE adopts the CCSDS packet telemetry� Before being sent to the DP� the XRS� XISand HXD data are edited and made into the CCSDS packets by DP�XRSDE� XISMPU �MainProcessing Unit� and HXDDE� respectively �� DHU converts the data from other nonscienti�cinstruments into the CCSDS packets� The process to convert the data into the CCSDS packetscomprises the �segmentation� �divide data into pieces� and the �encapsulation� �add headers toeach piece��

�XIS will take most of the scientic data� For typical observations� XIS will require � �� kbps� and for brightsources �like Crab nebula� it will take �� kbps� Housekeeping data� which are handled by DHU� take up to��kbps�

�XRS�CDP �Calorimeter Digital Processor� does not have a capability to edit the CCSDS packet� hence a part ofthe DP takes care of converting the XRS data into the CCSDS packets� this part of the DP is named DP�XRS�DE�


A single CCSDS packet consists of the byte primary header� byte secondary header� andthe user data with a variable length of � to �� bytes� User data of the XRS� XIS and HXDCCSDS packets can be variable from � to �� bytes� User data of the CCSDS packets generatedby DHU have the �xed length � bytes� Figure �� shows the CCSDS packet format��The ��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 followingfour bits are for the instrument�subsystem ID� and the last �bit data type ID depends on theinstrument�subsystem ��gure �� Explanation of the data type ID will be given in later chaptersfor each instrument �sections �� and �� The ��bit secondary header tells the satellite time�Time Counter� TI�� in which the LSB is �� sec�

�� Telemetry Data Transfer

CCSDS packets are edited by DP and embedded in the �x format telemetry frames� First� variableCCSDS packets having the same Virtual Channel ID �VCID� are divided or concatenated to forma �� bit Multiplexing Protocol Data Unit �MPDU��gure �� A single MPDU packet has a � bit header and a �� bit MPDU� The least signi�cant �� 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 � bit VCDU primary

header and a � bit VCDU trailer to the beginning and end of a single MPDU packet� The bitVirtual Channel ID �VCID� in the VCDU header describes the content of the VCDU ��gure ��The VCDU trailer consists of the �� bit Command Link Control Work �CLCW� and the � bitCyclic Redundancy Code �CRC�� These are used to detect any data transmission errors�A �� bit sync maker �Attached Sync Maker� ASM� is attached to the beginning of a VCDU

packet� and a single �� byte ASTROE telemetry data unit is made� This is the telemetry datatransmission unit from the satellite to the KSC ground station�

�� SIRIUS Database

When the telemetry data is received� a ��byte telemetry header is attached at the ground station��gure �� Information such as data receive time� orbital pass number� communication radioband �Sband or Xband�� 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 perma

nently stored in the ISAS database named �SIRIUS� after minimumdata processing� The SIRIUSdatabase 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�

�� Obtain the telemetry data� and identify them as Sband real� Xband real� or Xband playbackdata�

�� Separate these data by di�erent VCID�

�� Merge Sband real and Xband real data with the same VCID�

� Merge real data and Xband playback data with the same VCID� and reset the VCID to thereal one� The original VCID is kept in the ��byte SIRIUS header ��gure �� Now� therewill be �ve �les for a single sequence� corresponding to the VCID � to � ��gure ��

�� Copy the TI of the �rst CCSDS packet in the telemetry data to the SIRIUS header afteradding upper � bits� The � bit time counter thus made is called Extended Time counter�ETI��

�See gures on p�� to p�� in �� for details��Unit of a single SIRIUS sequence is rather arbitrary� and not necessarily corresponding to the observational

sequence�


Pri

mar

y H

eade

r (6

byt

es =

48

bits

)S

econ

dary

Hea

der

(Tim

e C

ount

er; T

I)

Use

r D

ata

Ver

sion

Typ

eS

ec. H

eade

r F

lag

App

lica

tion

P

roce

ss I

D

3 bi

ts/0

001

bit/

01

bit/

111

bit

Seq

uenc

efl

ag

leng

th/v

alue

(if

cons

tant

)

Seq

uenc

eC

ount

Pac

ket

leng

th

2 bi

ts14

bit

s16

bit

s4

byte

s0~

6553

2 by

tes

com

mon

use

2 bi

ts

11 10 01 00

Res

erve

dH

ouse

keep

ing

Mem

ory

data

or D

ump

data

Sci

ence

and

oth

er d

ata

data

type

ID

5 bi

tssu

bsys

tem

ID

4 bi

ts

0001

0010

0011

0100

0101

0110

0111

1000

1001

1010

DH

UA

OC

UT

CI

HC

ED

IST

DP

XR

SX

ISH

XD

HK

Dep

ends

on

the

subs

yste

m

DH

U: D

ata

Han

dlin

g U

nit

AO

CU

: Att

itud

e an

d O

rbit

Con

trol

Uni

tT

CI:

Tel

emet

ry C

omm

and

Inte

rfac

eH

CE

: Hea

ter

Con

trol

Ele

ctro

nics

DIS

T: P

ower

Dis

trib

uter

DP

: Dat

a P

roce

ssor

A p

art o

f th

e di

vide

d da

ta (

not f

irst

nor

last

)

Dat

a is

com

plet

ein

a s

ingl

e pa

cket

The

fir

st s

egm

ent

of th

e di

vide

d da

ta

The

last

seg

men

t of

the

divi

ded

data

00 01 10 11

LS

B is

1/4

096

sec

Figure �� The CCSDS packet format�


VC

DU

pri

mar

y he

ader

(48

bit

s)

Vir

tual

Cha

nnel

Dat

a U

nit (

VC

DU

)(8

064

bits

)

VC

DU

trai

ler

Mul

tipl

exin

g P

roto

col D

ata

Uni

t (M

PD

U)

(804

8 bi

ts)

MP

DU

hea

der(

16 b

its)

CC

SD

S p

acke

tC

CS

DS

pac

ket

CC

SD

S p

acke

tC

CS

DS

pac

ket

.....

Eac

h C

CS

DS

pac

ket l

engt

h is

vari

able

(80

to 6

5612

byt

es)

CL

CW

(32

bits

)C

RC

(16

bits

)

firs

t CC

SD

S p

acke

the

ader

poi

nter

(11

bits

)N

ot u

sed

0000

0

Ver

sion

N

o.(2

bits

)S

pace

craf

tID

VC

IDV

CD

Uco

unte

rN

ot u

sed

(8bi

t)

0100

0001

016

bits

24 b

its

0000

0000

real

-ti

me

data

repr

o-du

ced

data

scie

nce

data

scie

nce

data

sate

llit

em

anag

emen

t

sate

llit

em

anag

emen

t

XR

S d

ata

DP

,XR

S,X

IS, H

XD

sta

tus

tim

e as

sign

men

tD

P a

nd D

HU

tim

e

Mea

ning

com

mon

inst

. sta

tus,

AO

CS

dat

a

com

mon

inst

. sta

tus,

AO

CS

dat

a

DP

,XR

S,X

IS, H

XD

sta

tus

XIS

dat

aH

XD

dat

a

XR

S d

ata

XIS

dat

a

HX

D d

ata

0000

00

0000

01

0000

10

0000

11

0001

0000

0101

1000

01

1000

10

1000

11

1001

00

1001

01

VC

IDC

ateg

ory

VC

DU

pac

ket (

8160

bit

s)A

ttac

hed

Syn

c M

aker

(32

bit

s)

A s

ingl

e A

stro

-E te

lem

etry

dat

a un

it (

8192

bit

s=10

24 b

ytes

)

1AC

FF

C1D

h

Tel

emet

ry D

ata

(819

2 bi

ts)

Tel

emet

ry H

eade

r (

256

bits

)S

IRIU

S H

eade

r (

256

bits

) SIR

IUS

dat

a fo

rmat

Figure �� The ASTROE telemetry data frame structure�


The SIRIUS database may be accessed only within ISAS� The ISAS ASTROE team willregularly access the SIRIUS database to create the First FITS Files� which will be the start pointof all the instrumental calibration and scienti�c data analysis �chapter � and �� Simultaneously�the Raw Packet Telemetry �RPT� FITS �les are created and sent to GSFC for a backup of theraw telemetry �les �chapter ��

�� Sub�Instruments

Names and their abbreviations of ASTROE subinstruments which are not directly related to thescienti�c observations are summarized here�

Power Supply Sub�SystemsSolar Array Paddle SAPPower Control Unit PCUBattery Charge Control Unit BCCUBattery BATShunt Dissipater SHNTPower Distributer DISTPower Supply Unit PSU

Communication Sub�SystemsSband Antenna SANTXband Antenna XANTSband Duplexer SDIPSband Switch SSW

SHYBXHYB

Sband Transmitter TMSXband Transmitter TMX

SBCNSband Receiver SBRXband Power Ampli�er XPA

Data Handling Sub�SystemsCommand Decoder CMDData Handling Unit DHUPeripheral Interface Module PIMTelemetry Command Interface TCIData Processor DPData Recorder DRHousekeeping HK

Launch Operation Sub�SystemsEPTSA

InstrumentSatellite INSIgnition Power System IGPS

Attitude and Orbit Control Sub�SystemsAttitude and Orbit Control Unit AOCUDrive DRVMagnetic Torquer MTQMomentum Wheel MWStar Tracker STT


Nonspinning Sun and Aspect Sensor NSASGeomagnetic Aspect Sensor GASInertial Reference Unit IRUAccelerometer ACM

Propulsion Sub�SystemsReaction Control System RCS

Thermal Sub�SystemsHeater Control Electronics HCE

Chapter �

X�ray Telescopes �XRT�

�� Mirrors

ASTROE Xray telescopes �XRT� consists of nested conical thinfoil mirrors which share similardesign concepts with ASCA XRT �� but with several improvements �� ASTROE carries�ve XRTs� four identical ones for four XISs �XRTI� and one for XRS �XRTS��In table �� characteristics of ASCA and ASTROE XRT are compared� Each mirror unit

consists of two layers� the top layer is the primary mirror and the bottom layer is the secondarymirror� Each layer is divided into quadrants� hence each mirror unit is composed of eight identicalquadrants� The half powerdiameter �HPD� is better than ASCA XRT by about a factor of two�which is mainly due to improved surface smoothness �section �� Compared to ASCA XRT� theratio of the focal length over the diameter is smaller� thereby incident angles of the Xrays to themirror surface are smaller �table �� This leads to better re�ectivity in the high energy bandabove � � keV�Re�ective mirror surface is coated by gold for XRTI or by platinum for XRTS� Platinum has

a higher electron density than gold� since its density �� g cm�� is higher than that of gold ��g cm�� while their atomic numbers are similar �� and �� for platinum and gold� respectively��Thereby XRTS will have higher Xray re�ectivity in high energies� This will compensate theshorter focal length of the XRTS ��gure �� and the XRTS and XRTI will have comparablee�ective areas at the higher energies �table ��

�� Method of Fabrication

Although both ASCA and ASTROE mirrors employ conical aluminum substrate and gold �orplatinum� surface� method of the fabrication is di�erent�The ASCA mirrors are made by shaping aluminum foils into the desired conical shapes� then

dipped in a �lacquer� to impart a � ��m acrylic layer which smoothes surface defects on a scale of�� m or smaller� Then a �� A gold is vacuum deposited over the acrylic layer �� The focusingblurriness of ASCA XRT� HPD � � arcmin� which is � seven times the theoretical limit allowedby the conical approximation of the re�ecting surface� is mainly attributed to midfrequency ��mm� surface roughness ��To circumvent this e�ect� �surface replication� is adopted for the fabrication of ASTROE XRT�

In this method� by putting very thin �� m� epoxy layer between a rough conical aluminumsubstrate and a smooth �mandrel�� then separating the two at the mandrel surface� characteristicsof the smooth mandrels are transferred onto the mirror surface�� A gold layer loosely adhering tothe mandrel acts both as the release agent as well as the re�ecting surface of the replicated mirror�� The ASTROE mirror� thus made� is achieving the � � arcmin HPD image size goal� halving

�Instead of using pre�made substrate� the mirror substrate may be electro�formed on the mandrel� This methodis used for SAX and XMM mirrors�

��

� CHAPTER �� X�RAY TELESCOPES �XRT�

ASCA ASTROEXRTS XRTI

Production Method Acrylic coating Surface ReplicationFocal Length ��m �� m �� mNumber of telescopes � Substrates Aluminum AluminumSubstrate Thickness �� m �� mRe�ecting Surface Au Pt AuThickness of the Surface �� A � �� AOther Structure Acrylic lacquer �nish �� m� Epoxy coupling layer �� m�Inner Diameter �� mm �� mm �� mmOuter Diameter �� mm �� mm �� mmMirror Length �� mm �� mmNo� of Foils to Nest �for one quadrant�a �� Primary incident angle ��

Weight�telescope �� kg �� kgGeometry Area�telescope �� cm� �� cm� �� cm�

Filed of View� keV ��

� keV � � ��

E�ective Area�telescope�� keV �� cm� �� cm�

keV �� cm� �� cm�

Half Power Diameter � arcmin �� arcmin

a� Number of foils per mirror is eight times�

Table �� Comparison of ASCA and ASTROE XRT� Taken from the table in �� p� �� TheASTROE HPD value is updated based on the recent ground calibration�


the discrepancy between the ASCA XRT focusing performance and the theoretical limit allowedby the conical approximation ��

�� Thermal Shield

It is undesirable that the telescope cools much rapidly than the satellite body� this could lead todegradation of the performance through deformation of the telescope structure� and absorptionof the outgas from the satellite on the mirror surface� Therefore� a thermal shield is put on thetop 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 XRTthermal shield is made of PET �C��H�O�� Toray Lumirror

�� coated with the aluminum surface�Thickness of the thermal shield and the aluminum coating is �� m and �� m respectively�and their densities are �� g cm�� and �� g cm�� The thermal shield is supported by a meshstructure made of stainless wires of the �� mm width� Thickness of the thermal shield is �� mmand the cell size is �mm�

�The same material as Dupont Mylar�

� CHAPTER �� X�RAY TELESCOPES �XRT�

Chapter �

X�ray Spectrometer �XRS�

�� XRS Instrument

The ASTROE XRS will be the �rst Xray microcalorimeter �own on an orbiting observatory ��The Xray microcalorimeters� the Adiabatic Demagnetization Refrigerator �ADR� and the liquidhelium tank are supplied by GSFC� The solid neon tank surrounding the helium tank is built byISAS� and the Filter Wheel �section �� is developed at Tokyo Metropolitan University� XRSwill have an unprecedented energy resolution of � �� eV �FWHM� over the �� keV energyband� The e�ciency is nearly unity over the entire bandpass� which is about an order of magnitudebetter than dispersive spectrometers such as Xray gratings�

�� Calorimeter Array

Xray calorimeters measure energy of the incident Xray photon by determining temperature ofthe absorbing material� which has to be su�ciently opaque to Xrays� Energy resolution of thecalorimeter is higher for lower heat capacity of the absorber� In ASTROE XRS� mercury telluride�HgTe� was chosen as the absorber to satisfy these requirements�The calorimeter array has � � � pixels ��gure �� Each pixel size is �� mm � ��

mm and the �� staggered pixels cover � � � �� on the sky� On each pixel� the HgTe absorberis attached on the monolithic silicon substrate in which the thermistor is ionimplanted� Thethermistor changes its resistance with the temperature in the range of �� megaohms� and asa result the temperature increase is detected as a change of the voltage across it� Signal fromeach thermistor is picked up by the JFET and sent to the Calorimeter Analogue Processor �CAP��gure �� CAP provides power to the detector and ampli�es the signals by a factor of ��CAP has �� channels� each of which handles data from a single calorimeter pixel�The detector assembly will have to be kept at � mK within accuracy of tens of microKelvins

to operate at the maximum performance� The rise time of the temperature is a few millisecond�and the total recovery time is about �� ms� which determines the maximum counting rate of theobservable sources�Beneath the calorimeter array� a silicon PIN anticoincidence detector is put in order to detect

background particles which penetrate the calorimeter array� XRS events which are simultaneouslydetected with the anticoincidence detector are �agged �section �� and may be rejected in laterdata analysis�

�� Cryogenics and Refrigerator

The instrument is contained in the insulated dewar� which consists of nested shells� At the centerof the dewar is the helium tank �lled with � �� liter liquid helium whose temperature is about ��

�Details of the XRS instrument are explained on the WWW page maintenanced by the XRS team athttp��lheawww�gsfc�nasa�gov�docs�xray�astroe�ae�xrs�html � Description in this chapter is largely owing tothis WWW page and the XRS section in ��

��

�� CHAPTER � X�RAY SPECTROMETER �XRS�

Figure �� XRS bilinear pixel con�guration on the detector plane �in the DETECTOR coordinates�appendix B�� looking up the sky��

K� It is surrounded by the neon tank which is �lled with �� liter solid neon at a temperature ofabout �� K� The time required for all the solid neon to completely melt determines the lifetimeof XRS� which is expected to be about two years�

Inside the helium tank� the XRS detector assembly �named Front End Assembly � FEA� is putand thermally connected to the Adiabatic Demagnetization Refrigerator �ADR�� which cools theFEA down to � mK� The ADR works �rst by aligning the magnetic moments �electron spins�of the molecules in the saltpill by superconducting magnet ��gure �� Then the saltpill isconnected to the liquid helium bath via the heat switch� allowing it to cool down to the liquidhelium temperature� Once it has reached the equilibrium� the heat switch is opened� and at thispoint the magnetic �eld is reduced to nearly zero� The spins of the salt molecules are therebyallowed to �ip in random directions to reach a high entropy state �adiabatically demagnetized��The heat to increase the entropy is absorbed from the saltpill� thus the saltpill� and the detector�is cooled� The ASTROE ADR can keep the detector at the desirable temperature for � �� 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 lastingabout � minutes�� will be performed once every � �� hours� This is called the Gross Cycle Control�GCC�� The recharge process will be carried out when observing targets are occulted by the Earthso as not to interrupt the observations� The temperature is maintained at the desired level withintens of microKelvins� 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 theADR and control the ADR temperature at the desirable level�

�The magnetic current is gradually increased to � � A �ramp up�� kept at that level� and gradually decreasedclose to the level at the normal operation�ramp down�� Each process will take � �� min�


CA

P-A

(16

cha

nnel

s)

CA

P-B

(16

cha

nnel

s)

Salt

Pill

Hea

t S

wit

ch

Fil

ter

Whe

el

X-r

ay A

bsor

ber

(H

gTe)

Sil

icon

sub

stra

te/I

mpl

ante

d T

herm

isto

r

He

Tan

k

Att

achm

ent

Fil

ter

Whe

elD

rive

Ele

ctro

nics

Sup

erco

nduc

ting

Mag

net

Ele

ctri

cal L

ead

/The

rmal

Lin

k

Blo

ckin

gF

ilte

rs

JFE

T

Cal

orim

eter

Ana

log

Pro

cess

or

AD

R C

ontr

ol a

ndH

ouse

keep

ing

Ele

ctro

nics

Cal

orim

eter

Dig

ital

Pro

cess

or

DP

/XR

S-D

E

X-r

ays

Cal

orim

eter

arr

ay, w

hich

in r

eall

ity

has

32 s

enso

rs.

Adi

abat

icD

emag

neti

zati

onR

efri

gera

tor

Ne

Tan

k

Dew

ar

CD

P-A

(16

cha

nnel

s)

CD

P-B

(16

cha

nnel

s)

Mas

ter

Car

dM

aste

rC

ard

Figure �� A schematic diagram of XRS�


�� Blocking Filters

There are �ve blocking �lters made of extremely thin sheets of aluminized polyimide� which are putat the entrance window of each shell of the dewar� and shield the detector from the space� Theyare named as� from outside to inside� DMS �Dewar Main Shell� �lter� IVCS �Inner Vapor CooledShell� �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 thelid of the detector box� The blocking �lters let the Xrays through to the detector� but keep outother radiations which can be a source of the heat or noise� The �lter transmission determines thelowest observable energy by XRS� It is expected that XRS will have a high enough throughputdown to � �� keV�

�� Calibration Sources

��Ca and ��Fe calibration sources are attached in the detector box for the energy calibrationpurposes� They are expected to illuminates all the calorimeter pixels uniformly� ��

��Ca decays to

��K by electron capture and emits the K�� and K�� keV and �� keV� and K� ��

keV� lines�� Line energies of ��Fe �� Mn� is �� and �� keV �K�� and K�� and �� keV�K�� XRS gain is expected to be variable� and pulseheights of the calibration peaks will be usedto create the XRS gain history �les �section ��

�� Filter Wheel

XRS has a rather large deadtime of � �� msec� Consequently� in order to observe bright sourceswith XRS� the Xray �ux is desirable to be reduced to avoid event pileup� The Filter Wheelis put in front of the XRS to this end� The Filter Wheel is a circular plate made of aluminumwith six windows� One window is completely open� which is the default� Two of the windows arecovered with beryllium� one is �� micron and the other is �� micron� Three windows coveredwith molybdenum are for the neutral density �lters� such that they are mechanically drilled toallow fractions �� and �� of Xrays to go through �molybdenum is opaque to Xraysin the XRS band�� Depending on the di�erent source �ux and spectrum� appropriate windows arechosen and put in front of the XRS� The Filter Wheel Drive Electronics �FDE� rotates the FilterWheel using stepping motors�

�� On Board Data Processing

�� Outline

When an Xray photon is detected� the microcalorimeter generates a pulse signal� which is ampli�ed by the JFET� Furthermore� CAP ampli�es the signals by a factor of �� so they can betransmitted to CDP �Calorimeter Digital Processor�� Both CAP and CDP have two independentsides named SideA and B� Each side has � channels� and the �� channels and the detector pixelshave onetoone correspondence� There are two Master Cards in CDP for SideA and SideB� CDPcommunicates with the spacecraft Data Processor �DP�XRSDE� through the Master Cards�The job of the CDP is to extract Xray events from large amount of the raw signals� determine

the event arrival times and energies� and send compressed event packets to the spacecraft DataProcessor �DP�XRSDE�� Each channel of CDP consists of an antialiasing �lter �or lowpass �lter��A�D converter and Digital Signal Processor �DSP�� The antialias �lter cuts o� the frequency above� kHz� DSP samples and digitizes the data at a rate of �� Hz with �bit resolution� ForHigh Resolution mode �see the next section�� samples are required to analyze a single pixel�Therefore� the amount of raw data in a single pulse is �� samples� � bits�sample �� bits�DSP determines the pulseheight and arrival time� and outputs the event packet along with other

�The half life is �� year�


information� A single event packet to output is bits in length� which favorably compares to theamount of the raw data�Telemetry limit for XRS is ��bits�sec for the total �� pixels� which corresponds to � �

events�s�� pixels� as a single event XRS consumes bits� Also there is a hardware limit of theXRS counting rate� which is �� counts�s�pixel�

�� Pulse Detection

The �rst job of the DSP�CDP is to detect Xray pulses in the data stream� To do this� DSPcalculates smoothed derivative of the data� The initial pulses are detected when the derivativeexceeds 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 a�ect the determination of the pulse heights of the initial pulses� Hence it is importantfor 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 tem

plate of the singlepulse derivative shape� which the CDP software maintains� The derivative shapetemplate is subtracted from the measured derivative by scaling the peak values to form the ad�justed derivative� If the adjusted derivative rises above a threshold and then falls below within aspeci�ed length of time �corresponding to the recovery time� � �� msec�� the secondary pulses aredetected� The secondary pulses are �agged so that they can be discriminated from initial pulses�section ��Once an initial pulse has been detected� CDP begins counting down the length of a Hi�resolution

data record� If the pulseheight reaches zero without detecting any secondary pulses within ��samples � �� msec�� the event is �agged as a Hi�res record �see next section�� Ifa secondary pulse does occur� the initial pulse will be proceeded as either a Mid�res or Low�resevent� and the counter will reset to the full Hires length�

�� Pulse Height Determination

It is one of the most important tasks for CDP to get the best possible estimate of the height ofeach pulse� The zerothorder pulseheight 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 asprecisely as possible using all the samples in the pulse� optimal �ltering technique is adopted� Inthis technique �named Hi�res mode�� noise is reduced by averaging all the samples in the pulse�The Hires mode is usable only when there is a single pulse in the block of �� samples�To create the optimal �lter� time series of the average pulse �� samples in � � 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 relativelylarge number �� of individual noise power spectra� each of which is made from a single noiserecord of �� samples� are runningaveraged� The average pulse is made by runningaveragingsimilar pulses which fall in a limited range on the pulseheight vs risetime plane� The optimal�ltering template in the Hires mode thus has �� samples in time space� The optimal pulse heightis calculated by multiplying the data and optimal �lter by samplebysample and adding them up�This procedure cancels out the interference of the noise component in the pulse�The above method of the pulseheight calculation in the Hires mode cannot be used when

there are two or more events in the chunk of �� samples� If two pulses are closer than ��samples but not �too close�� a shorter optimal �ltering template� typically �� samples long� isused� This method of the pulse hight calculation is called Mid�res mode ��gure �� In generalshorter templates are less e�ective to determine and reject the interference of the noise at particularfrequencies� If there are no noises� the Midres pulses will approximately give the same resolutionas the Hires mode�When pulses are too close even for the Midres mode� pulse heights are determined simply

measuring the heights of the peak over the baseline level� this will be the Low�res mode ��gure


t1

t2

High

Mid

Low

Low-Secondary

Mid-Secondary

Low-Secondary

Low-Secondary

Low-Secondary

Mid-Secondary

35.3ms

142ms

35.3ms 142ms

Figure �� De�nition of the event grade for an event separated in time by t� from the precedingevent and by t� from the subsequent event on the same pixel�

�� The baseline is measured by taking average of typically eight samples right before the startof the pulse�

Each XRS event has a �ag which tells either of the three methods of the pulse height determination is used �section �� Hires event mode provides a resolution that is limited by the detectorand ampli�er electronics� and this can be as good as � eV �FWHM� in laboratory� Midres modeprovides better than � eV if there are no noises� The Lowres mode gives a resolution around �� eV� In �gure �� de�nition of the event grade is indicated�

�� XRS Telemetry Structure

�� XRS APIDs

In XRS� the last �bit data type ID in the APID �section �� gure �� takes the followingvalues�

The �rst three bits� The last two bits�� ACHE �� Auto data�� CAPA �� Telecommand data�� CAPB �� Only used for the ACHE Data Memory Dump�� CDPA�� CDPB

The Auto data continuously comes out to the telemetry responding to the autonomous requestcommands from DP�XRSDE�� while the Telecommand data comes out discretely responding toparticular Telecommands sent to the instruments from ground�

In theory� the number of possible distinct APIDs is �� ve instruments and three data types�science� housekeeping� memory dump�� both in Auto or Telecommand forms�� but in practice onlythe following � APIDs will be used for XRS�

�Frequency of the request commands for the science Auto data is �� Hz� and that for the HK Auto data is ��Hz�


Data Type� APID�CDPA�B Science Auto ��

CDPA�B HK Auto �� CAPA�B HK Auto �� ACHE HK Auto ��

CDPA�B HK Telecommand �� CAPA�B HK Telecommand �� ACHE HK Telecommand ��

CDPA�B Memory Dump Telecommand �� ACHE Memory Dump �code� Telecommand �� ACHE Memory Dump �data� Telecommand ��

�� Contents of the XRS Telemetry

The CDP science data� whose format is explained below� include the XRS event information aswell as important auxiliary information regarding CDP status�All the �auto� HK streams of CDP� CAP and ACHE are output every � seconds� The CDP

auto HK includes the anticoincidence rates and the master status information� The CAP autoHK 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 �� has two kinds of ROMs� linkprogrammed ROM �per

manent� and EEPROM �rewritable�� both of which store initial programs and data to be sentto the individual processor cards� The Mastercard can be set to boot the processors from eitherROMs� but EEPROM is planned to be used all of the time unless something fails� in which casethe programmed ROM will be used� Contents of the EEPROM are output in the CDP MemoryDump streams when requested by a command� ACHE Memory Dump packets include the contentsof the ACHE onboard memory�

�� CDP Science Data Structure

CDP science data includes the XRS events and associated information for scienti�c data analysis�Unit of the CDP science data is a bit �block�� and there are six types of blocks� PHA� DataDump� Reply� Error� Housekeeping� and Rates� An XRS event information makes up a single PHAblock� Other types of blocks are for auxiliary information �section ��The �rst two bits of the bit tells the kind of data in the packet�� for event� �� for Data

Dump� �� for other auxiliary information� Regardless of the kinds of the data packets� the thirdbit tells the Side in CAP�CDP� either A �� or B �� and the following bits tell the pixel� from� to �� Meaning of the rest �� bits depends on the block types�

�� 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 Hires event�

�This should not be confused with the housekeeping information having the separate HK APID �the rst twobits of the APID is ��

� CHAPTER � X�RAY SPECTROMETER �XRS�

� Secondary �� bit� � This is the secondary pulse occurred on the tail of another pulse �see�gure ��

� Midres ��bit� � The short optimal �ltering template is used�� Lores ��bit� � No optimal �ltering is done�Midres�Lores means the maximum number of lags was exceeded without �nding a peak�

� baseline �� bit� � This pulse is a baseline �noise� pulseheight�� antiCo �� bit� � The anticoincidence detector is �red at the beginning of the pulse�� clipped �� 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 � to �� This represents themeansquare di�erence between the observed pulse shape and the average pulse� after scaling theaverage pulse to the same peak height as the measured pulse� � is the least error and �� is themost�

Physical Information

� Pulse Height �� bits�� Rise Time �� bits�� Tick Counter � bits� � The low bits of the ��bit tick counter� This wraps around every� seconds�

� Time �sample count� �� bits� � The number of samples since the last tick�� Time Vernier � bits� � This is the �nest time division� and is only valid for hires and midrespulses� This is a signed number in the range of � to �� with units of �� of the sampleperiod�

�� 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 bycommands�

Data Dump

Data Dumps contain important variables related to the onboard data processing and have �types as shown below� Only one Data Dump type can be active at any time� A Dump messageconsists of many �up to several hundred� blocks�

�� Fixed length Dumps�

� Sweeplength �� items�� dumps�� Pulse record

� Noise record

� Sample record � The last �� samples received

� Nonpulse record

�Some of the items come from � �bit quantities� and some from �� bits� However� when they are expanded� theywill become all ��bit words�


� Template � The optimal �ltering template

� Average pulse � The average pulse used to construct template

� Other �xedlength dumps�� Short template � The short optimal �ltering template for the Midres mode

� Noise spectrum � Noise spectrum used to construct template

� Input parameters � All the modi�able parameters

� Output parameters � All the unmodi�able parameters

�� Variablelength Dumps�

� Hu�man table � The table used for compression� CDP Memory dump � A memory dump of one of the �� RAMs �corresponding to the�� 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 � blocks long and primarily give event rates for certain accumulation periods� Housekeeping messages are � blocks long and give mostly software status� Some of the Housekeepinginformation is used to tie the tick count to spacecraft time� Rates and Housekeeping blocks areoutput 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 generatedautomatically when an error is detected�

�This should not be confused with the CDP Memory Dump stream which has the Memory Dump APID �startingwith �� and holds contents of the Mastercard EEPROM �section ��

� CHAPTER � X�RAY SPECTROMETER �XRS�

Chapter �

X�ray Imaging Spectrometer �XIS�

�� XIS Hardware

The XIS has four identical Xray CCD sensors� named XISS�� S�� S� and S�� each of which iscombined with an Xray Telescope for XIS �XRTI�� XRTI�� XRTI� and XRTI�� respectively��One CCD camera has a single frontside CCD chip with �� pixels� and covers a �� arcmin� �� arcmin region on the sky� Each pixel is a � �m square� and the size of the CCD is �� mm �� mm� The XIS is developed at MIT� Kyoto Univ�� Osaka Univ� and ISAS� The XISSensor andAE�TCE are made at MIT� and DE is developed in Japan�

TCE �TEC Control Electronics� where TEC stands for Thermal Electric Cooler� controls thetemperature of the sensors� and keeps them at around ��C during observations� The AnalogueElectronics �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 twoAE�TCE� AE�TCE�� takes care of XISS� and S�� and AE�TCE�� takes care of XISS� and S��

DE consists of two Pixel Processing Units �PPU� and one Main Processing Unit �MPU�� Corresponding to the two AE�TCE� there are two PPUs� PPU�� and PPU�� PPU receives the rawdata from AE� carries event detection� and sends event data to MPU� MPU edits and packets theevent 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 �� A� Each XIS sensor has an ��Fecalibration source for energy calibration purpose which illuminates a corner of the CCD chip�

Installation of XIS� and XIS� on the baseplate are aligned� whereas XIS� and XIS� are�� degree rotated relative to them� in opposite directions respectively ��gure �� In �gure ��locations of the ��Fe calibration sources are also indicated� This �gure also indicates the relasionbetween the XIS DET coordinates and ACT coordinates �appendix B��

�� On�board Data System

�� CCD Data Transfer

Figure �� describes a schematic view of each XIS onboard system� Xrays focused by XRT areaccumulated at the Exposure Area for a certain exposure period� and the data are transfered tothe Frame Store Area after each exposure� Data stored at the Frame Store Area are readoutsequentially by AE� and sent to PPU� The data are put into the memory named Pixel RAM inPPU�

A single XIS CCD chip consists of four Segments �marked A� B� C and D in �gure �� andcorrespondingly has four separate readout gates� Pixel data on each Segment are readout fromthe corresponding readout gate and sent to the Pixel RAM� In the Pixel RAM� pixels are givenRAWX and RAWY coordinates for each Segment in the order of the readout� such that RAWX

��

�� CHAPTER � X�RAY IMAGING SPECTROMETER �XIS�

A B C D

ACTX

ACTY

XIS-0

A

B

C

D

ACTY

ACTX

XIS-1

A

B

C

D

ACTX

ACTYXIS-2

DETX

DETY

A B C D

ACTX

ACTY

XIS-3

Figure �� Con�guration of the XIS sensors in the DETECTOR coordinates �looking up the sky��Note that XIS� and XIS� installations are aligned� whereas XIS� and XIS� are �� degree rotatedrelative to them� in opposite directions respectively� Characters �A� to �D� indicate the SegmentID� and corner areas to expect ��Fe calibration source photons are indicated with the fanshapedshades� Segment A of XIS� has a hardware problem� and may not be usable for observations�

values are from � to �� and RAWY values are from � to �� These physical pixels are namedActive pixels�In the same Segment� pixels closer to the readout gate are readout earlier and stored in the

Pixel RAM earlier� Hence� the order of the pixel readout is the same for the Segment A and C� andfor the Segment B and D� but di�erent between these two Segment pairs� because of the di�erentlocations of the readout gates� In �gure �� numbers �� and marked on each Segment andPixel RAM indicate order of the pixel readout and the storage to the Pixel RAM�In addition to the Active pixels� Pixel RAM stores the Copied pixels� Dummy pixels and H�

Over�Clocked pixels ��gure �� At the borders between two Segments� two columns of pixelsare copied from each Segment to the other� Thus these are named Coped pixels� On both sides ofthe outer Segments� two columns of empty Dummy Pixels are attached� In addition� � columnsof HOverClocked pixels are attached to each Segment�Actual pixel locations on the chip are calculated from the RAWXY coordinates and the Segment

ID� The coordinates to describe the actual pixel location on the chip are named ACT X and ACTY coordinates ��gure �� see also appendix B��

�� Pulse Height Determination

When a CCD pixel receives an Xray photon� the Xray is converted to an electric pulse� whosepulseheight is proportional to the Xray energy� In order to determine the true pulseheightcorresponding to the input Xray energy� it is necessary to subtract Dark Levels and correct possibleoptical light leaks�Dark Levels are nonzero pixel pulseheights 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 andtheir average was calculated for every exposure� Then the same average Dark Level was used todetermine the pulseheight of each pixel in the sample� After the launch of ASCA� it was found thatthe Dark Levels of di�erent pixels are actually di�erent� and its distribution around the averagedoes not necessarily follow the Gaussian� The nonGaussian distribution has evolved with time�referred to as Residual Darkcurrent Distribution or RDD�� and resulted in degradation of energyresolutions due to wrong Dark Levels�To avoid the RDD problem� Dark Levels are determined for every pixel in the case of ASTROE

XIS� PPU calculates the Dark Levels in the Dark Initial mode �section �� and they are storedin the Dark Level RAM� Dark data are taken with the Dark Initial modes� and the number of theframes can be chosen from � �� and �� The average Dark Level is determined for each pixel�and if the dark level is higher than the hotpixel threshold� this pixel is determined as a hot pixel�section �� Dark Levels can be updated by the Dark Update mode� and sent to the telemetry


1 2

3 4

1024 pixels

1024 pixels1024 pixels

1 2 12

Read-out (through AE)

256pixels

256pixels

256pixels

256pixels

1 2 12

Act X

Act Y

Raw Y(0-1023)

Exposure Area(no physical boundaries

between segments)

Frame Store Area

Memory (Pixel RAM)

O p t i o n a l W i n d o w

Raw X Raw XRaw XRaw X Dummy pixels(two columns)

Copied Pixels (two columns)

Dummy pixels(two columns)

256 or 64pixels

3 4 34 3 4 34

Pixel Processing Unit(PPU)

EventRAM

EventDetection

MainProcessingUnit(MPU)

SatelliteData Processor(DP)

A B C D

DataEdit

XIS-DE

XIS-Sensor

XIS-AE/TCE

control temperaturedrive CCDread-out datasend data to DE

Read-outgatesRead-out

gates

1 2

3 4

1 2

3 4

1 2

3 4

H-OverClockedPixels

(16 columns)

ActivePixels(256

columns)

ActivePixels(256

columns)

ActivePixels(256

columns)

ActivePixels(256

columns)

Figure �� A schematic diagram of the XIS onboard data system and the data transfer for oneCCD� In practice� there are four CCD sensors �XISS� to S�� two AE�TCUs �AE�TCE�� and ��and two PPUs �PPU�� and PPU�� Each AE�TCU takes care of two CCDs� so does each PPU�XISDE consists of two PPUs and one MPU� See section �� and �� for details�

� CHAPTER � X�RAY IMAGING SPECTROMETER �XIS�

by the Dark Frame mode �section �� Unlike ASCA� Dark Levels are not determined for everyexposure� but the same Dark Levels are used for many exposures unless they are initialized orupdated�When there are opticallight leaks in the sensor� CCDs may receive optical photons and produce

pseudo pulseheights which are not related to Xrays� PPU estimates amounts of the opticallightleaks and correct them when the pixel pulseheights are determined�

�� On�board Event Analysis

PPU carries out event analysis on all the � � � square pixel groups �for Normal Clock mode� orthree horizontal pixel groups �for Parallel Sum Clock mode� for each Segment �see section ��for Clock modes�� The Copied pixels and Dummy pixels are made so that the event analysis isenabled on the pixels at the edges of each Segment��

When an Xray photon is absorbed in a pixel� the photoionized electrons can spread exceedingthe pixel size� hence pulseheights may be detected not only from that pixel but also from adjacenttwo or more pixels� An event is recognized when the pulseheight of the central pixel among the � �� square pixels �or � horizontal pixels for Parallel Sum Clock mode� is the highest and between theEvent Lower Threshold and Upper Threshold� The RAW XY coordinates of the central pixel areconsidered as the event location� Pulseheights of the adjacent � � � square pixels �or � horizontalpixels� are analyzed� and the pulseheight information �which depends on the Editing mode� is sentto the Event RAM as well as the pixel location� For example� all the �� pulseheights are sentto the telemetry in the �� mode� On the other hand� in the �� or �� modes� only the �agswhich tell if pulseheights of the outer pixels exceed some threshold or not is output� Inner SplitThreshold is used for the central �� pixels and Outer Split Threshold is used for the surrounding� �� mode� or � �� mode� pixels� See sections �� and �� for details�

�� Hot Pixels

Hot pixels are pixels which always output high enough pulseheights even without input signals�Hot pixels are not usable for observation� and have to be removed for scienti�c analysis� In the caseof ASCA SIS� hot pixels are not identi�ed onboard� 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 signi�cant parts of the telemetry� In the case of ASTROE XIS� hot pixelsare detected onboard by Dark Initial mode� and their positions and pulseheights are stored inthe Hotpixel RAM and sent to the telemetry� Thus� hot pixels can be recognized onboard� and itis possible to specify by command not to send hot pixel events to the telemetry� It is also possibleto specify to output hot pixel events� if necessary�

�� Data Processing Modes

There are two di�erent kinds of XIS onboard data processing modes� The Clock modes describehow the CCD clocks are driven� and determine the exposure times and time resolutions� The Clockmodes are determined by the AE� The Editing modes specify how detected events are edited� anddetermine 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 di�erent

Clock and�or Edit modes for di�erent sensors�

�� Clock Modes

� Normal ModeIf Window option �see below� is not speci�ed� exposure time is � seconds� and all the pixelson the CCD are read out every � seconds� This can be combined with either of the ��

�In the case of Parallel Sum Clock mode� only inner one of the two columns of Copied or Dummy pixels on eachside of the Segment is necessary and used�


�� and �� Editing modes�

� Parallel Sum ModePixel data from plural rows are combined in the Ydirection� and the sum is put in the PixelRAM as a single row� Number of rows to combine is chosen by command from � �� and�� Parallel Sum mode can be used only with the Timing Editing mode �see below�� andthe Y coordinate is used to determine the event arrival time� No spatial resolution in theYdirection� Time resolution is �� msec�

�� Window and Burst option

For the Normal Clock mode�Window and Burst option can modify the e�ective area and exposuretime� respectively� The two options are independent� and may be used simultaneously� Theseoptions cannot be used with the Parallel Sum Clock mode�

� Burst OptionAll the pixels are read out every � seconds �if Window option is not speci�ed�� but exposuretime can be chosen arbitrarily �with �� second step� within the readout interval� Thisoption may be used to avoid the event pileup when observing bright sources�

The burst option introduces a dead time every � sec� For example� if the exposure is t sec�the dead time will be about �t sec�

� Window OptionThis option allows shorter exposure times using only a part of CCD to expose� Only a partof the chip in the Ydirection speci�ed by the commandable Window is used for exposure��gure �� The Window width in the Ydirection is either �� or pixels� and itsposition is arbitrary� When the Window width is �� pixels� the exposure time becomesa quarter of that without the Window option� and the Pixel RAM is �lled with the datafrom four successive exposures� Similarly� when the Window width is �� or pixels� theexposure time becomes �� or �� of that without the Window option respectively� and thePixel RAM is �lled with the data from � or � successive exposures�

The following table indicates how the e�ective area and exposure time are modi�ed by theBurst and Window options�

Normal Mode Burst Option Window Option Burst !without options Window

E�ective Nominal Nominal � �� or �� Area �� mm��

Exposure � sec � � sec � exposures� �Time � sec � � exposures

�� sec � � exposures

�� Editing Modes

Observation Modes

� �� modeAll the pulse heights of the �� pixels centering at the event center are sent to the telemetry�This is used with the Normal Clock mode�

� �� modePulse heights of the � pixels centering at the event center are sent to the telemetry with otherinformation on the event distribution �see section �� This is used with the Normal Clockmode�

� CHAPTER � X�RAY IMAGING SPECTROMETER �XIS�

� �� modePixel heights of the �� square pixels which includes the center pixel are sent to the telemetrywith other information on the event distribution �see section �� This is used with theNormal Clock mode�

� Timing modePulse heights of the three pixels in the Xdirection are summed if they are over the InnerSplit Threshold� and sent to the telemetry� In addition� Grades of the events are determinedand output� This is used only with the Parallel Sum Clock mode� Window and Burst Optionsare not available in the Timing mode�

Diagnostic Modes

� Dark Initial modeDetermine the initial Dark Levels of all the pixels� and store them in the Dark Level RAM�After the initialization� addresses and pixellevels of the hot pixels are sent to the telemetry�This mode can be used with either Normal Clock mode �with or without Burst and Windowoptions� or Parallel Sum Clock mode�

� Dark Update modeUpdate the Dark Levels of all the pixels in the Dark Level RAM� After the update� addressesand pixellevels of the hot pixels are sent to the telemetry� This mode can be used only withNormal Clock mode �with or without Burst and Window options��

� Frame modePixel levels of all the pixels in the Pixel RAM are dumped to the telemetry� The exposuretime is commandable and either of � sec� �� sec and �� sec� This mode can be used witheither Normal Clock mode �with or without Burst and Window options� or Parallel SumClock mode�

� Dark Frame modeDark Levels are output and sent to the telemetry� This mode works independently of theClock modes�

�� Event and Telemetry Structure

�� Observation Modes

The event information and the size of a single event for each observation mode are summarizedbelow� The event sizes are those appeared in the telemetry after the data compression by MPU�Note that RAWX value is from � to �� bits�� and RAWY value is from � to �� bits��since events are processed individually for each Segment� The pixellevel �pulseheight� takes valuesfrom � to �� thus it can be expressed in �� bits� However� MPU may also use � or � bits forpixellevels �byte compression� depending on the pixellevel values�

�� Mode

The event size is variable from �� bytes to �� bytes in length� depending on the pixellevel values�

� RAWX �� bits� and RAWY �� bits�Raw XY coordinates of the center pixel of the event�

� �� Pixel Levels �� bits for the central pixel and � or � bits for the rest�Pulseheights of the � � � pixels centering at the event center pixel� The central pixel levelis output as it is� and the rests will be output after byte compression�


�� Mode

The event size is variable from �� bytes to �� bytes in length� depending on the pixellevel values�


� � Pixel Levels �� bits for the central pixel and � or � bits for the rest�Pulseheights of the � � � pixels centering at the event center pixel� The central pixel levelis output as it is� and the rests will be output after byte compression�

� pOuterMost �� bits�A � bit pattern which tells which pixels among the Outermost Pixels exceed the OuterSplit Threshold� The Outermost Pixels are the � pixels surrounding the central �� pixels��gure ��

� sumOuterMost �� bits�Sum of the pixellevels among the � Outermost Pixels which do not exceed the outersplitthreshold�� The lowest �� bits are output�

�� Mode

The event size is variable from � bytes to �� bytes in length� depending on the pixellevel values�


� Pixel Levels �� bits for the central pixel and � or � bits for the rest�The central pixel level is output as it is� and the rest three pixel levels will be output afterbyte compression�

The �� pixels whose pixel heights are output are determined as follows ��gure ��

�� Among the four pixels which are contiguous to the center pixel� choose the pixel whichhas the highest pulse height�

�� Discard the pixel which is in the opposite side of the pixel chosen above� From theremaining two pixels� choose the one which has the higher pulse height�

�� Determine the �� pixel region which includes the center pixel and the two pixels chosenby the procedure above�

� �x�pos �� bits�Indicates relative location of the �� pixel region within the �� region centering at theevent� See �gure �� for the de�nition�

� pAdjacent �� bits�A � bit pattern which tells which of the eight Adjacent pixels exceeds the Outer SplitThreshold� See �gure �� for the de�nition of the Adjacent pixels�

Timing Mode

A single event is bytes in length�

� RAWX �� bits� and RAWY �� bits�Raw XY coordinates of the center pixel of the event� The event is searched for in the threecontiguous pixels parallel to the RAWX direction�

�This is mainly used to correct the DFE level� so those which do not exceed the threshold are more importantthan those which do exceed�

CHAPTER � X�RAY IMAGING SPECTROMETER �XIS�

Outermost Pixels

E

E EE E

H-address

V-address

2x2pos=0 2x2pos=1 2x2pos=2 2x2pos=3

E 2

4

1

3

E1

2

34 E

1

2

3

4E1

2

3 4

E

2

4

1 3 E1

23

4

E 12

3

4

E1

2

3

4

Figure �� Top Left� De�nitions of the Outermost Pixels for the � � � mode� The pixel markedwith �E� is the event center� Top Right� Some examples of the �� pixel region in the �� mode�Numbers on the pixels indicate order of the pulse heights among the four pixels attached to thecenter� Bottom� De�nition of the Adjacent pixels and the �x�pos �ag for the �� mode� The ��pixel region is darkshaded� and the eight Adjacent pixels are lightshaded�

� One Pixel Level �� bits�Sum of the pixel levels from the center pixel and other pixels which exceed the Inner SplitThreshold�

� Grade �� bits�Either of �� and �� which tells the split pattern of the event among the three horizontalpixels� Grade � is the single event �no split�� grade � and � are the leading and trailing splitevents respectively� in which either of the leading or trailing pixel exceeds the Inner SplitThreshold� Grade � means the double split in which both leading and trailing pixels exceedthe Inner Split Threshold�

�� Diagnostic Modes

Dark Initial Mode and Dark Update Mode

When these modes are invoked� the positions and pulseheights of all the hotpixels are outputonly once� and the mode returns to the previous observation mode� Each hotpixel information is� bytes in length�

� RAWX �� bits� and RAWY �� bits� of hot pixelsAddresses of the hot pixels� RAWX coordinates of the hot pixels can be from � to �� inthe Normal Clock mode� since hot pixels may be on the Copied and Dummy pixels� Hence �bits are used� In the Parallel Sum Clock mode� the RAWX coordinates of the hot pixels arefrom � to �� see footnote on page ��

� Pulse Height �� bits�Raw pulse height of the hot pixel�


Frame Mode

� Raw Frame DataPixel levels of all the pixels in the Pixel RAM are dumped� These pixels consist of Activepixels� Copied pixels� Dummy pixels and HOverClocked pixels� Therefore total number ofthe pixels in the Pixel RAM is �� pixels per segment ��gure��

Dark Frame Mode

� Dark LevelDark Levels stored in the Dark Level RAM for all the pixels are output� Both Dark Levelsfor the Normal mode �� rows � �� lines� and Parallel Sum mode �� rows � � line� areoutput� Note that Dark Levels exist not only for the Active pixels but also for the Copiedand Dummy pixels�

�� XIS APID

Di�erent kinds of the XIS data have di�erent APID �section �� Note that the subsystem ID�the third to sixth bits� is �� for XIS� Following APID values are used for XIS�

Data Type� APID�XIS HK ��

��

XIS Memory Dump ��

XIS Observation Data �� XIS�� Segment A�� XIS�� Segment B�� XIS�� Segment C�� XIS�� Segment D�� XIS�� Segment A�� XIS�� Segment B�� XIS�� Segment C�� XIS�� Segment D

XIS I�O Dump� �� PPU Memory Dump� �� AE Read Data ��

��

CHAPTER � X�RAY IMAGING SPECTROMETER �XIS�

Chapter �

Hard X�ray Detector �HXD�

�� Sensor

The ASTROE Hard Xray Detector �HXD� covers the wide energy band of �� keV incombination of the GSO welltype phoswich counters �� keV� and the silicon PIN diodes �� keV�� The HXD is characterized by the low background of � �� cts�s�cm��keV� which has madethe HXD the most sensitive instrument ever in this energy range� The nominal FWHM spectralresolution of HXD is � � � �at � keV� to � �� at �� keV�� The HXD is jointly developedat University of Tokyo� ISAS� RIKEN� and National Laboratory for High Energy Physics �KEK��Find references �� and � � for details of the HXD�

�� BGO Shields

Figure �� shows schematic views of the HXD assembly� The total weight of the assembly will be� �� kg including the electronic part �not shown in the �gure�� The HXD consists of � � identical detector units� The �ve sides of the detector are completely covered by the thick BGObackground shield� �� anticounters surround the four sides� and the bottom of each unit is alsomade of BGO� The anticounters will be used not only to reject background� but also to observepersistent and transient hard Xray��ray sources �section ��

�� GSO Sensors

Each detector unit is furthermore divided into four deep wells by the BGO active shields� Thedetector does not have imaging capability� and the �eld of view is limited to � �� by thewell having the �� mm depth and � �� mm � �� mm area� At the bottom of each well� a GSOcrystal� which deposits X��rays above � �� keV� is glued on BGO� The size of each GSO crystal is� mm � � mm and the thickness is � mm� Those events which are detected by the GSO but notby 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 lightsare detected by photomultiplier attached below the bottom BGO part of each welldetector� andsignals are read through the preampli�ers ��gure �� Total photon collecting area by GSO is �� cm��

�� PIN Diodes

On the GSO crystal� two layers of the PIN diodes� which are sensitive to Xrays between �� and�� keV� are put� Each layer has the � mm thickness and the �� mm � �� mm area� HXD carries�� PIN diodes in total� achieving the photon collecting area � �� cm��

�

� CHAPTER �� HARD X�RAY DETECTOR �HXD�

34cm

34cm

BGO

GSO

Photomultiplier + pre-Amplifier

Well Unit Side Anti Unit Corner Anti Unit

Passive Fine Collimator

32cm

34cm38cm

��

��

��

��

��

��

PIN

Figure �� The HXD assembly crosssection and the topview� The housing and electronics partare not shown�

�� Passive Fine Collimaters

Inside of each well� passive �ne collimaters made of phosphor bronze sheet �� m thick� are placedto limit the �eld of view for soft Xrays �� keV� down to �� arcmin�� This �eld of view iscomparable to those of XRS and XIS� The �ne collimaters are also expected to reduce the cosmicdi�use Xray background� which otherwise might be a signi�cant background source for the PINdiodes�

�� Electronics

The onboard electronics consists of the HXDAE �Analog Electronics� and HXDDE �DigitalElectronics� ��gure ��

�� HXD�AE

HXDAE consists of the Analog Control Unit �ACU�� Well Processing Units �WPU� and TransientProcessing Units �TPU�� There are four WPU boards �WPU�� and four TPU boards �TPU��Each WPU handles PMT and PIN events from adjacent four wellcounters� Each TPU processesevents detected by adjacent �ve anticounters ��gure �� ACU supplies high voltage to AE� andcollects housekeeping data such as voltage and temperature and sends them to DE�

�� HXD�DE

HXDDE receives signals from HXDAE� edits them into the CCSDS packets �section �� andsends them to the satellite DP� Also� DE received commands from DP through Peripheral InterfaceModule �PIM� and sends them to AE�


Sensor Signal

Sensor Power

Sensor Signal

Sensor PowerWPU1

Sensor Signal

Sensor Power

Sensor Signal

Sensor Power

Well type phowich W00

Well type phowich W01Well type phowich W02Well type phowich W03

HV-W0HV-P0



HV-W1HV-P1



HV-W2HV-P2



HV-W3HV-P3

#0

#1

#2

#3

Sensor Signal

Sensor PowerHV-T0

HV-T1

HV-T2

Sensor Power

Sensor Signal

Sensor Power

Sensor Signal

Sensor Power

Sensor Signal

BGO Anti Counter T00BGO Anti Counter T01BGO Anti Counter T02BGO Anti Counter T03BGO Anti Counter T04

Sensor Calibration Control Signal

CPU Module

Command I/F adaptor

TelemetryI/F adaptor

DP I/F adaptor


BGO Anti Counter T30

BGO Anti Counter T31BGO Anti Counter T32

HV-T3

BGO Anti Counter T33BGO Anti Counter T34


HV Unit Power

WPU/TPU Power

ControlDataTime

Status

HV Monitor

Temperature

System Bus

WPU0

WPU2

WPU3

128kbpsWPU adapter

TPU0

TPU1

TPU2

TPU3

ACU

ACU adapter

TPU adapter

#0

#1

#2

#3

HXD-S HXD-AE HXD-DE

Figure �� HXDsensor� HXDAE and HXDDE onboard data processing system diagram�

�� CHAPTER �� HARD X�RAY DETECTOR �HXD�

W00 W01

W02W03

W10

W13

W11

W12

W20

W22

W21

W23

W31

W32

W30

W33

T00 T01 T02 T03 T04

T10

T11

T12

T13

T14T20T21T22T23

T24

T30

T31

T32

T33

T34

TPU0 WPU0 WPU1

TPU1

WPU2WPU3TPU2

TPU3

P2

P0 P1

P3

PIN 構成

Figure �� Identi�cation for each segment of the HXDsensor� and the processing units to processindividual parts�

�� On�board Data Processing

�� Pulse Shape Discrimination

The point of using two di�erent types of scintillators for the active shield �BGO� and X��raysensors �GSO� is that they have di�erent decay times for �uorescence� �� ns for BGO and � ns for GSO� Each welldetector detects signals from both GSO �mostly X��ray events� and BGO�mostly background events� with the same photomultiplier and preampli�er� but the two typesof events can be discriminated by the di�erence of the pulse decay time� The same signal is shapedin WPU by two ampli�ers with di�erent shaping times� Thus two pulseheights are obtained froma single event� �Fast� pulseheights and �Slow� pulseheights� The Pulse Shape Discriminater�PSD�� a semicustom made LSI chip� carries out the discrimination of the two pulseheights� Onthe twodimensional Fast vs Slow pulseheights plane� the GSO events� in which most celestialXray��ray events are included� can be separated from the BGO events and other backgroundevents ��gure ��

�� Anti Coincidence

The �� BGO anticounters surrounding the GSO welldetectors are used to monitor the �hit pattern� of the event� TPU continuously monitors the signals from the anticounters� and tells WPU ifeach anticounter detected an event simultaneously with one of the welldetector� The hit pattern isrecorded and telemetered for each WPU event �section �� and used to select pure Xray��rayevents in the data analysis �section ��

�� Pseudo Event

ACU generates �Pseudo events� to be used for deadtime correction at a regular rate which isvariable by command� The Pseudo events are processed equally as the real GSO events� except thePseudo events have the �ag to be identi�ed so �section �� The real counting rate of a target


.

0

1

2

3

4

5

6

7

0 1 2 3 4 5 6 7

FAST (Volt)

Slo

w (

Vo

lt) pure

GSO ev

ents

Compton scatt.

pure

BG

O e

vent

s

- - -

- - -

- - -

fast trig.cutoff

.

0

1

2

3

4

5

6

7

0 1 2 3 4 5 6 7

FAST (Volt)

Slo

w (

Vo

lt) pure

GSO ev

ents

Figure �� An example of the Pulse Shape Discrimination based on the di�erence between thedecay times of GSO �for Xrays��rays� and BGO �background shield� scintillators�

may be estimated with the following formula�

Real Counting Rate ��Number of produced Pseudo events

Number of detected Pseudo events

��Observed Counting Rate�

�� PI Program

Complex onboard data processing is handled by a set of Cfunctions named PI program� PIprogram carries out the following tasks for the WPU data processing�

� Accumulate �d histograms on the Fast�Slow diagramOn the Fast�Slow diagram ��gure �� dimensional histograms are accumulated� Thehistograms may be made for either � � � regions for the � units or � regions for asingle unit� Accumulation time can be chosen�

� Event selection on the Fast�Slow diagramOn the Fast�Slow diagram� a trapezoidal region is speci�ed for the event selection� Minimumand maximumFast values of the allowed region� and for each of them� the lowest and highestSlow values are speci�ed�

� �t cutContinuous events whose intervals are less than the preset �t value are rejected� This is toavoid continuous triggers which may be caused be highZ cosmic rays�

� HitpatternAnticoincidence with other WPU or TPU is checked� and only �clean hit� events are selected�section ��

� Check trigger pattern� �ag patternTrigger patterns and �ag patterns are checked� and only events which coincide with someparticular patterns may be selected or rejected�

�� CHAPTER �� HARD X�RAY DETECTOR �HXD�

Mode TH PH Burst memory coverage� �� s �� s sec �pre �s�post � s�� s � s �� sec �pre � s�post ��s�� s � s �� sec �pre ��s�post ��s� �� s s �� sec �pre s�post �s�

Table �� Time resolution of the TPU TH �Time History� and PH �Pulseheight History� data fordi�erent modes� Mode � is the default�

�� TPU Observations

Besides the primary purpose of the background rejection� TPU data from the anticounters� inconjunction with the WPU data from the bottom BGO part of the welldetectors� can be used forscienti�c observations too�

Each TPU board combines and accumulates events from the �ve anticounters� and producestwo kinds of the histograms named TH �Time History� and PH �Pulseheight History� from thesame data� TH has a shorter accumulation time with pulseheight channels� whereas PH hasa longer accumulation time with pulseheight resolutions� Time resolution of the TH and PHcan be variable as shown in table ��

�� Transient data

The PH histograms from each board are continuously output to the telemetry� This is named the�Transient data� �section �� Transient data �contrary to the name� may be used to monitorthe persistent hard Xray�gammaray sources �section ��

�� Gamma�ray burst data

Each TPU board has a ring bu�er of a capacity of kbytes on which TH data and PH data arecontinuously recorded� The ring bu�er can store the latest �� sets of the PH histograms and �� sets of the TH histograms� the actual durations of the data stored in the ring bu�er are variable�as shown in table ��

The TH stream is continuously monitored by a gammaray burst determination circuit� which�ags when a gammaray burst�like� event is detected� When the gammaray burst is triggered�the ring bu�er is frozen� and the TH and PH data shortly before and after the burst trigger arekept �table �� The gammaray burst data are sent to the DP �then to DR� when HXD pausesnormal operation such as during SAA �section ��

�� Position determination

Although each unit of the anticounters does not constrain the photon arrival direction� crudedirection of a celestial source may be determined if one can compare the numbers of the sourcephotons detected by the orthogonal groups of the detectors�

This position determination method will be feasible for the Gammaray burst data� since therewill be virtually a single outstanding source at a time� Position determination of persistent sourcesin 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 BATSEto separate and identify the individual persistent sources in the Transient data�

�� HXD TELEMETRY STRUCTURE ��

�� HXD Telemetry Structure

�� 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 di�erent APIDs as follows�section �� Note that the VCID of HXD is ��h �real data� or ��h �reproduced data�� and thirdto sixth bits of APID is �� for HXD�

Instrument� data type� Meaning� APID�WPU Well Main data WPU� Event �� h�

WPU� Event �� h�WPU� Event �� h�WPU� Event �� h�

WPU Monitor data Scalar �� h�

WPU Well Event Histogram Coarse �� h�WPU Well Event Histogram Fine �� Ah�WPU Well Event Histogram Reserve �� Bh��Eh�

TPU Transient data �� h�

TPU Gammaray burst �� h�

HK data DHU HK data �� h� VCID �HXD HK data �� h� VCID �ROM mode HK data �� h� VCID �

Status DE System Status �� h�ACUHK data �� h�PI program Status �� h�

Dump data I�O dump �� h�ECC dump �� Ah�AE parameter dump �� Bh�ROM mode I�O dump �� Dh�ROM mode ECC dump �� Eh�Memory dump �� h�

�� WPU main data

Either PMT� PIN or Pseudo events trigger the data acquisition system of WPU� When a trigger isissued� the analog outputs of the corresponding phoswich unit� Slow shaper� Fast shaper� and thefour diode shapers� are digitized� Then a single WPU event is recorded and output as a �� bitlength record� WPU events from each board have separate APID as shown above� Explanationsof the WPU event record are the following�

� Length Check �� bit� � A �ag to tell if the event record has the correct length� Should bealways �� unless DE found the data length is wrong when the bit is �ipped to ��


� Event time �� bits� � Arrival time of the event measured with either �� Normal mode�� Fine mode� or �� Super�ne mode� � sec tick�� The Fine mode will be used asdefault�

� PIN Peak Hold Status �� bit� � Tells if the PIN pulse height peak is correctly held �� or not�� This �ag should be On �� for a good event�

� PIN Double Trigger �� bit� � During a process of an event� if another event is detected� this�ag becomes On �� Those �double events� may be removed in the data screening processlater�

� PIN UD �� bit� � Tells if the PIN upper discriminater is hit �� or not �� Channel ID �� bits� � ID of the sensor �� to �� within the WPU� Note that WPU ID is notoutput explicitly� since this is known from the APID�

� Trigger Pattern � bits� � The six bits correspond to the PMT anode �� bit�� four PIN sensors� bits� and Pseudo trigger �� bit� section �� Each bit tells if the trigger is made by thecorresponding sensor �� or not ��

� PMT Peak Hold Status �� bit� � Tells if the PMT pulse height peak is correctly held �� ornot �� This �ag should be On �� for a good event�

� PMT Double Trigger �� bit� � During a process of an event� if another event is detected� this�ag becomes On �� Those �double events� may be removed in the data screening processlater�

� PMT UD �� bit� � Tells if the PMT upper discriminater is hit �� or not �� PSD �� bit� Out � Output of the Pulse Shape Discriminater �PSD�� for a GSO event� � fora BGO event�

� Hit Pattern �� bits� � Each bit tells if each of the � detectors �� sensors and �� anticounters� detected this event �� or not ��

� PMT Fast Pulse Height �� bits� � PMT pulse height with Fast shaping time�� PMT Slow Pulse Height �� bits� � PMT pulse height with Slow shaping time�� PIN� �� bits� � Pulse height of PIN�� PIN� �� bits� � Pulse height of PIN�� PIN� �� bits� � Pulse height of PIN�� PIN� �� bits� � Pulse height of PIN��

�� WPU sub data

Well monitor data

The �Scalar packets� include various monitor counting rates such as numbers of the events whichhit the Lower Discriminater and Upper Discriminater for each unit� Monitor counts are summedover each board and also output in the HXDHK packets �section ��

Histogram data

In addition to that each WPU event is output to the telemetry� twodimensional histograms canbe produced for the Fast vs Slow pulseheights distribution �section �� and output as the�Histogram packets��

�These modes correspondto the HXD WPU CLK RATEHK parametervalues of � �Normal�� Fine� or � �Super�Fine��


�� TPU data

Transient data

The PH histograms �section �� are continuously sent from AE to the telemetry� The upper � energy channel of the PH are binned by two� thus the number of spectral channels becomes � �One � bytelength �block� contains a � channel PH histogram for a single time bin� For thedefault time resolution of one second� one block is output every second� Di�erent boards have thesame 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 �LDhits� of the anticounters� One block contains LDhit rates of the �veanticounters belonging to that TPU board� and the LDhit rates of the four underlying anticounters belonging to a WPU�PH histogram data are condensed for each board and also output in the HXDHK packets

�section ��

Gamma�ray burst data

The upper � energy channel of the PH are binned by two� thus the number of spectral channelsbecomes � � One set of the gammaray burst data includes �� sets of the � channel PH histogramsand �� sets of the channel TH histograms �table �� In addition� the same LDhit rates ofthe anticounters as in the Transient data are included� The gammaray burst data requires ��byte blocks to output for each board�

�� HK data

DHU HK is the HK data DHU accumulates through HXDPIM� independently of the DP� HXDHK data is the main HK data edited by HXDDE� This includes the ACU HK data� condensedmonitor data and transient data �sections �� and �� 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 theDE data�

�� Status Packets

DE System status and PI program status show the setting and status of the DE system softwareand the PI program �section �� respectively� ACUHK data is diagnostic information of theAE�ACU module�

�� Dump Packets

Contents of the onboard memories are dumped depending on the DE status�


Chapter �

Mission Operations

In this chapter� we brie�y explain how the ASTROE mission is operated� observation programis conducted� and the data is processed� Figure �� is a �owchart illustrating various processes inthe ASTROE 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 laterchapters�

�� Observation Program

�� De�nition of the Mission Phases

Since XRS lifetime is limited� observation program in the early stage of the mission shall bedesigned to maximize XRS capabilities and performances� This period� which is expected to be� � years� is called Phase � ��gure �� Phase � is further divided into Phase ��A� which is the�rst six months� Phase ��B� the next � � months� and Phase ��C� the rest � � months� Afterthe XRS cryogen is exhausted� Phase � will start� during which only XIS and HXD will carry outobservations�

During Phase �� certain portion of the observation time is guaranteed to the ASTROE ScienceWorking Group �SWG�� which consists of the ASTROE hardware teams� software teams andseveral invited researchers� The Phase �A is entirely for the SWG observations� and the GuestObservations� selected through competitive process� starts at Phase �B ��gure �� Phase � willbe completely open to the Guest Observers� Key dates by the end of Phase � are shown in table��

Phase ��A

The �rst �� year of Phase �A will be spent to establish the satellite and instrumental operation�this period may be called In Orbit Checkout �IOC� phase� The remaining �� year will be primarilyused for the veri�cation of the instrumental performance and data handling system� Some scienti�cresults are expected during this �� year� All the observation time of Phase �A is alloted to theSWG�

Phase ��B and ��C

In Phase �B� Guest Observer observations will start� such that � � of the time is allocated toSWG� and � is for GOs ��gure �� In Phase �C� �� of the time is given to SWG� and�� is for GOs� The GO time will be equally divided to the Japanese and US communities� Asmall portion of the Japanese time may be reserved for GOs from ESA �European Space Agency�member countries�

��

�� CHAPTER �� MISSION OPERATIONS

Sate

llite

KSC

Orb

itD

eter

min

atio

n(N

ASD

A)

Ope

ratio

nD

ata

Acq

uisi

tion

Qui

ckL

ook

Com

man

ds

ISA

S

Tel

emet

ryD

atab

ase

(SIR

IUS)

Mer

ging

TO

OO

bser

vatio

ns

Com

man

dsD

ata

Ope

ratio

nR

epor

ts

Prop

osal

Dat

abas

e

Obs

erva

tion

Dat

abas

e

GSF

C

Ast

ro-E

arch

ives

Japa

nese

Gue

st O

bser

vers

US

Gue

st O

bser

vers

Cal

ibra

tion

Dat

abas

e

Ope

rati

on

Cen

ter

Sche

dulin

g

Del

iver

y

Prop

osal

Dat

abas

e

Obs

erva

tion

Dat

abas

e

Sele

ctio

nin

Jap

an

Sele

ctio

nin

USA

Prop

osal

s

Prop

osal

s

Mir

rore

d

Arc

hiva

lD

atab

ase

Cal

ibra

tion

Ast

ro-E

Tea

m

Cal

ibra

tion

Dat

abas

e

Proc

esse

dPr

oduc

ts

Proc

esse

dPr

oduc

ts

Ast

ro-E

Scie

nce

Wor

king

Gro

up

Cal

ibra

tion

Obs

erva

tions

SWG

Obs

erva

tions

(onl

y Ph

ase1

)

GO

O

bser

vatio

ns(a

fter

Pha

se 1

-B)

Pipe

-lin

ePr

oces

sing

Raw

Pac

ket

Tel

emet

ry(R

PT)

Atti

tude

File

s

Orb

itFi

les

Firs

t FIT

SFi

les

Atti

tude

Det

erm

inat

ion

FIT

SC

onve

rsio

n

Raw

Pac

ket

Tel

emet

ry(R

PT)

FIT

SC

onve

rsio

n(b

acku

p)

Atti

tude

File

s

Orb

itFi

les

Firs

t FIT

SFi

les

Pipe

-lin

ePr

oces

sing

Mir

rore

d

Figure �� Overview of the ASTROE mission operation and observation program�


SWG

SWG

SWG

GO(AO1)

GO(AO2)

0.75 year0.4 year ~0.75 year0.1 year

GOIn

Orb

it C

heck

-out 34%

33%

20%

40%Japan

US

Japan

US40%33%

60% Japan

15% Japan-US25% US

Phase 1 Phase 2Phase 1-A Phase 1-B Phase 1-C

Figure �� De�nition of the ASTROE mission phase and observing time allocation� Note thatthe spare Observatory Time �� throughout the mission life� is not indicated�

Selection of SWG targets for Phase �A and �B periods �� JuneAO� NRA release with SWG target list �� JuneAO� deadline �� SeptemberAO� proposal review �� NovemberPhase �A and �B period observation schedule determined �� December

ASTROE Launch �� January

Phase �A observation starts �� MarchPhase �B observation starts �� AugustSelection of SWG targets for Phase �C period �� NovemberAO� NRA release with SWG target list �� NovemberAO� deadline �� FebruaryAO� proposal review �� AprilPhase �C period observation schedule determined �� MayPhase �C observation starts �� MayEnd of Phase � �XRS �nish� � �� January

Table �� Key dates by the end of Phase �

Details of the ASTROE Guest Observer program will be fully described in the ASTROENASA Research Announcement �NRA�� which is published toward US researchers by NASA� Therewill be two AO periods� AO� corresponds to Phase �B� and AO� corresponds to Phase �C�

Phase �

In Phase �� all the observation targets are selected based on the proposals from US and JapaneseGuest Observers� The GO time will be divided between Japanese and US communities such that � � of the time is allocated to Japanese community� �� for US� and �� for JapanUScollaborative observations�

�� Type of the Observations

�� Observatory Time

Throughout the ASTROE mission life� approximately � � � of the time will be spared for theObservatory Time maintained by the ASTROE team at ISAS� The Observatory Time will bespent� for example� for instrumental calibration� maintenance of the satellite� or to compensate

� CHAPTER �� MISSION OPERATIONS

unexpected observational�operational failure such as cancellation of the ground contacts due tobad weather� Target of opportunity �TOO� observations �section �� may be also carried outusing the Observatory Time�

�� IOC Observations

The �rst �� year of the mission life will be devoted to the In Orbit Checkout �IOC� by theASTROE team� Although celestial Xray targets may be observed� meaningful scienti�c resultsmay not be expected�

�� SWG Observations

During Phase �A� most SWG observations will be selected considering not only the scienti�cmerits� but also usefulness for instrumental calibration� In Phase �B� SWG observations willbecome more science oriented�SWG observations are planned and analyzed by SWG members� For each target� a target team

composed of several SWGmembers will be organized and a team leader will be assigned� The teamleader will serve e�ectively as a Principle Investigator �PI�� and be responsible for coordination ofthe analysis and presentation of the result�SWG targets for Phase �A and the �rst half of Phase �B �AO� period� should be �xed and

announced by the time AO� NRA is released �table �� SWG targets for the second half of Phase�B �AO� period� will be determined after the launch� taking account of possible feedback fromresults of the Phase �A observations� the SWG target list should be announced by the release ofAO� NRA�

�� GO Observations

Targets are selected through a competitive process from observation proposals submitted by USand Japanese Guest Observers �GO�� US GOs will submit proposals to NASA responding to theNASA 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�� di�erent scienti�c 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 madethrough independent Japanese review process� The �nal accepted target list is determined at theJapanUS merging meeting based on the Japanese and US target lists� In case there are identicaltargets on the Japanese and US target lists� and�or in order to adjust the time allocation betweenthe 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 ASTROE GOF as needed �chapter ��

�� Calibration Observations

ASTROE team will regularly carry out calibration observations to monitor the performance of theinstruments both in Phase � and Phase �� Calibration observations will be carried out primarilyusing the Observatory Time�

�� Target of Opportunity Observations

Target of Opportunity �TOO� observations may be carried out responding to rare observationalopportunities and considering their high scienti�c merits� For example� Xray nova or supernovae�strong �ares of known targets� and afterglows of Gammaray bursts may be considered as TOOtargets� There will be TOO observations both in Phase � and Phase �� Rules and procedures ofthe TOO observations will follow those of ASCA which have been in practice since �� July�� To

�See http��heasarc�gsfc�nasa�gov�docs�asca�too�too�html�


summarize these policies� anybody can propose TOO observations by contacting ASTROE projectscientists at ISAS and GSFC� Once TOO observations are approved� observations will be carriedout using the Observatory Time� The proposer will be the PI� and several ASTROE memberswill participate to the study as coinvestigators�

�� Time Constraint Observations

Some observations are required to be performed at speci�c periods� These include the time criticalobservation� such as simultaneous observations with other wavelengths or instruments� and thephase critical observation� such as observations of Xray binary eclipses� Also� observation ofextended targets may require speci�c rollangles� which constrain observation windows in a yearbecause of the solar condition� Number of time constraint observations will be limited so that theentire observation scheduling is not burdened too much�

�� HXD TPU Observations

Besides that HXD WPU supplies hard Xray��ray spectral data of the target simultaneouslyobserved with XRS and XIS� HXD TPU is capable of detecting gammaray bursts and monitoringpersistent hard Xray��ray sources from large region of the sky �sections �� and �� TheseTPU data will constitute precious all sky monitor datasets� It has yet to be determined how tohandle TPU monitor data and gammaray burst data in terms of the data priority�

�� Proprietary Period

Calibration data will be immediately public regardless of the mission phases� Proprietary period ofthe scienti�c data taken during Phase �A is �� months� for all the other data� proprietary periodis one year� After the proprietary period is over� the public data are delivered to the ASTROEarchives �section �� chapter �� so that interested researchers can obtain the data throughInternet�

�� Satellite Operations

�� Scheduling the Observations

ISAS will be responsible for making observation schedules and operating the satellite� At theoperation center at ISAS� a long term plan will be made at the beginning of each AO periodand updated every few months to cover the targets in the observation database �section ��Short term plans are made every couple of weeks based on the long term plan� taking account ofcontemporaneous 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 toASTROE Observers� When short term plans are announced� ASTROE GOF contacts US GOsto con�rm their observation plans� and the �nal plans are sent to ISAS �section ��Satellite command planning softwares similar to those used for ASCA will be used to make

observation schedules with optimum conditions �see also section �� In the case of ASCA� atechnician 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 assistancein the satellite operation is expected for ASTROE as well�

�� Operating the Satellite

Duty scientists at ISAS and KSC will be responsible for the daily ASTROE operation� AllJapanese ASTROE team members at universities and other institutions are expected to work asduty scientists from time to time either at ISAS or KSC� Duty scientists at ISAS operation centermake the daily observation commands based on the observation plans con�rmed by ASTROE

� CHAPTER �� MISSION OPERATIONS

Observers� The operation commands are daily sent to the Kagoshima Space Center �KSC�� wherethe satellite is operated and the data are retrieved� At KSC� the satellite is contacted usually �vetimes a day� each �� minutes�� during which period the operation commands are sent to thesatellite� and the data are retrieved�

Duty scientists at KSC may carry out quick look analysis to make sure if the observation wascarried out correctly� Quick look results are sent to GOs through ISAS or GSFC to notify statusof 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 propercountermeasures shall be taken�

�� Data Flow

�� Data Retrieval and Raw Data Archives

The data is retrieved from the satellite only at KSC� Amount of the ASTROE data daily retrievedis � �� Gbytes �� contacts � �� Gbytes�contact� see section �� Raw data are sent from KSCto ISAS through a dedicated network� and saved in the raw database named SIRIUS� The SIRIUSdatabase at ISAS stores the raw telemetry data of all the past ISAS missions �see also section��

�� Data Processing at ISAS and GSFC

The ASTROE data processing means conversion from the raw telemetry data to the highlevelcalibrated data deliverable to the ASTROE Observers� Details of the data processing are explainedat section �� and only an outline is given here ��gure ��

At ISAS� telemetry �les in the SIRIUS database are wrapped into portable Raw Packet Teleme�try �RPT� FITS �les� being added a minimum set of FITS keywords� Routinely� ISAS will processRPT �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 determined�� The FirstFITS Files� attitude �les and orbit �les constitute a complete data package for each observationalsequence� These packages are archived at ISAS� and the identical copies are delivered to GSFCregularly� The RPT �les are also delivered to GSFC for archival and backup purposes� so thatthe 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 thecalibration information and produce the highlevel processing products �section ��

�� Data Delivery to ASTRO�E Observers

The processing products are delivered to Guest Observers and SWG members� US ASTROEObservers will receive data from GSFC� and Japanese Observers will receive from ISAS� Thedelivery medium will be CDROM or DVD� The proprietary data might be also put online sothat ASTROE Observers may obtain the data promptly using a secure data transfer protocol suchas the PGP encryption�

ASTROE Observers will be able to conduct scienti�c analysis immediately from the processingproducts� The analysis software and user support are provided by the ASTROE GOF �see chapter�� and ��

�Occasionally� the time of the ground contacts con�icts with other satellites operated at KSC� According tocircumstances� some of the ve ASTRO�E ground contacts may have to be canceled� This will limit the number ofcommands sent to the satellite� as well as amount of the data to be downloaded �section ��

�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 Archives

All the ASTROE data will be delivered to and archived at the HEASARC� and may be at theISAS data center too� Access to the proprietary data is only allowed to ASTROE Observersthrough a secure data transfer protocol� After the proprietary period is over� the data is madepublic� so that users are able to obtain exactly the same datasets as the original Gust Observershave received� From time to time� contents of the archives will be updated� being reprocessed withthe latest softwares and calibrations� Details of the ASTROE archives are explained in chapter��

CHAPTER �� MISSION OPERATIONS

Chapter �

Software Principles

In this chapter� we present the ASTROE software principles and agreements� which all the softwaredevelopers need to follow throughout the ASTROE project�

�� General Software Design Principles

ASTROE data analysis system should share the same design principles with all the other projectsconducted under OGIP� These design principles may be summarized as follows�

�� Standard and portable data format � FITS �Flexible Image Transport System� format isadopted 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 conventionsshould be submitted to HEASARC FITS Working Group to check for consistencies withother missions� Use of ASCII format is allowed for small �les�

�� 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 calibrationsby hardware teams are used for the scienti�c data analysis by Guest Observers�

�� Designed for multimission analysis � Already written software infrastructures will be madeuse of as much as possible� Users will be able to analyze ASTROE data with standardhighlevel Xray data analysis packages such as XSPEC� XIMAGE� XRONOS� etc�

� Easy to install and use � The softwares will be easy to install and use� and extensive help�support and documentation will be provided� ASTROE speci�c softwares for lowlevel tasksare distributed in the standard FTOOLS package� providing user friendly interface on moststandard platforms �section ��

�� 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 anyprivileges or credits� Users may modify and distribute ASTROE softwares freely on theirresponsibility�

�� ASTRO�E Speci�c Design Principles

In addition to the general design principles above� ASTROE GOF and ISAS propose the followingdesign principles for the ASTROE software�data processing system� Experience from the ASCAsoftware project is re�ected here�

�

CHAPTER � SOFTWARE PRINCIPLES

�� The raw telemetry will be converted to FITS format before distribution� There isonly one set of software �mk�st�ts� section �� to access and interpret the raw telemetrydata and to convert them to the FITS format �First FITS Files� section �� Mk�st�ts� aswell as other processing softwares� has to be fully tested and ready before the launch of thesatellite�

�� All the calibration and data processing should start from the First FITS Files�To that end� the First FITS Files should re�ect the original structure of the raw telemetryas much as possible�

�� All the scienti c analysis starts from the standard calibrated FITS les� The FirstFITS Files are further processed by the standard softwares with instrumental calibrationinformation� and the Calibrated FITS Files �section �� are produced� Scienti�c outputsare produced always from the o�cial Calibrated FITS Files� and there should not be otherroutes for scienti�c analysis�

� The same processing system to calibrate the First FITS les should run at GSFCand ISAS� Thereby� US and Japanese ASTROE Observers shall receive the identical Calibrated FITS Files�

�� Important calibration tools�softwares should be made promptly available to GOs�At a time� there shall be always a single version of the o�cial instrument calibration �lesand softwares controlled by the ASTROE GOF and instrument teams�

� ASTRO�E softwares will be written by the ASTRO�E software and hardwareteams at GSFC� ISAS and other institutions in Japan� Tasks which require deepunderstanding of the ASTROE instruments� spacecraft and telemetry formats will be mainlywritten by the members of the hardware teams and ISAS� On the other hand� higher leveltasks� in which userfriendliness� standardization and conformity with other high energymissions should have a high priority� will be mainly written by the software team at GSFC�

�� All the softwares for public release will be delivered to ASTRO�E GOF beforethe release� ASTROE GOF will ensure that the softwares follow the rules presented in thischapter� and will package them in a form which is suitable for general release� ASTROEGOF will be responsible for releasing and maintaining the packages� When softwares arerequired to be modi�ed or �xed� ASTROE GOF will be responsible for the �x and the rerelease� contacting the original authors as needed� When signi�cant changes are necessary�ASTROE GOF will always consult the original authors in advance�

�� Tasks required for the Pipe�line processing should run in scripts� In the automatedpipeline processing system �section �� series of data processing tasks are run as background jobs by scripts� Therefore� all the processing tasks including those which make useof GUI are required to run in scripts�

�� ASTRO�E Software Standards

�� Languages

ASTROE 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 independentpackages �e�g�� raytracing program�� Fortran�� is allowed� but Fortran�� shall not be used�

In the scripting tasks� use of system independent environments such as Perl or Tcl�Tk isrecommended� Use of the shell languages �such as csh� bsh and tcsh� which do not run besideUNIX environment is forbidden�


�� Coding Rules and Compiler Requirements

Portable coding practices shall be adhered to� including the isolation of systemdependencies� TheANSI C standards shall be adhered for Cprogramming� and so is the OGIP Fortran standards�Mukai �� for Fortran programming�

The systemindependence test for C shall be that the code can be compiled by gcc on the severalsupported architectures �see section �� and so is by g�� for Fortran� The cfortran package shallbe used to combine C and Fortran routines when necessary�To write and read FITS �les� c�tsio �in C� or �tsio �in Fortran� should be used� The obsolete

�tsio Cwrappers� which were developed to call fortran �tsio routines from Ccodes� should not beused�

�� Systems Supported

All the ASTROE softwares intended to distribute shall run on the most popular systems ofASTROE users� It is di�cult to predict now which systems will be most important around ��However they are likely to include Sun�Solaris� DEC�Alpha� SGI�Irix� HP� Linux� and WindowsNT�

�� Coordination and Version Control

The Software Coordination Group consisting of members from each hardware team� ISAS� and theGOF shall meet regularly �at least twice a year until and soon after the launch� to ensure softwarecoordinations� In addition� the GOF shall have one person attached to each hardware team withresponsibility to help coordinate software development� The software coordination group shall alsobe responsible for ensuring consistency of FITS keyword naming across teams�

The �st Stage Software �section �� is maintained by ISAS� GSFC keep master copies of allthe softwares except the �st Stage Software under a control system� This control system shallensure that a given �le is only edited by one person at a time and also that previous versions arearchived and can be recovered� The practical way that ASTROE FTOOLS will be developed andmaitained gloably is explained in section ��

�� Documentation

All the softwares intended for distribution should be fully documented in English� Commentsin the source codes should be written in English� but Japanese translation might be added forconvenience 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 alsoprovide template routines containing the standard header�The FITS �le format of ASTROE related �les is fully explained in a separate document

maintained by the ASTROE GOF�

�� ASTRO�E FTOOLS Global Development Scheme

Many scientists and programmers in the United States and Japan are involved in the ASTROEFTOOLS development� Also� ASTROE 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 nodi�erent �avors of the same FTOOLS be developed and proliferated�

�See http��heasarc�gsfc�nasa�gov�docs�journal�ogip fortran��html � This is ANSI Fortran�� with someextensions� The extension includes the following� �� Both upper and lower case letter are allowed� �� END DOare allowed� �� DO WHILE loops are allowed� � � INCLUDE statements are allowed� �� INTEGER�� data typeis allowed� �� Variable can be up to �� character long� �� IMPLICIT NONE is allowed�

� CHAPTER � SOFTWARE PRINCIPLES

ISAS

Repository

Ftoolsteam

DevelopFtools

GOF

Build weekly

Test

Test

Test

GSFC

BuildASTRO-E ftoolsas needed

Official ftools release

(once or twice ayear)

MirroredDaily

ASTRO-EUsers in USand Europe

Release Ftools

ASTRO-E add-on

Release Ftools

ASTRO-E add-on

HXD team

XIS team

SoftwareDevelopmentCoordinator

Delivernew codes

Check Consistency

Test

Test

Test

ASTRO-EUsers

ASTRO-EUsers

ASTRO-EUsers in Japan

Usedfor analysis

Usedfor analysis

ftp

ADF

Processing Center

Mirroredas needed

anonymousftp

anonymousftp

ProcessingFtools

pipe-line processingsystem

ProcessingFtools

pipe-line processingsystem

XRS team

XRS team at GSFC

XRS team in Japan

Figure �� ASTROE FTOOLS global development and version control scheme�


In the early stage of the mission� as understanding of the instruments deepens and new dataanalysis techniques are getting established� it will be necessary to update and release the ASTROEFTOOLS 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 �� has been proposed and will be practised for theASTROE FTOOLS development� version control� and release�

�� At GSFC� the FTOOLS team maintains the FTOOLS �Repository�� for which only theteam members are granted the write permission� The FTOOLS team receives original sourcecodes from the �Contact� groups �through ISAS when the Contact groups are in Japan�see below�� and put the codes in the Repository� after minimal programmatic changes ifnecessary� The codes in the Repository should be considered the genuine copy of the latesto�cial FTOOLS�

�� The entire FTOOLS directory tree is built weekly from the Repository� This FTOOLS iscalled �Develop� FTOOLS� and only available inside GSFC� The Develop FTOOLS are testedat GSFC� and the codes will be �xed if any problems are found� and put in the Repositoryagain� Note that the Develop FTOOLS re�ect updates of all the FTOOLS including ASTROE�

�� 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�

� In order to catch up with short development cycle� whenever ASTROE FTOOLS in theRepository are updated� the FTOOLS team will build the ASTROE FTOOLS against theRelease FTOOLS� and install the �ASTROE addon�� Interval of the ASTROE addonbuild will be as short as one week � Develop FTOOLS build cycle�� The Release FTOOLSwith the ASTROE addon is the one ASTROE users will use for their data analysis� TheASTROE addon package will be promptly released toward ASTROE users� so that theycan install it on their own Release FTOOLS�

�� The Release FTOOLS with the ASTROE addon will be mirrored daily to ISAS� and willbe used for ASTROE data analysis at ISAS� Japanese ASTROE users outside of ISAS mayobtain the original package from GSFC or mirrored one from ISAS�

� Instrument teams in Japan will test and modify the source codes in the ASTROE addonpackage to re�ect the latest calibration� and they will deliver the new codes to the SoftwareDevelopment Coordinator at ISAS� The Software Development Coordinator will make surethat the codes from di�erent groups are consistent and can be built cleanly using gcc� Afterthat� he or she will deliver the codes to the FTOOLS team at GSFC �go back to step �� Notethat some of the XRS FTOOLS will be released through the ISAS Software DevelopmentCoordinator� while other XRS FTOOLS will be directly delivered to the FTOOLS team�

�� The Processing team at ADF will obtain the Release FTOOLS with the ASTROE addon�which will become the base of the pipeline processing� However� the processing team willneed its own installation of FTOOLS ��Processing� FTOOLS� which should be completelyshielded fromother 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 isoften necessary to timely accomplish the demanding data processing tasks� The ProcessingFTOOLS� as well as the pipeline processing scripts� will be mirrored to the ISAS processingcenter from ADF� so that the data centers at ADF and ISAS use the identical system toproduce standard ASTROE data products�

�� As of writing this document �January �� the Release ftool �v�� is too old� and the nextrelease �v�� is around the corner �medJanuary �� On the other hand� we should starttesting the ASTROE FTOOLS con�guration paradigm proposed here as soon as possible�Therefore� only until the v�� release� the Release FTOOLS in the diagram above will be

�� CHAPTER � SOFTWARE PRINCIPLES

replace with the �Baseline� FTOOLS� which will be an interim release of a stabilized DevelopFTOOLS snapshot�

Chapter �

ASTRO�E Function Libraries

There will be software functions which are repeatedly used in various stages of the ASTROEmission� from the satellite operation to the scienti�c data analysis� In order to avoid overhead andinconsistency� functions supposed to be used by two or more software modules will be included inthe ASTROE function libraries�There will be at least three such function libraries for ASTROE� astetool� which includes

functions for ASTROE speci�c tasks� atFunctions� which includes functions for generic attitudeand orbital related tasks�� and xrrt� which is for XRT raytracing� They are implemented in theFTOOLS package as libastetool�a� libatFunctions�a� libxrrt�a� respectively� �

�� ASTRO�E Speci�c Tasks astetool�

�� Time Conversion

Routines to carry out conversion between ASTROE time and other time systems will be necessary�ASTROE time will be de�ned as the elapsed time from the beginning of year �� in UTC �� Theleap second table is referenced to take into account the leap seconds�For the calibration data taken in �� and earlier� negative values of the ASTROE time may

be used�

�� Coordinate Conversion

Since XIS and XRS are imaging instruments� the coordinates to which XIS images and XRS eventsare referenced have to be de�ned� Functions to carry out conversion between these coordinateswill be necessary �e�g�� when making observation plans and calibrating FITS event �les�� and willbe put in the astetool�

�� Energy Calibration

ASTROE instruments convert Xray photon energy into a pulseheight 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� Aftercorrecting these e�ects� we may de�ne Pulse Invariance �PI�� which should be perfectly proportionalto 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 �� The routines to calculate PI from PHA should be put in theastetool� These routines need to access calibration �les to get calibration information �chapter ��

�atFunctions has been used also for ASCA��On the Unix platforms� For other platforms �such as Windows�� the names will be di�erent��Test data taken in �� or before will have negative values of the ASTRO�E time�

��

�� CHAPTER �� ASTRO�E FUNCTION LIBRARIES

�� Data Access Layer �DAL� functions

All the ASTROE �les will have de�nitive FITS format� and many ASTROE softwares willread�write event �les or calibration �les with the same FITS formats� In order to facilitate theFITS �le access� there shall be a set of Data Access Layer �DAL� functions� which is suppose totake care of the FITS �le interface by calling lower level �tsio functions�All the ASTROE 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 DALfunctions are required to be modi�ed� without any changes at at higher levels�

�� HK Information Acquisition

The HK FITS �les �sections �� and �� will include all the complex satellite and instrumentHK parameters� thus can become huge� However� only small parts of the HK parameters will beactually required for scienti�c data processing� In order to facilitate the HK �le access� HK �leaccess routines should be provided in astetool� Note that HK access routines need to be built withe�ciency 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 continuouslyby 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� AlthoughSIB itself is not portable� ASTROE related information in SIB will be necessary to interpret HKparameters in the telemetry� Therefore� essential parts of the SIB will be extracted and put in thecalibration �les �section ��

�� Other Tasks

Functions for other tasks will be put in astetool as needed� For example� a random numbergeneration function will be required so that the same random numbers are always obtained fromthe same seeds�

�� Attitude and Orbit Related Tasks atFunctions�

The attitude and orbit related functions in atFunctions will be used in various purposes suchas� command planning� assign SKY coordinates to events �section �� creating the Filter �les�section �� calculate the exposure maps� and carry out barycentric corrections �section ��They may require either or both of the attitude �les and orbit �les �section �� The followingare examples of the tasks in atFunctions�

�� Attitude Information

� Obtain qparameters and�or Euler angles for given ASTROE time inputs�

� Determine the pointing direction of each telescope�sensor for given ASTROE time inputs�

�� Orbit Information

� Obtain satellite orbital position for given ASTROE time inputs�

� Obtain magnetic cuto� rigidity for given ASTROE time inputs�

� Determine if the satellite is in day �sunlit� or dark �not sunlit� for given ASTROE timeinputs� Also obtain the elapsed time after the last daytodark or darktoday transitions�


� Determine if the satellite is in the South Atlantic Anomaly or not for given ASTROE timeinputs� Also obtain the elapsed time after the last SAA passage�

� Obtain sidereal direction of the magnetic �eld line for given ASTROE time inputs�

�� Attitude and Orbit Information

� Output the angles from the earth rim and sunlit part of the earth for given ASTROE timeinputs�

� Determine if the pointing direction is blocked by earth or not� If it is� determine if the earthis sunlit or not�

�� Ray�tracing function library xrrt�

The ASTROE raytracing package named xrrt has been written in C�� and is available as afunction library� This library provides function to load mirror� obstruction� and re�ection tablesfrom FITS �les� and then to trace photons through the mirror sets and collect statistics about theresults� See section �� for detail�

� CHAPTER �� ASTRO�E FUNCTION LIBRARIES

Chapter �

Planning and Simulation Software

In this chapter� ASTROE softwares used for observation planning and simulation are explained�

�� Observation Planning Software

�� TAKO �Timeline Assembler� Keyword Oriented�

A planning software package named �TAKO� �for Timeline Assembler� Keyword Oriented� isdeveloped for ASTROE by GSFC based on the methods used for ASCA and XTE�This package is designed to accommodate ASTROE speci�c constraints� These constraints

are determined in cooperation of ISAS and GSFC instrument and operations teams� Postlaunchchanges will be handled in a similar fashion� As has been the case for ASCA� a technician isexpected to be hired by GSFC to stay at ISAS to take care of running TAKO to produce regularobservation schedules�TAKO will be used not only by satellite operators and command planners at ISAS but also

by general ASTROE Observers� Users input observation time� target position and optionally thesatellite aspect� then they will get observation conditions such as values of the magnetic cuto�rigidity� times of the ground contacts� earth eclipses� and SAA passages� Either ASCII dump orgraphical output �such as that by ASCA �DP��gure �� will be available� so that users couldeasily see the Good Time Intervals �GTI� of the observations� TAKO will be accessible throughWeb interface�

�� MAKI

MAKI is developed at GSFC for ASTROE and future multimission planning�� As its name stands�users may run MAKI through a Web browser �users will need to obtain and install the �LHEAPlugIn� �� Users may place di�erent 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 indicateif the roll is allowed or not by di�erent colors for a given time period� Users can also view the sunangle visibility limits for several missions� as well as adding phase constraints� MAKI is expected toreplace the ASCA command planning program �adcongra� which had similar but more primitivefunctions�MAKI accepts a sky image �le from �SkyView� �� or almost any FITS image �les� It also lets

users save the results� and reload them� In �gure �� 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��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 canlaunch from the SkyView output page if Advanced� interface is selected�

��

� CHAPTER �� PLANNING AND SIMULATION SOFTWARE

Figure �� An example of the ASCA DP�� plot� TAKO is supposed to produce a similar plotfor ASTROE�

Figure �� An examples of the MAKI plot� An XRS �eld of view is displayed on an optical imageobtained from SkyView�

�� SIMULATION SOFTWARE ��

�� Simulation Software

ASTROE simulation softwares will have the following purposes� First� simulation softwares will beused to study technical feasibility of planned observations� Second� they will be used to determineinstrumental responses in order to simulate and understand physical processes in the instruments�Third� they may be used in data analysis when instrument responses are di�cult to determine andMonte Carlo approach is considered more e�ective� Finally� simulated data sets will be used toverify softwares for data analysis and processing�

�� Counting Rate Simulation � PIMMS

When planning observations� the �rst thing needed is to estimate the expected counting rates� Forsuch a purpose� PIMMS �Portable� Interactive� MultiMission Simulator� has been developed atGSFC and already widely used in the communityUsers 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�� cm�� or counting rates from other satellites�instruments�

As of early �� PIMMS already calculate expected counting rate for ASTROE� See detailsathttp��heasarc�gsfc�nasa�gov�docs�software�tools�pimms�html ��

�� Spectral Simulation � XSPEC

The XSPEC spectral �tting package has a capability to simulate instrument dependent pulseheightspectra for given input photon spectra�� To that end� XSPEC requires not only the e�ectivearea and e�ciency �ARFs � Ancillary Response Files�� but also the response matrices �RMF �Redistribution Matrix Files��

GOF has released a suite of the ASTROE response functions for spectral simulation purposes�See� http��heasarc�gsfc�nasa�gov�docs�astroe�aehp prop tools�html for details�

�� XRT Ray�tracing Package � xrrt

The raytracing package� named �xrrt�� is developed at GSFC ADF �Astrophysics Data Facility�code �� in cooperation with ISAS� Nagoya University and GSFC mirror team �cod �� Thepackage is written in C�� It is available as standalone FTOOLS� xrrtrt and xrrtray �table�� or as a function library �section �� for use by other FTOOLS such as xrssim �section��

xrrtrt creates re�ection tables for use by xrttray� These tables give surface re�ectivity as afunction of surface type� energy� and incident angle� xrrtray traces photons using the xrrt librarythrough de�ned thinfoil 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 statisticalsummary�

The raytracing package will be used to determine physical parameters of the mirrors which aredi�cult to measure �e�g�� surface densities�� by comparing the actual data and simulations� XRTresponses such as point spread functions and e�ective areas will be determined through iterationsof the raytracing simulations and actual calibration data�

The ray tracing package is also useful to simulate observations when making plans or analyzingdata� For example� if there are bright sources outside of the �eld of view� amounts of the straylightscan be estimated through the raytracing simulations�

�The WWW version of PIMMS� W�PIMMS is also developed and available athttp��heasarc�gsfc�nasa�gov�Tools�w�pimms�html �

�The WWW version of the XSPEC spectral simulation�WebSpec� is available athttp��heasarc�gsfc�nasa�gov�webspec�webspec�html�

�� CHAPTER �� PLANNING AND SIMULATION SOFTWARE

Figure �� An example of the XRS event simulator� xrssim output� The source is the supernovaremnant CasA� and the expected XRS pixel count distribution is shown on the simulated contourmap�

�� Detector Simulators

The detector responses shall be made based on the pre and postlaunch calibrations� In the courseof determining the detector responses� response generators will be developed to understand physicalprocesses taking place in the detectors� The response generators are easily converted into detectorsimulators� The only di�erence will be that while response generators calculate bulk properties ofthe instrument responses �e�g� response matrices for the entire energy band�� detector simulatorsshould be able to output a single pulseheight signal corresponding to a single input photon witharbitrary parameters� The detector simulators will be used to construct the endtoend simulator�see below� combined with the XRT raytracing 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 processtaking place in the detector�� However� such big software packages may not be suitable for distribution and not necessary for most Guest Observers� In such a case� ASTROE GOF will providesimpli�ed versions of the simulator for general use� which should be more compact but equippedwith most functionalities of the full simulator� This may be done� for example� by precalculatingdetector response matrices with the fullsimulator� so that the simpli�ed simulator can refer to theprecalculated response matrices to calculate expected pulse heights for input photons�

�� End�to�End Simulator � xrssim

One can build the endtoend ASTROE simulator by combining the raytracing package andthe detector simulators� The endtoend ASTROE simulator will read input photon lists having

�For example� HXD team is planning to build a full detector simulator by incorporating the generic libraries forhigh energy physics �developed at CERN� to simulate the particle interactions taking place in the detector�


arbitrary spatial and energy distribution� and outputs simulated event lists� fully simulating thepaths of the Xray events from the telescope openings to the detector electronics�The �rst ASTROE endtoend 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 beuseful to simulate observations of extended sources� Also� xrssim has a capability to simulate theXRS event grades �sections �� and �� hence will be used to see e�ects of the event pileupin bright source observations� In �gure �� we show an example of the xrssim output� Similarto xrssim� the XIS event simulator� xissim� is also being developed as an FTOOL�

�� ASTRO�E Simulator and Data Analysis

Endtoend simulators will be also used for data analysis when the instrument response functionsare di�cult to determine� For example� it will be laborious to determine spatial structures andtemperature distributions of clusters of galaxies from XIS data� since XRT PSF has signi�cantspatial dependences� In such a case� the ASTROE simulator may be used to create simulatedimages and spectra of clusters of galaxies with di�erent values of the physical parameters �e�g��temperature and �parameter� through Monte Carlo simulations� By comparing the simulateddata with actual observations� one may choose the most likely cluster parameters to mimic theobserved data�

�� CHAPTER �� PLANNING AND SIMULATION SOFTWARE

Chapter ��

Data Analysis and ProcessingSoftware

In this chapter� ASTROE software tasks are de�ned and explained� These tasks are required forthe data processing from the data acquisition at ISAS to the delivery to ASTROE Observers� andfor the data analysis by ASTROE Observers�

�� Overview

Figure �� illustrates an overview of the ASTROE data �ow� which we conventionally divide intofour Stages� from satellite speci�c calibration at ISAS �Stage �� to the scienti�c data analysis byASTROE Observers �Stage ��

In general� software tools used in the earlier stages are not required to be portable �i�e�� runonly at ISAS and�or GSFC�� but have to be stable enough so that the data do not have to gothrough these stages repeatedly� On the other hand� softwares in the later stages have to be moreportable and �exible� so that ASTROE Observers can reprocess�reanalyze their data repeatedlyby themselves�

All the softwares to be used in Stage � and Stage � are distributed to ASTROE Observers�In particular� it is important to distribute the softwares for calibration so that ASTROE Observers can recalibrate their data when new calibration information is made available� All thedistributable ASTROE softwares are included in the FTOOL package� The ASTROE FTOOLSare summarized in table ��

�� Stage � � Satellite Speci�c Calibration at ISAS

This is the stage to carry out satellite speci�c calibration�corrections� This stage is performedonly at ISAS� thus softwares to accomplish these tasks are not required to be portable� Inputs tothis stage are satellite raw telemetry and other satellite speci�c �e�g�� orbit and clock� information�Outputs are the Raw Packet Telemetry �RPT� �les� attitude �les� and orbital �les� These �les� aswell as the First FITS Files �section �� are regularly sent from ISAS to GSFC ��gures �� and��

�� Orbit Determination

The ASTROE orbit will be determined by NASDA� and orbit �les will be regularly sent to ISAS�ASTROE orbit �les will have the same FITS format as that of the ASCA orbit �les�

��

�� CHAPTER �� DATA ANALYSIS AND PROCESSING SOFTWARE

Stage 0

Stage 3

Stage 2

Stage 1

Raw Telemetry

First FITS Files

Satellite SpecificCorrections

FITS Conversion

Calibration

Data Analysis

KagoshimaSpaceCenter

Astro-ESatellite

Processing products

Raw Packet Telemetry (RPT) FilesAttitude Files

Orbit Files

PresentationPublication

GOAL

GSFC

ISAS

GuestObservers

Figure �� Overview of the ASTROE data �ow�

�� 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 whowill work fulltime on the ASTROE attitude determination� The same FITS format as the ASCAattitude �les may be also used for ASTROE�

�� Create RPT �les from the SIRIUS Database

The telemetry database at ISAS is named SIRIUS� in which all the telemetry �les of past ISASmissions are stored �sections �� and �� The ISAS data center� which is suppose to take careof all the ISAS mission data� puts the ASTROE data sent from KSC into the SIRIUS database�SIRIUS database is available on the UNIX workstations for ASTROE�� Format of the SIRIUS�les will be similar to the original ASTROE telemetry format �section ��The ISAS ASTROE 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 formatsare conserved� RPT �les may be considered as the original telemetry �les� just being wrapped byFITS headers� Satellite clock correction and correct time assignment may be carried out at thisstage� RPT �les are portable� and regularly sent to GSFC for a backup purpose�There will be one RPT �le per observation sequence �section �� RPT �les have three

columns� for the TIME when the packet was created �in ASTROE time� section �� the APID�and the CCSDS packet� RPT �les have names like�

aeYYYYMMDD HHMM HHMM�rpt �ae�� rpt is an example��

�Until ASCA� SIRIUS was mounted only on the main�frame computers�


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

�� Stage � � Conversion of the Telemetry to the FirstFITS Files

ISAS shall further process the RPT �le� using the �st Stage Software� to create the First FITSFiles� which should conform to the FITS standard de�ned by HEASARC� The First FITS Fileswill 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 speci�cdata that require special knowledge to be understood�� In addition� columns for the physicalquantities to be derived from these low levels values should be already present in the First FITSFiles��Access to the RPT �les is limited only to when creating the First FITS Files at ISAS� Routine

data processing for scienti�c data analysis shall start from the First FITS Files� Hardware teamsshall 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 �stStage Software�

� When revisions are made to the �st Stage Software� GSFC processing team shall generatenew 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 aback�up� all on an ongoing basis� and the �st Stage Software and related �les as necessary�

�� First Stage Software � mk�st�ts

First Stage Software consists of the following components�mkcom�stfits � binary executable for Common instruments �only create HK �les�mkxrs�stfits � binary executable for XRSmkxis�stfits � binary executable for XISmkhxd�stfits � binary executable for HXDmk�stfits � script to drive the executables aboveEach executable reads a single RPT �le� and output many First FITS Files� for di�erent kinds

of science and HK data and observation modes �see below�� Tasks of the �st Stage Software mayinclude� time assignment� reformatting of event data into standard FITS binary tables� conversionof raw digital readout to physical units for housekeeping data� and splitting of event data whensuch major mode changes occur that requires signi�cant �leformat changes�The �st 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 �st Stage Software shall be able to run both at ISAS and GSFC on some speci�cmachines�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 neednot be modally split for such minor mode changes that do not require FITS format changes�� neednot contain the full set of keywords necessary for analysis� and the GTI table may be preliminary��

�Examples are the PHAS column in the XIS �x� event les for the �� pixel values� and the separate integercolumns from which XRS event arrival time will be calculated�

�Corresponding to the examples above� PI and GRADE columns for the former� and the TIME column for the lattershall be present�

�The minor� mode change requires referring to the house�keeping data to be identied� For example� usingXRS Filter Wheel �section �� or XIS Window option is considered such minor observation modes�

�GTI in the First FITS Files should correspond to the time intervals when the telemetry exists� regardless of theinstrumental status or observational conditions �see section �� and ��

� CHAPTER �� DATA ANALYSIS AND PROCESSING SOFTWARE

Instrument Mode nameXRS� NoneXIS� x�x bst

x�x bst

�x��x� bst

timing

frameNNN�frameNNN bst�frameNNN psum�darkframeNNN

darkinit�darkinit bst�darkinint psum

darkupdata� darkupdate bst

HXD� wel�trn�bst NNN

�NNN is the sequential number within the RPT�

Table �� Observation mode names used for event First FITS Files�

Within a single RPT �le� science data taken with the same �major�� instrumental mode willbe put in the same First FITS �le� even if there are timegaps within it� For example� if XIS isswitched from the �x� mode to �x� mode then back to the �x� mode� the �rst and later �x� modeevent data shall be combined into a single First FITS File� In other words� mk�stfits separatesthe input RPT �le into di�erent �major� observation modes� and creates FITS event �les for eachmajor mode�Major modes are determined only by looking at the science packet� while knowing minor modes

will need HK packet information ��gure �� 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 ��

�� First FITS File Names

First FITS Files consist of event �les �science �les� and HK �les for each instrument� For both ofevent and HK �les� the root name of the RPT �le name from which First FITS Files have beenproduced is inherited� For example� if the RPT �le name is ae�� rpt� the FirstFITS File names always start with ae��

Event Files �Science Files�

After the RPT root name� an instrument name and a majormode namewill followwith underscores�� between them� The instrument name is either xrs� xis�� xis�� xis�� xis or hxd� Su�xwill be ��fff�� The major mode names are listed in table ��On XIS� the major mode names correspond to all the possible combinations of the Clock modes

and Edit modes �bst and psummeans Burst option and Parallel Summode� respectively� see section�� The three HXD major modes correspond to the WPU main event data� TPU Transient data�and TPU gammaray burst data �sections �� and ��Examples of the First FITS File names are shown below�

ae�� xrs�fff

ae�� xis� x�fff

ae�� xis� x�fff

ae�� xis� �x��fff

ae�� hxd bst�fff

ae�� hxd trn�fff

�Major� modes dene the event formats �such as the XIS �x�� x� and �x� modes�� Observational modes whichdo not change the event formats are considered minor modes �such as the XIS Window option��


Instrument HK identi�er MeaningCOM� com common instrument HKXRS� xrs �s HK items which come out every � sec

xrs cdp CDP HKxrs dump Dump HKxrs echo Echoxrs error Errorxrs mem Memory dump HKxrs rates CDP Ratesxrs reply Reply

XIS� xis� xis� xis� xis XIS HK for each sensorHXD� hxd HK data� system status� ACUHK� ROMHK

hxd tbl Status monitor� PI program parameters� PI program statisticsAE parameter table �SC�HC�

hxd dmp Memory dump� I�O dump� ECC dump� ROM I�O dumpROM ECC dump

hxd hst Histograms� SlowFast �SF� Coarse� SF Fine �� SF Fine ��PMT spectrum� PIN spectrum� DeltaT

hxd scl Scaler HK

Table �� HK identi�er names for HK First FITS Files and their meanings�

ae�� hxd wel�fff

HK Files

Instrument names are the same as the event �les� except that com is used for the common HK �le�Su�x of the HK �les is �hk�� The HK identi�ers and their meanings are shown in table ��Examples of the HK �le names are shown below�

ae�� com�hk

ae�� xrs �s�hk

ae�� xrs cdp�hk

ae�� xis��hk

ae�� hxd�hk

ae�� hxd tbl�hk

ae�� hxd dmp�hk

ae�� hxd hst�hk

�� Stage � � Apply Instrument Speci�c Calibration

The First FITS Files shall be further processed into the Calibrated FITS Files by the �nd StageSoftwares� The �nd Stage Softwares are developed by the hardware teams in conjunction with theGOF� and distributed to public within the FTOOL package �table �� Populating the columnsfor physical quantities �such as pulse invariant values and sky coordinates� is the major task inthis Stage�The formats of the First FITS event �les and Calibrated event FITS �les shall be as close to


Name FunctionAttitude�Orbitastemkehk Create attitude and orbit Extend HK �EHK� �lesCommon�Processingmake�lter Create a Filter �le from HK and EHK �lesCommon�Analysisastearf Generate XRS and XIS ARFs for spectral analysisastescreen Carry out standard data screening of the event �lesasteexpo Create exposure maps for XIS and XRS image analysisastetimeconv Carry out barycentric correctionCommon�Simulationmkphlist Create a photonlist �le for xrssim or xissim simulationsXRTxrrtrt Create raytracing table to be used for xrrtrayxrrtray Perform XRT raytracingXRSxrsmkgainhist Create XRS gain history �lexrspi Fill the PI column of the XRS event �le using the gain history �lexrscoord Fill the coordinate columns in the XRS event �lexrscrosstalk Find and �ag the crosstalk eventsxrsrti Calculate Rise Time Invariance �RTI� from Rise Timexrsrmg Generate XRS spectral response averaging dependency on pixelsxrsimage Calculate XRS pixel pattern � image� projected onto the skyxrsspecsim Simulate the physical process and onboard processing of the detectorxrssim From a photonlist� generate a simulated XRS event listXISxismkgainhist Create XIS gain history �lexispi Fill the XIS GRADE� PHA and PI columns of the XIS event �lesxiscoord Fill the coordinate columns of the XIS event �lexistime Time assignment for Burst mode� Psum mode or Window optionxisrmg Generate XIS RMF for spectral analysisxisclean Remove hot pixelsxis�at Correction of light leak� DFE� zero peak extentxisspecsim Simulate the physical process and onboard processing of the detectorxissim From a photonlist� generate a simulated XIS event listHXD�WPUhxdtime Fill TIME column of the Well event �lehxdmkgainhist Create the HXDwell gain history �lehxdpi Fill the PI column of the event �le using the gain history �lehxdgrade Fill the GRADE column of the event �lehxdrsp Merge RMFs and ARFs to create RSPshxdarf Create the HXDWell ARFshxdmkbgd Model and Estimate the HXDwell backgroundhxdscltime Time assignment for Scaler HK dataHXD�TPUhxdtrntime Fill TIME column of the Transient data �lehxdtrnbintbl Create the Transient data Binning tablehxdmktrngainhist Create the HXDtransient data gain history �lehxdtrnpi Calculate the PI for the HXDtransient data using the Binning tableHXD�TPU �burst�hxdbsttime Fill TIME column of the gammaray burst event �les

Table �� ASTROE FTOOLS list


identical as possible� Any calibration softwares that run on the First FITS Files must also be ableto run on the Calibrated FITS Files� New columns may be added but existing columns shall notbe removed� This ensures that recalibration is possible on the Calibrated FITS �les� not requiredto start from the First FITS �les�This Stage will be run both at ISAS and GSFC in the pipeline processing �section �� When

recalibration is necessary for already distributed data� Guest Observers also shall be able to runthis Stage on their data using distributed FTOOLS ��gure ��

�� Stage �� Preprocessing

� Produce a Filter FileWhile 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 convenientto 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�� A single Filter �le will madefrom a single observation sequence� Counting rates of the instruments and�or BGD monitorsare also used for deadtime correction �section �� Instrument speci�c items� such as theelapsed time after recharging the ADR for XRS �section �� will be also included in theFilter �le�

� Create Extended HK �EHK� FilesThe 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 formatas the HK �les� from attitude and orbit �les� Attitude and orbit information are thusimplemented in the Filter �le�

� Determine the Average Pointing DirectionsFrom the attitude �le� average pointing direction is determined� which is used later as areference point to assign sky coordinates to each XRS and XIS event� The FTOOL attitude

will be used�

� Create Time Dependent Calibration FilesTime dependent calibration �les� such as the XRS and HXD gain history �les to be usedfor later processing� are created from the First FITS Files� XRS and HXD gains arelikely 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 ��The hxdmkgainhist will create the HXD gain history �le�

When long term instrument performance change is signi�cant� time dependent calibration�les may be created not only from a single sequence� but also frommany sequences covering along period�� Such calibration �les covering a long timeperiod may be put in the CalibrationDatabase �CALDB� see chapter �� and also used to correct long term performance variationsof the instruments�

�� Stage �� Re�ne the First FITS event �les

� Separate event �les for minor observation modes�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� magneticcut�o� rigidity� and times of the South Atlantic Anomaly passages�

�In the case of ASCA� long term changes of the GIS temperature�gain coe�cients and SIS charge transferine�ciency are such examples� They are respectively recorded in the calibration les gis temp�gain�fits andsisph�piddmmyy�fits �where dd� mm and yy are date� month and year of the release respectively��


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 ��and number of lines to add in the Parallel Sum mode �section �� are such examples�

The XIS HK items to distinguish minor modes are in the Filter �le or HK �les� and usingmaketime� 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 tothe GTI thus calculated�

Another example of the minor mode on which First FITS event �les are separated is theHXD time resolution� which is variable and may be known by looking at the correspondingHK parameters �p� ��

The separated event �le names will have the minor mode and the sequence number attachedto the original �le name� For example� if there are two di�erent Window options in the FirstFITS File ae�� xis� x�evt� they will be named asae�� xis� x win��evt and ae�� xis� x win��evt�

� Calculate GTI and update the GTI extension in the event �leGTI extensions in the FITS Files are preliminary� and correct GTI calculation may requirecrossreferencing several HK items� This task is carried out in this Stage with the FTOOLmaketime� by referencing First HK FITS �les or Filter �le� It is assumed that all the necessaryHK 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�� from the XRS GTI� as the scienti�c data do not come out during that period� TheGCC 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 ofthe GTI suitable for scienti�c data analysis will be made in a later Stage �see section ��

� Flag XRS crosstalk events� sort events in time orderBy crosscorrelating XRS event arrival times� �nd and �ag crosstalk events� which are falseevents due to crosstalk of the onboard event processing system� Also� sort events in timeorder� 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 modeIn the XIS Timing mode� there is only one dimensional position information� and the RAWYvalues represent relative event arrival times �sections �� and �� A special tool will benecessary which reads Timing mode event �les and overwrite the TIME column� calculatingthe event arrival times from the RAWY values� Location of the source on the detector willbe necessary� This task is carried out by the FTOOL xistime�

�� Stage �� Apply Calibration and Fill Columns

Instrument speci�c calibration is performed and corresponding event �le columns are �lled� Observation speci�c� instantaneous calibration information should be extracted in advance at Stage�� Other general calibration information is taken from CALDB �chapter �� Following taskswill be performed�

� Calculate PI from PHA

PI values are calculated fromPHA values for all the three instruments� The astetool functionswill be used �section �� in conjunction with appropriate calibration �les �such as XRSgain history �le�� This task is carried out with the FTOOLS xrspi� xispi and hxdpi forXRS� XIS and HXD respectively�


� Calculate SKY Coordinates �XRS and XIS�When the First FITS Files are created� only the coordinate columns to indicate locationson 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� instrumentalignments� described in calibration �les� and satellite attitude information� taken from theattitude �le� are necessary� The FTOOLS xrscoord and xiscoord will be used for XRS andXIS respectively�

�� Stage �� Re�ning Calibrated FITS Files

Further processing of the Calibrated FITS Files� such as splitting the �les by minor mode for thedistribution 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 FilterWheels are changing in order to check the instrumental performance� On the other hand� forscienti�c data analysis by Guest Observers� it will be more convenient that the event �les are splitaccording to the Filter Wheels used� Just like the minor mode operation task for XIS �section�� combination of the FTOOLS maketime and extractor will do the necessary task�After the re�nements 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 GTIextensions� and are split by instrumental modal parameters� They are ready for extraction of thescienti�c data products� except that they still include �noises� such as particle background events�

�� Stage � � Data Analysis

The Unscreened event �les and �lter �les are distributed to ASTROE Observers� and ready fordata analysis� This Stage is primarily carried out by ASTROE Observers� but the standard datascreening� extraction� and corresponding response generation may eventually be implemented inthe Pipeline processing� as the processing system is getting improved��

�� Stage �� Data Screening

Data have to be screened to reject background before extracting scienti�c products� Data screeningcriteria 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 scienti�c analysis is calculated based on the HK parameters in the Filter �le� byexcluding time intervals when� for example� BGD is high� temperature of the instrument is notappropriate� 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 �lesare used to extract Screened event �les or other scienti�c products such as images� spectra andlight 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 ormore �exposures� �section �� Choosing or rejecting a batch of events in the same frame orexposure 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 framesaturation �ag�

�In the case of ASCA� implementation of the automated data screening� extraction and response generation intothe pipe�line processing has required almost years of study�


Filtering Events

Eventbyevent data selection is often necessary for all the three instruments using some kinds ofevent quality �ags�

� XRS� XIS and HXD event selection based on event �agsIn the XRS event FITS �le� each event record carries sixbit event �ags which tell qualityof the event �section �� For example� only the Hires events may be chosen for the bestenergy 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� Xrayevents have only certain Grade values �� and events with other grades have to be discarded�HXD events may be also attached similar quality �ags� as an output of the onboard eventprocessing �section �� The fselect FTOOL will be used for event selection based onthe event quality �ags�

� Remove XIS hotpixelsXIS has an onboard hotpixel detection algorithm and can send event lists without hotpixels �section �� However� in order to con�rm the onboard algorithm and to removepossible hotpixels or �ickering pixels� a program to remove hotpixels will be necessary� Thexisclean FTOOL� which will be analogous to the cleansis FTOOL for ASCA SIS� will beused�

� HXD event selection on the Fast vs� Slow decaytime planePure GSO Xray�gammaray events will fall onto a narrow region on the two dimensionalFast vs� Slow decaytime plane �section �� gure �� The onboard PSD is expectedto discriminate and �ag the GSO events �section �� However� in order to check the onboard algorithm and to furthermore narrow the region to reduce background� a software taskis necessary to �lter only events falling on a particular region on the Fast vs� Slow decaytimeplane� The flookup FTOOL is expected to be used ��

� Separate HXD PIN and GSO eventsHXD WPU main data include the events which hit only GSO or PIN� or both� Data analystsmay choose one of them according to their purposes� This may be done with the fselectFTOOL using event �ags �section ��

Data Screening Script � astescreen

Data screening tasks described above will be �semi�automatically carried out with the astescreenscript� which will be written in Perl and spawn several necessary FTOOL tasks� astescreen willbe implemented in the Pipeline processing �section �� for standard data screening� and alsoused by Guest Observers to screen data with their own criteria�

�� Stage �� Extract Scienti�c Products

Scienti�c 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� Dataanalysts may apply their own data extracting criteria such as sky regions� time intervals� or energyranges� The xselect FTOOL� in conjunction with extractor� will be mostly used�Scienti�c 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 instrumentalresponses 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 �� and events��This is similar to the ASCA GIS screening on the two�dimensional PHA vs� Rise Time plane �gisclean�� for

which flookup is used�


is extracted from multiple pixels� the spectral �le will have to keep the number of events from eachpixel selected� xselect and�or extractor may need to be modi�ed to implement such ASTROEspeci�c requirements�

�� Stage �� Generate Observation Speci�c Responses

Observation speci�c instrumental responses are generated� and necessary corrections are performed�Inputs to this Stage are products created in the previous Stage� and outputs are observation speci�cresponses 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 matriceswhich describe relationships between the input Xray energies and output pulseheights� ARFdescribes the telescope e�ective area or collimater transmission corresponding to the extractedenergy spectra� Instrumental e�ciency may be included either in RMF or ARF�

� Generate RMFIf RMFs are invariable with time and observation conditions� they can be put in CALDB �asis the case for ASCA GIS�� In general RMFs are speci�c to each observation and have to becreated with RMF generators �like sisrmg for ASCA SIS�� Inputs to the RMF generatorsare spectral �les created in the previous Stage and calibration �les from CALDB� outputsare observation speci�c RMF� The FTOOLS xrsrmg and xisrmg will be used for XRS andXIS respectively��

� Generate ARFThe XIS and XRS spectral �le should keep the information on the event distribution on thechip�pixels� which is combined with the XRT response �les �section �� to calculate theARFs� For XRS� in order to calculate ARFs for selected pixels� the pixel sizes� shapes andcon�gurations are necessary� which are taken from the XRS pixel map �section �� ForHXD� ARF is calculated from source position in the FOV using HXD collimater responses�section �� The astearf FTOOL will be used to create ASTROE ARFs for XRS andXIS� 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 thecorresponding exposure maps� Exposure map is necessary when obtaining counting rates of thesources and making a mosaic from multiple images� Attitude �les will be necessary� as exposuremaps are usually made in the SKY coordinate� The hotpixel lists will also be necessary for XISto correct pixels which are not used in creating the images�The vignetting maps describe the telescope vignetting and optionally instrumental e�ciency

for given celestial images� Vignetting map is necessary to correct telescope vignetting and obtainsource �uxes through image analysis� XRT calibration �les in CALDB will be necessary �section��The exposure maps and vignetting maps are made with the aeexpo FTOOL both for XRS and

XIS�

Apply Corrections

� Deadtime correctionThe instrument deadtime is corrected for light curves� spectra and images� This is necessaryfor XRS and HXD to determine the correct exposure times and Xray �uxes for bright sources�

��HXD GSO and PIN RMFs are expected to be time�invariable�


The FTOOLS xrsdtcor and hxddtcor are used for XRS and HXD respectively� using theFilter �le created in Stage ��

� Barycentric correctionThe event arrival times on the satellite are converted to the arrival times expected at thebarycenter of the solar system� This is necessary for precise timing analysis� The orbital �lewill be necessary� The timeconv FTOOL for ASCA is expected to be used with minimalmodi�cation for ASTROE too�

Generate Background Files

Background data will be necessary for precise spectral and image analysis� Because of the smallFOV and extended XRT PSF� it will be di�cult for XRS to take simultaneous background datain the same FOV� so will be for XIS when observing extended sources� Therefore� it is desirable totake blank sky data and night earth data in an early stage of the mission� and make the backgrounddatabase immediately available to Guest Observers� Background spectra and images are extractedusing xselect from these blank sky or night earth background database�For HXD� non Xray background will be calculated and reproduced based on some empirical

models� The hxdbackest FTOOL will be used for this purpose�

�� Stage �� Scienti�c Analysis and Consideration

Scienti�c analysis is conducted using the scienti�c products and responses created in the previoustwo Stages� Observers make scienti�c consideration and judgment on their data analysis results�According to their needs� they may reextract scienti�c products �back to Stage �� and�or changedata screening criteria �back to Stage �� They may even go back to Stage � if they need torecalibrate the data or recreate the Filter �le� In any case� they will never go back to Stage ��gure ��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�ASTROE speci�c data analysis tools are explained below�

Image Analysis

� Display XRS image� and superpose images or FOV of the three instrumentsSince XRS is not a full image instrument and its pixel shapes and con�gurations are peculiar�a special tool is required to display XRS images on the sky� The xrsimage FTOOL willproject the XRS pixel con�guration on the sky� taking account of attitude wobbling� It willallow to overlap the XIS image and HXD FOV too�

The XRS pixel map in CALDB �section �� and �� will be used to handle the XRSpixel shape and con�guration� The HXD transmission map is also used �section ��

�� Pipe�line Processing System

At GSFC and ISAS� signi�cant parts of the data processing tasks described in the previous sectionswill be carried out automatically by running specially developed scripts� We call this automatedsystem the Pipe�line processing�In the case of ASCA� the Pipeline processing scripts have been developed at GSFC ADF�

It contains over �� lines of ksh code and is running only at GSFC� The ASTROE Pipelineprocessing scripts is primarily developed at ADF� and written in Perl� The same processing scriptwill run at ISAS� with the same versions of the calibration �les and softwares� A particular careshould be taken so that exactly the same processing scripts run at GSFC and ISAS �see section��


The Pipeline processing mainly handles tasks in Stages � and � described in the previoussection ��gure �� After Stage �� data are delivered to ASTROE Observers� who are supposedto carry out most tasks at Stage �� However� some tasks in Stages � may be also automated andimplemented in the Pipeline processing�As the calibration and softwares are updated� the Pipeline processing system will be revised�

and the same data will be reprocessed with the new system� The new products will be shippedto ASTROE Observers if the new processing is done within the proprietary period� The newproducts also replace the old ones in the ASTROE archives �chapter �� To distinguish di�erentversions of the Pipeline processing system� they may be called REV�� REV�� REV� and so on�for revision �� and so on respectively�The REV� pipeline products are put under the HEASARC archive directory�

ftp��legacy�gsfc�nasa�gov�astroe�data�rev��All the ASTROE 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 sequencenumber�For example� the sequence �� is a ground test data �thermal vacuum test� taken at ISAS

on September �� That data is found atftp��legacy�gsfc�nasa�gov�astroe�data�rev��

and there are the following subdirectories�

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 HKFirst FITS Files� Calibrated �les ��un�ltered �les�� are in the unfiltered directory� Eventually�we are going to have filtered directory in which standard ��ltered� event �les will be put�


Chapter ��

Calibration

It is instrument teams� responsibility to calibrate instruments� release the results� and deliver tothe calibration database �CALDB� section �� Products of the calibration activities are to bematerialized in the forms of documents� softwares or calibration �les� ASCA GOF is responsiblefor obtaining the calibration products from the instrument teams and providing them to GOs ineither of the three forms�

�� Documentation

In cooperation with the instrument teams and the OGIP CALDB team� ASTROE GOF willprovide a set of documents which describe the ASTROE calibration� These documents should bepublic and available online in either of the text� postscript or HTML format� The document setshould cover at least the following subjects�

� Explain ground and inorbit calibrationASTROE GOF will help the hardware teams to document the calibrations� It will benecessary to document when and how the ground and inorbit calibrations are conducted�and which parameters are determined� Con�guration of the calibration experiments shouldbe illustrated�

� Explanations of the calibration �lesThe origins� formats� meanings� and usages of the calibration �les stored in the CALDB�section �� and �� are explained�

� Algorithms of building responses and making correctionsExplain the algorithms to construct instrumental responses and perform instrument speci�ccorrections using calibration �les and softwares� For example� it should be explained howRMFs and ARFs are created from spectral �les� and how exposure maps are made from event�les and attitude �les�

� Summarize important calibration parametersImportant satellite and instrument parameters determined through calibration are summarized� These parameters include� for example� positions of the optical axis for each sensor�

� Calibration uncertaintyUnexplainable systematic uncertainties of the latest responses are described so that dataanalysts are warned� It is instrument teams� responsibility to de�ne such calibration uncertainties� The latest calibration uncertainty information is distributed to Guest Observerswith their data� News articles regarding the latest calibration issue shall appear in theASTRO�E Newsletter� which is published by ASTROE GOF� from time to time�

��

� CHAPTER �� CALIBRATION

�� Calibration Software

Calibration softwares are primarily written by the instrumental teams� and will be incorporatedinto the function libraries �section �� simulation softwares �section �� or response generators�section �� ASTROE GOF will make the calibration softwares conform to the ASTROEsoftware conventions �chapter ��

When constructing instrumental responses or carrying out instrument speci�c corrections� it isimportant that algorithms and parameters be separated as much as possible� The calibration softwares should de�ne parameter independent algorithms� whereas instrumental parameters shouldbe put in the calibrations �les� Thereby� when either of the algorithms or parameters are changeddue to new calibration� only calibration softwares or �les need to be changed� It will be alsopossible to make di�erent test responses by changing only algorithms or parameters�

�� Calibration Database CALDB�

ASTROE calibration �les shall be put in the HEASARC Calibration Database �CALDB�� whichalso contains calibration �les for other high energy missions� All the calibration �les in CALDBshould conform to the OGIP standard FITS format�

�� 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 subdirectories 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 directoriesdata�mission�instrument for each instrument� and each directory contains three subdirectories�pcf� bcf and cpf� which respectively stands for the primary calibration �les� basic calibration �lesand calibration product �les�

Primary calibration �les are raw or almostraw calibration data� and will not be directly used toconstruct instrument responses� Ground calibration data will be archived and regarded as Primarycalibration data� Calibration �les used to perform instrument speci�c corrections or to constructresponses are called basic calibration �les� Responses themselves or calibration �les used in theStage � data analysis �section �� 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 positionalgain variations of the sensors� are examples of the basic calibration �les� SIS and GIS RMFs arecalibration product �les and put under the cpf directory� In the case of ASTROE� we have a planto archive ground calibration data� which will be put under pcf� Most of the important calibration�les listed below �section �� are considered basic calibration �les�

�� Time�dependent Calibration Files

Some calibration �les will be timedependent� If timescale of the variation is long enough �� acouple of months� to include many observations� the timevariable calibration �les may be put inCALDB to be used for the observations within the period� If the timescale is as short as the lengthof a single observation� the calibration �les will be created in the pipeline processing and used onlyfor that particular observation �section �� 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 withina single observation� These short timescale calibration �les will not have to be put in CALDB�

�See http��heasarc�gsfc�nasa�gov�docs�heasarc�caldb�caldb intro�html�


�� 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 onetoone correspondence� hence symbolic linksshould not be used� The calibration �les must have the mandatory CALDB keywords whichdescribe the nature of the �les and are referenced by CALDB softwares �see below��Recommended naming convention for the ASTROE calibration �les is the following�

inst kind yyyy�mm�dd�ext� or inst kind version�ext�

where inst is the name of the instrument �� kind is brief description of the �le� yyyy� mm and dd

are year� month and day of the release� respectively�� version is the version� and ext is the �leextension which can be fits or any other letters to describe the nature of the �le �e�g�� rmf orarf�� The kind and version may include hyphens �� periods �� may not be used anywhereexcept just before ext� For example� the XRS pixel map �section �� released on November in �� may have a name like xrs pixel�map ��fits� Files may be named withthe �version� scheme� such as hxd col transmission v��fits� However� once �les are namedeither in �yyyymmmdd� scheme or �version� scheme� the same naming convention should befollowed for the same kind of �les� so that names in the two schemes are not mixed�

�� Version Control

Control of the version and release of the calibration �les is very important� ASTROE GOF andinstrument teams should establish the standard procedure to deliver the �les to CALDB and releasethem� For each calibration �le� there shall be a contact person in the instrument team and one inGOF� and after they checked the validity of the �le and agreed to release� the �le will be shippedto 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 briefdescriptions for all the calibration �les included in this directory and the subdirectories� Theseinformation are taken from the mandatory CALDB keywords in each calibration �le� Also in thecaldb�indx �le are quality and validity �ags of all the calibration �les which are to be judgedby ASTROE GOF and instrument teams� A package of the CALDB access softwares to chooseappropriate 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 CALDBon their sites� or they may get only necessary �les for their analysis�

�� Important Calibration Files

ASTROE GOF and the instrument teams will determine which kinds of calibration �les arenecessary� and �x their formats� Although it is not possible at this stage to de�ne all the necessarycalibration �les� important calibration �les which will be de�nitely needed are listed below�

�� General

� Telescope de�nition �lesAlignments between the telescopes and instruments are described� In addition� parametersof the instruments and the coordinate systems� such as focal lengths and detector pixel sizesare written� There may be separate telescope de�nition �les for di�erent detectors�

�Either xrs� xis� xis�� xis�� xis�� xis�� hxd or aste �for general les��It is likely that the period of the calibration le release will spread over the year �� Therefore digits will

be desirable to denote years� So that les are sorted in chronicle order� year� month and date are put in this order�

�� CHAPTER �� CALIBRATION

� Satellite Information Base �SIB�Parameters for conversion from the digitized HK telemetry to the physical units are stored inthe multimission database named Satellite Information Base �SIB� located at ISAS� Essentialparts of the SIB will be extracted and put in the calibration �les� These calibration �les areused to interpret HK parameters in the telemetry�section ��

�� XRT

� E�ective areaXRT e�ective area corresponding to a certain encircled radius is given as a function of energyfor di�erent o�axis and azimuthal angles� Separate �les are made for XRTI and XRTS� Ife�ective areas for the four XRTIs are di�erent� there shall be more than one �le for XRTI�

These �les are made from calibration measurements and raytracing simulations �section�� and used to calculate ARFs and vignetting maps �section ��

� Point spread functionsAlthough point spread functions can be created from raytracing simulations� it will beconvenient to have a set of readymade point spread functions for di�erent o�axis andazimuthal angles� If there is energy dependence� the point spread functions have to be madefor di�erent energies�

Point spread functions are necessary when making ARFs �section �� and for imageanalysis such as image �tting and image deconvolution �section ��

� Files for the raytracing simulationsThe raytracing program �section �� requires two calibration �les describing the telescopeparameters� one for re�ectivity and the other geometrical structure of the foils�

�� XRS

� XRS pixel mapThe XRS pixel map indicates XRS pixel sizes� shapes� and con�gurations� This �le will beused 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 �leImportant XRS parameters required to build spectral responses are written� The parameterswill include� for example� thickness and heat capacity of each HgTe absorber�

� Gain history �leThe XRS gain� which is likely to be variable within a single observation� is written as afunction of time� This �le is created for individual observations at Stage � in the pipelineprocessing and used to calculate PI from PHA �section ��

� Blocking Filter parametersThickness and transmission for each Blocking Filter should be in a calibration �le �section��

� Filter Wheel parametersThickness and transmission for each Filter Wheel window should be in a calibration �le�section ��


�� XIS

� XIS hotpixel mapPositions of the hotpixels� May slowly vary with time�

� Time invariable XIS parameter �leImportant 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 �lesVariable instrumental parameters required to calculate PI from PHA and to build spectralresponses are written as functions of time� Gain history �pulsepeak of the calibration source�and Charge Transfer Ine�ciency �CTI� will be such examples� �

�� HXD

� HXD collimater transmission mapEnergy dependent collimater transmission is written as a function of the pointing vectorson the satellite frame� The direction which gives the maximum transmission becomes theboresite� This �le will be necessary to make HXD ARFs�

� HXD detector parameter �leImportant detector parameters required to build responses are written� These parametersshould include� e�g�� dimensions of the GSO crystals� silicon PIN diodes and the detectorassembly� This �le will be necessary to make HXD RMFs�

� HXD background parameter �leThe HXD background is expected to be empirically modeled �section �� Model parameters necessary to construct HXD background will be in the calibration �le�

�In the case of ASCA SIS� RDD �Residual Dark�currentDistribution� and echo parameters are also variable� andtime history of these parameters are also saved in the individual calibration les� RDD is expected to be negligiblefor XIS �section ��

�� CHAPTER �� CALIBRATION

Chapter ��

Guest Observer Support

In this chapter� we describe ASTROE GOF�s primary tasks to support Guest Observers �GOs��The GOs whom ASTROE GOF mainly targets are professional astronomers located in the UnitedStates who submit ASTROE proposals and analyze ASTROE data� Support of the ASTROEObservers in Japan and other countries and the ASTROE archives users all over the world is alsoenvisioned�

In order to perform the following GO support tasks� ASTROE GOF in cooperation withADF and other groups under OGIP will develop infrastructures such as softwares� documents anddatabase systems� Also ASTROE GOF will give accounts for the GO support issues to the usercommunity in occasions� and will provide personal assistance to GOs visiting GSFC�

�� On�line Service and Help

ASTROE GOF release most updated information through WWW at the ASTROE GOF homepage�

http��heasarc�gsfc�nasa�gov�docs�astroe�astroegof�html �Online email help desk is available at astroehelp�athena�gsfc�nasa�gov� to which GOs canask any questions regarding ASTROE� Recipients will be the ASTROE GOF members and somemembers of ADF� ASTROE GOF shall have a rota system with which one of GOF members byturns keeps track of the questions to make sure they are answered within reasonable time�

There shall be extensive ASTROE online databases with which GOs can retrieve variousASTROE information as well as the archival data� Details on the ASTROE database and archivesare explained in the next chapter�

�� Proposal Support

NASA will o�cially release the ASTROE NRA �NASA Research Announcement� to announce theGO opportunity of the ASTROE program� ASTROE GOF will be responsible for preparing NRAincluding instrumental specs required for GOs to prepare proposals� The indepth instrumentaldescriptions will be supplied as NRA appendices� ASTROE GOF will supply simulation tools�section �� and observation planning tools �section �� which are intended to be used by GOswhen 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 programsof other missions� The same RPS system will be used in US and Japan� The proposal databasenamed ARGUS oversees the proposal processing status� like which proposals are submitted andaccepted and if observations are scheduled� performed� processed or archived �section ��

��

�� CHAPTER �� GUEST OBSERVER SUPPORT

�� Observation Planning

ASTROE 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� Preliminaryobservational plans should be given in the proposals� and the �nal plans have to be con�rmed byGOs prior to the observations �section �� The procedure is that GOF members contact GOswhen the short term observation schedule is released� and ask GOs if there might be any changesfrom the observations plans in the proposals� If necessary� GOs may make small changes at thisstage �e�g�� slight change of the rollangle� consulting GOF advice� ASTROE GOF conveys the�nal GO observation plans to ISAS� and the ISAS satellite operation team incorporates the �nalplans into the command stream�When the observation is performed� the operation team at KSC brie�y describes the status of

the observation in the daily operation reports� which will be immediately archived at ISAS andGSFC so that GOs can see the status of their observations� Quick look analysis may be done bythe operation team at KSC in order to make sure the observation is correctly done� Rough lightcurves� images and energy spectra may be made� and plots of these products will be promptly sentto GOs through ISAS and�or GSFC�

�� Pipe�line Processing and Data Distribution

ASTROE GOF and ADF receive the data from ISAS and process them by adding calibrationinformation so that the processed data are ready to be extracted scienti�c information �section�� The softwares for processing will be mainly developed by ASTROE GOF in cooperationwith the instrument teams �section �� The US GOs receive the processed data fromGSFC� Thedistribution media will be CDROM as default� and optionally tape� DVD �Digital Versatile Disk�may become available� The proprietary GO data may be encrypted and put online using somereliable encryption protocol such as PGP� Thereby only GOs who are given the key can retrievethe data online and decode them�

�� Data Analysis Support

It is prospected that GOs would obtain data analysis softwares from OGIP�ASTROE GOFthrough Internet� install them� and use them to analyze their data on their sites� The analysis softwares will be developed and supplied by ASTROE GOF and OGIP� and should be easyenough to install and use �section �� Extensive documents and online help should be providedto assist software installation and use� and a standard and thorough data analysis manual shouldbe written by ASTROE GOF� Whenever GOs had questions� they can inquire to the GOF byemail or they may call GOF members in an emergency�GOs may visit GSFC to analyze ASTROE data� if they need expert advice or tutoring� or they

do not have su�cient computing resources� or they need directly access the ASTROE�HEASARCdatabase to retrieve huge amount of data� ASTROE GOF will have a rota system such that oneof the members by turns takes care of a visiting GO�

�� Community Oversight

An ASTROE Users Group will be established in order to provide advise on the ASTROE GuestObserver Facility services� The ASTROE Users Group and ASTROE GOF will have regularmeetings to discuss guest observer support issues�

Chapter ��

ASTRO�E Database and Archives

�� ASTRO�E Databases

ASTROE GOF will maintain a cluster of the online ASTROE databases to facilitate the GOsupport tasks� By accessing these databases� GOs will be able to browse and obtain ASTROEpublic information and archival data� Figure �� indicates the structure of the ASTROE databasecluster� These databases will be primarily developed at GSFC where the original copies will belocated� The observation database may be primarily maintained at ISAS instead �section ��and other databases may be mirrored to ISAS too�

�� Data Access

At HEASARC� astronomical catalogs and archival databases are may be accessed using the �W�Browse�interface� By inputting target names or coordinates on the W�Browse graphical interface� userscan browse the databases and retrieve archival data for the desired targets�

�� 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 andall the accepted proposals are put in the proposal database� The proposal abstracts and otherinformation such as observational modes and constraints will be public for the accepted proposals�The multimission proposal database named ARGUS oversees all the aspects of the proposals andobservations� from their acceptance to the �nal resting place in the public archives� W�Browse canbe also used to browse proposal abstracts and other information� Using ARGUS or W�Browse�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 commandplans�

�� Observation Database

The observation database keeps observation plans and the observation log� This database will berequired both for the satellite operation at ISAS and the GO support at GSFC� hence will belocated at both sites� Identical databases will be maintained at ISAS and GSFC�All the GO observations� IOC observations� TOO observations and calibration observations

�section �� are given unique sequence numbers� and their observation plans such as dates andtime� instrumental modes and pointing directions are put in the observation database� At ISAS� thecommand planning softwares access the observation database to construct observation schedulesand 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

��

�� CHAPTER �� ASTRO�E DATABASE AND ARCHIVES

Gue

st O

bser

vers

RP

Sprop

osal

s acce

pted

prop

osal

s

Obs

erva

tion

Dat

abas

e

Obs

erva

tion

Pla

nsC

omm

and

Pla

nnin

gS

oftw

are

Dat

a

Sat

elli

te

Obs

erva

tion

Log

ISA

S

AR

GU

S

W3b

row

se

Arc

hive

Dat

abas

e

Pro

posa

l Dat

abas

e

proc

esse

dda

ta

HE

ASA

RC

Ast

ro-E

Arc

hive

s

AD

F

Pro

cess

ing

Dat

abas

e

Pip

e-li

ne P

roce

ssin

g

Figure �� Structure of the ASTROE database�


the data processing should be also recorded in the observation database� so that it is readily seen ifthe telemetry data are received and archived at ISAS� gone through the Stage � and � processing�and shipped to GSFC �section ��

�� Processing Database

At ADF�GSFC� each step of the pipeline processing �section �� from the data reception to theshipment to GOs� is documented and recorded in the processing database� Processing databasetells when and with which processing systems the data are processed� By accessing the processingdatabase� GOs will be able to browse and retrieve their proprietary data through some encryptionprotocol �section �� and anybody can browse and retrieve the public data� Since purpose of theprocessing database is di�erent from other ASTROE databases� the processing database will bedeveloped and maintained by ADF separately from those managed under W�Browse ��gure ��

�� Archive Database

After proprietary period is over� all the ASTROE data will be public �section �� The archivedatabase lists the observation sequences which have been made public� The archive databaseis driven by W�browse and connected to the ASTROE archives� so that users can browse andretrieve contents of the ASTROE archives using the W�Browse interface�

�� Product Database

There will be a separate database for the scienti�c products created in the pipeline processing�Images� light curves and spectra of the sources of all the instruments will be generated �section�� This database will be particularly useful to crosscorrelate the sources detected with ASTROE and the sources listed in other catalogs or detected by other missions� For example� it will bepossible to check if sources in the ROSAT All Sky Survey catalog are detected with ASTROE andto obtain their energy spectra and light curves� The product database is connected to the productarchives �section �� so that products can be retrieved through the W�Browse interface�

�� ASTRO�E Archives

�� Policy and Responsibilities

It is agreed that all the ASTROE data taken by XRS� XIS and HXD �including the TPU gammaray burst data� section �� and �� should be made public after the proprietary periods�

The High Energy Astrophysics Science Archive Research Center� HEASARC� which belongsto OGIP supports multimission Xray and gammaray archival research� The ASTROE GOF�in cooperation with ADF� is responsible for creating the ASTROE archives and delivering it tothe HEASARC� The HEASARC will then maintain the archives� while the ASTROE GOF willsupport archival research while the mission is still alive� At the end of the mission� the HEASARCtakes over the archival user support responsibility�

�� Contents

The outputs of the pipeline processing are immediately copied to the HEASARC as well as sentto GOs and kept encrypted until the end of the proprietary periods� when the data are decrypted�section ��

The products produced in the pipeline processing will be put in subdirectories of each observation sequence� In addition� there will be a separate product archives for the catalogs as well asspectra and light curves of each source�

�� CHAPTER �� ASTRO�E DATABASE AND ARCHIVES

�� Archival Access

The ASTROE 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 anyuser 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 userswill access the archives through the W�Browse interface by inputting source names or coordinates�section ��

Appendix A

Acronym

Acronyms often used in the AstroE project are summarized with their fullnames and relateditems�

Acronym Full Name Related Item

ACHE ADR Control and Housekeeping Electronics XRSACM AccelometerAOCS Attitude and Orbit Control SystemACU Analogue Control Unit HXDADF Astrophysics Data Facility GSFCADR Adiabatic Demagnetization Refrigerator XRSAE Analogue ElectronicsAO Announcement of OpportunitiesAOCU Attitude and Orbit Control UnitAPID Application Process IDASC AXAF Science CenterASM Attached Sync Maker telemetryAXAF The Advance Xray Astrophysics Facility

BAT BatteryBGO Bi�Ge�O�� HXDBCCU Battery Charge Control Unit

CAB Command Answer BackCALDB Calibration DatabaseCAP Calorimeter Analogue Processor XRSCCSDS Consultative Committee for Space Data SystemsCDP Calorimeter Digital Processor XRSCLCW Command Link Control WordCMD Command DecoderCAB Command Answer BackCRC Cyclic Redundancy CodeCTI Charge Transfer Ine�ciency XIS� ASCA SISCTS Calorimeter Thermal Sink XRS

DAL Data Access LayerDE Digital ElectronicsDHU Data Handling UnitDIST Power Distributer

��

�� APPENDIX A� ACRONYM

DMA Direct Memory AccessDMS Dewar Main Shell XRSDP Data ProcessorDR Data RecorderDRV DriveDSN Deep Space Network NASADSP Digital Signal Processor XRSDVD Digital Versatile DiskDWR Dewar XRS

EEPROM Electronically Erasable Programmable ROM XRSEOB Extensible Optical BenchEPTSAESA European Space AgencyETI Extended Time Counter

FDE Filter wheel Driver Electronics XRSFEA Front End Assembly XRSFTP File Transfer ProtocolFITS Flexible Image Transport SystemFOV Field of ViewFW Filter Wheel XRS

GAS Geomagnetic Aspect SensorGCC Gross Cycle Control XRSGO�s� Guest Observer�s�GOF Guest Observers FacilityGSFC Goddard Space Flight CenterGSO Gd�SiO� HXDGTI Good Time IntervalsGUI Graphic User Interface

HPD Harf Power DiameterHCE Heater Control ElectronicsHK HousekeepingHTML Hyper Text Makeup LanguageHTTP Hyper Text Transfer ProtocolHXD Hard Xray Detector

IGPS Ignition Power SystemINS InstrumentSatelliteIOC In Orbit CheckoutIRU Inertial Reference UnitISAS Institute of Space and Astronautical ScienceIVCS Inner Vapor Cooled Shield XRS

KEK Japanese acronym forNational Laboratory for High Energy Physics HXD

KSC Kagoshima Space Center

LHEA Laboratory for High Energy Astrophysics GSFCLSB Least Signi�cant Bit

MIT Massachusetts Institute of Technology

��

MPDU Multiplexing Protocol Data UnitMPU Main Processing Unit XISLSB Most Signi�cant BitMTQ Magnetic TorquerMW Momentum Wheel

NASA National Aeronautics and Space AdministrationNASDA National Space Development Agency of JapanNRA NASA Research AnnouncementNSAS Nonspinning Sun and Aspect Sensor

OG Operational GroupOGIP O�ce of Guest Investigator ProgramsOP Operational Programs

PCU Power Control UnitPGP Pretty Good PrivacyPSF Point Spread FunctionPHA Pulse Height AnalyzerPI Pulse InvariancePI Principle InvestigatorPIM Peripheral Interface ModulePIMMS Portable� Interactive� MultiMission SimulatorPPU Pixel Processing UnitPSD Pulse Shape Discriminator HXDPSU Power Supply UnitPV Performance Veri�cation

RAM Random Access MemoryRCS Reaction Control SystemRDD Residuals of Dark Distribution ASCA SISRIKEN Japanese acronym for

Institute of Physics and Chemical ResearchROM Read Only MemoryRPS Remote Proposal Submission systemRPT Raw Packet Telemetry

SANT Sband AntennaSAP Solar Array PaddleSBR Sband ReceiverSBCNSDIP Sband DuplexerSHNT Shunt DissipaterSHYBSI Scienti�c InstrumentsSIB Satellite Information BaseSSW Sband SwitchSTT Star TrackerSWG Science Working Group

TAKO Timeline Assembler� Keyword Oriented AstroE planningTBD To Be DeterminedTCE TEC Control Electronics XISTCI Telemetry Command Interface

�� APPENDIX A� ACRONYM

TEC Thermal Electric Cooler XISTI Time CounterTMS Sband TransmitterTMX Xband TransmitterTOO Target Of OpportunitiesTPU Transient Processing Unit HXD

VCS Vapor Cooled Shields XRSVCDU Virtual Channel Data Unit

WCS World Coordinate SystemWDNWPU Well Processing Unit HXDWWW World Wide Web

XANT Xband AntennaXHYBXIS XRay Imaging SpectrometerXPA Xband Power Ampli�erXRS XRay SpectrometerXRT XRay Telescope

Appendix B

De�nition of the CoordinateSystem used for ASTRO�E

B�� De�nition of the Coordinates

The following coordinates are de�ned to describe event locations in the telemetry� on the detector�or on the sky� All the coordinates are written in the ASTROE event �les�

� RAW coordinates�Original digitized values in the telemetry to identify pixels of the events� May not re�ectphysical locations of the pixels on the sensor� For example� XIS RAW X and Y coordinateswill have values from � to �� on each Segment�� For XRS� the pixel ID� from � to �� willrepresent the RAW coordinates�

� ACT coordinates�ACT is de�ned only for XIS� The ACT X and Y values are de�ned to represent actual pixellocations in the CCD chips� ACT XY will take � to �� to denote the �� pixelsin the chip� The XIS RAW to ACT conversion depends on the observation modes �such asWindow Options� and will require housekeeping information�The XIS ACT coordinates isde�ned by lookingdown the sensors�

� DET coordinates�Physical positions of the pixels within each sensor� Misalignments between the sensors arenot taken into account� The DETX�Y coordinates are de�ned by looking up the sensor�such that the satellite �Y direction� becomes the DETY direction �the same as ASCAconvention��

The DET X and Y values take � to �� for XRS� and � to �� for XIS� For XRS� the DETX�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 betweenthe sensors as well as the di�erence of the focal length are taken into account so that the FOCimages of di�erent sensors �both XRS and XIS� can be superposed� FOC is calculated fromDET by linear transformation to represent the instrumental misalignment� i�e�� the o�set andthe rotation angle� and the focal length of the XRT� Information of these misalignment andthe 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�

��

�� APPENDIX B� DEFINITION OF THE COORDINATE SYSTEM USED FOR ASTRO�E

satellite attitude in the attitude �le and the alignment matrix �� written in the teldef �le�For each XIS event� the equatorial coordinates of the pixel center projected on a tangentialplane are given�� For each XRS event� the equatorial coordinates of the pixel center as wellas the roll angle of the pixel are given� The roll angle is necessary since the XRS pixel sizeis �nite�

In this scheme� it is important that the conversion from RAW to DET does not depend onthe misalignments between the sensors� Therefore� DET XY� as well as RAW XY� can be writtenin the event FITS �les without having the calibration information� The DET to FOC conversionrequires information of the focal length and the misalignment between the sensors� The sameroutines�functions can be used for FOC to SKY conversions for di�erent sensors not depending onthe individual characteristics�

B�� Implementation to the FITS Event Files

B�� Names of the Columns

XIS XRS HXDSENSOR SENSOR � SENSORRAW SEGMENT� RAWX� RAWY PIXEL �ACT ACTX� ACTY � �DET DETX� DETY DETX� DETY �FOC FOCX� FOCY FOCX� FOCY �SKY X� Y X� Y� ROLL �

B�� Type and Range of the Columns

XIS

Type Minimum Maximum Origin Size of the PixelSENSOR Integer � � � �SEGMENT Integer � � � �RAWX�Y Integer � �� ACTX�Y Integer � �� mmDETX�Y Integer � �� mmFOCX�Y Integer �� a � �� arcminX�Y Integer �� a � �� 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 pixelsize corresponds to the angular size of a single XIS CCD pixel� To allow rotation of the image andsome shift of the pointing direction during the observation� the XY range is taken slightly biggerthan

p��

�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� iswidely used� and will be adopted for ASTRO�E event les too�

B�� IMPLEMENTATION TO THE FITS EVENT FILES ��

XRS

Type Minimum Maximum Origin Size of the PixelPIXEL Integer � �� DETX�Y Integer � �� mmFOCX�Y Integer � �� a � �� arcminX�Y Integer �� a � �� arcminROLL Real �� b � �

a� Default image region� The X and Y Values can be outside of the region�b� An angle of FOCYaxis from north �usually SKY Yaxis� 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 forthe both sensors for FOCX�Y and X�Y� and the XRS DETXY pixel size is de�ned as �XIS pixelsize� � �XRS focal length� � �XIS focal length��

HXD

Type Minimum Maximum Origin Size of the PixelSENSOR Integer � ��

HXD is not an imaging instrument and will not have coordinate columns� The average pointingdirection may be written in the event FITS �le header�

�� 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 ASTROE ftools�This guideline is particularly aimed for Japanese instrument members who are developing in theANL environment and going to convert ANL modules into ftools�

C�� Items to be Delivered

The delivery to the GSFC ASTROE GOF�ftools team should include the Software and testexample�s��

� Softwares� Source Codes

� Parameter �les �default�

� Make�le

� Documents� in plain ASCII text and IRAF �lro�� format�

� Examples�� Relevant input �les and resulted output �les�

� Test parameter �les or test script�

C�� 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 � andhttp��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 �� only�� For scripts� use Perl �� or Tcl�Tk �� Comply with the standards of ANSI C� ANSI C�� or Fortran �� 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�hfrom CERN�

��

�� APPENDIX C� FTOOL DEVELOPERS GUIDELINE

� For C or FORTRAN ftools� use the cdummyftool and fdummyftool as templates� They canbe 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 hardcoded �scanf� or command line options to read in the parameter in C orFortran codes� Use XPI parameter interface� The routines are documented in p�le�h for theC ftools�

� Don�t directly write the message to stdout� use the fcecho or fcerr routines in cftools and xpilibrary� 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 shoulduse 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 Fits�le� use c�tsio� 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 �tsioroutines� which are the wrapped c�tsio routines�

� Before calling the c�tsio routine� make sure the error status is set to zero� otherwise� theroutine returns immediately�

� After calling the c�tsio 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 abilitiesof c�tsio 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�� Parameters

It is well documented in URL� http��heasarc�gsfc�nasa�gov�ftools�others�p�les�html

C�� Make�les

We use �hmake�� which is the �make� utility developed locally for the HEASARC software� Wedon�t required developer to write the �hmake� style make �le� However� we do appreciate thedeveloper to provide a make�le 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�� Documents

The help �le should be provided in a plain ASCII text �le with the extension �txt� and a �lewith the IRAF �lro�� format and extension �hlp� The �lro�� format is quite similar to the UNIXnro��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�� DOCUMENTS ��

� 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 email address for questions and bug reports �It is usuallyftoolshelp"olegacy�gsfc�nasa�gov or the help desk of the mission��

�� APPENDIX C� FTOOL DEVELOPERS GUIDELINE

Appendix D

Important Internet Addresses

D�� HTTP addresses

AstroE GOF at NASA�GSFC�http��heasarc�gsfc�nasa�gov�docs�astroe�astroegof�html

ISAS Xray Astronomy Group�http��www�astro�isas�ac�jp�xray�mission�astroe�astroeE�html

ADF at GSFC�http��hypatia�gsfc�nasa�gov�adf�adf�html

AstroE 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��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�

W�Browse page�http��heasarc�gsfc�nasa�gov�WBrowse�

Skyview page�http��skyview�gsfc�nasa�gov�skyview�html

��

�� APPENDIX D� IMPORTANT INTERNET ADDRESSES

D�� FTP addresses

Anonymous FTP address at NASA�GSFC�ftp��legacy�gsfc�nasa�gov

D�� E�mail addresses

AstroE online help desk � astroehelp�athena�gsfc�nasa�gov

Index

�st Stage Software �� mode ��nd Stage Softwares �� mode �� mode �ACHE ��Active pixels ��ADF �Astrophysics Data Facility� ��Adjacent Pixels �adjusted derivative ��ADR ��Analog Control Unit �ACU� �anti coincidence ��anticoincidence detector �XRS� ��AO �Announce of Opportunities� ��APID �Application Process ID� ��ARF �Ancillary Response File� ��ARF �Ancillary Response Files� ��ARGUS ��ASCII �ASTROE archives �ASTROE GOF �ASTROE Newsletter ��ASTROE simulator ��ASTROE time ��ASTROE Users Group ��Attached Sync Maker �ASM� ��Attitude and Orbit Control System �AOCS�

��Barycentric correction ��basic calibration �les � BGO �Blocking Filters ��Burst option �byte compression �C�� Calibration Database �CALDB� � calibration product �les � Calorimeter Digital Processor �CDP� ��Calorimeter Thermal Sink �CTS� ��capacity � of the DR ��CCSDS packets ��CCSDS ��CDROM �clean hit events ��

cleansis ��Clock modes �Command Decoder ��Command Link Control Work �CLCW� ��Copied pixels ��CRC ��cryogenics ��cuto� rigidity ��Cyclic Redundancy Code �CRC� ��Dark Frame mode ��Dark Initial mode ��Dark Level RAM �Dark Levels ��Dark Update mode ��DARTS system �Data Access Layer �DAL� ��Data Dump ��Data Handling Unit ��Data Processor �DP� ��data rate ��Data Recorder �DR� ��Data Recorder ��Deltat cut ��detector simulators ��Dewar Main Shell �DMS� ��DHU ��Digital Signal Processor �DSP� ��downlink ��dp�� DSN �Deep Space Network� ��DVD �Digital Versatile Disk� �� echo ��Editing modes �e�ective area ��ESA �European Space Agency� ��Euler angles ��Event Lower Threshold �Event Upper Threshold �Exposure Area ��exposure map ��Extended HK �EHK� �les ��Extended Time counter �ETI� ��Extensible Optical Bench ��Filter �le ��Filter Wheel Drive Electronics �FDE� ��

��

�� INDEX

Filter Wheel ��First FITS Files �� First Stage Software ��FITS �Flexible Image Transport System� ��tsio ��ookup ��Fortran�� Fortran�� Frame mode ��Frame Store Area ��fselect ��FTOOLS �g�� gammaray bursts �gcc �gisclean ��Good Time Intervals �GTI� ��Grade �XIS events� �Grade Gross Cycle Control �GCC� ��GSO �HOverClocked pixels ��HEASARC �High Energy Astrophysics Sci

ence Archive Research Center� ��HgTe ��Hires event ��Histogram packets �hot pixel threshold ��hot pixels ��Hotpixel RAM �Hu�man table ��HXDPIN ��In Orbit Checkout �IOC� phase ��Inner Split Threshold ��Inner Vapor Cooled Shield �IVCS� ��KSC �Kagoshima Space Center� ��ksh ��leap second ��Lowres event ��Lumirror ��Main Processing Unit �MPU� ��maketime ��MAKI ��Midres event ��mk�st�ts ��mkcom�st�ts ��mkhxd�st�ts ��mkphlist ��mkxis�st�ts ��mkxrs�st�ts ��MPDU ��NASA Research Announcement �NRA� �NASDA �National Space Development Agency

of Japan� �

NASDA ��NRA �NASA Research Announcement� ��Observatory Time �OGIP �Optical Blocking Filter �OBF� ��optimal �lter ��optimal pulse height ��Outer Split Threshold ��Outermost Pixels �Peripheral Interface Module ��Perl ��PGP encryption �� PH �Pulseheight History� ��PHA ��PI �Pulse Invariance� ��PI Program ��PIMMS �Portable� Interactive� MultiMission

Simulator� ��PIN diodes �pipeline processing ��Pixel Processing Unit �PPU� ��Pixel RAM ��PI ��point spread functions ��Power Control Unit ��primary calibration �les � Principle Investigator �PI� �Pseudo events ��Pulse Shape Discriminater �PSD� ��qparameters ��Raw Packet Telemetry �RPT� �les ��raytracing package ��RDD �Residual Darkcurrent Distribution� ��response generators ��RMF �Redistribution Matrix Files ��RMF �Redistribution Matrix File ��RPS �Remote Proposal submission System�

��RPT �Raw Packet Telemetry� �RPT �les �Raw Packet Telemetry �les� ��Sband ��Satellite Information Base �SIB� ��Science Working Group �SWG� ��SIRIUS database �� SIRIUS ��South Atlantic Anomaly �SAA� ��South Atlantic Anomaly ��Split Threshold ��subinstruments ��TAKO �Timeline Assembler� Keyword Ori

ented� ��TCE �TEC Control Electronics� ��Tcl�Tk TEC �Thermal Electric Cooler ��

INDEX ��

teldef �les � telemetry limit �XRS� ��telemetry rate ��TH �Time History� ��Thermal Shield ��Time Counter �TI� ��timeconv ��Timing mode �TPU �Transient Processing Units� �Transient Data ��Transient Processing Units �TPU� �Unscreened event �les ��VCDU packet ��VCID ��vignetting map ��Virtual Channel Data Unit �VCDU� ��W�Browse ��WebSpec ��Well Processing Units �WPU� �Window option �Xband ��XRS pixel map ��xrssim ��XRS ��XSPEC ��

�� INDEX

Bibliography

�� The Scienti�c Satellite AstroE Interim Report� ��Kagaku Eisei AstroE ChuukanHoukokusho�� ISAS� �� in Japanese

�� Serlemitsos� P� J� et al� �� PASJ� � ��

�� Serlemitsos� P� J� and Soong� Y� �� Astrophys� Sp� Sci��

�� Serlemitsos� P� J� �� The Next Generation of Xray Observatories�� p� ��

�� Kamae� T� et al� �� SPIE� vol� ��

� � Takahashi� T� et al� �� A!A� ��

�� Mukai� K� �� in Legacy� p� �� http��heasarc�gsfc�nasa�gov�docs�journal�ogip fortran�html �

��