[Gep5] 12 GeV data
Carlos Ayerbe-Gayoso
gayoso at jlab.org
Thu Jun 20 12:37:44 EDT 2013
For a small summary, we should run the decode again for the 12 GeV runs,
shouldn't we?
Carlos
El 6/20/2013 11:59 AM, Alexandre Camsonne escribió:
> 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
> <mailto: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
>> <mailto:gayoso at jlab.org>>
>> To: "Edward Brash" <brash99w at gmail.com <mailto:brash99w at gmail.com>>
>> Cc: "Mark Jones" <jones at jlab.org <mailto:jones at jlab.org>>,
>> "Edward Brash" <edward.brash at cnu.edu
>> <mailto:edward.brash at cnu.edu>>, "Edward Brash" <"Edward
>> Brash"@smail.jlab.org <http://smail.jlab.org>>, "Ed Brash"
>> <brash at jlab.org <mailto:brash at jlab.org>>, "Vina Punjabi"
>> <punjabi at jlab.org <mailto:punjabi at jlab.org>>, "Charles F.
>> Perdrisat" <perdrisa at jlab.org <mailto: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 <tel:%28757%29%20594-7451>
>>> cell: (757) 753-2831 <tel:%28757%29%20753-2831>
>>> www.cnu.edu/pcs <http://www.cnu.edu/pcs>
>>>
>>> On Jun 19, 2013, at 4:48 PM, Mark Jones <jones at jlab.org
>>> <mailto: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 <tel:757-594-7451> • f: 757-594-7919
> <tel: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/aeaab33d/attachment-0001.html
More information about the Gep5
mailing list