this file is /e787s/jrstone/kofia/stc/stc.txt Wed Jan 4 18:55:08 EST 1995 Stopping Counter Finder Update -- JRS The LeCroy 2366 (now in slot 8 of CAMAC crate 40) takes as input 24 T.2 signals and 24 phi.CT signals from the range cards. The phi.CT signals are delayed with 32 feet of flat cable and the T.2's delayed with 37 feet of flat cable to time in properly with the Extended T.2 signal which strobes the stopping counter finder. The RZ board supplies 2 copies of the Extended T.2 signal, one of which goes to input J4 pin 12 in slot 16 of the same crate (which is a fanout). I use J6, pin 14 on that board (one output of the fanout) as the strobe (which is pin *17* on J2 of the LeCroy module). Right now I am using 6 output bits from the module, which I have wired up to the I/O board in slot 21 of the top fastbus crate. The signals are now going into J2, pins 1-6. We took 2000 kmu22's this morning (run 20057) and I looked for events where my stopping counter finder disagreed with rd_trk about what the stopping sector was. Looking at these events in photo, I see only ~10 events that look like the stopping counter finder didn't give the right answer. All of these look like event #1 below. A small about of energy was deposited in the last counter of the track, after a sector crossing. Next I ran through a tape (run 20058) of ~50k kmu22's looking for events where the stopping counter finder couldn't find any T.2's (this should never happen). 30 events surfaced. Looking at them in photo, they fell into two classes of events. The first (of which event #2 below is representative) type has a sector crossing near the 2 counter and as a result the 2 counter has very little energy in it. The second type (event #3 below, for example) has some kind of scatter in the T counter, with a lot of energy deposited there. ----------------------------------------------------------------------------- Thu Jan 5 21:06:02 EST 1995 Stopping Counter Finder Update -- JRS Today I took 3000 pnn-level 0 (old) events to disk (run 20154) and looked for events where rd_trk, my stopping counter finder, and the current method (SHEX in TR2BITS) did not all agree on what the stopping hextant was. 72 events surfaced (not including events that failed the hextant cut). In most of these, the stopping counter finder agreed with rd_trk; it was SHEX which disagreed. A good fraction of these look like event #1 below (the last counter didn't have enough energy to fire that hextant). Some of these look like event #2 (the adjacent hextant was fired by an accidental). I could find no events in this sample where the stopping counter finder failed to find the right stopping hextant AND the current method didn't also fail. ----------------------------------------------------------------------------- Thu Jan 12 21:18:35 EST 1995 Stopping Counter Finder Update -- JRS The SCF now puts out 8 bits of information: 3 bits - Stopping Hextant (1-6) 1 bit - One and only one T.2 (0-1) 2 bits - Stopping Sector (within stopping hextant) (0-3) 2 bits - T.2 Sector (counting back from stopping sector) (1-3) As always, if the one and only one T.2 bit is low, the other bits are meaningless. I wired the 8 outputs to a FO board in the top Eurocrate, and wired the outputs of the FO to the first 8 inputs of the IO board. Still to do: Wire it to the level 1.1. ----------------------------------------------------------------------------- New Stopping Counter Finder program -- JRS Sun Feb 5 15:01:17 EST 1995 Today after run 21468 I downloaded a new program to the SCF (stc14.asc). Previously (program stcn11.asc), it delivered the stopping hextant (1-6) to the L1.1 if it found one and only one T.2. If it found 0 T.2s it delivered SHEX=0 to the L1.1 resulting in the event being passed. If the SCF found more than one T.2 it delivered a mostly random number from 1-7 to the L1.1. The new SCF logic handles the #T.2s>1 case differently. It picks the first T.2 it finds (starting at sector 24 and working around to sector 1) and calculates a valid stopping hextant for it (1-6). ----------------------------------------------------------------------------- New Stopping Counter Finder program -- JRS Sat Mar 16 17:54:20 EST 1996 I changed the default SCF program from stc14 to stc15 in /e787/local/online/camac/scf/setup_scf_95. When we used stc14 (in '95 data) if the SCF could find no T.2 it returned SHEX=0, resulting in the event automatically passing L1.1. With stc15 ('96 data) the SCF will return SHEX=7 if it finds no T.2, and the event will automatically fail L1.1. The SCF should never return SHEX=0 now.