Message 1/506 Ed Himwich Oct 17, 2000 11:38:54 am -0400 Date: Tue, 17 Oct 2000 11:38:54 -0400 Reply-To: weh@ivscc.gsfc.nasa.gov X-Accept-Language: en To: EVNtech Subject: EVNtech: [Fwd: FS and Team China] Sender: owner-evntech@jb.man.ac.uk Precedence: bulk Here is my contribution to the Team China report for the TOG meeting. Thanks to Mike G. for sending me copy to forward to the exploder. Ed ---------------------------------------------------------------------- Nanshan Software Prior to our arrival the new Field System (FS) computer had been installed at Nanshan and all of the station software ported from the old system. While I was there I worked Wang Na, Chen Maozheng, and Liu Xiang to implement an antcn antenna interface program and provide some training on Linux operations. Unfortunately we did not have as much time as hoped for training and antenna pointing due to the hardware troubleshooting that was necessary. The FS antenna interface was completed and seemed to be working well when we left. Several hours of pointing data were collected at C-band and some separate data were collected at X-band. The interface provides commanding a source with apparent positions of date, Hour Angle-Declination and Azimuth-Elevation offsets, and onsource information. The station staff was interested in utilizing aquir, fivpt, and onoff to automate pointing and gain measurements at the station. One problem in accomplishing this is that some of the stations measurement programs use control systems other than the FS. One of strengths of doing all pointing control from the FS directly is that it provides a complete measurement and analysis system for pointing. A new pointing model can be installed in the FS and checked to make sure it is correct with the same tools. In order for other control systems to utilize pointing models developed by the FS, it will be necessary to transfer the models to either the other control systems or to the antenna control computer directly. The latter, transferring the model to the antenna control computer is preferred since this will allow the FS to be used to verify that the model has been transferred successfully. As the system was left, there is no capability for using a pointing model in the antenna interface. However this can easily be added at a later date. I set-up two SNAP procedures libraries for pointing checks: "pointc" (for C-band) and "pointsx" (for X- and S-band simultaneously). These can be copied and easily modified to make libraries for other bands. The only modifications that should be necessary are to change: (1) noise diode temperatures, (2) LO information, (3) flux models for the sources, (4) the name of the control file for aquir, and (5) the name of the log file. For each band the list of sources and whether to run fivpt and/or onoff can be modified in the aquir control file ("ctlpoc.ctl" and "ctlposx.ctl" for C-band and XS-bands respectively, these can copied and used as starting points for control files for other bands as well). These programs offer the potential for implementing a source flux monitoring program. Recommendations Communication with the recorder is still somewhat problematic. The recorder incorrectly and intermittently reports the state as not-ready when it is ready and moving when it is stopped. It is likely that replacing the Mark III controller board will solve this problem. This step is highly recommended since it prevents reliable computer control of the system. As implemented, the antenna interface supports the FS "track" SNAP command. It is recommended that the "track" command be included in the "midob" procedure for all experiments. This allows information about the antenna status to be logged for each observation. The command "sy=run setcl &" should also be included in the "midob" procedure for all experiments to track the drift of FS time relative to the formatter. The control room needs a counter, an HP 53131A is a good choice, to monitor the offset between the Formatter and GPS. This can be connected to the FS and automatically log the offset as "fmout-gps" or "gps-fmout" depending on which signal starts the counter. For a GPS signal the TAC in the adjacent room could be used. This monitoring is completely separate from the monitoring of the offset between the Maser and GPS. The offset between the Formatter and GPS should be logged in each "midob" procedure. It is also recommended that the existing Showtime software for controlling the TAC be replaced with the newer TAC32plus software which runs under various flavors of MS-Windows (95, 98, NT, 2000). This software can also serve as NTP time server for the FS over a LAN. The station should implement a LAN. This would allow the TAC control PC to serve as a time server for the FS computer. It would also allow schedules and logs to be transferred between the FS computer and the computer used for Internet access without using a floppy. As an aside I would note that with the most recent versions of MS-Windows, it should be possible to set up the Internet access PC so that other PCs on the LAN can access the Internet using so-called "connection sharing". Unfortunately, this will not allow direct access to the PCs on the LAN from the outside (although this may be possible with "secure shell"), but this has some security advantages as well. I was able to make a LAN using a thin Ethernet connection between my laptop and the FS computer so it was verified that the network support was working in the FS computer. Seshan Software At Seshan the new Field System (FS) computer had been set-up prior to or arrival. The station software had been ported from the old computer. Xue Zhuhe had implemented an antcn antenna interface program. We made some minor changes to facilitate pointing checks. I provided some training in Linux operations. Unfortunately we did not have as much time as hoped for training and antenna pointing due to the hardware troubleshooting that was necessary. The antenna interface is largely complete. However there were some remaining issues on the antenna side of the interface that prevented it from being used in the fringe test. This was probably my fault (see below), since I think the issue involved how to handle a request for a particular cable-wrap. A small amount of testing should clear up any uncertainty about whether these aspects are working. The interface provides a capability to command sources using mean epoch coordinates, offsets in Right Ascension-Declination (R.A.-Dec.), and return onsource information. The antcn program is also able to command independent Azimuth-Elevation offsets because it calculates the effective R.A.-Dec. offsets that correspond and add these into any requested R.A.-Dec. offsets. To avoid problems with the effective offsets changing depending on what part of the sky is antenna is in, the FS automatically recalculates the offsets and recommands them whenever the source is changed. A few areas where the antenna side of the interface should be improved are: (1) If a new source is commanded, the antenna should automatically assume that the offsets have been set back to zero. Normally offsets should persist independently of the source. This is for consistency with other stations as well as ease of operation. A simple test of whether this is happening is to get the antenna tracking a source with non-zero offsets. In this state, the source should be recommanded. The antenna should not start to slew away from its current position, but should continue to track smoothly. The servo systems makes a distinctive sound when the antenna starts to slew so it is easy to tell when this happens. (2) The use of the cable wrap flag in source commands to the antenna may not be working correctly. Some effort was applied to testing but because of the nature of the problem it is awkward and tedious to test it. Ideally, the antenna would respond to requests for which cable wrap to use for each source. However, in the short run it may be best to implement an algorithm that takes the antenna by the shortest route that will reach the source regardless of which wrap this will place the antenna on. New guidelines on using cable wrap should become available soon, so it is premature to implement anything else at this time. We spent sometime on this at the station and I apologize for this, but it is what made me realize that new guidelines are needed. (3) Some of the output from the antcn program in the log could be reduced. In general there is no need for the default log messages provided by the default antcn. Normally output generated by the antcn program is limited to error message to specify off-source conditions and the "pr" and "tr" records from the "track" command. Recommendations As implemented, the antenna interface supports the FS "track" SNAP command. It is recommended that the "track" command be included in the "midob" procedure for all experiments. This allows information about the antenna status to be logged for each observation. The command "sy=run setcl &" should also be included in the "midob" procedure for all experiments to track the drift of FS time relative to the formatter. The control room needs a counter, a 53131A is a good choice, to monitor the offset between the Formatter and GPS. This can be connected to the FS and automatically log the offset as "fmout-gps" or "gps-fmout" depending on which signal starts the counter. For a GPS signal the TAC in the adjacent room could be used. The offset between the Formatter and GPS should be logged in each "midob" procedure. It is also recommended that if the station is using a TAC in the Maser with the Showtime software for controlling a TAC, that this software be replaced with the newer TAC32plus software which runs under various flavors of MS-Windows (95, 98, NT, 2000). In any event it is recommended that a TAC be installed in the VLBA equipment room with TAC32plus. This software can also serve as NTP time server for the FS over a LAN. The installation of a TAC in the equipment room will make GPS available without having to carry a stop watch between rooms. In addition it will make a 1 PPS signal available for comparisons with the Formatter. The station should implement a LAN. This would allow the TAC control PC to serve as a time server for the FS computer. It would also allow schedules and logs to be transferred between the FS computer and the computer used for Internet access. As an aside I would note that with the most recent versions of MS-Windows, it should be possible to set up the Internet access PC so that other PCs on the LAN can access the Internet using so-called "connection sharing". Unfortunately, this will not allow direct access to the PCs on the LAN from the outside (although this may be possible with "secure shell"), but this has some security advantages as well. Unlike Nanshan I was not able to make a LAN using a thin Ethernet connection between my laptop and the FS computer. However it was not clear whether this was a problem with the FS computer (hardware or software) or whether there was a problem with the thin Ethernet cabling that was used. If there is a problem with the software, it should be possible to reload the software. The network card costs less than US$100 if that is where the fault lies.