> Hi Chris,
>
> So you're proposing complete re-design of the module. Simple re-drawing
> of the ACTEL chips logic can do the job.
Well. I wasn't actually recommending this for right now. Ideally
though yes I wold rather have it implemented in one module.
>
> 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 understand that in principle. However I know of at least one case
with the STOP masters that should never happen. Sometimes the STOP is
caused by the TOHM and there was no TOHM trigger. You can tell by
looking at the STOP times but this shouldn't be able to happen. The
data in the WFDs is junk. Probably there is some sort of subtle logic
timing hole in the computer busy circuits. That's the sort of thing I
worry about.
> 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.
Well As I said I'm worried about a case where you can't tell.
>
> 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).
The problem would be if the fast stop happened and you didn't know
it. Then it wouldn't matter if you recorded all the data because you
would think that the data was at 1ms(and look there) where in fact the
data that caused the trigger was at 10uSec. So when you look in the
wrong place you see random radioactivity.
>
> 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.
Thanks. Don't take this wrong. I'm *not* trying to talk you out of
this. What I'm trying to do is suggest that we make sure we have
failsafe systems in place so the sort of things I mentioned can't
*ever* happen. So for example:
1) There should be a separate trigger and latch so we can check for
consistency(this is how I find most errors).
2) It would be better if we new the relative time of the fast STOP
signal to the other signals like in the STOP master. One option would
be to replace the CSPAM input with the output of the discriminator.
Now the CSPAM is not used for readout it is just convenient because it
is very fast so it makes reading the STOP master times a little easier
to understand.
And So on....
Back to work,
-Chris