User Tools

Site Tools


operations:aum-hb

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
operations:aum-hb [2018/07/31 01:37]
Warren Hankey
operations:aum-hb [2019/07/06 12:02] (current)
Chin Chuan Lim
Line 30: Line 30:
 The next step is to convert the existing snp file into one which will control the flexbuff recordings appropriately. This is done via a script at present - please use the following commands <​code>​cp aum001hb.snp aum001hb.orig.snp The next step is to convert the existing snp file into one which will control the flexbuff recordings appropriately. This is done via a script at present - please use the following commands <​code>​cp aum001hb.snp aum001hb.orig.snp
 /​usr2/​sched/​snp2flexbuff.sh aum001hb.orig.snp aum001hb.snp hb</​code>​ /​usr2/​sched/​snp2flexbuff.sh aum001hb.orig.snp aum001hb.snp hb</​code>​
 +
 +Updated: The DBBC3KE (which will be recording the X-band data is now configured. "​correlation statistics"​ might be slightly lower from the DBBC than  expected (~16000000 rather than 18000000+). It hopefully won't be too  much of an issue (Lim: cited from Jamie). Use the following script instead:
 +<​code>​snp2flexbuff.aum.sh aum001hb.orig.snp aum001hb.snp hb
 +aum007.setup.dbbc3ke.py</​code>​
 +The flexbuff logs will be under 
 +<​code>/​usr2/​log/​$(lognnm).flexbuffhb.log</​code>​ (S-band recordings only, 46236) and <​code>/​usr2/​log/​$(lognnm).flexbuflyg.log</​code>​ (X-band recordings only, 46229 & 46230)
  
 The newly created aum001hb.snp file retains the timing of the source commands, scan names and times but calls a script to run the recorder and omits many of the typical procedures like preob, etc.  **NB - do not use the line number entries in the sum file!** ​ The newly created aum001hb.snp file retains the timing of the source commands, scan names and times but calls a script to run the recorder and omits many of the typical procedures like preob, etc.  **NB - do not use the line number entries in the sum file!** ​
  
-  * RF and IF paths configured/​DBBC settings: The RF/IF/DBBC configuration has been compiled into a single script on pcfshb ''/​usr2/​sched/​aum.32mhz.py''​. Running this should set up all the essential settings for both the X-band recorded through the DBBC3 and S-band through the 26m backend and dbbcho. ​+  * RF and IF paths configured/​DBBC settings: The RF/IF/DBBC configuration has been compiled into a single script on pcfshb ''​~/aum007.setup.py''​. Running this should set up all the essential settings for both the X-band recorded through the DBBC3 and S-band through the 26m backend and dbbcho. ​
     * No RF configuration is needed for the X-band data recorded through the DBBC3, but it is necessary to set the inputs on the 26m's remote backend (e.g "the folly" or "​PalfreymansBackend"​. Go to the hobart26 VNC session (''​vncviewer newsmerd:​1''​) and go to desktop 3. Refresh the Folly display with '​r'​ and confirm that **S/X SRCP** and **S/X XRCP** are highlighted for channels 1 and 2 respectively. ​     * No RF configuration is needed for the X-band data recorded through the DBBC3, but it is necessary to set the inputs on the 26m's remote backend (e.g "the folly" or "​PalfreymansBackend"​. Go to the hobart26 VNC session (''​vncviewer newsmerd:​1''​) and go to desktop 3. Refresh the Folly display with '​r'​ and confirm that **S/X SRCP** and **S/X XRCP** are highlighted for channels 1 and 2 respectively. ​
-    * DBBC server: If the aum.32mhz.py script cannot communicate with the DBBC servers, you can restart the software running through the VNC sessions on dbbc3hb (''​DBBC#​ Control ​DDC_V_v121.exe''​) and dbbcho (''​DBBC2 Control DDC v105_2.exe''​ and ''​SerialServer.sem.py''​),​ respectively.  +    * DBBC server: If the aum007.setup.py script cannot communicate with the DBBC servers, you can restart the software running through the VNC sessions on dbbc3hb (''​DBBC#​ Control ​DDC_V_v122.exe''​) and dbbcho (''​DBBC2 Control DDC v105_2.exe''​ and ''​SerialServer.sem.py''​),​ respectively.  
-    * IF selections ​ can be checked with the ''​aum.query.py''​ script on pcfshb. For the DBBC3, all inputs and filters should be ''​2'' ​ and all power levels should have a target level of ''​42000''​. For the dbbcho, the input should be ''​1'',​ the filter ''​2''​ and the target power level should be ''​48000''​+    * IF selections ​ can be checked with the ''​aum.check.sh''​ script on pcfshb. For the DBBC3, all inputs and filters should be ''​2'' ​ and all power levels should have a target level of ''​42000''​. For the dbbcho, the input should be ''​1'',​ the filter ''​2''​ and the target power level should be ''​48000''​
   * Maser ok: Check the Hobart26 maser as per usual   * Maser ok: Check the Hobart26 maser as per usual
-  * Mark5: Not used. Instead log in to the Flexbuff recorder (with ''​ssh observer@flexbuffhb''​) and confirm that the time is correct (with ''​ntpq-np''​) and that jive5ab is running (with ''​ps -ef | grep jive''​) +  * Mark5: Not used. Instead log in to the Flexbuff recorder (with ''​ssh observer@flexbuffhb''​) and confirm that the time is correct (with ''​ntpq -np''​) and that jive5ab is running (with ''​ps -ef | grep jive''​) 
-  * The clock offsets can be (partially) read through the FS. ''​maserdelay''​ reads the maser-GPS difference as usual while ''​dbbc3delay''​ logs the DBBC3-GPS delay //as gps-fmout//​. The existing ''​clkoff''​ command is measuring the dbbchb-gps difference and logging this as //​fmout-gps//​ - this is irrelevant to the Hb12 recordings but is needed for the simultaneous Ho26 experiments!. In summary - compare the outputs of the ''​maserdelay''​ and ''​dbbc3delay''​ commands, logged as ''/​maser2gps/''​ and ''/​gps-fmout/''​ respectively. You should check the dbbc-gps difference for DBBCHO using the ptzhb camera. The relevant counter is to the left of the mark4 rack at the top of rack 9. It's labeled ''​DBBCHO-TACGPS''​and is typically ~1 microsecond offset from the maserdelay. You do not need to log this value but not the difference ​nd confirm that it is steady.+  * The clock offsets can be (partially) read through the FS. ''​maserdelay''​ reads the maser-GPS difference as usual while ''​dbbc3delay''​ logs the DBBC3-GPS delay //as gps-fmout//​. The existing ''​clkoff''​ command is measuring the dbbchb-gps difference and logging this as //​fmout-gps//​ - this is irrelevant to the Hb12 recordings but is needed for the simultaneous Ho26 experiments!. In summary - compare the outputs of the ''​maserdelay''​ and ''​dbbc3delay''​ commands, logged as ''/​maser2gps/''​ and ''/​gps-fmout/''​ respectively. You should check the dbbc-gps difference for DBBCHO using the ptzhb camera. The relevant counter is to the left of the mark4 rack at the top of rack 9. It's labeled ''​DBBCHO-TACGPS''​and is typically ~1 microsecond offset from the maserdelay. You do not need to log this value but not the difference ​and confirm that it is steady.
   * Test Recordings: To make a test recording, as ''​oper@pcfshb''​ run  ''​sxflexbuff.sh test 19''​ to carry out a 20s test recording. You can check the status of the flexbuff by tailing the log file (e.g ''​ tail -100f /​usr2/​log/​$(lognm).flexbuff.log''​). Confirm that the total number of packets is incrementing after each check and that there are no lost or out-of-order packets - these are symptoms of the flexbuff being overloaded. ​   * Test Recordings: To make a test recording, as ''​oper@pcfshb''​ run  ''​sxflexbuff.sh test 19''​ to carry out a 20s test recording. You can check the status of the flexbuff by tailing the log file (e.g ''​ tail -100f /​usr2/​log/​$(lognm).flexbuff.log''​). Confirm that the total number of packets is incrementing after each check and that there are no lost or out-of-order packets - these are symptoms of the flexbuff being overloaded. ​
   * Check for any integer second offsets in the recorded data by running ''​sxtest.sh''​ on pcfshb. This will make a short test recording and then present the decoded time of the three files - all three entries (presented as ''​MJD = 58330/​01:​09:​59.91''​) should agree to within 0.01 seconds. ​   * Check for any integer second offsets in the recorded data by running ''​sxtest.sh''​ on pcfshb. This will make a short test recording and then present the decoded time of the three files - all three entries (presented as ''​MJD = 58330/​01:​09:​59.91''​) should agree to within 0.01 seconds. ​
Line 52: Line 58:
   * No autocorrelations   * No autocorrelations
   * Check the delays with ''​maserdelay''​ and ''​dbbc3delay'',​ confirm the dbbcho time delay is stable   * Check the delays with ''​maserdelay''​ and ''​dbbc3delay'',​ confirm the dbbcho time delay is stable
-  * Check thew Hb maser as usual. ​+  * Check the Hb maser as usual. ​
   * Check the weather data is being logged & add in sky conditions as usual. ​   * Check the weather data is being logged & add in sky conditions as usual. ​
   * No Tsys checks.   * No Tsys checks.
Line 227: Line 233:
 </​code>​ </​code>​
 This last block is the Fila10G status. Please confirm that these settings match the output when performing the checks. ​ This last block is the Fila10G status. Please confirm that these settings match the output when performing the checks. ​
 +
 +  * You can check on the status of the recordings by tailing the flexbuff log (''/​usr2/​log/​aum001hb.flexbuff.log''​ on pcfshb - the name will change when a new FS log file is started). This is written to by the recording script and running ''​tail -100f /​usr2/​log/​aum001hb.flexbuff.log''​ will show the same output as in the recording tests, e.g 
 +<​code>​
 +50
 +!runtime = 0 : stream46230 ;!evlbi? 0 : total : 782143 : loss : 0 ( 0.00%) : out-of-order : 0 ( 0.00%) : extent : 0seqnr/pkt ;
 +!runtime = 0 : stream46236 ;!evlbi? 0 : total : 782107 : loss : 0 ( 0.00%) : out-of-order : 0 ( 0.00%) : extent : 0seqnr/pkt ;
 +!runtime = 0 : stream46229 ;!evlbi? 0 : total : 782064 : loss : 0 ( 0.00%) : out-of-order : 0 ( 0.00%) : extent : 0seqnr/pkt ;
 +</​code>​
 +
 +Please note that the output is "​laggy"​ and is usually delayed by ~1 minute. You can see the current status of the recorder using [[http://​ptzhb.phys.utas.edu.au/​web/​admin.html|ptzhb]] - when recording you will see the blue lights of disk activity scattered over the flexbuff (below the DBBC in rack 13). 
/home/www/auscope/opswiki/data/attic/operations/aum-hb.1533001035.txt.gz · Last modified: 2018/07/31 01:37 by Warren Hankey