Changeset 6125 for trunk/MagicSoft/GRB-Proposal/Requirements.tex

Timestamp:

01/30/05 11:23:12 (20 years ago)

Author:

gaug

Message:

*** empty log message ***

File:

• trunk/MagicSoft/GRB-Proposal/Requirements.tex (modified) (4 diffs)

trunk/MagicSoft/GRB-Proposal/Requirements.tex

@@ -8 +8 @@
 \par
 
-We strongly push the responsible persons of the drive-, camera-, amc- and central
-control subsystems to fulfill the criteria defined in~\cite{design}. We suggest
-to make a one week shift where the experts meet together and test the GRB
+We strongly push the responsible persons of the Drive-, Camera-, AMC- and Central
+Control subsystems to fulfill the criteria defined in~\cite{design}. We suggest
+to make a one week shift where the experts meet and test the GRB
 strategies. In order to avoid good observation time we suggest to make the shift
-during the moon period. This shift should take place, in arrangement with the
+during a moon period. This shift should take place, in arrangement with the
 different subsystem managers, before April this year. The time limitation is
-based on the moment when SWIFT will start to work fully automatically, sending
+based on the moment when SWIFT will start to work fully automatically and send
 alerts in real time to the ground stations.
 \par
 
-We present a list of tasks that are very crucial for the GRB survey:
+We present now a list of tasks which are crucial for the GRB survey:
 
 \par
@@ -25 +25 @@
 \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
+One of the most important issues is to implement and test the fast slewing capability
+of the telescope. Especially the communication between CC and Cosy has still to be implemented for
 the case of fast movements.
 
@@ -32 +32 @@
 
 The use of look-up tables to correct the mirror focus during the movement to the GRB
-coordinates is advantageous. In the alert situation it is a waste of time if we would have to
+coordinates is desirable. In the alert situation it is a waste 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 position, the AMC needs the coordinates immediately. In this case it is necessary to change the protocol between the AMC and CC.
+In case of using lookup-tables during the slewing, 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.
+moon. It is excluded by the GRB Alert System that a burst closer than 30$\deg$ to the moon will be pointed. 
+However, it can happen 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 enough for the
 GRB observation.
@@ -47 +47 @@
 \end{itemize}
 
-\par
-
-All this issues have to be checked during the suggested shift. The aim would be to send fake alerts to
-the GRB Alarm System and proof the behaviour of all subsystems.
-
-