[Halld-pid] Time-of-Flight Meeting Minutes, March 14, 2018

[Mark Ito]

Folks,

Please find the minutes below and at

https://halldweb.jlab.org/wiki/index.php/GlueX_TOF_Meeting,_March_14,_2018#Minutes 
.

   -- Mark

_______________________


    GlueX TOF Meeting, March 14, 2018, Minutes

Present:

  * *FSU: * Sasha Ostrovidov
  * *JLab: * Thomas Britton, Eugene Chudakov, Mark Ito (chair), Simon
    Taylor, Beni Zihlmann

There is a recording of this meeting <https://bluejeans.com/s/5iWhS/> on 
the BlueJeans site. Use your JLab credentials.


      Review of minutes from the January 31 meeting

We went over the minutes 
<https://halldweb.jlab.org/wiki/index.php/GlueX_TOF_Meeting,_January_31,_2018#Minutes> 
without significant comment.


      Calibration Status

As reported last time, Beni has done a preliminary calibration of 2018 
data using early runs and has found timing constants very close to those 
obtained in Sprint 2017. A complete calibration of all of the Spring 
2018 data will have to to done at some point, but is not the highest 
priority now (the run is officially still in progress).


      Amplified Base Prototype

Beni has been studying data take this year with the amplifier-on-board 
PMT base mounted on a spare TOF counter in the Hall.


        Resolution

He sees that the resolution of the test paddle (one end with the 
amplifier-on-board the other end standard) is about 20% worse than 
reference paddle 21 from the TOF proper. This is one of the counters 
with the highest rate.


        Going Back to Basics

He showed several plots of recent raw waveform data 
<https://logbooks.jlab.org/files/2018/03/3544404/outputfile.pdf> from 
Logbook Entry 3544404 <https://logbooks.jlab.org/entry/3544404>. Each 
page potentially shows four waveforms: the two ends of the test paddle 
and the two ends of the reference paddle. A missing waveform indicates 
that there was no waveform data for that end.

His conclusions (exclamations marks his):

 1. Algorithm is not adequate (due to high rates)!
 2. Pulse_Peak zero as error flag causes TOF walk correction to fail!

 From the discussion:

  * The pulses from the amplifier-on-board channel show a significant
    baseline shift of about 20 ADC counts.
  * The results of the firmware summary data is also read-out along with
    the waveform data making comparison possible.
  * If the first few samples in the window are above baseline, the the
    algorithm gets confused, often reporting a leading edge at sample 1.
  * Also, in this case the peak amplitude is reported as 0 (peak=0).
    Since the current walk algorithm works on the peak amplitude, the
    hit, including TDC information, is discarded (no walk correction
    possible). This alone may account for the low efficiency of the TOF
    in the high rate counters, an effect that Beni identified months ago.
  * The algorithm is capable of identifying two or more pulses in the
    raw read-out window, though some of the results disagree what you
    can see by eye.
  * The minimum time difference for double pulse separation by the
    algorithm is much less than that you can see by eye, including cases
    where the first pulse returns nearly to baseline.

Bottom line is a large efficiency hit (30-50%) for high rate counters at 
nominal photon flux due to the way the firmware treats the raw data. In 
the limit of zero rate, it seems to do fine, so the TOF rates are 
exposing the problem.

Amelioration strategies:

  * Fall back to using the integral for the time-walk correction in
    cases where the amplitude is reported as 0.
  * Read out the waveform data and analyze timing and amplitude offline
    for regular data taking:
     1. with channel no sparsification (all channels every event)
     2. with channel sparsification (all channels above threshold)
     3. for selected channels, event-by-event (channels which look
        problematic for the algorithm e. g. peak=0)
  * Change to firmware to not use amplitude=0 as a flag for pedestal
    sensing problems.
  * More sophisticated peak finding algorithm in the firmware.

-- 

Mark Ito, marki at jlab.org, (757)269-5295

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-pid/attachments/20180315/3234e67c/attachment.html>