This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
operations:documentation.eremotecontrol_checklist_midob [2013/05/02 20:13] Warren Hankey old revision restored |
operations:documentation.eremotecontrol_checklist_midob [2016/11/10 09:35] Bryn Emptage |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Checklist Parameter Descriptions ====== | ====== Checklist Parameter Descriptions ====== | ||
+ | |||
+ | Note: In case of a power outage, you cannot assume that anything is safe! Use the pre-observation checklist. | ||
Below is an explanation of the current list of items to check during an observation: | Below is an explanation of the current list of items to check during an observation: | ||
Line 10: | Line 12: | ||
* **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). The monitoring software will calculate the difference for you and should ring an alarm if the difference is not acceptable. See [[operations:monitoring_hb#clkoff_reading_is_drifting_or_far_from_the_maser-gps_offset|this entry]] in the common Problems section for a remedy. | * **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). The monitoring software will calculate the difference for you and should ring an alarm if the difference is not acceptable. See [[operations:monitoring_hb#clkoff_reading_is_drifting_or_far_from_the_maser-gps_offset|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 via the Applications menu to time[hb|ke|yg]). Green numbers are good, red are bad. Here's an example of how it should look:\\ {{:operations:maserok.jpg?200|}}\\ 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. | * **Time: Maser status OK**\\ Check the "Standard VCH-1005A Manager" display on the Windows PC (to view it, start a VNC session via the Applications menu to time[hb|ke|yg]). Green numbers are good, red are bad. Here's an example of how it should look:\\ {{:operations:maserok.jpg?200|}}\\ 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 eRemoteControl: ''mk5=mode?''. The result should be\\ ''/mk5/!mode? 0 : ext : 0x55555555 : 2 : 2 ;'' for R1 and R4 experiments, (''ext : 0x55555555 : 2 : 1 ;'', for Katherine)\\ ''/mk5/!mode? 0 : ext : 0x55555555 : 4 : 2 ;'' for OHIG, APSG and CRF observations. | + | * **Mark5: mk5=mode? correct**\\ Check mode with this command in eRemoteControl: ''mk5=mode?''. The result should be, ( where the last number represents the number of disk modules loaded, either 1 or 2 ),\\ ''/mk5/!mode? 0 : ext : 0xffffffff : 2 : 2 ;'' for 2nd and 4th R1/R4 experiments each month, \\ ''/mk5/!mode? 0 : ext : 0x55555555 : 2 : 2 ;'' for R1 and R4 experiments, \\ ''/mk5/!mode? 0 : ext : 0x55555555 : 4 : 2 ;'' for OHIG, APSG, T2 (Arwin) and CRF observations\\ ''/mk5/!mode? 0 : ext : 0xffffffff: 1 : 2 ;'' for AOV and AUG experiments (Arwin). \\ ''/mk5/!mode? 0 : ext : 0xffffffff : 1 : 1 ; '' for AUST experiments. \\ More information may be found on [[http://auscope.phys.utas.edu.au/opswiki/doku.php?id=operations:documentation.ivs.mark5mode|the Mark5 mode page]]. |
* **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 econtrol:''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. | * **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 econtrol:''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. | ||
- | * **Mark5: disk_pos OK**\\ The command ''disk_pos'' in eRemoteControl 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. The Log Monitor also reports disk usage | + | * **Mark5: disk_pos OK**\\ Also see [[operations:disk_pos.py]]. The command ''disk_pos'' in eRemoteControl 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. The Log Monitor also reports disk usage. Compare amount of bites recorded with that listed in the summary file (e.g. r4000hb.sum). Snap-file summary is located in /vlbobs/ivs/sched/, and according to current practice, should be open in the favourite text editor on the screen (for all monitored antennas) (don't forget to ssh to ops2 if you're not already there). Feel free to edit and add your comments. |
+ | * If the recording lags the summary file significantly (several 10s of gigabytes and backlog is growing), it might be an [[operations:documentation:pcfs_rfpic|rfpic]] issue. The recording does not start in time because it is waiting for the report from Monica. In this case you shall restart the Rxmon, at it is described in the [[operations:starting_monitoring_9.10.5#rfpic_problem|Other things to watch out for: "rfpic" problem]] | ||
* **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\\ | * **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\\ | ||
* **Meteorology: Sky conditions logged**\\ Make a note in the entry box of present weather conditions like cloud cover and wind e.g. "weather 50% cloud, light winds". | * **Meteorology: Sky conditions logged**\\ Make a note in the entry box of present weather conditions like cloud cover and wind e.g. "weather 50% cloud, light winds". | ||
- | * **Tsys: S-band Tsys OK**\\ Check recent output from a systemp12 command (don't execute it unless the Mark5 is NOT recording) to see if the S-band Tsys is within the expected range (an indication will be given in brackets, but 80 to 100 K is typical). Make a note in the log if it is outside this range. If it persists, or the values vary wildly, there may be a problem. | + | * **Tsys: S-band Tsys OK**\\ Check recent output from a systemp12 command (don't execute it unless the Mark5 is NOT recording) to see if the S-band Tsys is within the expected range (an indication will be given in brackets, but 80 to 100 K is typical). The monit3 window shows the most recent values and [[operations:documentation.test_tsys|here is how to interpret them]]. Note that at Ke, continuous Tsys measurements are made during scans and the monit3 window updates every 30s with these values. However you can obtain a Tsys value at any time at ke with the systemp12 command (see also these notes on [[operations:documentation.contcal|Continuous Calibration]]). Make a note in the log if it is outside this range. If it persists, or the values vary wildly, there may be a problem. |
- | * **Tsys: X-band Tsys OK**\\ Check recent output from a systemp12 command (don't execute it unless the Mark5 is NOT recording) to see if the X-band Tsys is within the expected range (an indication will be given in brackets, but 80 to 100 K is typical). Make a note in the log if it is outside this range. If it persists, or the values vary wildly, there may be a problem. | + | * **Tsys: X-band Tsys OK**\\ Check recent output from a systemp12 command (don't execute it unless the Mark5 is NOT recording) to see if the X-band Tsys is within the expected range (an indication will be given in brackets, but 80 to 100 K is typical). The monit3 window shows the most recent values and [[operations:documentation.test_tsys|here is how to interpret them]]. Note that at Ke, continuous Tsys measurements are made during scans and the monit3 window updates every 30s with these values. However you can obtain a Tsys value at any time at ke with the systemp12 command (see also these notes on [[operations:documentation.contcal|Continuous Calibration]]). Make a note in the log if it is outside this range. If it persists, or the values vary wildly, there may be a problem. |
+ | * **Log Monitor audio check button sounds audible beep**. Make sure you can hear the alarms | ||
+ | * **Skype**. Make sure Skype is running to allow a chat session with all participating sites plus the on-call person | ||
+ | * **System: Check and update [[operations:handover|Handover]] and [[operations:currentissues|Current Issues]] wiki pages** | ||
* **System: Any problems or concerns logged**\\ If there are any other issues or unusual behaviour, report it in the log by typing in the comments box at the end of the dialog. | * **System: Any problems or concerns logged**\\ If there are any other issues or unusual behaviour, report it in the log by typing in the comments box at the end of the dialog. | ||