I see that I did miss one tank when checking for known problems.
However that event was actually tagged for another reason. So I still
claim all of my events have problems no one knew about..... Here is
some more info and answers to a few of your questions.
>
> > Event 1308:
> > ************************************************************************
> > Tank 3W8/10/12/14 chan 0x319:
> >
[info on missed roll-over deleted]
> 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?
I agree these are worrying. As you can see this case is a 4:1 fanin.
>
> >
> > 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.
Hmm I actually did check my notes but I blew it. Now I see it's
something we noticed after we made all of our changes. But this is
not the reason the event was tagged. It was because of the rollover
miss in this event in the other box.
>
> > 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.
You are not saying we fixed this or noticed it in any particular
channel just that you have seen it other places before right? This
chan is not in any list I have of broken or fixed channels.
>
>
> > 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.
>
I can't find this on listed in any of our problem lists. Are you
sure?
>
> Chris' search here has made it evident that we need a
> standardized place to report known problems.
I agree we need to keep logs. It is more complicated then you might
imagine however. I have noticed channels not working for one or two
runs. What I plan to do is build a database of every channel and when
it could reconstruct muons properly. This way when I calculate
acceptance I can know what was going on.
>
> That's my two cents. More pennies to come in the near future!
>
I want quarters!
>
> Chris
>