WFD plan Jan 95

Ed Kearns (kearns@budoe.bu.edu)
Mon, 23 Jan 1995 13:03:20 GMT

This is the WFD plan-O-action for Jan 23, 1995. I outline some of the
steps we have to take to move the WFD system towards completion. There
are items listed for the ultimate goal of stable 6 SM running for LIPs
and monopoles as well as the near-term goal of 1 SM running and
evaluation of the readout software. Miscellaneous to-do items included.
========================================================================

Right now we have 16 channels available in SM-1. We are using these to
take short time window data with the LIP and TOHM. We should generally
look at this data and develope software for checkout. The next
shiftworker will bring another 4 channels of daughtercards.

The new set of daughtercards will be the first hand-built ones
of the production boards. They should be exercised immediately and
the results reported to ETK who is setting up assembly.

As soon as possible the first batch of new daughtercards will be sent to
LNGS. Expand the coverage of SM-1 and continue taking data. I expect
that calibration will take place at LNGS as the d/cards are bolted onto
the motherboards. I will provide a custom device to help with this.

This setup should be be moved into main ACQ for combined running, at
least occasionally. In other words the data will show up in the standard
MACRO data. For now, we will get around buffer size problems by only
reading a tiny amount of data.

(A) When not in main ACQ, we should be developing and testing the readout
software. There are basically two main problems:
1) Write the narrow time window readot algorithm. So far
we only have the full readout version. I have this mostly
done and hope to get it to LNGS 1/24 or 1/25.
2) Understand and test the new-event splitting provided by FR.
This may or may not include buffer length checking. I haven't
done anything on this yet.

(B) I have had intermittent problems with the long VMV cable (aka VIC).
Although the length falls withing specifications, I am afraid that the
problem is indemic to VMV over long runs and not a specific flaw in that
cable. Keep your eyes open for it.

(C) We have not yet made a test where we daisy chain the readout to SM-2.
We should do this. We can use the VBR-8212 as the terminal receiver
on the VMVbus.

(D) We should redo a transfer rate measurement with the long cable, and
the daisy chain for that matter. The rate will be proportional to
the entire round-trip time of the VMV bus.

(E) We need a good estimate of the trigger rates and data rates under
reasonable readout assumptions. For starters, we can look at old
data to estimate the trigger rates and their correlations.

We must complete (A)-(E) to check off on the decision to use VIC
hardware. I would like to see as much as possible of SM-1 being
successfully run in acquisition before we purchase more interface
hardware for the other supermodules.

Continue setting up the support for the readout. Understand the
STOP manager and exercise it. Develop specifications for the final
model. Write the CAMAClist commands to arrive at a robust system
that records everything we need. For example:
1) We must make sure we can handle events where the regular readout
is fast and the WFD readout might otherwise commence before it
is STOPped. Currently, I think the plan is to wait for a Q
from the STOP master. This should be tested and shown to be robust.
2) Understand the necessary STOP and START sequences that are needed
for the cold start of a new run.

A side project which can be factored out is to design and implement a
safety mechanism for high trigger rates that call for WFD readout.
Hardware or software could be considered; for starters, I recommend a
monitor job which checks the rates of individual tanks or channels and
passes information to SUPER.SYS that masks off hot channels when
necessary (of course, recording that fact!).

Another side project is to help Aurelio prepare for more data. For
example, a specific solution must be chosen to assure that the run
length (now based on file-size) does not become too short.

Also, we wish to drive WFD readout from ERP triggers. We have a scheme
where we can modify WFD_PATREG to search backwards through ERP data
to determine the readout channels. Jim Musser is arriving soon and
is a good man to work on this. Bob Nolty has also expressed interest
if the work is still ongoing when he arrives.

To do items:

* Make long cables to run from the central clock to each SM. Currently,
the clock is the gold module on SM2 or SM3 (I forget). It only has
two outputs. You may assume that the final version will have 6.
BNC at one end and LEMO at the other.

* handle AC supply for WFD crates: plug-in capability with sufficient
current handling capability at 220 V.

* finish bundling and labelling signal cables (more labels are on the
way!) Note: I suggest when you put on the label, you have it overlap
the red cable marker slightly to help keep it on.

* install the noise suppression toroids in a neat way which reliably
solves the noise problems. Ash is bringing more toroids in early
February. Nat and others at LNGS are on this right now.

* right now, WFD_TEST.FOR (part of "do you want an equipment dump?" in
COMMAND) does not correctly decode WFD equipments if the equipment
starts on an odd I*2 boundary. Debug and fix. Brute force is allowed.