Just for the record there are no VME or CAMAC errors associated with
any of these events.
> I'm not sure what Chris means by "digitizing during a stop."
> Possible the same cause for both problems? If these do not
> represent much of the data, maybe the fix can be replaced by
> something which tosses out the events... I would have to know a
> little more about what "digitizing during a stop" meant, though.
>
OK, I'll explain this. I wasn't sure if everyone knew about this or
not.
First off, let's look at the data from the beginning of this event:
Chan: 3090000
VME WFD Node
Channel: 3090000
Tics to data: 0
Number of buckets: 2172
Time Timewd dBits AD0 AD1 AD2 AD3
0 61198 8888 28 28 27 32 -1.4 -1.4 -0.6 -4.6
327690 61196 8888 31 35 33 32 -3.8 -7.0 -5.4 -4.6
327710 61192 8888 32 29 33 35 -4.6 -2.2 -5.4 -7.0
327730 61188 8800 37 34 30 27 -8.7 -6.2 -3.0 -0.6
OK now look at the time words. You see the first one goes from 61198
to 61196. This isn't really supposed to happen. Time Words are
always supposed to be separated by 4. This one is only separated by
2. Now what happens if you use these words to expand the time into an
array? You would get:
61198 << first timeWd
61197
61196
61195
61196 << second timeWd (woops! went back up!)
61195
61194
61193
61192 << third timeWd
So it looks like a timeWd glitch, and if you weren't being careful,
when you saw that happen you would assume a rollover happened. This
seems to happen if a card is digitizing during a STOP. Now there are
many ways to deal with this problem. What I decided to do was the
following: For every buffer I look at the time between the first 4
samples and the second 4 samples(61198 and 61196 in this case) and I
record the difference in time in the "number of tics to first data
word" part of the structure. Then I shift everything down 4 samples
so the first timeWD never appears. For this study I turned that off
so that I could see the words that happened during the stop whichthe
event showed up here.
> >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!
> >
> >Tank 3B09/13 chan 0x304 0x305:
> >
> >These overflowed but because of a very large pulse. The WFDs are OK
>
> Again, I'm suspicious that the "not understood" problem occurred on
> the same event as an "understood" problem.
Well it really looks just like a coincidence. As Chris O pointed out
we have tagged this other overflow channel as being bad. The reason
the event was tagged was because of the missed roll-over. I suppose
it conceivable that these two things are somehow related but I don't
see how.
> How are we on the byte limit? Can we move this up without affecting
> the data too much? We may not be able to trust the events that hit
> the limit... but it would sure kill some of the big showers if we
> just tossed them out. This may be a problem for a readout guru. Do
> we often miss rollover words in the same events where we have hit
> the byte limit?
Interesting question. We are of coursed biased against FMTs because
of this problem. For really big events you just see the positive
going part of the tail.
> >Event 4767:
> >************************************************************************
> >Tank 3E04 chan 0x317:
> >missed roll-over word
>
> Can we find out which tanks most often miss rollover words and try swapping
> cards?
>
Well none of these are tanks which have this problem a lot. These are
all fairly rare cases. I think I can say though that I have only seen
the rollover problem on verticals.
>
[timewd glitch stuff removed]
> If this only happens once, I suppose it can be chucked.
>
I agree that this is the easiest of the problems to tag. In fact my
windowing algorithm already notices something is wrong on these events.
[Bad stop data and then missing real data stuff removed]
> Again, it just looks like bad readout bits... could be
> anything... CAMAC, bad disk write... if it's rare enough (ie one
> time only), can it be chucked?
This one worries me. I think its easier to look at this
problem by eye and say("yup that is weird allright") then tag it
reliably in software.
> >Event 7414:
> >************************************************************************
> >Tank 6E04/06 chan 0x617:
> >Missed roll-over
>
> >Tank 6C08 chan 0x60B:
> >The second ADC value is stuck at the value 9
>
> Both sound like hardware. If they happen again, we could look at the cards.
>
Well the 0x60B problem we knew about. It is the rollover that caused
the event to get tagged.
-Chris