Just some quick comments on Chris' last e-mail:
>I wanted to say a little bit about the fast stop proposal. In my
>experience, in the WFD analysis the biggest problems have been caused by
>the STOP masters. You absolutely need them to work correctly otherwise
>you will look in the wrong place for the data. Unfortunately, they are
>plagued by a host of problems. It is somewhat tricky to write the
I agree that the STOP MASTERs suffer from various problems since day one.
That's why the fast stop we're testing has nothing to do with the
STOP MASTER module.
>code to catch all of them because of things like the fact that the
>STOP masters count to different maximum values depending on the run
>and the SM. For this reason I have found it is best to use the
>triggers themselves to make decisions about where the data should be
>and just check the STOP masters for errors.
It has been examined the possibility to create a new trigger. I remind
you that in the current STOP MASTER hardware there is NO spare input
(for a new trigger) and more importantly there is NO capability to do
different time delays (STOP times) for different triggers.
The WFD STOP in SM1 (and SM2) at this very moment is the .OR. of the
STOP MASTER output (i.e. ~1msec after the "event") and the delayed
by ~110usec signal coming from the charge integrator. Flagging the
events where this is happening was my #1 concern. That's why I resurrected
an old SPU latch where the discriminated outputs of all the integrating
circuits are latched and read on every event. I created a new equipment
(#36) where a 16 bit word is read with this info. All this info (logic
set up, bit assignment etc) can be found on the WWW site I pointed you
yesterday.
If you think a trigger has to be created (currently the FAST STOP is
issued on ~10evnts/hour/SM), that's fine with me.
The fast stop was created from scratch in order to test a few things
we've advertized as constituents of the WFD fix. I kind of like the
idea behind this "trigger" (i.e. integration of PMT over long time
scales) as it selects events that are a priori interesting. In order
though to elevate it to an acquisition trigger level I would prefer if
somebody could undertake the effort to design it nicer, i.e., provide
less multiplexing (currently 2chnls/SM), internal discrimination/thresholds,
some ADC's to make the charge value of the integrators available to the
camac bus etc etc. Every time the FAST STOP is issued now is where
we would had most probably lost the original PMT signal. I'm saying
most probably because our only limitation now is the multiplexing
in this integrator.
>Because of this I am a little worried about making the STOP more
>complicated. I would think at a minimum you should create another
>trigger for this condition. It would be a bad idea to rely on the
>STOP master times themselves to figure out if a fast STOP happened.
I'm sharing the same worries with you, that's why I followed the
above approach. I believe the STOP in its current scheme is as simple
as we could do it, assuming that we really want a fast stop.
Given everything at this moment, it might worth looking into re-designing
the STOP MASTER in order to fix the problems the module is suffering
already plus to accomodate the variable STOP schemes in a more ordered
and compact way.
>The most important thing is that you need to be able to *reliably* and
>deterministically figure where the data should be on an event by event
>basis.
The bits read with EQP36 should do the job.
>> without the fast stop will lose ALL WAVEFORM INFO. COULD THIS FAST
>> STOP BE A SOLUTION BY ITSELF (no hardware modification)?
>So you are saying this would work completely except for a certain range
>of betas we would only have one face? Have I understood correctly?
Yes, that's correct. Actually, it has to be a combination of beta .AND.
dE/dx in order to lose the EXIT waveform. For particles that have
a time of flight <~120usec (always within the entire detector), the present
scheme (with the FAST STOP imposed) guarantees that ALL light yields will be
caught on ALL the waveform faces and most likely (see above note on PMT
multiplexing for the integrator) a 1 millisecond PMT histories will be
available for analyses (namely catalysis). For particles with ToF greater
than 120usec, if their light yield (actually charge) remains less than
~500mVusec within every face they cross, ALL the waveform faces will be recorded
and a 1 millisecond PMT histories will be available for analyses (namely
catalysis). If the particles with ToF greater than ~120usec release light
more than ~500mVusec in at least one detector face, then the FAST STOP
will take place and any face waveform that follows the face that triggered
the FAST STOP will be subject to LOSS. Only ~120usec of PMT histories
will be available for analyses in this case.
Please note that after we undergo the WFD/PMT fanout hardware modification,
the only thing that will change in the above description is the CHARGE THRESHOLD
of the FAST STOP; namely it will be pushed from ~500mVusec to ~20Vusec.
Needless to say, in EVERY case we need to perform DETAILED LED calibration
runs in order to make sure that the above figures we've used as benchmarks
DO NOT VARY A LOT from channel to channel. An LED RUN with the FAST STOP
is already available (Lori Gray took on Wednesday RUNs 90553, 90554 and is
in the process of analyzing them).
--Erik