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:32]
Warren Hankey
operations:aum-hb [2020/12/21 22:30] (current)
Lim Chin Chuan
Line 1: Line 1:
 ====== Some background ====== ====== Some background ======
  
-the AUM experiments are designed to investigate and hopefully demonstrate the compatibility of the new wideband VGOS receiver with the existing S/X system. This is important for maintaining a global geodetic network during the transition to a fully global VGOS array. ​+The AUM experiments are designed to investigate and hopefully demonstrate the compatibility of the new wideband VGOS receiver with the existing S/X system. This is important for maintaining a global geodetic network during the transition to a fully global VGOS array. ​
  
-The Hobart12 ​antenna ​now has a functional wideband system, with reasonable ​sensitivitiesThe initial observations ​of the AUM series ​will be made using the "​VGOS"​-mode DBBC3 software, recording channels with an (excessive) bandwidth of  32 MHz which will be dealt with in the correlation stage. ​If the current issues with the DBBC3 and its "​Legacy"​-mode software are resolved, we sill change over to use this insteadso the instructions may be updated - please check the page carefully each time you are starting or monitoring an AUM experiment. ​+The Hobart12 ​and Katherine antennas ​now have a functional wideband system, with reasonable ​sensitivityAs of January 2020, we are still observing using the same mode as in the AUM series. This uses the "​VGOS"​-mode DBBC3 software, recording channels with an (excessive) bandwidth of 32 MHz which will be dealt with in the correlation stage. ​Once the new DBBC3 firmware is confirmed as usable for our systems, we will move across ​to using that. As suchthese instructions may be updated - please check the page carefully each time you are starting or monitoring an AUA/AUM experiment. ​
  
 ===== Major Differences ===== ===== Major Differences =====
  
-The major differences for observing an AUM experiment rather than a standard S/X experiment are that there is no FS support for the hardware and that we need to run two DBBCs simultaneously to record the S- and X-band data. The recorder has also changed from the mark5B to a flexbuff which operates in a very different fashion. Preliminary scripts have been written to monitor the relevant parameters but again, these are likely to be changed and improved as needed.+The major differences for observing an AUM experiment rather than a standard S/X experiment are that there is limited/no FS support for the hardware and that we need to run two DBBCs simultaneously to record the S- and X-band data. The recorder has also changed from the mark5B to a flexbuff which operates in a very different fashion. Preliminary scripts have been written to monitor the relevant parameters but again, these are likely to be changed and improved as needed.
  
-==== Revised checklist ==== 
- 
-Taking the existing e-remote control checklists as a template, here is a listing of the significant differences. 
  
 === Before the Experiment === === Before the Experiment ===
  
-  * Preparing the schedule file: Do not use the existing slogit scripts, but instead download the skd file directly to pcfshb ​and run drudg to generate the prc, snp and sum files and put them where they'​re needed.+  * Preparing the schedule file: **Do not use the existing slogit scripts**, but instead download the skd file directly to pcfs[hb|ke|yg] ​and run drudg to generate the snp and sum files and put them where they'​re needed.
  
-<​code>​cd /​usr2/​sched +<​code>​ 
-wget ftp://​cddis.gsfc.nasa.gov/​vlbi/​ivsdata/​aux/​2018/aum001/aum001.skd +cd /​usr2/​sched 
-drudg aum001.skd +wget ftp://​cddis.gsfc.nasa.gov/​vlbi/​ivsdata/​aux/​2020/aum018/aua018.skd 
-   hb +drudg aum018.skd 
-   12 +   ​hb ​(station) 
-   3 +   11 (show/set equipment type) 
-   5 +   1 16 1 1  (none, flexbuff[mark5b],​ none, none) 
-   0 +   ​3 ​ (make snap file) 
-scp /​tmp/​sched.tmp observer@ops-serv2:/​vlbobs/​ivs/​logs/aum001hb.sum+   ​5 ​ ​(print summary) 
 +   ​0 ​ ​(exit) 
 +scp /​tmp/​sched.tmp observer@ops-serv2:/​vlbobs/​ivs/​sched/aum018hb.sum (tmp summary file might have a different file name! i.e. DR.tmp)
 </​code>​ </​code>​
     ​     ​
