User Tools
operations:documentation.eremotecontrol_checklist_midob
This wiki is not maintained! Do not use this when setting up AuScope experiments!
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
operations:documentation.eremotecontrol_checklist_midob [2015/07/31 00:53] Jamie McCallum |
operations:documentation.eremotecontrol_checklist_midob [2018/03/13 11:14] (current) Patrick Yates |
||
|---|---|---|---|
| Line 12: | 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, ( where the last number represents the number of disk modules loaded, either 1 or 2 ),\\ ''/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/!mode? 0 : ext : 0xffffffff : 1 : 1 ; '' for AUST experiments | + | * **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 AUA, 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. 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. | + | * **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]] | * 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\\ | ||
| + | * If the weather is either not updating, or not returning anything see [[operations:fixwth|this page]] | ||
| * **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). 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: 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. | ||
/home/www/auscope/opswiki/data/attic/operations/documentation.eremotecontrol_checklist_midob.1438304038.txt.gz · Last modified: 2015/07/31 00:53 by Jamie McCallum
Page Tools
