validation of on-board algorithms for svom satellite payload management1191455/... ·...

Validation of on-board algorithms for SVOM satellitepayload management

CNES (Centre National d’Etudes Spatiales)Toulouse, France

NACER NACIRI

Master of Science Thesis

Particle and Astroparticle PhysicsSchool of Engineering Science

KTH Royal Institute of Technology

Stockholm, Sweden

March 2018

Examiner: Pr. Torbjorn Back

Abstract

SVOM (Space-based multiband astronomical Variable Objects Monitor) is an astrophysicssatellite that is developed by both the French space agency CNES and the Chinese space agencyCNSA. Its purpose is to detect and observe Gamma-Ray bursts, some of the most powerfulsingular events in the universe which are thought to be linked to the formation of black holesor when neutron stars collide. To do so, SVOM has four on-board instruments (two of themare under French responsibility while the other two are under Chinese responsibility) on top ofseveral telescopes on ground which are used to detect the bursts and observe them, bursts whichseem to happen randomly. The on-board instruments generate a wide-range of data which hasto be transmitted to the ground. That is done using a VHF link which sends the messages toa network of ground stations. During my internship in CNES, I worked on two parts of thesatellite: the MXT instrument and the VHF link.

The MXT instrument has a complex on-board algorithm with many working modes andtransitions between these modes depending on the commands that MXT receives. Since MXT’son-board algorithm is still in the definition phase, I developed a simulator on Scilab to simulatethe mode transitions in order to help validate the algorithm and make sure that it works asexpected. While working on the simulator, it turned out that the transitions between the modesweren’t done the right way when a command is received while a transition is being made. Weopted for using additional transition modes which solved the problem and gave a more stableversion of MXT’s algorithm. The simulator could still be used for the project as it has a deeplevel of modelling the way MXT works.

For the second part of the internship, I worked on the VHF link which sends the observeddata to the ground. The ground stations are chosen to maximize the coverage and have an activelink all the time, however the coverage isn’t permanent and there are periods where the satelliteisn’t visible by any ground station and the sent messages are lost. To minimize the loss ofpackets, they are repeated, each differently depending on different parameters. In order to makesure that a good compromise is found between the time all messages are received on ground andthe probability of reception of messages, a simulator was developed on Scilab for the VHF link.My role was to update the simulator as it was developed a few years ago and is no longer up-to-date. Once that was done, I added new functionalities to it such as the reception of packets byeach station and the use of buffers. Finally, I exploited the simulator in order to design some ofthe on-board messages and validate their parameters. For example, I found out that the optimalbuffer size for MXT photon data messages is three, that having an early GRM trigger doesn’tmajorly influence the times of reception of all the messages and that the maximum that couldfit a MXT photon list message is 33 packets. These results are used to design the messages andthe message emission algorithm as they are issued from a simulator that models realisticallythe generation of messages by instruments, their management and emission by the on-boardmanagement algorithm and their reception by ground stations.

i

Sammanfattning

SVOM (Space-based multiband astronomical Variable Objects Monitor) ar en astrofysiksatellit som ar utvecklad av bade den franska rymdbyran CNES och den kinesiska rymdbyranCNSA. SVOM upptacker och observerar gammablixtarna som ar de valdsammaste fenomenonvi kanner till i universum och som forekommer i alla riktningar. Gammablixtar anses varakopplade till bildandet av svarta hal eller nar neuronstjarnor kolliderar. SVOM ar gjord av fyrainstrument och flera teleskop pa marken som anvands for att uppfylla satellitens mal. Tva avinstrumenten ar under franska ansvaret och tva ar under kinesiska ansvaret. Instrumenten pasatelliten genererar mycket data som maste overforas till marken. Det gors med en VHF-lanksom skickar meddelanden till en natverk av fyrtio markstationer. Det finns dick manga inbyggdaalgoritme som annu inter har bestamts eftersom satelliten fortfarande ligger i utvecklingsfasen.Till exempel, MXT som ar ett av de inbyggda instrumenten har flera funktionella lagen somberor pa olika parametrar (South East Anomaly, jord ockultation, typ av observation...). Mittarbete bestod i att validera de algoritmer som dikterar laget overgangar for att sakerstallaatt instrumentet fungerar som forvantat under uppdraget. Den andra delen av praktikplatsenbestod i all validera och hjalpa till med designmeddelanden som skickades via VHF-lanker.Faktum ar att nagra av algoritmerna for generering/overforing av meddelanden inte har studeratsfullstandigt och jag anvande en simulator som jag uppdaterade for att designa dessa algoritmeroch validera VHF-overforingarna.

iii

Acknowledgements

I would first like to thank and express my gratitude for my supervisor in CNES Marie-Claire Charmeau for giving me the opportunity to work on this master thesis subject and for herconstant guidance and availability. Working on the subject has helped me gain an insight on thedevelopment process of a satellite which I believe would be most valuable in the future.

I would also like to thank Martin Boutelier the MXT engineer for his help while I wasworking on the MXT part and for being there when I needed explanations, as well as the wholeSVOM team for being as welcoming.

I would as well like to thank my university supervisor Hoi Fung/David Yu and examinersTorbjorn Back adn Felix Ryde for their availability during my thesis and for their help withKTH’s administrative work.

Finally, I would like to thank my parents for being supportive and for giving me theopportunity to reach this level of education.

v

Contents

1 Introduction 11.1 Gamma-ray bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Mission of the SVOM system . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 SVOM payload architecture . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Observing program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.3 Slew maneuvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.4 Orbit parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Context of the internship 92.1 Presentation of CNES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Objective of the internship . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Validation of MXT’s algorithms 113.1 Introduction to MXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Mode diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Telecommands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Development of the MXT simulator . . . . . . . . . . . . . . . . . . . . . . . 183.2.1 Input files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 State variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.3 Output of the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.4 Mode transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 The VHF simulator 284.1 Introduction to the VHF network . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1 Types of VHF messages . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.1.1 Trigger messages: ECLAIRs trigger and GRM trigger . . . . 314.1.1.2 Light Curves: ECLAIRs LC High Priority/Low Priority,

GRM LC High Priority/Low Priority . . . . . . . . . . . . . 314.1.1.3 Attitude chart and finding charts: attitude chart R, finding

chart R, finding chart R, finding chart V, finding chart V+R . 324.1.1.4 MXT position and MXT photon list . . . . . . . . . . . . . . 334.1.1.5 Sub-images: ECLAIRs sub-image, VT sub-image R, VT

sub-image V . . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.1.6 ECLAIRs alert descriptor . . . . . . . . . . . . . . . . . . . 344.1.1.7 MXT photon data and MXT MM photon data . . . . . . . . 344.1.1.8 PDPU messages: GRB PDPU, idle packet . . . . . . . . . . 344.1.1.9 Recurrent messages: ECLAIRs, GRM, MXT, VT and PDPU 34

4.1.2 The existing simulator . . . . . . . . . . . . . . . . . . . . . . . . . . 34

vii

viii CONTENTS

4.2 Updating the VHF simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.1 VHF messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.2 Visibility by ground stations . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.2.1 Simulation of the orbit . . . . . . . . . . . . . . . . . . . . . 394.2.2.2 Visibility of the satellite by a station . . . . . . . . . . . . . 434.2.2.3 Influence of the RAAN on the visibility gap duration . . . . 444.2.2.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.3 Message repetition by PDPU . . . . . . . . . . . . . . . . . . . . . . . 454.2.3.1 The buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.3.2 The repetitions . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Exploiting the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.1 General program results . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.2 MXT photon data with a buffer . . . . . . . . . . . . . . . . . . . . . 50

4.3.2.1 Generation rate of 1 packet every 3 seconds . . . . . . . . . 524.3.2.2 Results for different generation rates . . . . . . . . . . . . . 534.3.2.3 Recurrent messages generated at random times . . . . . . . . 544.3.2.4 Influence of the burst duration of the transmitted photon data

packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3.3 Early GRM trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3.4 ToO-MM; MXT photon list . . . . . . . . . . . . . . . . . . . . . . . 62

5 Conclusions and improvements 665.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Bibliography 68

List of Figures

1.1 Diversity of γ-ray light curves observed by BATSE. [1] . . . . . . . . . . . . . 21.2 Overview of the on-board instruments. . . . . . . . . . . . . . . . . . . . . . . 41.3 Payload data handling architecture . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Slew duration distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 The location of the SAA region at an altitude of around 560km.[2] . . . . . . . 8

2.1 CNES Toulouse Space Centre . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 MXT mode diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Summary of MXT’s mode transitions . . . . . . . . . . . . . . . . . . . . . . 183.3 Architecture of the simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Example of the MXT graphic output . . . . . . . . . . . . . . . . . . . . . . . 213.5 Summary of MXT’s transition modes and their link to TCs . . . . . . . . . . . 22

