[d2n-analysis-talk] retimed TDCs and Brad drops the ball on the T2 timing

[Brad Sawatzky]

OK, mea culpa here.  I hope this is semi-coherent... I went through
answering the different bits and then came back to the retiming bit in
the middle of the post.

Bear with me, this trigger business gets kind of complicated...

On Tue, 06 Apr 2010, MATTHEW R POSIK wrote:

>   I had thought that there may be a correlation between the T2 and the T1
> and/or T6. Last week I made two plots DBB.t2:DBBt1 and DBB.t2:DBB.t6
> 
> http://jlab.org/~posik/d2n/BB/trigger/trig_check/2060_t6_t1_t2_mod.png
> 
> There seems to be more correlation between the T2 and the T1.

There will be a correlation between T1 and T2, because T1 is just "T6"
with a lower threshold.  Every T6 should be a T1 too, and every T2 must
have a T6.  The catch is that you can have the T2 and T6 being prescaled
away so that your L1A gets timed off the T1.

> I also looked at a first hit in the T2 re-timed TDC for run 2060 vs
> different trigger bits.
> 
>  http://jlab.org/~posik/d2n/BB/trigger/2060_tdc_bit_lin_Ndata.png

The event counts in this plot don't make sense to me -- are these the
prescaled or un-prescaled triggers?  For example, every T2 must have a
T6 too, but that isn't reflected here.  Any retiming must be done using
the non-prescaled copies of the appropriate triggers (or they won't
exist to retime with).

I'm also a little confused about what it is that you're plotting here...
You only want to retime your signals when the L1A timing is taken by the
'wrong' trigger.  It's not valid when to subtract T2 off for every
event.  Most of the events already have correct timing.

[ . . . ]
> I was looking at the trigger diagram here
> 
> https://hallaweb.jlab.org/wiki/index.php/DAQ_Diagrams

You know what, I think I lied to you...  Damn.

The whole point of the T6 (not T2!) retiming on that page was to make
sure that all of the TDC common stops and the ADC gates were timed off
the Shower signal (ie. the T6).  See my comments on the
Sh_group+Cer_group overlap timing (that forms T2) here:
  http://www.jlab.org/~adaq/halog/html/0902_archive/090210205803.html
So, T2 should carry the timing of T6 for all real electrons.  We then
retime a T2-generated L1A with T6 after the trigger supervisor.  (That's
content of the retiming diagram on the wiki page link from above).
Let me call the T6-retimed trigger L1A_t6.

The correlated walk seen in T2 vs. BBcerT04 in the left plot here
  http://jlab.org/~posik/d2n/BB/trigger/t2_walk/2060_tdc4_t2.png
means that T2 and the BBcerT04 are moving together vs. L1A_t6.  That
just says that BBcerT04 is generating the T2 for those events.  We don't
want to be subtracting the T2 timing off of these -- we're just making a
pseudo-self-timing peak that way.  There's no physics there...my bad.

I still don't understand the shoulder to the right of the peak in
BBcerT04 though (the circled bit in the right plot from above).
It looks like we have a higher chance of recording a random in that
60 bin (30ns) shoulder region.
  - Those shoulder events come in when T2 has a fixed timing relative to
    L1A_t6.  That suggests that the T2 is being timed off of the T6 part
    of the Sh_group+Cer_group overlap.   
  - I think those are random background events in BBcer04 that happen to
    arrive early at the Sh_group+Cer_group overlap.  The timing of the
    overlap is then carried by the Sh_group (which later makes the T6).
    The width of the shoulder should be equal to the width of the
    Cer_group logic pulse at that overlap.  The documentation here
      https://hallaweb.jlab.org/wiki/images/5/5b/Cerenkov_electronics.pdf
    says that width was 35ns or 70 channels for an 1877 TDC.  That
    actually seems to match the width of the shoulder -- I'll be damned.

OK, so I think I now understand the dominant structure in these plots.
  http://jlab.org/~posik/d2n/BB/trigger/t2_walk/2060_tdc4_t2.png
There's still a couple smaller features that I don't get yet.  There's
the second band at T2=565... and it looks like there is a region between
the two horizontal bands in T2 and above that shoulder where the BBcer04
seems to move with T2 again, but with a shallower slope...

Note that the T6-based retiming also helps explain the significant
non-self-timing structure present in the DBB.t2.  I still don't
understand all the structure, but at least I now know why it's not
simple self-timing for T2 triggers.

