| by | Lucyna Kedziora-Chudzer |
| Michael Murphy | |
| Jill Rathborne | |
| Jung-Kyu Lee |
Last updated 28/08/02
A copy of this manual is placed in the control room, although even that is probably not the latest version. The latest version can be accessed (and downloaded) from the following web sites:
| UNSW: | http://newt.phys.unsw.edu.au/astro/mopra |
| ATNF: | http://www.narrabri.atnf.csiro.au/mopra/mopra_home.html |
The person in charge of the UNSW mm observing program is Lucyna Kedziora-Chudczer (). Contact her if you have any equiries about mm observations at Mopra. If you have any suggestions for this manual contact Cormac Purcell ().
Smoke Detectors: The local smoke detector in the Lounge/Kitchen area is really sensitive. Even burning toast sets it off. Don't panic, just open the doors and windows. The main smoke detectors in the kitchen are usually deactivated when people are on site.
Alarm Pendant: If you are working alone, wear the white `work-alone' alarm pendant and press the button in an emergency. There is one hanging on the fire alarm in the Control Room and there is a spare one in the drawer of the PC desk in the office (see Figure 2.1). This alarm, equivalent to the 'HELP' alarm on the phones will be picked up by the nearby hospital, and a doctor 'on-call'. There are two phones with the `help' button, one in the control room and one in the kitchen. There is also a dial box with 'help' button placed in the lower vertex room of the antenna (fig 1.1).
| |
Telephones: To redirect a phone call from where it is ringing to where you are, just pick up the handset and press No. 1 twice. To call out of the ATNF internal directory, dial ``0'' before your phone number.
Water: At Mopra, all water supply comes from rainwater tanks. It is probably the cleanest water you're likely to come across any time soon. Do not waste it. Keep this in mind when washing up or going for a ``long, hot shower'' on those cold and frosty mornings.
Food: Please don't eat any of the food in the Lounge/Kitchen area that
isn't yours - it might well be someone's last morsel.
| Mopra | Control Room | 6849 1801 |
| Office | 6849 1806 | |
| Office (Fax) | 6849 1888 | |
| Kitchen | 6849 1803 | |
| Pedestal Room | 6849 1807 | |
| Vertex Room | 6849 1808 | |
| Lucyna | Office | (02) 9385 5470 |
| Mobile | 0425 228614 | |
| Narrabri | Duty Person on call | (see control room whiteboard) |
| Narrabri | Control Room | 6790 4033 |
| Robina | Home | 6842 2615 |
| Mobile | 0146 14 951 |
 |
There are two types of mushrooms: one to stop the antenna from moving and one to disable turret rotation.
You should depress a mushroom on your way onto the antenna so that you don't get killed while there in case someone decides to move the telescope when you don't want them to. If you go back to the control room and try to move the antenna and nothing happens (except a beep), then it is most likely that a mushroom is depressed somewhere - go and find it and give it a lift. Also, camon or MAPS (see Figure 2.1) in the Correlator room will tell you if a mushroom is active. A list of the mushrooms is available in the safety manual (red folder in control room).
There are also lights on the antenna which you should turn on at night should you be climbing on it. Don't leave them on though! There are optical telescopes (and astronomers, eeyyywww!) up the hill and they need their precious night-time darkness.
 |
Some other useful commands, which display system status:
> show hw > show sv > show cowhere `hw' stands for hardware, `sv' for servo and `co' are coordinates, and stop will obviously stop the antenna. Note that all ACC-commands are 4-letter words. The use of other 4-letter words in the Control room is at the discretion of the support astronomer.
 |
