<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi All,<br>
    <br>
    It looks like Simon identified the problem. The phase offset
    parameter<br>
    in the data base is wrong. It is set to one while it should be zero.<br>
    This has the consequence that about a 1/6 th of all events are off
    by<br>
    20ns.<br>
    I am currently checking what the else will go wrong with the phase<br>
    parameter is set to zero. I assume the overall timing offset for the
    TOF<br>
    will be off by 4 ns. This is part of Mikes general calibration.
    Hence I <br>
    include him in this email.<br>
    <br>
    cheers,<br>
    Beni<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/09/2015 09:02 AM, Beni Zihlmann
      wrote:<br>
    </div>
    <blockquote cite="mid:5640A791.4070207@jlab.org" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Some Additional Information:<br>
      <br>
      This event 72 has plenty of TOF Hits however the code does not <br>
      make any good TOFPaddleHits out of them and as a consequence<br>
      there are no TOFPoints! <br>
      See below the list of TOFHits that show clearly that there should<br>
      be TOFPaddleHits and TOFPoints in this event!<br>
      <br>
      Another question is, why does the hdview2 display show TOF Points<br>
      indicated by the small circles but the analysis code does
      not!!!!!!<br>
      <br>
      72 NO TOF POINT FOUND around -56 / -52.8306   0<br>
      TOF POINTS: 0<br>
      TOF PADDLE HITS: 0<br>
      TOF HITS:<br>
      1    14    0    21.9892    0.00180846<br>
      1    19    0    18.9116    0.00340961<br>
      1    14    1    15.9522    0.00282884<br>
      1    19    1    20.0516    0.00300154<br>
      0    13    0    22.5638    0.00196538<br>
      0    19    0    -24.383    3.38461e-05<br>
      0    26    0    21.1689    0.00260192<br>
      0    27    0    21.1554    0.00268269<br>
      0    29    0    177.607    0.000225769<br>
      0    13    1    16.8317    0.00314423<br>
      0    26    1    18.682    0.00251154<br>
      0    27    1    18.361    0.00305077<br>
      0    29    1    181.224    0.000116923<br>
      1    14    0    -1.1103    0<br>
      1    16    0    2657.98    0<br>
      1    17    0    2148.19    0<br>
      1    19    0    -6.62601    0<br>
      1    21    0    2656.27    0<br>
      1    19    0    1301.28    0<br>
      1    26    0    449.838    0<br>
      1    14    1    -8.18142    0<br>
      1    16    1    2657.57    0<br>
      1    17    1    2148.19    0<br>
      1    19    1    -4.21791    0<br>
      1    19    1    1301.18    0<br>
      1    21    1    2656.77    0<br>
      1    26    1    451.372    0<br>
      0    13    0    -1.64007    0<br>
      0    26    0    -4.20047    0<br>
      0    27    0    -4.11068    0<br>
      0    29    0    154.786    0<br>
      0    13    1    -7.93381    0<br>
      0    23    1    2655.92    0<br>
      0    26    1    -6.16121    0<br>
      0    27    1    -6.42895    0<br>
      0    29    1    158.365    0<br>
      <br>
      <br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 11/09/2015 08:06 AM, Beni Zihlmann
        wrote:<br>
      </div>
      <blockquote cite="mid:56409A54.1080008@jlab.org" type="cite">Hi
        All, <br>
        attached is a screen shot of event 72 of run 3179. There are 2
        tracks <br>
        that go forward and hit the FCAL. There are also several TOF
        paddles hit <br>
        as indicated by the viewer. However non of the DTOFPoints that
        are <br>
        calculated from the TOF paddle hits overlap with any of the FCAL
        hits <br>
        or the two tracks that are associated with the FACL hits. As a
        result <br>
        the tracks do not have any match points with the TOF. <br>
        This can't be right. Something must be going wrong in our code!
        <br>
        This is also seen by Elton who pointed out that the matching
        efficiency <br>
        of a charged track that does match with an FCAL shower with the
        TOF <br>
        is very bad. This efficiency should be close to 100% but it is
        way lower <br>
        more like 50%. Again, I think this is a problem somewhere in our
        code <br>
        not the detector itself. <br>
        <br>
        cheers, <br>
        Beni <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Halld-pid mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Halld-pid@jlab.org">Halld-pid@jlab.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-pid">https://mailman.jlab.org/mailman/listinfo/halld-pid</a></pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Halld-pid mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-pid@jlab.org">Halld-pid@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-pid">https://mailman.jlab.org/mailman/listinfo/halld-pid</a></pre>
    </blockquote>
    <br>
  </body>
</html>