--------------------------------------------------------------------------
I will assume most of you are more or less aware of the progress from
my last formal update in July, either from reading shift reports or
from word-of-mouth. I'll summarize that stuff anyway, as well as
discuss the current state of affairs. Just for fun and comparison,
here is the executive summary from the last update:
> We now own the pcb's and parts for 80 wfd motherboards, these are
> being assembled at Texas Instruments and will be QC tested at TAMU.
> The daughtercard project is lagging, but the "go" button could be
> pressed at any time we are ready to commit the final resources.
> Nothing new has been accomplished on the readout front; in fact, the
> final architecture for the readout is still negotiable. More work has
> been done on the switching supply noise, but as of now it remains
> unsolved. The first stop master is at GS and will soon be tested. The
> START/STOP/CLOCK fanouts are being assembled, as is the 200 MHz clock.
> The next phase of work will be in Gran Sasso in August. There we hope
> to *really* incorporate a handful of channels in the MACRO daq and
> begin to assemble the system. At this time we will finalize decisions
> on the daughtercard and readout.
---------------------------------------------------------------------------
The assembly and testing of the wfd motherboards is effectively
complete. Webb/Lu/David/Sanzgiri of Texas A&M have received the
assembled boards from Texas Instruments and pushed them all through a
standard testing procedure. Out of 76 cards, 43 passed the tests with
little or no debugging. I think that's a pretty good yield for a board
of this complexity. By the way, they also uncovered one last design
error (an incorrect capacitor value)... nice job.
The switching supply noise problem is effectively solved. Our engineer,
Bill Earle, suggested winding the signal cables around a ferrite toroid
of sufficient permeability. Chris Orth and I tried this out at Gran
Sasso and found that it worked very nicely, although it takes at least
10 turns to quiet the noisiest channels. I'm still interested in trying
these out on the DC wires inside the power enclosure; but that test
hasn't happened yet. My thanks to all those who also worked on this
problem, especially Ash Sanzgiri and Phil Green.
Our temporary tech, Paolo (Ersilia's son) has labelled all of the
TAMU-built signal cables, so those are ready to go. I installed and
routed the cables on SM-1, using nifty cable trays to make the layout
tidy. This layout should be a template for the remaining supermodules. I
bought all of the raw material for the remaining cable trays- they can
be found in the 1st floor of the counting house.
At Gran Sasso we spent a fair fraction of August looking at waveforms,
understanding the daughtercard and setting up new software for readout.
Now that we are able to effectively work at low thresholds (2.5 mV)
because the noise problem is solved, we came across a "new" problem. It
appears that there is a certain amount of cross-talk between an input
with a large signal (muon level) and the other channels in the d/c.
Although the crosstalk is relatively small with respect to the big input
signal, it is often large enough to exceed the 2.5 mV threshold and
cause discriminator bits to fire for channels with no signal. This is
something we could probably live with, sorting things out offline; but
after some study of the situation, it is likely we can fix it. We are
looking into this right now at BU. The extra feature that makes a change
attractive is that this may also be related to the leading edge glitch,
and fixing this might solve two problems. Stay tuned.
We also looked at the calibration curve of the daughtercard. Chris and
Kael tweaked pots to set the amplifiers to the desired non-linear
response. The tough thing about this is that to cover the upper range of
the PMT's we have a very flat response curve. This makes a change in
calibration cause a greater change in response. Also it exacerbates the
leading edge glitch (the glitch is small but is reconstructed as a large
deviation). And it washes out small fluctuations on top of a square
wave: Campbell theorists beware! Nevertheless, it is our only design for
now; I have taken Barry's suggestion to trade off more of the lower
range versus the flat upper range. We are also checking this out at BU
(it is just a component change). This will help marginally, but the
above caveats still apply its just the math of the compressing the
dynamic range.
In terms of software, I futzed around with the mini-DAQ program as well
as the VAXELN drivers. I enhanced my menu option in the mini-DAQ that
puts you into a WFD testing command line interface. In particular, I
put together a fairly useful event display (thanks go to Colin for
helping me with this).
Most of the driver work was actually unrelated to reading out the wfd's.
(It ain't going to get any better than it is now- at least with the
VICbus). What I did was to define a method for handling the selective
readout of wfd channels. (Thanks to Bob Nolty for heplful discussions).
Here is how it works. There are a number of triggers in MACRO that may
drive the readout; each of them specifies in some way which channel(s)
triggered. After each pertinent trigger word is read into the data
stream (by a CAMACLIST command), we will place a new command: WFD_PATREG
with arguments ID and SUBID. ID and SUBID specify which of the many
MACRO trigger words this is and directs the code in WFD_PATREG to set
bits in a global software pattern register. So during the readout of an
event, each trigger will have the opportunity to set bits in this global
register, and then as one of the last equipments, the wfd readout will
loop over those bits and read the selected channels.
WFD_PATREG is something like a USER_PROCEDURE, in that several people
are likely to contribute to it and it is not integral to the main
daq drivers. So I put the routine in USER_PROCEDURE.PAS; you may
find the latest copy in [BOSTONPUB.KEARNS.PAS] if you would like to
peruse it.
By the way, this caused me to discover, much to my disgust, that VAXELN
effectively has **no** provision for bit manipulation of whole words.
This is so unbelieveable that it actually took me awhile to arrive at
this conclusion. Anyway, it is possible to get the job done bit-by-bit
using FIND_NEXT_BIT_SET and FIND_NEXT_BIT_CLEAR. However, Kael figured
out how we can link in a separate C function. Now, it isn't obvious that
we win enough to want to do this, but it is certainly something to keep
in mind as we continue to work on the readout software.
Bob and I tested the scheme out using WRITEHEX to stuff constants into
the data stream to spoof TOHM bit patterns. If only we had been able to
get the TOHM working in the mini-DAQ we could have done a more dynamic
test. This remains on the to-do list. I have also heard that Chris is
arriving shortly with a LIP board, which gives us another opportunity to
drive selective readouts. I am uncertain of the state of the FMT
trigger.
Without real triggers, we did not get very far with Rongzhi's wfd stop
master. Chris O and Kael looked at it in June and verified that it works
to 0th order. The one "gotcha" we have come across is that it absolutely
requires some sort of computer busy to keep it in a mode where it
generates STOPs. I have emailed him a few times about a few design
details such as this; for example, we also need a way to generate a
START signal, and it would be handy to be able to generate a STOP via
CAMAC control. So let's think about this device now so RZL can implement
whatever is possible before building the production versions.
One of the biggest unsolved issues is how we handle the much larger
events. In particular, there is a limit on the size of a VAXELN message
buffer (~ 64 Kb) that we will easily reach on large events. Chris Orth
looked at some data (good TOHM running, provided by Gary Ludlam) and
made a histogram of the number of wfd channels we would read out
assuming our current multiplexing, and assuming the minimal scenario of
just reading out channels with trigger tanks. The distribution reaches
out to around 26 channels, which is likely to be around 260 kB. So we
have to solve this fundamental problem.
Besides individual large events (even if they are rare), we have to
implement some sort of safeguard for when a wfd trigger that becomes
high rate.
Well, I hope this has given you a flavor for where things stand. There
is a lot left to do, but we are making progress at a good clip. I'm also
heartened to see the growing involvement of other people. More from me
later... Ed
--------------------------------------------------------------------------