Although the turret rotation is done within a_test you can't believe the information
on page 5 as to the current receiver on axis (``Rec stat''). This gives the
value ``KQ'' (which is the mm reciever) even when it is not on axis. To check
which receiver is on axis, the best thing to do is go up to the vertex room
and actually look. If you are too lazy to do this, then you can check the /turret
page in camon. Turret position 2 is the mm receiver (position 3 is the ``CX''
receiver which is often used by VLBI observers). If this is indeed the receiver
on axis, then the status should read ``TRUE'' (``FALS'' for those not on axis).
If you find that the mm receiver is not an axis then you need to move the turret,
make absolutely 100% sure there is no one on the telescope before doing this!.
In a_test type;
> receiver `KQ'
> turret
This should swivel the turret and you should see the values in camon change
within a minute. If it doesn't then wait another few minutes and ONLY THEN go
and check. Make 100% sure that you depress as many mushrooms as cross your path
on the way to checking the turret. Remember that MUM always said mushrooms were
good for you!
The important rule is that the observers are not allowed to touch the manual control of the turret unless specifically instructed by the AT person to do so. Also the antenna gate must be left open when someone is above the pedestal level, so the antenna drives are disabled. This ensures that the antenna cannot be accidently driven when there is someone in the vertex room.
 |
The ``loc'' (specifying local control) light should always be lit. It is very important to check that the subreflector is in the correct position. The number displayed on this panel should be checked and changed if necessary every time receiver is changed. There is a table of subreflector position numbers for each frequency in the control room (on the small whiteboard). The current setting for the 3mm observations is 11.3. To change the position of the subreflector, make sure that the step rate is set at `half' and the `enable' button has been pressed. Choose whether you want to move the subreflector `up' or `down' and then you need to simply hit the `run' button until you are at the desired position number. Remember to turn `enable' off when finished.
Below the subreflector drive controls is the pedestal room power supply readout. You may need to check the voltages and amperages if something goes wrong.
This is the big grey box in front and to the right of you as you enter the room, marked with the big ``DANGER'' sticker. This is a high voltage area (550V DC). Under no circumstances open this box. This box contains many fuses for various antenna control systems. These fuses can be exchanged by a qualified electrician only!
If there is a problem with the UPS then MAPS (see Chapter 4) will show a warning: either a primary or secondary failure will occur. In both circumstances it is best to call the support person at Narrabri (see Table 1.1). A secondary failure usually indicates that the UPS is beginning to run out of power. A primary fault indicates that the UPS is just about to go down. If you get a secondary warning, it is likely that the generator has not come on - try to start the generator and call a support person. If you get a primary failure, call a support person quickly - your main aim is to get power to the cryogenics.
The platform contains the compressors (labeled COMP1 & COMP2) for the cryogenic systems. If MAPS issues a warning, then it may be necessary to come up to the platform to check they are still working. It is very important to make sure that the cryogenics are working, especially if it looks like the power might go down (i.e. during a storm). To see if the compressors are still working, look and listen. Listen: if you try talking out loud with your head really close to one of the compressors and you can't hear yourself then you know that that particular compressor is working. Look: there are four pressure gauges. A Narrabri technician might ask you to read those values in an emergency.
In addition there are also the manual stowing drives on this level, used to stow the antenna in bad weather if the normal drives have failed. These are not often used. If you think you might have to use the manual stow drive then ring someone first (if you haven't already done so) - there is something wrong with the drives and it is better to get that sorted out quickly after stowing.
 |
The turret is situated in this room. Note that this room has two halves - the detectors are mounted on top of the turret, while the electronics for them are mounted below. The central piece on both these levels rotates when the turret is moving. Under no circumstances should there be anyone in either half of the Vertex room when the turret is being moved remotely. It can also be done manually with a great deal of care. The Turret Control Panel is attached on your left as you enter the Vertex Room (Figure 2.5). If the manual option is used to move the turret, then it is best to either keep the switch at manual or keep the door on the lower (Pedestal Room) level open. This will prevent the computer from moving the turret back to the previous position when the switch is returned to the automatic position. The turret moves very quickly when controlled remotely. You don't want this to happen while you are in either Vertex Room!
There are three things that need to be checked in this room, depending on the type of observing that is required (either mm or VLBI).
 |
 |
For VLBI there is a cable labelled with ``VSOP RX WILTRON to CC17''. For mm observations there is a triangular box with two outputs. These are labelled ``TONE GENERATOR'' and ``MARCONI 2GHz CONVERSION'' and are fixed to the triangular shaped box. This should be inserted into the RF output for mm observations.
After changing these cables and before moving the turret, make sure that there are no free hanging cables that could get in the way when the turret is moved. Always check the pointing after the turret has been moved.
This chapter does not need that much detail as you will become very familiar with the control room in a very short time. The general layout and names of the computers in the control room are shown in Figure 3.1. Here is a description of each computer and its function. Note that most of these computers have a specific use and so using them for other more general things (eg. surfing the internet ... I mean, writing papers) is not recommended. We provide a list of useful directories for each computer in Table 3.1.1.
 |
Remote logins to 'OBSERVER' account on MOPRA are not supported from other machines, so it is a good idea to request your personal account on MOPRA. This can be done by contacting Robin Wark at rwark@atnf.csiro.au. However MOPRA has a very limited number of licenced logins. Therefore it is advisable to create a MOPRA DECterm on any other ATNF machine in a following way, which does not require keeping remote link open. If you are next to MOPRA console, open a new DECterm and type in it:
set DISPLAY/create/node=warrum/transport=tcpip
create/term=decterm/detach
The above commands will create Mopra DECterm on warrum. You should substitute this name with a name of a computer where you want the display to be created. When the window shows up on your computer, you should close the DECterm in which you typed the above commands.
If you are physically separated from the Mopra console, you can rlogin to Mopra from any ATNF machine provided you have your own account (`OBSERVER' will not work). Next you should type the above two commands, and after the DECterm is created on your machine, make sure that you log out from MOPRA. This will not affect the DECterm you have just created. In fact you can create more DECterms by typing the mentioned above commands in your new DECterm window. This new windows do not act as remote logins, and the other potential users of MOPRA will thank you for being considerate.
ssh, rsh, slogin, rlogin and telnet are all available along with the usual host of general programs (i.e. netscape, ghostview etc.). spc is also available for quick-look data reduction (see Chapter 7). There is generally not much space on MINOS so don't go downloading large files or transferring much data there. Note that the /c/observer disk is cross-mounted on WARRUM and MINOS.
MINOS has the CD-writer mounted, which is used for data archiving. The instructions how to use it are written above the MINOS monitor (also see Chap.8).
Both WARRUM and MINOS have the a2ps facility and printing ASCII files from MOPRA can be done with the command LPTOPS filename.
There is an important computer which is relevant to operations in the control room which is not kept in the control room itself.
| Computer | Directory | Description |
| Mopra | mopra$dkb100:[obs.rpfits] | Data storage area |
| obs$0:[multi.sched] | Schedule files | |
| obs$0:[multi.point] | Pointing summary files | |
| obs$:[point.skydip] | Skydip results and summary files | |
| obs$:[point.run] | Skydip postscript files | |
| obs$:[point.work] | Preferred to run Skydip | |
| Warrum | /data/WARRUM_1 & WARRUM_2 | Small data disks |
| ~ /data | Soft link to mopra data area | |
| /c/observer | Observer home area | |
| /c/observer/CAT | Object catalogues | |
| MINOS | ~ /data | Soft link to mopra data area |
| currently not working | ||
| /c/observer | Observer home area | |
| MPCCC | /data/MPCCC_1/corr/dat | Data storage area |
 |
 |
 |
 |
 |