-The next step is to convert ​the existing snp file into one which will control ​the flexbuff recordings appropriatelyThis is done via script at present ​please ​use the following commands <​code>​cp aum001hb.snp aum001hb.orig.snp +The next step is to create ​the procedure ​file with the appropriate commandsThe easiest way is to copy the procedure file from previous experiment using the same mode. For the 32-MHz mode (In use as of March 2020), ​the SI experiment setup can be used as the templatee.g:
-/​usr2/​sched/​snp2flexbuff.sh aum001hb.orig.snp aum001hb.snp hb</​code>​+
  
-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!** ​+<​code>​ 
 +cd /​usr2/​proc/​ 
 +cp si.prc aum018hb.prc  (Hb, Ke) 
 +cp aum018yg.prc [exper]yg.prc (Yg) 
 +</​code>​
  
-  ​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.  +=== Setting up for Hb, Ke === 
-    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 3Refresh ​the Folly display ​with 'r' and confirm that **S/X SRCP** and **S/X XRCP** are highlighted for channels ​and respectively +  ​Terminate the FS and restart it with "​fs-dummy"​. (To ensure that the Field system will not connect to the DBBC2 and block the configuration ​scripts) 
-    * 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.  +  * Log in to **DBBC3** (''​vncviewer dbbc3hb''​) and make sure that the ''​DBBC3 Control DDC_V_v123.exe''​ program is running, and that the final line of output reads ''​Waiting ​for connection''​).  
-    ​* ​IF selections ​ can be checked with the ''​aum.query.py''​ script ​on pcfshbFor 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'​'+  * Next, check the **DBBC2** (''​vncviewer dbbcho''​ for Hb and ''​vncviewer dbbcke''​ for Ke) and check that the correct control program is running (''​DBBC2 Control DDC v105E_2.exe''​ for Hb, ''​DBBC2 Control DDV v106E_120118.exe''​ for Ke) and displays ''​Waiting for connection''​) 
 +  If the server program ​is not running, please start it from the link on the desktop (and be prepared for a 15-20 minute wait for the DBBC3 after answering "​y"​ to the reconfiguration question).  
 +  * If it does not read ''​waiting for connection''​, it should give the IP address of the machine that'​s ​currently talking to it (e.g if it reads ''​Command from 131.217.63.201:''​ then the connection is from 131.217.63.201). You can lookup up the name of this machine using ''​nslookup 131.217.63.201''​ - in this example it is the ''​hobart''​ machine that is talking with the DBBC. If a PCFS machine is connected, the best option is to terminate ​the FS on that machine and restart with a version that will not conflict. For the Hobart example, running ​''​fs-auscope'' ​will avoid this problem while ''​fs-flexbuff''​ will block communications.  
 +  * From a terminal on the pcfs machine, run the command ''​./​bin/​aum.query.summ.py''​. If the script stalls (and does not return ​to the command prompt), then it's likely that either one or both of the DBBC control programs are not running, or that something else is talking to them 
 +  * Once you can run ''​~/​bin/​aum.query.summ.py''​ successfully,​ you should be fine to configure ​the backends ​with ''​./​bin/​aum.setup.py [exp_name]''​. NB - this script will force a synchronisation of the BBCs and is equivalent to running ''​setupsx''​ and ''​fmset''​ in sequence. ​**Do not run the setup script during the experiment!** 
 +  * Load the procedures with ''​proc=aum018hb'' ​and configure the recorder with ''​setupvgos''​ 
 +  ​Check the ''​~/bin/​aum.query.py''​ returns "​pps_delay/​ [1]: 43 ns, [2] 39 ns, [3] 39 ns, [4] 43 ns, [5] 43 ns, [6] 43 ns, [7] 0 ns, [8] 0 ns"(If not, the dbbc3 may need to be reconfigured or even restarted) 
 +  * Check that ''​~/​bin/​aum.query.summ.py''​ returns "​Delays:​ OK" and "​Samplers:​ Ok" (if the IF or BBC power levels are reported as bad, this should be re-checked after a few minutes but they might be out of range when freshly set up).  
 +  * You can make a test recording to check for synchrnoisation problems between the different DBBCs with ''​~/​bin/​sxtimetest.sh''​ which will print out the decoded time of the start of the test recording. All three values should agree and match the time reported in the FS log for when the "​record=on"​ command was issued. If the times differ between the different datastreams, you will need to reconfigure ​the relevant DBBCs. If they are all in agreement but differ from the FS log, please note this difference in the log but proceed ​on to the next step.  
 +  * Set the log file for the experiment with ''​log=aum018hb''​ 
 +  * Load the schedule file with ''​sched=aum018hb,#​1''​ 
 + 
 +== Setting up for Yg == 
 +  * Yarragadee should be set up normally, using the DBBC2 (v104_2.exe) and mk5yg - Please make sure this is configured by starting the Field System with ''​fs''​. 
 + 
 +==== Revised checklist for Hb, Ke==== 
 + 
 +A new script has been created which summarises the DBBC3/DBBC2 status. A version is installed on the pcfs machines as ''​~oper/​bin/​aum.query.summ.py'' ​and should be running in the VNC session. The Hobart and Katherine menus on ''​ops8''​ also have a new entry called ''​AUM Monitor''​ which will start a version on opsrunning in an xterm and refreshing every 60sThe output is below: 
 + 
 +<​code>​ 
 +2020.056.05:​00:​06 
 +##################​ 
 +DBBC3 - Delays: OK 
 +DBBC2 - Delays: OK 
 +##################​ 
 +DBBC3 - Sampler 3: OK 
 +DBBC3 - Sampler 4: OK 
 +#####################​ 
 + 
 +DBBC3 IFC: OK 
 +DBBC3 IFD: OK 
 +DBBC3 Freq BW Power DBBC3 Freq BW Power 
 +#############################################################​ 
 +BBC17 2204.99 32 OK BBC25 2204.99 32 OK 
 +BBC18 2244.99 32 OK BBC26 2244.99 32 OK 
 +BBC19 2344.99 32 OK BBC27 2344.99 32 OK 
 +BBC20 2504.99 32 OK BBC28 2504.99 32 OK 
 +BBC21 2724.99 32 OK BBC29 2724.99 32 OK 
 +BBC22 2844.99 32 OK BBC30 2844.99 32 OK 
 +BBC23 2884.99 32 OK BBC31 2884.99 32 OK 
 +BBC24 2924.99 32 OK BBC32 2924.99 32 OK 
 + 
 +DBBC2 IFA: Bad 
 +DBBC2 IFB: Bad 
 +DBBC2 Freq BW Power DBBC2 Freq BW Power 
 +#############################################################​ 
 +BBC01 300.99 32 OK BBC09 300.99 32 OK 
 +BBC03 332.99 32 OK BBC11 332.99 32 OK 
 +BBC05 364.99 32 OK BBC13 364.99 32 OK 
 +BBC07 348.99 32 OK BBC15 348.99 32 OK 
 + 
 +</​code>​ 
 + 
 +When carrying out a check, please run this script and check the outputs. Any errors related to the delays or DBBC3 samplers are critical are should be followed up (phone Jamie). Errors related to the IF or BBC levels should ​be noted - if these are consistently bad (in three consecutive readings), please contact Jamie to follow this up. 
 + 
 +=== Checklists === 
 + 
 + 
 +Taking the existing e-remote control checklists as a template, here is a listing of the significant differences. Most of the information is gathered by the ''​~/oper/bin/aum.query.py''​ script. ​This can be called from the FS with ''​sy=bin/​aum.query.py'' ​with the outputs printed to screen ​and also logged to a file called e.g: ''/​usr2/​log/​aua060hb.dbbc.log''​. It's strongly recommended to have a terminal watching this (''​tail -100f /​usr2/​log/​aua060hb.dbbc.log''​) as it can be difficult to read from the FS displayAn example of the output is given at the end of this page.  
 + 
 + * RF and IF paths configured/​DBBC settings: The RF/IF/DBBC configuration has been compiled into a single script on the pcfs machine called ​''​~/​aum.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 DBBC2 but the script should not be run during an experiment to avoid unnecessary clock breaks. ​   
 +    * Check that the dbbcif[abcd] input, ​filter ​and power target level readings in the ''​aua060hb.dbbc.log'' ​are correct. For Hobart12, these should be <​code>​ 
 +dbbcifa=4,​**11**,​agc,​2,​**47680**,​ 48000 
 +dbbcifb=4,​**27**,​agc,​2,​**47843**,​48000 
 +dbbcifc=2,​32,​agc,​2,​**40073**,​40000 
 +dbbcifd=2,​23,​agc,​2,​**40070**,​40000 
 +</​code>​  
 + 
 +and for Katherine:​ 
 +<​code>​ 
 +dbbcifa=2,​**38**,​agc,​2,​**42008**,​42000 
 +dbbcifb=2,​**37**,​agc,​2,​**41669**,​42000 
 +dbbcifc=2,​**29**,​agc,​2,​**48178**,​48000 
 +dbbcifd=2,​**23**,​agc,​2,​**47928**,​48000 
 +</​code>​  
 + 
 +NB - values with asterisks may vary depending on the input power level. Just make sure that the IF power readings is within ~1000 counts of the target.  
 +    * DBBC server: If the aum.query.py script cannot communicate with the DBBC servers, you can restart the software running through the VNC sessions as described in the setup procedure. Again, please note that this will introduce a clock break so make sure that there's no other issue like another machine having connected to the DBBC server. ​
   * 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''​ commandslogged 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// ​for Katherinedbbc2delay (at Katherine) will log the DBBC2-GPS difference. ​For Hobart12, the DBBC3-maser difference is being printed in a terminal on in the pcfshb VNC session ​this should be ~0.microseconds. If the display is not present, or not updating try running ''​cat /​dev/​ttyS0''​ as root on flexbuffhb  
