1 Tsys measurements

The most prevalent reason for wrong Tsys estimates being present in ANCAL files is that the ``preob'' Tsys before each scan was measured wildly off-source. This often results in the need for manual editing and copying the ``postob'' after each scan values to replace the plain wrong Tsys values in the ANCAL file.

At present, the only widely accepted way to ensure the on-source status is to make sure that all scheduling packages have a correct estimate of the slewing speed of each antenna. This means that the VLBI friends would have to know the right contact persons to whom they need to announce any changes in their antenna performance.

It is not a practical idea to force the FS to wait until the antenna has reached the source, since this would result in a different tape start times for each individual antenna. Also, a few reference-mapping applications have deliberately started recording when the majority of antennas have reached the source---there is no point in waiting for the slowest one while the majority subnet can already produce good data. However, in these cases start-of-the-scan Tsys figures of all slow antennas will be wrong.

Currently the FS uses the 60dB (MarkIII/IV) or 20dB (VLBA) attenuators to present a ``zero'' IF level to all VCs/BBCs and uses that as the zero level of total power indicators (``tpzero''). 60dB is probably quite safe in this sense, but 20dB is not enough to prevent a strong source from ``coming thru'' with enough level to distort the final Tsys readings, calculated using an artificially high estimate of the internal ``tpzero'' noise level. This results in too optimistic Tsys figures.

There is a fundamental difference between MarkIII/IV VCs and VLBA BBCs, namely MarkIII/IV VCs only have a single one total power indicator whereas VLBA BBCs have two. BBCs can measure total power of both USB and LSB simultaneously but VCs have to be separately switched from USB to LSB and vice versa. Furthermore, the integration period of the TPI of MarkIII/IV VCs is fixed at one second which means one has to wait for at least two seconds after switching the TPI source from USB to LSB or vice versa before reading out the TPI value.

To get a similar set of log lines and Tsys figures of both upper and lower sidebands, we propose that the following strategy be adopted for measuring any ``tpi'', ``tpical'', and ``tpzero'' value, regardless of the rack type:

1. All TPIs of VCs are kept at the USB setting.
2. The TPI values of all VCs/BBCs USB channels only are read in.
3. All TPIs of VCs are switched over to the LSB setting.
4. A two-second delay.
5. The TPI values of all VCs/BBCs LSB channels only are read in.
6. All TPIs of VCs are switched back to the USB setting.
7. A two-second delay (unless this is the last in a series of measurements).

The net result would be that the ``tsysn'' lines in the logs would be in a similar format regardless of the rack type. This would make it easier to generate the ANCAL file automatically using the ``LOG2ANCAL''/``CAP'' package. Also, this would introduce Tsys of LSBs using MarkIII/IV video converters---these are not usually measured at the moment.

To further ease the interpretation of ``tsysn'' lines in the ``CAP'' package it would be beneficial to agree on the order of VC/BBC numbers in which the TPI readouts will appear in the log. There are a few possible alternatives:

1. ``drudg'' will be modified to emit the procedures for measuring Tsys and it will include only those VC/BBC channels which are actually being used in the current mode. This would happen much in the same way ``drudg'' currently emits mode-specific setup SNAP procedures in the schedule procedure file.
2. We will always include all 14 converters in the ``tpxxxx'' log lines. This introduces the problem that if an unnecessary VC/BBC is missing or malfunctioning, we will not get the log line at all. This is probably an oversight in the implementation of ``tpxxxx'' commands in the FS and can be rectified.
3. We will use fixed sets of all BBCs (Mark III mode A), odd-numbered BBCs (Mark III modes B, C, and E), and/or first eight BBCs (all VLBA and most MarkIV modes). SNAP procedures for a limited number of cases can be ``prepackaged'' and selected either manually or by ``drudg'' into the ``.prc'' schedule procedure file.

Practice has shown that most VLBI receivers feature relatively stable gain, i.e.~the gain does not change considerably during the timescales of the order of minutes, the duration of most scans/passes. The same holds for noise diodes and this would allow us to estimate changes in Tsys even during the scans although we cannot fire up the noise diode.

We can linearly interpolate the values of ``tpical-tpi'' and ``tpzero'' in between the start and the end of a given scan. During the scan we can measure additional ``tpi'' values at regular intervals and these will enable us to calculate more accurate estimates for during-the-scan Tsys values. This approach requires that VLBA BBC automatic gain control is disabled and set to manual at the start of each scan, in conjunction with measuring the start-of-scan Tsys value. It is important to let AGC to adjust gain levels just before measuring start-of-scan Tsys, at a time when the antenna is already on source. It needs to be estimated if disabling AGC during one scan will affect 2-bit sampling too much.

Measuring ``tpi'' at regular intervals during the scan can be performed in (at least) the following ways:

1. Using the so-called ``time-scheduled'' SNAP commands. Unfortunately in the current implementation of FS any absolute timed wait will prevent any time-scheduled commands from being executed, i.e~for instance every typical wait in a schedule will prevent any timed commands from executing while the FS is waiting for the absolute wait to expire.
2. Using SNAP procedures with a calculated number of ``tpi'' commands and short waits. There is a danger of accidentally inserting too long a procedure after the ``midob'' of a short scan, unless the extra ``tpi'' commands are inserted automatically by for example ``drudg''.