The following describes the complete startup procedure for the computer systems. Is is worth doing this at least a couple of times so that you understand how the various systems talk to each other. You might need to redo only small sections of the startup procedure during your observing run when the connections to various system go down or become confused. It is cruical when doing this that the various commands are executed in the correct order.
| Log onto MOPRA (WARRUM and MMDRIVE should already be booted) | |
| In a MOPRA DECterm execute the following commands and give appropriate answers: | |
| sda | starts the array program; should start automatically |
| camon | this should automatically begin when you log on |
| cain | make sure integration time is 10 s (or whatever you intended, |
| otherwise you have to set it within the program); must report ``Success'' for all | |
| antennae, if not try again | |
| mmlo_setup | check reports and if there is some problem, try again |
| mmdrive | check reports ® tune receivers on MMDRIVE |
| MMDRIVE PC | start up tuning program on PC if it is not running already |
| In another DECterm on MOPRA execute the following: | |
| a_test | necessary to change atten and pointing offsets |
| to check the initial values, use camon pages /mopra and /pp | |
| assistance | |
| On three separate MPCCC terminals (create on WARRUM) execute the following; | |
| mpcor | the mpcor GUI should pop up |
| spd | the pgplot window will pop up |
| cd /data/MPCCC_1/corr/dat (for checking progress of data) | |
| On another MOPRA DECterm run; | |
| tcs | Make sure it connects successfully with the mpcor GUI |
| On a WARRUM xterm run; | |
| tcs | Open the GUI in expert mode |
There are two different ways to call the DECterm windows to run the tasks described below. Several of these have links set up under the Session Manager so that you may start them by simply selecting the task from a list. This will bring up a DECterm window in which the task has been automatically started. There are several tasks for which these are not set up, in these cases you will need to bring up a normal MOPRA DECterm window and start the task yourself. Since you will have several DECterm windows displayed as you set up, not all being needed at the same time, you may want to label and iconize them. You can do this under `Options' by choosing `Window' and changing `Window Title' and `Icon Title'. It is best to do this as you bring each of the windows up.
If you find necessary to open one of the Mopra DECterms on the console of another computer (eg. Warrum), you should create a new DECterm on Mopra and type in it:
set display/create/node=warrum/transport=tcpip
create/term=decterm/detach
It is also useful to know a few commands in camon to help you diagnose problems later on:
Usually, you will choose option ``3'' since you will want one channel (channel B) to be at the SiO maser frequency and the other channel (Channel A) to be at your source frequency. However, for brevity, we will pretend you have chosen option ``1'' - both channels at the same frequency. The questions asked otherwise will be similar. Choose ``n'' for the Doppler shift correction (the Telescope Control System ( tcs) will handle this later) and choose your bandwidth, say 64 MHz. All of these options can be changed later in tcs so don't panic if you choose the wrong ones. It is best to first get on a bright source and get a signal before the user wants to start observing. Do some pointing exercises (see Section 5.5) or something to build up your confidence in the system.
Occasionally you may find that the attenuation levels are too low or too high.
The GTP values and associated sampler statistics are highlighted in camon.
You can adjust the attenuators to some level by going into a_test and selecting
page 4 in this program
> 4
Next you should specify the level of fine attenuation:
> fine '4343'
To activate the change type:
> atten
This action sets attenuators on channel A to 4, and on channel B to 3. Two other
numbers are not relevant to Mopra. (They were inherited together with this software
from the ATCA.) This should (after several seconds) change the attenuation and
GTP values displayed in the camon page. More information about attenuation and
GTP values can be found in Appendix G.1.
Open an xterm on WARRUM, set the xhost to include MPCCC (xhost +mpccc) and
ssh to MPCCC:
> ssh -l corr mpccc
The password will be given to you by the support astronomer. Then set the display
to the WARRUM screen using
> setenv DISPLAY warrum:0.0
Once this is done you should then open two xterms from the MPCCC window:
> xterm &
In one of these MPCCC xterms you can open communication with the Mopra correlators
by typing
> mpcor
Several things should happen when you do this. Several windows will open up
but will immediately iconize themselves. Most importantly, the mpcor GUI will
pop up. The GUI displays information about the configuration of the correlator
(i.e. bandpass, number of channels etc.), integration cycle, name of the current
data file and diagnostic information about the correlator activity. It is handy
during observations for changing the configuration file and for checking whether
or not a file is open. A snapshot of the mpcor GUI is shown in Figure 4.1.
There are a few programs running in the background when you start mpcor. If the mpcor crashes for some reason, these programs have to be killed, to be able to restart the correlator. The detailed procedure is described in the Appendix B.
 |
In another of your MPCCC xterms type
> spd
to begin the spectra display software with a pgplot window.
The commands below are the ones you will need to ...
| > select 1 2 | View both polarizations |
| > a | View the amplitude of the signal |
| > a y1 y2 | Change the display range of y-axis |
| > save | Save a reference signal |
| > d -10 80 | View the difference between the source signal and the reference signal |
| (and set the plot range to -10 to 80) | |
| > x | change the x-label to channel number from frequency |
| > chan x1 x2 | change the display range of channel number |
You will get very used to using the tcs but Table 4.2 summarizes the main features. This table also serves as a quick-look guide to those things you might have to change when setting up for an observation. Chapter 5 has more details on observing with tcs.
| OBSERVATION ID | These fields are reasonably self explanatory. |
| ANTENNA CONTROL | |
| Source name | Find a standard source either from the Standard or Own source. |
| file or by typing the coordinates in. | |
| Duration | The value of this parameter is just an arbitrarily large integer, |
| usually 500. | |
| CORRELATOR | |
| Configuration | Check that this is consistent with the LOCAL OSCILLATOR |
| configuration. | |
| Averaging | Number of cycles averaged to save in a file. |
| LOCAL OSCILLATOR | Set the bandwidth, and number of channels you want |
| (consistent with the configuration file). Also type | |
| in the desired frequencies for channel A and B. | |
| ACTION PANEL | |
| Sched | Load the relevant schedule file. |
| Repeat | This is the number of times the schedule file is |
| repeated per integration. | |
| SYSTEM STATUS | |
| Antenna | Clicking on this button allows you to disable the antenna |
| (select ``disable'') at which point if the antenna is stowed you can | |
| continue to ``track' (i.e. data will be coming in) if you need to check | |
| anything in the vertex room for instance. |
 |
| |
It is also a VERY GOOD IDEA to make a copy of the relevant pages of the log book for your own use when reducing data. moplog can be used to make electronic copies which tend to be harder to lose.
See also Appendix D about Logs.
Tuning on any other frequency is somewhat of a black art - try not to leave any torn shreds of hair lying about. The basic idea is to maximize (i.e. least negative) the power reading on the power meter on top of the CRO while keeping maximum side band rejection. But this won't mean much until you've tried it out.
When weather is good, the paddle in/out gives 2 - 2.5 dB difference in power reading for Channel A and ~ 3.5 dB for Channel B. If not, tuning needs refinement.
Table 5.1 shows some information for each configuration.
| # Channels | |||
| Bandwidth /MHz | 256 | 512 | 1024 |
| 64 | nbits = `4444' | nbits = `4444' | nbits = `4444' |
| Dv=0.75 kms-1 | Dv=0.38 kms-1 | Dv=0.19 kms-1 | |
| 128 | nbits = `2222' | nbits = `2222' | nbits = `2222' |
| Dv=1.5 kms-1 | Dv=0.75 kms-1 | Dv=0.38 kms-1 | |
| 256 | nbits = `1111' | nbits = `1111' | nbits = `1111' |
| Dv=3.0 kms-1 | Dv=1.5 kms-1 | Dv=0.75 kms-1 |
If you pointing source is very strong, you can save some time by trimming number of intergration cycles in each scan. The pointing schedule: point_sio.sch uses 5 cycles, while point_test3 uses only 3 cycles. Three cycles seems to be a reliable minimum number.
At this point it is important to check that both the channels of the local oscillator are active and that the frequency of Channel A is correct (e.g. at 115.2 GHz for the CO line) and Channel B is at 86.243 GHz (SiO maser frequency).
moput <filename>
on the MPCCC window. (We hope to avoid this step in the near future.)
In the same DEC term (MOPRA) that you usually run a_test in, type
$ sio_point
to run the pointing test analysis program.
You will be asked to give an input filename, enter the file name of the
most current run through the pointing test. sio_point will then show
you a plot of the 5 spectra and give you the pointing offsets in azimuth
(dfx) and elevation (dfz). You can either < accept > ,
< recompute > or < quit > them. Type `accept' to accept them, or just
hit < CR > to quit. For the former, fx and fz change accordingly,
which you should check in the camon window to make sure these values
are corrected since it sometimes fails to do so. When this happens, or you
simply want to do it yourself, go to a_test (page 2) and type the
following:
$ fx -154
$ fz -72
$ setp
Check the camon window here as well to make sure these values are
correct. No correction is needed for fx or fz if the offsets are < 5".
Keep these values in the log together with the time, azimuth and elevation
of your measurement..
When these adjustments have been made you may want to re-run the pointing schedule file (steps 4-6 above) to check if the model worked. If there are more adjustments made, remember to add these new pointing corrections into the pointing log. This process should be repeated until you are happy with the pointing, that is, when the offsets are small and the first spectra displayed (i.e. the on-source position) has a large emission, compared with the emission in the offset frames, all of which should be approximately the same.
To save the output spectra of sio_point as a postscript file, run it
again and choose the device /ps for a postscript in landscape mode, or /vps
for portrait mode.
$ laser < filename.ps >
will send it to the printer (or ftp it to WARRUM or MINOS and psnup it!
- see Appendix E).
Some schedule files now include a ``mm_tsys'' command at the beginning. For those that don't, or if you just want to measure the Tsys then type ``mm_tsys'' in the tcs GUI control command window (at the bottom). This automatically calculates the system temperature by adjusting the attenuators and putting the paddle in or out. The whole procedure takes about 2 minutes to complete, so you may choose to calculate the so-called Y-factor instead, and to convert it to the system temperature next. Remember to record the system temperature in the log book. More details about the atmospheric calibration are provided in Appendix G.
The system temperature should be measured every 1.5-2 hours, and perhaps more often if observing at lower elevations or in unstable weather.
> source `Jupiter'
> scan
within this progrm. You should not have the TCS running while using POINT. GTPs are logged in GTPLOGGER in AT$LOG on Mopra (this log has values for each integration cycle). You can also read GTPs off the `camon' page.
GTPoff/(GTPon-GTPoff)=Tsysoff/Tantenna
we can calculate Tantenna. Tsysoff is taken from the skydip at the planet's elevation. Next we need to find out the temperature of the planet. The program written by Mike Kesteven calculates the temperature of the planet given its size during the observations and translate it to Jy.
Assume that the brightness of a planet is 600 Jy. The efficiency of the antenna is defined as 600/Tantenna (Jy/K).
Be sure to note all necessary information in the log. Failing this, get the observers to do it. Just looking over the format of the log will allow you to formulate a rough observing technique. See Appendix D for log information.
Observers are requested to notify the ATNF staff of any problems which cannot be solved by the observer or the UNSW support astronomer. This should be done by placing a fault report at http://www.narrabri.atnf.csiro.au/feedback .
To average all the scans in filename.rpf and to fit a baseline to the
resultant, you can use an expectk script written by Ramesh called
spect. It is best to copy the spect script from /c/observer/bin
to your current working directory and execute it from there (or just make a
soft link using ``ln -s /c/observer/bin/spect''). Then execute by typing
> spect
This will bring up the spect GUI (see Figure 7.1). At the
moment, spect is a little fragile, so you must do things in a very
regimented manner. The orange message box should guide you through the
steps but here is a little summary of what to do in a typical case:
 |
