Session Notes for RD0701 Prepared by D. Behrend, NVI, Inc./GSFC =========================================================== PURPOSE AND GENERAL NOTES =========================================================== The purpose of rd0702 is to continue the series of Gb/s tests and to check new stations in Gigabit mode (station checkout). Medicina and Tigo run their first Gb/s test in an IVS session. This session has all stations fully scheduled. Tigo was given quintuple weight in order to increase the number of observations. Also, the SNR target was relaxed on baselines with Tigo for the same purpose. This was successful to a limited degree only, due to network configuration and sensitivity. The schedule uses the 80 best sources. Kokee and Wettzell will observe INT I07087 and join rd0702 at about 1950 UT. This schedule was generated using ultra-high minimum SNRs of 80 at X-band and 60 at S-band. Tigo baselines use SNRs of 60 at X-band and 40 at S-band. An extra 3 seconds is added at the start of each scan for correlator synchronization. These extra seconds are not included in the calculation of the scan SNR. This session must be recorded on Mk5 disks. Multiple disk modules will be required. Stations must plan for disk changes by referring to the drudg listings that display the number of Gb recorded during the experiment. Refer to the last sections of these notes for reminders about testing and setup for the Gb/s recording mode. Testing prior to the experiment is essential for success. =========================================================== Parameter values for experiment RD0702 Experiment description: R&D-02 2007 Scheduler: dbb Correlator: HAYSTACK Nominal start: 2007-087-18:00:00 Nominal end: 2007-088-18:00:00 Current yyyyddd: 2007087 (2007.24) ( 14188 MJD, WED. 28MAR.) Greenwich sidereal time: 6:23: 5.00 (18: 0: 0 UT) Sun's RA and DEC: 0h 28.2m 3d 2.8 =========================================================== First observations Observation listing from file ./rd0702.skd for experiment RD0702 Source Start DURATIONS name yyddd-hhmmss Kk Mc Ny Tc Wf Wz 0454-234 07087-180000| 91 162 162 | 0823+033 07087-180300| 50 50 | 1044+719 07087-180646| 89 110 110 | ...... 0133+476 07087-195004| 90 61 173 173 138| 1739+522 07087-195412| 100 42 80 100 81| ...... End of listing. =========================================================== Last observations Observation listing from file ./rd0702.skd for experiment RD0702 Source Start DURATIONS name yyddd-hhmmss Kk Mc Ny Tc Wf Wz ...... 3C446 07088-172951| 174 329 329 | ...... 3C418 07088-175138| 133 113 213 243 243| 0642+449 07088-175652| 40 62 62 58| End of listing. =========================================================== SKED Summary from file ./rd0702.skd for experiment RD0702 (all scans with at least one subnet station) Average number of obs. per baseline per source(normalized by up-time) = 6.0 Min = .0 Max = 57.6 (Baseline Ny-Wf on 1741-038) RMS = 9.3 Total time: 1438 minutes ( 24.0 hours). Key: Kk=KOKEE Mc=MEDICINA Ny=NYALES20 Tc=TIGO Wf=WESTFORD Wz=WETTZELL Kk Mc Ny Tc Wf Wz Avg % obs. time: 36 33 51 31 57 52 43 % cal. time: 2 5 4 1 4 4 3 % slew time: 11 40 20 3 14 10 17 % idle time: 50 22 24 64 24 33 37 total # scans: 209 398 372 95 323 370 294 # scans/hour : 9 17 16 4 13 15 12 Avg scan (sec): 147 72 118 283 152 122 148 # data tracks: 32 32 32 32 32 32 # Mk5 tracks: 32 32 32 32 32 32 Total GBytes: 4413 4132 6329 3872 7056 6488 5382 Total GB(M5): 3922 3672 5626 3442 6272 5767 4784 # of tapes : .1 .1 .1 .1 .1 .1 tape change times (hhmm): Total number of tapes: .9 Total GBytes (M5) recorded: 28701.5 # OF OBSERVATIONS BY BASELINE | Kk Mc Ny Tc Wf Wz StnTotal ---------------------------------------- Kk| 107 157 56 168 113 601 Mc| 316 49 237 362 1071 Ny| 24 246 299 1042 Tc| 82 43 254 Wf| 209 942 Wz| 1026 Number of 2-station scans: 81 Number of 3-station scans: 189 Number of 4-station scans: 140 Number of 5-station scans: 86 Number of 6-station scans: 8 Total # of scans, observations: 504 2468 =========================================================== Recording mode Name Code GEOSX8N 8F Recording mode setup for: KOKEE MEDICINA NYALES20 TIGOCONC WESTFORD WETTZELL Mode Tot.Rate Tot.BandW #chan #bits Barrel Mk341:2 1012.736 Mbits 506.368 MHz 14 2 NONE Chan.BW #Subpasses Tracks(*fan) Tot.tracks Speed 16.00 MHz 1 16(*2) 32 .02 X-band spanned bw= 720.0 MHz rms spanned bw= 280.4 MHz S-band spanned bw= 140.0 MHz rms spanned bw= 50.9 MHz Effective number of channels recorded per sub-pass X S Total 19.780 11.868 31.648 =========================================================== Tape types ID Station Tape length Density Passes Kk KOKEE Mark5A Mc MEDICINA Mark5A Ny NYALES20 Mark5A Tc TIGOCONC Mark5A Wf WESTFORD Mark5A Wz WETTZELL Mark5A =========================================================== SNR Targets Minimum SNR by baseline for multi-baseline scans X-band (margin 10) S-band (margin 10) Kk Mc Ny Tc Wf Kk Mc Ny Tc Wf Mc 80 Mc 60 Ny 80 80 Ny 60 60 Tc 60 60 60 Tc 40 40 40 Wf 80 80 80 60 Wf 60 60 60 40 Wz 80 80 80 60 80 Wz 60 60 60 40 60 ====================================================================== TESTING AND SETUP ====================================================================== This session requires 4 ribbon cables between the Formatter and the Mark 5 Recorder. If one of these cables is missing, the correlator will not be able to read any of the data. Recording 1GB/s data should be verified for your station if you have not already done so. To do this, Mark 4 stations should run ftp://web.haystack.edu/pub/mark5/SNAP/chk1024.snp with ftp://web.haystack.edu/pub/mark5/SNAP/chk1024.prc VLBA4 stations such as Kokee Park, should run ftp://web.haystack.edu/pub/mark5/SNAP/vchk1024.snp and ftp://web.haystack.edu/pub/mark5/SNAP/vchk1024.prc If you have FS 9.9.0 or later installed, you may have already installed these files as part of the upgrade. If not, they are available in /usr2/fs/systests directory. Instructions on installing, using, and analyzing the results of this test can be found in "systests.txt" in the same directory. Regardless of where you get the .snp and .prc files, you should use the systests "chk1024" script to analyze the results of the test. For more information, please try the shell command: chk1024 -h or try: chk1024 logfile for a summary of the results from "logfile". Please be sure to start a new log (i.e., rename the existing old one) each time you run one of the test .snp schedules mentioned above. If the results from "chk1024" aren't completely positive (all setups, particularly "1g" shown as 64 tracks tested, "100% good", and NO "other tracks present" clause), please send a copy of the log to dsmythe@haystack.mit.edu, or put a copy in the ivsmisc area in ivscc (please use a unique name for your file so that your log is not overwritten by others), with a follow-up e-mail to dsmythe. Do not touch any of the cables between the Formatter and the Mark 5 Recorder after this test has been run without any errors. ====================================================================== DISK MODULE CHANGES ====================================================================== This session will require 2, 3 or 4 disk modules, depending on the sizes that you have available at your station. DRUDG does not know the sizes, so it shows an ever-increasing GByte count. Please be aware that you will have to change modules several times during this session, and plan accordingly. There are a few of things to consider: 1) It is desriable to precondition all modules ahead of time that you will use for the session. Recording at the 1 Gigabit/second often works better if the modules have been preconditioned since their last shipment. If you don't have time to precondition all the modules that are needed, plus one or two spares, please precondition as many as you can. 2) Mark module change times. Select the modules you will use for this session, note their sizes, and then mark by hand the places in the schedule where a module change will be necessary, and which bank will need to be changed. You can use the drudg Option 5 listing for this purpose. Unfortunately it is not possible to predict the module change times exactly. For various reasons, a module can be finished at a different time, usually earlier than expected. As long as a module does not end a great deal earlier than expected, this should not cause a problem. 3) Change modules promptly. When a module is full, the FS will automatically switch to the next one and put up a notice that you should change the old one. It is good practice to change the module as soon as it's called for, because then a new one is available in case the module in use should end prematurely for some reason. If you have any questions, please contact Ed Himwich (weh@ivscc.gsfc.nasa.gov).