This is an old revision of the document!
The examples below assume Katherine running v252ai.
If time permits, make a recording test before starting and check the bit stats and autocorrelations (note this won't work from a fringe-checking schedule):
From the Field System:
proc=v252aike setup01 disk_record=on (wait ~10 sec) disk_record=off scan_check postob
Now start the schedule
schedule=v252aike
During the run, make sure that
onsource
and check the antenna is tracking, which it should be provided a new source command hasn't recently been issued.clkoff
and maserdelay
. These values should be within 0.5 microsecond of each other and stable (i.e. similar results if you issue the commands again). The monitoring software will calculate the difference for you and should ring an alarm if the difference is not acceptable. See this entry in the common Problems section for a remedy.mk5=mode?
. The result should be/mk5/!mode? 0 : ext : 0x55555555 : 2 : 2 ;
for R1 and R4 experiments,/mk5/!mode? 0 : ext : 0x55555555 : 4 : 2 ;
for OHIG, APSG and CRF observations.mk5=dot?
. Make sure it reports a small offset (~<10ms) as the final value, that syncerr_eq_0
and that FHG_on
or FHG_off
depending on whether it is currently recording or not.disk_pos
in econtrol should report three values - the current number of btyes recorded, bytes at start of previous scan and bytes at start of current scan. If not currently recording, the first and third values should agree. It is normal for Yarragadee disk_pos
to lag its expected value due to regular stows for USN uplinks.wth
command, which will look like this:\\/#wx#/16.1,1007.9,58.6\\Also make a note in the log of present weather conditions (if you're at the observatory). Start the comment with the word “weather”, e.g. “weather 50% cloud, light winds”. Note that weather is not currently logged at Yarragadee./usr/bin/xterm -name monit2 -e /usr2/fs/bin/monit2
onsource
command from the Field Systemclkoff
and maserdelay
are within 0.3 microseconds of eachotherOne difference from IVS observing is that the postob procedure will also pop up a window listing the bit statistics of the recorded data. The observer should check this regularly to make sure it stays at near to the nominal 18/32/32/18 distribution (±2%).
If monitoring from Mt. Pleasant, use pmSTALMke.sh to monitor the alarms. If you want the station alarms to go off when there’s an error (rather than playing a sound through the speakers), use pmSTALMke.newsmerd.sh. I’d recommend changing the title of the terminal window to make it clear which alarms are from which station
See the Current Issues section for known problems and how to fix them.
See also these notes on