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

Below is an explanation of the current list of items to check during an observation:

• Antenna: drives OK
  Check the antenna status display in the system monitor window for the antenna. If Drive Status is green then all is well.
• Antenna: Time OK (i.e. SNTP server OK)
  Check the Controller Clock status display in the system monitor window for the antenna. If it's green and “OK” then the controller knows the time. If not, the antenna probably doesn't know where its pointing, there's a problem. Check the HMI display on the time[hb|ke|yg] VNC session for more information. If HMI isn't running or you want to restart it here are some notes on Starting HMI.
• Antenna: on source and tracking
  In the field system, type onsource and check the antenna is tracking, which it should be provided a new source command hasn't recently been issued.
• Data: LO Locked
  In the System monitor, in the RF section, check that the LO Status is Locked. If not, no valid data will be recorded.
• Data: Autocorrelations OK
  At the end of every scan, the postob procedure will run a script to extract some Mark5 data and plot the autocorrections and show the bit statistics.
• Time: delays OK, stable and within 1us (clkoff, maserdelay)
  In the eRemoteControl, issue the commands 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). If not, see this entry in the common Problems section for a remedy.
• Time: Maser status OK
  Check the “Standard VCH-1005A Manager” display on the Windows PC (to view it, start a VNC session to time[hb|ke|yg]). Green numbers are good, red are bad. Here's an example of how it should look:
  
  Report any red numbers to Brett ASAP. if you see mention of 'Battery', the maser has lost mains power and is running on it's UPS. If so, tell Brett immediately.
• Mark5: mk5=mode? correct
  Check mode with this command in the field system: mk5=mode?. The result should agree with the procedure file setting in setup01
• Mark5: mk5=dot? response nominal
  This is a check of the Mark5 decoder time. Check the time offset in the formatter with this command in the field system: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. If not, fmset may need to be run.

To do this, open a terminal on pcfs[hb|ke|yg], and type

fmset

When the interface appears, type

s

then confirm with a

y

Following this, the clocks should all be synchronised and agree with UT. Press the [Esc] key to exit fmset. Then check the times again:

mk5=dot?

• Mark5: disk_pos OK
  The command disk_pos in the field system 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.
• Meteorology: Weather (wth) being logged
  Look through recent messages in the field system log for output from the wth command, which will look like this:\\/#wx#/16.1,1007.9,58.6
  
• Systemp readings are nominal (Tsys readings are kludged in. If the experiment is recording a single polarisation both tsysS and tsysX will report whatever that is. For dual pol, tsysS is RCP and tsysX is LCP)
• System: Any problems or concerns logged
  If there are any other issues or unusual behaviour, report it in the log by typing a comment in the field system. All comments should start with double quotes.

One 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