4.1 Light curves sampling periods (High priority at the top, low priority at the bottom) 324.2 VT refining sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Architecture of the old VHF simulator . . . . . . . . . . . . . . . . . . . . . . 354.4 Visibility gap duration cumulative distribution function - 35 stations network . 364.5 Earth occultation duration cumulative distribution function . . . . . . . . . . . 364.6 Example of the old VHF simulator’s output . . . . . . . . . . . . . . . . . . . 374.7 VHF alert network (40 stations) . . . . . . . . . . . . . . . . . . . . . . . . . 404.8 Satellite orbits - Kepler elements[3] . . . . . . . . . . . . . . . . . . . . . . . 414.9 Angles to describe satellite motion . . . . . . . . . . . . . . . . . . . . . . . . 424.10 Inertial Reference System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.11 ENU frame[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.12 Satellite visibility by ground stations for a RAAN of 0 . . . . . . . . . . . . . 464.13 Plot of the satellite trajectory for a RAAN of 0 . . . . . . . . . . . . . . . . . 474.14 Satellite visibility by ground stations for a RAAN of 120 . . . . . . . . . . . . 484.15 Plot of the satellite trajectory for a RAAN of 120 . . . . . . . . . . . . . . . . 494.16 General sketch of the buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.17 Architecture of the VHF simulator’s final version . . . . . . . . . . . . . . . . 504.18 Architecture of the VHF simulator’s final version . . . . . . . . . . . . . . . . 514.19 No buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.20 Size 2 buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.21 Size 3 buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.22 Number of transmitted packets for different buffer sizes (1 packet every 3s) . . 564.23 Number of transmitted packets for different buffer sizes (1 packet every 2s) . . 574.24 Number of transmitted packets for different buffer sizes (1 packet every second) 574.25 VHF traffic without an early GRM trigger . . . . . . . . . . . . . . . . . . . . 594.26 VHF traffic with an early GRM trigger . . . . . . . . . . . . . . . . . . . . . . 61

ix

x LIST OF FIGURES

4.27 Example of tiles and slew distributions . . . . . . . . . . . . . . . . . . . . . . 624.28 ’Not in SAA not in EO’ duration distribution . . . . . . . . . . . . . . . . . . 634.29 Weekly mean duration of ’not in SAA not in EO’ intervals . . . . . . . . . . . 644.30 ToO-MM simulations with messages overflowing to the next orbit . . . . . . . 65

List of Tables

3.1 Description of the telecommands . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Start of slew events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 End of slew events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Enter SAA events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 Relative importance of the activities . . . . . . . . . . . . . . . . . . . . . . . 203.6 Number of events happening during the same minute . . . . . . . . . . . . . . 233.7 Results of the test cases for the MXT simulator . . . . . . . . . . . . . . . . . 24

4.1 Types of VHF messages, with priority and number of packets . . . . . . . . . . 294.2 Types of VHF messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Comparison of the VHF messages . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Target orbit parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5 Influence of the RAAN on the maximum gap duration . . . . . . . . . . . . . . 454.6 Types of messages sent in the nominal case . . . . . . . . . . . . . . . . . . . 514.7 Influence of the buffer size on the number of transmitted PD packets for

different generation rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.8 Influence of the buffer size on the number of transmitted PD packets for

different generation rates (random generation times for recurrent messages). . . 554.9 Types of VHF messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

xi

List of Abbreviations

For clarity, we summarize some of the terms and what they stand for before presenting them inthe next sections.

GRB Gamma-Ray Burst

SVOM Space-based multiband astronomical Variable Objects Monitor

MXT Micro-Channel X-ray Telescope

GRM Gamma-Ray Monitor

VT Visible Telescope

PDPU Payload Data Processing Unit

MDPU MXT Data Processing Unit

FOV Field Of View

SAA South Atlantic Anomaly

EO Earth Occultation

ToO-MM Target of Opportunity - Multi Messenger

xii

Chapter 1

Introduction

This report aims at presenting the work that I have done during my internship at CNES(Centre National d’Etudes Spatiales) in Toulouse, France for six months from late September2017 to mid-March 2018. The internship was done at the command/control department on theSVOM satellite project. It deals with the validation of algorithms for the payload managementof the SVOM satellite. SVOM (Space Variable multi-band astronomical Variable Objects) is anastrophysics satellite which aims at detecting and observing gamma-ray bursts in the Universe.

1.1 Gamma-ray burstsGamma-ray bursts (GRB) are known to be the most luminous explosions in the

Universe, their origin and mechanism being the focus of intense research and debate. Theyare extremely powerful, radiating a power that is equivalent to more than billions of billions ofsuns. Because of this, they outshine every gamma-ray source in the source, even though theyare at distances comparable to the most distant galaxies and quasars known in the Universe.

The bursts are referred to as gamma-ray bursts because of the high energy gamma particleswhich are released in a burst. They are the most energetic particles in the electromagneticspectrum. While a photon from visible light might have an energy of around 2 electron-volts, gamma-ray photons have energies on the order of magnitude of billions of electron-volts. Gamma-ray bursts consist of short flashes of gamma-ray photons coming from randomdirections of the sky, with durations ranging from 10−3s to about 103s.

The explosion at the origin of these bursts results in a catastrophic energy release in stellarmass objects which leads to two scenarios to explain the power of the γ-ray bursts: they couldbe caused by the fusion of compact objects (neutron stars or black holes) or by the collapse ofa very massive star (hypernova or collapsar). The majority of the γ-ray bursts collected to thisday indicate that they are produced when a very massive star dies, as a dying star needs to bevery massive in order to generate the necessary energy to eject matter at a very high speed. Thisejected matter will then transform the energy to γ-rays while spreading in space. In both cases,the formed residue (probably a black hole) will become bigger when capturing its neighbouringmatter and will result in the formation of an accretion disk rotating at a high speed. Part of thematter is ejected in the form of two opposing jets in the rotation axis of the disk. This ejectionis the one responsible for the apparition of the γ-ray bursts. The afterglow, also referred to asresidual emission, is then generated from the jets according to the fireball model and is emittedin all the wavelengths. The afterglow, being less quick than the initial burst, could then beobserved in different wavelengths using telescopes which would lead to information on the jetthat generated it and therefore a better understanding of the whole phenomenon.

1

2 CHAPTER 1. INTRODUCTION

Figure 1.1: Diversity of γ-ray light curves observed by BATSE. [1]

There are two types of bursts that have been identified: short bursts and long bursts. When aburst has a duration less than two seconds, it is referred to as a short burst. The current theoriessuggest that these bursts are a result of the fusion of compact objects. When the burst’s durationis over two seconds, they are referred to as long bursts. They are thought to be the consequenceof the collapse of a very massive star. Because of these two types of GRBs, the γ-ray lightcurves range from smooth, fast-rise and quasi-exponential decay, through curves with severalpeaks, to highly variable curves with many peaks. The GRB prompt emission is followed by amuch fainter afterglow, which can be detected in X-ray, visible, infrared or radio wavelengths.

BATSE (Burst And Transient Source Experiment) [1], whose objective was to study thephenomenon of γ-ray bursts, was a high energy astrophysics experiment in orbit around Earthon NASA’s Compton Gamma-Ray Observatory. During its operation, BATSE recorded around2700 γ-ray bursts. Figure 1.1 shows γ-ray light curves for 12 different bursts recorded byBATSE. We can notice how different and diverse all of the light curves are. Among the collecteddata by BATSE, 30% of the bursts were found to be short bursts while 70% were long bursts.

1.2. MISSION OF THE SVOM SYSTEM 3

1.2 Mission of the SVOM system

Gamma ray bursts are a great tool for probing the Universe at very distant times andstudy physics in very extreme conditions. Because the phenomenon is volatile and because itneeds to be observed in the largest possible spectral band, special means are needed. However,since gamma-rays are filtered by the atmosphere, one has to get out of the Earth in order toobserve gamma-ray bursts. That is where satellites come in handy. SVOM, acronym for Space-based multi-band astronomical Variable Objects Monitor, is a Sino-French mission dedicatedto the detection, localization and study of Gamma-ray bursts and other high-energy transientphenomena (X-ray bursts, soft gamma repeaters, Active Galactic Nuclei (AGN), novae...).

SVOM has a wide range of instruments, be it on-board or on the ground, which are sensitiveto the whole range from gamma-rays to infrared. The use of instruments that allow observationsto be made for the whole spectrum from gamma-rays to infrared is unique and will allow adetailed study of gamma-ray bursts, from the prompt emission to the residual emission. Becauseit is dedicated to the study of GRBs, SVOM will offer the possibility to detect the promptemission which lasts only a few seconds at most and needs the instruments to be very responsiveto point at the right region of the sky and start the observations.

Gamma-ray bursts are intense flushes of gamma photons that are suddenly emitted by aregion of the sky. They were discovered in the end of the sixties by american satellites whichwere used to monitor nuclear tests. The bursts are still a big mystery today that intrigues thescientific community. The observations made in the last few years have demonstrated that thegamma-ray bursts are the most energetic events in the Universe (after the Big Bang). Since theycome from the most distant places in the Universe, they allow for a study of the formation ofstars and galaxies during the early ages of the Universe. For example, a burst that was detectedon April 23rd 2009 was found to be emitted when the universe was only 600 million years old.Our galaxy didn’t even exist at that time and yet we were able to observe the phenomenon sincethe light took 13 billion years to reach us. Therefore, studying these bursts would allow us toobserve signals from the Universe’s early years that took billions of years to reach us.

Thanks to the fact that SVOM will make observations in multiple wavelengths and will beable to detect most types of GRBs, it will contribute uniquely to two of the most fuitful researchareas that emerged from the recent discoveries on gamma-ray bursts: the understanding of theGRBs, and how to use GRBs in cosmology. When it comes to understanding gamma-ray bursts,SVOM will help explore the different types of GRBs and their nature. It will also help studythe relation between the prompt emission and the residual emission which will contribute to abetter understanding of the relation between the bursts and the phenomena at their origin suchas supernovae. Further than that, SVOM would allow to study the physics between relativisticejections that are found in various astrophysic phenomena such as the active galaxy cores or themicroquasars. Hopefully, the data could be used to understand the nature of the stars that leadto gamma-ray bursts which would help in figuring out how to use GRBs in cosmology. Indeed,studying the GRBs would allow us to study the first generation of stars (population III stars)which have not yet been observed directly, starts which have formed when the universe was lessthan 500 million years old. Understanding the phenomenon around GRBs would allow for abetter understanding of the Universe and its composition during the its early years.

The Universe is made of hundreds of billions of celestial bodies, some of them beingqualified as static objects while others are transient. Static objects are objects which changevery slowly with time to the point where they appear the same to us on Earth. That is the casefor example for the Andromeda galaxy, the closest galaxy to Earth, which has not changed shapefor decades since its detection on 964. Transient objects are different since they change over


time. They appear for a certain amount of time and disappear, never to be observed again. Theirchanges could be a variation in their luminosity or their observed position and can be caused bymovement or by transformation of the source itself. The time scales of transient phenomena arediverse, ranging from seconds to days. Gamma-ray bursts belong to these transient phenomenabut there are many others, such as supernovae, eruptive stars or active galactic nuclei.

Thanks to the instruments being able to make detections in the whole electromagneticspectrum, SVOM will also be used for scientific observations outside of the GRBs. As theGRBs aren’t expected to occupy the whole mission time, research teams from all around theworld coud make use of SVOM’s technology to observe transient cosmic phenomena. TheSVOM mission may react to alerts generated by transient sky observatories, on the ground orin space. SVOM will thus be a partner of choice for other observational programs, such asIceCube and its neutrino telescope, LIGO and Virgo for the detection of gravitational waves,LSST and SKA for transient sky in the visible and radio range.

In order to fulfill these objectives, the system is based on an instrumental setup of fourinstruments on-board of the satellite and three instruments on the ground. Fast communicationbetween the satellite and the ground is ensured by an on-board VHF emitter and a dedicatednetwork of ground receivers. The ground instruments include two 1m Ground Follow-upTelescopes (GFTs) evenly distributed and GWAC (Ground Wide Angle Cameras). The on-board instruments include ECLAIRs, a low energy γ-ray imager and spectrometer, GRM, aγ-ray spectrometer, MXT, a low-energy X-ray telescope, and VT, an optical telescope.

Figure 1.2: Overview of the on-board instruments.


1.2.1 SVOM payload architectureSVOM has four on-board instruments which are used to detect and observe GRBs

as well as other phenomena that could be interesting. The French and Chinese Payloads arecomposed of the ECLAIRs instrument, MXT instrument, VT instrument, GRM instrument,PDPU electronic units, VHF subsystem and X-band subsystem. ECLAIRs, MXT, VT andGRM are connected to the PDPU which is the data processing unit that controls all payloadinstruments. Some of the instruments are used for detection of GRBs while others are used forcollecting data about the GRBs or detecting events that could damage the rest of the instruments.

Figure 1.3: Payload data handling architecture

• ECLAIRsECLAIRs is an instrument which has a large field of view (FOV) that can detect GRBs inthe hard X-ray energy band. It is used for GRB trigger and localization and can localizeGRBs with a position accuracy better than 13 arcmin in J2000. That position is then sentto the other instruments in order for them to point to the GRB.ECLAIRs is under French responsibility.

• GRMGRM (Gamma Ray Monitor) is an instrument dedicated to the measurement of gamma-ray in high energy band, up to a threshold of 5 MeV. It consists of three detectors, oneCharged Particle Monitor and correlative electronics. The CPM sends an alert when thesatellite passes an area with a big gathering of particles, such as in SAA (South Atlantic


Anomaly). The alert can then inform the science instruments in order to enter specificprotection and data management configurations.GRM is under Chinese responsibility.

• MXTMXT (Micro-Channel X-ray Telescope) is an instrument dedicated to GRB follow-upobservation. Having a small FOV, it can provide, after satellite pointing toward the GRB,a localization better than 2 arcmin in J2000. It uses the position given by ECLAIRs topoint towards the GRB.MXT is under French responsibility.

• VTVT (Visible Telescope) is an instrument dedicated to GRB follow-up observation onboard. It is composed of a mechanical part, two camera heads and electronics for thermalcontrol function. It has a very small FOV which means that it needs satellite re-pointingin order to locate the GRB in its FOV.MXT is under Chinese responsibility.

1.2.2 Observing programSince GRB detection isn’t expected to occupy all of SVOM’s observing time, non-

GRB measurements could be done thanks to the broad wavelength coverage of the on-board instruments and their good sensitivity. Examples of non-GRB science could be earthenvironment studies, supernovae and galaxy observation, X-ray survey... The only constraintshould be that these observations must not influence the GRB observations which are the maingoal of the mission. The observing program of SVOM can be divided as follows:

• Instrument calibrations: to be regularly performed through the course of the mission,

• Core Program: the fraction of the total observing time available for science allocatedto the observations of celestial fields where GRBs have been detected and localized byECLAIRs,

• Targets of Oppotunity (ToO): the fraction of the total observing time available forscientific events that cannot be foreseen and whose scientific importance warrantsimmediate alteration of the observing baseline,

• General Program: the fraction of the total observing time available for science whichis allocated to the observations of targets proposed by the SVOM joint Science WorkingGroup.

1.2.3 Slew maneuversWhen a GRB is detected by ECLAIRs or GRM, the spacecraft performs a slew in order

to place the GRB within the fields of view of MXT and VT to refine the GRB position and studyits emissions.

A slew is performed whenever a new observation needs to be made. Since the slew dependson the current pointing of the satellite and the position of the observation source, its durationis variable. In order to get an idea of the distribution of the slew duration, I performed an


Figure 1.4: Slew duration distribution

analysis of scenario files which were generated using the SVOM mission simulator (these filesare introduced in more detail in section 3.2.1).

Figure 1.4 shows the slew duration distribution for simulations run over a year. Themaximum duration for a slew was 8 minutes with a mean duration of 2.83 minutes.

1.2.4 Orbit parameters

The satellite will be placed on an orbit with a 600km altitude and an inclination angleof 29°. Its period will be around 5800s (a bit over an hour an a half).The satellite is expected to have a minimum operational phase of 2.8 years with a goal of 5years. Because of the regulations concerning space debris, the satellite should be disposed of atmost 25 years after its operational lifetime.In order to optimize burst detection, localization and afterglow observation, an attitude lawneeds to be defined so that, when no observations are made, the satellite points at a region ofspace with the highest probability of burst detection. The satellite’s reference pointing is inertialand a study has been made to derive the attitude law that needs to be applied. That law is calledB1.Because of the orbit of the satellite and its position with relation to the Earth, the satellite willregularly pass over an area on Earth know as SAA (South Atlantic Anomaly). The area is wherethe Earth’s inner Van Allen radiation belt comes closest to the Earth’s surface, which leads to ahigh radiation due to the very weak local geomagnetic field and, consequently, it represents thefavorite entrance of high-energy particles in the magnetosphere.

The high density of particles in this region can damage the on-board instruments as theyare very sensitive. The instruments must therefore be protected from the radiation. The SAAregion’s location and extend can be computed using models of the magnetosphere, the VanAllen radiation belt, etc... and as a result, a possible solution could be for the satellite to be


Figure 1.5: The location of the SAA region at an altitude of around 560km.[2]

programmed to shut the instruments down when the region is reached.

Chapter 2

Context of the internship

2.1 Presentation of CNESThe French Space Agency, CNES (Centre National d’Etudes Spatiales), is an agency

for space programmes mastering a full range of space techniques. It was founded in 1961 andis under the joint authority of the Ministry of Higher Education, Research and Innovation andthe Ministry of the Armed Forces. CNES is responsible for proposing France’s space policyto the Government, and implementing it within Europe. It does that through 5 major areas ofintervention: Ariane, Science, Observation, Telecommunications and Defence.

Figure 2.1: CNES Toulouse Space Centre

CNES has over 2400 employees working in four different centres: PARIS Les Halles, theheadquarters where the administrative departments are centralized; PARIS Daumesnil, whichhandles everything related to the study, design and development of launch systems; French

9

10 CHAPTER 2. CONTEXT OF THE INTERNSHIP

Guiana, which is Europe’s spaceport where the satellites are launched; and Toulouse wheretake place the study, design, development and control of orbital systems, and computing anddate exploitation.My work for the internship has been done in the Toulouse Space Centre and the project ispart of the ”Science” area of intervention. The internship took place in the command/controldepartment in the Architecture, Validation and Integration sub-directory, under the orbitalsystems direction.

2.2 Objective of the internshipFor the duration of my internship, I was integrated to the SVOM project team. My maininteractions were with my tutor, who is a command/control engineer, and the engineer in chargeof MXT.During the six months I have spent in CNES, I worked on two parts of the SVOM satellite:

• For the first part of the internship, I worked on the validation of the algorithms that areused for the MXT instrument (hence my interactions with the MXT engineer). As Iwill explain later, the logic behind the management of the different modes of MXT isquite complex, and therefore, in order to validate it functionally, I developed a dedicatedsimulator in Scilab. The simulator is then used for test scenarios to validate MXT’s on-board algorithms.

• In the second part of the internship, I worked mainly on a simulator that has beendeveloped for the VHF link between the satellite and the ground stations. The simulatorwas developed a few years ago, but different changes in the architecture of the VHF linkhave occurred and I had as a mission to update it and add new functionalites to it, as wellas exploit the new simulator.

Although I talk about two chronological parts of the internship, I didn’t work on themseparately. A lot of the work on the MXT part was done during the first months of the internship,while a lot of the work on the VHF part was done during the last months of it. However, whileworking on one of them, I would work on the other one as well, but I wouldn’t allow it as muchtime, depending on the needs of my tutor and the project.

In the following chapters, I will explain in more detail how both MXT and the VHF linkwork and I will proceed to present the work I have done for both parts.

Chapter 3

Validation of MXT’s algorithms

As said earlier, the SVOM french payload consists of two of the four instruments: ECLAIRsand MXT. My focus was on the MXT instrument (Micro-channel X-ray Telescope) which isan instrument dedicated to GRB follow-up observation in soft X-ray band. Since it has a smallfield of view, it can provide a localization better than a few arcseconds.

MXT’s algorithm is quite complex as it has many working modes and transitions betweenthese modes which are triggered by commands that the instruments receives. Each workingmode corresponds to a different configuration of MXT and each configuration is dedicated to acertain scenario. If MXT ends up with a configuration that is intended for a different scenario,it could be damaged. Therefore, one has to make sure that the algorithm works according toexpectations in order to guarantee the instrument’s safety.

For the moment, the instrument’s algorithm is still in the definition phase which means thatit’s not yet stable and that a lot of changes are being made to it in order to make it fulfillthe requirements. In order to ensure that the algorithm works as expected in the differentcases, simulations are used by implementing MXT’s algorithm on Scilab and checking thatthe transitions are well made. My work consisted in developing the simulator and using it tovalidate MXT’s algorithm. Using the simulator is important as it helps having a stable versionof the algorithm and is more reliable, as long as it implements the algorithm realistically, thanchecking test cases manually and helps see how changes influence the whole performance ofthe instrument.

3.1 Introduction to MXTMXT has multiple functions which could be split into two categories: main functions andadditional functions. The main functions of MXT are identified from the main requirementsand are as follows:

• F1. Interception of the incident photons in the desired filed of view

• F2. Detection of the associated photons in the range 0.2 keV - 10keV

• F3. Elimination of photons and charged particles coming from directions out of the fieldof view

• F4. Digitalization of the photon characteristics and timing of the photon detection event

• F5. Determination of the source direction

11

12 CHAPTER 3. VALIDATION OF MXT’S ALGORITHMS

• F6. Transfer of alert and science data to the satellite for transmission to ground

In addition to that, there are additional functions which are needed to tune the instrumentand ensure detection performance:

• Camera calibration

• Instrument and detector thermal control

• Camera configuration for specific observation targets

• Camera protection from high energy particles and direct sunlight

MXT detects X-ray and Gamma-Ray photons falling on its detection plane and determinesthe impact position (hit pixel), energy level and reception time of each photon. Since onlyreal photon events are needed for science processing on ground, on-board processing is used todiscriminate real photon events from background noise and particle impacts. Position, energyand time information of photon events combined with satellite attitude are used on ground tocharacterize the photon source and accurately determine its direction.When MXT receives a first slew command for a GRB from PDPU, it starts the transition toGRB localization mode. At the end of the slew, determined by the reception of an end of slewcommand, MXT starts the localization process. From the burst center’s position on detectorplane, MXT computes the burst direction coordinates (angles) in MXT reference frame. Sincethe satellite’s attitude quaternion is broadcasted to MXT every second, it is used, along with abias matrix, to compute the burst direction’s coordinates in the J2000 frame.After a first successful localization, MXT creates and transfers to PDPU a ”MXT position” VHFpacket. The packet contains the alert identifier received in the slew command, the localizationtime, the burst coordinates in MXT reference frame, the burst coordinates in J2000 frame, thesatellite attitude used to compute the burst coordinates, the photon counts, the integration time,the mean energy, and a quality flag. ”MXT position” messages are refreshed every 30 secondsuntil the end of the first orbit following GRB detection, and every 5 minutes during the secondorbit. There are additional VHF messages sent by MXT such as photon lists and recurrentmessages which contain information about the instrument health and current activity. TheseVHF messages will be seen in more detail in the second part of the report.In order to adjust the energy level measurement, a periodic calibration of each pixel of thedetection plane is performed, and bad pixels are detected and deactivated. MXT is verysensitive to particles as well and since the orbit goes above the SAA region, the instrumentshould be protected from the radiation in that region. To do so, MXT is equipped with a wheelwhich closes and opens on command and which could be used to stop the SAA particles fromdamaging the instrument.

3.1.1 Mode diagramIn order to ensure that the whole detection process is done according to plan while avoidingthe SAA region’s particles and performing periodic calibrations, modes were identified andsummed up in the mode diagram in figure 3.1.

As it can be seen from the diagram, each mode corresponds to a certain state of the cameraand a certain position of the wheel. They can also correspond to a different state for the thermalcontrol of the detection plane. Each mode’s purpose and configuration could be summed up asfollows:

3.1. INTRODUCTION TO MXT 13

Figure 3.1: MXT mode diagram

• OFF state: MXT and its sub-systems are powered off. The platform’s thermal controlensures that MXT remains in safe thermal conditions.

• Initialization mode (INIT): this mode is entered by MXT after it is switched on byPDPU. Only the MDPU is powered on. This mode is initialized by a boot software. Inthis mode, it is possible to perform maintenance operations of the on-board applicativesoftware (patch, reload). The communication between PDPU and MXT is active, as wellas MXT’s internal thermal control.

• STAND-BY mode: This fallback mode is accessible from any other mode except fromINIT mode, on reception of an ”emergency command”. This mode puts MXT in a stableand reproductible state. MDPU is on, the camera is off, the shutter is closed and thethermal control of the detection plane is stopped.

• SAA-CONFIGURATION mode (SAA-CONF): This mode protects the focal planeduring the SAA crossing. The detection plane is off and the shutter is closed.

• Operation mode (OPER): this mode is the main observation mode of MXT. In thismode, all of MXT’s observation functions are active. The MXT camera sends sciencedata (photon data) to MDPU. They are processed and formatted into X-band packets byMDPU software. This mode is composed of two sub-modes: GRB-loc submode, whichis entered when receiving a first slew command for a GRB and in which photon data are


used to localize the source, and science sub-mode which is used for observation only. Inthe simulator, I don’t implement these two sub-modes, and only consider the bigger modewhich is OPER. Distinctions are made between different types of targets. The differenttypes of observations are detailed in table 3.5.

• TEST mode: this mode is used to perform health check tests of MXT during AIT process.Since the simulator I developed was supposed to model scenarios representative of themission, I didn’t implement this mode which is only used in the AIT process.

• DARK mode: this mode is used to monitor the detector dark current. The wheel is inthe closed position and the camera acquisition mode is on ”full frame”. Thanks to thisconfiguration, MXT makes sure that the observed pixels correspond to a dark spot andhelps in adjusting the energy level measurement. In this mode, the MDPU computesstatistical information about the pixels such as an offset map, a noise map, a bad pixelmap, a mean dark current and a number of bad pixels.

• Calibration mode (CALIB): this mode is used to acquire a specific detection planegenerated with a calibrated source’s data in order to perform instrument calibration. Theinstrument is pointed towards known regions whose energy levels are known and thetransmitted photon data is compared to the expected data.

• BACKGROUND mode: this mode is used to measure the background noise in the eventacquisition mode with the shutter being closed.

3.1.2 TelecommandsThe modes having been defined, transitions between these modes should be defined as well. Thetransitions are triggered by telecommands (TCs) which are shown in figure 3.1. A telecommandtriggers a transition sequence which changes the instrument’s configuration. This transitionsequence may be configurable and implemented as a TC sequence. Some telecommands areaccepted only in one mode and rejected in the others. A list of the telecommands is summed upin figure 3.1.

The TC STARTAIT telecommand is only used during the AIT (Assembly, Integration andTest) phase and it is therefore not included in the simulator which tries to simulate MXTin its nominal working case in orbit. Apart from slew and emergency telecommands, thesetelecommands are either sent from the ground or used in TC-sequences. Slew telecommandsare generated by PDPU once a burst has been detected, and the emergency TC may also begenerated by PDPU before switching off the payload.

3.1.3 EventsIn order to make the transition sequence behind each TC configurable, events are used. Anevent is raised once a TC is received. Once raised, the event triggers a transition sequence,which changes the instrument’s configuration. The purpose of using events is to make changesin the transition sequence behind the TCs easier. In order to enumerate all the events that areused, let’s look at which TC each event is linked to.

• TC SLEWSTART: This request informs the instrument’s software that a slew is starting.The instrument generates a start of slew event report for the event EV SLEWSTART,


Table 3.1: Description of the telecommands

Name of the telecommand Purpose of the telecommand Reserved for AIT

TC EMERGENCY Emergency transition to stand-by mode

TC SLEWSTART Start of slew

TC SLEWSTOP End of slew

TC INIT2CONF Enter SAA-CONF from INIT mode

TC CONF2ENG Enter ENG-CONF mode from SAA-CONF mode

TC ENG2OPER Enter OPER mode from ENG-CONF

TC STARTDARK Start DARK mode

TC STARTBACKGRD Start BACKGROUND mode

TC STARTCALIB Start CALIBRATION mode

TC STOPCALIB Stop CALIBRATION mode

TC STDBY2INIT Enter INIT mode from STAND-BY mode

TC STOPOPER Stop OPERATION mode

TC ENTERSAA Enter SAA configuration

TC EXITSAA Exit SAA configuration

TC STARTAIT Start AIT TEST mode X

TC SETMXTMODE Set MXT mode

TC CHECKAUTOTR Check Automatic Transition

TC CHGAUTOTRANS Change Automatic Transition rules

which generates one of the following events depending on the mode in which the TC isreceived and on the observation target.

Table 3.2: Start of slew eventsENG CONF OPER CALIB DARK BACKGROUND

GRB/CAT AUTOSLEWS01 AUTOSLEWS05 AUTOSLEWS09 AUTOSLEWS12 AUTOSLEWS14

ToO AUTOSLEWS02 AUTOSLEWS06 AUTOSLEWS10 - AUTOSLEWS15

ToO-MM AUTOSLEWS03 AUTOSLEWS07 AUTOSLEWS11 AUTOSLEWS13 AUTOSLEWS16

Other AUTOSLEWS04 AUTOSLEWS08 - - AUTOSLEWS17

In SAA-CONF mode, no AUTOSLEW event is generated. In INIT mode and STAND-BY mode, the telecommand is rejected.

• TC SLEWSTOP: This request informs the instrument’s software that the slew hasstopped. The instrument generates an end of slew event report for the event EV SLEWSTOP,which generates one of the following events if the TC is received in ENG CONF mode.No event is generated in DARK, CALIB, OPER or BACKGROUND.


Table 3.3: End of slew eventsENG CONF

GRB/CAT AUTOSLEWE01

ToO-MM AUTOSLEWE02

Other AUTOSLEWE03

• TC INIT2CONF: On reception of this TC in INIT mode, the instrument’s softwaregenerates the event EV TRINIT2CONF.

• TC CONF2ENG: On reception of this TC in SAA-CONF mode, the event EV TRCONF2ENGis raised which performs the transition to ENG CONF. If the TC is received in a modeother than SAA-CONF or if the current condition is SAA crossing, it is rejected.

• TC ENG2OPER: On reception of this TC and if the status is out of SAA, a transitionto the OPER mode is performed after generation of the event EV TROPEROPEN,EV TROPERFILT or EV TROPERUNCHGD. If the TC is received in any other modethan ENG CONF or if current condition is occulted field of view or in SAA, it is rejected.

• TC STARTDARK: On reception of this TC in ENG CONF mode and if SAA status isout of SAA, the transition to DARK mode is performed after the generation of the eventEV TRDARK. If the TC is received in any mode other than ENG CONF, or if SAA statusis in SAA, it is rejected.

• TC STARTBACKGRD: On reception of this TC in ENG CONF mode and if SAAstatus is out of SAA, the transition to BACKGROUND is performed after the generationof the event EV TRBACKGRD. If the TC is received in any mode other than ENG CONF,or if SAA status is in SAA, it is rejected.

• TC STARTCALIB: On reception of this TC in ENG CONF mode and if SAA statusis out of SAA, the transition to CALIBRATION is performed after the generation of theevent EV TRNEWCALIB or EV TRRESUMCALIB. The TC is rejected if the currentactivity is a ToO, or if the SAA status is in SAA.

• TC STOPCALIB: On reception of this TC in CALIBRATION mode, the transition toENG CONF mode is performed after the generation of the event EV ENDOFCALIB.The TC is ignored if received in any mode other than CALIBRATION.

• TC STDBY2INIT: On reception of this TC in STAND-BY mode, the transition to INITmode is performed after the generation of the event EV TRSTDBY2INIT. The TC isrejected if received in another mode than STAND-BY.

• TC STOPOPER: On reception of this TC in OPER mode , the transition to ENG CONFis performed after generation of the event EV TROPER2ENG. The TC is ignored ifreceived in any mode other than OPER.

• TC ENTERSAA: On reception of this TC, the software sets the SAA status to inSAA, and generates the event EV SAASTART. Depending on the mode it is received,EV SAASTART generates a different transition event as shown in table 3.4.


Table 3.4: Enter SAA eventsENG CONF CALIB, OPER, BACKGRD, DARK

EV TRENG2CONF EV TRSAACONF

• TC EXITSAA: On reception of this TC, the software sets the SAA status to out of SAAand generates an event EV SAAEXIT. If this request is received in SAA CONF, the eventEV TRAUTOENG is generated to perform the transition to ENG CONF mode.

• TC CHECKAUTOTR: On reception of this TC, the service checks the conditions thatmust be verified to trigger an automatic transition to an observation mode. If they areverified, it generates one of the following events: EV AUTOOPER or EV AUTOCALIB.If they are not verified, no event is generated.

The conditions to generate EV AUTOOPER are the following:-SAA status is out of SAA-Automatic transition to OPER mode is allowed-Slew status is not in slew-MXT field of view is not occulted by the Earth-Current activity is an observation

The conditions to generate EV AUTOCALIB are the following:-SAA status is out of SAA-Automatic transition to CALIB mode is allowed-MXT field of view is occulted by Earth

• TC CHGAUTOTRANS: On reception of this request, the service changes the status ofautomatic transition to OPER mode or automatic transition to CALIB mode according tothe telecommand’s argument values.

On top of these events, there are two events that are used for Earth Occultation (EO):EV OCCULTSTART and EV OCCULTEXIT. Since observations cannot be made while thefield of view is obstructed by the Earth, the time of Earth Occultation could be used to performcalibrations (DARK, BACKGRD, CALIB). To do so, the events are used and they are triggeredby PDPU when entering or exiting EO.

All of these transitions could be summed up in table 3.2 which is easier to read.X refers to an unexpected transitions, N to a TC without an effect, R to a rejected TC and X

to a transition that is allowed.X1, X3 and X4 are rejected if the current condition is IN SAA.X2 is rejected if current condition is an occulted FOV or IN SAA.X5 is rejected if current activity is ToO, if GRB or CAT localization sequence is on-going, or ifin SAA.X8 generates EV AUTOOPER if not in SAA and auto to OPER allowed, not in slew and currentactivity is an observation; or it generates EV AUTOCALIB if not in SAA, auto to CALIBallowed and not in EO.


Figure 3.2: Summary of MXT’s mode transitions

3.2 Development of the MXT simulator

Now that the different modes, telecommands and events have been introduced, let’s look at thepurpose of the simulator and its different functionalities.

The aim of the simulator is to take as an input a list of telecommands and perform the modechanges according to these TCs, and then give as an output the list of visited modes and thedifferent state variables. The architecture of the simulator and the implemented functions areshown in figure 3.3.

The processing of the TCs and generation of the corresponding events is made in thefromXXX functions, XXX being the mode at which the TC is received. These transitionfunctions are triggered at each time step. Different side functions (utilities) are used to verifytransition conditions and to trigger the events. The simulator generates two different outputs:one plot showing the mode evolution over time and one file showing the visited modes as wellas the state variables. As an input, two files issued from simulations performed with the SVOMmission simulator (JSPARE) were used.

3.2.1 Input files

The input files are issued from the SVOM mission simulator and contain an example of realisticmission scenarios over one year. Two files are provided:

3.2. DEVELOPMENT OF THE MXT SIMULATOR 19

Figure 3.3: Architecture of the simulator

• One giving the time, the position, the velocity of the satellite and the SAA status

• The second one giving the time and the satellite attitude with some flags regarding theobservation (earth occultation, satellite availability, manoeuvers...).

The positions and velocities are expressed in the J2000 frame.From the scenario files, only the SAA status, the EO status, the start and end of slew, the

current activity (observation linked to the slew), and the satellite status are extracted. Oncethis data is extracted, it is used to generate TC ENTERSAA and TC EXITSAA using the SAAflag. TC EMERGENCY, TC STDBY2INIT and TC STARTCALIB are generated based on thesatellite status. TC SLEWEND and TC SLEWSTART are generated with the correspondingactivity based on information about the slew. EV OCCULTSTART and EV OCCULTEXIT aregenerated based on the EO flag.Once each TC/event is generated, it is added to a buffer. The size of the buffer depends onhow much of the scenario files is used. In general, I read two orbits in the scenario files andtherefore, the simulation is run over two orbits. At the end of the generation of TCs using thescenario files, some TCs can be added manually in the buffer in order to generate test cases thatare not necessarily included in the scenario files.

3.2.2 State variablesIn order to keep track of different parameters during the simulation and use it for output display,some state variables are used. They are also useful when it comes to condition-verification inthe simulator’s algorithm. The used state variables are:

• Automatic transitions to OPER: check if automatic transitions to OPERATION mode areallowed or not. It is changed when the TC CHGAUTOTRANS telecommand is received.

• Automatic transitions to CALIB: check if the automatic transitions to CALIBRATIONmode are allowed or not. It is changed when the TC CHGAUTOTRANS telecommandis received.


• SAA crossing: check if the satellite is above the SAA region or not. It is changed by theSAA events.

• FOV occultation: Check if the satellite is occulted by the Earth or not. It is changed bythe earth occultation events.

• Slewing: check if the satellite is performing a slew or not. It is changed by the slewevents.

• Current activity: describes what the current activity is. The current activity is changedwhen a slew command is received and if the new activity is more important than thecurrent activity (activities refer to the type of observation target). The relative importanceof activities is defined in table 3.5, 1 being the most important activity, and 4 the leastimportant one.

Table 3.5: Relative importance of the activities

Activity Meaning of the activity Importance of the activity

GRB GRB initial observation 2

CAT Catalog transient event 2

ToO-NOM-GRB Target of opportunity for GRB revisit 3

ToO-NOM-ACAL Target of opportunity for Additional Calibration 3

ToO-NOM-AT Astrophysic target of opportunity 3

ToO-EX Exceptional target of opportunity 1

ToO-MM Multi-messenger target of opportunity 1

GP-PPT General Program observation - preplanned target 4

GP-CAL General Program observation - calibration 4

3.2.3 Output of the simulatorTwo different outputs are generated by the simulator. The first one is a plot that shows themodes and transitions over time, while the second one is a text file which displays different dataat each time step.

• The graphic plot is used to display the modes, the transitions, the SAA, the slew and theearth occultation at each time step. Two different methods have been implemented forthese plots. The first one is much slower as I draw the current mode, the SAA, the slewand earth occultation for each time step once at a time. This method is slow, especiallywhen simulations are run over a relatively long period of time (two orbits) as the plotfunction is called multiple times at each time step. The other function works differentlyand is much quicker. For example, for earth occultation, it stores the index at which weenter the EO and, when it is exited, a line is drawn from the index until the moment EOis exited. Whenever EO is entered, the index is updated. The same is done for the SAA,the slew and the current mode. This function is faster than the first one because the plotfunction is only called when the current mode/SAA/EO/Slew is exited, but it’s trickier to


implement as it can display a false plot in some special cases which would lead to a falseinterpretation of the results.

• The text files are generated to give a better idea of the evolution of different data at eachtime step. It shows, at each time step, the current mode, the earth occultation status,the SAA crossing status, the slewing status, the automatic transitions (both to OPER andCALIB) status, the current activity, and the command that is received.

Figure 3.4: Example of the MXT graphic output

Figure 3.4 shows an example of the graphical display. The transitions that are used areexplained in more detail in section 3.2.4. The slew periods are displayed as green rectangleswhile SAA periods are displayed as red rectangles. The brown lines at the top represent theEarth Occultation.

v

3.2.4 Mode transitionsFor the first version of the simulator that I developed, the transitions were considered to beinstantaneous: as soon as a telecommand is received, the mode is changed according to thattelecommand. That was acceptable for when the simulations had a time step of one minuteas I considered that one minute is enough time for a transition to be made. However, whentransitioning to a time step of one second, I had to take into account the transition time thatit takes to make a transition. By considering an average transition time of five seconds, itturned out that the algorithm wasn’t working as expected for certain cases. For example, ifMXT is in ENG CONF and it receives an emergency telecommand, it will start the transitionto STAND-BY mode. However, if a telecommand to enter SAA CONF is received duringthat transition, the instrument will start a transition to SAA CONF and wouldn’t end up inSTAND-BY which could be dangerous for the instrument. That is due to the fact that, during a


transition, the fallback mode is considered to be the starting mode (ENG CONF in the example)of the transition.

To tackle this issue, a solution was adopted which was to add new transition modes. Sixmodes were added: TR2INIT, TR2CONF, TR2ENG, TR2OPER, TR2CALIB and TR2BACKGRD.Introducing these modes gives control over the way TCs are handled while making a transition.For example, let’s suppose MXT is in the ENG-CONF mode and receives the TC ENTERSAA.Then, the current mode would be TR2CONF instead of staying at ENG-CONF. While makingthe transition, if a TC STARTDARK is received, it won’t have any effect and MXT will stillend up in SAA-CONF which wouldn’t have been the case had we not added the new transitionmodes.

Figure 3.5: Summary of MXT’s transition modes and their link to TCs

Figure 3.5 sums up the different behaviours when a TC is received in each transition mode.X1: If we receive TC STOPOPER in TR2OPER, we execute TC STOPOPER as if we were

in OPER.X2: If we receive TC STOPCALIB in TR2CALIB, we execute TC STOPCALIB as if we werein CALIB.X3: TC EXITSAA if we’re in a transition from SAA CONF to ENG CONF, only change statusof SAA crossing.X5: if the starting mode is ENG CONF, just change the ‘slewing’ status to FALSE. If the endingmode is ENG CONF, trigger the SLEWSTOP event.X6: only change the SAA status to TRUE (in case we’re going to SAA CONF from INIT)

In order to have a better idea about which events happen around the same time and identifytest scenarios, I analyzed the scenario files which contain data every minute and looked at theevents that happen at the same minute (Enter and exit of SAA, EO and slew). Since there are


six different possible events, there are C26 = 15 different test cases to check. However, since the

start and end of the same type of event (SAA, EO or slew) can’t happen at the same time, threetest cases can be eliminated which leaves 12 test cases in total to check.

Table 3.6: Number of events happening during the same minuteNumber of occurrences

SAA enter and EO enter 43

SAA enter and EO exit 42

SAA exit and EO enter 40

SAA exit and EO exit 42

SAA enter and slew enter 9

SAA enter and slew exit 8

SAA exit and slew enter 8

SAA exit and slew exit 8

EO enter and slew enter 114

EO enter and slew exit 7

EO exit and slew enter 102

EO exit and slew exit 11

We can see from table 3.6 which uses simulation data generated over one year that all 12 testcases happen at some point during the year and therefore, we have to verify that the transitionswork as expected for all of them. I had to test these overlapping events for all the differentmodes (INIT, STAND-BY, SAA CONF, ENG CONF, CALIB, DARK, BACKGROUND andOPER), which means 8*12=96 test cases. Thankfully, we don’t have to try as many test casessince, for example, receiving SAA exit wouldn’t trigger any mode transition if it is received inany mode other than SAA CONF. This excludes 4 test cases for 7 modes which leaves 68 testcases. The same way, any overlapping that doesn’t include SAA EXIT that is received while inSAA CONF should be ignored, which excludes 8 test cases in SAA CONF, and leaves 60 testcases. There’s also the fact that in INIT and STAND-BY, the mode changes aren’t affected bythe SAA, EO or slew, and we can then exclude them and have 44 test cases left. Finally, theslew exit event should only be received in ENG CONF, which excludes 2 additional test casesper mode for the tuning modes and OPER and leaves 36 test cases.

For each one of the test cases, there are two tests to run. For example, for theSAA enter EO enter case, we should test when we receive SAA enter while making thetransition caused by EO enter and when we receive EO enter while making the transition causedby SAA enter. And in both cases, the result should be that we end up in SAA CONF becauseotherwise, we would risk being in the SAA region and not being in SAA CONF which couldlead to damaging the instrument.

Now that the test cases are identified, we can sum them up in a table (see table 3.7) showingthe expected results as well, and run simulations to check that the results are the ones that areexpected.


Table 3.7: Results of the test cases for the MXT simulator

Mode Test case Expected result Result

SAA CONF

SAA exit & EO enter ENG CONFTransition to ENG CONF and

IN EO

EO enter & SAA exit ENG CONFTransition to ENG CONF and

IN EOSAA exit & EO exit ENG CONF Transition to ENG CONFEO exit & SAA exit ENG CONF Transition to ENG CONF

SAA exit & slew enter ENG CONFTransition to ENG CONF and

initiation of slewslew enter & SAA exit ENG CONF Transition to ENG CONF

SAA exit & slew exit ENG CONFTransition to ENG CONF and slew

exit processedslew exit & SAA exit ENG CONF Transition to ENG CONF

ENG CONF

SAA enter & EO enter SAA CONFTransition to SAA CONF and

IN EO

EO enter & SAA enter SAA CONFTransition to SAA CONF and

IN EO

SAA enter & EO exit SAA CONFTransition to SAA CONF and

OUTSIDE EO

EO exit & SAA enter SAA CONFTransition to SAA CONF and

OUTSIDE EOSAA enter & slew enter SAA CONF Transition to SAA CONF

slew enter & SAA enter SAA CONFSlew initiated and transition to

SAA CONF

SAA enter & slew exit SAA CONFTransition to SAA CONF and slew

stopped

slew exit & SAA enter SAA CONFSlew stopped and transition to

SAA CONFEO enter & slew enter SAA CONF IN EO and slew initiatedslew enter & EO enter SAA CONF IN EO and slew initiatedEO enter & slew exit SAA CONF IN EO and slew stoppedslew exit & EO enter SAA CONF IN EO and slew stoppedEO exit & slew enter SAA CONF OUTSIDE EO and slew initiatedslew enter & EO exit SAA CONF OUTSIDE EO and slew initiatedEO exit & slew exitslew exit & EO exit

OPER


IN EO

EO enter & SAA enter SAA CONFIN EO and transition to

SAA CONF


OUTSIDE EO

EO exit & SAA enter SAA CONFOUTSIDE EO and transition to

SAA CONFSAA enter & slew enter SAA CONF Transition to SAA CONF


slew enter & SAA enter SAA CONFSlew initated and transition to

SAA CONFSAA enter & slew exit SAA CONF Transition to SAA CONFslew exit & SAA enter SAA CONF Transition to SAA CONF

slew enter & EO enter ENG CONFTransition to ENG CONF, slew

started and IN EO

EO enter & slew enter ENG CONFIN EO, transition to ENG CONF

and slew started

slew enter & EO exit ENG CONFTransition to ENG CONF, slew

started and OUTSIDE EO

EO exit & slew enter ENG CONFTransition to ENG CONF, slew

started and OUTSIDE EO

CALIB


IN EO


SAA CONF


OUTSIDE EO

EO exit & SAA enter SAA CONFOUTSIDE EO and transition to

SAA CONFSAA enter & slew enter SAA CONF Transition to SAA CONF

slew enter & SAA enter SAA CONFSlew initated and transition to



started and IN EO

EO enter & slew enter ENG CONFIN EO, transition to ENG CONF

and slew started

slew enter & EO exit ENG CONFOUTSIDE EO, slew initiated and

transition to ENG CONF

EO exit & slew enter ENG CONFSlew initiated, transition to

ENG CONF and OUTSIDE EO

DARK

SAA enter & EO enter SAA CONF IN EO and transition to SAA CON


SAA CONFSAA enter & EO exit SAA CONF Transition to SAA CONFEO exit & SAA enter SAA CONF Transition to SAA CONF

SAA enter & slew enter SAA CONF Transition to SAA CONF




initiated and IN EO

EO enter & slew enter ENG CONFTransition to ENG CONF, slew

initiated and IN EO



initiated and OUTSIDE EO



BACKGROUND

SAA enter & EO enter SAA CONF IN EO and transition to SAA CON


SAA CONFSAA enter & EO exit SAA CONF Transition to SAA CONFEO exit & SAA enter SAA CONF Transition to SAA CONF

SAA enter & slew enter SAA CONF Transition to SAA CONF




initiated and IN EO

EO enter & slew enter ENG CONFTransition to ENG CONF, slew

initiated and IN EO





It appears from table 3.7 that the transitions are handled as expected. Having telecommandsand events happen relatively closely and during transitions doesn’t lead to any unwantedchanges. This wouldn’t be the case if the transitions modes weren’t introduced. Therefore,adding the new transition modes gives full control over how the transitions are handled. Tofurther illustrate this, let’s look at an example. Let’s suppose forget about the transition modesand suppose MXT has received a telecommand to make the transition to check automatictransitions in ENG CONF and that it found that the conditions are verified to go to theCALIB mode. If, while making the transition to CALIB, MXT receives TC STOPCALIB,the telecommand won’t have any effect as MXT behaves as if the telecommand was receivedin ENG CONF. By adding the new transition modes, when making the transition to CALIB,MXT will be in the TR2CALIB mode. And in the TR2CALIB mode, if MXT receives thetelecommand to stop the calibrations, it goes back to ENG CONF which is the desired result.Therefore, the new transition modes give control over the way transitions are handled and arenecessary to ensure that the transitions are made as expected and that MXT is used safely.

By pushing the simulations to have a time step of one second, I ensured that the simulatorbehave as close as possible to the way MXT behaves. Indeed, the mode transitions withouttaking into account the transition time behave as expected as I verified using the first versionof the simulator. Then, I made sure that the transitions are handled well as well by addingthe transition mode and making sure that the overlapping of telecommands and events doesn’tlead to unexpected transitions. At this step, the simulator could be used to test new transitiontechniques and new algorithms for MXT and study their influences on the overall algorithm. Itcould also be used as an input for other simulators (for example the VHF simulator which I willtalk about in the next chapter) to simulate MXT and have more realistic results in the validationphase of the project. Finally, the simulator could be taken one step further by implementing theposition of the wheel, the camera and the thermal control in it to make it as close to the real


instrument as possible.

Chapter 4

The VHF simulator

VHF is the on-board subsystem dedicated to transmit GRB messages to the ground in real time.Burst data and some important instrument housekeeping data can also be transmitted throughit. This link is always active during satellite operations. It is made of an on-board emitter andantennas.

4.1 Introduction to the VHF networkThe VHF ground network is comprised of 40 stations located around the Earth equator +/-30°,and the network connecting them. They have nearly full coverage of satellite passes, ensuring anear real time space-ground link is available most of the time (around 80%). The Alert messageand data which can be sent to ground through the VHF link are shown in figure 4.1.

ECLAIRs, MXT, VT and GRM are connected to the PDPU (see figure 1.3) which is thedata processing unit that controls all payload instruments. VHF messages are computed byinstruments and PDPU and transmitted to the VHF emitter by PDPU.

Since the network coverage is not 100%, there could be periods of time without anyavailable ground stations to send the messages to, either due to a gap in the coverage, orto a station being under maintenance or not available, or for any other possible reason. Themessages that are sent by PDPU during these times are lost and depending on how importantthey are, it could influence the observations and the observation program. In order to makesure that all the messages are received by ground stations, they are repeated by PDPU. TheVHF messages on-board management algorithm performs the storage and repetition of VHFmessages. Depending on the message’s importance and on when it needs to be received, thereare different repetition intervals and repetition techniques for each message. The goal is to find acompromise between the probability of receiving all the messages and the transmission time toreceive all the packets. The probability of reception of messages needs to be maximized whilemaking sure that the transmission times still meet the availability requirements of the SystemRequirements Document.

The VHF messages on-board management algorithm stores received packets in memorybuffers, then chooses amongst all the available packets the next packet that must be transmittedto the VHF emitter. Packets are chosen according to their priority level and according to therepetition settings that are fixed for each message.Some packets are repeated by instruments on a regular basis with a low priority. Only the lastreceived one is transmitted. Loss of packets is allowed. This is the case of recurrent packets.These packets are stored in Type 1 buffers.Some short high priority messages of only one packet must be repeated at regular intervals

28

4.1. INTRODUCTION TO THE VHF NETWORK 29

Table 4.1: Types of VHF messages, with priority and number of packets

IndexMessage name Priority Number of packets

ECLAIRs1 ECLAIRs trigger 1 12 ECLAIRs Light curve high priority 7 203 ECLAIRs Light curve low priority 12 444 Alert descriptor 10 55 ECLAIRs sub-image 16 556 ECLAIRs recurrent 19 2

GRM7 GRM trigger 17 48 GRM Light curve high priority 8 209 GRM Light curve low priority 13 4410 GRM recurrent 20 1

MXT11 MXT position 2 112 MXT photon list 6 1013 MXT MM photon data 18 114 MXT photon data 24 115 MXT recurrent 21 1

VT16 Attitude chart R 3 217 Finding chart R 4 1318 Finding chart V 5 1319 Finding chart V+R 14 1320 VT sub-image R 11 7421 VT sub-image V 15 27422 VT recurrent 22 2

PDPU23 PDPU GRB message 9 124 PDPU recurrent 23 125 Dummy packets 25 1

during a predefined ”repetition duration period’ to ensure that they are received by groundstations at least once. They can be refreshed by instruments, in this case, the last one is repeated.This is the case of the trigger alert messages. These packets are stored in Type 2 buffers.Some packets must be repeated a fixed number of times. These packets are stored in Type 3buffers in which several messages with the same priority can be stored.After a message has been sent, it cannot be chosen again before the repetition interval is elapsed.The algorithm uses a storage buffer for each message with a different priority. The buffer is aFIFO buffer (First In First Out) where the oldest messages are the first that are sent through theVHF link.

4.1.1 Types of VHF messagesVHF messages are computed by the instruments and the PDPU, and they are transmitted to theVHF emitter by the PDPU. These messages are then sent depending on their priorities. Thedifferent messages as well as their sizes, priorities, buffer types and buffer sizes (number of

30 CHAPTER 4. THE VHF SIMULATOR

messages) are summed up in table 4.2.

Table 4.2: Types of VHF messages

Message name Buffer type Buffer size Repetitionduration (s)

Repetitioninterval (s)

Repetitionnumber

ECLAIRsECLAIRs trigger T2 1 2100 300ECLAIRs Light curve high priority T3 2 600 3ECLAIRs Light curve low priority T3 2 600 3Alert descriptor T3 10 600 3ECLAIRs sub-image T3 2 300 3ECLAIRs recurrent T1 2 0 0 0

GRMGRM trigger T3 4 300 3GRM Light curve high priority T3 2 600 3GRM Light curve low priority T3 2 600 3GRM recurrent T1 1 0 0 0

MXTMXT position T2 1 2100 300MXT photon list T3 1 300 5MXT MM photon data T1 3 0 0 0MXT photon data T1 3 0 0 0MXT recurrent T1 1 0 0 0

VTAttitude chart R T3 2 300 4Finding chart R T3 2 600 3Finding chart V T3 2 600 3Finding chart V+R T3 2 600 3VT sub-image R T3 2 300 5VT sub-image V T3 2 300 5VT recurrent T1 2 0 0 0

PDPUPDPU GRB message T3 1 600 3PDPU recurrent T1 1 0 0Dummy packets T1 1 0 0 0

Some of the VHF messages are repeated by the on-board management algorithm (or thePDPU), while others are repeated by the instruments themselves. In table 4.2, the messageswith a non-zero repetition interval are messages which are repeated by the PDPU, while themessages with a zero in the last three columns are repeated by the instruments.

• Recurrent messages: the recurrent messages are repeated by their respective instrumentsevery 30 seconds.

• MXT position: the MXT position message is repeated by MXT every 30 seconds until theend of the first orbit or the beginning of Earth occultation, and every 5 minutes during thesecond orbit. Since the message has a size 1 buffer, the repetition is equivalent to havingthe stored message in the buffer refreshed every 5 minutes. The actual repetition is madeby PDPU every 5 minutes for 2100s.


• MXT MM photon data & MXT photon data: these messages are repeated by MXTwhenever a full packet is available/generated.

In order to get a better idea about the purpose of each message and what it contains, let’slook in more detail into how these messages are generated.

4.1.1.1 Trigger messages: ECLAIRs trigger and GRM trigger

In General Program observation mode, the GRM and ECLAIRs instruments are in operationalstatus for GRB event detection, while MXT and VT instruments are in operational status forGeneral Program target observation. When a GRB event is detected by ECLAIRs, an alertmessage is sent through the VHF link and transmitted to the ground telescopes for follow-upobservations. If the signal to noise ratio is high enough (above a certain threshold, the slewthreshold), a burst pointing request is sent to the platform. After the satellite slew, MXT andVT will generate more accurate GRB localization coordinates for the ground telescope.ECLAIRs trigger is the first alert message that is produced by ECLAIRs when a GRB isdetected. It initiates the alert sequence and provides the slew request if the signal to noiseratio is bigger than the slew-threshold. The alert message is sent to the ground via the VHF linkand to the GRM for the management of the acquisition sequence.The GRM trigger contains similar information but it’s only used in case of a first detection byGRM.

4.1.1.2 Light Curves: ECLAIRs LC High Priority/Low Priority, GRM LC High Priority/LowPriority

When GRM receives an ECLAIRs alert message, it generates two GRM light curve messages, ahigh priority one and a low priority one. The aim of the VHF Light Curve message is to transmitto ground, as quickly as possible via the VHF network, a standard set of count-rates, detectedby ECLAIRs in several energy bands covering a time period around Tb0 (time of the trigger),typically ∼2min before to ∼6min after, with a fine resolution close to Tb0 and a coarser oneelsewhere.The motivation for the VHF Light Curves is to permit a near-real-time on-ground analysis ofthe temporal and broad spectral characteristics of the trigger, and the construction of a coarsebackground subtracted burst light curve. This allows to assess if the trigger looks like a burst, thecategory of burst (short or long) and derive crude spectral characteristics such as the hardnessratio (soft or hard burst).From the scientific point of view, the number of ECLAIRs counters to be sampled is 6containing:

• 4 energy bands (the trigger bands, e.g 4-120, 4-15, 4-50, 25-120 keV). They are a requiredscientific minimum. They permit on ground to construct the light curves used by thetrigger on-board as well as to derive the burst hardness in the soft, standard and hardenergy bands with associated hardness ratios.

• 1 high energy band, including saturating events (e.g >120 keV). It allows to monitor highcount rate conditions mainly due to particles expected when approaching the SAA or highmagnetic latitude zones.

• 1 multiple events counter which permits to specifically monitor zones with increasedcosmic ray fluxes. High increases in saturating and multiple event counters can be usedon ground to put a veto on a trigger.


To produce the light curves, the instruments perform a sampling of the light curves and storea defined amount of samples in a packet. The sampling rates are detailed below. The GRMLC messages contain data from GRM in at least seven bands (two for each of the three GRDsand one for the GPM) on different time scales. The ECLAIRs LC messages contain data fromECLAIRs in at least five bands on different time scales.

The time scales for the high priority LC are as follows:-A high resolution time scale of 128ms, covering at least from 2s before to 6s after Tb0-A medium resolution time scale of 1s, covering at least from 16s before to 60s after Tb0-A low resolution time scale of 8s, covering at least from 150s before to 16s before Tb0

The time scales for the low priority LC are as follows:-A high resolution time scale of 128ms, covering at least from 2s before to 6s after Tb0-A medium resolution time scale of 1s, covering at least from 16s before to 60s after Tb0-A low resolution time scale of 8s, covering at least from 150s before to 400s after Tb0.

The sampling phase of the low priority light curve is offset with respect to the high priority onein order to have a higher overall resolution. Packets for samples at times inferior to Tb0 are allsent at Tb0.

In order to obtain these resolutions, and knowing that four samples are stored in each packet,the sampling periods are as represented in figure 4.1.

Figure 4.1: Light curves sampling periods (High priority at the top, low priority at the bottom)

4.1.1.3 Attitude chart and finding charts: attitude chart R, finding chart R, finding chartR, finding chart V, finding chart V+R

The attitude chart is a message containing the list of the 20 brightest sources in red filter in thewhole VT image. Finding charts are produced by PDPU using images sent by VT in different


filters: red, blue and a combination of both.The attitude chart is generated for the R channel on the first 100s acquisition image. PDPU alsogenerates the attitude chart for the first R channel image at the second orbit.If the GRB is localized by MXT, PDPU generates at the beginning of the first earth occultationone finding chart for the red channel, one finding chart for the blue channel and one findingchart for the combined channels using the three last sets of six 100s images at the current GRBposition.At the beginning of the second earth occultation, PDPU processes the last six VT 100s imagesfor each channel and then combines them.At the beginning of the second orbit, PDPU also generates one finding chart for the red channel,one finding chart for the blue channel, and one finding chart for combined channels using thefirst six 100s images and the current GRB position provided by MXT.

Figure 4.2: VT refining sequence

4.1.1.4 MXT position and MXT photon list

MXT position contains the brightest source in MXT’s field of view. The packet contains thealert identifier received in the slew command, the localization time, the burst coordinate in MXTreference frame, the burst coordinates in J2000 frame, the satellite attitude used to compute theburst coordinates, the photo counts, the integration time, the mean energy, and a quality flag.The MXT position messages are refreshed every 30 seconds until the end of the first obit or thebeginning of Earth occultation, and every 5 minutes during the second orbit.


The MXT photon list packets contain the list of photons detected by MXT since GRB alert andtheir position and energy level.

4.1.1.5 Sub-images: ECLAIRs sub-image, VT sub-image R, VT sub-image V

Sub-images contain images of the GRB taken around the GRB source. The deconvolved sky-region around the source location in the triggered energy band is sent to the ground via VHF inorder to give confidence to the burst advocate that a point-like source was found, and to performon-ground a refined fit of the source position.

4.1.1.6 ECLAIRs alert descriptor

An alert descriptor is generated after the last alert message has been generated. It contains thesummary of the best knowledge ECLAIRs scientific data processing has on a GRB candidate atthe end of the alert message sequence.

4.1.1.7 MXT photon data and MXT MM photon data

On top of recurrent messages, MXT sends to the ground opportunity VHF packets (MXT photondata packets) to report photon data when no other data is transmitted. Outside of GRB sequenceperiods, the VHF link is not totally filled by recurrent messages. Available space can be usedto transmit some real time photon data instead of dummy packets, with the lowest priority, thusno guarantee of transmission to ground.

In MXT’s OPERATION-SCIENCE mode, except when the activity is a ToO-MM, MXTgenerates a photon data VHF packet every time a packet is full. It is filled with photon datacollected during the interval. When the activity is ToO-MM observation, MXT generates MMphoton data VHF packets instead of routine photon data VHF packets.

4.1.1.8 PDPU messages: GRB PDPU, idle packet

The GRB PDPU message contains information about the type of GRB that is detected. The idlepacket is sent whenever there is no message traffic to keep an active VHF link with the satellite.

4.1.1.9 Recurrent messages: ECLAIRs, GRM, MXT, VT and PDPU

The PDPU and each instrument send a recurrent message containing housekeeping informationabout the equipment.

4.1.2 The existing simulatorA simulator for the VHF link has already been developed a few years ago by an intern in orderto contribute to the validation of the VHF messages. In this section, I will present roughly itsfunctionalities.

There are three main functions that simulate the process of generating the messages andsending them to the ground:

• Instrument: The instrument function simulates the instruments. At each time step, itgenerates messages from each of the instruments depending on their generation times. Italso handles the repetition of messages. It has as an output four 3D arrays, one array foreach instrument. Each array contains all the generated packets at that time step for each


Figure 4.3: Architecture of the old VHF simulator

message type. If no message was generated for a message type, the corresponding linecontains %nan at each cell.

• Svomalgo1: This function takes the messages generated by ’Instrument’ and stores themin a queue by adding them at the end. In case of messages of type 1 or type 2 buffers,they are overwritten in the queue whenever new ones are received. For type 1 messages,it’s understandable since loss of packets is allowed and only the messages that weregenerated last are sent. For type 2 messages (ECLAIRs trigger and MXT position), itcan be explained by the fact that, for the trigger for example, only the last received triggerneeds to be sent as it interrupts the old triggers. The same applies for MXT position.

• Svomalgo2: This function finds the packet with the highest priority in the queue andsends it through the VHF emitter. It only sends one packet at a time. When all the packetsof a message are sent, it stores the time it happens and waits for a defined delay beforesending again messages of that type. This function runs at half the speed of the otherfunctions, which is one second (for the other functions). The reason behind this is that ittakes two seconds to send a VHF packet through the VHF link and there is therefore noneed for it to run at a higher speed.

The propagation of the VHF signal from the satellite to the ground is modelled by a 2 secondsdelay. In order to model the earth occultation and the visibility of the ground stations (whichwere not defined at the time), statistical distribution laws were used for earth occultation,visibility gaps and visibility durations.The visibility gap duration distribution function was computed statistically based on a geometricalanalysis of a network of 35 ground stations. The distribution function can be seen in figure 4.4.

The same method is used for the earth occultation. Since earth occultation occurs whenthe instrument’s filed of view is obstructed by the earth and the GRB can’t be observed, a


Figure 4.4: Visibility gap duration cumulative distribution function - 35 stations network

Figure 4.5: Earth occultation duration cumulative distribution function

statistical distribution can be computed based on the delay before an observation due to the earthoccultation and the duration of the observation. The earth occultation’s distribution function is

4.2. UPDATING THE VHF SIMULATOR 37

shown in figure 4.5.The simulator has three different outputs. The first output is an excel table showing the time

of reception of each message as well as its content. The second output is a graphical displayof the table, showing the reception times of packets, when a message is received in its entirety,and when it is repeated. It also displays the stations’ visibility and the earth occultation. Anexample of this display is shown in figure 4.6. The third output that is generated is a tableshowing statistical results about the percentage of the message received at each repetition foreach message, as well as the sending time at each repetition and the total number of messagessent during the simulation. This output was used to make sure that the repetitions were enoughto respect the availability requirements.

Figure 4.6: Example of the old VHF simulator’s output

4.2 Updating the VHF simulatorAs said earlier, the first version of the simulator was developed a few years ago and is no longerup-to-date. Furthermore, that simulator was used to validate the availability requirements;meaning to determine an optimal tuning of the system parameters according to the requirements.At that point, the requirements were qualitative and one of the objectives of the simulationswas to possibly adjust the requirements depending on the system performance. However, at


the current stage of the satellite development, the simulator could be used for a different kindof validation, which is to adjust parameters relative to specific messages. Before exploiting thesimulator and using it for the current needs of the project, it needs to be updated so that it reflectsthe current state of the VHF link. I will detail the way the new simulator is used in section 4.3.While updating the simulator, I had to update the message parameters as they have changedduring the years (such as the size of messages, their priorities, add the new messages...). Also,since a network of ground stations has been chosen as a reference, I implemented the simulationof an orbit and the emission of messages to the ground stations individually. Finally, I changedthe PDPU’s management algorithm which has been changed since the simulator was developed.

4.2.1 VHF messages

The first step in updating the simulator was to update the message parameters. The numberof packets in each message as well as the message priorities have been changed as it can benoticed in table 4.3. When it comes to the GRM trigger, its scenario wasn’t specified at thetime and although it had a set priority, its components weren’t known. Subsequently, it wasn’timplemented in the simulator and it had to be implemented in the new version.Other messages that weren’t implemented in the old simulator were the MXT MM photondata and MXT photon data messages. The reason behind it is that these messages didn’t exist.They were thought of only later in the development process when their utility started appearing.Therefore, these messages had to be added to the simulator.

Another major difference between the two versions was the Light Curves for both ECLAIRsand MXT. In addition to having a different number of packets, a different number samples parpacket and a different packet size, the old version had different sampling periods compared tothe recent ones (figure 4.1). In the old version, each type of light curve (High priority and Lowpriority) gave the desired resolutions of 128ms, 1s and 8s (as explained in section 4.1.1.2). Thismeans that there is a lot of data to send, data which could be redundant at times. Since then,some changes were made to the light curves to make sure to have the desired resolutions butwith a fewer amount of packets. The changes consisted in using a resolution that is the doubleof the desired one for both High Priority and Low Priority, but to offset the Low Priority onescompared with the High Priority ones. This way, high priority and low priority light curvesdon’t take samples at the same time stamps in order to have a better efficiency. When receivingthe High Priority messages, the resolution is lower than the desired one. But once the LowPriority messages are received on ground, the resolution is improved and reaches the desiredvalues.

4.2.2 Visibility by ground stations

In the version of the VHF simulator that was given to me, the visibility of the satellite byground stations was computed using distribution laws. These distribution laws were extractedfrom simulations that performed a geometrical analysis of the station network.

As explained in section 4.1.2, visibility of the satellite by ground stations was computedstatistically using distribution laws for the visibility and gap durations due to the fact that theground stations that make the ground network weren’t determined at the time. However, sincethen, a set of reference stations has been chosen among existing networks used for operationalor experimental projects as well as for scientific activities. The selection criteria fulfill theSVOM goegraphical constraints, which are being located in a latitude of +/-40° with no strong


Table 4.3: Comparison of the VHF messagesNew values Old values

Index Message name Number ofpackets Priority Number of

packets Priority

ECLAIRs1 ECLAIRs trigger 1 1 1 12 ECLAIRs Light curve high priority 20 7 25 73 ECLAIRs Light curve low priority 44 12 50 124 Alert descriptor 5 10 5 105 ECLAIRs sub-image 55 16 55 166 ECLAIRs recurrent 2 19 2 18

GRM7 GRM trigger 4 17 - 178 GRM Light curve high priority 20 8 21 89 GRM Light curve low priority 44 13 28 13

10 GRM recurrent 1 20 1 19MXT

11 MXT position 1 2 1 212 MXT photon list 10 6 10 613 MXT MM photon data 1 18 - -14 MXT photon data 1 24 - -15 MXT recurrent 1 21 1 20

VT16 Attitude chart R 2 3 2 317 Finding chart R 13 4 13 418 Finding chart V 13 5 13 519 Finding chart V+R 13 14 13 1420 VT sub-image R 74 11 76 1121 VT sub-image V 74 15 76 1522 VT recurrent 2 22 2 21

PDPU23 PDPU GRB message 1 9 1 924 PDPU recurrent 1 23 1 2225 Dummy packets 1 25 1 23

masking. Two VHF Networks have been identified during analysis. One includes 40 stationsthat are optimal from a geometrical point of view; the other includes 20 “SVOM” stationsselected by default and 25 geometrically optimized stations to cover the gaps. In the case of thesimulator, only the first network of 40 stations is considered.

Since a set of ground stations has been determined for the studies, the simulator could beupdated to take into account the real positions of the stations. Then, the simulator could keeptrack of the messages that were received by each station during the simulation. In order todo that, we need to figure out a way to simulate an orbit using orbit parameters, and thencompute the visibility of the satellite by each station. Then, this information would be used inthe simulator to determine which ground stations are visible at each time step.

4.2.2.1 Simulation of the orbit

The parameters of the orbit are specified using Kepler elements[3].


Figure 4.7: VHF alert network (40 stations)

The orbit parameters, as specified in the system requirements document, are:

• Semi major axis range: 6978km (h=600km) - 7028 (650km)

• Eccentricity(e): 0 ± 0.003

• Inclination(i): 29° ± 0.2°

• Argument of perigee (ω): 90° ± 180°

These parameters are defined as a baseline. The Right Ascension of the Ascending Node(RAAN, Ω) will be shifting westwards at 6.2°/day. The eccentricity can be reduced to closeto te frozen one (e=0.0005157) in order to minimize the daily attitude variation at a given pointon the orbit. The target parameters are summed up in table 4.4.

Semi major axis 7013kmEccentricity 0.0005157Inclination 29°

Perigee argument 90°RAAN Free

Table 4.4: Target orbit parameters

In order to simulate an orbit, we need to use these parameters in a way that would givethe satellite’s position at each time step. To do so, the satellite’s coordinates are computed inthe LLH (Latitude Longitude Height) frame using three steps: calculate the eccentric anomaly,


Figure 4.8: Satellite orbits - Kepler elements[3]

calculate the cartesian position using coordinate changes, and then convert the cartesian positionto spherical coordinates.

1. Calculate the eccentric anomaly: It is defined based on the circumscribed circle on theellipse. Let t be the current time and t0 be the time at perigee crossing. The mean anomaly,a non-geometrical quantity based on the mean motion of the satellite, is calculated asM(t) = n(t − t0), where n =

√µa−3/2 is the mean motion in radians/sec. The mean

anomaly is then used to calculte the eccentric anomaly as E(t) = M(t)+ esin(E(t)).As it can be noticed, this equation is non-linear and therefore, E(t) is computed usingNewton’s method as:

E = ME0 = E + 1;while abs(E-E0) > epsilon then

E0 = E;E = M + e*sin(E);

end

This method converges after a few iterations and gives a solution close to the real valueat the epsilon-level. Epsilon is typically chosen to be around 10−10;

2. Calculate the cartesian position: Given the eccentric anomaly and the orbit parameters,the position and the velocity of the satellite can be calculated in the q-frame which hasits z-axis perpendicular to the orbital plane and its x-axis pointing to the perigee (theframe is shown in figure 4.9). The position and velocity vectors are computed as follows:


Figure 4.9: Angles to describe satellite motion

Q = [acos(E)− e,a√

1− e2 sin(E),0] and Q = na1−ecos(E) [−sin(E),

√1− e2 cos(E),0].

These vectors are expressed in the q-frame, and we want them expressed in sphericalcoordinates. To do so, we convert them into the intertial frame first.The inertial frame has the mass center of the Earth as its origin. Its x-axis is in theequatorial plane pointing towards vernal equinox, the z-axis is at the mean rotationalaxis, while the y-axis is in the equatorial frame to form a right-handed Cartesian system.It is fixed in space and does not rotate with the Earth.

Figure 4.10: Inertial Reference System

The position and velocity vectors in the inertial frame are computed as:

r = R3(−Ω)R1(−I)R3(−ω)qr = R3(−Ω)R1(−I)R3(−ω)q


where R3 and R1 are the following rotation matrices: R1(θ) =

1 0 00 cos(θ) −sin(θ)0 sin(θ) cos(θ)

and R3(θ) =

cos(θ) −sin(θ) 0sin(θ) cos(θ) 0

0 1 0

3. Convert the cartesian coordinates to spherical coordinates: Once the position is

calculated in the inertial frame r = [x,y,z], it can be converted to latitude, longitude andheight using:

latitude = sin(zR)

longitude = arctan(yx)

height =R

1000−6371(km)

where R =√

x2 + y2 + z2 is the distance from the Earth’s barycenter to the satellite.

4.2.2.2 Visibility of the satellite by a station

In order to compute the satellite’s visibility by a ground station, a solution would be to write thesatellite’s position in a frame fixed to the ground station. The satellite’s position is computed inCartesian coordinates and then coordinate changes are used to write the satellite’s position inthe ENU frame. The ENU (East-North-Up) is used for determining satellite positions relativeto the ground stations. It is fixed to the ground station (making it therefore location dependent)and it is tangent to the lines of coordinates with one axis pointing to the East, one axis pointingto the North and the last axis going upwards following the line that goes from the center of theEarth to the ground station.

Figure 4.11: ENU frame[4]

In order to perform the coordinate change, the following matrix is used:


P =

−sinφ cosλ −sinλ cosφ sinλ

−sinφ sinλ cosλ cosφ sinλ

cosφ 0 sinλ

T

The satellite’s ENU coordinates are then computed using this matrix as:

n = P(1, :)[X−Xre f ,Y −Yre f ,Z−Zre f ]

e = P(2, :)[X−Xre f ,Y −Yre f ,Z−Zre f ]

u = P(3, :)[X−Xre f ,Y −Yre f ,Z−Zre f ]

where Xre f ,Yre f ,Zre f are the ground station’s coordinates in the cartesian frame.These coordinates are then used to calculate the azomuth and zenith angles as follows:

s =√

n2 + e2 +u2

azimuth = arctanen

zenith = arccosus

s is the line of sight, or the distance between the station and the satellite. We could eithercalculate the zenith angle or the elevation angle as elevation = 90°-zenith.The elevation angle is used to compute the satellite’s visibility by the ground station as it is theangle from the horizon to the satellite. We can consider that as long as the elevation angle isabove a certain threshold, the satellite is visible to the ground station. In our case, we use as athreshold an elevation angle of 5°.

To sum it up, at each time step, we calculate the satellite’s position in the Cartesiancoordinates and use coordinate transformations to write the satellite’s position with relation tothe ground station before calculating the elevation angle and checking if it’s above the threshold.This computation is done for each ground station at each time step and gives the satellite’svisibility by all ground stations.

4.2.2.3 Influence of the RAAN on the visibility gap duration

As said in the previous section, the RAAN isn’t fixed and it drifts daily by 6.2°. I used theimplementation of the previous equations to see the influence of the RAAN on the maximumgap duration (longest period of time with no ground stations visible).

From table 4.5 obtained using 24 hours of simulation, we can see that for an angle of 120°,we get a maximum of 360s. This data could be used to simulate different scenarios in theVHF simulator: we could change the value of the RAAN depending on whether we want highvisibility by ground stations or we want to take the worst case scenario with big visibility gaps.

4.2.2.4 Example

In this section, we will see an example of the results for two RAAN values. The RAAN values0 and 120 are used which represent respectively the value for which there are no visibilitygaps and the value for which the visibility gaps are the biggest.

Let’s start by the 0 value. We generate an orbit as seen above and we check the visiblestations at each time step. Figure 4.14 shows the visibility of each station at each time step. The


Table 4.5: Influence of the RAAN on the maximum gap durationRAAN (°) Maximum gap duration (s)

0 020 040 15060 080 60

100 180120 360140 0160 0180 0200 60220 60240 30260 0280 90300 240320 210340 0

top band is green when there is at least one visible station and it’s red when there aren’t anyvisible stations. Figure 4.15 shows a projection of the satellite’s orbit on the ground and helpscheck the validity of the results displayed by figure 4.14. This plot has been generated usingthe VTS software which is a space visualization software from CNES whose main purpose isto animate satellites.

For a RAAN of 120, there are gaps in the Gunma-Haleakala and Haleakala-Easter Islandregions as it can be seen in figure 4.14 and 4.15.

4.2.3 Message repetition by PDPU

In the old version of the simulator, message repetitions were not handled as they should be.In fact, instead of having the PDPU resend messages as it is specified in the specificationdocuments, it is the instruments that take care of repetitions.

The instrument generates a message and sends it to the PDPU. It is stored in a buffer andthen, when the conditions are met to send packets from that message, they are sent by PDPU.Then, when it’s time to repeat that message, the instrument generates it and stores it at the endof the buffer. This is not how repetitions are specified. In reality, the instruments do not handlerepetitions, they only generate the message once and then it is stored in the PDPU which takescare of repeating these messages enough times. Since all of the messages have different buffertypes, different buffer sizes and a different number of packets (see table 4.2), a different bufferhas to be used for each message type.

4.2.3.1 The buffer

The buffer that is used for each message type is a circular buffer. It’s an array with a size ofbuffer size, where buffer size is the buffer size in terms of packets (number of packets*buffer size).


Figure 4.12: Satellite visibility by ground stations for a RAAN of 0

A pointers is used to identify the end of the queue: last index. It points at the slot next to thelast element in the list. Therefore, when adding a new element to the list, it is added in thelast index and then last index is shifted by one. Empty elements of the buffer are filled with%nan which is Scilab’s way of referring to ’not a number’. In order to explain how packets areextracted from the buffer, let’s first introduce how repetitions are handled.

4.2.3.2 The repetitions

The new way repetitions are handled is that the instruments only generate fresh messages anddo not repeat the same message. The PDPU stores them and repeats them depending on thenumber of repetitions, type of buffer... Furthermore, in the original version of the simulator,when the last packet of a message is sent, PDPU waits for a defined amount of time beforestarting to send the message once again. In reality, things are different as PDPU waits for thedefined amount of time for each packet and only sends the packet when the delay is over. Toclarify it, let’s consider a message with two packets (packet 1 and packet 2). In the originalversion of the simulator, when PDPU sends packet 2, it waits for a defined amount of time (let’ssay 5 minutes) before sending packet 1 and packet 2 again which are sent one after the other.In reality, PDPU sends packet 1 and waits for 5 minutes before sending it again. After the firstsending of packet 1, PDPU sends packet 2 and waits for 5 minutes before sending it again. In

4.3. EXPLOITING THE SIMULATOR 47

Figure 4.13: Plot of the satellite trajectory for a RAAN of 0

this example with only one message, the result would be the same and we would have packet 1and packet 2 which are sent one after the other, then 5 minutes later, they are sent once again.But in cases with all the messages with different priorities, it makes a difference on the emissiontimes of messages and does not give the same results. Therefore, since the repetition is handledby PDPU, the extraction of packets is less straight-forward than before. For each buffer, beforereading a packet, PDPU’s algorithm finds the packet with the biggest interval since the lastsent emission, the least amount of repetitions and, if several packets fulfill these conditions, thepacket with the minimum slot index. This ensures that the packets are sent in chronologicalorder when several message occurences are stored in the buffer.

4.3 Exploiting the simulator

Once the simulator was updated by implementing the different changes seen in section 4.2, Icould use it to validate and help design different algorithms for the VHF link.


Figure 4.14: Satellite visibility by ground stations for a RAAN of 120

4.3.1 General program results

One way the simulator was exploited was by using it to see how the messages were sent,meaning the order at which each packet is sent, how long it takes to send one completemessage and how long it takes to finish repeating it, how the visibility profile by ground stationsinfluences these times...The graphic display shows whenever a packet has been received on ground. It also shows whena message has been completely sent by the satellite for the fist time, or when a message has beenrepeated. In addition to that, it shows the satellite’s visibility by ground stations (if the satelliteis visible by at least one station, the packet is received on the ground) as well as the satellite’sfield of view occultation by the Earth. The messages are displayed by order of priority; themessages with the highest priority are displayed at the bottom of the y-axis while the messageswith the lowest priority are displayed at the top of the y-axis. The simulations are performedover two orbits since it takes two earth occultations to generate some messages.The main benefits of this graphic display are to verify the tuning by visually noticing any wrongimplementation, identify and assess qualitatively the tuning parameters to optimize the traffic,quickly study the influence of a different tuning on the traffic, as well as analyze the sendingand reception times of packets.On top of the graphic display, excel files are generated: one file containing the packets that were


Figure 4.15: Plot of the satellite trajectory for a RAAN of 120

Figure 4.16: General sketch of the buffer


received at each time step, and several files (one for each ground station) showing the packetsthat were received by each station and the time at which they were received. All the times arerelative to the ECLAIRs trigger.

Figure 4.17: Architecture of the VHF simulator’s final version

Figure 4.18 shows the final version of the VHF simulator. The earth occultation profile isgenerated in the workspace and used as an input for the ”Instrument” function to generate VTmessages. A time step of one second is used. ”Svomalgo1” stores the generated messages intothe buffer, then ”svomalgo2” is used to extract packets from the queue and sending them. Notethat this function runs at half the speed of ”svomalgo1” and ”Instrument”. That is due to thefact that PDPU sends one message every 2 seconds at best and having ”svomalgo2” run at halfthe speed of other functions ensures that. Then a delay of two seconds is added to the packetthat was selected by PDPU to be sent. This delay is a very basic way of modelling the delaydue to the transmission via the VHF link of the packet. The function ”available stations” findsthe available stations at each time step. ”Check visibility” then checks if at least one stationis available. If that is the case, the packet is sent to the ground. If not, the packet is lost. Thereception of packets is modelled by the packets being stored in a variable in the workspacewhich then could be processed to generate different outputs and displays.

4.3.2 MXT photon data with a bufferAs seen in section 4.2.3, a buffer was used to handle the storage and sending of packets thatare received from the instruments. Since the MXT photon data messages have been thought ofonly recently, a buffer size needs to be designed in order to make sure that the most amount ofpackets is sent, especially since their priority is lower than that of the recurrent packets.During an observation, photon data (coordinates, energy and pattern codes) are collected by


Figure 4.18: Architecture of the VHF simulator’s final version

MXT and gathered in photon data packets, which contain data for 18 photons, before being sentto the ground through the VHF link. In the nominal case, there are no new triggers, the onlymessages that are sent to the ground are the recurrent messages and the photon data messages,the other messages having been sent earlier with the trigger. Therefore, we want to maximizethe number of photon data messages sent in the midst of all the recurrent messages.

Table 4.6: Types of messages sent in the nominal caseInstrument Type of message Number of packets Priority Repeated by instrument every

ECLAIRsRecurrent 1 1 21 30sRecurrent 2 1 21 30s

GRM Recurrent 1 22 30s

MXTPhoton data 1 26 TBDRecurrent 1 23 30s

VTRecurrent 1 1 24 30sRecurrent 2 1 24 30s

PDPU Recurrent 1 25 30sDummy packets 1 27 30s


There are two constraints that should be taken into account when designing the buffer:

• Emission rate of PDPU: The PDPU has a maximum emission rate of 1 packet every 2seconds. This means that in 30s, only a maximum of 15 packets can be sent (1/2).

• Generation rate of photon data packets: Since there are 7 different recurrent messagesthat should be sent every 30s, this leaves 8 packets other than recurrent packets to sendevery 30s. Therefore, only 16 photon data packet can be sent at most per minute (4/15).

In case the generation rate of photon data packets is lower than the maximum generationrate of photon data packets (4/15), then we generate less PD (Photon Data) packets than wecan send at most and therefore, all the generated packets will be sent. In case the generationrate is higher than 4/15, then stored packets in the buffer will be overwritten since the rate atwhich they are added to the buffer is higher than the rate at which they are extracted. Thiscase corresponds to a generation rate equal to 1 packet every 3s, 1 packet every 2s or 1 packetevery second. It is this case which we want to design a buffer size for in order to ensure that aonly photon data packets are sent in the ’empty slots’ and not dummy packets which are lessimportant.In order to design the buffer’s size, I tried different sizes for different photon data generationrates. I ran simulations over 3000s. I started by a generation rate of 1 packet every 3 seconds,which means that the number of photon data packets that are generated by MXT are 1000packets, of which we want to send the maximum.

4.3.2.1 Generation rate of 1 packet every 3 seconds

• Size 1 buffer - No buffer The case with a size 1 buffer corresponds to the case withouta buffer. Whenever a new packet is received, it replaces the packet that is already stored.Figure 4.19 shows the profile and the order at which the packets are sent. The packets arenumbered to help see their reception order.

Figure 4.19: No buffer

When not using a buffer, there are 600 packets which are sent over 1000 generated ones,which represents around 40% of lost packets. We can see from the plot that there are 2


dummy packets and 6 photon data packets that are sent every 30s. These dummy packetsare sent right after sending photon data packets, which is due to the fact that the storedPD packet was sent and a new one hasn’t been received yet. Therefore, the aim of thebuffer is to store photon data packets which would be sent instead of dummy packets.

• Size 2 buffer When using a size 2 buffer, we notice that 700 photon data packets are sentout of 1000 generated ones, with a loss rate of 30%. This is already higher than the firstsolution which had a loss rate of 40%.

Figure 4.20: Size 2 buffer

Figure 4.20 shows that less dummy packets are sent and photon data packets are sentinstead. However, this is still not optimal as there are dummy packet which are still sent.

• Size 3 buffer When using a size 3 buffer, 800 packets are sent out of 1000. This is higherthan both previous solutions with a lost rate of 20%. As it can be seen in figure 4.21,dummy packets aren’t sent anymore and they are replaced by photon data packets.

• Size n buffer, n>3 We can expect for the size 3 buffer to give the best results as we use allthe available slots to send photon data packets, and we cannot have a higher transmissionrate. This is confirmed by the simulations as we get the same loss rate as with a size 3buffer.

Therefore, a buffer which can store 3 photon data packets ensures that the maximum amountof photon data packets is sent. This is true for a generation rate of 1 packet every 3 seconds.However, in order to make sure that it’s the case for different generation rates, we should try iton generation rates of 1 packets every 2 seconds and 1 packet every second.

4.3.2.2 Results for different generation rates

We do the same thing as above for the generation rates of 1 packet every 2 seconds and 1 packetevery second. Table 4.7 sums up the results that were found.


Figure 4.21: Size 3 buffer

Table 4.7: Influence of the buffer size on the number of transmitted PD packets for differentgeneration rates.

Generation rate of photondata packets

SolutionNumber of

generated packetsNumber of emitted

packetsLoss percentage

1 packet / 3sNo buffer 1000 600 40%

Size 2 buffer 1000 700 30%Size ≥ 3 buffer 1000 800 20%



1 packet / sNo buffer 3000 800 73%


We can notice that for generation rates of 1 packet every 2s and 1 packet every second, thesolution without a buffer gives the same results as the solutions with buffer. The reason behind itis that the rate at which packets are added to the buffer (of size 1 or higher) is the same of higherthan the rate at which they are extracted. Therefore, even without a buffer, there is always atleast one packet in the buffer to be extracted. For the generation rate of 1 packet every second,the generation rate is higher than PDPU’s emission rate and therefore, at least 1 packet over 2is overwritten in the queue before it gets the chance to be sent.

4.3.2.3 Recurrent messages generated at random times

By looking closely at figure 4.19, we can notice that the recurrent messages are sent one afterthe other. That is due to the fact that they are generated at the same time and then theyare sent by order of priority. However, that may not be the case in reality as the order ofgeneration of recurrent packets depends on the time at which the instruments are switched on.Therefore, it could be a good idea to check how it influences the results in table 4.7. I did the


same simulations as above but with a more sparse generation time of recurrent messages and Igathered the results in table 4.8.

Table 4.8: Influence of the buffer size on the number of transmitted PD packets for differentgeneration rates (random generation times for recurrent messages).

Generation rate of photondata packets

SolutionNumber of

generated packetsNumber of emitted

packetsLoss percentage





1 packet / sNo buffer 3000 801 73%


We can see from table 4.8 that the results are the same as in the case where the recurrentmessages are generated at the same time except for the case without a buffer with a generationrate of 1 packet every 3 seconds.

Therefore, in order to ensure that the biggest amount of photon data packets are sent and notdummy packets, a buffer with a size 3 would allow the best performance for different photondata generation rates. However, we have only looked at the influence of the buffer size fordifferent PD generation rates. This ensures that the highest amount of packets is sent in theshort term, but in the long term, we would like to send the maximum amount of the generatedphoton data packets (the number of emitted packets would be closer to the number of generatedpackets). Therefore, the duration of the bursts should be taken into account.

4.3.2.4 Influence of the burst duration of the transmitted photon data packets

The high photon data generation rates are due to the fact that a burst is occurring. There are twotypes of bursts: strong bursts and weak bursts. A strong burst produces 16000 photons in 300s,but they generate an ECLAIRs alert, so they won’t be considered here.So let’s suppose we observe a weak burst, not strong enough to trigger an alert, over a period of300s with different flux levels (to be added to the background noise and luminous sources):

• 2 photons/s, <1/20 of a strong burst

• 5 photons/s, 1/10 of a strong burst

• 14 photons/s, 1/4 of a strong burst

One photon data packet contains 18 photons. Since background noise generates 1 photon/sand luminous sources generate 3 photons/s, we would have one packet every 4 or 5 secondsby considering only background noise and luminous sources. Therefore, for a weak burst over300s, we would have three different possible generation rates:

• 1 packet every 3 seconds

• 1 packet every 2 seconds


• 1 packet every second

In this part, I will study the influence of the burst duration on the number of lost packets. Todo so, I set a high photon data generation rate (one of the ones above) during a fixed durationwhich corresponds to the burst duration, and then a low duration rate (less than 1 packet every 4seconds). I ran the simulations over a period of 2000s, with a generation rate of 1 packet every 4seconds outside the burst. I ran the simulation for different photon data generation rates duringthe burst, different burst durations and different buffer sizes.

Figure 4.22: Number of transmitted packets for different buffer sizes (1 packet every 3s)


Figure 4.23: Number of transmitted packets for different buffer sizes (1 packet every 2s)

Figure 4.24: Number of transmitted packets for different buffer sizes (1 packet every second)


From the three figures 4.22, 4.23 and 4.24, we can see that a size 3 buffer offers the bestcompromise between a small size of the buffer and a high number of transmitted packets, withabout 95% of the maximum number of packets that could be sent with high sized buffers beingsent. This conclusion holds for all three durations of the burst and for the three generation ratesduring the burst.

4.3.3 Early GRM trigger

When a strong burst occurs, it can be detected by either ECLAIRs or GRM. However, eventhough the trigger has a high chance of being sent by ECLAIRs first, it could be generated byGRM before ECLAIRs sends it because of the fact that GRM has three detectors pointing atdifferent directions. In case the trigger is generated by GRM first, we need to check the delaythat is induced by the new messages that are sent before the ECLAIRs trigger and see how muchit delays the overall sending of the messages.

When a GRM trigger is sent to the PDPU, the GRM Light Curves High Priority start beinggenerated as well and they are repeated to ensure that they are received on ground. On theother hand, when the ECLAIRs trigger is generated, the GRM Light Curves High Priority aregenerated as well once again since they contain new data, and they have to be repeated to bereceived on ground. Therefore, the fact that GRM LC High Priority are generated twice woulddelay other messages and we want to see how much it is delayed and if the delay is acceptable.

To do so, I ran a simulation with the GRM trigger and GRM Light Curves High Prioritybeing generated at t=0 and the ECLAIRs trigger being generated at t=100s after the whole LightCurves message was generated. The ECLAIRs trigger sets off the rest of the messages exceptthe GRM trigger. Each message is repeated thrice, which means that each message is sent atotal of 4 times, except the attitude chart R message which is repeated four times. I register thetime at which the last packet of the last repeated message is received for each message and Icompare these times between the case with an early GRM trigger and the case without an earlyGRM trigger.

Table 4.9 sums up the results for the case with 2 repetitions. The times are expressed inseconds and with the ECLAIRs trigger as an origin for time. Figures 4.25 and 4.26 show thegraphical plot of the simulations that were used to generate table 4.9.

From table 4.9, we can see that most messages aren’t affected by the early GRM and thatthey are still received at the same time after the ECLAIRs trigger. That is the case for all themessages with a priority higher than 8 since GRM light curve high priority and GRM trigger’spriorities are lower. Concerning the messages with lower priorities than GRM light curve highpriority, they are each influenced in a different way by the early GRM trigger. Let’s look at eachone of these messages by order of priority.

Priority 8: GRM Light Curve High Priority are received at the same time even thoughthere is twice as much data to send. That is due to the fact that the first fresh message that isgenerated is generated completely before the ECLAIRs trigger while the second fresh messagestarts being generated at the ECLAIRs trigger. From then on, they will get repeated one afterthe other and the last message that would be repeated would be the one that was generated atECLAIRs trigger. Since the messages with higher priorities haven’t been changed, the sameamount of time has elapsed from the ECLAIRs trigger to the last packet of the GRM LC HPmessage. However, since there is more light curve data that is sent in the same amount of time,we can expect to have delays for messages with lower priorities.

Priority 9: GRB PDPU are received at the same time. That is because the GRB PDPUpackets are sent while GRM LC HP are generated in the times without any GRM LC HP data


Figure 4.25: VHF traffic without an early GRM trigger

being sent. It is therefore not affected as the order so far for the messages that are generated asa consequence of the ECLAIRs trigger isn’t disturbed yet.

Priority 10: ECLAIRs alert descriptor received at the same time because these packets aresent right after GRB PDPU packets with the same repetition intervals. Therefore, there is noreason for them to be delayed relatively to the ECLAIRs trigger.

Priority 11: VT sub-image R is received at the same time for the same reason as forECLAIRs alert descriptor.

Priority 12: ECLAIRs Light Curve Low Priority is received at the same time for the samereasons.

Priority 13: GRM Light Curve Low Priority is delayed by 36s. That is due to the fact thatthe repetitions happen at the same time as the repetitions of the first GRM LC HP messagewhich delays each GRM LC LP repetition by 36s.

Priority 14: Finding chart V+R is delayed by 50s. It is delayed because it is sent directlyafter the GRM LC LP and therefore it inherits GRM LC LP’s delay. The additional 14 secondsof delay are due to GRM LC HP which are still being sent when the finding chart V+R arebeing generated. This delay is only for the first finding chart V+R message that is generated.The other updates that are made depending on earth occultation aren’t affected by the early


Table 4.9: Types of VHF messages

Message name Priority Volume (packets)No early

GRMtrigger

with earlyGRMtrigger

ECLAIRsECLAIRs trigger 1 1 - -ECLAIRs Light curve high priority 7 20 1918 1918ECLAIRs Light curve low priority 12 44 2234 2234Alert descriptor 10 5 1970 1970ECLAIRs sub-image 16 55 3504 3536ECLAIRs recurrent 19 2 - -

GRMGRM trigger 17 4 3640 3254GRM Light curve high priority 8 20 1958 1958GRM Light curve low priority 13 44 2322 2358GRM recurrent 20 1 - -

MXTMXT position 2 1 - -MXT photon list 6 10 1302 1302MXT MM photon data 18 1 - -MXT photon data 24 1 - -MXT recurrent 21 1 - -

VTAttitude chart R 3 3 1828 1828Finding chart R 4 28 2458 2458Finding chart V 5 28 2510 2510Finding chart V+R 14 28 2948 2988VT sub-image R 11 74 2720 2720VT sub-image V 15 74 3984 4340VT recurrent 22 2 - -

PDPUPDPU GRB message 9 1 1884 1884PDPU recurrent 23 1 - -Dummy packets 25 1 - -

GRM trigger and are still received at the same time.Priority 15: VT sub-image V is delayed by 356s. Because these messages are big ones (74

packets) and have a low priority, they are easily affected by the delays above. Without an earlyGRM trigger, most of the VT sub-image V message is sent right after finding chart V+R asthere are no messages with a higher priority to be sent. However, in the case with an early GRMtrigger, the delay to GRM LC LP and finding chart V+R causes the available ’spot’ to be filled,and there is less place overall as there is twice as much GRM LC HP data to be sent.

Priority 16: ECLAIRs sub-image is delayed by 32s. This delay is much smaller than thedelay for VT sub-image V as this message manages to fit in the ’empty spots’ for VT sub-imageV, the empty spots being times where no VT sub-image V packet is ready to be sent becausethe repetition interval isn’t elapsed yet.

Priority 17: GRM trigger is received earlier by 386s. In the case without an early GRMtrigger, the first emission is made at t=410s while the second one is made at t=2892s. In the


Figure 4.26: VHF traffic with an early GRM trigger

case with an early GRM trigger, the first emission is made at t=-64s and the second one at t=410s(relatively to the ECLAIRs trigger). The third emission is then made at t=2892. Therefore, thereason behind the early reception of the GRM trigger is that there is only one spot in the ’earlyphases after ECLAIRs trigger’ to send a GRM trigger because of its low priority. By sendinga GRM trigger before ECLAIRs trigger, we save one emission in the sequence after ECLAIRstrigger.

From analyzing the results of the simulations, it appears that most of the messages aren’taffected by the fact that there is an early GRM trigger. The only messages that are affectedare ECLAIRs sub-image, GRM trigger, GRM LC LP, finding chart V+R and VT sub-image V.They are all delayed except GRM trigger which is received earlier. The delays are relativelysmall (32s for ECLAIRs sub-image, 36s for GRM LC LP and 40s for finding chart V+R)except for VT sub-image V for which the delay is 386s. However, even with this delay,the availability requirements are still met (the message should be available 65minutes=3900safter its generation) as the message is generated at t=625s and the last repetition is received att=4340s.

Therefore, having an early GRM trigger induces some small delays for some messagesbut the times of reception of the messages are still roughly the same and they still meet theavailability requirements.


4.3.4 ToO-MM; MXT photon listObserving a ToO-MM (Target of Opportunity-Multi Messenger) source is different fromobserving other sources such as GRBs or the General Program. That is due to the fact that Too-MM observations are made in tiles. The targeted sky-region is divided into small observationareas called tiles which are 5°x5°, and they are programmed outside of SAA and outside ofearth occultation. In case of a multi-messenger ToO, between 4 and 25 tiles are observed withan average duration of 10 minutes for each of them. The tiles are split into several orbits witha maximum number of 3 tiles per orbit. Before each tile, a slew must be performed in orderto point in the right direction for the next tile. ToO-MM are expected to be made once permonth during the first phase of the mission with a goal of once per week for the second phase(the number and frequency of ToO-MM isn’t controllable as it depends on the opportunity). Toallow for a fast source identification at the science centers, all MXT photons detected duringthe ToO-MM are sent to the ground using the VHF link in MXT photon list messages. Thesepackets are filled as photon data is gathered and are sent whenever a packet is full.

Figure 4.27: Example of tiles and slew distributions

Figure 4.27 shows an example of how tiles are distributed over two orbits. The data istaken from the scenario files (see 3.2.1) generated by the SVOM mission simulator. Each tileis preceded by a slew with a duration of 2 minutes. Each tile takes 10 minutes. All the tilesare performed outside of SAA and outside of Earth Occultation. When the third tile of an orbitcomes to the end of its 10min duration, the tile stays active until it’s time to start a new tile inthe next orbit.

As it is the case for other messages, whenever a MXT photon list message is generated, ithas to be repeated in order to make sure it’s received on ground in case it was sent during avisibility gap. However, since a message is generated in each tile, it could happen that new


messages and repetitions overlap and all the messages wouldn’t be received during the orbitthey were generated on.

I performed an analysis of the input files that were generated using the SVOM missionsimulator in order to deduce a statistical distribution for the periods ”not in SAA and not inEO”, which are the periods during which the ToO-MM observations are made. Figure 4.28shows the duration distribution by displaying the number of occurrences of each duration, usingdata collected over one year. Figure 4.29 uses the same data to display the mean duration of’not in SAA and not in EO’ intervals.

Figure 4.28: ’Not in SAA not in EO’ duration distribution

We can see that the periods where tiles could be programmed have a duration that is mostlydistributed around 50 minutes. The average duration of a period ’out of SAA out of EO’ isaround 36 minutes with a standard deviation of 17 minutes. This seems to be enough to meetthe requirement of 3 tiles of 10 minutes each per orbit. To get a better idea of the distribution ofthe ’not in SAA not in EO’ durations, let’s look at their weekly mean duration over the span ofone year in figure 4.29. We can see that the mean duration per week is around 30 minutes witha minimum of about 26 minutes in a week. This is enough to meet the goal of one ToO-MMobservation per week.

I used the VHF simulator to see how long it takes to send new messages and their repetitionsand to check if the repetitions overflow to the next orbit. The simulations are made over twoorbits. Three tiles are programmed each orbit on periods outside of SAA and outside of earthoccultation, followed by thrre other tiles on the second orbit. Each tile lasts ten minutes and theslew before each tile lasts two minutes. The third tile of an orbit stays active until the next orbit.A slew isn’t initiated unless the satellite is neither in SAA nor in earth occultation. If the tenminutes that a tile lasts end and the satellite is in SAA or earth occultation, the tile stays activeuntil the satellite is outside both SAA and earth occultation, and then the slew can be initiated.The only messages that are sent are MXT photon list and the recurrent messages. During each


Figure 4.29: Weekly mean duration of ’not in SAA not in EO’ intervals

tile, a MXT photon list message is generated and stored in the buffer which can contain up tosix messages. Each message is repeated twice with an interval of ten minutes. Concerning thegeneration rate of photon list packets, I considered the background noise’s rate which is onephoton per second. Because each packet contains data from 18 photons, it takes 18 seconds togenerate a packet.

These results would naturally be influenced by the ’not in SAA and not in EO’ distributionwhich lead me to test it on different scenarios. In this report, I will only present a scenario withan anomaly which I believe to be the most interesting.

We can notice that, because each packet is repeated individually by PDPU, the time that isnecessary to send a fresh message and its repetitions is none other than the sum of the repetitiontimes and the time to send each of the messages. Since it takes 18 seconds to generate onepacket, even if a new message is generated while an old one is being repeated, there won’tbe any delay (or at most 2 seconds of delay if they happen exactly at the same time). Thisconclusion is valid for different scenarios for ’not in SAA not in EO’ distributions. The onlycase where a message would overflow on the next orbit is if the tile starts late in an orbit andthere isn’t enough time to send the fresh messages and its two repetitions.

Because there is no delay from one orbit to the other, it could be interesting to look atthe maximum number of packets that could fit in a MXT photon list packet before unwantedside effects would start appearing. By running simulations for different packet sizes, it appearsthat the first dimensioning parameter which could cause problems is the duration of the tileswhich is fixed to ten minutes. If we consider the extreme case where photon list packets aregenerated for the whole duration of a tile (1 packet every 18 seconds), we would be limitedto 33 packets (33*18=594s). Generating 34 packets would require 612 seconds which is more


Figure 4.30: ToO-MM simulations with messages overflowing to the next orbit

than the expected duration of a tile. Therefore, unless the duration of the tiles is extended, MXTphoton list is limited by a maximum of 33 packets.

This gives a rough idea about how much the messages are delayed. The durations of the tilesand the slew could be variable depending on the position of the tile and the observation to bemade in each tile. These variables could be used to get more accurate simulations. Furthermore,in this case, I didn’t consider a GRB observation. The simulations could be pushed further byconsidering a GRB alert (which doesn’t interrupt the ToO-MM observations, but some messagesare still sent after the alert). MXT MM photon data could also be added to the mix to see theirinfluence by choosing different photons fluxes. Unfortunately, I didn’t have enough time duringthe internship to further explore these leads.

Chapter 5

Conclusions and improvements

This chapter explains the conclusions obtained throughout the thesis and proposes a number ofimprovements that could be made to improve the work that was done and exploit it.

5.1 ConclusionsThe thesis consisted of two main parts: the simulator for MXT and the simulator for the VHFnetwork. While the work on the MXT simulator consisted mainly in developing it, the work onthe VHF simulator consisted in updating the existing simulator and exploiting it.The MXT simulator has reached a deep level of modelling and is quite close to the way modetransitions should be handled on-board. The input can be chosen at will and the output shoulddisplay the mode at each time step. The two different outputs (graphical display and textdisplay) allow for two ways of looking at the results. By using the simulator, I managed tofind cases where the algorithm didn’t work as expected, especially when a telecommand isreceived while a transition is made. Adding new transition modes helped solve this issue as itgave complete control over how transitions are handled. Adopting this solution has helped havea relatively stable version of the MXT’s algorithm which fulfills the role that is expected fromit. If further changes are needed to be made to the algorithm, the simulator that I developedcould be used to look at the consequences of these changes on the overall performance of thealgorithm.I have worked more on the VHF simulator which I have updated using the new parameters thathave changed since it was developed. I have also added new functionalities to it by simulatingan orbit and computing the satellite’s visibility by each ground station, and making PDPU’son-board management algorithm more realistic. Once these updates were made, I was ableto exploit the simulator to help design certain message parameters and validate them. Theseincluded the design of the buffer for MXT photon data and MXT MM photon data for which Ifound that the optimal buffer size is three, the study of the influence of an early GRM triggeron the sequence of messages, for which I found out that having an early GRM trigger doesn’tmajorly influence the results because of the way packets are repeated, as well as the study of theToO-MM observations and the MXT photon list messages that are sent for these observations,for which I found out that there is no overflowing of messages over the next orbits and thatthe maximum number of packets that could be fit into one MXT photon list message is 33.These results will be used when dimensioning the MXT photon data and MXT MM photondata buffers as I have found the optimal buffer size to compromise between a small size of thebuffer and a small loss percentage of packets. The study of the early GRM trigger shows how adifferent detection method (by GRM instead of ECLAIRs) influences the sequence of messages

66

5.2. FURTHER WORK 67

and their reception times. The limit that was found for the size of MXT photon list will helpwhile dimensioning these messages when their content will be known in more detail.

5.2 Further workThere is still more work that could be done to with both the MXT and VHF simulators. Atthe moment, MXT’s on-board algorithms are still in the definition phase and there is no stableversion yet. The use of the simulator that was developed would help validate the new algorithmsas long as it’s kept up to date with the new changes.For the VHF simulator, packets could be made to be more realistic as it is now only an arraywith some basic IDs. Making the packets more realistic would help have a VHF flow that isquite close to the flow the real VHF link would generate. Then, by tracking the messages thatare received by each ground station, it would be possible to get an idea of how the messagesare received on the ground (flux, types of messages, the sequence of messages...) and possiblypredict the way messages should be handled once received by a ground station.Another possible improvement could be to try and combine both simulators so that the messagesgenerated by MXT could be more realistic and generated at accurate times. To do so, the twosub-modes of the OPER mode have to be detailed as they are not considered in this version ofthe simulator, and only the OPER mode is considered.

On a personal level, this internship was a great opportunity for me as it introduced me bothto the space industry and to the professional world. The fact that the project is on-going and verydynamic was interesting as well. It allowed me to get an insight on how a big and ambitiousproject is carried out and introduced me to engineering methods which I didn’t know about.I am grateful for the opportunity that was given to me to learn many new things through theinternship and hope that I will be able to better these skills in the near future and keep learning.

Bibliography

[1] G. J. Fishman and C. A. Meegan, “Gamma-ray bursts,” Annual Review of Astronomy andAstrophysics, 1995.

[2] S. L. Snowden. Rosat guest observer facility. [Online]. Available: https://heasarc.gsfc.nasa.gov/docs/rosat/gallery/misc saad.html

[3] P. K. Enge, “The global positioning system: Signals, measurements, and performance,”International Journal of Wireless Information Networks, vol. 1, no. 2, pp. 83–105,Apr 1994. doi: 10.1007/BF02106512. [Online]. Available: https://doi.org/10.1007/BF02106512

[4] B. Hofmann-Wellenhof, H. Lichtenegger, and E. Wasle, GNSS-global navigation satellitesystems: GPS, GLONASS, Galileo, and more. Springer, Vienna, 01 2007.

68

https://heasarc.gsfc.nasa.gov/docs/rosat/gallery/misc_saad.html

https://heasarc.gsfc.nasa.gov/docs/rosat/gallery/misc_saad.html

https://doi.org/10.1007/BF02106512

https://doi.org/10.1007/BF02106512

validation of on-board algorithms for svom satellite payload management1191455/... ·...

Documents