Minutes of the 4th EMU Meeting

Ari Mujunen, Ari.Mujunen@hut.fi v1.1, 27 October 1994 Minutes of the 4th EMU meeting held on the 6th of October 1994 at Effelsberg and on the 7th of October 1994 at MPIfR, Bonn.

Contents

1 Participants 2

1.1 Getting this document in various different formats . . . . . . . . . . . . . . . . . . . . 3 2 On Thursday, 06.10.1994 13:20 3

2.1 Approval of agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Minutes of the previous meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Progress reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 EMU 310: BBCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.1 Filter boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.2 SSB Mixers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.3 Installation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 EMU 320: Tape Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6 EMU 330: Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7 EMU 340: Formatter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8 EMU 350: Read/Write Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 On Friday, 07.10.1994 13:07 9 3.1 Progress reports (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 EMU 400: Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Miscellaneous items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 Tsys measurements and phase calibration . . . . . . . . . . . . . . . . . . . . 11 3.3.2 Matching BBC passbands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.4 Jive hardware engineer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.5 Date of next meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 Production note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1 Participants

The first item in parenthesis indicates an email address and the second item is an abbreviation used to identify a given person in the rest of this document, ie. (email, Abbrev). Action items are later indicated with a boldfaced word “Action:”.

• EMU group:

– Jan Buiter, NFRA (buiter@nfra.nl, Buiter)

– Paul Burgess, Jodrell (pb@jb.man.ac.uk, Burgess)

– Jean Casse, NFRA (jean@nfra.nl, Casse)

– Tony Foley, NFRA (foley@p416arfnfra.nl, Foley)

– Arno Freiholt, MPIfR (p416arf@mpifr-bonn.mpg.de, Freiholt; present on Thursday only)

– David Graham, MPIfR (p062gra@mpifr-bonn-mpg.de, Graham)

– David Holland, Jodrell (dch@jb.man.ac.uk, Holland)

– Ari Mujunen, Metsähovi (Ari.Mujunen@hut.fi, Mujunen)

– Klaus Ruf, MPIfR (kruf@mpifr-bonn.mpg.de, Ruf)

– Richard Schilizzi, NFRA–JIVE (rts@nfra.nl, Schilizzi)

• TWG and station representatives:

– Walter Alef, MPIfR (walef@mpifr-bonn.mpg.de, Alef)

– Mr. Blaschke, MPIfR (*n/a*?, Blaschke; present on Thursday only)

– Mike Garrett, Jodrell (mag@jb.man.ac.uk, Garrett)

– Huib van Langevelde, JIVE–NRAO (hvanlang@nrao.edu, van Langevelde)

– Andrzej Marecki, Torun (amr@astro.uni.torun.pl, Marecki)

– Arno Müskens, MPIfR/Geodesy (geodesy@mpifr-bonn-mpg.de, Müskens)

– Biörn Nilsson, Onsala (bin@oso.chalmers.se, Nilsson)

– Alessandro Orfei, Medicina (orfei@astbo1.bo.cnr.it, Orfei)

– Alok Patnaik, MPIfR (apatnaik@mpifr-bonn.mpg.de, Patnaik; present on Friday only

– Richard Porcas, MPIfR (porcas@mpifr-bonn.mpg.de, Porcas)

– Maria Rioja, JIVE–MPIfR (rioja@mpifr-bonn.mpg.de, Rioja; present on Friday only)

– Jouko Ritakari, Metsähovi (jr@bigbang.hut.fi, Ritakari)

– Hardip Sanghera, JIVE (hss@nfra.nl, JIVE: jive@nfra.nl, Sanghera)

– Liang Shiguang, Shanghai (shocn@bepc2.ihep.ac.cn, Shiguang)

– Gino Tuccari, Noto (tuccari@39005.bo.cnr.it, Tuccari)

– Pablo de Vicente, Yebes (vicente@cay.es, Vicente)

– Michael Wunderlich, MPIfR (p655miw@mpifr-bonn-mpg.de, Wunderlich)

• Absent:

– Ralph Spencer, Jodrell (res@jb.man.ac.uk, Spencer)

– Les Parry, Jodrell (lrp@jb.man.ac.uk, Parry)

– Jaap Bregman, NFRA (jaap@nfra.nl, Bregman)

– Lars Bååth, Onsala (lbb@oso.chalmers.se, Bååth)

The meeting was chaired by Schilizzi, as Spencer was unable to attend.

1.1 Getting this document in various different formats

To get another version of this document:

• SGML version (ftp://bigbang.hut.fi/pub/emu/emumin4.sgml). You will need the linuxdoc-sgml

package to transform this file into other formats. See the section 3.4.

• LaTeX version (ftp://bigbang.hut.fi/pub/emu/emumin4.tex). You will need the linuxdoc-sgml

style  files  to  run  LaTeX  on  this  file.  Unpack  the

  “tar” archive (ftp://bigbang.hut.fi/pub/emu/linuxdoc-styles.tar), in the directory containing

“emumin4.tex”, define the environment variable “setenv TEXINPUTS ":./lib"” and invoke LaTeX “latex emumin4.tex” in the standard way (actually three times to get cross-references right.)

• DVI version of the previous (ftp://bigbang.hut.fi/pub/emu/emumin4.dvi)

• “gzip”  compressed  PostScript  version  of  the  DVI  file

  (ftp://bigbang.hut.fi/pub/emu/emumin4.ps.gz)
• PostScript version of the DVI file (ftp://bigbang.hut.fi/pub/emu/emumin4.ps)
• A “tar” archive of HTML files for WWW (ftp://bigbang.hut.fi/pub/emu/emumin4.tar)
• ASCII only version (ftp://bigbang.hut.fi/pub/emu/emumin4.txt)

2 On Thursday, 06.10.1994 13:20

Schilizzi welcomed all present and opened the meeting.

2.1 Approval of agenda

The following was approved as the agenda of this meeting:

1. Approval of agenda 2. Matters arising from imaginary meeting via email on 20 July

3. Progress reports and discussion of next steps on:

• EMU 310 Baseband converters • EMU 320 Tape path upgrade • EMU 330 Decoder

• EMU 340 Formatter

• EMU 350 Read/Write Electronics • EMU 400 Computing

4. Documentation

5. Jive hardware engineer?

6. Matching BBC passbands

7. AOB

8. Date of next meeting

2.2 Minutes of the previous meeting

The results of the previous EMU meeting, an email teleconference held around 20.07.1994 were presented by Schilizzi based on notes and memos by Spencer.

Bååth had investigated possible phase cal solutions and come into the conclusion that an analog add-on system will not suffice and measurement after sampling is eventually required. This cannot be fitted into MarkIV formatter, however (see 2.7).

Buiter had found out that the back diodes (BD7) for the total power detector in the new video converter filter boards were readily available. He hadn’t ordered them, though, because the newest Alan Rogers design doesn’t use them (see 2.4.1).

Burgess had studied test procedures of DAR equipment and investigated field system alternatives (NASA FS, Darfs.)

Foley concluded that a comprehensive list of MarkIII, VLBA, and MarkIV modes is very difficult to assemble because nobody really knows all the variations that can be devised. There was a comment about a listing of VLBA modes by Alan Whitney (at NRAO), and another listing by Brian Anderson (at Jodrell).

Action: Foley to contact these two sources to include this information in the mode list.

Mujunen had been at Jodrell in May for a week. During this time Linux was installed on one machine and NASA FS 8.x source code was transferred to it. A listing of issues encountered during reccompilation of this

system under Linux can be found at (ftp://bigbang.hut.fi/pub/emu/fs8RemakeOnLinux.txt).

Parry had measured new video converter filter boards and the results are presented later in the section 2.4.1.

Ruf had investigated the possibility of getting “second-hand” precision plates for tape recorders. This is presented in further detail in the section 2.5.

2.3 Progress reports

Schilizzi asked individual teams to present verbally the current status of the various EMU subprojects.

2.4 EMU 310: BBCs

Holland told that the new design that replaces back diodes (see 2.2) with Analog Devices chips had been received from Alan Rogers at Haystack. Prototype boards should be ready in a week and materials for 160 boards had been acquired. Holland further assumed that 8 weeks would be sufficient for putting the boards together.

2.4.1 Filter boards

Holland continued that he and Parry had measured the performance of new 4 MHz filters. Phase changes seemed linear—the results were circulated in the meeting. The cost of new filter boards was estimated at 87 ECUs each (a saving of 111 ECUs compared to estimates.) A low-frequency network analyzer will be rented for testing the new filter boards.

2.4.2 SSB Mixers

Buiter reported that new precision chip capacitors for SSB boards had been ordered and received and he handed the capacitors to Holland. Buiter also reminded that previously it had been decided that every station changes capacitors and installs new filter boards by themselves. Holland estimated that new boards would be ready for installation in about 10 weeks. This could enable installation during January 1995. Graham reminded that there is a VLBI session in February 1995 that shouldn’t be compromised by ongoing filter changes.

Ritakari warned the meeting about the possibility that changing the capacitors alone might not be sufficient to achieve desired performance out of the modified SSB mixer boards. Graham suggested that this can be checked by frequency sweeping and Ritakari confirmed that by sweeping slowly around a number of different center frequencies SSB mixer operation can be verified. Ritakari stated that changing only capacitors in SSB mixers to attain 8MHz and 16MHz bands apparently eliminates two of the narrowest bands.

2.4.3 Installation Issues

Garrett suggested that each station should upgrade one BBC first to check its performance and possibly have it up and running in a session. Graham disliked this idea and recommended upgrading all BBCs at once but not before February 1995 session and not before the 18cm lines experiment. The meeting estimated the duration of this upgrade to be around two weeks per station.

Porcas raised the issue about registering the completion of BBC upgrades at the correlators (Bonn:

mpicor@mpifr-bonn.mpg.de and Socorro: vlbacorr@aoc.nrao.edu). This would enable correlator op-

erators to invalidate assumptions about station behavior as hardware had been changed.

Graham noted that those stations which do not currently have 4MHz filter wouldn’t have them after the upgrade either. Three stations confirmed that they have them and Alef suspected that he would be surprised if everybody didn’t have them already.

Action: Hardip to find out whether all Mark III stations (including affiliated telescopes such as Urumqi and Simeiz) already have 4MHz filters or not.

Holland noted that additional filter PC boards have been made that can be populated later. Schilizzi reminded that no funding had been allocated for Simeiz, Urumqi etc.

Action: All stations, after a completed BBC upgrade, please send email to Spencer, Alef, and van Langevelde. (See section 1 for an address list.) If your station participates geodetic experiments, please remember to inform Haystack correlator, too.

While searching for optimum timing for BBC upgrade Burgess summarized that assuming that filter boards are delivered fully tested it should take about 1–2 weeks to install them, so it would make sense to start installation at least about two weeks before next session. As the first session in 1995 will start on 08.02.1994 and the second is expected in May, Schilizzi suggested that starting the BBC upgrade around 15.01.1995 at the stations would allow for about three weeks for the installation to successfully complete. Nilsson added that stations participating in geodetic experiments have additional time constraints.

Action: All geodetic stations, find out a suitable three-week time slot for the upgrade.

(Editor’s note: When I told about the timing plans to our VLBI friend Kaj Wiik at Metsähovi, he suggested that it might be wise to upgrade exactly one BBC at Jodrell first and then to use it in a session, preferably a CAL one. If something unexpected is discovered, the boards can still be modified before shipping them to the stations for installation.)

2.5 EMU 320: Tape Path

Ruf had contacted Jon Romney at Haystack about the new precision plates but Romney had declined to answer.

Ruf explained that the only problem remaining with tape path upgrade is the high cost (about $8000 each) and long delivery time of original Metrum precision plates. In principle new precision plated could be manufactured in Europe, perhaps using old standard spare plates or standard plates that were left over when NRAO upgraded all their VLBA recorders as starting points. Even one spare plate would be sufficient if precision plates were built one at a time and each dismantled old plate was used as raw material for next precision plate.

Workshops need complete drawings of items to be manufactured, however—and this is not the case with the precision plate design. Drawings are apparently Metrum proprietary and recreating them is a time-consuming task for which Ruf wasn’t sure time could be found at MPIfR.

Alef noted that there might have been a reason behind NRAO decision to completely replace the plates of their twenty-or-so recorders.

Action: Ruf to find out why this occurred. George Peck at NRAO and also van Langevelde need to be contacted.

Ruf estimated that the number of upgrades needed is around 10–20 and that MPIfR could possibly fabricate about 7–11 of them if detailed drawings were available. He asked for help in making these drawings. Porcas warned about copying.

Action: Ruf to contact Spencer about making drawings.

Alef asked whether old plates really are upgradable. Ruf told that only ceramic and copper inserts are different.

Foley asked if Metrum could be persuaded into upgrading old plates for us. Ruf and Graham doubted this.

Action: Ruf and van Langevelde should ask Metrum and Hans Hinteregger, George Peck, and/or Peter Bolis at NRAO

• Will Metrum upgrade?

• What happened to old plates at VLBA?

• Are ceramic inserts available? Less than 1000/order?

Schilizzi suggested an action item to check for available mechanical workshop time.

Action: All observatories please check the availability of mechanical workshop facilities in a timescale of one year and report this to Ruf.

Foley asked whether the tape path upgrade will take care of new damper rollers and idle roller sleeves that were introduced in TWG meeting and additionally Alef wanted to know whether EVN VLBA recorders are to be included in the tape path upgrade.

Schilizzi noted that damper rollers ($2000 each) were not included in the original cost estimates and Spencer has to be informed about this. Fortunately only few dampers are needed because apparently for example all VLBA and some MkIIIA recorders already have the new dampers et al. He also mentioned that the inclusion of VLBA recorders was not initially intended but that these might be eventually included. Ruf added that he had had the impression in previous EMU meetings that EVN VLBA recorders would all eventually receive the thin tape upgrade.

Alef and Graham wanted to verify the reason behind damper roller change and it was assumed that tracking would improve.

Ruf stated that it would take two months for Metrum to deliver new damper rollers and Blaschke verified that their installation was a simple matter: three screws and 10 minutes were required for installation plus a calibration tape check.

Action: Ruf orders idler roller sleeves and damper rollers for those stations that have listed him the items they don’t have in their recorders. Mujunen suggested that Action: All stations tell Ruf what you need before 14.10.1994 so Ruf can order items early enough.

2.6 EMU 330: Decoder

Spencer had received a message from Haystack that adding an output after sampler for phase calibration electronics wouldn’t be possible in formatter. Burgess verified that 8MHz is the maximum sampling speed that can be attained with current decoder hardware and that it probably cannot be easily modified for higher speeds. Bregman had originally devised a new high-speed interface to the current data buffer to relieve the current bottleneck of 9600 baud serial link. Buiter and Foley reminded that the decoder is not needed for phase calibration only but for “read-back” purposes as well. Schilizzi asked if we could use VLBA hardware design. Graham probably no.

What is needed can be summarized as follows:

1. Parity error estimates (readability)

2. Time code from recorded frames

3. Phase calibration of channels/tracks

These would be desirable at 8 and 16 MHz, too.

Graham acknowledged that modifying the buffer at 16 MHz is not recommendable. He added that fast reading of buffer into the field system is not actually needed except for getting phase cal readings more often than some minutes apart. Readability checks can be performed with the current slow rate quite well.

Graham added that it should be possible to check recordings by playing back at half speed. Perhaps it would be tolerable if bypass mode and read-after-write cannot be used at 8 and 16 MHz.

Porcas mentioned real time fringe tests: performing them by using for example Internet “ftp” to transfer data buffers would actually benefit from >9600 baud transfer rates.

Mujunen, Porcas, and van Langevelde questioned the necessity of frequent phase cal information. PIs frequently have to drop phase cal information provided by Bonn correlator are substitute information deduced from strong calibrator sources. Unless phase cal signal is fed near feed at receiver and special electronics in VLBA style is used, the phase cal readings provided by stations might end up ignored by PIs.

Graham suggested looking into simple modifications to increase current data buffer input rate from 4 -> 8 MHz. Buiter raised his concerns that the design might refuse to work at 8 MHz.

Action: Spencer should do something.

2.7 EMU 340: Formatter

Freiholt had received an email message from Jim Levine (at Haystack) on 03.10.1994 stating that a prototype should be ready before the end of this year. The message politely turned down EVN offers to help documenting and testing the prototype—financial support would be welcomed.

Action: Spencer should continue discussions with Alan Whitney at Haystack whether anything can be done to speed up formatter development and whether EVN help can help during testing and documenting stages.

Freiholt continued that he had been able to find at least two companies capable of and interested in building the formatters, but complete manufacturing documents are a strict prerequisite for them.

Ritakari used the opportunity to remind the meeting that manufacturers of magnetic media (commercial hard disk drives etc.) have since long abandoned the ordinary MFM-NRZM encoding that is used in MkIIIA, VLBA, and MkIV. By simply using RLL encoding instead of MFM a 25% increase in bit density is achieved.

Furthermore, current decoding chips utilize PRML predictive decoding techniques to reconstruct bit streams out of less-than-ideal raw data. Looking a little into detail in modern commercial techniques of writing and reading of magnetic media could well result in two-threefold increase of bit density on tape.

Action: Ritakari to prepare a proposal based on his ideas.

2.8 EMU 350: Read/Write Electronics

Mujunen and Ritakari presented at the meeting:

• a completed I/O board

• a prototype read board

• a prototype write board

• a prototype power distributor board

• a mechanical prototype of head preamplifier board

All eletronic components had been ordered and received. AEC/NIM boxes were being made. All PCB board designs except for the read board were completed and PCBs had been ordered from a manufacturer. Head interface boards (nearest to the actual head) will be produced with original Haystack PCB films although their pad dimensions are not ideal.

Mujunen asked the five station representatives where these new four AEC/NIM modules could be put in their recorders. The responses and the Effelsberg recorder showed that significant variations and thus mechanical problems can be expected.

Action: The five stations receiving the upgrade, please send photographs of your MarkIIIA recorder to Metsähovi. After this Metsähovi will try to resolve a common solution. Although additional 19” AEC/NIM subracks are not included in the R/W electronics contract, Metsähovi will make inquiries about where these subracks could be obtained.

3 On Friday, 07.10.1994 13:07

3.1 Progress reports (cont.)

Progress reports continued with the last subproject, EMU 400.

3.2 EMU 400: Computing

Schilizzi asked Mujunen to present his views about the most appropriate approach that EVN should take regarding field system software that will be used at the upgraded MarkIV stations.

Mujunen began by pointing out the diversity of field systems currently in use at EVN stations. The following table was created at the meeting:

     System name   Hardware  Op.sys.  DAR    Used at
     -----------------------------------------------
     NASA FS8.x    PC        Venix    MkIII  Westerbork, Medicina, Yebes
                                             Shanghai,
                                             apparently Urumqi, Simeiz,
                                             Hartebeesthoek
     NASA FS8.x    PC        Venix    VLBA   Noto
     NASA FS       HP1000    RTE      MkIII  Onsala
     Darfs         PC        DOS      VLBA   Cambridge, Metsahovi,
                                             apparently Torun
     Barfs         PC        DOS      VLBA   Pico Veleta
     MK3PC         PC        DOS      MkIII  Jodrell
     PCFS          PC        DOS      MkIII  Effelsberg
     VLBA          VME680x0  VXworks  VLBA   Effelsberg (and VLBA)
     PCASTR        PC        DOS      VLBA   Russia, app. Ussuriisk

All three variations of “NASA FS” share a common FORTRAN code base. “Barfs” is a variation of “Darfs” and also “MK3PC” shares much of Darfs Turbo Pascal code. “PCFS” is a unique program written in QuickBasic and “PCASTR” borrows most of its C code from NRAO standard “VLBA” station control software written in C. Some statistic comparisons between NASA FS and Darfs are presented in the text file

(ftp://bigbang.hut.fi/pub/emu/fsEvaluation1.txt).

Schilizzi summarized that what EVN would need is a consistent field system compatible with VLBA and VLBA correlator. He then went on to find a recommendation for the base of this system.

Schilizzi asked Mujunen about the consequences of EVN supporting the NASA FS which seems to be the most popular at the moment. Mujunen wanted to hear the opinions of Burgess as he has had good insight into original NASA FS code on HP1000s.

Burgess listed high cost, difficulties in station-specific code, antiquated source code, and the “speed converter” (a second PC) for VLBA MCB bus among the reasons against NASA FS with Venix. Mujunen added to that general maintenance difficulties caused by antiquated program structure that once was dictated by HP1000 limitations. He also described FS source code as “fluffy”, meaning that the same functionality can be achieved with at least 80% less source code with modern tools. Unmanageable program structure and its fluffiness would most severy hamper introducing those new features that are needed for EVN to be “VLBA correlator compliant”. Porcas reminded that the need for EVN modifications has been made clear in Friday’s meetings.

Foley defended the FS by saying that although it is not bulletproof, it performs mainly ok. TCP/IP networking cannot be actually used in Venix because it can crash the system—very undesirable during a session. Burgess noted that any operating system is bound to have difficulties with PC hardware when I/O bandwidth is exceeded. (Editor’s note: Apparently network software crashing the whole Venix system is not due to excessive I/O bandwidth. This problem has occurred in many unmature and little tested Unixen on PC hardware—even Linux used to crash with network-related causes in its early development versions in 1993.)

Mujunen then asked Graham whether the NRAO “VLBA” station system would be a viable alternative. Graham noted that it is suitable for VLBA DARs only and that it would like to have VLBA-style infraand interstation infrastructure in its control. Graham also reminded the European stations with VLBA DARs that in order to use barrel roll in their formatters both new formatter firmware and the new Digital Switching Module are required—the latter is required only because the former won’t run without it.

Porcas pleaded for reducing the current diversion of field systems.

Reasons for why a given system wouldn’t be suitable as the recommended EVN system were found as follows:

     System name   Reason
     --------------------
     VLBA          VLBA DARs only.
     PCASTR        Adaptation of old buggy VLBA.
     PCFS          Unique to Effelsberg.
     NASA FS8.x    NASA vs. MarkIV modes, VLBA correlator?

Mujunen asked the meeting how they felt about NASA adding MarkIV features to the field system. Graham replied that he would expect all possibilities available in MarkIV formatter to be included eventually, but that he would be very surprised if VLBA DAR/formatter was ever completely supported.

Schilizzi then wanted to know whether we could run NASA FS on Linux. Mujunen replied that although this would relieve the cost factor, we would still face difficulties in adding the required level of compatiblity with VLBA.

After this Schilizzi asked Burgess and Mujunen about the consequences of EVN supporting Darfs which seemed to be the only option left on the list. They suspected that EVN support is needed as neither Darfs nor MK3PC are currently “turnkey” solutions that can be readily run at any station without additional work.

Action: Mujunen looks into Darfs, MK3PC, and—where appropriate—NASA FS source code and prepares a recommendation for EVN within three months. The expected way to proceed is to consolidate Darfs, MK3PC, and desired functionality from NASA FS into a new software package that can be run on PC hardware.

3.3 Miscellaneous items

3.3.1 Tsys measurements and phase calibration

Much in the same way as with providing GPS–H-maser time differences in machine logs, most EVN stations have problems with one or more of the following items:

1. Only high-level noise diodes are available that cannot be switched on during tape passes, thus no Tsys values can be taken during a pass.

2. Noise diodes cannot be remotely controlled by the field system computer. This prevents using all BBCs to get Tsys of all channels separately. Also this makes synchronizing Tsys measurements to schedules much more difficult.

3. Resulting Tsys figures are not recorded in machine-readable form and if they are, they are not directly usable by PIs (=not in AIPS ANCAL format.)

4. Sanity checks are not routinely performed on Tsys data—absurd values are offered to PIs.

Graham mentioned about a method of following total power output changes during the scans and estimating Tsys by assuming the effect of noise diode constant during the scan. This might help in case 1) of high-level noise diodes. When using VLBA BBCs automatic gain control must be taken into account and AGC value must be read in addition to TPI value—which addmittedly should be around 1.0 when AGC is in effect.

Action: ??? Somebody should verify whether this method would work. Graham? Nancy Vandenberg at NASA? Apparently unstable receivers would be problematic with this approach.

A short survey of different ways of getting Tsys info at various EVN station, requested by Mujunen, showed the following:

     Station     Noise diode   Remote  Channels  Interval
     ----------------------------------------------------
     Effelsberg  High-level    No      ?         ?
     Metsahovi   Medium-level  Yes     All       BOP,EOP
     Jodrell     High-level    No      1         ?
     Onsala      ?             ?       ?         ?
     Shanghai    ?             Yes     All       BOP,EOP
     Westerbork  ?             No      1         10 secs

(BOP=Beginning of tape pass, EOP=End of tape pass, ?=not discussed)

Action: All VLBI Technical Friends: The aim of all EVN stations should be to provide Tsys information of each channel in 1–2 minute intervals in a machine-readable format useful to PIs.

3.3.2 Matching BBC passbands

This item was not processed in detail at the meeting. Schilizzi conveyed a message from Spencer that most of them came from the same factory but at least Jodrell has a few home-built ones.

3.3.3 Documentation

The meeting relied on that the different subgroups working on the upgrade will provide their own documentation of their own modules in professional manner. It is also a responsibility of individual teams to include appropriate and current Haystack documentation in their docs.

3.3.4 Jive hardware engineer?

Schilizzi brought up the idea of having a dedicated hardware engineer at Jive. The meeting discussed various ways (s)he could be useful in recorder testing etc. TWG felt that this subject should be brought to the EVN directors meeting.

3.3.5 Date of next meeting

The date of next meeting was left to Spencer to decide.

Action: Spencer to negotiate via email a suitable date for the next meeting.

Buiter announced that a MAT bus tester has been built at Dwingeloo. It is based on a Haystack design and can be made available if need for volume MAT testing arises.

3.4 Production note

This document is written using the linuxdoc-sgml DTD. SGML stands for “Structured Generalized Markup Language” and I chose SGML for this document because SGML is made specifically for translation to other formats. SGML allows you to specify the structure of a document—that is, what kinds of things make up the document. You specify the structure of a document with a DTD (Document Type Definition). linuxdoc-sgml is one DTD that specifies the structure for Linux HOWTOs and other docs. QWERTZ is another DTD; the SGML standard provides DTD’s for books, articles, and other generic document types.

For further information about software used to process this document, the linuxdoc-sgml package by Matt

Welsh, please refer to the text file (ftp://bigbang.hut.fi/pub/emu/linuxdoc-guide.txt).