This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
operations:aum-hb [2021/03/03 18:22] Lim Chin Chuan |
operations:aum-hb [2021/04/27 05:13] Pradyumna Kiran Kummamuru |
||
---|---|---|---|
Line 16: | Line 16: | ||
<code> | <code> | ||
cd /usr2/sched | cd /usr2/sched | ||
- | wget ftp://cddis.gsfc.nasa.gov/vlbi/ivsdata/aux/2021/aum028/aua028.skd | + | wget ftp://ivs.bkg.bund.de/pub/vlbi/ivsdata/aux/2021/aum028/aum028.skd |
drudg aum028.skd | drudg aum028.skd | ||
hb (station) | hb (station) | ||
Line 42: | Line 42: | ||
* 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. | * 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. | * 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.lim.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!** | + | * Once you can run ''~/bin/aum.query.summ.py'' successfully, you should be fine to configure the backend at Hobart 12 with ''./bin/aum.setup.lim.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!** |
- | * **As of March 2021, only dbbc3ke is available at Katherine, please stup using ''./bin/aum.setup.dbbc3only.py'' instead.** | + | * **As of March 2021, only dbbc3ke is available at Katherine, please setup using ''./bin/aum.setup.dbbc3only.py'' instead.** |
* Load the procedures with ''proc=aum018hb'' and configure the recorder with ''setupvgos'' | * 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 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) | ||
Line 49: | Line 49: | ||
* 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. | * 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'' | * Set the log file for the experiment with ''log=aum018hb'' | ||
- | * Load the schedule file with ''sched=aum018hb,#1'' | + | * Load the schedule file with ''schedule=aum018hb,#1'' |
== Setting up for Yg == | == Setting up for Yg == |