[Eg6_analysis] Data Acquisition System

[Nathan Baltzell]

Hi Raphael and EG6ers,

Ok, I've done some more analysis and thought ....

We have two things:  tracking and energy measurements.

I can do different things to try to estimate how these new noisy pads
affect the dedx measurement with the cooked data.  With that data,
I cannot estimate a pad-by-pad pedestal.

I can alsolook at how tracks with different amounts of these pads have
different tracking results.  But,


I did not go so far yet as to assess a new pedestal correction.
I suspect there's not much that can be done with pads whose off-plateau
hits are as loud as their on-plateau hits.  In the current scheme,
applying a pad-by-pad pedestal, wether event-by-event or averaged,
and seeing its effect on tracking, requires recooking, which can be
done soon when we have a firm plan on how to proceed.

It will be nice to know what pedestal was done online.
Where should I look to find that information?

-Nathan




On Mon, 04 Feb 2013 11:02:42 -0600, Dupré Raphaël
<raphael.dupre at gmail.com> wrote:

> Hello Nathan,
>
> Very nice!
>
> This seems to indicate that the noisy channels do not give very useful
> information. This is a bad news, I am afraid we are going to loose a
> bunch of pads in this story, but we should keep as much as possible
> until we are sure no meaningful data can be obtain from them.
>
> I think the first question now would be, should we use averaged
> pedestals for the pads or event by event subtraction? I am not sure
> how to test this. Maybe looking at a sample of good events hitting
> some noisy pad would show if one or the other method is better (or if
> the pad is completely useless).
>
> For the right left asymmetry, it was clear during the run that one
> side was more noisy than the other. It is not surprising that
> occupancy reflect this and it confirms that the noise remain an issue
> even after cutting many bad pads and applying the noise reduction
> algorithm.
>
> Best,
>
>
> On Mon, Feb 4, 2013 at 5:03 PM, Nathan Baltzell <baltzell at anl.gov> wrote:
>> Hello Everyone,
>>
>> Here's a report on RTPC pedastal/noise:
>>
>> http://clasweb.jlab.org/rungroups/lowq/wiki/index.php/RTPC_Pedestal_Investigation
>>
>> Let me know your comments and suggestions.
>>
>> -Nathan
>>
>>
>>
>>
>> On Thu, 31 Jan 2013 11:16:39 -0600, Dupré Raphaël
>> <raphael.dupre at gmail.com> wrote:
>>
>>> Hello guys,
>>>
>>> The system of data acquisition is set up such that it stocks the data  
>>> over
>>> a long time. When the trigger signal arrives the DAQ system takes data  
>>> for
>>> 8.5 micro seconds more and keeps values from -1.5 to 8.5 relative to  
>>> the
>>> trigger. TDC slots are of 100 ns and there you have 100 of them with  
>>> the
>>> trigger time at TDC = 15.
>>>
>>> Pedestals for the ADC values are calculated from a larger window taken
>>> from
>>> previous data. I do not remember the time window used for these  
>>> pedestals,
>>> but it is probably documented somewhere (it might be interesting to  
>>> try to
>>> find it). Finally the DAQ send some data, the data are sent by  
>>> clusters of
>>> consecutive TDCs. In order to define a cluster you need to have 3 (?)
>>> consecutive hits with ADCs higher than 45 (?). Then the cluster is  
>>> defined
>>> by all these consecutive hits plus the 3 before and the 3 after in  
>>> term of
>>> TDC, so you have a minimum size of clusters of 9 (except on the edges  
>>> of
>>> the time sample). These additional 6 hits can be of any ADC value and  
>>> can
>>> eventually be used in order to make an additional pedestal, either by
>>> using
>>> a mean value of them or the 2 extremes (or any other combination that
>>> would
>>> be most appropriate) and subtract this to all the hits of the cluster.
>>>
>>> I am not completely sure of the final values we used in the run, so the
>>> numbers followed by a "(?)" should be checked. It should be straight
>>> forward to find them by looking into data.  The minimum size of  
>>> clusters
>>> will give the number of consecutive hits needed and the ADC  
>>> distribution
>>> has a discontinuity at the threshold level.
>>>
>>>
>>> Best,