Message 1/466 Ed Himwich Oct 13, 2000 03:17:32 pm -0400 Date: Fri, 13 Oct 2000 15:17:32 -0400 Reply-To: weh@ivscc.gsfc.nasa.gov X-Accept-Language: en To: EVNtech Subject: EVNtech: EVN SW items Sender: owner-evntech@jb.man.ac.uk Precedence: bulk FS Report Ed Himwich, Paul Burgess, John Conway, Dave Graham, Ari Mujunen Oct 13, 2000 Current Status The current version is FS 9.4.15. We plan to release 9.5 in a few weeks. The main bottle neck here is finishing the documentation, doing the final testing, and other obligations on Ed's time. The biggest features in FS 9.5 are support for two drives and K4 racks and recorders. I don't think that these have any impact on any EVN stations. We are hoping to have an improved IFADJUST command that can be used to set IFD and IF3 attenuators automatically. This will include some previsions for recalling saved values. The goal (and we think we can achieve it) is to remove the need to edit procedures for Mark III and IV racks to include explicit attenuators settings. This has been designed both with astronomy (thanks to Jonathann Quick for lots of input on issues related to astronomy) and geodesy experiments in mind so we are hopefully that everyone will be able to use it. Many other small improvements and bug fixes have been included as well. We have been planning for sometime to release a new kernel this fall. This will depend a bit on Ari's availability and whether the kernel release he was planning to use has stabilized or not. New Development This is a rather large topic and covers many areas, many of them motivated by the EVN, but which should also be useful (or necessary in some cases) for geodesy as well. Below I have prepared a wish list of items that might be implemented. There may be others, discussion is still ongoing especially in regard to Tsys improvements. Anyone who wants to suggest other topics please do so. If you won't be at the TOG meeting it is best if I get your comments by Wednesday morning at the latest. If you are going to the meeting advance comments are of course preferred, but we can also discuss things at the meeting. We are trying to finalize this as much as possible at the TOG meeting, so please get your comments in if at all possible. The list is rather terse and goes into extreme detail in some cases since I am primarily trying to make a complete list of the key issues so that they won't be forgotten. Once the list seems to have stabilized we need assess how much work each would represent and assign priorities. The initial list was based on memo by Dave Graham. I. Two head recording A. Swap read/write and write heads 1. Hardware change 2. New calibration schedules 3. Change peak, locate, savev and hdcalc appropriately B. New syntax for second headstack (2:n) items: 1. tracks in repro, tracks, and trackform 2. groups on enable, tracks, and trackform C. Arrange pass index table so that both heads have distinct posns. 1. tapeform accepts 1: and 2: to distinguish headstacks 2. Pass command accepts 1: and 2: to select which tapeform table D. DRUDG generate appropriate procedures E. DRUDG adds pass=other, to move read headstack before every other parity check per direction II. New formatter firmware support A. Add bits/sample to use of /MUX B. Stop using /CON C. Support new /LIM syntax D. Implement rolling 1. New rollform command 2. Transmit rollform table to formatter 3. canned rolls? E. Data modulation control III. IF patching automation I think this depends on hardware that hasn't even been designed yet. We are eagerly awaiting any ideas. IV. Mark IV decoder support It isn't clear what is needed here. The most significant item is probably phase-cal monitoring which is discussed below. I am hoping that the EVN will in fact equip all their stations with these. It is essential to phase-cal monitoring and this in turn will be a very powerful station diagnostic. V. Multiple personalities I am not sure what is needed here on the software side. I suspect that this item is included primarily for simplifying hardware cabling changes. On the software side the change is made by changing a control file and restarting the FS. This could be automated more by making a script to do it. The only other thing to do I think is to make the change on the fly without requiring a restart. But I wonder if either of these are really useful. We could also support any new hardware, assuming it will be computer controllable. There are larger scale personality changes such as from one rack or recorder type to another. One possibility for this would be to have another layer of procedures available from commands. An "equipment" library which would be searched after the experiment library and before the station library. The procedures that depend on the equipment would obviously go in the new library. As a side benefit, this would probably make "station" procedures much easier to maintain. Otherwise this only affects stations with more than one possible back-end. VI. Semi-continuous cal; tsys, wx, and flagging in AIPS format John and I are still discussing tsys issues, but here is a preliminary draft. A. Command improvement 1. Make TPI, TPICAL, and TPZERO robust if some VCs time-out 2. Include detector name in TPI, TPICAL, TPZERO, and TSYSx output lines. B. Continuous (periodic TPI) 1. Formalize periodic measurements C. DRUDG changes 1. generates mode specific PREOB, MIDOB, POSTOB (and SXCTS?) 2. use U, L, or UL for mark IV detectors D. station procedures modified to remove TPI, TPICAL, TPZERO, TSYSx E. Post processing program to generate AIPS format TSYS, WX, and flagging data F. ONOFF changes 0. Additional calculated values? 1. Output reorganized so that 1 line per device for results 2. Allow up to 14(28?) devices G. GNPLT program 1. Modeled on pdplt but handles gain curve and sensitivity data H. Create FLAGR program 1. It would periodically interrogate ANTCN and report status as needed 2. Control file allows interrogation interval to be set 3. Other items to flag? I. Multiple band source fluxes table 1. Can be put in a file 2. By frequency with spectral index. J. Multiple band Tcal table 1. Can be put in a file K. Gain curves in file L. Report Gain Curves (and other info?) in the log. switching below. VII. External Mark IV filter support I'm a little confused on this one. I think the FS/DRUDG support this already. VIII. Frequency (band) switching Perhaps the easiest way to handle this is with station specific LO commands. By moving Tcal and source fluxes into table and files that the FS can use to lookup values it isn't clear if there is any need for bandXX procedures, but I have left the discussion in below in case anyone wants to consider it again. I've talked to Gino a little bit about this. What would be easy to implement would be to have DRUDG include a call to bandXX procedure in the set-up procedure where XX would be two characters that represent the configuration of the first LOs (e.g., bandsx, bandl, or bandc). This procedure could then include setting the caltempN commands and any stations specific commands necessary (if it is possible) to select the front-end. If recommanding these every observation is a problem, the station specific commands need to be smart enough to handle this. This is pretty straightforward except that we have to decide what names to use for various configurations. To minimize the number places changes are needed for this, I would propose that DRUDG calculate the names based on the sky frequencies. Then we just need to define cut-offs. Or do we more flexibility like maybe different procedures for different polarization configurations? I understand that this isn't entirely straightforward. Some bands have more than one rx/LO set-up, but this could still work as long as we can define explicit ranges. Another possibility is to implement this through the LO command. That will take care of the frequency, but other things like cal temps, and maybe fluxes, that you would like to switch by band still need to defined in some way so that FS can get the right ones. Perhaps a pre-defined table is easiest. IX. Phase-cal control monitoring from VEX schedules. This item has a lot of overlap with mark IV decoder support. Our summer student who was going to implement this was cut due to budget problems. 1. Make guts of pcald for Mark IV decoder 2. Make same for VLBA digital switch board X. NEW ITEM: Fast set-up The idea here is that we could shorten the time between sources considerably when there is no head motion and the formatter set-up doesn't change. Head motion is essentially take care of now anyway, but the form command(s) could be taught to not bother setting up the formatter if the current mode is correct. Most other items take minimal (but not zero! time). The change to the form command would eliminate most of the current set-up time. Further reductions would of course be possible if it looks worthwhile to reduce the minimal items as well.