[Clas12_calcom] database tables

[Raffaella De Vita]

Hi Cole,
for Mode 1 my preference would be to keep the options of emulating mode 
7 or working with fixed windows. For small signals with small time 
jitter (this is the case of FTCAL cosmic signal that are barely above 
noise) it may be convenient to work with fixed pulse integration 
windows. In addition, if I'm not mistaken, in mode 7 pedestals are 
calculated only using 4 samples that may not be sufficient when the 
signal/noise ratio is small.
Regards,
     Raffaella

Cole Smith wrote:
>
> The FADC250 firmware parameters are already in the datastream, which 
> is where the decoder should ultimately look to configure itself. 
> However if
> we decide to run in Mode 1 it is my opinion the decoder should emulate
> Mode 7 pulse integration rather than use fixed pulse integration windows.
>
> Cole
>
>
> On Mon, 11 Apr 2016, nick markov wrote:
>
>> Dear all,
>> these are not part of the decoder, but in my opinion in would be 
>> convenient to have them stored somewhere other than fadc 
>> configuration file.
>> Nick.
>>> On Apr 11, 2016, at 11:09 AM, Raffaella De Vita 
>>> <Raffaella.Devita at ge.infn.it> wrote:
>>>
>>> Hi Cole,
>>> in the discussion we had on Friday, it came out that what would be 
>>> useful to have in the DB (to remove hard coded parameters from 
>>> calib/monitor code) are the pedestal and pulse ranges that the 
>>> decoder uses to get the pulse charge for mode 1 data.
>>> If necessary, we can also add the windows parameters but, if I 
>>> understood correctly, these are not needed to decode the data.
>>> Regards,
>>>    Raffaella
>>>
>>> Cole Smith wrote:
>>>>
>>>> I wasn't at the meeting but Nick's original question referred
>>>> to the capture window parameters.  I would suggest window_offset 
>>>> and window_width instead of pulse, to avoid confusion over the 
>>>> meaning.
>>>> Using fixed pulse integration windows could be dangerous.
>>>>
>>>> Cole
>>>>
>>>>
>>>> On Mon, 11 Apr 2016, Raffaella De Vita wrote:
>>>>
>>>>> Dear All,
>>>>> following Nick's question and the discussion we had last Friday, I 
>>>>> edited the document (see attachment) to reflect the proposed 
>>>>> change to the /daq/fadc table that would now also contain the 
>>>>> parameter for Mode 1 analysis. The proposed names are 
>>>>> pedestal_start, pedestal_width, pulse_start, pulse_width .
>>>>> Comments are welcome.
>>>>> Best regards,
>>>>>    Raffaella
>>>>>
>>>>> nick markov wrote:
>>>>>> Dear CALCOM group,
>>>>>> I wonder if it possible and needed to add to the DAQ parameters 
>>>>>> tables
>>>>>> parameters of MODE1 readings:
>>>>>> FADC250_W_OFFSET
>>>>>> FADC250_W_WIDTH
>>>>>> Nick.
>>>>>>>  On Apr 1, 2016, at 11:09 AM, Mac Mestayer <mestayer at jlab.org> 
>>>>>>> wrote:
>>>>>>>>  Dear CALCOM group;
>>>>>>>>  Thanks for the concise and well-written guidelines.
>>>>>>>  They are very good for focussing discussion.
>>>>>>>>  I agree with most of the 'best practices' advocated, so
>>>>>>>  I will only mention my two disagreements here:
>>>>>>>>  1) sector, layer, component need not be enforced on the
>>>>>>>  tables (CCDB is much more flexible than CALDB was in this regard).
>>>>>>>  Not only that, but sector, layer, component is not at all 
>>>>>>> applicable
>>>>>>>  to the drift chamber data-base.  See > 
>>>>>>> https://clasweb.jlab.org/wiki/index.php/DC-calibration_Constants
>>>>>>>  for a description of the DC calibration table structure.
>>>>>>>  We use indices like region, superlayer or region, superlayer, 
>>>>>>> board, >  connector, etc. and I refuse to call a superlayer a 
>>>>>>> layer, etc.
>>>>>>>  There is no need to try to enforce a false structure on everyone.
>>>>>>>>  2) we should not use run number to denote a variation, such as
>>>>>>>  Monte Carlo.  This is precisely what variations are designed to 
>>>>>>> do.
>>>>>>>  Talk to Hall D to find out how they use various variations to 
>>>>>>> denote
>>>>>>>  Monte Carlo.  In fact, I think we may want to use actual run 
>>>>>>> number
>>>>>>>  ranges for the Monte Carlo variations to follow, for example, 
>>>>>>> different
>>>>>>>  luminosities and this proposed use of run numbers will just 
>>>>>>> confuse
>>>>>>>  people.
>>>>>>>>      regards, Mac
>>>>>>>>  "mestayer at jlab.org", (757)-269-7252
>>>>>>>>  On Fri, 1 Apr 2016, Raffaella De Vita wrote:
>>>>>>>>>  Dear Harut and Bryan,
>>>>>>>>  following the discussion we had on the database, we have 
>>>>>>>> collected a > >  set of "guidelines" concerning the calibration 
>>>>>>>> constants table > >  structure, the use of variations, the use 
>>>>>>>> of run numbers etc.  that we > > would like to distribute. You 
>>>>>>>> can find in attachment the document we > >  have produced.
>>>>>>>>  Let us know what you think about it.
>>>>>>>>  Best regards,
>>>>>>>>     Raffaella
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>  Clas12_calcom mailing list
>>>>>>>  Clas12_calcom at jlab.org
>>>>>>>  https://mailman.jlab.org/mailman/listinfo/clas12_calcom
>>>>>
>>>>>
>>>>>
>>
>>
>> _______________________________________________
>> Clas12_calcom mailing list
>> Clas12_calcom at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/clas12_calcom
>>