Changeset 6098 for trunk/MagicSoft/GRB-Proposal

Timestamp:

01/28/05 18:08:30 (20 years ago)

Author:

gaug

Message:

*** empty log message ***

Location:

trunk/MagicSoft/GRB-Proposal

Files:

• Requirements.tex (modified) (1 diff)
• Strategies.tex (modified) (2 diffs)

trunk/MagicSoft/GRB-Proposal/Requirements.tex

@@ -1 @@
-\section{Requirements to start the full GRB Observations}
+\section{Requirements to start full GRB observations}
 
-\subsection{Status now}
-\subsection{What is still missing:}
+In the previous sessions we described the status and tasks we still plan to do
+in order to complete the GRB Alarm System.
+Parallel to our system also the different subsystems of the MAGIC telescope have
+to implement and test strategies for the GRB survay.
 
-\ldots {\bf Communication AMC-CC } \ldots
+\par
 
-\ldots {\bf Fast slewing } \ldots
+We strongly push the responsibles of the drive-, camera-, amc- and central
+control subsystemsto fullfill the criteria defined in~\cite{design}. We suggest
+to make a one week shift wherethe experts meet together and test the GRB
+stategies. In order to avoid good observation timewe suggest to make the shift
+during the moon period. This shift should take place, in arrangementwith the
+different subsystem responsibles, before april this year. The time limitation is
+based onthe moment when SWIFT will start to work fully automaticly, sending
+allerts in real time to the groundstations.
+\par
 
-\ldots {\bf Test GRB Monitor } \ldots
-\ldots {\bf Test fast telescope movement} \ldots
-\ldots {\bf Simulation with fake alerts to ...CRAB???...} \ldots
+We present a list of tasks that are very crucial for the GRB survay:
 
+\par
+
+\begin{itemize}
+\item {\bf Fast slewing:}\
+
+One of the most important issues is to implement and test the fast movements
+of the telescope. Specially the communication between CC and Cosy has to be arranged for
+the case of fast movements.
+
+\item {\bf Use of look-up tables:}\
+
+The use of look-up tables to correct the mirror focus during the movement to the GRB
+coordinates is advantegous. In the alert situation it is a vaste of time if we would have to
+close the camera lids and carry out the full laser adjustment (\~5~min) before starting the observation.
+The reproducibility of the focus with the use of look-up tables has to be proven.
+In order to use the time during the telescope movement for the focussing of the mirrors to the desired
+telescope positon, the AMC needs the coordinates immediately. In this case it is necessary to change the protocol between the AMC and CC.
+
+\item {\bf Behaviour of the camera during moon:}\
+
+It has to be checked what happens when during the pointing to a GRB position the telescope move over the
+moon. It is excluded by the GRB Alert System that a burst closer than 30$\deg$ to the moon will be pointed. However it is not prevented that during the movement of the telescope the moon will pass the FOV.
+In this case the HV of the PMTs will be reduced automatically and will not increase fast enought for the
+GRB observation.
+
+\end{itemize}
+
+\par
+
+All this issues have to be checked during the suggested shift. The aim would be to send fake allerts to
+the GRB Alarm System and proove the behaviour of all subsystems.
+
+

trunk/MagicSoft/GRB-Proposal/Strategies.tex

@@ -47 +47 @@
 to implement a new feature into the Steering System wich
 follow a different path while selwing must be considered.
-
+\par
+There was a shift observing the Crab-Nebula with half-moon at La Palma in December 2004. 
+The experience was that the nominal High-Voltages could be maintained and gave no 
+currents higher than 2\,$\mu$A. This means that moon-periods can be used for GRB-observations 
+without fundamental modifications except for full-moon periods. We want to stress that 
+these periods increase the chances to catch GRBs by 80\%, even if full-moon observations are excluded 
+\cite{NICOLA}. 
+It is therefore mandatory that the shifters keep the camera in fully operational conditions with high-voltages 
+already switched on from the beginning of a half-moon night until the end. 
+\par
+Because the background is higher with moon-light, we want to decrease then the maximun zenith angle from 
+$\theta^{max} = 70^\circ$ to $\theta^{max} = 65^\circ$. 
 
 \subsection{Calibration }
 
-\ldots {\bf MARKUS gAUG} \ldots
+For ordinary source observation, the calibration is currently performed in the following way: 
+\begin{itemize}
+\item At the beginning of the source observation, a dedicated pedestal run following by a calibration run is 
+taken.
+\item During the data runs, interlaced calibration events are taken with a rate of 50\,Hz.
+\end{itemize}
+
+We would like to continue taking the interlaced calibration events when a GRB
+alert is launched, but leave out the pedestal and calibration run in order not to loose valueable time.
+
+\subsection{Determine the maximum zenith angle}
+
+We determine the maximum zenith angle by requiring that the overwhelming majority of 
+possible GRBs will yield an in principle observable spectrum. 
+
+\begin{figure}
+\centering
+\includegraphics[width=0.99\linewidth]{f4.eps}
+\end{figure}
 
 
@@ -60 +89 @@
 If some significance is seen, observe the same position next night to get some OFF-data.
 
-