Oh yeah don't forget to cut out the electronic deadtime pulses (EDTM)
for both the LHRS and BigBite.  That should be one of the standard cuts
(if it isn't already).  These will have timing that, by construction,
matches our electron signals.  It needs to be removed or it will create
peaks that aren't real.

> Am I correct in thinking that the signal at the BB weldment (T1,T2,
> ect) has a time that is determined from when the detectors got a start
> signal? For example say a particle comes in and hits the shower
> causing a TDC signal.  This TDC signal then triggers the shower
> trigger ( T1 ). The newly created T1 signal then arrives at the BB
> weldment and is then sent off to the trigger supervisor?  I also
> remeber you mentioning that there should be a diagram of the trigger
> time gates. I was looking on the wiki but did not see them up there.

In a typical situation the PMT signals get split into two copies, one
half gets sent to ADCs; the second half gets discriminated.  The
discriminated signals are also duplicated: one have goes to the TDC
inputs; the second copy is OR'd and AND'd to form a trigger.  That
trigger is then sent to the trigger supervisor (TS) which which subjects
it to a prescale decision (ie. only accept 1 in 200 of these triggers),
and if it passes will generate the Level 1 Accept (L1A).  That L1A will
form the common stop for all of the TDCs and often provides the gate for
the ADCs as well.

In a more sophisticated system, you may want to form different triggers
by combining the signals from multiple sub-detectors in different ways
(ie. Shower + Cherenkov in a way that imposes a geometric overlap).
That trigger can come into the TS with different timing than the simple
trigger I described above -- even if the same particle is firing
everything.  It all depends on cabling and how the trigger is
constructed.

> I am also confused on why the structure of the retimed TDCs are so much
> different depending on if I plot the first hit
> DBB.BBcerTxx[Ndata.DBB.BBcerTxx-1] or it I plot the last hit
> DBB.BBcerTxx[0]. Here is the same re-timed TDC plot I did above but using
> [0] array rather than [Ndata.DBB.BBcerTxx-1] array. Does this seem correct?
> 
> http://jlab.org/~posik/d2n/BB/trigger/2060_tdc_bits_0.png

Think about what the hits represent and it should become clear why
different hits in a multi-hit event should have different timing
characteristics.  For example, consider an N-hit event in a single TDC
channel.  The TDC is a common stop model that was stopped on a trigger
corresponding to a single real particle passing through the detector
package.  Possible options for what can generating your 'N' hit(s) in
the TDC channel are:
  - signal from the real particle (this should only generate one pulse)
  - random background 
    - constant rate, possibly be very high, could generate multiple
      pulses if you get 'lucky'
    - all are completely uncorrelated with the common stop,

The common stop must be delayed so that it is guaranteed to come *after*
all hits of interest (of course).  The TDC will report the time
difference (relative to the stop) of all hits it saw in a channel up to
1000ns before the common stop arrived.

If N=1 then your hit is either random or real.  Randoms have a flat
distribution, reals pile up in a spike.

If N=2 then you've got 2 possibilities
  - both are random:
    - what distribution would you expect for each hit?
    - note that you have to have a first hit before you can have a
      second hit -- random chance has to hit twice
  - one is random and one is real
    - consider which hit is most likely the real, and which is random
    - what do the two distributions look like?
Consider what do your distributions look like if the randoms rate is 1kHz,
10kHz, 1MHz, 10MHz?

This is a good thing to do with a fellow grad-student so you can bounce
ideas off each other.

(In real life you can also get afterpulsing, reflections, or some other
"echo" pulse that is caused by an initial pulse (could be the particle
you care about, or background).  Allowing different triggers to
contribute to a give histogram makes life even more complicated since
the common stop timing can now move around or fire on different classes
of events.)


> I also checked with Kalyan about how many tracks he saw for his d2n
> 1pass H2 run 1258 and he said he got ~25% one track events, he did
> mention that this was looked at near the d2n running and may have used
> old mwdc software. I looked at the same run I replayed and got ~56%
> one track events.

I think Xin was the optics expert.  Check with him instead.

-- Brad

-- 
Brad Sawatzky, PhD <brads at jlab.org>  -<>-  Jefferson Lab / Hall C / C111
Ph: 757-269-5947  -<>-  Fax: 757-269-5235  -<>- Pager: brads-page at jlab.org
The most exciting phrase to hear in science, the one that heralds new
  discoveries, is not "Eureka!" but "That's funny..."   -- Isaac Asimov