In regards to Chris W's report of various WFD problems I felt I
should add that many of them have already been repaired. Run 10850 was
during out period of first running, and at the Gran Sasso Collaboration
meeting we had identified and fixed a number of WFD bugs.
I have some new data that I am processing NOW, to make sure that
none of these problems Chris has mentioned have persisted.
> Event 1308:
> ************************************************************************
> Tank 3W8/10/12/14 chan 0x319:
>
> This channel has the muon showing up too early. It appears that this
> box missed a roll-over word. Some boxes (especially verticals) seem to
> sometimes miss a roll-over word. Perhaps the rate is not high enough
> in these boxes. The effect of this is that the muon seems to show up
> 328 uSec too early(328uSec = 65536*5ns).
I am a little concerned about these kinds of events events. I
think it is important to understand how quiet tanks have to be for this
problem to occur. Does it just happen where the multiplexing is 3:1
instead of the usual 4:1?
>
> Tank 3B12/14 chan 0x307:
>
> This chan overflowed(hit the byte readout limit). However all of the
> ADC data is 0 and all of the dBits are FFFF!
>
I have this exact problem mentioned in my notebook; it was fixed
in early December.
> Event 4986:
> ************************************************************************
> Tank 2W08 chan 0x218:
> In this event the time-word "glitched" and went up instead of going
> down. Because of this the readout routine got confused(thinking a
> roll-over happened) and stopped the readout thinking it had read
> enough data:
We also had identified this problem. Timing problems like these
can be hard to notice because the ADC data itself looks okay. It is
only when you look for muons like Chris has done that you notice there
is a problem. IE it won't be evident in your typical LIP or Slow
Monopole event that something is wrong.
> Event 5577:
> ************************************************************************
> Tank 6B12 chan 0x607
> The data is missing in the relevant section of the buffer for this
> event. However it is clear something went wrong during the stop as
> the ADC and dBit values in the first sample are nonsensical:
>
Fixed.
Chris' search here has made it evident that we need a
standardized place to report known problems. So in addition to making
sure Maurizio adds all of the past problems I know about to the wrong
list, I will also be making a "wfd-repair" log on our website here.
Hopefully people will use one of these resources before re-inventing the
wheel.
Not all of the problems Chris reported can be explained away, so
I will be looking into these channels in the newest data. Besides
these, I think the biggest concern for the WFD is are the missing
roll-over problem mentioned by Chris here in certain vertical WFD
channels.
That's my two cents. More pennies to come in the near future!
Chris Orth