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

\section{The Burst Alarm System at La Palma}

{\bf Current status:}

\par

The Burst Alarm System is installed and working since last summer
in La Palma. The duty of the Burst Alarm System
is to perform a full-time survey of the GCN (Gamma-Ray Bursts
Coordinates Network) alerts. Different satellite experiments perform GRB monitoring
in their wide FOV and send immediately the coordinates of the GRBs to the GCN network.
The network send the alerts to registered users and allows other satellites as well as
ground based observatories to observe the GRBs and their afterglows at different wavelenghts.
The Burst Alarm System is composed by a main program -
the core of the system - which acts in two ways: on the
one hand it manages the monitoring of the GCN, on the other it manages
the communication with the Central Control (CC). Then it also manages
three communication channels to notice the shifters
about a alert situation. The program is called {\it gspot} (Gamma
Sources POinting Trigger). It is a C based daemon running 24
hours a day onto the {\it www} machine, our external server, in a
{\it stand alone} mode. It do not need to be operated and is
fully automatically able to manage network diconnections
within the external net and/or the internal one.


\subsection{The connection to GCN}

The connection to GCN is performed by {\it gspot} through a
TCP/IP connection within a computer at Goddard Space Flight
Center (GSFC). This computer distributes the informations it is recieving from the satellite
experiments through the normal internet socket connection. The {\it gspot} onto our
side acts as a server while the client, running at the GSFC,
manages the communication of the data concerning the GRBs
and concerning the status of the connnection. \\

The format of the data distributed through GCN differ between the individual satellites
and the kind of package. There are three satellites participating in the GRB survey:
HETE-2, INTEGRAL and SWIFT. All are sending alerts which include the
UTC, coordinates (not always), error on coordinates
(not always) and intensity (photon counts) of the burst.
The first notice from HETE-2 and INTEGRAL usually do not include the coordinates.
In only few cases coordinates are distibuted delayed in more refined notices.\\

In case of an alert {\it gspot} stores the informations and enters into
an {\bf Alarm State}. The duration of the alert state depends on the following parameters:

\begin{itemize}
\item {\bf darkness of the sky}, determined from the distance of the sun
to the astronomical horizon of 108$^\circ$ zenith;
\item {\bf position of GRB}, the GRB equatorial
coordinates are transformed into local horizontal coordinates and comparised whether the
GRB zenith angle is smaller than 70$^\circ$; in the case that moon is
shining in the sky, we propose to reduce this zenith limith to 60$^\circ$;
\item {\bf position of moon}, checking whether the angular
distance from the GRB to the moon is at least 30$^\circ$.
\end{itemize}

If one or more of these conditions failed then {\it gspot}
enters into a {\bf Yellow Alarm State}. It means that the GRB is not observable
at the moment. Currently the program do not calculate if and when the GRB will
become observable at La Palma.
If all conditions mentioned above are satisfied,
{\it gspot} enters into a {\bf Red Alarm State}, which means that
the GRB is considered to be observable at the current time.\\

In both cases (in RED and YELLOW alarm state) {\it gspot} assamble the communication
with the CC and sends the GRB equatorial coordinates (RA/DEC J2000).
For the communication to CC the format defined in \cite{CONTROL} is used. In the same time
the shifters and the GRB-MAGIC group is contacted in different ways described in the next sessions.

\subsection{The interface to the Central Control}

An interface of {\it gspot} sends all the relevant informations about it's status to {\it arehucas}.
In the case of {\bf NO Alarm State} the standard packages, containing the main global status
of the two subsystems, are continuosly excanged between CC and {\it gspot}.
In the alert case {\it gspot} starts to send to CC special alert packages,
containg major informations of the GRB and on the ''colour'' of the alert.
The exchange of the alert packages continues untill the following steps occur:

\begin{itemize}
\item {\it gspot} get from {\it arehucas} the confirmation
that it recived the alert notice; {\it arehucas} must send the alert back in order to
to perform a crosscheck of the relevant data;
\item the alarm state expire after {\bf 5 hours}.
\end{itemize}