-  * 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+ 
 + 
 +  * Test Recordings: To make a test recording, ​simply run ''​disk_record=on''​''​disk_record=off'' ​and ''​checkmk5'' ​in the operator input as per usual.  
 +  * Check for any integer second offsets in the recorded data by running ''​./​bin/​sxtimetest.sh''​ on pcfshb. This will make a short test recording and then present the decoded time of the three files - all three entries should agree to the integer second.
   * No autocorrelation script has been implemented yet.    * No autocorrelation script has been implemented yet. 
   * There is no systemp measurewment implemented yet.    * There is no systemp measurewment implemented yet. 
Line 49: Line 131:
 == Monitoring == == Monitoring ==
   * Antenna checks as per usual   * Antenna checks as per usual
 +  * Check data is being recorded in three streams (mk5=datastream?​ 0:​3:​sxy:​xx:​xy) and 3 files the same size per scan on flexbuff<​st>​ vbs_ls -lh aum019_* | tail
   * LO check unavailable   * LO check unavailable
   * 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'' ​(Ke only). 
-  * Check thew Hb maser as usual. ​+  * Check the Hb and Ke masers ​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.
-  * On pcfshb, run ''​./​aum.check.sh'' ​to check the dbbc and recorder statusThere is a lot of debugging info stored here, so use a large terminal window to run the script and be aware that you will need to press space to go through the listIncluded below is the full output ​of a check, with the relevant parameters to check commented on below.+ 
 +== Additional log output == 
 + 
 +Most of the additional monitoring of the DBBC3 is currently logged to a separate log file (''​/​usr2/​log/​aua060hb.dbbc.log''​),​ updated every scan when the ''​sy=bin/aum.query.py | tee ...'' ​script is runThis is part of the ''​midob''​ procedureI've annotated ​the output below
 <​code>​ <​code>​
 +2020.028.12:​07:​03
 ###############################​ ###############################​
 Checking dbbc3hb Checking dbbc3hb
 ###############################​ ###############################​
