Just to make sure, this behavior isn't observed looking at the recon LCIO files correct? On Sep 20, 2016 7:59 AM, "Sebouh Paul" <[log in to unmask]> wrote: > Without pulse fitting, or the mode7 emulation, all of the hit times would > be at times that are multiples of 4 ns, corresponding to the time of the > first sample crossing the threshold. However, we use a pulse fitting > algorithm, which improves our resolution on timing for the hit, as well as > time-walk corrections. If a fit fails the pulse fitting and the mode-7 > emulation, then we use the time of the first sample that crosses the > threshold. In the "bad files" we see a lot of low energy hits with > multiples of 4ns times, which probably failed both these two methods of > time reconstruction. > > There is also another thing in here I forgot to mention: there is also a > shift in the timing window of when multiple hits are, between the "bad" > files and the "good" files. What i mean is, you'll see a peak in hit time, > corresponding to the trigger window. This peak is shifted between files > generated using the old version of the DST and the new version. > > On Tue, Sep 20, 2016 at 10:47 AM, Maurik Holtrop <[log in to unmask]> > wrote: > >> Hello Sebouh, >> >> There was a bug in the DST maker where it would only write ECAL hits that >> were part of a cluster, and if a hit appeared in two clusters, it would >> write that hit twice. This is not the correct behavior. I fixed this in >> Issue44 (https://github.com/JeffersonLab/hps-dst/issues/44) and then >> merged to master. >> >> So, #1, is because now the unrelated and out of time hits are also in the >> DST. >> I don’t think this explains #2. >> #3 Since the FADC samples at 250Mhz, I would expect all ECAL hit times to >> be at multiples of 4ns, but perhaps I am missing something? >> >> Best, >> Maurik >> >> On Sep 20, 2016, at 9:37 AM, Sebouh Paul <[log in to unmask]> wrote: >> >> Has anyone made modifications to the DST maker since pass0 began in June >> 6? Nathan ran recon and DST maker on some files at the beginning of >> August, and there are some problems with the DST files produced: >> >> 1) 1.5x more ecal hits per event than in DST files generated in pass0. >> 2) two cluster time difference has a much larger sigma than usual. >> 3) many ecal hits have hit times that are exact multiples of 4 ns. >> >> I ran DQM on the corresponding LCIO files, and saw none of these effects, >> so the problem must be in the DST maker. >> >> thanks. >> >> ------------------------------ >> >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the HPS-SOFTWARE list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 >> >> >> >> ------------------------------ >> >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the HPS-SOFTWARE list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 >> > > > ------------------------------ > > Use REPLY-ALL to reply to list > > To unsubscribe from the HPS-SOFTWARE list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1