This is an old revision of the document!
Please read the Overview Page for information on the observations, start and stop times etc. The google calendar on the schedules page describes experiment and shift times.
The AUSTRAL schedules are named A13nn
where (nn = 01, 02, 03, … , 15)
. Interleaved with these are regular IVS sessions R1614, CRF79 and R4615. There is only a 5 minute gap between AUSTRAL observations, just enough time to change schedule files and modules (if needed). Every three days, an hour is set aside for detailed checks at each site. They are staggered so that only one antenna is out of the array at a time. Check times for AuScope sites are as follows:
Site | Check time (UT) | Check time (Hobart) |
---|---|---|
Hb | 01.00 - 02.00 | 12.00 - 13.00 |
Ke | 02.00 - 03.00 | 13.00 - 14.00 |
Yg | 04.00 - 05.00 | 15.00 - 16.00 |
We are using 16 TB modules at each AuScope station. They will hold two days of data each, so module changes will occur at every second schedule change. The schedule files are written such that the same source is observed at the same sidereal time every day, so the actual schedule changes are NOT at the same UT every time. Note also that R1614, CRF79 and R4615 will go on different modules to the AUSTRALs. Please refer to the Module Usage Spreadsheet for a list of which modules to use for which experiments.
The sections below describe how operations differ from normal. Note that it will be possible to monitor the Hart 15m antenna and possibly Warkworth as well.
All schedule files for the period from A1301 to A1315 should already be prepared and ready to use before your shift. However, if you are starting R1614, CRF79 or R4615, you will need to make the usual schedule file preparations.
Please carry out the regular two-hourly checks as normal during the observations.
There is only a 5 minute gap between the AUSTRAL schedules. When no module swap is required, the last line of each schedule will be a command to start the next one (unless the next one is not an AUSTRAL experiment) so it should happen automatically. However, if a module change is required, the changeover should be done by hand. Here's what to do, and as an example, here is the swap from A1302 to A1303 at Hobart. All commands can go in eRemoteCtrl:
log=station
mk5=bank_set=inc
You should see on the camera that the red activity light changes from one module to the next.
ready_disk mk5=vsn?
If it doesn't, then the VSN will need setting:
,#1
section so that you start the schedule on the first line, e.g. schedule=a1303hb,#1
Once the new schedule has started:
Note that the observatory checking procedure requires you to interrupt the schedule and miss some scans. This allows us to skip checks if necessary but also means if the checks take less than the allocated hour we can be observing again as soon as possible.
Firstly, check the schedule summary printout and find out which is the first scan to finish after the start of the check period. The idea is to stop the schedule while no data are being recorded. For example, if the check time is 19:00 UT, then in the schedule below, it could be halted after 19:05:45 UT but before 19:07:43 UT:
Start Start Stop Record Scan Line# Source Az El Cable Record Data Data Dur Gbyte date = 2013NOV21 DOY = 325 . . . 325-1854 140 1610-771 170 6 CCW 18:53:58 18:54:08 18:58:33 4:25 35.0 * 325-1859 159 1255-316 119 19 CCW 18:59:02 18:59:12 19:05:45 6:33 43.8 * 325-1907a 178 0131-522 218 7 CCW 19:07:43 19:07:53 19:20:57 13:04 56.7 * . . .
Now, wait for the scan gap, and then type:
halt
Now make a note in the log that the schedule is being stopped for system checks. e.g.
"Halting schedule for system checks
We want to keep all the check data in a separate log, so open a log file called “check.log”:
log=check
At this point it's probably worth verifying that the recorder has stopped:
mk5=dot?
If the response includes the text FHG_off
then the recorder is off. However, if you see FHG_on
then you're still recording, so stop the recorder with
disk_record=off
If not running already, Start MONICA and choose the pre-set aust_check
profile from the GUI for the antenna. e.g. for hobart
Navigator -> hb -> aust_check
This will plot antenna coordinates, tracking errors and motor currents against time.
Now the checks can begin:
test1
flagr/antenna,acquired
or watch the system monitor display). While you're waiting, Check the generator status: iread
You will see what the current Conditioning module settings are. Output format is:
<time>/<Module label>/<IF input number>,<Auto or Manual gain control>,<Nyquist filter number>,<Target power level>,<attenuation>,<actual power level>
Check there’s agreement with what appears in the ifdsx
definition in the procedure file. The actual power level should agree pretty well with the target level. The attenuation number can be anywhere between 0 (none) and 63 (maximum). If you see it at 0 or 63, it means the Conditioning module is having trouble getting the power to the right level. You may want to adjust the attenuators (see configuring the RF and IF signal paths) to get them back in range.
bread
You will see what the DBBC has set the BBC freqs to (compare with the .prc file). Output looks like this:
<time>/<bbc name>/<Frequency (MHz)>/<Conditioning module in use>,<Bandwidth (MHz)>,...
the Frequency, Conditioning module label and bandwidth should agree with the listing in dbbcsxd
.
clkoff maserdelay
and check the difference reported in the log monitor
systemp12
flagr/antenna,acquired
before continuing to the next</note>: test1 test2 test3 test4 test5 test1
These commands send the antenna to the following set of (Az, El) coordinates in turn : (1, 87), (1, 6), (1, 45), (-269, 45), (269, 45), (1,87). The idea here is to exercise the antenna and log the results se we can look for any changes over the days that may indicate mechanical problems.
a1308hb_check.txt
a1308hb_check.png
Now you can re-start the schedule. Just use the schedule name without any line number suffix. e.g.
schedule=a1308hb
This will start the next scan that occurs at least 5 min in the future. Check that the antenna goes to the next source in the schedule that satisfies this criterion.
Now make a note in the log that the schedule has been restarted following system checks. e.g.
"Schedule resumed following system checks
Also, if there were any problems during the checks or anything else of note, now is a good time to do it. For example, if the weather was too cloudy to verify the pointing:
"Pointing check not successful, probably due to bad weather
The usual startup procedure can now be done: Starting and Monitoring
On 1921-293 every day. Procedure?