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
Next revision Both sides next revision
operations:aum-hb [2018/07/31 01:37]
Warren Hankey
operations:aum-hb [2019/07/06 12:02]
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/pages/operations/aum-hb.txt · Last modified: 2020/01/28 12:20 by Jamie McCallum