-dbbcifc/ 2,33,agc,2,41815,42000 +dbbcifc/ 2,32,agc,2,40019,40000; 
-dbbcifd/ 2,22,agc,2,42416,42000+dbbcifd/ 2,23,agc,2,39843,40000;
 </​code>​ </​code>​
 This first block is the equivalent of ''​iread''​ - check the inputs and filters are set to ''​2''​ and that the power level matches the target This first block is the equivalent of ''​iread''​ - check the inputs and filters are set to ''​2''​ and that the power level matches the target
 <​code>​ <​code>​
-dbbc17/ 2204.990000,​a,​32,​1,​agc,​55,63,14974,15206,0,0 +dbbc017/ 2204.990000,​a,​32,​1,​agc,​64,73,14921,14957,0,0; 
-dbbc18/ 2244.990000,​a,​32,​1,​agc,​58,69,17035,15254,0,0 +dbbc018/ 2244.990000,​a,​32,​1,​agc,​75,80,14837,14828,0,0; 
-dbbc19/ 2344.990000,​a,​32,​1,​agc,79,100,17160,14828,0,0 +dbbc019/ 2344.990000,​a,​32,​1,​agc,​100,​121,14883,14875,0,0; 
-dbbc20/ 2504.990000,​a,​32,​1,​agc,​124,108,15562,14913,0,0 +dbbc020/ 2504.990000,​a,​32,​1,​agc,​151,133,14822,14915,0,0; 
-dbbc21/ 2724.990000,​a,​32,​1,​agc,​107,121,16908,15844,0,0 +dbbc021/ 2724.990000,​a,​32,​1,​agc,​135,148,15015,14956,0,0; 
-dbbc22/ 2844.990000,​a,​32,​1,​agc,​181,181,16086,16144,0,0 +dbbc022/ 2844.990000,​a,​32,​1,​agc,​230,233,14936,14889,0,0; 
-dbbc232904.990000,​a,​32,​1,​agc,​188,196,16211,16191,0,0 +dbbc0232884.990000,​a,​32,​1,​agc,​227,243,14899,14933,0,0; 
-dbbc24/ 2924.990000,​a,​32,​1,​agc,​200,202,16298,16046,0,0 +dbbc024/ 2924.990000,​a,​32,​1,​agc,​255,255,14777,14163,0,0; 
-dbbc25/ 2204.990000,​a,​32,​1,​agc,​57,58,13976,17561,0,0 +dbbc025/ 2204.990000,​a,​32,​1,​agc,​60,64,15830,14184,0,0; 
-dbbc26/ 2244.990000,​a,​32,​1,​agc,​68,75,15413,16071,0,0 +dbbc026/ 2244.990000,​a,​32,​1,​agc,​65,74,14735,15623,0,0; 
-dbbc27/ 2344.990000,​a,​32,​1,​agc,90,92,15310,14988,0,0 +dbbc027/ 2344.990000,​a,​32,​1,​agc,​92,​105,14711,15240,0,0; 
-dbbc28/ 2504.990000,​a,​32,​1,​agc,​119,100,16736,16911,0,0 +dbbc028/ 2504.990000,​a,​32,​1,​agc,​147,114,14965,15007,0,0; 
-dbbc29/ 2724.990000,​a,​32,​1,​agc,​104,109,16772,14937,0,0 +dbbc029/ 2724.990000,​a,​32,​1,​agc,​122,130,14927,15052,0,0; 
-dbbc30/ 2844.990000,​a,​32,​1,​agc,​149,172,16204,15428,0,0 +dbbc030/ 2844.990000,​a,​32,​1,​agc,​182,211,14940,15090,0,0; 
-dbbc312904.990000,​a,​32,​1,​agc,​183,175,15675,16114,0,0 +dbbc0312884.990000,​a,​32,​1,​agc,​228,220,14919,14975,0,0; 
-dbbc32/ 2924.990000,​a,​32,​1,​agc,171,209,16013,16102,0,0+dbbc032/ 2924.990000,​a,​32,​1,​agc,​209,​255,14828,14455,0,0;
 </​code>​ </​code>​
 This is the quivalent of ''​bread''​ confirm all the values are within ~1000 of the 16000 target and that the frequencies match those listed above. This is the quivalent of ''​bread''​ confirm all the values are within ~1000 of the 16000 target and that the frequencies match those listed above.
 <​code>​ <​code>​
