source: trunk/MagicSoft/GRB-Proposal/Monitor.tex@ 6158

Last change on this file since 6158 was 6158, checked in by garcz, 20 years ago
*** empty log message ***
File size: 10.2 KB
Line 
1\section{The Burst Alarm System at La Palma}
2
3{\bf Current status:}
4
5\par
6
7The Burst Alarm System is installed and working since last summer
8in La Palma. The duty of the Burst Alarm System
9is to perform a full-time survey of the {\it GRB Coordinates Network} (\g)~\cite{GCN} alerts. Different satellite experiments perform GRB monitoring
10in their wide FOV and send immediately the coordinates of the GRBs to the \g network.
11The network send the alerts to registered users and allows other satellites as well as
12ground based observatories to observe the GRBs and their afterglows at different wavelengths.
13The Burst Alarm System is composed by a core program -
14which acts in two ways: on the
15one hand it manages the monitoring of the \g, on the other it manages
16the communication with the Central Control (CC). Then it also manages
17three communication channels to notice the shifters
18about an alert situation. The program is called {\it gspot} (Gamma
19Sources Pointing Trigger). It is a C based daemon running 24
20hours a day on the {\it www} machine, our external server, in a
21{\it stand alone} mode. It does not need to be operated and is
22fully automatic. It manages network disconnections
23within the external net and/or the internal one.
24
25
26\subsection{The connection to GCN}
27
28The connection to \g is performed by {\it gspot} through a
29TCP/IP connection to a computer at the Goddard Space Flight Center (GSFC).
30This computer distributes the information it receives from the satellite
31experiments through the normal internet socket connection. The {\it gspot} on our
32side acts as a server while the client, running at the GSFC,
33manages the communication of the data concerning the GRBs
34and concerning the status of the connection. \\
35
36The format of the data distributed through the \g differ between the individual satellites
37and the kind of package. There are three satellites participating in the GRB survey:
38HETE-2~\cite{HETE}, INTEGRAL~\cite{INTEGRAL} and SWIFT~\cite{SWIFT}. All are sending alerts which include the
39UTC, coordinates (not always), error on coordinates
40(not always) and intensity (photon counts) of the burst.
41The first notices from HETE-2 and INTEGRAL usually do not include the coordinates.
42In few cases only coordinates are distributed in more refined notices.
43The \sw alerts are predicted to arrive with coordinates between 30-80 sec after the onset of the burst.
44The error on the coordinates from the BAT detector will be 4 arcmin which is smaller than the size of one
45inner pixel of the \ma camera.\\
46
47In case of an alert {\it gspot} stores the informations and enters
48an {\bf Alarm State}. The duration of the alarm state depends on the following parameters:
49
50\begin{itemize}
51\item {\bf Darkness of the sky}: Determined from the distance of the sun
52to the astronomical horizon of 108$^\circ$ zenith;
53\item {\bf Position of GRB}: The GRB equatorial
54coordinates are transformed into local horizontal coordinates.
55The resulting GRB zenith angle has to be smaller than 70$^\circ$. In the case that the moon is
56shining, this zenith angle limit is reduced to 65$^\circ$;
57\item {\bf Position of moon}: The angular
58distance from the GRB to the moon has to be at least 30$^\circ$.
59\end{itemize}
60
61If one or more of these conditions fail, {\it gspot} enters into a \text
62{yellow}{\bf Yellow Alarm State}. It means that the GRB is not observable at the moment.
63Currently the program does not calculate if and when the GRB will become observable for \ma.
64If all conditions mentioned above are satisfied, {\it gspot} enters into a \textcolor{red}{\bf Red Alarm State}, it means that the GRB is considered to be observable now.\\
65
66In both cases (in \textcolor{red}{RED} and \textcolor{yellow}{YELLOW} alarm state) {\it gspot} establishes the communication with the CC and sends the GRB equatorial coordinates (RA/DEC J2000).
67For the communication with CC the format defined in~\cite{CONTROL} is used. In the same time
68the shifters and the GRB-MAGIC group is contacted in different ways as described in the next sessions.
69
70\subsection{The interface to the Central Control}
71
72An interface of {\it gspot} sends all the relevant information to {\it arehucas}.
73In the case of {\bf NO Alarm State} the standard packages, containing the main global status
74of the two subsystems, are continuously exchanged between CC and {\it gspot}.
75In the alert case {\it gspot} starts to send to CC special alert packages,
76containing information about of the GRB and the ''color'' of the alert.
77The exchange of the alert packages continues until the following steps occur:
78
79\begin{itemize}
80\item {\it gspot} receives from {\it arehucas} the confirmation
81that it has received the alert notice; {\it arehucas} must send the alert back in order
82to perform a cross-check of the relevant data
83\item the alarm state expire after {\bf 5 hours}
84\end{itemize}
85
86At the moment {\it arehucas} informs the shift crew about the alert and takes
87further steps only in case of red alerts. In this case a pop-up window
88appears with all the alert information received by the burst monitor.
89The operator has to confirm the notice by closing the pop-up window.
90He can decide to stop the current scheduled observation and to point the GRB.
91A new button in the CC will be displayed and allows to point the telescope to
92the GRB coordinates by pushing it.
93
94\subsection{GRB archive and emails to the GRB-mailing list}
95
96In case of an alert -- even if it did not contain the necessary coordinates -- the
97information is translated into ''human language'' and stored in ASCII files.
98At the same time an e-mail is sent to the MAGIC GRB-mailing list.
99
100\subsection{The GRB web page}
101
102The status of the GRB Alert System and relevant informations about the lastest
103alert are displayed on a separate web page. The page is hosted at the web server in La Palma.
104The address is the following:\\
105
106\qquad \qquad http://www.magic.iac.es/site/grbm/\\
107
108The web page updates itself automatically every 10 seconds. In this way
109the status of the Burst Alarm System can be checked by the shifters and from outside.
110
111\subsection{The acoustic alert}
112
113A further CC-independent acoustic alarm called {\it phava}
114(PHonetic Alarm for Valued Alerts) will be installed
115in La Palma very soon. It will provide a loud acoustic signal
116even if {\it arehucas} is switched off, so that persons in the counting house
117will be noticed about the alert situation. The signal will be on as long as
118{\it gspot} stays in alarm state, and in any case for a minimum of 1 minute.
119This device feature also a display with the status of the system and the alert.
120
121\subsection{Summary of alerts received until now}
122
123Since July, 15th 2004 {\it gspot} has been working stably at La Palma.
124It received about 100 alerts from HETE-2 and INTEGRAL, out of which
125only 21 contained GRB's coordinates. Time delays
126were in the order of several minutes to tens of minutes. The Burst Monitor can be considered bug-free since
127November 2004. From this moment we received the following two significant alerts:\\
128
129\begin{tabular}{lllcccl}
13019th & December & 2004 & 1:44 am & INTEGRAL satellite & Zd $\sim 60^\circ$ & Time delay 71 sec.\\
13128th & January & 2005 & 5:36 am & HETE-2 satellite & Zd $\sim 65^\circ$ & Time delay 73 min. \\ \\
132\end{tabular}
133
134In both cases the weather conditions at La Palma were very bad.
135
136\subsection{Experience of SWIFT GRBs until now}
137
138According to the \sw homepage~\cite{SWIFT} the satellite detected 12 GRBs since mid December last year.
139The bursts were detected by chance during the comissioning phase. The satellite did not send
140the coordinates on time to \g. Anyhow, in the current sample are two bursts
141which in principle could have been observed by \ma:\\
142
143\begin{tabular}{lllccc}
14419th & December & 2004 & 1:42 am & SWIFT satellite & Zd $\sim 65^\circ$ \\
14526th & December & 2004 & 20:34 am & SWIFT satellite & Zd $\sim 52^\circ$ \\ \\
146\end{tabular}
147
148\subsection{Comparison between the satellite orbits}
149
150Figure 1 show the difference between the orbits of the \sw, \he and \ig satellite.
151The \sw and \he satellites are situated in a circular orbit with 20.6$^\circ$ respectivly 2$^\circ$ inclination. The revolution period of the \sw and \he satellite add up to 100min. The \ig satellite is situated in an highly eccentric orbit with a revolution period around the Earth of three sidereal days.
152
153\par
154
155It is difficult to make strong conclusions from the individual satellite orbit. The orientation of the satellite FOV is influenced by the scheduled targets. Hovewer, \sw is the satellite with the largest inclination and overlaps mostly with the FOV of \ma. This increases the chance to recive {\bf Red Alarm} from this satellite.
156
157\begin{figure}[htp]
158\centering
159\includegraphics[width=0.7\linewidth]{GCNsatellites.eps}
160\caption{Orbits of the \sw, \he and \ig satellites}
161\label{fig:grh}
162\end{figure}
163
164\subsection{Routines to be defined}
165
166The Burst Alarm System is currently able to provide the minimum
167features needed to point and to observe a GRB. However, in order to improve our efficiency
168to point and observe GRBs, several procedures have to be defined:
169
170\begin{itemize}
171\item {\bf Yellow Alarm strategy}:
172The strategy to follow a {\bf Yellow Alarm} is not defined yet.
173In such a case the CC does not undertake any steps,
174except confirming the alarm notice to the Burst Monitor. We do not
175calculate if and when the GRB will become observable.
176It would make sense to check if during the period of 5 hours we could point to the burst.
177Then, the Alarm System should change to the {\bf Red Alarm State}
178at that time and allow the observation.
179
180\item {\bf Sequence of alerts}:
181How to deal with new alerts that are distributed during the time
182that {\it gspot} is in alarm state? Currently {\it gspot}
183locks its alert status until it exits the alarm state (see session 2.2).
184This feature was implemented to avoid any loose of the GRB information.
185Such a situation can occur when for example more than one burst alert is send before
186the shift crew starts the CC. To solve the problem we will change the {\it gspot} routine by implementing a list of the available GRB alerts.
187
188\par
189
190If more than one alert is present in the list, the program
191will weight the possible GRBs on the following criteria:
192(1) the total time of observability within the canonical 5 hours,
193(2) the intensity of the burst and
194(3) the time until the GRB becomes observable.
195The information of the best GRB will be send to the CC.
196
197\end{itemize}
Note: See TracBrowser for help on using the repository browser.