>I know this is going to sound schizophrenic but I would *rather* have
>it implemented in the STOP master. Although it does have problems it
So you're proposing complete re-design of the module. Simple re-drawing
of the ACTEL chips logic can do the job.
>is the only thing that can cause a STOP(which is a nice feature) and I
>have never seen an error I couldn't flag. The big worry is that the
>WFDs get stopped and you don't know it. All that being said I
>understand that you don't have much of a choice.
I hope I made myself clear; you shouldn't worry about the WFDs
getting stopped and not knowing about it. There is a simple discriminator
that drives both the WFD STOP and the bit on the latch.
>I know that Eric understands this but just for the others here is a
>clip of a message I sent to Charlie explaining what kind of
>backgrounds you can accidently introduce:
>
>------------------------------------------------------------------------
>
>This high energy early STOP thing makes me quite nervous. I guess
>they don't really have a choice but if I understand what they are
>doing they are bypassing the STOP master completely. This means that
>for a class of events the STOP master will look like it went for about
>1ms but in fact the WFDs will have been stopped much earlier. You
>will need to look in another piece of equipment to see that. If
>everything works then it should be OK. But if it screws up even a
>small fraction of the time(imagine once per 100 runs or something)
Let me make sure I understand your worries: is it the lack of latching
the info on every early WFD STOP issued by the module that worries you?
The discrimination/latch should be very reliable. We've been running
the whole detector with these modules in the past. If the system screws
up once every 100 runs, that's fine as long as you know about since you
can account for it. I understand though that this is where the problem
comes in: being a stand alone system, you do not have monitor of neither
its inputs (PMT signals) nor its direct outputs (charge). All you have
is a bit in a latch that tells you whether a discriminator triggered
or not. In a failure mode of this module (if it over/under triggers) it
will be almost impossible to debug it offline.
As an alternative and quick upgrade of this circuitry, I've looked into
adding one of the old LeCroy WFDs in order to digitize all input and output
signals of this module. The LeCroy WFD has four inputs and if you clock it
slow enough (20-30MHz) you'll have enough memory to cover 10-15usec long
signals. Two channels will be dedicated to the input PMT signals and two
channels will go for the outputs of the two integrators we currently
emply on a per SM basis.
>then you might introduce horrible background problems into a monopole
>analysis. The TOHM trigger will go off and you will think that the
>WFDs went for 1-ms. Then when you look at the WFDs you will look at
>the wrong place and instead of seeing a muon(for example) you will see
>random radioactivity which might be consistent with SPE trains. So we
>need to make sure it *really* works before we do this.
I believe monopole analyses should be looking at the entire PMT
history recorded by the WFDs anyways; we've been pushing on the whole
WFD story in order to get sensitivity to catalysis. Notice that
even when you have the fast stop (say at 120usec) YOU'LL STILL RECORD
ON THE WFDs 1-msec. The only difference with the "standard" (=1ms) stop
will be the fact that in the standard stop you have ~1ms of PMT history
*following* the event that triggered the detector. With the fast stop
you have ~880usec of PMT history *preceding* the event that triggered
you PLUS ~120usec of PMT history *following* the event (and actually
including that too).
>------------------------------------------------------------------------
Well, Chris, thanks a lot for all your comments and input. I hope people who
have (or plan to) analyses that involve WFD data all come up and express
their thoughts and worries now. The good thing about the fast stop is that
it can be removed/added/upgraded rather easily as opposed to any other
hardware fix on the WFDs/fanouts. HOWEVER, THIS ASSUMES THAT PEOPLE ARE
LOOKING AT THE DATA AND SEND INPUT BACK. After the WFD/fanout hardware
modification, the charge value at which we anticipate to raise the
fast stop threshold should be ~20Vusec, i.e. to values that (even with
signals multiplexed) if it *ever* triggers, it will be *the* MACRO event.
So, for such a scheme that we never expect it to fire, your worries you've
raised should be significantly reduced. At the same time though, with an
almost impossible-to-reach threshold for the fast stop, we'll lose our
ability to *monitor* the hardware using the muon data. And thus, yet
another calibration will have to be added.
A presto,
--Erik