[Halld-cal] [Halld-level1] L1 trigger meeting reminder

[Alexander Somov]

Hi Mark,

Thanks for the useful comments.

Actually the proposed mode 8 (GlueX-doc-2776, p3)
is essentially the mode 7 + raw samples. This mode will
be used for debugging; one can verify fpga processing
(pulse integral, time, ...) using offline analysis.
(Note, currently we don't have the integral reported in
mode 8)

We should not gain much by reading out samples
only around threshold crossing, In many cases
people are interested to see the baseline, so that one
needs significant number of samples before the pulse.
Anyway, we'll need to narrow down the readout window
around the trigger time, so that there will be now
big difference between reading out samples for the
whole window or around threshold crossing.


The combined mode, i.e., reporting raw samples for
events with multiple pulses is kind of complicated. I
doubt that in calorimeters we'll be able to reliably
disentangle pile-up events. For scintillators, the
time-walk correction can in principle be done using
the pulse peak, which is reported in mode 7.

Cheers,
       Alex




On Mon, 10 Aug 2015, Mark Ito wrote:

> Alex, et al.,
>
> One thing I have not seen in the email discussions is the idea of a mode 
> where both mode 7 and 8 data come out in the same event. That would allow 
> verification of the algorithm (and of any emulation, though perhaps not 
> necessary with this mode available), on a pulse-by-pulse basis. I would think 
> in such a mode would actually eliminate the need for pure mode 8. Reading out 
> both should not increase the data volume over mode 8 by a large percentage 
> and if we are reading out raw waveforms at all we would not be in a mode 
> where we are trying to push the event read-out rate so doing the processing 
> for both modes should not bother us. I have mentioned this to Hai before in a 
> hallway conversation some weeks ago.
>
> Also, in a previous experiment I was on, we always considered samples both 
> before the rising edge of the pulse and after the trailing edge (i. e., 
> before high-going threshold crossing and after low-going threshold crossing). 
> That ensured capture of the entire pulse, independent of pulse amplitude. 
> Also it gave more complete information about close-in-time pulses in a single 
> channel that appear as merged pulses; not complete, but more complete. It is 
> analogous to having the entire pulse visible on an oscilloscope screen. 
> Admittedly, the trailing edge is less well defined since the slope of V vs. t 
> (a negative slope if we say all pulses are positive going) is much smaller in 
> amplitude, but since V itself is small, the effect is not so bad.
>
> At a more advanced level one could think of having more complicated 
> processing of pulses where a double pulse is detected according to some 
> algorithm. In that case, it might be simpler to pass along the raw waveform 
> for such pulses and only such pulses, i. e., go ahead and read them out. Such 
> pulses should be a small fraction for the majority of channels and thus not 
> create a huge data volume load.
>
>  -- Mark
>
> On 08/09/2015 11:24 PM, Alexander Somov wrote:
>> 
>> Hi,
>> 
>> We are going to discuss with Hai Dong the feasibility to
>> implement some features in the new fadc250 firmware during
>> the meeting tomorrow (Aug 10th).  The meeting will be in
>> our usual place, A110 at 9:30.
>> 
>> Cheers,
>>        Alex
>> 
>> P.S. I've updated GlueX-doc-2776, which containes some proposed
>> changes.
>> _______________________________________________
>> Halld-level1 mailing list
>> Halld-level1 at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-level1
>
> _______________________________________________
> Halld-cal mailing list
> Halld-cal at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-cal
>