[Gep5] 12 GeV data

Thu Jun 20 11:33:33 EDT 2013

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 • Find us on Facebook

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/gep5/attachments/20130620/9f3f6782/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ADC_vs_event_number.pdf
Type: application/pdf
Size: 36552 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/gep5/attachments/20130620/9f3f6782/attachment-0001.pdf 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/gep5/attachments/20130620/9f3f6782/attachment-0003.html 