At the moment {\it arehucas} informs the shift crew about the alern and undergo
further steps only in case of red alerts. In this case a pop-up window
appears with all the alert information recived by the burst monitor.
The operator has to confirm the notice by closing the pop-up window.
He can decide to stop the current scheduled observation and to point the GRB.
A new button in the CC will be displayed and allows to point the the telescope to
the GRB coordinates by pushing it.

\subsection{GRB archive and emails to the GRB-mailing list}

In case of an alert, even if it did not contain the necessary coordinates, the
informations are translated into ''human language'' and stored into ASCII files.
In the same time an e-mail is send to the MAGIC GRB-mailing list.

\subsection{The GRB web page}

The status of the GRB Alert System and relevant informations from the last
alert are displayed on a seperate web page. The page is hosted on the web server in La Palma.
The address is the following:\\

\qquad \qquad http://www.magic.iac.es/site/grbm/\\

The web page automatically updates itself every 10 seconds. In this way
the status of the Burst Alarm System can be checked from everywere.

\subsection{The acoustic alert}

A further CC-indipendent acoustic alarm called {\it phava} 
(~PHonetic Alarm for Valued Alerts~) will be installed
in La Palma very soon. It will provide a loud acoustic signal
even if {\it arehucas} is switched off, so that people in the counting house
will be noticed about the alert situation. The signal will be on as long as
{\it gspot} stays in alarm state, and in any case for a minimum of 1 minute.
This device will keep also a display where to fast check the status
of the system and of the alert.

\subsection{Alerts recived untill now}

Since July, 15th 2004 {\it gspot} has been working stable.
It recived from HETE-2 and INTEGRAL about 100 alerts, most of them without coordinates.
More precisely only 20 of them contained GRB's coordinates. Time delays
were in most cases very large - in the order of of several minutes or even
tens of minutes. In the beginning the Burst Monitor contained some bugs so that we can not
rely on the alerts untill November last year. Since the bugs were fixed we got only one red alert.
This alert came from INTEGRAL with a delay of 71 seconds, it happened
on December 19th at 1:44 am and the GRB zenith angle was $\sim 60^\circ$. Pitty that the weather
conditions were very bad durnig this night.


\subsection{Tasks to be arranged}

The Burst Alarm System is currently able to provide the minimum
features needed to point and to observe a GRB. Anyway several
things must be defined in order to improve our efficiency
to point and observe GRBs.

\begin{itemize}
\item {\bf Yellow Alarm strategy}
First of all the strategy to follow in case of a yellow
alarm, i.e. in case of a not observable GRB, is not defined yet.
In such a case the CC does not undertake any steps,
except confirming the alarm notice to the Burst Monitor. We do not
calculate if and when the GRB will become observable.
It would make sense to check if during the period of 5 hours we could point to the burst.
Then the Alarm System would change to {\bf Red Alarm State} 
at that time and allow the observation.

\item {\bf sequence of alerts}
Another procedure that needs to be defined is how to deal with new alerts
that are distributed during the time that {\it gspot} stands
in alarm state. The status of the system now is that {\it gspot}
locks its alert status untill it exits
the alarm state. This feature was implemented in order not to
loose GRB informations due to nasty events. 
Such situation can appear ONLY when the CC is switched off so
that it cannot recive the alert. Indeed such situation can
occour when more than one alert happens in the late afternoon or
in the 5 hours before the beginning of the night-shift.
In such a case we propose
to implement into {\it gspot} a list in which every
item is a GRB's alert that expires after: 

\begin{itemize}
\item having been noticed to the CC;
\item the canonical 5 hours.
\end{itemize}

If more than one alert is present in the list then the program
gives a mark to the GRB based on the total time of observability
within the canonical 5 hours, on the intensity of the
burst itself and on the time to wait to get the GRB observable.
Such a mark should reflect our estimation in the chances that
we have to observe that GRB.
The GRB with the highest mark will be noticed to the Central Control.

\end{itemize}