Next: Further desirable features
Up: Online processing of the
Previous: Sequence of program execution
Contents
The time at which a given astronomical signal was received by
the GMRT is a fundamental parameter. At the GMRT we attempt to stamp the
data with an accuracy of better than sec. This time
resolution is very good given our baseline lengths and operating
frequencies.
A complex algorithm is followed to keep the time information
to within sec accuracy. As stated earlier time information is
collected from three sources, (i) the Host Computer Clock (usually called
the `PC Clock'), (ii) the GPS minute pulse and (iii) the STA pulse.
All these sources could possibly be in error. Below we describe in
more detail the time information available.
- The most basic source of time is the data itself. Recall that the
low level program, `data collector', reads the PC time at the end of
every 16 KB of data that is received from the MAC. This time information
is available to `acq' along with every block of data. The
`data collector' has no knowledge about where in the data a new STA cycle
begins because it simply collects the data coming at an uniform rate
as a continuous stream. `acq' figures out the beginning of the STA cycle,
by looking for the synchronizing bit in the data (see above). Once
the synchronizing bit is found `acq' can use the time-stamping of each
data block to associate a PC time to the beginning of the data block
of a given STA cycle.
- The GPS minute pulse is provided to the Host Computer as an
interrupting pulse. The `interrupt server' reads the PC time at this
event and maintains a list of the last several such times. `acq'
goes through this list, looking for a set of contiguous events
for which the interval between successive events is the same to
within sec. Once it finds such a set, it uses their
time of arrivals to establishes a linear equation between IST and
the PC time. This equation (which is communicated to all programs
which require to know the exact time) is used to go back and forth
between IST (which is essentially what is required for astronomical
purposes) and the PC clock, (which is what is readily available to
all programs). The linear equation accounts for an offset as well
as a constant drift between the PC time and IST. The equation is
continuously updated using the latest ``good'' GPS pulses, so
higher order drifts are also taken care off.
- At the start of a new STA cycle a synchronizing pulse is sent to
all the components of the correlator as well as the host computer.
This pulse is picked up by the `interrupt server' which maintains a
list of the time of arrivals of the last several such pulses and
provides it to `acq' on request. As discussed above, this same
information is acquired also from the synchronization bit in the
data. This redundancy allows for a consistency check to be made.
The STA interrupts are used for two purposes (i) to make this
redundancy check, and (ii) to set up a linear equation between the
STA pulse time of arrivals and the PC time. Once this equation has
been set up, a sequence number can be assigned to any given STA pulse
based on its time of arrival.
There are several possible sources of error in the time
keeping, viz.
- It is possible that the system (OS) may be busy when a given
event (say GPS or STA pulse arrival) took place, and by the time it
registers this event and notes down the PC time an unknown delay
has occurred.
- The basic unit of scheduling for the OS is a unit called
one CLOCK TICK (10ms), and occasionally the OS makes an error of exactly
one CLOCK TICK. This error is the simplest to detect and correct
for.
- Sometimes, (mainly because of hardware glitches), an expected
event does not take place, or there a number of spurious events.
The fundamental assumption that is used in correcting for these
errors is that the GPS cycles, STA cycles, and the STA coded in data
are all driven by external agents, therefore, even if there is a
momentary glitch, sanity will prevail again after a while. Similarly
drifts in the time of arrivals are expected to be slow and not
discontinuous. The only discontinuous event that could occur is the
missing of one CLOCK TICK, but since this leads to an error with a
well determined signature (a jump in time by exactly one CLOCK TICK),
it is very easily recognized. In practice this sort of error rarely
occurs. `acq' uses a number of complex heuristics as well as continuous
redundancy checks to interpolate short term hardware glitches and
experience has shown that it is quite robust to short term glitches.
While ignoring short term glitches, `acq' should nonetheless track
slow drifts of the PC time. To do this, after every 16 STA cycles it
makes an attempt to arrive at a new equation between the STA sequence
number and PC time. This equation is not accepted unless it is found to
be matching within 100 microseconds of the previous equation. Similarly,
every minute when a new GPS pulse is received, an attempt is made to
arrive at a new equation.
Sometimes `acq' cannot update its equations for more than a threshold
time interval (because the updated equations are very different from
the existing equations). This indicates that a much more serious
problem has occurred. Generally what has happened at this point is that
the PC time has jumped. `acq' then attempts to reestablish equations
afresh from a reasonably long sequence of good time intervals for STA and
GPS. For example, it is demanded that a contiguous set of 4 GPS pulses
must be within 100 microseconds of error, before the IST equation is
accepted. Since `acq' is starting afresh, the deviation from the
previous equation is not checked as it would normally be. Similarly
for the STA equation it requires that least half of 64 intervals in a
stretch of 64 STA cycles must be good before deriving a fresh STA
equation. When the PC time jumps a time accuracy of less than sec
is not guaranteed for the time interval between the jump and the time
when a new set of equations are established. However, there are a limited
number of environmental factors which cause the PC time to jump. These
are known and are avoided during observations.
Next: Further desirable features
Up: Online processing of the
Previous: Sequence of program execution
Contents
NCRA-TIFR