The first step to managing data is to BE CAREFUL. Never (and I mean NEVER) have the data in just one place. Always have a copy of it somewhere. This raises the question of knowing what storage media you have at your disposal. At Mopra there are currently the following options:
You also should be aware of how large the data sets are in relation to these sizes. On a typical day's observing, ~ 100 M of data can be pulled in. However, if you are doing mapping or other long integrations then a day of data can quite easily fill up the space on WARRUM's data disks. The following things should be done a few times per day:
Remember to label your tapes immediately after they are written!
CD writer is installed at the PC, MINOS, which uses Linux as the operating system. In order to create a CD of your data, you need to:
The MPCCC_1 disk is visible from MINOS pc.
The data can be found in /DATA/MPCCC_1/corr/dat and should be tar-ed and compressed for the backup and archiving.
First one needs to log in remotely to the MPCCC computer as 'corr' user. This can be done from WARRUM workstation, or MINOS. By the way MINOS has MPCCC data disks cross-mounted, and the data can be archived or copied directly from MINOS.
(However you need to remember that you are not allowed to write to this disk if logged in to MINOS. This means you will not be able to store your tar files on the same disk. To do it you need to be logged in to the MPCCC.)
In the directory: /data/MPCCC_1/corr/dat on MPCCC you need to create the separate tar files containing the data collected during each day of observing. For example to tar all the data from the 30th of July 2002, one has to type:
ls 2002-07-30*
(to check for the presence of the data). Next type:
tar cvf 2002-07-30.tar 2002-07-30*
gzip 2002-07-30.tar
to create and compress the tar file. All newly created *.tar.gz files should be ftp-ed to /DATA/WARRUM_2/UNSW_2002*. In addition the CD of these data should be created according to the procedure described in the previous section. The list of data files should be attached to the CD cover. The list can be created in the following way:
ls -l /DATA/MPCCC_1/corr/dat/2002-07-30*rpf > list
ls -l /DATA/MPCCC_1/corr/dat/2002-07-31*rpf >> list
etc.
Needs update! The file below is saved at /c/observer/ramesh/CAT/ as ``cat.SiO_SEST''. You can browse it from TCS GUI.
If the generators do not come on then this is a potential disaster
for receiver cooling! UPS batteries only lasts for 2-3 hours. Call someone
immediately and ask what to do. Above all, do not panic - it is not your
fault that something has gone wrong but a cool head will be needed to fix
it if that is possible. Your main concern is getting power to the
cryogenics systems.
The most common reasons for the alarm are that there have been too many
lightning strikes nearby or that the wind speed is too high. In these two
cases, the sounding of the alarm by MAPS will coincide with automatic
stowing of the antenna - check to see if this is happening (note that the ``auto
stow'' will only stow the antenna in elevation, not azimuth as you may expect - this is
ok). Check the ``Opto isolated alarms'' panel on MAPS in the correlator room to see if the
wind speed or lightning strike frequency has set off the alarm. If this is
the case then wait until the antenna has stowed and then press the black
``Reset MAP Alarm'' button on the ``Control from Narrabri'' panel on
MAPS. You can restart the system (when weather is better) from tcs
but first check that all systems still have control of the antenna (this can be done
by checking the ACC - ``show hw'' will display the state of the drives and if you have
reset the alarm all four should be ``ready: YES''. If they are ``NO'', then you need
to hit the reset button on maps. Note that the elevation drive will probably have ``Drive
OFF'' due to the stow, whereas for Azimuth, the drive will be ``ON'' - this is ok and as it
should be).
If the alarm went off due to lightning strikes then the generator has
probably come on (check this by typing ``/maps'' in the camon
window). However, just resetting the MAPS alarm does not turn the generator
off. Go to a spare DEC term on MOPRA and type ``generator''. This will
bring up a simple program. 'Stop' the generator there. If this doesn't work
then go to the GCU panel on MAPS in the correlator room. Press the ``SEL''
button to select ``Loc''al control. The drive button is a toggle switch -
try pressing it to see if this turns the generator off. If none of these
work then call on-call person.
If the alarm is going off for some other reason then try to identify the
problem on the MAPS panel. If you can figure out how to fix it then great,
tell us about it. If you can't then call someone to help.
If the alarm sounded due to a high temperature then you need to call the on-call person.
This may indicate that the air conditioning unit is faulty or the compressor outside has
stopped (this is the one closest to the control room door, near the water tanks and when
running should be noisy with a fan blowing). The Correlator room should remain below 25
degrees. The alarm is set to sound when it reaches approx 23 deg (there are over temperature
settings on the wall near the H maser). If the temperature reaches 29 degrees, the Mopra VAX
will shut down. It is highly recommended not to let the temperature get to this level!
If this looks like happening, then you should open the back window (be aware of rain!) and
the doors to the control room. At this point hopefully you have been in contact with someone
from Narrabri. They will probably tell you (if the temperature is dangerously high and
not decreasing) to turn off the correlators. There are 6 white switches on the back, 4 of which
need to be turned off (there will be 4 on and 2 off). The correlators produce about 2/3
degrees extra heat in the room, so turning them off should hopefully start to cool things
off.
This happened once so far, and the cause was traced to the crashing of an
invisible background process called `array' which runs communications between the VAX and
the Antenna Control Computer (ACC). 'Array' was restarted remotely by
Robin. However you can restart it yourself after exiting TCS and all other active processes.
In a MOPRA DECterm enter a command: sda
This is a task which starts 'array' program.
This usually would occur at the same time or shortly after a
mopra dead - old timestamp error message, this is caused also by ``array'' going
down for some reason. It should stop within a couple of cycles, by which stage
``Big Brother'' at Mopra has restarted it and you can try ``mmlo_setup'' again.
If this doesn't work then contact Robin.
Close monitoring of this is no longer needed. Robin has a batch job running that
automatically sends her an e-mail if space on the VAX is running out. She will contact you
if necessary. To check the disk space, you need to type;
$ show dev/m
List of the SiO Pointing Sources (Epoch 2000.0)
***********************************************
(calculated for year 1995.80)
R_And 00:24:02.00 +38:34:38.5 J2000
WX_Psc 01:06:26.01 +12:35:52.8 J2000
o_Ceti 02:19:20.72 -02:58:36.8 J2000 +46.0
SVS_00878 02:37:23.62 -26:58:38.9 J2000
R_Hor 02:53:52.81 -49:53:23.4 J2000
IK_Tau 03:53:28.7 +11:24:22.7 J2000 +33.7
U_Men 04:09:35.71 -81:51:18.1 J2000
R_Dor 04:36:45.7 -62:04:37.4 J2000 +4.0
SVS_01835 04:57:01.75 -84:16:05.8 J2000
T_Lep 05:04:50.83 -21:54:16.6 J2000
U_Dor 05:10:08.78 -64:19:05.4 J2000
S_Pic 05:10:57.24 -48:30:26.0 J2000
R_Oct 05:26:06.74 -86:23:18.8 J2000
Orion_SiO 05:35:14.5 -05:22:29.6 J2000 +5.0
U_Ori 05:55:49.12 +20:10:36.5 J2000
GX_Mon 06:52:46.93 +08:25:21.1 J2000
L2_Pup 07:13:32.31 -44:38:24.1 J2000
SVS_03513 07:17:05.68 -34:49:39.0 J2000
VY_CMa 07:22:58.1 -25:46:01.8 J2000 +24.0
SVS_03731 07:46:34.20 -32:18:16.6 J2000
R_Cnc 08:16:33.81 +11:43:34.2 J2000
RW_Vel 09:20:19.57 -49:31:27.2 J2000
R_Car 09:32:14.48 -62:47:19.7 J2000
R_LMi 09:45:34:10 +34:30:43.9 J2000
R_Leo 09:47:33.5 +11:25:43.8 J2000 +0.0
V_Ant 10:21:09:12 -34:47:19.3 J2000
R_Crt 11:00:33.98 -18:19:28.5 J2000
X_Cen 11:49:11.85 -41:45:28.0 J2000
RT_Vir 13:02:38.00 +05:11:08.3 J2000
W_Hya 13:49:02.1 -28:22:02.8 J2000 +40.0
RX_Boo 14:24:11.62 +25:42:13.3 J2000
S_CrB 15:21:23.94 +31:22:03.3 J2000
IRSV1540 15:44:39.90 -54:23:04.4 J2000 -82.0
R_Ser 15:50:41.71 +15:08:01.2 J2000
U_Her 16:25:47.52 +18:53:32.8 J2000
AH_Sco 17:11:16.9 -32:19:32.4 J2000 +0.0
V2108_Oph 17:14:19.37 +08:56:02.5 J2000
OH2.6-0.4 17:53:18.92 -26:56:37.1 J2000
VX_Sgr 18:08:04.1 -22:13:25.6 J2000 +4.0
SS_Tel 18:32:18.48 -56:37:00.4 J2000
V1111_Oph 18:37:19.38 +10:25:41.4 J2000
X_Oph 18:38:21.14 +08:50:02.1 J2000
R_Aql 19:06:22.19 +08:13:47.4 J2000
RT_Aql 19:38:01.60 +11:43:18.5 J2000
GY_Aql 19:50:06.35 -07:36:52.8 J2000
Chi_Cyg 19:50:33.9 +32:54:51.6 J2000 +11.0
S_Pav 19:55:13.90 -59:11:43.7 J2000
RR_Aql 19:57:36.16 -01:53:10.5 J2000
X_Pav 20:11:46.03 -59:56:12.7 J2000
R_Peg 23:06:39.20 +10:32:35.9 J2000
W_Peg 23:19:50.51 +26:16:43.8 J2000
R_Aqr 23:43:49.45 -15:17:04.3 J2000
Appendix B
The following is an FAQ-style guide to trouble shooting. It is simply a
collection of problems that have occurred (or are known to occur) and their
solutions. If you have any additions to this list then we would be glad to
add them here - they will be useful for someone sometime we're sure.
Remember that a more general table of problems is given in the Safety
manual.
Trouble Shooting
B.1 Emergency lights in Control Room/Office switch on
This is a reasonably common problem but it can have many causes. The first
thing is to check MAPS: type ``/maps'' at your camon window on
MOPRA. This will bring up a list of diagnostics about the power systems
etc. Check the `Power source', `Power status' and `Generator mode'. If they
read `mains', `okay' and `remote' respectively then you're OK (yay!) - it
was just a power glitch. The emergency lights should go off in a few
minutes. If the MAPS diagnostics reads anything else then call the person on-call
straight away (the on-call roster and phone numbers are displayed next to
the white board in the control room) and let them know what is going on.
Hopefully, the generators
will come on in a few minutes and then you are OK as well. Just stow the
telescope if it is bad weather. If good weather then keep observing and
keep an eye on the MAPS diagnostics to see if the mains power comes back
on. If it doesn't then call that special someone again and ask them what to
do. Short power-outs (lasting up to about 30 mins) are quite frequent at
SSO and Mopra.
B.2 High pitched alarm
There can be many reasons for this. The first thing to do is to turn off
the alarm. Go to MAPS in the correlator room and hit the red button on the
alarm module (rack B, front row). This merely silences the alarm - it does
not reset it.
B.3 Not-so-high-pitched alarm
If this comes from a machine (labeled DB1-21 and named Atlas) behind the door
to the Correlator Room, see if humidity warning is on. If that is the case,
just press `Alarm Mute' button on the right.
B.4 Communication to telescope is lost (1) - ``array_timeout'' at
cain
When starting up, cain will sometimes return an ``array_timeout''
error (instead of the heart-warming ``success'' reply). This can usually
be cured by simply running cain again. But if the problem persists
one possible cause is the VAX running out of space. The solution is to make
space by deleting something, OR shutting down and rebooting the VAX (see
below).
B.5 Communication to telescope is lost (2) - Error messages at
`mmlo_setup'
If error messages below are issued at `mmlo_setup', there is nothing much
you can do but contact Robin Wark at Narrabri.
Problems in LO_set_switch Problems in LO_set_lo Problems in LO_set_bits
B.6 Shutting down and Rebooting the VAX
Shutting down the VAX is a way to cure the troubles above, however it is an
operation that should not be undertaken without good cause, or without knowing
what you are doing. But also it could happen because of power failure. When
the VAX comes back up it often forgets that it has a cross-mounted drive with
the Unix machines, and nothing much will work. For example an attempt to
mmlo_setup will generate.
%DCL-W-ACTIMAGE, error activating image MMDRIVE_GL
%DCL-W-ACTIMAGE, error activating image MMDRIVE_GL
-CLI-E-IMGNAME, image file MOPRA$DKB0:[AT.GL_COMMON]MMDRIVE_GBLSEC.EXE;58
-CLI-E-IMGNAME, image file MOPRA$DKB0:[AT.GL_COMMON]MMDRIVE_GBLSEC.EXE;58
-SYSTEM-F-NOTINSTALL, writable shareable images must be installed
-SYSTEM-F-NOTINSTALL, writable shareable images must be installed
The solution to this can be found (but very well hidden!) in a VLBI note in
the yellow MUGS folder. To bring the disk back on line, the following DCL
commands have to be issued. Namely...
$ cmsd mmdrive
$ set proc/priv=all
$ make_mmdrive_gblsec
** not sure you need to do these....??
B.7 Low diskspace on VAX
B.8 a_test failure
a_test often fails to operate when it is `locked' by another user -
i.e. another a_test is running. Go to the Session Manager on Mopra
(the toolbar running upper right corner of the monitor) and open `Work in
Progress' from the pulldown menu under `Session'. There must be more than
one a_test running. Choose one of the a_test jobs, and kill
it by clicking `Stop Task' from there.
B.9 Reset Correlator Requested on TCS GUI or controller
Go to the Correlator Room, and press four reset buttons on the
correlators (back row) - one each on Rack C and D (above floppy disk
drivers), and two on Rack E, red `Reset' button and the reset button on PC
below, which is marked 'mpducc'.
B.10 Observing after a VLBI run: things to check
There are several important things changed when going between VLBI and mm observations.
VLBI runs occur every so often during our mm observations with the change over happening
fairly quickly and without incident. Robina usually handles these observations and makes all
the necessary changes of the electronics etc in the vertex room (a list of these is given in
the section 2.6). In a nutshell:
There are however two things that you should check after these
changes have occurred;
If all the frequencies are the same and in the correct units, then the problem might be caused by a DC offset related to a timing difference between the antenna and the correlator. At this point you should also check the delay counts on the mpcor GUI. If the numbers in the first rows of the ``1A'' and ``1B'' columns are the same (or close to) the total number of delay counts at the bottom, then this also points to a timing error. The first thing to do is try a ``settime'' in the tcs gui ``control command'' window (you may need to wait a few cycles for the new data to come in). If this hasn't solved the problem then you may need to re-initialise the integration clocks with ``cain''.
This problem may originate because we are using a strange integration time (12s). One possible way to get around this is to set the cycle start time to a multiple of 12 (i.e. 14:49:12.00). This needs to be done in ``expert'' mode in ``cain''. Firstly type ``e'', ``y'' and then ``c'' to change the integration parameters, then ``n'' and then the values you want (you can probably keep the defaults for all but the last one). Then proceed with initialisation. You may want to rerun cain (selecting just the ``i'' option) to make sure this has been initialised and so that you can check the ``Antenna success'' display.
If the presets of your chosen frequency (and sideband) are not working or there are none available then try selecting a nearby frequency which does have working presets. You might have to tweak the Gunn Frequency a little (not more than ±0.3) to get a phase lock on your dummy frequency. Even if you don't get phase lock, just select you initial frequency again and tweak the Gunn Frequency to see if you can get a lock. If this doesn't work then try another nearby frequency, perhaps one on the other side of your initial frequency.
If this doesn't work either then try tuning on any old frequency which has working presets until you get a lock. Then move back to your frequency again and try getting a lock with those settings.
If the peak is visible on the screen, but just not in the centre, then simply move the gunn bias up/down to get the lock (when moving these drives, it is best to move them to values higher than what you think it might be, then slowly bring the values down). Note that the ``sweep'' needs to be off for this to take effect. Check the lock when by flipping the ``sweep'' and adjust accordingly if it moves from the centre.
If this fails to get phase lock, or the peak isn't on the display, then you might want to fiddle with the gunn frequency slightly. If you move this to a higher value, then back down you may find a peak will appear on the display. Use the gunn bias then to move the peak to the centre, turning the sweep on and off to check the phase lock once you think you have it.
If, when you turn the sweep on, you see a square wave pattern running across the display when trying to check the phase lock, then you have locked on the wrong sideband (i.e. the opposite to what you have selected). Turn the sweep switch off and move the gunn bias to a higher value (this should move the peak to the left). If you keep doing this you should see another peak come onto the display moving to the right (i.e. in the opposite direction to the original peak). Keep adjusting the gunn bias until this peak is in the centre. This should now give you phase lock when you turn the sweep switch on and off. Just to double check move the peak to the right (past the centre) and then move it back to the centre. This should now be phase locked.
Once you have phase lock, the first thing to do is check the rejection. Select ``Hop'' on the Spectrum Analyser Input and the turn the SB tones on. This should give you two peaks on the display ``hoping'' on and off (one at a time). For frequencies set to the upper side band, we want the peak on the right to be bigger than the one on the left by about 1-1.5 divisions. This corresponds to 10-15 dB rejection. If you have Ch B set to Ch A, then you need to check the rejection for both channels (don't worry about this for SiO pointing). Ch B should have a similar rejection to Ch A, and the same sideband. If the rejection is not that great then simply change the Tuner value until you are happy (Ch A uses Tuner 2 for rejection and Ch B uses Tuner 1 for rejection!).
The second thing to check is the ``Y-factor''. This represents the amount of power going through the channels. If you hit the ``Rel'' on the power meter (with the paddle out), putting the paddle in should then give you about a 3dB change (this will vary with frequency-higher frequencies give lower power). If this value is low (say less than 2), you can increase it by fiddling with the values on the ``SIS MIXER BIAS'' window. Firstly you need to get back to the ``absolute'' mode (as opposed to ``rel'') on the power meter. You can do this by hitting ``shift'' then ``rel''. Adjust the ``Vi set'' knob firstly to maximize the power. You can also adjust the ``LO LEVEL'' know to increase the power. After doing this check the ``Y-factor'' again and hopefully it will have improved. If you are still not happy then you can also adjust the Tuner value (Ch A uses Tuner 1 for power and Ch B uses Tuner 2).
> local local control
> dron to turn the drives on
> droff to turn the drives off
> remote back to remote control
This will basically reset the drives. The telescope should now move if you ask it to!
For a typical observation:
Local Date
ST, LT and UT
Configuration file (eg. AC_64_1024_2)
Observer name (or your's)
Source name
File name - most importantly
Az and El
RA and DEC if not a standard source
fx and fz and their corrections, faddx and faddz,
when doing a pointing
VLSR if not a standard source
Comments (on the whether, things that are always in the header such as
integration time, etc.).
There is a sample log sheet on the next page. You might like to photocopy this page and use it as a log sheet or you might like to print out a few copies (photocopying is cheaper than printing). There should already be a few photocopies in the front of the log book. It is available as a gzipped ps file on WARRUM: /c/observer/mim/log/master_log.ps.gz. Just ``gunzip master_log.ps.gz'' and then ``lpr master_log.ps'' and then ``gzip master_log.ps'' to print it out. If you do use this observers log sheet then STAPLE ALL OF THEM INTO THE LOG BOOK AT THE END OF YOUR RUN (and after you have photocopied them for yourself).
|
Below we refer to the two outputs of moplog: 1) The log data table (moplog.tab by default): This is an ASCII table containing all the log information entered by the user. 2) The latex log file: This is a latex formatted file generated by moplog from the log data table. It can be latex'd to produce hardcopies of you log file.
Make sure that when you start a new log file that you DO NOT OVERWRITE YOUR OLD LOG FILES. Rename them to something convenient. You need not worry too much about the log.tex or log.ps files since they can be produced from the corresonding log data file upon running moplog again. So it is imperative to BACKUP THE LOG DATA FILES before starting a new log.
Type moplog at a WARRUM or MINOS prompt to begin:
> moplog
- > Log filename (existing or to-be-created)? [moplog.tab]:
If you want to start a new log (for example, at the beginning of each day during a run) then type the name you want the log data table to have. If you already have an existing data file (in the correct format) then type its name at the prompt. Carriage return (CR) accepts the default (moplog.tab).
New log
- > a - Add new line
- > q - Quit
- > Select letter [a]:
At this point you may either quit the program or add the first line to the log data file (default - hit CR)
- > Local date [dd/mm/yy]: (12 Characters)
Enter the local date. The format indicated by the default is not rigid.
- > LT-UT [1100]: (integer, 4 digits)
Enter the difference between the local time and the universal time.
- > Config file(s) [1:AC_64_1024_2,2:AC_64_1024_2F]: ( < 51 characters)
Enter the configuration files to be used during the observations. A good practice is to number them for reference in the comments section for each integration.
- > Observer [UNSW: mim]: (20 Characters)
Observer names (and institutions).
That completes the header information for the log. The next series of questions relate to a specific integration. They are in a specific order designed to mimic that order that the information comes in in.
Object [Object Name]: (12 Characters)
Schedule file [12characters]: (as it says, 12 Characters)
fx [-213.00]: (sign, 3 digits before and 2 after the decimal point)
fz [-10.30]: (sign, 2 digits before and 2 after the decimal point)
Tsys(A) [200.0]: (2 digits before and 1 after the decimal point)
Tsys(B) [180.0]: (dito)
ST [1000]: (4 digit integer)
RPF file [yy-mm-dd_utme]: (as the default suggests)
AZ [314]: (3 digit integer)
EL [45]: (2 digit integer)
fx(add) [-110.00]: (sign, 3 digits before and 2 after the decimal point)
fz(add) [-110.00]: (dito)
Comment < 40 characters [Conf. #, line, weather, quality etc.etc.]: (as
it suggests).
In the comments, you might like to give the configuration file (by refering to the number you gave it at the start of the file), the line you are observing (or the frequency you are using), a comment on the weather during the integration, the quality of the spectra obtained etc. etc.
The program then gives a summary of the line you just entered. You now have an exisiting log data file and are returned to a menu. See below for the next step.
Existing log
You will first be given a summary of the last 5 lines of the log data file, each indexed with a number.
- > Summary of last 5 lines:
- > ST Object RPF file Comment
- > 1:1000 Object Name yy-mm-dd_utme Conf. #, line, weather etc.
- > 2:1000 Object Name yy-mm-dd_utme Conf. #, line, weather etc.
- > 3:1000 Object Name yy-mm-dd_utme Conf. #, line, weather etc.
- > 4:1000 Object Name yy-mm-dd_utme Conf. #, line, weather etc.
- > 5:1000 Object Name yy-mm-dd_utme Conf. #, line, weather etc.
and then the following options:
- > a - Add new line
- > e - Edit a line
- > w - Write a new log.tex file
- > q - Quit
- > Select letter [a]:
If you choose to add a new line in the log data file then you will be
asked
- > Select default index (from summary above) [ 5]:
A CR will allow you to answer a series of questions (listed in the previous section) for the integration you are doing. The 5th entry in the list above will be used to assign default values for each of these questions. This allows for fast use and cuts down on the amount of typing you need to do.
If you choose to edit a line then you will be asked to enter which line you want to edit (from the list above). The existing line will be used to assign the defaults to the various questions which ensue.
If you select "w" then the latex file log.tex will be generated containing the present contents of the log data file. Instructions will also be given on how to latex the log.tex file so that a landscape postscipt sheet can be produced: the file has to be ftp-ed to MINOS. On MINOS type: latex log dvips -t landscape log lpr log.ps
Known problems with moplog
To ftp to MOPRA from WARRUM or MINOS, simply type
> ftp mopra (surprise, surprise)
> login: observer
> password: (you know the rules)
ftping data:
> bin
> cd mopra$dkb100:[obs.rpfits]
> get filename.rpf
Obtaining Skydip summary, results and postscript plot:
> asc
> cd obs$:[point.skydip]
> mget skydip.res skydip.summary (for the latest skydip results)
> cd obs$:[point.run]
> get pgplot.ps (or whatever you called the file while doing a ``run
skydip'')
Obtaining Pointing summary:
> asc
> cd obs$0:[multi.point]
> mget 00-07-13*.summary (to get all pointing summaries from UT day 13/7/00)
Placing a schedule file in the right place:
> asc
> cd obs$0:[multi.sched]
> put schedulefilename.shed
PSNUP is a very useful program when trying to avoid using heaps of paper.
> psnup -2 -l filename.ps temp.ps
That's a little ``L'' not a ``1''. This command places two postscript pages
from filename.ps into one page of temp.ps. Then you can print using
``lpr'' from WARRUM and MINOS.
We measure several things when we take on source and reference
``exposures'':
| (F.1) |
| TRX | is the Receiver Temperature (an additive constant) |
| t | is the optical depth of the atmosphere |
| TA | is the Temperature of the Atmosphere (assumed to be equal to the paddle temperature) |
| Ts | is the Temperature of the source and |
| C | is the Gain or Scalefactor. |
| (F.2) |
We also measure
| GTPon | = GTP with the paddle in, and |
| GTPoff | = GTP with the paddle out. |
so that
| (F.3) |
Hence, we have
| (F.4) |
| (F.5) |
With SKYDIP, we measure R=C[TRX+TA(1-e-t)]
where we can express the optical depth as
| (F.6) |
So, if we can make an estimate (guess/assume?) of TScat ( ~ 20 K) and with TA ~ 280-290 K, we can then obtain TSys.
If the GTP is higher than 2V it is possible to decrease it by increasing
the attenuation (if it is too low, then simply decrease the
attenuation). This can be done from a new DEC-term window by typing
$ a_test
followed by a return. This will give you a display showing the status of
the correlator, including values of the current attenuation (page 4). The
attenuation can be changed using either the fine or coarse attenuation
adjustments. 1 step is equivalent to a 2dB change when using the fine
adjustment, while 1 step in coarse adjustment mode is equivalent to a 6dB
change. To change the attenuation using the fine adjustment type
$ fine `5454'
This will change the attenuation to 5 in channel A and to 4 in channel B.
The change may take a few seconds to come up on the screen, after which the
numbers that you just changed will be in bold font.
To activate the change you need to type
$ atten
This may also take a few seconds, but the numbers should return to normal
font and the GTP decrease or increase depending on whether you increased or
decreased the attenuation. The new attenuation values should be displayed
at the bottom of the camon page.
If GTP doesn't come out right with fine tuning
you can try `Coarse attenuation' by typing
$ co `02'
followed by
$ atten
to activate it.
To begin this, you firstly need to quit out of the tcs on WARRUM
(ONLY EXIT THE GUI, not the GUI and controller!). This then causes
connection to be lost to the correlator. To regain connection hit
``Update'' in the mpcor GUI.to reset all the values in the
correlator. In a new DECterm type
> point
followed by a < CR > . This will begin the pointing task, for which skydip
is a subprocess (note: the command `help' here will give you a list of
commands). Type
> skydip
to begin the task. Wait a few second while the program checks make a change
to the attenuator values (so that the GTP doesn't saturate when Mopra goes
to low elevations and has the paddle in). Then hit < CR > . Mopra will then
drive to an elevation of 85 degrees.
Before continuing, it is important to check the GTP. If the skydip program has not changed the fine attenuator values to `7777' then do so now in the a_test window. When you are satisfied the GTP is okay, hit < CR > in the skydip window (i.e. confirm that you have `Checked the dataset level'). The skydip task will then begin, taking about 15 minutes to complete.
When the measurements are completed, the task will display two plots of Tsys against elevation, one for channel A and the other for channel B. Type `exit' when you have finished looking at these.
The results and summary files of the output of this task are stored in
OBS$0:[point.skydip] and called skydip.res and skydip.summary.
Check that you are in the directory OBS$0:[point.work] and then
type,
> run skydip
You can run older version of this program from OBS$0:[point.run]
if necessary.
This will begin the analysis of the skydip measurements. There will then be
several questions that need to be answered. We want to look at the receiver
temperature, so it is recommended to select,
> 3 to `fix' receiver temperature
> 75 100 as the receiver temperature,
then use the default file name (skydip.res) and the default device
(/xs). This will then produce the two plots again, which can be saved as a
postscript file by repeating the above procedure, with the device set as
/ps instead, creating a file called `pgplot.ps' (or if you wish to specify
the file name directly so that it doesn't get overwritten, set the device
as filename.ps/ps). This can then be printed out and ftped to
WARRUM (see Appendix E). For printing, it is best to put
these two plots onto the same page. To do this, first copy the file to a
temp.ps file, then type,
> psnup -2 -l filename.ps temp.ps
For theoretical calculations of atmospheric effects, refer to Maria Hunt's
notes, either see Appendix C.5, or the web at
.
See Appendix C.5 for tips on calibrating your data during reduction.
1If the changes to the GTP are being made when the
paddle is being put into the system, a rise of 2.5V should be expected in
the GTP when this is to occur. Hence, the value of the GTP should be made
sufficiently small so this increase doesn't go above the `safe' level.
