GlueX TOF Meeting, March 14, 2018

From GlueXWiki
Jump to: navigation, search

GlueX Time-of-Flight Meeting
Wednesday, March 14, 2018
10:00 am EST
JLab: CEBAF Center, Room F226
BlueJeans Meeting number is 350 531 998

Agenda

  1. Announcements
  2. Review of minutes from the January 31 meeting
  3. Calibration Status
  4. Amplified Base Prototype (Beni)
    • the resolution of the Test Paddle is about 20% worse than the Reference paddle 21 (highest rate)
    • going back to the basics by looking at wave forms and comparing to FPGA data uncovers that
      1. algorithm is not adequate (due to high rates)!
      2. Pulse_Peak zero as error flag causes TOF walk correction to fail!
  5. PMT testing
  6. NIM Paper (Paul)
  7. Action Item Recap

Slides

Talks can be deposited in the directory /group/halld/www/halldweb/html/talks/2018 on the JLab CUE. This directory is accessible from the web at https://halldweb.jlab.org/talks/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 on the BlueJeans site. Use your JLab credentials.

Review of minutes from the January 31 meeting

We went over the 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 from Logbook 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.
Retrieved from "https://halldweb.jlab.org/wiki/index.php?title=GlueX_TOF_Meeting,_March_14,_2018&oldid=85949"