-pps_delay/ [1]: 43 ns, [2] 43 ns, [3] 39 ns, [4] 39 ns, [5] 39 ns, [6] 39 ns, [7] 0 ns, [8] 0 ns;+pps_delay/ [1]: 43 ns, [2] 39 ns, [3] 39 ns, [4] 39 ns, [5] 43 ns, [6] 39 ns, [7] 0 ns, [8] 0 ns;
 </​code>​ </​code>​
 This is the translated equivalent of ''​dbbc=pps_delay'',​ separated by processing board. Check that all the listed values are either 43 or 39 ns, and are stable. ​ This is the translated equivalent of ''​dbbc=pps_delay'',​ separated by processing board. Check that all the listed values are either 43 or 39 ns, and are stable. ​
Line 90: Line 178:
 core3hstats/ ​ core3hstats/ ​
 Core3H[3] Power: Core3H[3] Power:
-Sampler 0: 60781106 +Sampler 0: 44362700 
-Sampler 1: 61694675 +Sampler 1: 44956375 
-Sampler 2: 62199248 +Sampler 2: 44344937 
-Sampler 3: 62160250+Sampler 3: 43982701
 </​code>​ </​code>​
 The Core3H power readings from each sampler should all agree to within ~3-5%. This is the first of two samplers in use.  The Core3H power readings from each sampler should all agree to within ~3-5%. This is the first of two samplers in use. 
Line 99: Line 187:
 Core3H[3] Bstat. Core3H[3] Bstat.
 Sampler 0: Sampler 0:
