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.