\documentstyle[linuxdoc-sgml,qwertz,null]{article}
\input{epsf.tex}
\title{Minutes of the 4th EMU Meeting}
\author{Ari Mujunen, {\tt Ari.Mujunen@hut.fi}}
\date{v1.1, 27 October 1994}
\abstract{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.}


\begin{document}
\maketitle
\tableofcontents

\section{Participants \label{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. {\tt (email,} {\em Abbrev).\/}  Action items are later
indicated with a boldfaced word ``{\bf Action:}''.

\begin{itemize}
\item  EMU group:
\begin{itemize}
\item  Jan Buiter, NFRA {\tt (buiter@nfra.nl,} {\em Buiter)\/}
\item  Paul Burgess, Jodrell {\tt (pb@jb.man.ac.uk,} {\em Burgess)\/}
\item  Jean Casse, NFRA {\tt (jean@nfra.nl,} {\em Casse)\/}
\item  Tony Foley, NFRA {\tt (foley@p416arfnfra.nl,} {\em Foley)\/}
\item  Arno Freiholt, MPIfR {\tt (p416arf@mpifr-bonn.mpg.de,}
{\em Freiholt;\/} present on Thursday only)
\item  David Graham, MPIfR {\tt (p062gra@mpifr-bonn-mpg.de,} {\em Graham)\/}
\item  David Holland, Jodrell {\tt (dch@jb.man.ac.uk,} {\em Holland)\/}
\item  Ari Mujunen, Mets\"{a}hovi {\tt (Ari.Mujunen@hut.fi,} {\em Mujunen)\/} 
\item  Klaus Ruf, MPIfR {\tt (kruf@mpifr-bonn.mpg.de,} {\em Ruf)\/}
\item  Richard Schilizzi, NFRA--JIVE {\tt (rts@nfra.nl,} {\em Schilizzi)\/}
\end{itemize}
\item  TWG and station representatives:
\begin{itemize}
\item  Walter Alef, MPIfR {\tt (walef@mpifr-bonn.mpg.de,} {\em Alef)\/}
\item  Mr. Blaschke, MPIfR {\tt (*n/a*?,} {\em Blaschke;\/}
present on Thursday only)
\item  Mike Garrett, Jodrell {\tt (mag@jb.man.ac.uk,} {\em Garrett)\/}
\item  Huib van Langevelde, JIVE--NRAO {\tt (hvanlang@nrao.edu,} {\em van Langevelde)\/}
\item  Andrzej Marecki, Torun {\tt (amr@astro.uni.torun.pl,} {\em Marecki)\/}
\item  Arno M\"{u}skens, MPIfR/Geodesy {\tt (geodesy@mpifr-bonn-mpg.de,} {\em M\"{u}skens)\/}
\item  Bi\"{o}rn Nilsson, Onsala {\tt (bin@oso.chalmers.se,} {\em Nilsson)\/}
\item  Alessandro Orfei, Medicina {\tt (orfei@astbo1.bo.cnr.it,} {\em Orfei)\/} 
\item  Alok Patnaik, MPIfR {\tt (apatnaik@mpifr-bonn.mpg.de,}
{\em Patnaik;\/} present on Friday only
\item  Richard Porcas, MPIfR {\tt (porcas@mpifr-bonn.mpg.de,} {\em Porcas)\/}
\item  Maria Rioja, JIVE--MPIfR {\tt (rioja@mpifr-bonn.mpg.de,}
{\em Rioja;\/} present on Friday only)
\item  Jouko Ritakari, Mets\"{a}hovi {\tt (jr@bigbang.hut.fi,} {\em Ritakari)\/}
\item  Hardip Sanghera, JIVE {\tt (hss@nfra.nl,} JIVE: {\tt jive@nfra.nl,} {\em Sanghera)\/}
\item  Liang Shiguang, Shanghai {\tt (shocn@bepc2.ihep.ac.cn,} {\em Shiguang)\/}
\item  Gino Tuccari, Noto {\tt (tuccari@39005.bo.cnr.it,} {\em Tuccari)\/}
\item  Pablo de Vicente, Yebes {\tt (vicente@cay.es,} {\em Vicente)\/}
\item  Michael Wunderlich, MPIfR {\tt (p655miw@mpifr-bonn-mpg.de,} {\em Wunderlich)\/}
\end{itemize}
\item  Absent:
\begin{itemize}
\item  Ralph Spencer, Jodrell {\tt (res@jb.man.ac.uk,} {\em Spencer)\/}
\item  Les Parry, Jodrell {\tt (lrp@jb.man.ac.uk,} {\em Parry)\/}
\item  Jaap Bregman, NFRA {\tt (jaap@nfra.nl,} {\em Bregman)\/}
\item  Lars B{\aa}{\aa}th, Onsala {\tt (lbb@oso.chalmers.se,} {\em B{\aa}{\aa}th)\/}
\end{itemize}
\end{itemize}


The meeting was chaired by {\em Schilizzi,\/} as {\em Spencer\/} was
unable to attend.




\subsection{Getting this document in various different formats}

To get another version of this document:
\begin{itemize}
\item  SGML version \url{ftp://bigbang.hut.fi/pub/emu/emumin4.sgml}{}.
You will need the {\tt linuxdoc-sgml} package to transform this
file into other formats.  See the section
\ref{production note}. 
\item  LaTeX version \url{ftp://bigbang.hut.fi/pub/emu/emumin4.tex}{}.
You will need the {\tt linuxdoc-sgml} style files to run LaTeX
on this file.  Unpack the ``tar'' archive
\url{ftp://bigbang.hut.fi/pub/emu/linuxdoc-styles.tar}{},
in the directory containing ``{\tt emumin4.tex}'', define
the environment variable 
``{\tt setenv TEXINPUTS ":./lib"}'' and invoke LaTeX
``{\tt latex emumin4.tex}'' in the standard way (actually
three times to get cross-references right.)
\item  DVI version of the previous \url{ftp://bigbang.hut.fi/pub/emu/emumin4.dvi}{}
\item  ``gzip'' compressed PostScript version of the DVI file \url{ftp://bigbang.hut.fi/pub/emu/emumin4.ps.gz}{}
\item  PostScript version of the DVI file \url{ftp://bigbang.hut.fi/pub/emu/emumin4.ps}{}
\item  A ``tar'' archive of HTML files for WWW \url{ftp://bigbang.hut.fi/pub/emu/emumin4.tar}{}
\item  ASCII only version \url{ftp://bigbang.hut.fi/pub/emu/emumin4.txt}{}
\end{itemize}







\section{On Thursday, 06.10.1994 13:20}

{\em Schilizzi\/} welcomed all present and opened the meeting.




\subsection{Approval of agenda}

The following was approved as the agenda of this meeting:

\begin{enumerate}
\item  Approval of agenda
\item  Matters arising from imaginary meeting via email on 20 July
\item  Progress reports and discussion of next steps on:
\begin{itemize}
\item  EMU 310 Baseband converters
\item  EMU 320 Tape path upgrade
\item  EMU 330 Decoder
\item  EMU 340 Formatter
\item  EMU 350 Read/Write Electronics
\item  EMU 400 Computing
\end{itemize}
\item  Documentation
\item  Jive hardware engineer?
\item  Matching BBC passbands
\item  AOB
\item  Date of next meeting
\end{enumerate}





\subsection{Minutes of the previous meeting}

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

{\em B{\aa}{\aa}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
\ref{formatter}). 

\label{back diodes}{\em 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 \ref{about filters}).

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

{\em 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).

{\bf Action:} {\em Foley\/} to contact these two sources to include this
information in the mode list.

{\em 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
\url{ftp://bigbang.hut.fi/pub/emu/fs8RemakeOnLinux.txt}{}.

{\em Parry\/} had measured new video converter filter boards and the
results are presented later in the section \ref{about filters}.

{\em Ruf\/} had investigated the possibility of getting ``second-hand''
precision plates for tape recorders.  This is presented in further
detail in the section \ref{about tape path upgrade}.




\subsection{Progress reports}

{\em Schilizzi\/} asked individual teams to present verbally the current
status of the various EMU subprojects.




\subsection{EMU 310: BBCs}

{\em Holland\/} told that the new design that replaces back
diodes (see \ref{back diodes}) 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.
{\em Holland\/} further assumed that 8 weeks would be sufficient for
putting the boards together.




\subsubsection{Filter boards \label{about filters}}

{\em Holland\/} continued that he and {\em 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.




\subsubsection{SSB Mixers}

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

{\em 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.  {\em Graham\/}
suggested that this can be checked by frequency sweeping and
{\em Ritakari\/} confirmed that by sweeping slowly around a number of
different center frequencies SSB mixer operation can be verified.
{\em Ritakari\/} stated that changing only capacitors in SSB mixers to
attain 8MHz and 16MHz bands apparently eliminates two of the narrowest
bands. 




\subsubsection{Installation Issues}

{\em Garrett\/} suggested that each station should upgrade one BBC first
to check its performance and possibly have it up and running in a session.
{\em 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.

{\em Porcas\/} raised the issue about registering the completion of BBC
upgrades at the correlators (Bonn: {\tt mpicor@mpifr-bonn.mpg.de}
and Socorro: {\tt vlbacorr@aoc.nrao.edu}).  This would enable
correlator operators to invalidate assumptions about station behavior
as hardware had been changed.

{\em 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 {\em Alef\/} suspected that he would be
surprised if everybody didn't have them already.

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

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

{\bf Action:} {\em All stations,\/} after a completed BBC upgrade, please
send email to {\em Spencer, Alef,\/} and {\em van Langevelde.\/}  (See section
\ref{participants} 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 {\em 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, {\em 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.  {\em Nilsson\/} added that
stations participating in geodetic experiments have additional
time constraints.

{\bf Action:} {\em 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\"{a}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.)




\subsection{EMU 320: Tape Path \label{about tape path upgrade}}

{\em Ruf\/} had contacted Jon Romney at Haystack about the new precision
plates but Romney had declined to answer.

{\em 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 {\em Ruf\/} wasn't sure time could be found
at MPIfR.

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

{\bf Action:} {\em Ruf\/} to find out why this occurred.
George Peck at NRAO and also {\em van Langevelde\/} need to be contacted.

{\em 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.  {\em Porcas\/} warned about copying.

{\bf Action:} {\em Ruf\/} to contact {\em Spencer\/} about making
drawings.

{\em Alef\/} asked whether old plates really are upgradable.
{\em Ruf\/} told that only ceramic and copper inserts are different.

{\em Foley\/} asked if Metrum could be persuaded into upgrading old
plates for us.  {\em Ruf\/} and {\em Graham\/} doubted this.

{\bf Action:} {\em Ruf\/} and
{\em van Langevelde\/} should ask
Metrum and Hans Hinteregger, George Peck, and/or Peter Bolis at NRAO
\begin{itemize}
\item  Will Metrum upgrade?
\item  What happened to old plates at VLBA?
\item  Are ceramic inserts available?  Less than 1000/order?
\end{itemize}


{\em Schilizzi\/} suggested an action item to check for available
mechanical workshop time.

{\bf Action:} {\em All observatories\/} please
check the availability of mechanical workshop facilities in a
timescale of one year and report this to {\em Ruf.\/}

{\em 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 {\em Alef\/} wanted to know whether EVN VLBA
recorders are to be included in the tape path upgrade.

{\em Schilizzi\/} noted that damper rollers (\$2000 each) were not
included in the original cost estimates and {\em 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.  {\em Ruf\/} added that he had had the
impression in previous EMU meetings that EVN VLBA recorders would
all eventually receive the thin tape upgrade.

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

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

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






\subsection{EMU 330: Decoder}

{\em Spencer\/} had received a message from Haystack that adding an
output after sampler for phase calibration electronics wouldn't be
possible in formatter.  {\em 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.  {\em Bregman\/} had originally devised a new high-speed
interface to the current data buffer to relieve the current bottleneck
of 9600 baud serial link.  {\em Buiter\/} and {\em Foley\/}
reminded that the decoder is 
not needed 
for phase calibration only but for ``read-back'' purposes as well.
{\em Schilizzi\/} asked if we could use VLBA hardware design.
{\em Graham\/} probably no.

What is needed can be summarized as follows:
\begin{enumerate}
\item  Parity error estimates (readability)
\item  Time code from recorded frames
\item  Phase calibration of channels/tracks
\end{enumerate}

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

{\em 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.

{\em 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.

{\em 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.

{\em Mujunen, Porcas,\/} and {\em 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.

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

{\bf Action:} {\em Spencer\/} should do
something.






\subsection{EMU 340: Formatter \label{formatter}}

{\em 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.

{\bf Action:} {\em 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.

{\em 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.

{\em 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.

{\bf Action:} {\em Ritakari\/} to prepare a proposal based on his ideas.






\subsection{EMU 350: Read/Write Electronics}

{\em Mujunen\/} and {\em Ritakari\/} presented at the meeting:
\begin{itemize}
\item  a completed I/O board
\item  a prototype read board
\item  a prototype write board
\item  a prototype power distributor board
\item  a mechanical prototype of head preamplifier board
\end{itemize}


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.

{\em 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.

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






\section{On Friday, 07.10.1994 13:07}


\subsection{Progress reports (cont.)}

Progress reports continued with the last subproject, EMU 400.




\subsection{EMU 400: Computing}

{\em Schilizzi\/} asked {\em 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.

{\em Mujunen\/} began by pointing out the diversity of field systems
currently in use at EVN stations.  The following table was created at
the meeting:
\begin{tscreen}
\par
\addvspace{\medskipamount}
\nopagebreak\hrule
\begin{verbatim}
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
\end{verbatim} 
\nopagebreak\hrule 
\addvspace{\medskipamount}
\end{tscreen}


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
\url{ftp://bigbang.hut.fi/pub/emu/fsEvaluation1.txt}{}.

{\em 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.

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

{\em 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.  {\em 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''.  {\em Porcas\/} reminded that the need for EVN
modifications has been made clear in Friday's meetings.

{\em 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.  {\em 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.)

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

{\em 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:
\begin{tscreen}
\par
\addvspace{\medskipamount}
\nopagebreak\hrule
\begin{verbatim}
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?
\end{verbatim} 
\nopagebreak\hrule 
\addvspace{\medskipamount}
\end{tscreen}


{\em Mujunen\/} asked the meeting how they felt about NASA adding MarkIV
features to the field system.  {\em 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.

{\em Schilizzi\/} then wanted to know whether we could run NASA FS on
Linux.  {\em 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 {\em Schilizzi\/} asked {\em Burgess\/} and {\em 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.

{\bf Action:} {\em 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.




\subsection{Miscellaneous items}


\subsubsection{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:
\begin{enumerate}
\item  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.
\item  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.
\item  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.)
\item  Sanity checks are not routinely performed on Tsys
data---absurd values are offered to PIs.
\end{enumerate}


{\em 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.

{\bf Action:} {\em ???\/} Somebody should verify whether this method
would work.  {\em 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 {\em Mujunen,\/} showed the following:
\begin{tscreen}
\par
\addvspace{\medskipamount}
\nopagebreak\hrule
\begin{verbatim}
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
\end{verbatim} 
\nopagebreak\hrule 
\addvspace{\medskipamount}
\end{tscreen}

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

{\bf Action:} {\em 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.




\subsubsection{Matching BBC passbands}

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




\subsubsection{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. 




\subsubsection{Jive hardware engineer?}

{\em 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.




\subsubsection{Date of next meeting}

The date of next meeting was left to {\em Spencer\/} to decide.

{\bf Action:} {\em Spencer\/} to negotiate via email a suitable date for
the next meeting.

{\em 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.






\subsection{Production note \label{production note}}

This document is written using the {\tt 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 {\em 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). {\tt 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 {\tt linuxdoc-sgml} package by Matt Welsh, please refer to the text
file \url{ftp://bigbang.hut.fi/pub/emu/linuxdoc-guide.txt}{}.



\end{document}