-11:       44 0.28+11:       10 0.06
-10:     7699 49.27+10:     7822 50.06
-01:     7846 50.21+01:     7785 49.82
-00:       34 0.22%+00:        ​6 ​0.04%
  
 Sampler 1: Sampler 1:
-11:       71 0.45+11:       11 0.07
-10:     7915 50.66+10:     7771 49.73
-01:     7604 48.67+01:     7833 50.13
-00:       33 0.21%+00:        ​8 ​0.05%
  
 Sampler 2: Sampler 2:
-11:       48 0.31+11:       21 0.13
-10:     7768 49.72+10:     7986 51.11
-01:     7773 49.75+01:     7610 48.70
-00:       33 0.21%+00:        ​6 ​0.04%
  
 Sampler 3: Sampler 3:
-11:       45 0.29+11:        ​9 ​0.06
-10:     7700 49.28+10:     7757 49.64
-01:     7844 50.20+01:     7850 50.24
-00:       35 0.22%+00:        ​6 ​0.04%
 </​code>​ </​code>​
 The Bstats can be ignored at this time - they'​re displayed because it's complicated to hide them.  The Bstats can be ignored at this time - they'​re displayed because it's complicated to hide them. 
 <​code>​ <​code>​
 Core3H[3] Corr. Core3H[3] Corr.
-Sampler 0-1: 180656919 +Sampler 0-1: 183273215 
-Sampler 1-2: 182717105 +Sampler 1-2: 186151539 
-Sampler 2-3: 182062361+Sampler 2-3: 183984793
 </​code>​ </​code>​
-All inter-sampler correlation values should be ~180000000+All inter-sampler correlation values should be above ~170000000
 <​code>​ <​code>​
 +
 +;
 core3hstats/ ​ core3hstats/ ​
 Core3H[4] Power: Core3H[4] Power:
-Sampler 0: 88700574 +Sampler 0: 64799981 
-Sampler 1: 90430690 +Sampler 1: 64621395 
-Sampler 2: 92322148 +Sampler 2: 65964916 
-Sampler 3: 93681776+Sampler 3: 64445221
 </​code>​ </​code>​
-The Core3H power readings from each sampler should all agree to within ~3-5%. This is the second sampler ​of two, and the above readings are ok.+The Core3H power readings from each sampler should all agree to within ~3-5%. This is the first of two samplers in use
 <​code>​ <​code>​
 Core3H[4] Bstat. Core3H[4] Bstat.
 Sampler 0: Sampler 0:
-11:      170 1.09+11:       50 0.32
-10:     7635 48.86+10:     7707 49.32
-01:     7680 49.15+01:     7807 49.96
-00:      ​138 ​0.88%+00:       60 0.38%
  
 Sampler 1: Sampler 1:
-11:      226 1.45+11:       59 0.38
-10:     7680 49.15+10:     7778 49.78
-01:     7582 48.52+01:     7743 49.56
-00:      ​135 ​0.86%+00:       42 0.27%
  
 Sampler 2: Sampler 2:
-11:      184 1.18+11:       57 0.36
-10:     7638 48.88+10:     7804 49.95
-01:     7658 49.01+01:     7719 49.40
-00:      ​142 ​0.91%+00:       43 0.28%
  
 Sampler 3: Sampler 3:
-11:      181 1.16+11:       53 0.34
-10:     7569 48.44+10:     7639 48.89
-01:     7733 49.49+01:     7887 50.48
-00:      ​140 ​0.90%+00:       44 0.28%
 </​code>​ </​code>​
 The Bstats can be ignored at this time - they'​re displayed because it's complicated to hide them.  The Bstats can be ignored at this time - they'​re displayed because it's complicated to hide them. 
 <​code>​ <​code>​
- 
 Core3H[4] Corr. Core3H[4] Corr.
-Sampler 0-1: 186212284 +Sampler 0-1: 187136057 
-Sampler 1-2: 190747558 +Sampler 1-2: 190993079 
-Sampler 2-3: 187420379+Sampler 2-3: 186760591
 </​code>​ </​code>​
-All inter-sampler correlation values should be ~180000000+All inter-sampler correlation values should be above ~170000000
 <​code>​ <​code>​
 +
 +;
 ###############################​ ###############################​
 Checking dbbcho Checking dbbcho
 ###############################​ ###############################​
