[Gep5] 12 GeV data

Thu Jun 20 11:59:14 EDT 2013

yes sorry my decoder was very primitive and I did not take that into
account.

Good you figured it out,

Alexandre

On Thu, Jun 20, 2013 at 11:33 AM, Edward Brash <edward.brash at cnu.edu> wrote:

> Hi All,
>
> OK, I have figured out the ADC overflow issue.  It's a bit complicated, so
> I am posting this to the gep5 mailing list so that there is a record of it.
>
> Referring to the CAEN v792 manual (this is the ADC that we are using), the
> output buffer actually contains an overflow bit - it is the 13th bit of the
> output buffer.  When this bit is zero, then there is a normal ADC value,
> and the lowest 12 bits contain the ADC value ... thus 0xFFF in those lowest
> 12 bits corresponds to ADC = 4095 in decimal.  Now, when the overflow bit
> is set to 1 (meaning that there was an overflow in that channel of the ADC,
> it turns out that the lowest 12 bits are NOT just set to 0xFFF, as I would
> have thought.  In fact, they are encoded with something that looks like
> 0xFXY, where "XY" is a number which runs from 0 to 255, and is in fact
> related to the event number.  That is, these lowest 8 bits start at FF, and
> then run down to 00 as the event number increases.  Once it gets to 00, it
> resets to FF and starts over again.
>
> I attach below a plot of the raw ADC value vs. event number.  For all of
> the events in this plot, the overflow bit (bit 13) of the output buffer was
> 1, so these really are ADC overflows.  The correlation with event number is
> obvious.
>
> So, how to fix this?  It does need to be fixed, because the ADC value for
> non-overflow events really can range from 0 to 4096.
>
> I looked at the code called decodeEel.C, which is the code that extracts
> the ADC values from the CODA data, and I see that indeed, to extract the
> actual ADC value, one does a bitwise AND with the mask "0xFFF", as one
> might expect would be correct.  But, this does not recognize the overflow
> bit.  So, I changed this to be a bitwise AND with "0x1FFF", so that when
> there is an overflow, it is put near channel 8192 (and the region just
> below that), so that now it is clearly separated from non-overflow events.
>
> This fixes the problem completely, and now ADC overflow events are cleanly
> distinguished from non-overflow events.
>
> Best,
> E.
>
>
>
>
> On Jun 20, 2013, at 9:29 AM, Mark Jones wrote:
>
> Carlos,
>        As Charles says you are right. Maybe it is the "summing" module
> which saturates.
>
>                   Mark
>
> ----- Original Message -----
> From: "Carlos Ayerbe-Gayoso" <gayoso at jlab.org>
> To: "Edward Brash" <brash99w at gmail.com>
> Cc: "Mark Jones" <jones at jlab.org>, "Edward Brash" <edward.brash at cnu.edu>,
> "Edward Brash" <"Edward Brash"@smail.jlab.org>, "Ed Brash" <brash at jlab.org>,
> "Vina Punjabi" <punjabi at jlab.org>, "Charles F. Perdrisat" <
> perdrisa at jlab.org>
> Sent: Wednesday, June 19, 2013 5:53:41 PM
> Subject: Re: 12 GeV data
>
> I'll check it, but I have some questions of this point of view, maybe
> I'm losing something of what we had from SLAC or could be some lack of
> knowledge from me.
>
> I understand that every peak we have in the sum of energies histogram
> represents a certain number of electrons delivered by the accelerator
> (5-6 electrons in the 3 GeV, 3 electrons in the 12 GeV). When we said
> that the machine provides electrons of 3, 9 or 12 GeV, we assume that
> every electron of the bunch has an energy of this number (3, 9, 12 GeV)
> with certain sigma but bigger, is this correct?
>
> Then, I assume that every electron contributes to the shower
> independently, so, the sum or the contribution of every shower is what
> the calorimeter measures. If I understand correctly, Mark, you said that
> with 36 GeV part of the shower goes out of the calorimeter, but I think
> this is true if we have electrons of 36 GeV and this is not the case,
> isn't it?
>
> Please correct me if I'm wrong or I misunderstand something... sometimes
> I assume things that seems logic to me and they're not.
>
> Best
>
> Carlos
>
> El 6/19/2013 5:10 PM, Edward Brash escribió:
>
> Good point ... :)
>
>
> Dr. Edward J. Brash
>
> Department of Physics, Computer Science & Engineering
>
> Christopher Newport University
>
> work: (757) 594-7451
>
> cell: (757) 753-2831
>
> www.cnu.edu/pcs
>
>
> On Jun 19, 2013, at 4:48 PM, Mark Jones <jones at jlab.org> wrote:
>
>
> I realized that for the SLAC 12 GeV data run the 3rd peak that should be
> at 36 GeV has
>
> less energy because it is lost through the back of the calo. But it would
>
> interesting to confirm with GEANT.
>
>
>
>
>                       Cheers,
>
>                              Mark
>
>
>
>
>
> *Dr. Edward J. Brash*****
>
> Department of Physics, Computer Science & Engineering****
>
> Christopher Newport University****
>
> p: 757-594-7451 • f: 757-594-7919****
>
> www.cnu.edu/pcs <http://www.cnu.edu/pcs/index.asp> • Find us on Facebook<http://www.facebook.com/pages/CNU-PCSE-Department/207472702360>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/gep5/attachments/20130620/fc305728/attachment.html 