Glad you are still thinking of solutions! While we are figuring
things out we should cover every idea.
> Doug made mention of examining a possible hybrid approach for the WFD
> over/undershoot problem until a final solution is reached.
BTW, although a hybrid solution may be the choice- I'd argue that we
have to our best shot at a permanent fix, rather than a fix while
we study some more.
> In this spirit, what about decreasing the DELAY TIME in the WFD STOP
> MASTER as a temporary "fix"? Currenly it is set at ~1 millisecond, a
> number that was defined based on the TOF of the slowest particle (in
> all geometries) we'd like to record together with some catalysis
> arguments. Given that the WFD hardware *as is* now records
> *everything* up to ~100 microseconds we may trivially change the
> camac lists that control the wait time of the stop master so that to
> match it.
In general, I echo Chris' email. To put it another way, I'd much
rather have several faces with a section of data missing than to miss
a face. Anyway, I've always thought we might reduce this number
slightly (800us?) once we knew exactly what acceptance we are
shooting for. But 20% isn't much help here (even for a hybrid fix).
> The acceptance in this configuration may be further improved by increasing
> the WFD data byte limit (if I recall well though, Ed mentioned that this is
> already at its limit). Another thing that will help in this direction is
It is. Too bad.
> to clock down the WFDs by some factor that will not harm our ability to
> distinguish s.p.e.'s. We can perform a type of Sophia's sensitivity
> measurement done back in Feb96 with some clocked down WFD channels and see
> how this is affected. We'll gain as much as we can afford in this way since
> the available digitizing window will be increased inversely prop. to the
> frequency. However, any precision TOF measurement for fast particles will
> be harmed...
This would be another 10-20% fix since we can't go much slower and still
record SPE's. If we were going to go to 180 MHz I'd do it to fix the
ASIC rollover 'bug', but we (me?) already decided long ago that full
resolution is more desirable.
Thanks for the continued discussion- Ed