next up previous contents
Next: Python implementation Up: Observing mode and elapsed Previous: Python implementation   Contents


Frequency cycling observations

In frequency cycling, the tuning frequency is regularly cycled between \bgroup\color{red}\ensuremath{n_\ensuremath{\mathrm{freq}}}\egroup predefined values inside the same receiver RF band. This first imply that the on-source observing time must be split between the different tuning of the frequency cycling. To do this, the user will have to give the percentage of the time required per tuning. The sum of the percentage will have to be equal to 100%. By default, PMS will divide equally the on-source time between the tunings, and the user will have the possibility to modify this time repartition.

Frequency cycling also has two consequences on the observational efficiency.

  1. The time to setup the tunings is increased with respect to standard observations by \bgroup\color{red}$(\ensuremath{n_\ensuremath{\mathrm{freq}}}-1)*\ensuremath{\Delta t_\ensuremath{\mathrm{freq}}}$\egroup, where \bgroup\color{red}\ensuremath{\Delta t_\ensuremath{\mathrm{freq}}}\egroup is typically XXX minutes.
  2. After the setup phase, each cycle observed at a given frequency must be surrounded by gain calibration observations at the same frequency. This means that the observing efficiency is decreased: in practice this is like doubling the number of calibrators, since each calibrator will have to be observed at the 2 frequencies (the frequencies of the previous and of the next cycle, whatever the number of cycles).

    To take this into account, we first define the overhead factor as

    \begin{displaymath}
\ensuremath{\Omega}= \frac{1}{\ensuremath{\eta_\ensuremath{\mathrm{tel}}}}.
\end{displaymath} (38)

    The overheads are now split into generic overheads, independent of the number of gain calibrators, and the calibration overheads that is directly proportional to the number of observed gain calibrators. This gives
    \begin{displaymath}
\ensuremath{\Omega}= \ensuremath{\Omega_\ensuremath{\mathrm...
...aincal}}} \ensuremath{\Omega_\ensuremath{\mathrm{cycling}}}.
\end{displaymath} (39)

    We will use \bgroup\color{red}$\ensuremath{\Omega_\ensuremath{\mathrm{gen}}}= 1.3$\egroup and \bgroup\color{red}$\ensuremath{\Omega_\ensuremath{\mathrm{gaincal}}}= 0.3$\egroup, \bgroup\color{red}$\ensuremath{n_\ensuremath{\mathrm{gaincal}}^\ensuremath{\mathrm{def}}}= 1$\egroup or 2 for detection or imaging, respectively, and \bgroup\color{red}$\ensuremath{\Omega_\ensuremath{\mathrm{cycling}}}= 2$\egroup in frequency cycling mode, 1 otherwise.
  3. The overall overheads are evaluated by computing the total on-source time over the total telescope time:
    \begin{displaymath}
\ensuremath{\Omega_\ensuremath{\mathrm{total}}}= 1-\frac{\e...
...athrm{on}}}}{\ensuremath{\Delta t_\ensuremath{\mathrm{tel}}}}
\end{displaymath} (40)

    In the context of frequency cycling, the overheads for a single frequency are computed by weighting the times with the fraction \bgroup\color{blue}$r_f$\egroup spent on this cycle (e.g. 50% for 1 among 2 frequencies):
    \begin{displaymath}
\ensuremath{\Omega_\ensuremath{\mathrm{total}}}= 1-\frac{\e...
... }{\ensuremath{\Delta t_\ensuremath{\mathrm{tel}}}\times r_f}
\end{displaymath} (41)

    which is identical to the previous formula. If the overheads reach 75%, a warning is raised.

When frequency cycling is combined with dual band observations, it is emphasized that both receiver bands are affected by the efficiency loss of the frequency cycling even though one of the two bands could not require frequency cycling at all.



Subsections
next up previous contents
Next: Python implementation Up: Observing mode and elapsed Previous: Python implementation   Contents
Gildas manager 2024-12-02