From G.F.Pearce@rl.ac.uk  Tue Feb 11 10:13:34 2003
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	["6305" "Tuesday" "11" "February" "2003" "15:13:03" "-0000" "Pearce, GF (Geoff) " "G.F.Pearce@rl.ac.uk" "<A5AF6F04CF7FD311BC5700902773DDC701196BC2@exchange13.rl.ac.uk>" "150" "RE: FarDet trigger." "^From:" nil nil "2" nil "FarDet trigger." nil nil nil nil nil nil]
	nil)
Received: from smtpgw3.sec.bnl.local ([192.168.1.47] helo=smtpgw3.bnl.gov)
	by minos with esmtp (Exim 3.34 #1 (Debian))
	id 18ic6I-0007H4-00
	for <bviren@minos.phy.bnl.gov>; Tue, 11 Feb 2003 10:13:34 -0500
Received: from bnl.gov ([130.199.128.163])
	by smtpgw3.bnl.gov with esmtp (Exim 3.36 #1 )
	id 18ic6K-00007f-00
	for <bviren@minos.phy.bnl.gov>; Tue, 11 Feb 2003 10:13:36 -0500
Received: (from daemon@localhost)
	by bnl.gov (8.12.4/8.9.2) id h1BFDVJB003590
	for bviren@minos.phy.bnl.gov; Tue, 11 Feb 2003 10:13:31 -0500 (EST)
Received: from smtpgw1.bnl.gov ([192.168.1.45])
	by bnl.gov (8.12.4/8.9.2) with ESMTP id h1BFDTIV003579
	for <bv@bnl.gov>; Tue, 11 Feb 2003 10:13:29 -0500 (EST)
Received: from exchange01.rl.ac.uk ([130.246.135.134])
	by smtpgw1.bnl.gov with esmtp (Exim 3.36 #1 )
	id 18ic5y-0000wB-00
	for <bv@bnl.gov>; Tue, 11 Feb 2003 10:13:14 -0500
Received: by exchange01.rl.ac.uk with Internet Mail Service (5.5.2656.59)
	id <1HMV75M0>; Tue, 11 Feb 2003 15:13:05 -0000
Message-ID: <A5AF6F04CF7FD311BC5700902773DDC701196BC2@exchange13.rl.ac.uk>
From: "Pearce, GF (Geoff) " <G.F.Pearce@rl.ac.uk>
To: "'Brett Viren'" <bv@bnl.gov>
Cc: "Pearce, GF (Geoff) " <G.F.Pearce@rl.ac.uk>
Date: Tue, 11 Feb 2003 15:13:03 -0000
Subject: RE: FarDet trigger.
X-PH: V4.4@bnl.gov
X-Mailer: Internet Mail Service (5.5.2656.59)
X-MailScanner: Found to be clean, Found to be clean
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.31
X-Spam-Level: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Brett,

Sorry I don't have this on the web. I really should have so I'll make this
the seed for generating a page.

The triggering in the DAQ is intentionally made inclusive, in as much as
that is possible rate wise. Pulse height is not used at all outside of the
electronics. The assumption is made that we want as loose a trigger as
possible and that the offline event selection on the snarls will make a
tighter selection - channel dependent no doubt.

There are two parts to the answer:

a. how does the electronics 'trigger' a hit (dynode thresholds,
sparsification thresholds, VARC trigger)

b. how does the DAQ form a trigger from collections of hits.

Hits.
====

Critical to the triggering and the reconstruction, particularly for NuE I
would guess, is what constitutes a hit. This is defined in the electronics.
We are meant to run "triggerless", meaning each PMT self triggers with it's
dynode signal. It's one of the big advantages of our system, but as you know
the scintillator readout fibers are generating their own light and pushed
the singles rate up by ~ x10. It also put the chip dead time rate up in the
same way, so the decision was to put local triggering in the FEE (the VARC
2/36 trigger) as this solved both problems (the DAQ could be made to handle
the rate but could do nothing about the chip dead time). 

So, what is a hit:

1. The PMT dynode signal must be above threshold. The thresholds should be
individually set to 1/3 p.e. but this tuning has yet to be done at Soudan.
They are using the same DAC threshold value throughout at the moment I
believe, so the threshold will be different for each PMT in terms of pe's.
In the design system, this is the only trigger there is.

2. Each VARC can serve up to 36 chips (12 VFBs, 3 VA chips each). Each chip
is one PMT of course. The VARC trigger requires that at least 2 of the chips
on the VARC satisfy the above dynode trigger before the VA chips digitise.
If there really are 36 chips connected to the VARC, this is a 2/36 local
trigger. In fact, many VARCs do not have this many chips connected so for
them it is a 2/N local trigger, where N<36.

Yes, this can lose single hits at VARC boundaries - you have to be careful
of this.

3. Shield PMTs are excluded from the VARC trigger. They need only satisfy 1.

4. If the trigger is satisfied, all 16 channels on the triggering chips are
digitised and read out, subject to the sparsification threshold, i.e. zero
suppression. The sparsification thresholds need to be fine tuned at Soudan
also, and should be set at about 3 pedestal widths above pedestal.

The scintillator rates have been slowly dropping so it is possible that one
day we may be able to drop the VARC trigger or reduce it to a 2/6. We
(sergei in particular) are watching this but nobody is holding their breath.

Snarls
======

Now the DAQ trigger. The DAQ is using the "gap" method at Soudan to identify
a "candidate snarl" based purely on timing information and then applies a
trigger test to that candidate. The procedure is

1. Time order all the detector hits. Scans through the hits are always done
in time order.

2. Starting with the first hit, scan through the hits until the time
difference between neighbouring hits is larger than T<gap>. Let's say this
happens on hit n, then (T<n+1> - T<n>) > T<gap>.

This defines the candidate snarl, i.e. hits 1 to n inclusive. 

A value for T<gap> of 100 clock ticks is being used, the same as at CalDet
(1 VA clock tick is the usual 25/16 ns).

3. Using all of the hits in the candidate (1 to n) test to see if M planes
in any consecutive N planes have at least one hit in them. Any hit,
regardless of pulse height, qualifies. M and N are 4 and 5 respectively,
i.e. 4 out of 5 plane trigger.

4. That's it. If it triggers, write it out. If not, dump it. Then start
again at hit (n+1)

This is an inclusive trigger aimed at minimum bias. An offline selection
should cut the rate down considerably. 
In addition to the plane trigger, I introduced an "activity" trigger for
development testing at one point which was 'OR'd with the plane trigger.
This required that the candidate snarl had hits in ANY N<activity> planes. I
intended to extend this to trigger on energy deposited as well, though that
has issues of calibration to negotiate. We are not running with the activity
trigger. It was removed from the trigger mask because of the Light Injection
echoes that the electronics is producing - it was very efficient at picking
up the echoes! This was part of the raison d'etre, to identify correllated
detector noise, so I guess it was successful.

The second method the DAQ can apply is NOT being used at Soudan although
there are a number of reasons why we might want to switch back to it. The
"gap" method was strongly favoured at the CalDet which is why we have been
using it as the default at Soudan. The second method is the sliding window.

1. Hits are time ordered as above

2. Step through the hits one at a time. Let's say we are starting at hit n
for the sake of this example. If the time of this hit is T<n>, collect all
the detector hits that fall in the time window T<n> to T<n> + dT<window>. I
tuned dT<window> to 50ns using MC (a long time ago) but of course it could
be anything.

3. Test these hits to see if they satisfy the M out of N plane trigger.

4. If they do not satisfy the trigger, step forward one hit and start again.
i.e. go back to 2. and use hit (n+1) as the start hit.

5. If they do satisfy the trigger, define the snarl to be all hits in the
fixed time window T<n> to (T<n> + dT<readout_window>). The readout window
size can be anything, typically ~ 200ns. Then go back to 2. and start again
with the first hit AFTER the snarl.

Hope this is clear.

Geoff

-----Original Message-----
From: Brett Viren [mailto:bv@bnl.gov]
Sent: 10 February 2003 16:42
To: Geoff Pearce
Subject: FarDet trigger.

Hi Geoff,

I want to check that the FarDet trigger is correctly implemented in
the current GMINOS with an eye on seeing how the current 4/5 setting
effects nu_e searches.

Can you point me to details on exactly how the trigger is implemented?
For example, what is the PE threshold for a plane to be considered
"hit"?  How is that added up from individual digits?  How is the 4/5
selection implemented?

Thanks,
-Brett.

From G.F.Pearce@rl.ac.uk  Tue Feb 11 12:21:48 2003
Status: RO
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
	["2443" "Tuesday" "11" "February" "2003" "17:21:28" "-0000" "Pearce, GF (Geoff) " "G.F.Pearce@rl.ac.uk" "<A5AF6F04CF7FD311BC5700902773DDC701196BCD@exchange13.rl.ac.uk>" "62" "RE: FarDet trigger." "^From:" nil nil "2" nil "FarDet trigger." nil nil nil nil nil nil]
	nil)
Received: from smtpgw2.sec.bnl.local ([192.168.1.46] helo=smtpgw2.bnl.gov)
	by minos with esmtp (Exim 3.34 #1 (Debian))
	id 18ie6O-0007bM-00
	for <bviren@minos.phy.bnl.gov>; Tue, 11 Feb 2003 12:21:48 -0500
Received: from bnl.gov ([130.199.128.163])
	by smtpgw2.bnl.gov with esmtp (Exim 3.36 #1 )
	id 18ie6I-0002be-00
	for <bviren@minos.phy.bnl.gov>; Tue, 11 Feb 2003 12:21:42 -0500
Received: (from daemon@localhost)
	by bnl.gov (8.12.4/8.9.2) id h1BHLgE1014563
	for bviren@minos.phy.bnl.gov; Tue, 11 Feb 2003 12:21:42 -0500 (EST)
Received: from smtpgw2.bnl.gov ([192.168.1.46])
	by bnl.gov (8.12.4/8.9.2) with ESMTP id h1BHLgIV014559
	for <bv@bnl.gov>; Tue, 11 Feb 2003 12:21:42 -0500 (EST)
Received: from exchange07.rl.ac.uk ([130.246.135.148])
	by smtpgw2.bnl.gov with esmtp (Exim 3.36 #1 )
	id 18ie6F-0002Zc-00
	for <bv@bnl.gov>; Tue, 11 Feb 2003 12:21:39 -0500
Received: by exchange07.rl.ac.uk with Internet Mail Service (5.5.2656.59)
	id <1JPGT3VS>; Tue, 11 Feb 2003 17:21:36 -0000
Message-ID: <A5AF6F04CF7FD311BC5700902773DDC701196BCD@exchange13.rl.ac.uk>
From: "Pearce, GF (Geoff) " <G.F.Pearce@rl.ac.uk>
To: "'Brett Viren'" <bv@bnl.gov>
Cc: "Pearce, GF (Geoff) " <G.F.Pearce@rl.ac.uk>
Date: Tue, 11 Feb 2003 17:21:28 -0000
Subject: RE: FarDet trigger.
X-PH: V4.4@bnl.gov
X-Mailer: Internet Mail Service (5.5.2656.59)
X-MailScanner: Found to be clean, Found to be clean
X-Spam-Status: No, hits=1.1 required=5.0
	tests=DOUBLE_CAPSWORD
	version=2.31
X-Spam-Level: *
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Brett,

1) Do VARC boundaries ever slice a plane?  That is, are there any
planes that are read out by more than one VARC? 

===========
No, the VARC boundary should never disect a plane. A single VFB (MUX box if
you like) serves one side of readout from two planes. There are 3 chips on
the VFB (16 channels used on each, a plane needs 24). Two of the 3 chips are
dedicated to individual planes; the third chip is shared between planes (8
channels each).

In short, the unit is exactly two planes go to a single VFB and two VFBs go
to a single VMM on the VARC, so they don't cross VARCs.

This is not to say nobody could do it!
===========

2) Given a 2/N local trigger in some VARC, are all other VARC's read
out, regardless of their local trigger status?

==========
No. Only the chips that triggered are read out. All this is doing is
tightening the dynode triggering a little by demanding at least one other
PMT on the VARC was above threshold to get the rate down. This can be done
easily in the VARC firmware since it initiates the VA digitisation. The
VARCs don't talk to one another. 
==========

I am guessing both answers are "no".  If so, then at worse an event
will loose one hit (err. "digit"), correct?

===========
Yes, probably. It must depend on what the events look like. Andrei did a MC
study of this about a year ago. He presented the results at a Minos meeting
so his slides must be on Dave Ayres web page somewhere.
============

So, (if correct), we will loose events which have exactly 4 out of 5
hit planes with 3 hits planes read out by one VARC and 1 hit plane
(with one hit PMT) inside the neighboring VARC.  It remains to be seen
what loss in efficiency this translates to.
============
Sounds right. I'd look to a simulation though! There is also an effect on
the energy measurement of events that do trigger.
============

BTW, ignoring this VARC boundary issue, I applied a simple 4/5 plane
trigger to the MC, with a hit plane being defined as having at least
one reconstructed "CandStripSR".  I find that 1.5% of beam nu_e CC QE
events are lost.
==============
That doesn't sound too bad. Are the thresholds used in the MC realistic? 
When I did a study of this for the TDR I found 0.5% of neutrino events
failed the trigger; these were all NC events - I didn't look at nu_e
specifically. Also, it was with the high energy beam, the vogue in those
days, which would be less sensitive.
===============

Geoff

From G.F.Pearce@rl.ac.uk  Mon Feb 17 13:48:12 2003
Status: RO
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1956" "Monday" "17" "February" "2003" "18:48:07" "-0000" "Pearce, GF (Geoff) " "G.F.Pearce@rl.ac.uk" nil "53" "RE: FarDet trigger." "^From:" nil nil "2" nil "FarDet trigger." nil nil nil nil nil nil]
	nil)
Received: from smtpgw3.sec.bnl.local ([192.168.1.47] helo=smtpgw3.bnl.gov)
	by minos with esmtp (Exim 3.34 #1 (Debian))
	id 18kqJI-00034X-00
	for <bviren@minos.phy.bnl.gov>; Mon, 17 Feb 2003 13:48:12 -0500
Received: from exchange07.rl.ac.uk ([130.246.135.148])
	by smtpgw3.bnl.gov with esmtp (Exim 3.36 #1 )
	id 18kqJG-0003ZX-00
	for <bv@bnl.gov>; Mon, 17 Feb 2003 13:48:10 -0500
Received: by exchange07.rl.ac.uk with Internet Mail Service (5.5.2656.59)
	id <1JPGTY43>; Mon, 17 Feb 2003 18:48:08 -0000
Message-ID: <A5AF6F04CF7FD311BC5700902773DDC701196C08@exchange13.rl.ac.uk>
From: "Pearce, GF (Geoff) " <G.F.Pearce@rl.ac.uk>
To: 'Brett Viren' <bv@bnl.gov>
Cc: "Pearce, GF (Geoff) " <G.F.Pearce@rl.ac.uk>
Date: Mon, 17 Feb 2003 18:48:07 -0000
Subject: RE: FarDet trigger.
X-Mailer: Internet Mail Service (5.5.2656.59)
X-MailScanner: Found to be clean
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.31
X-Spam-Level: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Brett,

Not so easy! To first order the following applies. There are 3 VARCs in each
crate (0,1,2). Varc 1 is full of "detector plane" VFBs and VARCs 0 and 2
have 10 out of their 12 VFB slots connected to planes. The remainder are
either shield readout or the LI pmt (TPMT), both of which are excluded from
the VARC triggering.

(So, for example, Varc0 of Crate 0 is a 2/30. Remember, each VFB = 1 MUX box
= 3 PMTs)

This is only to 1st order because the last two crates of SM1 do not get
filled so well. There aren't enough planes, so they "mop up" what is left.
The last 2 planes of SM2 do work out pretty well; because SM1 was filled to
capacity, there are fewer planes in SM2 (the total is constant) and the last
2 crates rather neatly fill up 2 VARCs each.

Look at the DAQ map:

http://www-numi.fnal.gov/minwork/daq/fardet/cabling-map.html

All those slots that are white background with plane numbers written on them
are in a "2/N" VARC trigger. The rest (TPMT (red), SHLD (green) or unused
(black)) are NOT. Since you are running offline jobs, you can get the
accurate mappings directly into your MC from the Plex.

NB Shield installation is ongoing so many of those marked unused (black)
will read out shield as it is installed.

Geoff

-----Original Message-----
From: Brett Viren [mailto:bv@bnl.gov]
Sent: 13 February 2003 20:19
To: Pearce, GF (Geoff) 
Subject: RE: FarDet trigger.

Hi Geoff.

I hope you will indulge another question:

You mention that the 2/"36" local trigger is not always 2/36 because
some VARCs are not fully instrumented with PMTs.  Can you give me an
idea of the distribution of VARC PMT occupancy?  Is it just VARCs at
the end of each super-module which are not full?

So far a pure 2/36 + 4/5 plane trigger seems to be okay for both
trigger efficiency and energy for nu_e CC QE events, but if the "36"
is significantly lower over much of the detector the small effect that
I do see will, of course, increase.

-Brett.