-dbbcifa/1,4,agc,2,47097,48000,1 +dbbcifa/4,9,agc,2,47129,48000,1 
-dbbcifb/1,14,agc,2,47991,48000,1 +dbbcifb/4,24,agc,2,48036,48000,1 
-dbbc01/317.990000,​a,​32,​1,​agc,​97,89,14803,14952,0,0 +</​code>​ 
-dbbc03/337.990000,​a,​32,​1,​agc,​108,89,14945,15083,0,0 +This is the equivalent of ''​iread''​. All inputs for dbbcho should be ''​1'',​ all filters ''​2''​ and all target power levels ''​48000''​ 
-dbbc05/357.990000,​a,​32,​1,​agc,​103,111,14891,14875,0,0 +<​code>​ 
-dbbc07/387.990000,​a,​32,​1,​agc,​119,100,12784,14783,0,0 +dbbc01/300.990000,​a,​32,​1,​agc,​72,136,17885,17699,0,0 
-dbbc09/317.990000,​b,​32,​1,​agc,​130,119,16077,16249,0,0 +dbbc03/332.990000,​a,​32,​1,​agc,​63,63,17873,17835,0,0 
-dbbc11/337.990000,​b,​32,​1,​agc,​139,123,16091,16175,0,0 +dbbc05/364.990000,​a,​32,​1,​agc,​53,62,17617,17971,0,0 
-dbbc13/357.990000,​b,​32,​1,​agc,​149,138,16248,16228,0,0 +dbbc07/348.990000,​a,​32,​1,​agc,​57,61,18100,17633,0,0 
-dbbc15/387.990000,​b,​32,​1,​agc,​125,145,14144,16119,0,0+dbbc09/300.990000,​b,​32,​1,​agc,​56,166,17989,17571,0,0 
 +dbbc11/332.990000,​b,​32,​1,​agc,​63,54,18342,18083,0,0 
 +dbbc13/364.990000,​b,​32,​1,​agc,​91,64,18088,17794,0,0 
 +dbbc15/348.990000,​b,​32,​1,​agc,​88,55,17788,18248,0,0 
 +</​code>​ 
 +This is the equivalent of ''​bread''​. Note that only odd-numbered bbcs are used. As this is S-band, power levels may vary significantly so a range of 10000-25000 is acceptable (but notable - please put an entr in the handover notes) 
 +<​code>​
 pps_delay/​61971 pps_delay/​61971
-sysstat+</​code>​ 
 +The pps_delay should be stable at 61971, to within 1 count of so. 
 +<​code>​ 
 +fila10g/sysstat
  
-^MSystem ​status: +System ​status: 
-^M Selected input      : vsi1 + ​Selected input      : vsi1 
-^M Input sample rate   : 64000000 Hz + Input sample rate   : 64000000 Hz 
-^M VSI input swapped ​  : no + VSI input swapped ​  : no 
-^M VSI input bitmask ​  : 0x0000FFFF + VSI input bitmask ​  : 0x0000FFFF 
-^M VSI input width     : 16 bit + VSI input width     : 16 bit 
-^M PPS count           : ​78607+ PPS count           : ​23451
  
-^M TVG mode            : vsi-h+ TVG mode            : vsi-h
  
-^M MK5B timesync ​      : yes + MK5B timesync ​      : yes 
-^M VDIF timesync ​      : yes + VDIF timesync ​      : yes 
-^M GPS receiver ​       : installed+ GPS receiver ​       : installed
  
-^M Output ​             : started + Output ​             : started 
-^M Output 0 format ​    : vdif + ​Output 0 format ​    : vdif 
-^M Output 0 dest.      : 192.168.1.11:46236 + ​Output 0 dest.      : 192.168.1.13:46227 
-^M Output 1 format ​    : vdif + ​Output 1 format ​    : vdif 
-^M Output 1 dest.      : none + ​Output 1 dest.      : none 
-^M Ethernet ARPs       : off+ ​Ethernet ARPs       : off
  
-^M Selected VSI output : vsi1-2+ Selected VSI output : vsi1-2
  
-^MFiLa10G %  +FiLa10G ​%
-^MFiLa10G ​+
 </​code>​ </​code>​
 +
 +This last block is the Fila10G status. Please confirm that these settings match the output when performing the checks. ​
 +
 +
/home/www/auscope/opswiki/data/attic/operations/aum-hb.1533000735.txt.gz · Last modified: 2018/07/31 01:32 by Warren Hankey