<!-- Title: 12:00:05  Tue Apr  8 2003 -->
<!-- Crewchief: Dave Toback -->
<!-- Op1: Sungwon Lee -->
<!-- Op2: Slava Krutelyov -->
<!-- Op3: Max Goncharov -->
<!-- Op4: and friends... -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<b>This is the EMTiming log, in which all detector-related activities are recorded and explained!</b> 


<!-- Date: Tue Apr 8 12:01:31 2003 -->
<pre>This is the start of the e-log for the CDF RUN2 EMTiming activity. Please write everything related to the project. 
 
This log should be used to update and summarize work done on the test-stand/detector and readout, including calibration runs, monitoring software, etc.</pre>
<!-- Author: Sungwon Lee -->
<!-- Comment: Sun Apr 20 15;43;54 comment by...Sungwon -->
<font size="+2"><b>=> <a href="http://txpc1.fnal.gov/emtiming/log.html">Current Hardware Configuration</a></b></font>
<!-- Date: Tue Apr 8 15:26:51 2003 -->
<pre>You can check the results of the HV tests for CEM LED. (All runs are MyronMode)  
http://txpc6.fnal.gov/~slava77/YMon/dump/dump-161077.txt  
http://txpc6.fnal.gov/~slava77/YMon/root/YMon161077.root  
Files for LED run with all HVs on at normal.  
 
http://txpc6.fnal.gov/~slava77/YMon/dump/dump-161078.txt  
http://txpc6.fnal.gov/~slava77/YMon/root/YMon161078.root  
LED run with LEFT PMT ON (~1.1kV), right PMT STNDBY (~0.92kV)  
 
http://txpc6.fnal.gov/~slava77/YMon/dump/dump-161079.txt  
http://txpc6.fnal.gov/~slava77/YMon/root/YMon161079.root  
LED run with RIGHT PMT ON (~1.1kV), LEFT PMT STNDBY (~0.92kV)  
 
http://txpc6.fnal.gov/~slava77/YMon/dump/dump-161080.txt  
http://txpc6.fnal.gov/~slava77/YMon/root/YMon161080.root  
LED run with LEFT and RIGHT PMT STNDBY (~0.92kV)  
 
You can see that in standby the ASD channel inputs are still above thresholds, and we have hits in both.  
</pre>
<!-- Author: slava77 -->
<!-- Comment: Tue Apr  8 15;27;29 comment by...slava77 -->
<pre>... we have hits in both CEM channels.</pre>

<!-- Comment: Tue Apr  8 16;30;25 comment by...slava77 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>You should change the links above <br>
from ...~slava77/YMon to ...~slava77/emTiming/YMon <br>
to be able to read them</pre></td></tr></td></table>


<!-- Date: Wed Apr 9 10:59:26 2003 -->
<pre>Updated list: 
 
 1) Make sure all channels of spare ASD are working properly (double check> 
the swapped chip channels, the RS422 swapped channels, and the lon 
 monostable width channels) so we can swap it in if necessary. 
 
2) Check for bad soldering on all channels of the TB so we could swap it in 
if necessary. Just check with splitter or pulser for now. Can do full check 
with PEM PMT later. 
 
3) Get spare TDCs and put in TDC crate for Frank. 
 
4) Get EMTiming crate finalized with Frank and Bill. Move to new TDC crate 
when it is ready. 
 
5) Get PEM PMT hooked up. Hook up the PEM PMT (do we need anything from 
Mike? If so, let me know) to do more realistic tests of the TB reflections. 
 
6) Put 2.2K resistor and 10pF cap on an ASD channel to check width. Should 
be 88nsec. Measure what the values of the capacitor is that is on now. 
 
7) Cross talk during plug laser calibrations. (Check log book first). 
 
after that: 
 
 8) Get scope pictures of the input to the TDC of Wedge 23, eta=-17 (low 
 widths, double firing, bad RMS etc). Looked fine with test card. Check 
scope 
 probe on TDC in the crate (in EMTiming crate) for LVDS inputs and outputs. 
 
 
9) Check TB with the PEM PMT. 
 
</pre>
<!-- Author: Dave Toback -->


<!-- Date: Wed Apr 9 11:10:03 2003 -->
<pre>Eric and I put a TDC (board number=715) into EMTDC crate (b0etc00), slot 5, and did a programming. </pre>
<!-- Author: Sungwon -->
<!-- Comment: Wed Apr  9 13;57;40 comment by...Sungwon -->
<pre>Eric and I also tried to do some DAQ test with new TDC via RC, but we're getting some errors in cold start stage; RC was just stop somewhere in initiation step. Eric said it's not a problem of TDC itself. I then talk to Frank and knew that he also had some problem and now they are working on it. Frank said that it would be connection problem of EMTDC crate. Therefore some peoples (JJ, Dervin and others) will take a look at the crate.   </pre>


<!-- Date: Wed Apr 9 16:40:25 2003 -->
<pre>Today DAQ peoples got some of the cables connected in EMTDC crate. But it looks like there still is a cable not connected from the crate to the vrb. Frank Chlebana will let us know when they can read it out.</pre>
<!-- Author: Sungwon -->


<!-- Date: Thu Apr 10 14:14:14 2003 -->
<pre>We had access today and have replaced EMTiming ASD board with the new one (10pF capacitors in it - not for all channels)</pre>
<!-- Author: Sungwon and slava -->


<!-- Date: Fri Apr 11 18:24:35 2003 -->
<pre>I received the parcel what Marco sent us. I will take a look at 
the all spare components for the ASD and will post what we get from you on the web shortly. There're also 4 schematic diagams in the parcel.</pre>
<!-- Author: Sungwon -->
<!-- Comment: Sat Apr 12 13;43;10 comment by...Sungwon -->
<ul>
<li>20 Chips One Shot PHS74HCT221
<li>14 Chips LVDS Drivers NSDS90C031TM
<li>20 Chips Fast Comparators ANAAD8561AR
<li>20 Voltage Reference LM4040CM4.l
<li>20 Diodes IN5908
<li>20 Red LED
<li>20 Pins
<li>50 Inductors
<li>20 Jumpers
<li>20 Trimmers 2Kohm
<li>600 Resistors SMT 0805 Different Values
<li>250 Capacitors SMT 0805 Different Values
</ul>


<!-- Date: Mon Apr 14 11:11:18 2003 -->
<pre>gave some "Male Jackscrew bodies" to Dervin</pre>
<!-- Author: Sungwon -->


<!-- Date: Tue Apr 15 14:54:04 2003 -->
<pre>We put 12 10pF SMT capacitors on the ASD board at the PPD-EE department. Thanks, Lou, for the helps. We also got some extra 10pF SMT capacitors from Lou. We will use them for the 1st ASD in dowmstairs later. The next thing to do is to check width, and it should be around 88 nsec. Both the ASD and extra 10pF SMT capacitors are in in office now.</pre>
<!-- Author: Sungwon -->


<!-- Date: Wed Apr 16 12:11:23 2003 -->
<pre>The TDC in the EM_Timing_00 crate slot 5 got programmed last night by Dan at a request of Slava. In the morning, Dervin pulled out 220 ft cable from HADTDC crate, and reroute the cable to EM_Timing_00 crate. I then plugged the cable in to the TDC in the EM_Timing_00 crate slot 5. Frank and I asked some test runs with new EMTDC configuration to operational manager, Andy, and Aces. They will take a cosmic run and a L2 torture run for the test. </pre>
<!-- Author: Sungwon -->
<!-- Comment: Wed Apr 16 14;44;59 comment by...Sungwon -->
<pre>Aces ran cosmics (no track and no muon scintiallator) with our crate em_timing_00. Readout failed immediately with apparently no header for the tdc. They have ended the run and taken the crate out. Slava said that he has changed the module ID for TDC in slot  
5 and the tdc apparently was not yet reprogrammed at the time of the run. Dan is going to reprogramme as soon as possible. As soon as everything is finish up, we can ask some test runs again to aces.   </pre>
<!-- Comment: Wed Apr 16 14;47;53 comment by...Sungwon -->
<pre>===============================================================
Below is Frank's comment in shift e-log (Wed Apr 16 14:27:32):
===============================================================
Earlier today we were able to readout the etdc crate but now  we are geting the following error: 

Runtime Error 0: TDC_readAllFifo: slot=5 No valid header, 0x400009b, evt=1 
TDC_readAllFifo: card  = 0 fifo emptied iTry = 1 header = 0x69800000  

</pre>
<!-- Comment: Wed Apr 16 14;49;19 comment by...Sungwon -->
<pre>===============================================================
Below is Ace's comment in shift e-log (Wed Apr 16 14:37:12):
===============================================================
Standing request today from Sanwon Lee & Dave Toback 
to include em_timing_00 crate in l2 torture/cosmic runs. 
Tried and failed twice (tdc header problem) and ready 
to try again when resources available. </pre>
<!-- Comment: Wed Apr 16 15;22;50 comment by...Sungwon -->
<pre>Dan just reprogrammed the TDC in EMTDC crate - which should fix the readout problem. After reprogramming we were able to include it, so it should be ok now. I asked to shift crews to include em_timing_00 crate again in L2 torture/cosmic runs,  </pre>
<!-- Date: Wed Apr 16 14:12:04 2003 -->
<pre>I've been looking at the multifire problem using Runs 161171 and 161220 which is real data and laser respectively. I've picked two of the largest culprits: (wedge 0, eta=-17) and (wedge 23, eta=-17). 
 
Here's what I found:  
For (0,-17): In real data 810 events fire the TDC in time, 17 have double fires. Channel (0, -16) also fires during 166 of these events, 16 of which are double fires. The one double fire which does not have (0,-16) firing, has (0,-14) firing. No other channel has even this high degree of correlation. In laser 
we only double fire 110 times out of 1000, even though all channels are always correlated. 
 
For (23,-17): 463 events fire the TDC in time (this channel has a dead dynode so it doesn't fire as often), 16 have double fires. Channel (23, -16) also fires during 142 of these events, 13 of which are double fires. Of the 463 fires, Chan (23,-15) also fires during 49 of them, with 13 double fires. Ten of 
the double fires have both -15 and -16. 34 of the 463 times both -15 and -16 also fire, and 10 of those times we double fire.  No other channel has even this high degree of correlation.  In laser we always double fire.  
 
So: In data, the end towers have a ~20% chance of a neighboring tower firing, and if there is a coincidental neighboring tower firing there is a ~10% chance we will double fire for channel (0,-17). Channel (23,-17) seems different as it fires more consistently based on other channels.  
 
I can't tell if this is TDC or cable.   </pre>
<!-- Author: David Toback -->






<!-- Date: Thu Apr 17 13:30:37 2003 -->
<pre>from ps manager: The operations plan is to include the EM timing crate in real physics running only after we've integrated  sufficient time with it in cosmics and L2 torture tests with no problems. 
 
from Frank: As a first step can we have the em timing crate included in the L2 torture and cosmic configurations so that we do not have the problem that the shift crew forgets to include the crate by hand. It has already been included in running with the evb and we have seen the data from this card written out to disk so I think it is ready for the next test. The next step would be to include it by hand in a physics run at the end of the store...</pre>
<!-- Author: Sungwon -->


<!-- Date: Sat Apr 19 12:29:28 2003 -->
<pre>EM_TIMING_00 is added and saved as default run config. (by andy and kaori) in the followings:  
aaa_shotsetup  
ace_cosmic_all  
ace_cosmic_notrack  
cosmic_nosilicon_tape  
cosmic_silicon_tape  
l2torture</pre>
<!-- Author: Sungwon -->
<!-- Comment: Sat Apr 19 13;26;21 comment by...Sungwon -->
<pre>We just took run 161718. Please take a look at the monitoring result on the web; http://txpc6.fnal.gov/~slee/emtiming/  or http://txpc6.fnal.gov/~slee/objmon/</pre>


<!-- Date: Sat Apr 19 14:35:40 2003 -->
<pre>    I spent awhile looking at energy corrections for the timing using data from 161171. We have 4 cases in our system: CEM  with 1 or 2 PMTs and PEM with 1 or 2 PMTS.  I tried a number of different correction factors: (here A is a constant, and E is the energy) 
 
CEM 1 tube: Tried A/E and A/sqrt(E). Either worked ok. 
 
CEM 2 tubes: A/(E1+E2) and A/sqrt(E1*E2) worked well, A/sqrt(E1+E2) and 
A/sqrt(Etot) didn't. 
 
PEM 1 tube: A/E and A/sqrt(E) both worked 
 
PEM 2 tubes: A/sqrt(E1+E2) worked, A/(E1+E2) didn't. 
 
        Not really sure why all these are true. 
 
    In anycase, for simplicity I found that to first order we can make good corrections (good enough for monitoring)  for all the channels if we take the following: 
 
CEM: corrected t0 = t0-(80/(E1+E2))  where E1 and E2 are the energies of the PMTS, assuming the tube is going into the ASD (for wedge 0, this only is the odd energy). 
 
PEM: corrected t0 = t0-(13/sqrt(E1+E2)) where again the energy of the PMT is only counted if the dynode is alive (can get this list, from the 100% eff. ObjectMon plot). 
 
    When one takes these corrections into account we see the RMS of the distributions go down to just above 2 nsec which is comparable to the HADTDC system. The numbers 80 and 13 are determined experimentally by minimizing the RMS as a function of the correction factor. 
 
     Vadim: Would you make a new canvas for ObjectMon. In this canvas, let's make it the same as the RMS canvas, but instead of having the RMS of t0, let's have it be the RMS of the corrected t0. This can be monitored since it should be around 2 nsec for each tower regardless of the trigger table or physical location. It just requires the dead channel lookup table at the beginning to know which tubes to add into the energy sums. 
 
    Max: This is probably a good start for your corrections. Let me know if you get different answers. This would be great to automate and refine for high statistics. 
</pre>
<!-- Author: Dave Toback -->


<!-- Date: Sat Apr 19 14:36:51 2003 -->
<pre>	I was looking at Run 161718 from ObjectMon and was noticing that while things in general look good (and in many ways BETTER) that things are fairly different. 
 
	For example there don�t seem to be two peaks in the t0 distribution anymore and the widths are in general much better, except for the CEM where they look worse. 
 
	Are we sure this TDC is calibrated? Is this the same TDC that was in the previous crate?  
 
</pre>
<!-- Author: Dave Toback -->
<!-- Comment: Sat Apr 19 15;52;44 comment by...Sungwon -->
<pre>The TDC we're using now in EMTDC crate (slot 5) is a new one we got from Michigan. The board number is 715. This was programmed last week. Below is the current status of the EMTDC crate. 
===============================================================
 b0etdc00  2   IDPROM = 0083 001 TRACER__V2.1A
 b0etdc00  3   (empty)
 b0etdc00  4   (empty)
 b0etdc00  5   IDPROM = 0715 009 MICHIGAN TDC LVDS Rev D    DSP =   V 036
 b0etdc00  6   (empty)
 b0etdc00  7   (empty)
 b0etdc00  8   (empty)
 b0etdc00  9   (empty)
 b0etdc00 10   (empty)
 b0etdc00 11   (empty)
 b0etdc00 12   (empty)
 b0etdc00 13   (empty)
 b0etdc00 14   (empty)
 b0etdc00 15   (empty)
 b0etdc00 16   (empty)
 b0etdc00 17   (empty)
 b0etdc00 18   (empty)
 b0etdc00 19   (empty)
 b0etdc00 20   (empty)
 b0etdc00 21   (empty)
===============================================================</pre>



<!-- Date: Sun Apr 20 16:41:46 2003 -->
<pre>EM_TIMING_00 now included as default in the following run conditions: 
 
<li>AAA_MINBIAS  
<li>AAA_NOSILICON  
<li>AAA_CURRENT  
 
Aces no longer need to add this crate by hand.</pre>
<!-- Author: Sungwon -->


<!-- Date: Mon Apr 21 09:26:04 2003 -->
<pre>There're no EMTiming Crate in default run configuration last night (since Run 161786). I talked with Andy to know about current status. At the moment there're some problems in L2/L3.. Therefore shift crews have decided to go back to previouse run configuration last night. That's why there's no emtiming crate in the run configuration and whay there's no EMTiming output in the monitoring page. Andy said that they will go back to the default run configuration as soon as they find some clue of the current problem. We hope we can see any outputs from emtiming crate from next store.</pre>
<!-- Author: Sungwon -->


<!-- Date: Mon Apr 21 10:12:58 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-1&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-2  width='300' align='top'></td><td>EMTDC crate with EMTDC and 220 ft cable</a></td></tr></table>
<!-- Author: Sungwon -->


<!-- Date: Mon Apr 21 10:27:29 2003 -->
<pre>    Just thought I'd send around a cute test I was able to do with the LED data. 
 
    I was realizing that the time of arrival at the TDC is energy dependent, so this means that using different voltages for the PMT's we can simulate a few different energies. Thus. we can tell the difference between two tubes being hooked up or just one. Might be able to check for swaps. 
 
    Here's what I saw: 
 
There are four configurations:  
1) Both tubes on full. (11) 
2) Left on full, Right on Standby (10) 
3) Left on Standby, Right on full (01) 
4) Left on Standby, Right on Standby (00) 
 
Here are the times for wedge 0 (Left side only implemented) 
 
11 -> 842.2 
10 -> 842.4 
01 -> 861.0 
00 -> 860.7 
    sharp change in time when the one implemented side changes input. 
 
Here are the times for Wedge 23 (both implemented) 
 
11 -> 844.6 
10 -> 849.6 
01 -> 846.3 
00 -> 859.8 
    small change in time when we reduce a little voltage on one side or the other, big change in time when we reduce both. 
 
    I think this is a useful tool. Can we get similar data for the PEM?  
</pre>
<!-- Author: David Toback -->


<!-- Date: Mon Apr 21 15:41:59 2003 -->
<pre>EMTiming is included in the run configuration now. Please take a look at the latest ObjectMon plots (run 161817) on the monitoring page.</pre>
<!-- Author: Sungwon -->


<!-- Date: Tue Apr 22 14:39:59 2003 -->
<pre>910 splitters (un-attached splitter pieces) and shrink wraps (and ties) are just shipped to the Lab6 (Thanks, Dervin). We will built 91 CEM harnesses. For your info, we already built 6 CEM harnesses and we installed one of them in downstairs at Feb 04, 2003.  
 
Bottom line: Total of 970 splitters.  960 splitters for the system (96 harnesses, 32 of each "type"), plus 1 spare harness of the longest type.</pre>
<!-- Author: Sungwon -->


<!-- Date: Tue Apr 22 15:13:06 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-3&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-4  width='300' align='top'></td><td>910 splitters (un-attached splitter pieces) and shrink wraps (and ties) are just shipped to the Lab6.</a></td></tr></table>
<!-- Author: Sungwon -->
<!-- Comment: Wed Apr 23 09;23;07 comment by...Sungwon -->
<pre>Another good news: All PEM harnesses are built now. Dervin and I will store all PEM harnesses in somewhere at B0.  Congrat!! everybody~</pre>
<!-- Date: Tue Apr 22 15:19:05 2003 -->
<pre>Plug laser runs: 
----- 
  Slot:  5  Id:  0715 009 MICHIGAN TDC LVDS Rev D 
run#161859 -- plug hv on stndby 
run#161862 -- plug hv ramping up 
run#161866 -- plug hv on 
----- 
  Slot:  5  Id:  0522 009 MICHIGAN TDC LVDS Rev D 
run#161868 -- plug hv on 
----- 
results http://txpc6.fnal.gov/~slava77/emTiming/YMon/dump 
and http://txpc6.fnal.gov/~slava77/emTiming/YMon/root 
raw data files are available in look area on fcdfsgi2 and in 
 /data07/slava77/emtd</pre>
<!-- Author: slava77 -->


<!-- Date: Tue Apr 22 18:10:46 2003 -->
<pre>--------- 
  Slot:  5  Id:  0522 009 MICHIGAN TDC LVDS Rev D 
run#161880 -- test/reference run 
run#161882 -- reseat MDR68 connector 
--------- 
  Slot:  5  Id:  0715 009 MICHIGAN TDC LVDS Rev D 
run#161885 -- after swapping back the TDC 
--------- 
The data should appear in the same place as in the elog entry above.</pre>
<!-- Author: slava77 -->
<!-- Comment: Tue Apr 22 18;20;18 comment by...slava77 -->
<pre>Forget these, the laser was not ON.</pre>


<!-- Date: Tue Apr 22 18:35:26 2003 -->
<pre>Plug laser runs: 
---------  
  Slot:  5  Id:  0522 009 MICHIGAN TDC LVDS Rev D  
run#161886 -- a test for (bad) connection effects 
--------- 
  Slot:  5  Id:  0715 009 MICHIGAN TDC LVDS Rev D  
run#161888 -- get the 715 back in 
--------- 
The data should appear in the areas mentioned in the entry above.</pre>
<!-- Author: slava77 -->



<!-- Date: Thu Apr 24 11:19:48 2003 -->
<pre>We have replaced EMTiming ASD and Transition board with new one; NW Plug crate.</pre>
<!-- Author: Sungwon and Slava -->
<!-- Comment: Thu Apr 24 15;06;55 comment by...Sungwon and Slava -->
<pre>Ws pulled the EMTiming ASD board out from NW-Plug crate, fixed the board, and put it back again.</pre>


<!-- Date: Thu Apr 24 15:35:08 2003 -->
<pre>Run#161989, see http://txpc6.fnal.gov/~slava77/emTiming/YMon 
is right after swapping the TB and the ASD and swapping chanID  
71<-->64, 81<-->87 
Results: chanID67 looks like having a reflection problem  
(TB--PMT)-- increase the deadtime of the ASD to avoid triggering 
 on the reflection. 
Added 5pF to channelID 67 to the ASD (width is ~96ns on ASD  
output). 
ChanID71 looks fixed 
ChanID 87 (actually  81, due to the swap not yet loaded into the 
 TDC) looks worse -- swapped it back. 
Waiting for the plug HV control to come back up (experts working)  
to check the current status.</pre>
<!-- Author: slava77 -->


<!-- Date: Tue Apr 29 16:02:33 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-5&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-6' ></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-7&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-8' ></a></center>
<!-- Author: Sungwon -->
<!-- Comment: Tue Apr 29 16;03;39 comment by...Sungwon -->
<pre>48 PEM Cable Harnesses at B0</pre>


<!-- Date: Wed Apr 30 11:47:27 2003 -->
<pre>We got the cables (original 220ft, 3644B/50, 3600B/68 cables) from Steve Chappa yesterday. IN the morning I sent the cable to KSM Electronics Inc. It will take a couple of days to deliver to KSM.</pre>
<!-- Author: Sungwon -->
<!-- Comment: Wed Apr 30 11;48;35 comment by...Sungwon -->
The cable what I sent is .. "<b>3644B/50</b>" 


<!-- Date: Tue May 27 17:53:45 2003 -->
<pre><h4>EM timing access summary </h4> 
Removed an extra capacitor off a chanel on EM timing ASD board 
<br> 
Looked at the PEM (dynode, EM timing) harnesses from the side of PMT box with a TDR (just a pulser and a scope and a piece of mind for interpreting the reflection picture): 
<br> 
some  bad channels look like short on the AMP connector side: plan to look inside the AMP connector assembley later. 
<br> other bad channels look like having problems on the far end (the transition board): will check these m/be tomorrow when we get an access to the back of EPNW rack (middle crate) 
<br> fixed 6 bent pins on the AMP connectors on the (EM timing) harness side (female).</pre>
<!-- Author: slava77 -->


<!-- Date: Wed May 28 19:24:41 2003 -->
<h4>Harness channels checkout summary</h4> 
<br> all channel numbers are as numbered on the harness 
<br> checkout done visually and with a hand-made TDR 
<h5>W22:</h5> 
0-10 OK; 
<br> 11 bent pin on AMP (fixed); 
<br> 12 bad terminator on the LIMO side (swapped with a good one); <br>13-15 OK 
<h5>W23:</h5> 
0 OK; 
<br> 1 possibly short on AMP + no connection on LIMO (the LIMO eventually fell off the RG cable end); 
<br> 2,3 OK 
<br> 4 bent pin on AMP (fixed); 
<br> 5,6 OK 
<br> 7 looks fine on LIMO side, from the AMP side looks like open/high impedance (possibly a bad LIMO-LIMO connection: moved to another connector) 
<br>8 OK 
<br>9 short on the LIMO side, also had a bent pin (the pin was fixed/unbent) 
<br>10-14 OK 
<br>15 bent pin on AMP, fixed; 
<h5>W0:</h5> 
0-5 OK 
<br>6 short on AMP 
<br>7-9 OK 
<br>10 bent pin on AMP (fixed) 
<br> 11 short on AMP 
<br>12-15 OK 
<br>In total: unbent 6 bent pins, localized 4 problems, W23#7 is still a mistery (if that was a connection problem, that could've fixed itself by reseating)  
<!-- Author: slava & max -->


<!-- Date: Wed May 28 19:36:12 2003 -->
<h4>Channel swap summary</h4> 
<h5>W0:</h5> 
swapped pairs of channels, now it is 0,4,1,5,2,6,3,7 
<h5>W23:</h5> 
swapped pairs 3 and 4. 
<br>the channel map is quoted below
<!-- Author: slava & max -->
<!-- Comment: Wed May 28 19;38;03 comment by...slava & max -->
<pre>Online channels only

CHANNELID=48 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=24;
CHANNELID=49 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=25;
CHANNELID=50 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=26;
CHANNELID=51 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=27;
CHANNELID=52 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=28;
CHANNELID=53 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=29;

CHANNELID=73 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=30;
CHANNELID=89 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=31;


CHANNELID=71 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=32;
CHANNELID=65 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=33;
CHANNELID=66 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=34;
CHANNELID=68 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=35;
CHANNELID=67 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=36;
CHANNELID=69 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=37;
CHANNELID=70 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=38;
CHANNELID=64 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=39;

CHANNELID=80 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=40;
CHANNELID=84 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=41;
CHANNELID=81 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=42;
CHANNELID=85 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=43;
CHANNELID=82 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=44;
CHANNELID=86 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=45;
CHANNELID=83 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=46;
CHANNELID=87 CARD_CARDNAME='TDC_EM_02' SUBADDRESS=47;

</pre>


<!-- Date: Fri May 30 02:47:14 2003 -->
<h4>Looking at plug laser run#163721, normal mode</h4> 
CEM channels look empty (that's good) 
In most cases the channels below give a single fire, the multiples are mentioned below. 
<h5>W22</h5> 
all channs whide enough, no doublefires, no dead channels, always 1 hit 
<h5>W23</h5> 
eta=-10: 2 hits t1-t2=14ns, w2=12ns, w1~50ns (first short then long pulse, in time order) 
<br> 
eta=-11: 2hits t1-t2=54ns, w2=50ns, w1=1.5ns (first long then short) 
<br> 
eta=-13: 2 hits t1-t2=5ns, w1~50ns, w2=4ns (short then long) 
<h5>W0</h5> 
eta=-17: 2hit events t1-t2=6, w1=53, w2=2 (short then long) 
<br>3 hitters (ibid) t1=724, t2=670, t3=663, w1=1ns, w2=52ns, w3=2ns (short-long-short) 
<br><br> 
As a summary: all the multiple hits seem to be coming from the TDC/longCable features.
<!-- Author: slava & max -->


<!-- Date: Thu Jun 19 17:41:59 2003 -->
<pre>Hi, 
 
    I've been poking around in the data for Run 164761. I noticed that wedge 
22, eta=-10 had the worst corrected RMS. When I looked at the data I found 
the following (see enclosed picture). 
 
    From the top two figures it looks like the odd PMT connection is either 
flaky or just has a very different voltage vs. energy curve. Clearly it's 
good enough to make the ASD fire and be fully efficient at a reasonable 
value, but from the lower plot you can see that there appear to be two 
curves in the time vs. energy arrival and makes the energy corrections not 
work. 
 
    Could someone check into this PMT and see if there are any known 
problems? If not, then we should check it out when we're down there next. I 
looked at an older run and I see it has the same problem in 162238. 
 
                        Thoughts? 
 
                                    Dave 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Jun 19 17:43:19 2003 -->
<table><tr><td><a href=/elog/notebooks/emtiming/Thu_Jun_19_2003_174309.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-10  align='top'></td><td>Figure to the above e-mail message from Dave</a></td></tr></table>
<!-- Author: Peter -->


<!-- Date: Thu Jun 19 17:44:08 2003 -->
<pre>Hi all, 
 
    I finished an updated study of the correction factors for the PEM.  What 
I did was find the correction factor which gives the best RMS, then compared 
that with the old correction factor of 13.0. The data is given below, but 
I'll summarize:  For all channels which appear to have good connections 
(wedge 22, eta=-10 is a problem I discussed earlier) the bestfit RMS is less 
than 2.5. I also noticed that a correction factor of 13.0 is within 2% of 
the bestfit value for almost all the channels except for Wedge 22 which 
seems to be very different than the others (again eta=-10 is as I discussed 
in a previous email), and wedge 0, eta=-10. For 13.0 none appear to have 
values greater than 2.6 except the broken channel. 
 
So: If we need a single correction factor for all channels I'd say that 13.0 
is just fine.  If we have a correction factor for each wedge I'd go with 
22=> 15, 23=>13 and 0=>13.  If we can do it channel by channel, then I'd use 
the individual best fit values given below (good to 0.25). 
 
In anycase, I think we should make RMS>3.0 or 3.5 a failure mode check. 
 
    Thoughts? 
 
 
 Wedge            eta                 CorrFac         RMS 
OldCorrFac  OldRMS      %Diff 
 
  22.00000     -10.00000      15.00000      3.858691      13.00000 
3.889687     0.7968848 
  22.00000     -11.00000      19.50000      2.294866      13.00000 
2.802807      18.12259 
  22.00000     -12.00000      18.00000      1.848300      13.00000 
2.226089      16.97101 
  22.00000     -13.00000      17.00000      1.797159      13.00000 
2.043259      12.04450 
  22.00000     -14.00000      15.00000      1.725974      13.00000 
1.786438      3.384646 
  22.00000     -15.00000      12.50000      2.119852      13.00000 
2.124359     0.2121724 
  22.00000     -16.00000      11.00000      0.000000      13.00000 
0.000000           nan 
  22.00000     -17.00000      11.00000      0.000000      13.00000 
0.000000           nan 
  23.00000     -10.00000      12.50000      1.933779      13.00000 
1.935911     0.1101382 
  23.00000     -11.00000      12.25000      2.396048      13.00000 
2.427797      1.307729 
  23.00000     -12.00000      13.00000      2.140548      13.00000 
2.140548      0.000000 
  23.00000     -13.00000      13.50000      2.220994      13.00000 
2.223819     0.1270240 
  23.00000     -14.00000      13.50000      2.176343      13.00000 
2.178529     0.1003019 
  23.00000     -15.00000      12.00000      2.043659      13.00000 
2.053662     0.4870739 
  23.00000     -16.00000      11.50000      2.192088      13.00000 
2.210979     0.8544008 
  23.00000     -17.00000      12.50000      2.062094      13.00000 
2.063875     0.8631643E-01 
  24.00000     -10.00000      11.75000      2.453360      13.00000 
2.545538      3.621163 
  24.00000     -11.00000      15.25000      2.286284      13.00000 
2.326179      1.715047 
  24.00000     -12.00000      12.00000      2.174535      13.00000 
2.186907     0.5657204 
  24.00000     -13.00000      13.25000      2.259575      13.00000 
2.259935     0.1594075E-01 
  24.00000     -14.00000      12.25000      2.187619      13.00000 
2.192893     0.2405177 
  24.00000     -15.00000      12.25000      2.021174      13.00000 
2.027654     0.3195801 
  24.00000     -16.00000      12.25000      1.863680      13.00000 
1.868073     0.2351930 
  24.00000     -17.00000      12.75000      2.481081      13.00000 
2.481277     0.7888746E-02 
 
                                    Dave</pre>
<!-- Author: Peter -->


<!-- Date: Sun Jun 22 09:11:02 2003 -->
<h3>EM Timing types</h3> 
Your <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=consumer-ops&action=view&page=11&frame=2&anchor=14:09:41'> 
EMTDC Timing plot</a> has gone south.  <B>Fix it</b> 
<!-- Author: CDF SciCo -->


<!-- Date: Wed Jul 9 16:11:57 2003 -->
<pre>Testing of the splitter cables: 
tested: 4 bunches 
bad: 3 cables in 2 bunches 
</pre>
<!-- Author: Peter -->


<!-- Date: Fri Jul 11 21:10:13 2003 -->
<pre>Test of splitter harnesses: 
Wed07E: non-splitter end 7left flaky 
Wed19E: connection on-splitter 0left flaky 
Wed13E: splitter on 9right no cover 
	non-splitter end 1left weak signal 
	non-splitter end 7right flaky 
Wed 04W: non-splitter end 9right no signal 
Wed 01W: non-splitter end 4left no signal 
Wed 10E: OK 
Wed 13W: OK</pre>
<!-- Author: Peter -->


<!-- Date: Mon Jul 14 17:20:01 2003 -->
<pre>Test of splitter harnesses II: 
Wed16W: 2right on-splitter no signal/flaky 
	7left non-splitter end flaky 
	9left	"                " 
	6left   "              slightly flaky 
Wed22W: 3right on splitter 
	4right non-splitter side no signal 
	4left    "               flaky, reflections 
	7left    "               flaky 
Wed19W: 6left no splitter protection 
	6right   " 
Wed07W: 7right non-splitter side no signal 
	3left  "                    " 
Wed10W: OK 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Jul 17 13:49:28 2003 -->
<pre>Testing of harnesses: 
Wed04E: OK 
Wed22E: OK</pre>
<!-- Author: Peter -->


<!-- Date: Thu Jul 17 15:50:14 2003 -->
<pre>Test of harnesses: 
Wed06W: OK 
Wed18W: OK 
Wed23W: OK 
Wed12W: OK 
Wed00W: 5right non-splitter side (flaky) 
Wed17W: 0left on the splitter (weak, flaky signal) 
Wed05W: 3left non-splitter side (no signal) 
	7right       "            (weak signal) 
Wed11W: 7left on splitter (no cover)</pre>
<!-- Author: Peter -->


<!-- Date: Thu Jul 17 17:53:28 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-11&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-11  width='300' align='top'></td><td>Test of harnesses: Here a screen image from the scope in an "OK" case</a></td></tr></table>
<!-- Author: Peter -->


<!-- Date: Tue Jul 22 02:47:17 2003 -->
<pre>Testing of splitter-harnesses: (the following were already checked in Jul 9th) 
Wed16E: 3right non-splitter end (flaky) 
	5right non-splitter end (flaky) 
Wed01E: 1right non-splitter end (flaky) 
 
 
All east and west harnesses repaired and retested, all OK, except these which still have problems: 
Wed07W: 7right no signal 
Wed 13E: 1left no signal 
Wed22W: 3right (no signal) 
	4right (no signal)</pre>
<!-- Author: Peter -->


<!-- Date: Fri Jul 25 01:56:14 2003 -->
<pre>Testing of splitter harnesses: 
Wed06E: 6left on splitter flaky 
Wed23E: 3left non-splitter side no signal 
	6right on splitter flaky 
Wed17E: 1right on splitter flaky 
Wed17W: OK 
Wed05W: OK 
Wed11W: OK 
Wed05E: OK 
Wed12E: OK 
Wed18E: OK 
Wed00E: OK 
Wed11E: OK 
 
already repaired harnesses with problems: 
Wed00W: 5right non-splitter side flaky 
Wed22W: same problems as before</pre>
<!-- Author: Peter -->


<!-- Date: Tue Jul 29 00:24:48 2003 -->
<pre>Test of splitter harnesses: 
Wed09W: 6right non-splitter side flaky 
Wed03: 8right on splitter flaky 
Wed02W: OK 
Wed08W: OK 
Wed21W: OK 
Wed20W: OK 
Wed14W: OK 
Wed15W: OK 
Wed14W: 7right non-splitter side no signal 
Wed09E: OK 
Wed20E: OK</pre>
<!-- Author: Peter -->


<!-- Date: Wed Jul 30 14:04:58 2003 -->
<pre>Error in last entry: 
 
Wed14W: 7right no signal    --> correct Wed14_E_: 7right ... 
 
 
testing of harnesses: 
Wed2E: OK 
Wed8E: OK 
Wed15E:OK 
Wed21E: OK 
Wed3E: OK 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Jul 30 14:36:30 2003 -->
<pre>Correction to last entry: 
 
Wed21E: 6right non-spliter side no signal 
Wed03E: 1right non-splitter side no signal (exchange cable!) 
	6right splitter side exchange cable!</pre>
<!-- Author: Peter -->


<!-- Date: Fri Aug 1 17:13:34 2003 -->
<pre>PEM-harness testing is done. There are about 10 harnesses with errors, which are returned to Dervin to be repaired.</pre>
<!-- Author: Peter -->


<!-- Date: Fri Aug 8 18:08:30 2003 -->
<pre>Status on PEM-harnesses: 
39 harnesses are done 
7      "     to be repaired on the test stand 
3      "     on the detector 
1 test harness 
</pre>
<!-- Author: Peter -->


<!-- Date: Mon Aug 11 12:46:19 2003 -->
<pre>CEM harness tests finished.</pre>
<!-- Author: Peter -->


<!-- Date: Wed Sep 17 17:44:08 2003 -->
<pre>We start to install the 220ft long cables for the EMTiming system. 
Below is what we did today: 
Plug: NW and SW,  
Central: SW(top) and SW(bottom) 
 </pre>
<!-- Author: Sungwon Lee -->


<!-- Date: Thu Sep 18 18:32:32 2003 -->
<pre>Post-installation cable integrity check with a pulse reflection: 
 
It looks like there's no broken wires. The variation of the  
reflected pulse height for wires in the cable is around 4-12 mV  
or 4-11 % (see table below). Somehow channels 1-12 usually show  
smaller variation than channels 13-24. Equitpemt systematics?  
Slava says that variation in time of arrival of the reflection  
pulse about 4-6 ns for wires in the cable is acceptable. There is  
only one 'anomal' cable EPSWM:Spare, which has time ~100 ns more  
and peak height down by ~50%. This is because the cable had some  
repairs. 
 
 
1 UNIT = 4 mV 
l = channels 1-12 
r = channels 13-24 
 
CANWT: 
T11:4_0  r:2   l:2 
T14:4_1  r:2.5 l:<1.5 
B11:4_2  r:<2  l:2 
spare    r:2.5 l:1 
 
CASWT: 
T11:4_3  r:1.5 l:1 
T14:5_0  r:1.5 l:1 
B11:5_1  r:2   l:1.5 
spare    r:2   l:<2 
 
CASWB: 
T11:5_2  r:1.5 l:2 
T14:5_3  r:2.5 l:1.5 
B11:6_0  r:2   l:1.5 
spare    r:2.5 l:<2 
 
CANWB: 
T11:6_1  r:2.5 l:2 
T14:6_2  r:1.5 l:2.5 
B11:6_3  r:2.5 l:1.5 
spare    r:2.5 l:1.5 
 
CANET: 
T11:7_0  r:2   l:2. 
T14:7_1  r:1.5 l:1.5 
B11:7_2  r:2   l:1.5 
spare    r:2   l:2 
 
CASET: 
T11:7_3  r:2   l:1.5 
T14:8_0  r:2.5 l:2.5 
B11:8_1  r:2   l:1 
spare    r:2.5 l:2 
 
CASEB: 
T11:8_2  r:2.5 l:2 
T14:8_3  r:2   l:1 
B11:9_0  r:2.5 l:1.5 
spare    r:2   l:1 
 
CANEB: 
T11:9_1  r:2   l:1.5 
T14:9_2  r:2.5 l:<2 
B11:9_3  r:2   l:1.5 
spare    r:2.5 l:<2 
 
 
EPSWM: 
4:10_0  r:2.5 l:2 
5:10_1  r:2   l:1 
6:10_2  r:2   l:1.5 
7:10_3  r:3   l:2.5 
spare  non-standard: gives time ~100 ns more, peak is down by ~50% 
 
EPNWM: 
4:11_0  r:2  l:1.5 
5:11_1  r:<2 l:1.5 
6:11_2  r:2  l:1.5 
7:11_3  r:3  l:2.5 
spare   r:2  l:1.5 
 
EPSEM: 
4:12_0  r:2.5 l:2 
5:12_1  r:2.5 l:2 
6:12_2  r:2   l:<2 
7:12_3  r:2.5 l:2 
spare   r:2.5 l:2 
 
EPNEM: 
4:13_0  r:2   l:1.5 
5:13_1  r:2   l:2 
6:13_2  r:2.5 l:1 
7:13_3  r:2   l:2 
spare   r:2.5 l:1 
</pre>
<!-- Author: Vadim -->


<!-- Date: Wed Sep 24 02:29:42 2003 -->
<pre>Decided to programm the tdcs in etdc00  
config in b0etdc00.crate.new 
 
Module IDs are (slots 4 through 13) 
0,8,16,32,40,48,71,83,103,115 as in the note 
 
The channels are mixed (as decided) 
... see the full dump of channelIDs as read out by VME from the TDC FRAM and the vme bus scan at 
http://txpc6.fnal.gov/~slava77/emTiming/tdcs.09242003 
 
b0etdc00 VmeBusScan 
  PartitionId:        3 
  IpAddress:          131.225.237.41 
  Ethernet:           08:00:3e:29:0c:29 
  SystemNumber:       S07924|3410533|549606 
  Slot:  2  Id:  0083 001 TRACER__V2.1A 
  Slot:  4  Id:  0579 009 MICHIGAN TDC LVDS Rev D   V 040 
  Slot:  5  Id:  0715 009 MICHIGAN TDC LVDS Rev D   V 037 
  Slot:  6  Id:  0341 009 MICHIGAN TDC LVDS Rev D   V 037 
  Slot:  7  Id:  0213 009 MICHIGAN TDC LVDS Rev D   V 037 
  Slot:  8  Id:  0503 009 MICHIGAN TDC LVDS Rev D   V 040 
  Slot:  9  Id:  0329 009 MICHIGAN TDC LVDS Rev D   V 040 
  Slot: 10  Id:  0163 009 MICHIGAN TDC LVDS Rev D   V 040 
  Slot: 11  Id:  0693 009 MICHIGAN TDC LVDS Rev D   V 040 
  Slot: 12  Id:  0522 009 MICHIGAN TDC LVDS Rev D   V 036 
  Slot: 13  Id:  0741 009 MICHIGAN TDC LVDS Rev D   V 040 
 
</pre>
<!-- Author: slava77 -->


<!-- Date: Sat Sep 27 18:27:37 2003 -->
<pre>Sep. 19: 
    - Long Cables: The installation of the long cables has been  
      finished. (counting room and detector hall; CEM and PEM  
      Cables)  
    - 10 TDCs in the EMTiming crate are installed and  
      connected to the long cables 3 plug harnesses are plugged  
      into the TB-ASD in plug.  
    - We also have fixed existing problems  
      with AMP and Lemo connectors for plug harnesses. 
Sep. 22: 
    - Transition Boards for PEM: The 16 TBs from Frascati arrived 
      in good condition 
Sep. 23: 
    - TBs are brought to Bob DeMaat to attach the front  
      panel.Serial number and a tracking barcode will be affixed  
      to each front panel. 
    - PMT->TB Harnesses for PEM: Installation finished 
    - We worked on the east plug in the afternoon hooking up the  
      harnesses to the Light Boxes. We found two bad lemos  
      (shorts) in the process. One connector has different  
      screws. We replaced the screws on our connector with an old 
      one, and it worked. 
Sep. 24:  
    - EMtiming TDCs were programmed. Looks fine. All TDCs are in  
      and enabled/online. All 17 TBs (including one spare) are  
      picked up at Hi-Rise. 
Sep. 25: (Installation summary) 
    - Plug installation finished. 
    - Long cables are installed for CEM and PEM, all checked, no  
      problems. 
    - Plug harnesses are installed and hooked to the TBs 
      and Light Boxes, checked, no problems. 
    - We had problems with lemos, all fixed. 
    - No problems on the amp side: there are 2 
      shorted channels on the Light Box itself. 
    - All TBs are checked, no problems found. 
Sep. 26:  
    - We ask George (PREP) to put RC on the rest two TB boards. 
</pre>
<!-- Author: Peter & Sungwon -->


<!-- Date: Wed Oct 1 10:25:04 2003 -->
<pre>9/30: we got one TB (with RC) from PREP.</pre>
<!-- Author: Sungwon -->


<!-- Date: Wed Oct 1 10:26:47 2003 -->
<b><a href="http://txpc1.fnal.gov/emtiming/photos_installation/">EMTiming Installation Photo Gallery</a></b>
<!-- Author: Peter and Sungwon -->


<!-- Date: Wed Oct 1 10:31:03 2003 -->
First 25 ASD boards are left to Fermilab. (October 01, Italy time)<br> 
<a href="http://www.dhl-usa.com/cgi-bin/tracking.pl?AWB=5325318062&LAN=ENG&TID=US_ENG&FIRST_DB=US">DHL Air Waybill 532 5318 062</a>
<!-- Author: Sungwon -->


<!-- Date: Fri Oct 3 09:57:18 2003 -->
<pre>we got the 2nd TB (with RC) from PREP. (All done now!!)</pre>
<!-- Author: Sungwon -->


<!-- Date: Fri Oct 17 02:13:03 2003 -->
<pre>Plug laser run with HV ramping:  
(all the files are physically in /data07/slava77/emtd directory)  
Run # 171311:  
raw data: http://txpc6.fnal.gov/~slava77/emTiming/emtd/raw/ir026544.0001test  
dat file (dave-style formatted): http://txpc6.fnal.gov/~slava77/emTiming/emtd/dat/171311.dat  
root file from the dat file: http://txpc6.fnal.gov/~slava77/emTiming/emtd/root/171311.root  
 
ObjectMon results: 3 GeV threshold for 100%: http://txpc6.fnal.gov/~slava77/emTiming/emtd/root/ObjectMon171311aa.root 
 
corresponding ps file: http://txpc6.fnal.gov/~slava77/emTiming/emtd/ps/time_171311-aa.ps  
 
4GeV threshold and 565 ADC open gate time for 100% efficiency plots:  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/root/ObjectMon171311ac.root  
ps:  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/ps/time_171311-ac.ps  
 
3GeV threshold and 565 ADC open gate time for 100% efficiency plots:  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/root/ObjectMon171311ad.root  
ps:  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/ps/time_171311-ad.ps  
Actually, this is something to show to the public (actually something's goofy here, as E13:10 seems to have a low efficiency 
if just looking on the hits vs energy, but it's 100 here in ObjectMon).  
   
 
Times and widths vs energy:  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/ps/171311-t1w1-vs-ene.ps  
 
Nhits vs energy (thresholds):  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/ps/171311-thresh-eff.ps  
 
More than 1 hitters:  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/ps/171311-t-w-doublehits.ps  
   
 
==========  
Summary:  
Dead: W7:11  (the rest got fixed)  
Double hitters due to TB/reflection: E13:10 (also has a fairly low efficiency, bad connection?)and W21:11.  
Double hitters due to TDC: ~16 of them (all over the place)  
 
To do:  
1)fix W7:11 (check if the second channel in the pair is good): West PMT box 5, EPNW-2 Slot4 cables 2,3 or TB channel 
pair 5 (cable 3 is the one with the short inside PMT box).  
 
2)Swap TBs in EPSE-2 Slot6 (E13:10) and EPNW-2 Slot4 and fix the corresponding channels (pair 01 in EPSE-2 Slot6 TB 
and pair 21 in EPNW-2 Slot4 TB).  
 
3) match the thresholds on the ASDs with the threshold on the old prototype ASD for proper use on CEM, possibly swap 
wiht the currently installed PEM boards.  
 
4) have the TB serial number to rack/slot map done.  
 
5) figure out why ObjectMon reports 100% efficiencies with 3GeV for some channels that don't have hits at above 3GeV and 
visually have ~4GeV thresholds: W0:11,15,16,17, E13:10  
 
===========  
I guess we can show  
http://txpc6.fnal.gov/~slava77/emTiming/emtd/ps/time_171311-ad.ps  
 
to show that we have the PEM working.  
   
 
        --slava  
 
"Excellent!" (M.Burns) </pre>
<!-- Author: slava77 -->


<!-- Date: Thu Oct 23 23:45:32 2003 -->
<pre>a summary of today's access: 
 
Purpose: try to identify and fix the single channel failures in PEM EM timing. 
 
Method: take the "thresholds" map from the recent Plug laser run with HV ramping and select 
the channels with threshold >~2GeV (The average threshold is ~1.5GeV) and check both lines from the  
PMT box side (easily accessible). 
 
Results: 
Selected 15 channels (3 had no apparent problems and thresholds ~1.7, attributed this to some possible  
threshold estimate fluctuation: 10-15% from average is OK) 
 
Ind  E/Wwedge:tower (plug_rack Slot:ASDchannel [wire/PMTOption1,wirePMTOption2] -- diagnosis  
--> treatment suggested/applied 
 
1 - E0:11 (NE5:20 [2,3]) -- OK (thresh ~1.7) 
2 - E5:12(NE7:9 [4,5]) -- #5 LEMO short -->fix tomorrow 
3 - E7:10(SE4:0 [0,1]) -- ASD threshold high (appeared after ASD swap yesterday) --> ASD swapped 
4- E10:14(SE5:2[8,9]) -- #8 LEMO short --> fix tomorrow 
5 - E10:10(SE5:0 [0,1]) -- #0 AMP male not connected (PMT box) --> bug Mike L. 
6 - E13:17(SE6:7[14,15]) -- #14 LEMO short -->fix tomorrow 
7 - E14:15(SE6:14[10,11]) -- #11 LEMO short --> fix tomorrow 
8 - E16:11(SE7:4[2,3]) -- #3 LEMO short -->fix tomorrow 
9 - E17:15(SE7:14[10,11]) -- OK (thresh ~1.8) #11 AMP male(PMT) a bit flaky (iffy) --> m/be bug  
Mike L. 
10- E20:17(NE4:15[14,15]) -- OK (thresh ~1.7) 
11 - E21:17(NE4:23[14,15]) -- OK (thresh ~1.7) 
12 - W6:13(NW7:21[6,7]) -- no apparent problem, thresholds are good as checked with  
pulser/attenuator; threshold was better before ASD swap --> swapped ASD, suspected a different PMT  
gain; would check as a function of ADC counts. 
13 - W7:11(SW4:4[2,3]) -- #3 short on AMP male(PMT box) --> Mike L. 's been aware for ~2weeks 
14 - W11:17(SW5:15[14,15]) -- #15 AMP male(PMT box) pushed in by ~1/8" -->bug Mike L. 
15 - W16:10(SW7:0[0,1]) -- #1 LEMO short -->fixed 
 
Summary/to do: 
15 channels checked: 
3.5 (0.5 for #9 above) -- considered OK. 
3.5 (0.5 for #9 above) -- need to be fixed inside/on PMT box (Mike L. ) 
5+1 LEMO shorts -- (1 fixed) -- 4 LEMOs are in the same side, all are not easily identifiable (need to  
twist and shake to see a short) 
1 -- ASD high threshold was set -- ASD swapped 
1 -- mistery channel. 
 
Overall:  
1.56% of the channels had problems identified, of those: 
0.78% -- LEMO connectors shorts 
~0.5% -- not related with the present EM timing installation (problems on PMT boxes) 
0.13% -- ASD threshold set error (it's actually 1/384~0.26% by the number of ASD channels) 
0.13% -- misterious (suspect a PMT related feature). 
 
 
Also, need a better threshold scanning method: the current one is based on a fairly unstable PMT  
condition and a low number of events around thresholds. Need to learn how to rotate the filters on the  
plug lasers on the 1st floor. 
 
</pre>
<!-- Author: slava77 -->


<!-- Date: Sat Nov 29 20:29:23 2003 -->
<pre>Comments on dave.dat file from Run no.175008 (PEM only): 
 
- There are only two towers which seem to have significant 
 "fakes" (fire when no energy). These are wedge 14, towers 13 and 
 14, and they appear to be swapped with each other.  
 *** This requires action.  
 
- Wedge 8, tower 11, side1 appears to have a dead input to the 
 TB.  
 *** This requires action. 
 
- Only 2 towers have low width events and in all events there is 
 a adjacent tower firing. I'd say we've done the right thing with 
 this problem. 
 
- There are a number of other towers which appear to double fire, 
 and as far as I can these are two separate firings, and they all 
 occur in events where there are other towers which have one fire 
 and are late, i.e., this is beam splash or cosmics on top of a 
 real event. I don't see this as a problem. 
 
- I see three places in the ObjectMon plots where the efficiency 
 seems to be low  or there is no evidence of firing (<17,10>, 
 <7,-10> and <8,-11>) . As far as I can tell these are low 
 statistics towers, i.e., they have too  few events with E>3 GeV 
 to make a proper determination of the efficiency.  We should 
 keep our eyes on these towers. 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Dec 25 23:51:42 2003 -->
<pre>TDC Serial 0314 (from slot 6) gone bad: wouldn't even come up on the VME bus scan. Placed the 0314 in slot 16 (not plugged) close to another bad spare .. couldn't find a spare at all. Took the  #0715 from slot 5 (not isntrumented region) and placed that into slot 6. Slot 5 is now empty. 
It took me a while to reprogram the tdc (some file write permission problems)</pre>
<!-- Author: slava77 -->


<!-- Date: Mon Jan 12 16:54:30 2004 -->
Hi Eric: 
 
 
FYI:  
I've placed the following boards on your desk:  
the 2 bad LVDS boards (board serials 562684, 536084)  
and the 3 ECLs (supposedly good, accidentally taken en masse with other LVDS boards while originally populating the crate with TDC boards), serials 566358, 541662, 563215.  
 
5 LVDS boards were then taken from the test crate to replace the above and placed into b0etdc00 slots 16-20 (not plugged in):  
564167, 565874, 562671, 563982, 565811.  
 
So, now the em timing crate has 4 spares and 10 "worker" TDCs. 
<!-- Author: slava77 -->


<!-- Date: Mon Aug 16 01:11:43 2004 -->
<pre>Finished with a first phase of testing CEM-harnesses. 
Problems: 
Wedge 13E, 0left: first suspected that the TDC side LEMO is broken; after repairing problem persists; the test showed that the splitter is broken. 
Wedge 05W, 8right: LEMO on TDC side fixed 
Wedge 03W, 1right: first suspected that the TDC side LEMO is broken; after repairing problem persists; the test couldn't determine which side is broken -> maybe splitter broken(?) 
	   3right: LEMO on TDC side fixed 
	   4right: LEMO on TDC side fixed 
Wedge 09W, 3left: splitter broken (connection AdMEM - PMT is fine, only TDC side connection is affected) 
 
(Note: It takes 2 hours to fix 5 LEMOs, including testing.) 
 
</pre>
<!-- Author: Peter -->
<!-- Comment: Tue Aug 17 19;21;01 comment by...Peter -->
<pre>The following phrase created some confusion: "first phase of testing" means that 2 boxes of CEM harnesses out of 5-6 (didn't count them) boxes were tested. There is still a lot to do...
</pre>
<!-- Date: Mon Aug 16 14:28:27 2004 -->
<pre>Wedge 03W, 1right: LEMO on TB side fixed (it turned out not to be the splitter) 
 
</pre>
<!-- Author: Peter & Max -->


<!-- Date: Tue Aug 17 18:51:26 2004 -->
<pre>Wedge 13E, 0left: fixed (TB connection on the splitter soldered correctly) 
Wedge 09W, 3left: fixed (LEMO on PMT side was broken)</pre>
<!-- Author: Peter -->



<!-- Date: Tue Aug 24 22:52:33 2004 -->
<pre>CEM-Harness testing (2nd part): 
Wed 07E, 7right: TB side - fixed 
	 9right: TB side - fixed 
Wed 09E, 6left: TB side - fixed 
	 9left: TB side - fixed 
Wed 15W, 9right: on the splitter - need further investigation! 
Wed 06E, 7left: on the splitter - need further investigation! 
Wed 13E, 0left: on the splitter - need further investigation! 
	 5left: TB side - not yet fixed! 
Wed 18W, 5left: TB side - fixed 
Wed 17W, 0left: TB side - fixed 
	 5right: TB side - fixed 
Wed 19W, 7left: TB side - fixed 
	 8left: TB side - fixed 
	 6right: TB side - fixed 
Wed 22W, 6left: TB side - fixed 
Wed 21W, 4left: TB side - fixed 
 
To sum up: one TB side LEMO is not fixed, b/c we don't have enough LEMOs. Slava or I will look at the splitter problems tomorrow. 
So, if all above problems are fixed, the CEM harnesses should be ready for installation. 
 
</pre>
<!-- Author: Peter -->
<!-- Comment: Wed Aug 25 18;46;58 comment by...Peter & Max -->
<pre>Wed 13E, 0left: fixed by resoldering (the shield touched a point on the splitter that was connected to the core => short)
	 5left: could not be reproduced
Wed 06E, 7left: fixed - ordered core and shield and fixed with tape (the shield touched a point on the splitter that was connected to the core => short)
Wed 15W, 9right: fixed - after cutting off the plastic cover of the splitter the problem disappears; core and shield fixed tape (signal vanishes shortly when jiggling the PMT side)
</pre>


<!-- Date: Thu Sep 2 17:25:26 2004 -->
<pre>-----Original Message----- 
 From: David Toback [mailto:toback@TAMU.EDU] 
 Sent: Tuesday, August 31, 2004 5:30 PM 
 To: 'David Toback'; 'Rob Roser'; 'Camille Ginsburg'; 'Pat         
      Lukens'; 'Steve Kuhlmann' 
 Cc: 'Marco Cordelli'; 'Maxim Goncharov'; 'Bob DeMaat'; 'Peter  
      Wilson'; 'Henry Frisch'; 'Mike Lindgren'; 'Willis  
      akumoto'; Dervin Allen 
 Subject: Weekly status report for 8/30/04 
  
> Hi all, 
>  
> A detailed weekly status report for 8/30/04 can be found at 
> http://hepr8.physics.tamu.edu/hep/emtiming/management/weekly_2004_update.html 
>  
> 	Very quick status summary: 
>  
> The first 4 ASDs and TB pairs are tested and ready to go. They  
> can be found on Rob's desk. The harnesses, which have been  
> retested, are in the 2nd floor test stand and are also ready to  
> be installed. I believe there are no roadblocks to installing  
> as soon as possible on our end. 
>  
> 	Longer quick summary: 
>  
> - The ASD's and TB's have been mechanically and electrically  
> tested and 
> found to be sound by PJW, MG etc. 
>  
> - All TB PCB are in hand and the bulkhead boards from the old  
> TB's have been removed. The first 4 have been stuffed and  
> tested. 
>  
> - All the parts for the remaining ASD's and TB's are in hand  
> except the front panels (which are on site, but not yet in  
> Bob's hand), and are being stuffed. This should easily outpace  
> installation. Expected to be completed by the 14th. 
>  
> - Long cable production has started. Expected ~Nov 1st. 
>  
> 	We see are ready to install and see no roadblocks to  
>    having a full complement of boards available for each wedge  
>    as it is ready for installation. We hope installation can  
>    start as soon as possible. Please let me know if I can help >    in any way. 
>  
> 			Questions and comments are welcome, 
>  
>                                      Dave 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Fri Sep 3 10:26:30 2004 -->
<pre>-----Original Message----- 
> From: demaat@fnal.gov [mailto:demaat@fnal.gov] 
> Sent: Friday, September 03, 2004 5:39 AM 
> To: David Toback 
> Cc: 'David Toback'; maxi@fnal.gov; 'Peter Wagner' 
> Subject: Re: Next round of ASD and TB boards 
>  
>  
> Hi Dave, 
>  
> We'll have at least 8 more available Friday morning 
> and probably another 4 on Friday afternoon. 
>  
> I'l coordinate with Max to get them to him. 
>  
> Bob 
> ----- Original Message ----- 
> From: David Toback <toback@tamu.edu> 
> Date: Thursday, September 2, 2004 5:25 pm 
> Subject: Next round of ASD and TB boards 
>  
 
> > Hi Bob, 
> > 
> > 	What's the good word on the next round of ASD and TB boards to 
 
> test? 
 
> > We have some time before the installation starts on Tuesday and it 
> > would be 
> > good if we could get as many tested by us as possible before then. 
> > 
> > 	                        Thanks and keep in touch, 
> > 
> >                                     Dave</pre>
<!-- Author: Peter -->


<!-- Date: Fri Sep 3 10:47:33 2004 -->
<pre>-----Original Message----- 
> From: Bob DeMaat [mailto:demaat@fnal.gov] 
> Sent: Friday, September 03, 2004 10:38 AM 
> To: maxi@fnal.gov 
> Cc: David Toback; 'Peter Wagner' 
> Subject: Re: Next round of ASD and TB boards 
>  
> Hi Max, 
>  
> I'm bringing 8 transition boards over to your office now. 
>  
> I am also bringing some screws with smaller heads that can 
> be used to replace the mounting screws for the front panels 
> on the 4 boards you already have. 
>  
> Bob 
>  
> ----- Original Message ----- 
> From: "David Toback" <toback@physics.tamu.edu> 
> To: <demaat@fnal.gov>; "'David Toback'" <toback@tamu.edu> 
> Cc: "'David Toback'" <toback@tamu.edu>; <maxi@fnal.gov>; "'Peter Wagner'" 
> <wagnp@fnal.gov> 
> Sent: Friday, September 03, 2004 7:17 AM 
> Subject: RE: Next round of ASD and TB boards 
>  
>  
> : Great!  Sounds like we can get them from you in the AM and I would guess 
> : finish them off just in time for the next round. That will put us way 
> ahead 
> : for installation!  Thanks again! 
> : 
> :                                             Dave 
> :</pre>
<!-- Author: Peter -->


<!-- Date: Sat Sep 4 14:00:45 2004 -->
<pre>TB testing: 
The board was connected to the ASD board for termination, the signal was generated with the pocket pulser. The following board numbers were tested by looking at reflections on the PMT side using the scope:  
37, 24 29, 32 and 4 unlabeled boards.  
 
One problem was found in board no. 32, channel 15(right). The board is marked, and put on top of the others. 
</pre>
<!-- Author: Peter -->


<!-- Date: Tue Sep 7 16:10:17 2004 -->
<br> 
<u>CEM harness installation:</u> (1st day) 
<br> 
All harnesses for the NWB crate have been installed (meaning: PMTs are connected, cables are dressed and LEMOs plugged into the crate); except the PMTs of the right side of 18W, which is at the very bottom of the detector. For this we need assistance from Jamie, etc. => tomorrow.  
<!-- Author: Peter -->


<!-- Date: Tue Sep 7 17:35:16 2004 -->
<pre>Hi all, 
 
	A detailed weekly status report for 9/6/04 can be found at 
 
http://hepr8.physics.tamu.edu/hep/emtiming/management/weekly_2004_update.html	 
 
	Quick status:  
 
- Installation started this morning and appears to be going well. 
 
- All remaining TB and ASD parts have arrived (including front panels and 
other parts to put on the bulkhead boards). 
 
- 13 TB's have been finished. 8 Tested and ready to go. 5 more in testing 
now. Expect to complete all ASD's and TB's by the 14th. 
 
- Long cable production has started. Expected ~Nov 1st.  
 
			Questions and comments are welcome,  
 
                                     Dave</pre>
<!-- Author: Peter -->


<!-- Date: Thu Sep 9 14:54:06 2004 -->
<br><u>CEM harness installation:</u> (2nd day) 
<br> 
All harnesses for the NEB crate have been installed (meaning: PMTs are connected and cables are dressed): 18 (right), 19, 20, 21, 22, 23 (the former is from Fall '03). Wedge 18E (left) has not been attached to PMTs yet (as with 18W (right)).  
LEMOs have not been plugged in yet. Dervin will do this himself in the next days. 
<br>Also, the installation for the NWT crate has been finished by Jamie (00 (from Fall '03), 01, 02, 03, 04, 05). 
<br>Tests will start this evening. 
  
<!-- Author: Peter -->
<!-- Comment: Thu Sep  9 14;55;06 comment by...Peter -->
<pre>(The summary was for the 2nd and 3rd day.)</pre>


<!-- Date: Mon Sep 13 10:32:14 2004 -->
<pre> 
Below is a summary of the TB and ASD labels. 
 
====================================================================== 
Note that 1st number: two-digit serial number 
      and 2nd number: yellow bar code 
====================================================================== 
 
                                CEM 
---------------------------------------------------------------- 
                     11                     14 
---------------------------------------------------------------- 
              ASD        TB             ASD        TB 
---------------------------------------------------------------- 
CANWB:    00/567916   50/529875     30/566126    37/567902 
                27/567943   51/529876     09/567925    29/567894 
---------------------------------------------------------------- 
CANWT:    34/567950   33/567898     43/567959    20/567885 
                28/567944   40/567905     20/567939    36/567901 
---------------------------------------------------------------- 
CANEB:    03/567919   52/529877     12/567928    25/567890 
               02/567918   53/529878     23/567939    54/529879 
---------------------------------------------------------------- 
CANET: 
 
---------------------------------------------------------------- 
 
 
                               Plug 
---------------------------------------------------------------- 
       4          5           6           7 
---------------------------------------------------------------- 
      ASD        ASD         ASD         ASD 
---------------------------------------------------------------- 
NW  30/567946   24/567940   40/567956   11/567927 
NE   22/567938   08/567924   39/567955   17/567933 
SW  44/567960    01/567917   42/567958   06/567922 
SE   14/567930    25/567941   35/567951   21/567937 
---------------------------------------------------------------- 
[note] I couldn't reach to the plug TB side. 
 
 
Teststand room 
 
TB:  24/567889 
      28/567893 
      31/567896 
      55/529880 
      56/529881 
      57/529883 
      58/529884 
      59/529885 
      60/529886 
 
ASD: 26/567942 
        33/567949 
 
==================================================================== 
</pre>
<!-- Author: Sungwon -->


<!-- Date: Mon Sep 13 17:05:18 2004 -->
<u>CEM harness installation:</u> (2nd day)  
<br><br> 
Today the following harnesses on the NE-Top side were installed: 01 and 03. Jamie went on with the installation on the SW-Top side (I didn't see her any more to ask her how much she did...). 
<br>  
<!-- Author: Peter -->
<!-- Comment: Wed Sep 15 18;47;37 comment by...Peter -->
<pre>"2nd day" is wrong here.</pre>
<!-- Date: Tue Sep 14 12:18:24 2004 -->
<pre>David Toback wrote: 
 
Hi all, 
 
A detailed weekly status report for 9/13/04 can be found at 
 
http://hepr8.physics.tamu.edu/hep/emtiming/management/weekly_2004_update.html	 
 
Very quick status summary: Installation is in progress and moving 
well. 
 
 
                                     Dave 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Tue Sep 14 13:19:39 2004 -->
<u>CEM harness installation:</u> 
<br> 
Today the following harnesses on the NE-Top side were installed: 02 and 04 (only 1 half, 2nd half must be installed from the top which was not accessible). Jamie installed all of SE Top yesterday. 
<br>
<!-- Author: Peter -->


<!-- Date: Wed Sep 15 16:30:19 2004 -->
<pre>-----Original Message----- 
> From: Bob DeMaat [mailto:demaat@fnal.gov] 
> Sent: Wednesday, September 15, 2004 3:40 PM 
> To: David Toback 
> Cc: dervin@fnal.gov; maxi@fnal.gov; 'Peter Wagner'; 'Sung-Won Lee' 
> Subject: ASDs and TBs ready for testing 
>  
>  
> The following Transition Boards and ASD Main Modules are ready to be 
> picked up from my office. Max said he will pick them up on 
> Thursday morning. There are 7 transition boards, 9 new ASD boards and 4 
> ASD boards from a previous production run. 
>  
> Bob 
>  
> EM Timing Transition Boards 
>  
> SN/Bar_code_number 
>  
> 60/529873 
> 61/529872 
> 62/529874 
> 63/529887 
> 64/529888 
> 65/529889 
> 66/529890 
>  
>  
> ASD Main Modules ready for testing. 
>  
> 75/529891 
> 76/529892 
> 77/529893 
> 78/529894 
> 79/529895 
> 80/529896 
> 81/529897 
> 82/529898 
> 83/529899 
>  
> ASD Main Modules from a previous production 
> run. These should be tested to determine if 
> they are in need of repair. 
>  
> 05/567921 
> 31/567947 
> 36/567952 
> 37/567953 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Sep 15 18:03:09 2004 -->
<pre>1) Harnesses installed: west wedge 14, 15 
2) ASD/TB installed and cabled up: west wedge 14 (DONE), west wedge 15 (partially DONE) 
3) LED/Showermax testing done and tested by ACE: asked to ACE (available soon) 
4) Towers working?</pre>
<!-- Author: Sungwon -->


<!-- Date: Wed Sep 15 18:46:25 2004 -->
<u>CEM harness installation:</u> 
<br> 
Today all harnesses on the SW-Bottom side were installed by Jamie except the lowest wedge (17). A half of this wedge will be done tomorrow morning.<br> So, fully installed will be then NW, NE and SW except the wedges that are accessible from the top (1/2 of 4 and 5) and the very bottom (1/2 of 18 and 1/2 of 17). <br>Also, the SWT has been hooked up to TBs.<br>
<!-- Author: Peter -->



<!-- Date: Thu Sep 16 15:15:53 2004 -->
<pre>email from 09/11/04: 
 
 Hi All, 
 
last week we installed fully north-west arch and the bottom portion of the  
north-east arch. The wedge 18 has only left PMTs hooked up. In the current  
configuration wedge 18 in our system is in place of wedge 19, wedge 19 is not  
present at all, but it checked out perfectly earlier. On the east side wedge  
4 is in fact wedge 23 (old hardware configuration). 
 
I took an LED run yesterday to check the system. The bottom line is that there  
seems to be only one swap, but the rest of the system checks out. I am  
attaching several files since I can not put them on the web for now.  
 
To understand the following plots keep in mind that LED system cycle has 4 L1  
accepts. It shines light in the following order: left pmts (towers 0-6) ,  
right pmts (towers 0-6), both pmts (towers 3,7-9), and does not shine on the  
forth trigger. The data is taken in Myron mode. 
 
Hit rate canvas is the ratio of events with TDC hits to the events with energy  
above 200 ADC counts. TDC fires is the raw count of events with TDC hits.  
CEMLED is the canvas I took from DBANA with the latest led run, the important  
plots in right top corner (CEMLED). 
 
I will go and describe all fitures as I understand them. First digit in my  
abbreveation is side (0-West, 1-East), wedge number, and tower number. 
 
0_19_6: low number of TDC hits, but hit rate is 1. CEMLED - right pmt led does  
not work, so it all makes sence. 
1_18_1: no TDC hits, hit rate is 0. CEMLED - left tower is blue color - very  
low energy, below the threshold. 
1_18_6: no TDC hits, hit rate is 0. CEMLED - left led does not work. 
0_5_6; 0_3_6; 0_2_6; 0_0_0: low number of TDC hits, but hit rate is 1. CEMLED  
- led on one side does not work 
0_4_5; 0_5_3; 0_1_2: low number of TDC hits, low hit rate. CEMLED - one pmt  
has blue color, so one pmt does fire the TDC. 
 
Now, 0_0_8 has high number of TDC hits, but 0_0_6 has low efficiency. CEMLED  
does not show any problems. Suspicion - swap, the last canvas, Swap Towers,  
confirms it. 
 
So, the bottom line is that with cem led we can id one swap, the rest of the  
system checks out perfectly so far, there are some channels that we can not  
check with led because they do not deposit enough energy. 
 
Cheers, --Max 
 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Sep 16 15:21:39 2004 -->
<table><tr><td><a href=/elog/notebooks/emtiming/Thu_Sep_16_2004_152136.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-17  align='top'></a></td><td>1st plot for the above email. led1.ps 
</td></tr></table>
<!-- Author: Peter -->
<!-- Comment: Tue Sep 21 11;27;13 comment by...Peter -->
<pre>Please disregard this entry!
</pre>
<!-- Date: Thu Sep 16 16:11:00 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-22&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-23  width='300' align='top'></a></td><td>Try again... 1st plot.</td></tr></table>
<!-- Author: Peter -->


<!-- Date: Thu Sep 16 16:11:41 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-24&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-25  width='300' align='top'></a></td><td>2nd file:</td></tr></table>
<!-- Author: Peter -->


<!-- Date: Thu Sep 16 16:13:06 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-28&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-29  width='300' align='top'></a></td><td>3rd file.</td></tr></table>
<!-- Author: Peter -->


<!-- Date: Thu Sep 16 16:13:42 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-30&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-31  width='300' align='top'></a></td><td>4th plot to email.</td></tr></table>
<!-- Author: Peter -->


<!-- Date: Fri Sep 17 11:45:24 2004 -->
<u>CEM harness installation:</u> 
<br> 
Yesterday me and Dervin installed the 2nd half of wedge 18 in NE.<br> 
Today harnesses 15,16 and 1/2 of 17 on the SE-Bottom side were installed. The cables are not dressed all the way and the cable ties have been left loose. That will happen when the 2nd half of 17 is installed.  
<!-- Author: Peter -->


<!-- Date: Fri Sep 17 18:04:21 2004 -->
<pre>1) Harnesses installed: west wedge 15, 16, 17 (all partially DONE) 
2) ASD/TB installed and cabled up: not yet 
3) LED/Showermax testing done and tested by ACE: cem led 187265 and smqie 187266 for wedge 13/14/ 
4) Towers working?</pre>
<!-- Author: Sungwon -->


<!-- Date: Sun Sep 19 18:27:35 2004 -->
<pre>-----Original Message----- 
> From: Max [mailto:maxi@fnal.gov] 
> Sent: Friday, September 17, 2004 1:46 PM 
> To: maxi@fnal.gov 
> Cc: toback@fnal.gov; kamon@fnal.gov; wagnp@fnal.gov; slava77@fnal.gov; 
> khotilov@fnal.gov; slee@fnal.gov 
> Subject: Re: installation results 
>  
> Hi All, 
>  
> here is an update of the current status: 
>  
> West side is almost fully installed. Wedges 17 and 18 will be finished 
> when arches are pulled out. 
>  
> East side - north is partially installed. In the south bottom wedges are 
> installed. 
>  
> One can find the plots at 
> txpc6.fnal.gov/~maxi/EMTiming/Calibrations/CEMLED, look first at plots 
> for run 187219. I tried to fix problems, and right now the latest and 
> greatest plots is in run 187261. 
> As you can see there is one tower where both leds are out, so no way to 
> check right now. Tower in wedge 7 has probably one side not plugged in. 
> The rest of the system looks good (except leds for wedge 8 do not work 
> again). 
>  
> --Max</pre>
<!-- Author: Peter -->


<!-- Date: Mon Sep 20 16:07:16 2004 -->
<u>CEM harness installation:</u> 
<br> 
Jamie and I installed the second half of wedge 17 at SEB.  
<!-- Author: Peter -->



<!-- Date: Wed Sep 22 09:46:04 2004 -->
<pre>Hi all,  
 
	This week's detailed EMTiming installation status report         
        (for 9/20/04) can be found at: 
 
http://hepr8.physics.tamu.edu/hep/emtiming/management/weekly_2004_update.html 
 
	Quick summary status:  
 
- All ASD's are completely stuffed and checked out. 
 
- Enough TB's for the full installation have been stuffed and checked out. Now working on making more spares. 
 
- Installation is ahead of schedule. All of the West (except the bottom of 17 and 18) is installed and checked out (except for channels where we can't check because of LED's which are still dead). Wedges 0 and 15-23 on the East are in the same state. There is a single channel failure in West <17,2> which we expect to be a simple fix in the next days. 
 
	Questions and comments are welcome. Cheers,  
 
                                 Dave, for the EMTiming group 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Sep 22 11:53:41 2004 -->
<pre>-----Original Message----- 
From: Peter Wagner [mailto:wagnp@fnal.gov] 
Sent: Wednesday, September 22, 2004 11:31 AM 
To: David Toback 
Cc: 'David Toback'; 'Maxim Goncharov' 
Subject: Re: status of harness installation 
 
 
Right. (17 and 18 will be done by me and Jamie) 
 
Peter 
 
 
David Toback wrote: 
 
Hi, 
 
       Just to make sure I understand: 
 
- Starting Monday (or whatever) the SW arch will open and we can finish West 17 and 18. Jamie will do these. We can then hook them up to the TB's/ASD's since those are already in and largely checked out. 
 
- On the East we have the harnesses on 0-4 installed, but need to get to the top to do 5 and 6. This Jamie will do next week when the SW arch is in. We then install the TB's and ASD's on the NET. This can also be done next week. 
 
- On the East we have 15-23 done. We need a lift for 12-14 on the SEB and then 6-11 on the SET.  This will wait 2 weeks until we get a lift. When these are done, then we will install the TB's and ASD's for SEB and SET. 
 
                              Is this right? Thanks again, 
 
                                     Dave 
  
********************************************************  
 
-----Original Message----- 
From: Peter Wagner [mailto:wagnp@fnal.gov] 
Sent: Wednesday, September 22, 2004 10:07 AM 
To: David Toback; 'Maxim Goncharov' 
Subject: status of harness installation 
 
I just talked to Dervin: 
 
All that remains is the SE, the top wedges and the very bottom on the north side. 
 
- The SE arch will be pushed back this Friday. 
 
- The SW arch will be pulled out beginning of next week (Monday I guess). So, we can install the NE and NW wedges on the very bottom (complete 17, 18). Also, then we can start finishing the top wedges. This will be done by Jamie. 
 
- As for finishing the top part of SE: We will not have a lift there till in two weeks. Dervin strongly recommends to wait till then, since with a ladder it is much harder to do. 
 
So, the next step will happen on Monday when Jamie shows me how to work on the top wedges, and we will then install the bottom north. Then nothing till in 2 weeks when we will finish the SE. 
  
 
Cheers, 
Peter 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Sep 23 17:49:39 2004 -->
<pre> 
<TABLE BORDER = 0 CELLPADDING = 1 WIDTH = "80%"> 
<TR> 
<TD BGCOLOR=yellow> 
<pre> 
<center> 
<b>==========================================  
Status of the ASD/TB installation (09/23/2004) 
===========================================</b> 
</center> 
 
==================================================================== 
VERSION Version 1: 09/22/2004 
VERSION Version 2: 09/23/2004 
==================================================================== 
 
[key] ??  ?????? = installed already in downstairs, 
                   but not checked the numbers yet (not easy to access) 
      XX  XXXXXX = no stickers at the moment 
      --  ------ = not installed yet. 
 
==================================================================== 
PEM 
==================================================================== 
Rack  Crate   Slot    ASD          TB 
                   SN# BarCode  SN# BarCode 
==================================================================== 
NW    M       4    30  567946   ??  ??????  
NW    M       5    24  567940   ??  ??????  
NW    M       6    40  567956   ??  ??????  
NW    M       7    11  567927   ??  ?????? 
-------------------------------------------------------------------- 
SW    M       4    44  567960   04  567869  
SW    M       5    01  567917   03  567868 
SW    M       6    42  567958   02  567867 
SW    M       7    06  567922   01  567866 
-------------------------------------------------------------------- 
NE    M       4    22  567938   09  567874  
NE    M       5    08  567924   10  567875 
NE    M       6    39  567955   12  567877  
NE    M       7    17  567933   11  567876 
-------------------------------------------------------------------- 
SE    M       4    14  567930   13  567878 
SE    M       5    25  567941   14  567879  
SE    M       6    35  567951   22  567887   
SE    M       7    21  567937   16  567881 
-------------------------------------------------------------------- 
 
 
==================================================================== 
CEM 
==================================================================== 
Rack  Crate   Slot    ASD          TB 
                   SN# BarCode  SN# BarCode 
==================================================================== 
NWT   BOTTOM  11   28  567944   40  567905 
NWT   BOTTOM  14   20  567939   36  567901 
NWT   TOP     11   34  567950   33  567898 
NWT   TOP     14   43  567959   20  567885 
-------------------------------------------------------------------- 
SWT   TOP     11   ??  ??????   ??  ?????? 
SWT   TOP     14   ??  ??????   ??  ?????? 
SWT   BOTTOM  11   ??  ??????   ??  ?????? 
SWT   TOTTOM  14   ??  ??????   ??  ?????? 
-------------------------------------------------------------------- 
SWB   TOP     11   41  567957   28  567893 
SWB   TOP     14   26  567942   60  529886 
SWB   BOTTOM  11   15  567931   24  567889 
SWB   TOTTOM  14   10  567926   57  529883 
-------------------------------------------------------------------- 
NWB   BOTTOM  11   27  567943   51  529876 
NWB   BOTTOM  14   09  567925   29  567894 
NWB   TOP     11   00  567916   50  529875 
NWB   TOP     14   30  566126   37  567902 
-------------------------------------------------------------------- 
 
 
==================================================================== 
Rack  Crate   Slot    ASD          TB 
                   SN# BarCode  SN# BarCode 
==================================================================== 
NET   BOTTOM  11   --  ------   --  ------ 
NET   BOTTOM  14   --  ------   --  ------ 
NET   TOP     11   --  ------   --  ------ 
NET   TOP     14   --  ------   --  ------ 
-------------------------------------------------------------------- 
SET   TOP     11   --  ------   --  ------ 
SET   TOP     14   --  ------   --  ------ 
SET   BOTTOM  11   --  ------   --  ------ 
SET   TOTTOM  14   --  ------   --  ------ 
-------------------------------------------------------------------- 
SEB   TOP     11   --  ------   --  ------ 
SEB   TOP     14   --  ------   --  ------ 
SEB   BOTTOM  11   45  567961   60  529873 
SEB   TOTTOM  14   32  567948   XX  XXXXXX 
-------------------------------------------------------------------- 
NEB   BOTTOM  11   02  567918   53  529878 
NEB   BOTTOM  14   23  567939   54  529879 
NEB   TOP     11   03  567919   52  529877 
NEB   TOP     14   12  567928   25  567890 
-------------------------------------------------------------------- 
 
 
==================================================================== 
14 ASDs (12: teststand room, 2: Dervin's office) 
==================================================================== 
05-567921 
31-567947 
33-567949 
36-567952 
37-565953 
75-529891 (Dervin's office) 
76-529892 
77-529893 
78-529894 (Dervin's office) 
79-529895 
80-529896 
81-529897 
82-529898 
83-529899 
==================================================================== 
 
 
==================================================================== 
10 TBs (8: teststand room, 2: Dervin's office) 
==================================================================== 
18-567883 
32-567897 (Dervin's office) 
61-529872 
62-529874 
63-529887 
64-529888 
65-529889 
66-529890 
XX-XXXXXX 
XX-XXXXXX (Dervin's office) 
==================================================================== 
 
</td> 
</tr> 
</table>  
<!-- Author: Sungwon -->
<!-- Comment: Thu Dec 14 14;09;04 comment by...  -->
</pre>
<!-- Date: Wed Sep 29 10:29:49 2004 -->
<pre>-----Original Message----- 
> From: David Toback [mailto:toback@tamu.edu] 
> Sent: Wednesday, September 29, 2004 10:11 AM 
> To: 'David Toback'; 'Rob Roser'; 'Camille Ginsburg'; 'Pat Lukens'; 'Steve 
> Kuhlmann' 
> Cc: 'Marco Cordelli'; 'Maxim Goncharov'; 'Bob DeMaat'; 'Peter Wilson'; 
> 'Henry Frisch'; 'Mike Lindgren'; 'Willis Sakumoto'; 'Dervin Allen'; 'Peter 
> Wagner'; 'Sungwon Lee'; 'Franco Bedeschi'; 'Bob Wagner' 
> Subject: Weekly status report for 9/27/04 
>  
> Hi all, 
>  
> 	This week's detailed EMTiming installation status report (for 
> 9/20/04) can be found at: 
>  
> http://hepr8.physics.tamu.edu/hep/emtiming/management/weekly_2004_update.html 
>  
> 	Quick summary status: 
>  
> - All ASD's are completely stuffed and checked out. 
>  
> - Enough TB's for the full installation have been stuffed and checked out. 
> All spares should be finished this week (if they aren't done already). 
>  
> - Installation is ahead of schedule. All of the West (except the bottom of 
> 17 and 18) is installed and checked out (except for channels where we 
> can't 
> check because of LED's which are still dead). Wedges 0 and 15-23 on the 
> East 
> are in the same state. There is a single channel failure in West <17,2> 
> which we expect to be a simple fix in the next days.  Waiting on lift 
> access 
> to finish it all. 
>  
> 				Questions and comments are welcome. Cheers, 
>  
>                                      Dave, for the EMTiming group 
>  
> </pre>
<!-- Author: Peter -->


<!-- Date: Fri Oct 1 14:26:14 2004 -->
<u>CEM Harness Installation:</u> 
<br><br> 
Jamie and I installed the bottom wedges 17(SW) and 18(NW) on Wednesday. => The West side is completed.  
<!-- Author: Peter -->


<!-- Date: Mon Oct 4 15:24:30 2004 -->
<a href="http://txpc6.fnal.gov/~maxi/EMTiming/Talks/InStatus-09292004/">Max's talk in the EMTiming Meeting on Wed 09/29/04</a><br>
<!-- Author: Peter -->


<!-- Date: Tue Oct 5 14:21:44 2004 -->
<pre>David Toback wrote: 
>  
 
> >Hi, 
> > 
> >	I've updated the status at 
> >http://hepr8.physics.tamu.edu/hep/emtiming/management/2004_status/report_2004_10_04.txt 
> > 
> >	Could each of you check and get back to me with 
> >comments/corrections? 
> > 
> >				Thanks, 
> > 
> >                                     Dave 
> > 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Oct 7 14:37:22 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-34&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-35  width='300' align='top'></a></td><td>Current map of working channels (ignore PEM for now). 
<br> 
Red=Working<br> 
Green=Broken (or not hooked up)<br> 
Blue= Can't tell because LED system isn't up.<br> 
 
</td></tr></table>
<!-- Author: Peter -->


<!-- Date: Mon Oct 11 10:57:20 2004 -->
<pre>That's excellent news Bob! 
 
If my notes are correct, this completes the production of all the EMTiming 
components from FNAL. Now we're just waiting on those long cables. 
 
					Thanks and keep in touch,  
 
                                     Dave 
 
 
 
> -----Original Message----- 
> From: Bob DeMaat [mailto:demaat@fnal.gov] 
> Sent: Monday, October 11, 2004 9:13 AM 
> To: David Toback 
> Cc: Sungwon Lee; 'Maxim Goncharov' 
> Subject: Re: Transition board 
>  
> Dave, 
>  
> The bulkhead boards have been transferred to 
> a new motherboard. It is now on the table in 
> my office, ready to be taken to B0 for testing. 
>  
> Bob</pre>
<!-- Author: Peter -->


<!-- Date: Tue Oct 12 18:01:56 2004 -->
<pre>Hi all,  
 
	This week's detailed EMTiming installation status report (for 10/11/04) can be found at: 
 
http://hepr8.physics.tamu.edu/hep/emtiming/management/weekly_2004_update.html 
 
	Quick summary status:  
 
- All ASD's are completely stuffed and checked out. 
 
- All TB's stuffed with one remaining to be tested 
 
- West: All installed and checked out (except for channels where we can't check because of LED's which are still dead); 2 potential single channel failures.  
 
- East: 0-5 and 15-23 are in the same state; 1 potential single channel failure. Should install the rest once we can get a lift. 
 
				Questions and comments are welcome. Cheers, 
 
                                     Dave 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Oct 14 13:34:14 2004 -->
<pre>We checked a problem in wedge 17, tower 14 (PEM, South-East crate) which shows only 80% efficiency on the EMTiming efficiency-plot. 
Using the mapping note we found the corresponding crate, ASD slot, LEMO-group and position of the 2 LEMOs on the TB. 
The corresponding LEMO cables to this tower in the wedge are no. 8 and 9. We checked with a scope the TB side the connection towards the PMT and towards the TB side - nothing suspicous. Also we checked the AMP connection on the PMT box towards the TB and towards the PMT. We found a slightly flaky connection on the PMT box: PMT box for wedge 17(east), AMP connector (on PMT box side) for channels 0-9, channel 8.  
We will report this problem.</pre>
<!-- Author: Peter -->


<!-- Date: Fri Oct 15 11:14:54 2004 -->
<pre>On Fri, Oct 15, 2004 at 10:47:35AM -0500, David Toback wrote: 
 
Hi Max, 
 
You didn't tell me it was done!!! I just looked at 
http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/CEMLED/188145/HitRateCem.jpg 
 
This is GREAT!!!  Excellent news!!! Please put this in the log book! 
 
 
                                     Dave 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Tue Oct 19 11:51:30 2004 -->
<pre>On Tue, Oct 19, 2004 at 11:04:55AM -0500, David Toback wrote: 
> Hi all, 
> 
>       This week's detailed EMTiming installation status report (for 
> 10/18/04) can be found at: 
> 
> http://hepr8.physics.tamu.edu/hep/emtiming/management/weekly_2004_update.html 
> 
>       Quick summary status: 
> 
> - All ASD's and TB's are completely stuffed and checked out. 
> 
> - Installation: All wedges have been installed and checked out (except for 
> channels where we can't check because the LED system isn't working); 3 
> potential single channel failures. 
> 
>       If there are no further questions, this will be the last 
> installation report. Congrats to everyone on a job well done! On to 
> commissioning! 
> 
>                               Questions and comments are welcome. Cheers, 
> 
>                                      Dave for the EMTiming group 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Oct 20 15:56:17 2004 -->
<pre>Here is the list:  ("wedge"/"tower ID" ; "u": upper box in the 
EMTiming plots, "l": lower box in the plots) 
 
22/8u * : pot. problem in the PMT connection 
21/8l * : pot. problem in the PMT connection 
18/2u * : pot. problem in the PMT connection 
17/-1u * : pot. problem in the PMT connection 
14/-1l * : pot. problem in the PMT connection 
14/1u: potential problem in both lines (not plugged into PMT correctly?) 
13/6l * : pot. problem in the PMT connection 
9/-3l * : pot. problem in the PMT connection 
9/-0u: pot. probl. in secondary line 
8/+0l * : pot. problem in the PMT connection 
7/-2l: problem in secondary line (confirmation of earlier observations) 
6/6u *: pot. probl. in secondary line 
1/6l *: pot. probl. in secondary line 
 
 
*: all indicated as problems in the LED run; but there are too few or 
 no hits in the spike run, so here we should wait till we have more 
 "luminosity" in the spike run to be sure. 
 
From the spike run we can also determine the problems in those towers 
in the CEM into which the LEDs fire all at once, these are towers 7,8 
and 9 (hence these problems were not visible in the LED run): 
10/-9u 
10/-8u 
3/8u 
3/9u 
10/9u 
1/9u 
---> all potential secondary line problems 
 
 
Cheers, 
Peter 
 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Thu Oct 21 10:42:47 2004 -->
<pre>Hi, 
 
Very nice. I was surprised to see that even if the LED system is 
working for a PMT that some of them don't have enough oomph to fire the ASD. 
For example East <1,2> doesn't fire from LED, but you can see it clear as day its working from the spikes and cosmics. 
 
Just to make sure I understand some of the other stuff. It looks 
like West <5,8> and <5,9> are dead in cosmics and spikes, and since the LED's are dead in that wedge we can't tell anything there. Is that right? It could also be that those tubes are dead somehow... Hmmm... 
 
Can we do an LED run with the left side at standby like we did with Bob Wagner last year? That would give us more about towers 7, 8 & 9 everywhere. For example East <10,8> and <10,9> show problems in one side in the spike run but are fine in LED (consistent with both firing at the same time, so no new information there) and at about 50% with cosmics (no 
confirmation info there really, but consistent). 
 
Bob & Steve: Thoughts? 
 
Cheers, 
 
                                     Dave 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Oct 27 11:14:48 2004 -->
<pre>Hi All, 
 
here is a summary of checks I have done on the system. 
 
Cosmic ray run: 
http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/Cosmics/188235-188303/HitRate.jpg 
<http://txpc6.fnal.gov/%7Emaxi/EMTiming/Calibrations/Cosmics/188235-188303/HitRate.jpg> 
 
what I ca see is that all channels are working, meaning that everything 
in the line ASD->TDC works. It is impossible to say anything about 
individual PMTs from this data. 
 
CEM LED: 
http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/CEMLED/188304/HitRateEgt2000.jpg 
<http://txpc6.fnal.gov/%7Emaxi/EMTiming/Calibrations/CEMLED/188304/HitRateEgt2000.jpg> 
 
is allows to check individual PMTs up to tower 7. There is no 
information about channels in blue (so they should go on list of 
suspects), and channels in green should also go on the list of suspects. 
However, green channels might be fine, the LED signal might be wide and low. 
 
Spike Runs: 
http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/SUMET5/188305-188334/HitRate.jpg 
<http://txpc6.fnal.gov/%7Emaxi/EMTiming/Calibrations/SUMET5/188305-188334/HitRate.jpg> 
 
This run is complimentary to the LED run. If the suspect from LED run 
has non zero rate, then we cross it out from the list, if there is no 
information here, then the channel remains on the list. 
 
So, at the end what I can say for sure is that wedge 7, tower 2 west 
seems to be disconnected. Other channels - who knows. Peter sent around 
a list of channels he was going to look at. 
 
--Max 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Oct 27 13:21:19 2004 -->
<pre>The channels have been checked for the connection on the PMT, the 
connections on the splitter and the connection on the TB if it was a secondary line problem. 
Here are the results for the EMTiming checks: 
 
("wedge"/"tower ID" ; "u": upper box in the EMTiming plots, "l": lower box in the plots) 
 
22/8u * : pot. problem in the PMT connection 
-> no problem detected 
 
21/8l * : pot. problem in the PMT connection 
-> the primary on the splitter was unplugged 
 
18/1u * : pot. problem in the PMT connection 
-> no problem detected 
 
17/-1u * : pot. problem in the PMT connection 
-> not accessible (on the bottom) 
 
14/-1l * : pot. problem in the PMT connection 
-> no problem detected 
 
14/1u: potential problem in both lines (not plugged into PMT correctly?) 
-> no problem detected 
 
13/6l * : pot. problem in the PMT connection 
-> PMT connection was a bit loose 
 
9/-3l * : pot. problem in the PMT connection 
-> no problem detected 
 
9/-0u: pot. probl. in secondary line 
-> no problem detected 
 
8/+0l * : pot. problem in the PMT connection 
-> known problem on the PMT: the ADMEM socket on the PMT is broken 
 
7/-2l: problem in secondary line (confirmation of earlier observations) 
 
6/6u *: pot. probl. in secondary line 
-> not accessible (on the top) 
 
1/6l *: pot. probl. in secondary line 
1/9u 
3/8u 
3/9u 
-> not accessible (arch pulled out) 
 
10/-9u 
10/-8u 
10/9u 
-> will check these next time 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Mon Nov 1 17:24:20 2004 -->
<pre>Now I checked the following channels which were indicated only from the spike run as suspicious: 
 
10/-9u *: pot. probl. in secondary line 
-> the secondary line (inclusive splitter) of this channel was swapped with 10/-8u 
 
10/-8u *: pot. probl. in secondary line 
-> the secondary line (inclusive splitter) of this channel was swapped with 10/-9u 
 
10/9u *: pot. probl. in secondary line 
-> the secondary line (inclusive splitter) of this channel was swapped with 10/7u 
 
So, obviously the spike run is quite valuable. 
 
 
 
There are still the following channels remaining to be checked: 
6/6u *: pot. probl. in secondary line 
-> not accessible (on the top) 
1/6l *: pot. probl. in secondary line 
From the spike run: 
1/9u 
3/8u 
3/9u 
-> not accessible (arch pulled out) 
 
 
</pre>
<!-- Author: Peter -->
<!-- Comment: Mon Nov  1 17;42;22 comment by...Peter -->
<pre>There is one more channel that has to be checked:

17/-1u * : pot. problem in the PMT connection 
-> not accessible (on the bottom) 

</pre>


<!-- Date: Tue Nov 9 11:54:37 2004 -->
<pre>I checked the remaining channels: 
("wedge"/"tower ID" ; "u": upper box in the EMTiming plots, "l": lower box in t\he plots) 
 
6/6u *: pot. probl. in secondary line 
-> no problem detected 
 
1/6l *: pot. probl. in secondary line 
-> no problem detected 
 
from the spike run: 
1/9u 
-> primary line was swapped with 8u 
 
3/8u and 3/9u 
-> splitter were swapped 
 
17/-1u * : pot. problem in the PMT connection 
-> no problem detected 
 
 
So, are all towers are now checked for potential problems indicated by previous LED and Spike runs. 
 
 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Tue Nov 16 17:47:27 2004 -->
<pre>The eight long cables, which will be used as spares, arrived yesterday. They have been tested today at the test stand; no problems are found. They are now situated near the main receiving door at B0. 
</pre>
<!-- Author: Peter & Max -->


<!-- Date: Tue Nov 23 14:44:54 2004 -->
<pre>Hi All, 
 
after all trials the status of CEM PMTs: all pedestals are good, there 
is one channel with high RMS, but it was always this way. We have one 
splitter unplugged at the moment (west 9 2R), it has to be replaced. 
 
Jut a bit of information: if one of the lemos is not fully plugged in - 
it can cause a zero pedestal. So for the future if there is a problem 
like we have seen the first thing would be to check all connections - 
fixed this way 2 problems today. 
 
I would like to thank Bob Wagner, he fixed a channel on wedge 17 (yes, 
all the way under the detector) and prevented CDF from having to Monte 
Carlo my body stuck in there. Thanks Bob! 
 
Cheers, 
        --Max 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Tue Nov 30 14:47:13 2004 -->
<pre>CEM Status: (see also Max's email above) 
 
9 West, 2R: due to zero pedestals it had to be unplugged; the splitter will be repaired/replaced. 
 
17 West, 1L: fixed by Bob Wagner; we have taken a pedestal run as a check. -> OK. 
 
6 East, 1R: RMS too high in the pedestal run. Fixed by screwing the ADMEM LEMO properly. As a sidenote, during the installation we noticed that quite a few ADMEM LEMOs were not screwed tight properly. 
</pre>
<!-- Author: Peter -->
<!-- Comment: Fri Jan  7 11;29;10 comment by...Peter -->
<pre>Channel 2,9 has been fixed by Dervin by replacing the splitter after problems showed up during the pedestal run.

</pre>
<!-- Date: Wed Dec 8 15:06:05 2004 -->
<pre>After taking the first data with the complete timing system: 
 
=============== 
 
Hi All, 
 
I posted plots for EMTiming system with new data in 
http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/BeamData/190697-190702 
 
PEM: 
Efficiency2DPEM.ps - shows the efficiency for plug. There are several channels that look suspicious, but only one is real problem: east 13-16-0, others are due to lack of statistics 
Threshold2DPEM.ps - place for the efficiency turn-on, again the real problem is in channel 1-3-16-0 
 
CEM: 
Threshold2DCEM.ps - efficiency turn-on. For each of the suspicious channels there is a separate plot (effcem...). 
1-5-6 : known problem with one pmt channel, since I require symmetric in energy events, this is has nothing 
1-6-6 : threshold seems to be high - might be real problem, need more statistics to look at rms of the turn-on curve. If there is a problem with one channel - it will show wider than normal rms 
0-14-1 : same comments as for 1-6-6 
0-1-4  : same as for 1-6-6 
0-9-2  : known problem: one channel is unplugged, splitter needs to be replaced. 
 
nhits_cem.ps and nhits_pem.ps - TDC occupancies for both systems 
 
meant0_2dcem.ps and meant0_2dpem.ps - 2D plots of the mean T0s for each channels. 
t0_cem.ps - t0_pem.ps - T0 distributions for both systems. 
 
All in all: 3 problems at the moment 
CEM two channels that need work - 
0-9-2 - splitter needs to be replaced 
1-5-6 - something is wrong with one PMT energy readout 
PEM - 1-13-6-0 needs to be looked at. 
 
Cheers, 
    --Max  
</pre>
<!-- Author: Peter -->
<!-- Comment: Wed Dec  8 15;07;14 comment by...Peter -->
<pre>About channel 1_5_6:

========================


Bob Wagner Argonne HEPD wrote:

> Larry and Max,
>
>     I think this might be the tube that has a high voltage problem.  The tube's voltage read back drops; it gets reset, and then voltage later shows too high.  I need to look at my records to make sure, but I think Willis also knows precisely the offender.
>
> Regards,
>
> Bob
>
>
> On Tue, 7 Dec 2004, Larry Nodulman wrote:
>
>
>>  From home all I get is the tower plot,  that is 5E tower 6 looks dead, ymon online has a pmt plot so we should be able to tell which guy it is.        -Larry
>>
>> On Dec 7, 2004, at 9:35 PM, Max wrote:
>>
>>
>>> Hi,
>>>
>>> I looked at the new data taken today, one channel - west w5 6 looks like one pmt is not there. Are there ymon plots somewhere on the web to look at PMT occupancies?
>>>
>>> Thanks,
>>>     --Max
>>>
>>
</pre>


<!-- Date: Thu Dec 9 10:47:09 2004 -->
<pre>Hi All, 
 
I ran over all files in bphysr look area, the plots for CEM are in 
 
http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/BeamData/190697-190764/ 
 
Wedge 9 - known problem 
Wedge 1 - swap in towers 4 and 6 
Wedge 14 and 6 - unknown 
Wedge 5 - going to look at it today 
 
for PEM status is unchanged - one bad channel 
 
--Max 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Dec 15 12:54:55 2004 -->
<pre>Access on Dec 09: 
 
Two CEM problems were fixed during the controlled access: 
 
      1) CEM 6R05E showed up as dead on occupancy.  Found the 
         ground connector unscrewed from the signal conductor on 
         the anode lemo cable at the point where it plugs into the 
         EM timing splitter board.  Reconnected the two.  Should 
         be working properly again. 
 
      2) EM timing cables for 4R01W and 6R01W were swapped at the 
         input of the cables to the transition board.  Swapped 
         cables back to proper location.  Should now see problem 
         gone on EM timing occupancy plot. 
 
  - Bob Wagner (ANL) 
 
 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Wed Dec 15 13:02:45 2004 -->
<pre>EMTiming  access summary of today:  
 
fixed 2 channels:   
1 on CASWB top crate (slot 14; west wedge 14, tower 1)  
1 on CASET top crate (slot11; east wedge 6 tower 6) 
 
In both cases the socket of the LEMO connection on the TB was flaky. We plugged both the left and right sides of both channels to another TB channel and changed the mapping of the TDCs correspondingly and reloaded the memory of the TDCs. We checked the remapping by taking a short test run - without problems. 
 
We will wait for the new data to check the result of our repairs. Data taking will presumably start later today or tomorrow morning. 
 
Channel 0_9_2 has not been fixed by Dervin yet. 
The problematic PEM channel was not accessible as the plug was not moved out. 
</pre>
<!-- Author: Peter -->



<!-- Date: Wed Jan 12 11:44:44 2005 -->
<pre>Status of Access requests as of Mon, 10 Jan 2005: 
 
From wagnp@fnal.gov 
To: Willis Sakumoto <willis@fnal.gov> 
CC: David Toback <toback@tamu.edu>, 
 Vyacheslav Krutelyov <slava77@fnal.gov>, 
 'dervin' <dervin@fnal.gov> 
Subject: Re: Calorimetry Access request 
 
[...] 
 
Also, I would like to put in an access request for the following 
channels in addition to CEM W09-2 and PEM E13-16 which we have not fixed 
yet: 
 
CEM: E03-6 
This seems to be a similar problem as CEM W09-2. See turn-on curves at 
http://txpc1.fnal.gov/wagnp/ObjectMon_plots/1_3_6_thresheff.eps and 
http://txpc1.fnal.gov/wagnp/ObjectMon_plots/0_9_2_thresheff.eps 
(good CEM channel at 
http://txpc1.fnal.gov/wagnp/ObjectMon_plots/goodCEM_thresheff.eps) 
Time: ~3 hours 
 
 
[...] 
 
 
 
>> [Mon, 20 Dec 2004] Willis Sakumoto wrote: 
>> 
>> 
>> 
>>>The Calorimetry group is submitting the following access request for 
>>>EM timing work. This is likely two separate jobs. 
>>>                                                       -- Willis 
>>> 
>>>0) Personnel: Slava Krutelyov, Peter Wagner 
>>>1) CEM: W09-2 splitter needs to be replace. 
>>>        - Dervin knows about this problem. 
>>>        - South muon wall out 
>>>        - Time: 3 hours 
>>>2) PEM: E13-16 : unknkown problem, we have to take a look. 
>>>        - East toroid out, and possibly the electronics rack needs to be 
>>>          pulled out to access the EM timing transition card 
>>>        - Time: 8 hours 
>>> 
> 
</pre>
<!-- Author: Peter -->


<!-- Date: Mon Jan 24 10:37:23 2005 -->
<pre>Date: Fri, 21 Jan 2005 19:44:48 -0600 (CST) 
From: Bob Wagner Argonne HEPD <rgwcdf@hep.anl.gov> 
Subject: Bad EM Splitter Board 1L17W 
To: David Toback <toback@tamu.edu> 
Cc: 'Willis Sakumoto' <willis@fnal.gov>, cdf-ops-managers@fnal.gov, 
 maxi@fnal.gov 
 
Dave and Max, 
 
        I removed the splitter from 1L17W on access today.  It had a short 
that rendered the channel bad.  This same tube caused a problem back on 22 
Nov 2004.  I crawled under the detector to work on it at the time.  I 
recall that the anode cable was not securely plugged into the splitter but 
am not 100% sure that was the problem.  I tried looking back through the 
e-log and my mails for what I did but didn't find the exact cause. 
Anyway, you should put this on your fix list for the next supervised 
access.  Be aware that someone will have to crawl underneath the detector 
to fix it.  Peter Wagner? 
 
Regards, 
 
Bob 
 
</pre>
<!-- Author: Peter -->
<!-- Comment: Mon Jan 24 10;38;14 comment by...Peter -->
<pre>This channel only showed up as bad on the Pedestal plots in DBANA.
</pre>


<!-- Date: Mon Jan 24 10:50:46 2005 -->
<pre>See below: TimeMonitor catches the bad channel 17,-1. 6,1 is a new problem? 
 
 
 
Run 192794 with 42091 processed events 
 
There were red histograms with names: 
    t0RawPEM 
    t0RawCHA 
    t0RawPHA 
 
Bad/Improved channels summary: 
 
wedge rapd Failures: 100%  Multi+LowW MultiOk Fake  Change Status 
3     6              10/10 0/0        0/0     0/0 
6     1              00/00 0/0        1/0     0/0   New Problem 
9     -2             11/11 0/0        0/0     0/0 
13    16             10/10 0/0        1/1     0/0 
17    -1             01/00 0/0        0/0     0/0   New Problem 
 
Objectmon results for current run (may be not ready immediately): 
http://txpc6.fnal.gov/~slee/objmon/Time/192794-Time2.ps 
http://txpc6.fnal.gov/~slee/objmon/summ/192794.summ 
Objectmon results for bad channels reference run: 
http://txpc6.fnal.gov/~slee/objmon/Time/191783-Time2.ps 
http://txpc6.fnal.gov/~slee/objmon/summ/191783.summ 
Histogram reference file was: 
/data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Mon Jan 31 10:38:28 2005 -->
<pre>-----Original Message----- 
From: Data Acquisition [mailto:cdfdaq@b0dap82.fnal.gov] 
Sent: Saturday, January 29, 2005 10:58 PM 
To: khotilov@fcdfsgi2.fnal.gov; maxi@fnal.gov; toback@fnal.gov; 
slee@fnal.gov; wagnp@fnal.gov 
Subject: TimeMonitor Notification for run 193029 
 
Run 193029 with 61408 processed events 
 
There were red histograms with names: 
    t0RawPEM 
    t0RawCHA 
    t0RawPHA 
 
Bad/Improved channels summary: 
 
wedge rapd Failures: 100%  Multi+LowW MultiOk Fake  Change Status 
3     6              10/10 0/0        0/0     0/0 
7     -17            00/00 0/0        0/0     1/0   New Problem 
7     -16            00/00 0/0        0/0     1/0   New Problem 
7     -15            00/00 0/0        0/0     1/0   New Problem 
7     -14            00/00 0/0        0/0     1/0   New Problem 
7     -13            00/00 0/0        0/0     1/0   New Problem 
7     -12            00/00 0/0        0/0     1/0   New Problem 
7     -11            00/00 0/0        0/0     1/0   New Problem 
7     -10            00/00 0/0        0/0     1/0   New Problem 
8     -17            00/00 0/0        0/0     1/0   New Problem 
8     -16            00/00 0/0        0/0     1/0   New Problem 
8     -15            00/00 0/0        0/0     1/0   New Problem 
8     -14            00/00 0/0        0/0     1/0   New Problem 
8     -13            00/00 0/0        0/0     1/0   New Problem 
8     -12            00/00 0/0        0/0     1/0   New Problem 
8     -11            00/00 0/0        0/0     1/0   New Problem 
8     -10            00/00 0/0        0/0     1/0   New Problem 
9     -17            00/00 0/0        0/0     1/0   New Problem 
9     -16            00/00 0/0        0/0     1/0   New Problem 
9     -15            00/00 0/0        0/0     1/0   New Problem 
9     -14            00/00 0/0        0/0     1/0   New Problem 
9     -13            00/00 0/0        0/0     1/0   New Problem 
9     -12            00/00 0/0        0/0     1/0   New Problem 
9     -11            00/00 0/0        0/0     1/0   New Problem 
9     -10            00/00 0/0        0/0     1/0   New Problem 
9     -2             10/11 0/0        0/0     0/0   New Problem 
10    -17            00/00 0/0        0/0     1/0   New Problem 
10    -16            00/00 0/0        0/0     1/0   New Problem 
10    -15            00/00 0/0        0/0     1/0   New Problem 
10    -14            00/00 0/0        0/0     1/0   New Problem 
10    -13            00/00 0/0        0/0     1/0   New Problem 
10    -12            00/00 0/0        0/0     1/0   New Problem 
10    -11            00/00 0/0        0/0     1/0   New Problem 
10    -10            00/00 0/0        0/0     1/0   New Problem 
13    16             10/10 0/0        1/1     0/0 
17    -1             01/00 0/0        0/0     0/0   New Problem 
 
Objectmon results for current run (may be not ready immediately): 
http://txpc6.fnal.gov/~slee/objmon/Time/193029-Time2.ps 
<http://txpc6.fnal.gov/%7Eslee/objmon/Time/193029-Time2.ps> 
http://txpc6.fnal.gov/~slee/objmon/summ/193029.summ 
<http://txpc6.fnal.gov/%7Eslee/objmon/summ/193029.summ> 
Objectmon results for bad channels reference run: 
http://txpc6.fnal.gov/~slee/objmon/Time/191783-Time2.ps 
<http://txpc6.fnal.gov/%7Eslee/objmon/Time/191783-Time2.ps> 
http://txpc6.fnal.gov/~slee/objmon/summ/191783.summ 
<http://txpc6.fnal.gov/%7Eslee/objmon/summ/191783.summ> 
Histogram reference file was: 
/data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
 
 
 
</pre>
<!-- Author: Peter -->
<!-- Comment: Mon Jan 31 10;39;53 comment by...peter -->
<pre>

From the Shift-elog:

- Sat Jan 29 23:05:57 comment by...Oriol --

crate b0pcal02 was stucking during ending the run.
we shephered it.
Solved.


I looked it up, this crate serves the problematic wedges.

So, it has nothing to do with the timing system directly.


</pre>


<!-- Date: Fri Feb 11 10:08:05 2005 -->
<pre>Today repaired channels  
17,2 West: replaced the splitter. 
3,6 East: connection of the harness to the TB was flaky on the TB board side. (I jiggled with the test harness from the scope on the TB plug and the signal clearly vanished). So, I replugged the harness from TB plug 4 to TB plug 11. One now still has to remap the TDC board which I have not yet done! 
 
Anyways, I took QIE calibration runs to check (runs 193670 and 193671). Channel 17,2 looks fine now. But what confuses me is that 3,6 looks fine as well, although I would expect a white box there since I haven't yet remapped the TDC board... hmmm... 
 
</pre>
<!-- Author: Peter -->
<!-- Comment: Mon Feb 14 15;40;49 comment by...peter -->
<pre>The repairs were successful:

> -----Original Message-----
> From: Data Acquisition [mailto:cdfdaq@b0dap82.fnal.gov]
> Sent: Sunday, February 13, 2005 8:52 AM
> To: khotilov@fcdfsgi2.fnal.gov; maxi@fnal.gov; toback@fnal.gov;
> slee@fnal.gov; wagnp@fnal.gov
> Subject: TimeMonitor Notification for run 193855
>
> Run 193855 with 56337 processed events
>
> Bad/Improved channels summary:
>
> wedge rapd Failures: 100%  Multi+LowW MultiOk Fake  Change Status
> 3     6              00/10 0/0        0/0     0/0   Improved
> 9     -2             00/10 0/0        0/0     0/0   Improved
> 13    16             10/10 0/0        1/1     0/0
> 17    -1             00/01 0/0        0/0     0/0   Improved
> 21    -17            00/00 0/0        1/1     0/0
>
> Objectmon results for current run (may be not ready immediately):
> http://txpc6.fnal.gov/~slee/objmon/Time/193855-Time2.ps
> http://txpc6.fnal.gov/~slee/objmon/summ/193855.summ
> Objectmon results for bad channels reference run:
> http://txpc6.fnal.gov/~slee/objmon/Time/193013-Time2.ps
> http://txpc6.fnal.gov/~slee/objmon/summ/193013.summ
> Histogram reference file was:
> /data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root

</pre>

<!-- Comment: Mon Feb 21 13;47;29 comment by...peter -->
<pre>In the same access also 9,2 West has been fixed by Max (replaced the splitter).
</pre>


<!-- Date: Tue Mar 22 13:20:36 2005 -->
<pre>>-----Original Message----- 
> 
>From: Data Acquisition [mailto:cdfdaq@b0dap82.fnal.gov] 
> 
>Sent: Monday, March 21, 2005 2:40 PM 
> 
>To: khotilov@fcdfsgi2.fnal.gov; maxi@fnal.gov; toback@fnal.gov; 
> 
>slee@fnal.gov; wagnp@fnal.gov 
> 
>Subject: TimeMonitor Notification for run 195585 
> 
>  
> 
>Run 195585 with 76221 processed events 
> 
>  
> 
>Bad/Improved channels summary: 
> 
>  
> 
>wedge rapd Failures: 100%  Multi+LowW MultiOk Fake  Change Status 
> 
>1     5              11/00 0/0        0/0     0/0   New Problem 
> 
>13    16             10/10 0/0        1/1     0/0 
> 
>  
> 
>Objectmon results for current run (may be not ready immediately): 
> 
>http://txpc6.fnal.gov/~slee/objmon/Time/195585-Time2.ps 
> 
>http://txpc6.fnal.gov/~slee/objmon/summ/195585.summ 
> 
>Objectmon results for bad channels reference run: 
> 
>http://txpc6.fnal.gov/~slee/objmon/Time/194147-Time2.ps 
> 
>http://txpc6.fnal.gov/~slee/objmon/summ/194147.summ 
> 
>Histogram reference file was: 
> 
>/data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
> 
>     
</pre>
<!-- Author: peter -->
<!-- Comment: Tue Mar 22 13;22;17 comment by...peter -->
<pre>From the elog: 
http://www-cdfonline.fnal.gov/cgi-bin/elog.pl?nb=2005&action=copyentry&page=239&time=08:43:42.680


http://fcdfhome.fnal.gov/usr/wagnp/pedestals_195591.eps . You see that you see nothing, i.e. it is not a connection problem.

ObjectMon makes an entry=0 (=blank box) if either numerator or denominator is 0. Since in the CEM we take the sqrt, we see both denominators=0, which makes both PMTs blank. This will be fixed in the next ObjetMon version.

I made an entry in the bad channels log http://txpc6.fnal.gov/~wagnp/EMTiming_badchannels/ . See "Current log file."


peter

</pre>


<!-- Date: Wed Mar 30 08:48:57 2005 -->
<pre>Run 195758 with 162397 processed events 
> > 
> >There were red histograms with names: 
> >    t0RawPEM 
> >    t0RawCHA 
> >    t0RawPHA 
> > 
> >Bad/Improved channels summary: 
> > 
> >wedge rapd Failures: 100%  Multi+LowW MultiOk Fake  Change Status 
> >1     5              11/00 0/0        0/0     0/0   New Problem 
> >13    16             10/10 0/0        1/1     0/0    
> >19    10             00/00 0/0        0/0     1/0   New Problem 
> >19    11             00/00 0/0        0/0     1/0   New Problem 
> >19    12             00/00 0/0        0/0     1/0   New Problem 
> >19    13             00/00 0/0        0/0     1/0   New Problem 
> >19    14             00/00 0/0        0/0     1/0   New Problem 
> >19    15             00/00 0/0        0/0     1/0   New Problem 
> >19    16             00/00 0/0        0/0     1/0   New Problem 
> >19    17             00/00 0/0        0/0     1/0   New Problem 
> >20    10             00/00 0/0        0/0     1/0   New Problem 
> >20    11             00/00 0/0        0/0     1/0   New Problem 
> >20    12             00/00 0/0        0/0     1/0   New Problem 
> >20    13             00/00 0/0        0/0     1/0   New Problem 
> >20    14             00/00 0/0        0/0     1/0   New Problem 
> >20    15             00/00 0/0        0/0     1/0   New Problem 
> >20    16             00/00 0/0        0/0     1/0   New Problem 
> >20    17             00/00 0/0        0/0     1/0   New Problem 
> >21    10             00/00 0/0        0/0     1/0   New Problem 
> >21    11             00/00 0/0        0/0     1/0   New Problem 
> >21    12             00/00 0/0        0/0     1/0   New Problem 
> >21    13             00/00 0/0        0/0     1/0   New Problem 
> >21    14             00/00 0/0        0/0     1/0   New Problem 
> >21    15             00/00 0/0        0/0     1/0   New Problem 
> >21    16             00/00 0/0        0/0     1/0   New Problem 
> >21    17             00/00 0/0        0/0     1/0   New Problem 
> >22    10             00/00 0/0        0/0     1/0   New Problem 
> >22    11             00/00 0/0        0/0     1/0   New Problem 
> >22    12             00/00 0/0        0/0     1/0   New Problem 
> >22    13             00/00 0/0        0/0     1/0   New Problem 
> >22    14             00/00 0/0        0/0     1/0   New Problem 
> >22    15             00/00 0/0        0/0     1/0   New Problem 
> >22    16             00/00 0/0        0/0     1/0   New Problem 
> >22    17             00/00 0/0        0/0     1/0   New Problem 
> > 
> >Objectmon results for current run (may be not ready immediately): 
> >http://txpc6.fnal.gov/~slee/objmon/Time/195758-Time2.ps 
> >http://txpc6.fnal.gov/~slee/objmon/summ/195758.summ 
> >Objectmon results for bad channels reference run: 
> >http://txpc6.fnal.gov/~slee/objmon/Time/194147-Time2.ps 
> >http://txpc6.fnal.gov/~slee/objmon/summ/194147.summ 
> >Histogram reference file was: 
> >/data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
> > 
> > </pre>
<!-- Author: peter -->
<!-- Comment: Wed Mar 30 08;50;27 comment by...peter -->
<pre>See http://www-cdfonline.fnal.gov/cgi-bin/elog.pl?nb=2005&action=copyentry&page=257&time=09:12:15.400. 
The L1 trigger expert says that it was a case of bad readout which disappeared after shepherding that crate. no emtiming issue...

</pre>


<!-- Date: Thu Mar 31 00:19:33 2005 -->
<pre> 
Wed Mar 30 11:42:49 On controlled access this we replaced the base for 5R01E CEM. This seemed to fix the dead tube problem. Observed 60pA dark current. The LED and Xenon flasher runs both show the tube to be alive. Will check YMon with real data when we have a store. - Bob Wagner (ANL) 
-- Wed Mar 30 11:57:05 comment by...Steve Hahn --  Also, HV is now just fine (as opposed to floating to the max possible voltage before we swapped the PMT base). 
 
 
</pre>
<!-- Author: peter -->
<!-- Comment: Thu Mar 31 00;19;58 comment by...peter -->
<pre>We just start to taking data. I'm looking at the ObjectMon 
EMTDC canvas now, and the problematic guy (tower 5/wedge 1) 
is gone now. Hope this helps. -Sungwon</pre>


<!-- Date: Mon May 2 13:24:55 2005 -->
<pre>-----Original Message----- 
> From: Max [mailto:maxi@fnal.gov] 
> Sent: Tuesday, April 19, 2005 8:01 AM 
> To: David Toback 
> Cc: 'Peter Wagner' 
> Subject: Re: ObjectMon 
>  
>  
[...] 
>  
> For other things: around 3 weeks ago new CALDIGI... (tables that 
> translate analog ADMEM signal into ADC counts) were loaded, so new 
> reference hists need to be changed. 
>  
> --Max</pre>
<!-- Author: peter -->


<!-- Date: Wed May 11 14:33:30 2005 -->
<pre>-----Original Message----- 
> From: Sung-Won Lee [mailto:slee@fnal.gov] 
> Sent: Tuesday, May 10, 2005 10:54 AM 
> To: David Toback 
> Cc: 'David Toback'; maxi@fnal.gov; toback@fnal.gov; wagnp@fnal.gov 
> Subject: RE: TimeMonitor Notification for run 197657 
>  
>  
>   Hi Dave, 
>  
> It seems to me that a sizable clock shift happended after supervised 
> access on last thursday. I don't know whether this is a coincidence. 
>  
> Another high statistics runs (since run 197657) is available now; 
> run 197716!! 
>  
> Cheers, Sungwon 
>  
>  
>> > 
> 
> > -----Original Message----- 
> > From: David Toback [mailto:toback@physics.tamu.edu] 
> > Sent: Monday, May 09, 2005 1:13 PM 
> > To: maxi@fnal.gov; toback@fnal.gov; slee@fnal.gov; wagnp@fnal.gov 
> > Subject: RE: TimeMonitor Notification for run 197657 
> > 
> > Hi, 
> > 
> > 	Was there a clock shift? Can anyone tell? 
> > 
> > 	I took a look at the plots and it appears that <20,14> had a low 
> > threshold (although the summary file says 5.1, the plot shows it around 18 
> > which doesn't make sense to me given the correction factors) and low 
> > plateau 
> > efficiency (0.6). 
> > 
> > 	Could someone take a look at this? Make a comment in the log book? 
> > 
> > 	No high statistics runs since then. 
> > 
> >                                             Dave 
> > 
> > >> 
> > > -----Original Message----- 
> > > From: Data Acquisition [mailto:cdfdaq@b0dap82.fnal.gov] 
> > > Sent: Sunday, May 08, 2005 9:51 AM 
> > > To: khotilov@fcdfsgi2.fnal.gov; maxi@fnal.gov; toback@fnal.gov; 
> > > slee@fnal.gov; wagnp@fnal.gov 
> > > Subject: TimeMonitor Notification for run 197657 
> > > 
> > > Run 197657 with 185405 processed events 
> > > 
> > > There were red histograms with names: 
> > >     t0CEM 
> > >     t0PEM 
> > >     t0CHA 
> > >     t0PHA 
> > >     t0WHA 
> > > 
> > > Bad/Improved channels summary: 
> > > 
> > > wedge rapd Failures: 100%    Eff.  Thr.  Sigma  CorrT  CRMS Multi+LowW 
 
> > > MultiOk Fake  Change Status 
> > > 13    16             10/10   1/1   1/1   0/0    1/1    0/1   0/0 
> > > 0/0     0/0   New Problem 
> > > 20    14             00/00   1/0   1/0   0/0    0/0    0/0   0/0 
> > > 0/0     0/0   New Problem 
> > > 
> > > Objectmon results for current run (may be not ready immediately): 
> > > http://txpc6.fnal.gov/~slee/objmon/Time/197657aa-Time2.ps 
> > > http://txpc6.fnal.gov/~slee/objmon/summ/197657.summ 
> > > Objectmon results for bad channels reference run: 
> > > http://txpc6.fnal.gov/~slee/objmon/Time/196969-Time2.ps 
> > > http://txpc6.fnal.gov/~slee/objmon/summ/196969.summ 
> > > Histogram reference file was: 
> > > /data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
> 
</pre>
<!-- Author: peter -->


<!-- Date: Fri Jun 10 10:19:30 2005 -->
<pre>Hi, 
 
        I took a look at http://txpc6.fnal.gov/~slee/emtiming/  (which seems 
to be broken somehow...) and I only see a few runs which were large enough 
to have large statistics in ObjectMon. 
 
 
199061 had 956 nb, but only 95K events 
199143 had 1266 nb, but only 88K events 
199146 had 838 nb, but only 86K events 
199148 had 665 nb, but only 81K events 
 
         All showed the clock shift problem, but because they didn't have 
100K events we didn't get email. Is there a way to get more events into 
ObjectMon? 
 
        Also, Peter is looking at putting clock-shift offset into the 
ObjectMon tcl file so we can do this by hand rather than having to change 
reference histograms. 
 
        Will someone put something about all this into the log book? The 
last entry I see is from mid May, also about clock shifts. 
 
        Please find out if Eric is the right person. If so, then perhaps we 
should add him to our mailing list if we see clock shifts. 
 
                                     Dave 
 
 
> -----Original Message----- 
> From: Sung-Won Lee [mailto:slee@fnal.gov] 
> Sent: Thursday, June 09, 2005 6:50 PM 
> To: David Toback 
> Cc: 'Vadim Khotilovich'; toback@fnal.gov; 'Peter Wagner'; 'Slava 
> Krutelyov'; kamon@fnal.gov 
> Subject: RE: Timing shift 
> 
> 
>   Thanks Dave for the comments. 
> 
> > I'm not sure what you are saying. The monitoring is working perfectly 
> here. 
> > I see an email sent to you about this problem (in CEM, CHA and WHA) on 
> > Tuesday. I can resend if you like... 
> 
> Sorry, it wasn't clear.  Yes, TimeMonitor Notification is working for 
> run 199042 . Since run 199042 most of runs (17 runs after run 199042) has 
> a timing shift problem. My point is that we need to keep eye on such 
> problems and to do some action as quickly as possible, eg. reference 
> histo. By the way, we got TimeMonitor Notification e-mail after run 
> 199042? 
> 
> > Yes! I'm guessing that if there is an overall shift in both EM and HAD 
> then 
> > this is a clock/TDC shift. Is there someone we should send mail to? I'm 
> > happy to do it whenever we see such a shift in multiple systems. 
> 
> Eric?  I will check it out. 
> 
> -Sungwon 
> 
 
</pre>
<!-- Author: peter -->


<!-- Date: Fri Jun 10 10:20:57 2005 -->
<pre>> 
> Max has updated the calibration tables to account for the change 
> in the CALDIGI 
> table. 
> I talked to Vadim already a couple of weeks ago about updating 
> ObjectMon. anyways... I updated the tcl file now. So, it should 
> look better starting 
> next run. 
> 
> 
> peter 
> 
</pre>
<!-- Author: peter -->


<!-- Date: Mon Jun 13 10:01:40 2005 -->
<pre>> 
> On Fri, Jun 10, 2005 at 01:11:08PM -0500, Willis Sakumoto wrote: 
> > Hi Peter: 
> >    Look here: 
> > 
> > http://www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=calibdb 
> > 
> > for alll calibration db stuff. The CalDigiToGeV change occured on 
> > 18Mar05, and affects runs > 195428. 
> >                                                   -- Willis 
> > 
> > On Fri, 10 Jun 2005, Peter Wagner wrote: 
> > 
> > > Hi Willis, 
> > > 
> > > can you tell me at which date or at which runnumber the  
> > > CALDIGI table was changed? 
> > > It seems to have been some time around mid-April. Has it  
> > > been changed again since then? 
> > > 
> > > Thanks, 
> > > peter 
</pre>
<!-- Author: peter -->


<!-- Date: Wed Jun 22 10:23:16 2005 -->
<pre>Run 199725 with 263511 processed events 
 
Bad/Improved channels summary: 
 
wedge rapd Failures: 100%    Eff.  Thr.  Sigma  CorrT  CRMS  Multi+LowW MultiOk Fake  Change Stat\us 
16    14             00/00   1/0   0/0   0/0    0/0    0/0   0/0        0/0     0/0   New Problem 
 
Objectmon results for current run (may be not ready immediately): 
http://txpc6.fnal.gov/~slee/emtiming/root2/199725-Time2.ps 
http://txpc6.fnal.gov/~slee/emtiming/root2/summ/199725.summ 
Objectmon results for bad channels reference run: 
http://txpc6.fnal.gov/~slee/emtiming/root2/Time/196969-Time2.ps 
http://txpc6.fnal.gov/~slee/emtiming/root2/summ/196969.summ 
Histogram reference file was: 
/data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
 
</pre>
<!-- Author: peter -->


<!-- Date: Fri Jul 1 15:42:28 2005 -->
<pre>Hi, 
 
	This is interesting... I see the problem with <8,-15> in the Eff 
above 3.00 GeV plot. It's there also on the fit plateau plot, but this isn't 
reported... The threshold looks fine. Can we make the eff turn on curve?  
 
<12,-11> doesn't look too bad on the plateau, but is low. It isn't on the 
Eff above 3.00 GeV plot. The threshold looks fine.  
 
	Can we run the new ObjectMon on this run? 
 
	Peter: Can you put this in the log book? Thanks, 
 
                                     Dave 
 
******************************************************** 
David Toback 
Assistant Professor of Physics 
Texas A&M University 
CDF Collaboration 
toback@tamu.edu 
979-845-1179 
********************************************************  
 
 
>> -----Original Message----- 
>> From: Data Acquisition [mailto:cdfdaq@b0dap82.fnal.gov] 
>> Sent: Friday, July 01, 2005 4:54 AM 
>> To: khotilov@fcdfsgi2.fnal.gov; maxi@fnal.gov; toback@fnal.gov; 
>> slee@fnal.gov; wagnp@fnal.gov 
>> Subject: TimeMonitor Notification for run 200284 
>>  
>> Run 200284 with 105945 processed events 
>>  
>> There were red histograms with names: 
>>     t0CEM 
>>     t0PEM 
>>     t0CHA 
>>     t0PHA 
>>     t0WHA 
>>  
>> Bad/Improved channels summary: 
>>  
>> wedge rapd Failures: 100%    Eff.  Thr.  Sigma  CorrT  CRMS  Multi+LowW 
>> MultiOk Fake  Change Status 
>> 8     -15            01/00   0/0   0/0   0/0    0/0    0/0   0/0 
>> 0/0     0/0   New Problem 
>> 12    -11            00/00   1/0   0/0   0/0    0/0    0/0   0/0 
>> 0/0     0/0   New Problem 
>> 13    16             10/10   1/1   1/1   0/0    1/1    1/1   0/0 
>> 0/0     0/0 
>>  
>> Objectmon results for current run (may be not ready immediately): 
>> http://txpc6.fnal.gov/~slee/emtiming/root2/200284-Time2.ps 
>> http://txpc6.fnal.gov/~slee/emtiming/root2/summ/200284.summ 
>> Objectmon results for bad channels reference run: 
>> http://txpc6.fnal.gov/~slee/emtiming/root2/Time/196969-Time2.ps 
>> http://txpc6.fnal.gov/~slee/emtiming/root2/summ/196969.summ 
>> Histogram reference file was: 
>> /data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
</pre>
<!-- Author: peter -->


<!-- Date: Tue Jul 5 13:06:00 2005 -->
<pre>Hi, 
 
        It looks like <8,-15> has a dead line. This is the second big run 
we've seen with this problem. From http://txpc6.fnal.gov/~slee/emtiming/ it 
200236 has some good first indications that things are broken, but the 
statistics are low. 200231 looks fine. 
 
        Max and Peter: Take a closer look? We should probably put this in 
our access request list. Also, put a note in the log book and update the 
calibrations tables. 
 
                                     Dave 
 
******************************************************** 
David Toback 
Assistant Professor of Physics 
Texas A&M University 
CDF Collaboration 
toback@tamu.edu 
979-845-1179 
******************************************************** 
 
> -----Original Message----- 
> From: Data Acquisition [mailto:cdfdaq@b0dap82.fnal.gov] 
> Sent: Saturday, July 02, 2005 2:53 PM 
> To: khotilov@fcdfsgi2.fnal.gov; maxi@fnal.gov; toback@fnal.gov; 
> slee@fnal.gov; wagnp@fnal.gov 
> Subject: TimeMonitor Notification for run 200309 
> 
> Run 200309 with 278520 processed events 
> 
> There were red histograms with names: 
>     t0CEM 
>     t0PEM 
>     t0PHA 
> 
> Bad/Improved channels summary: 
> 
> wedge rapd Failures: 100%    Eff.  Thr.  Sigma  CorrT  CRMS  Multi+LowW 
> MultiOk Fake  Change Status 
> 8     -15            01/00   0/0   0/0   0/0    0/0    0/0   0/0 
> 0/0     1/0   New Problem 
> 13    16             10/10   1/1   1/1   0/0    1/1    1/1   0/0 
> 0/0     0/0 
> 
> Objectmon results for current run (may be not ready immediately): 
> http://txpc6.fnal.gov/~slee/emtiming/root2/200309-Time2.ps 
> http://txpc6.fnal.gov/~slee/emtiming/root2/summ/200309.summ 
> Objectmon results for bad channels reference run: 
> http://txpc6.fnal.gov/~slee/emtiming/root2/Time/196969-Time2.ps 
> http://txpc6.fnal.gov/~slee/emtiming/root2/summ/196969.summ 
> Histogram reference file was: 
> /data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
</pre>
<!-- Author: peter -->


<!-- Date: Mon Jul 11 12:21:08 2005 -->
<pre>- bad channels log is updated. First run with this channel bad seems to be 200236 (200231 looks fine). The problems is not fixed as of now. 
 
 
>> -----Original Message----- 
>> From: Willis Sakumoto [mailto:willis@fnal.gov] 
>> Sent: Monday, July 11, 2005 11:43 AM 
>> To: Peter Wagner 
>> Cc: maxi@fnal.gov; toback@fnal.gov; Mark Mattson; slava77@fnal.gov 
>> Subject: Re: plug channel 
>>  
>> Hi Peter: 
>>    The cafe card for this PEM PMT was replaced on 4 July 2005. The 
>> new cafe card also had a problem: it was effectively dead. We 
>> replaced it, again, today. 
>>                                                      -- Willis 
>> On Mon, 11 Jul 2005, Peter Wagner wrote: 
>>  
> 
>>> > Interesting is also that in all recent runs (>200536 , date: 07/05) 
>>> > Objectmon does not show any recorded energy for this PMT. I couldn't 
>>> > find anything about this on the calorimeter pages/logs exept Max's entry 
>>> > below which explains it until July 4th... would be strange if it is an 
>>> > Objectmon problem... 
>>> > 
>>> > cheers, 
>>> > peter 
>>> > 
>>> > 
>>> > 
>>> > Max wrote: 
>>> > 
>> 
>>>> > > Hi All, 
>>>> > > 
>>>> > > just to wanted to convey to you following information: 
>>>> > > 
>>>> > > from EMTiming system we see recently one strange channel in plug: 
>>>> > > 0(west)-8-15 - one of the pmts has less than hundred efficiency, 
>>>> > > otherwise it looks completely normal, something that I have never seen 
>>>> > > before. 
>>>> > > 
>>>> > >  After talking to Willis I realized that the problem might come from 
>>>> > > the ADMEM readout - meaning that there seems to be lots of energy, but 
>>>> > > in reality there is nothing physically in the tower. 
>>>> > > 
>>>> > >  Willis pointed me to the web page and here it is (entry from Mark 
>>>> > > Mattson) that explains everything. May be in ObjectMon we can figure 
>>>> > > out channels like that and have e-mail send to Mark and other 
>>>> > > calorimeter experts? What do you think? 
>>>> > > 
>>>> > > 
>>>> > > 81. 30 Jun - 04 Jul 2005 
>>>> > >      a) PEM 08W-15.1: hot - ADMEM Cafe card problem. Some of the CAPs 
>>>> > >         were affected, so this tower is not hot all the time and it 
>>>> > >         was only hot if with energy in the tower. Trigger tower was 
>>>> > >         masked off. The Cafe card was replaced and trigger tower 
>>>> > > unmasked. 
>>>> > >         Runs: 200064-200484 
>> 
>>> > 
>>> > 
>>> > 
</pre>
<!-- Author: peter -->


<!-- Date: Fri Jul 22 15:22:56 2005 -->
<pre>Hi, 
 
This file is now on the web page so I took a look. Basically, there is nothing new here: 
 
1) LOTS of OOT channels, but this is a known problem and Max and Peter are working on it. Since we can't reproduce it offline, we really need to get the new executable in online so we can get more information into the log files. 
 
Vadim: What's the status of this??? 
 
2) The other problem is three channels fail the multiOK. Two of them barely fail the 0.005 threshold which is clearly too tight. I thought this was going to be raised to 0.01.  <9,17> is clearly different than the others and should be watched. 
 
Peter: What's happening with changing the threshold? 
 
3) <13,16> is still problematic... duh. 
 
Peter: Would you put something about this into the logbook? I don't see any entries on the topic. 
 
Thoughts? 
 
                                     Dave 
 
******************************************************** 
David Toback 
Assistant Professor of Physics 
Texas A&M University 
CDF Collaboration 
toback@tamu.edu 
979-845-1179 
********************************************************=20 
 
> -----Original Message----- 
> From: Data Acquisition [mailto:cdfdaq@b0dap82.fnal.gov] 
> Sent: Friday, July 22, 2005 6:50 AM 
> To: khotilov@fcdfsgi2.fnal.gov; maxi@fnal.gov; toback@fnal.gov; 
> slee@fnal.gov; wagnp@fnal.gov 
> Subject: TimeMonitor Notification for run 201543 
> 
> Run 201543 with 107715 processed events 
> 
> Bad/Improved channels summary: 
> 
> wedge rapd Failures: 100%    Eff.  Thr.  Sigma  CorrT  CRMS LowW 
> MultiOk Fake OOT  Change Status 
> 0     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 0     0              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 1     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 1     -1             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 1     0              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 1     9              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 2     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 2     -0             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 2     0              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 2     1              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 3     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 5     0              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 6     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 7     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 8     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 8     -0             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 8     0              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 8     9              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 9     -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 9     0              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 9     17             00/00   0/0   0/0   0/0    0/0    0/0   0/0   1/0 
> 0/0   0/0   New Problem 
> 10    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 11    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 12    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 13    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 13    16             11/10   0/1   1/1   0/0    0/1    1/1   0/0   1/0 
> 0/0   0/0   New Problem 
> 14    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 14    -8             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 14    9              00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 15    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 18    -17            00/00   0/0   0/0   0/0    0/0    0/0   0/0   1/0 
> 0/0   0/0   New Problem 
> 21    -17            00/00   0/0   0/0   0/0    0/0    0/0   0/0   1/0 
> 0/0   0/0   New Problem 
> 21    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 21    -8             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 21    -7             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 21    -5             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 21    -0             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 22    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 23    -9             00/00   0/0   0/0   0/0    0/0    0/0   0/0   0/0 
> 0/0   1/0   New Problem 
> 
> Objectmon results for current run (may be not ready immediately): 
> http://txpc6.fnal.gov/~slee/emtiming/root2/201543aa-Time2.ps 
> http://txpc6.fnal.gov/~slee/emtiming/root2/summ/201543aa.summ 
> Objectmon results for bad channels reference run: 
> http://txpc6.fnal.gov/~slee/emtiming/root2/Time/196969aa-Time2.ps 
> http://txpc6.fnal.gov/~slee/emtiming/root2/summ/196969aa.summ 
> Histogram reference file was: 
> /data1/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
 
 
</pre>
<!-- Author: Peter -->


<!-- Date: Tue Jul 26 22:30:59 2005 -->
<pre>----- Original Message ----- 
From: Peter Wagner <wagnp@fnal.gov> 
Date: Monday, July 25, 2005 5:18 pm 
Subject: Re: prev cvs tag 
 
> The new tag for the CalorTimeMods version in CVS before my changes 
> is 
> maxi_25Jul2005. 
> 
> peter 
> 
> 
> 
> maxi@fnal.gov wrote: 
> 
> >This is what I sent to myself on how the previous tag was created. 
> > 
> >relwrite 
> >cvs tag -r HEAD tagname directory 
> > 
> >--Max 
> > 
</pre>
<!-- Author: peter -->
<!-- Comment: Tue Jul 26 22;31;42 comment by...peter -->
<pre>The above concerns the Timing MonteCarlo code...
</pre>


<!-- Date: Tue Aug 16 11:47:04 2005 -->
<pre>Date: Sat, 13 Aug 2005 17:08:53 -0500 
From: Peter <wagnp@tamu.edu> 
To: Sung-Won Lee <slee@fnal.gov> 
Cc: Maxim Goncharov <maxi@fnal.gov>, Slava Krutelyov <slava77@fnal.gov>, Vadim Khotilovich <vkhotilovich@physics.tamu.edu> 
Subject: Re: objectmon: back in the normal life 
 
I fixed the timing page now as much as possible. also, I changed the 
corrected time shifts in the tcl: 
# CEM, PEM, CHA, PHA, WHA: 
    shiftCorrTime set 2. 1.31 1.92 1.16 2.05 
--> 
    shiftCorrTime set 1.4 0.8 1.52 1.7 2.05 
 
peter 
</pre>
<!-- Author: Sungwon -->


<!-- Date: Tue Aug 16 11:52:20 2005 -->
3 hrs cosmic dataset for emtiming is available. run number is <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=202855">202855  </a>. please take a look at them. prelimary monitoring plots is also available from <a href="http://txpc6.fnal.gov/~slee/objmon/">online objectmon page</a>. 
<!-- Author: sungwon -->


<!-- Date: Sat Aug 27 11:58:53 2005 -->
Runs <a href="http://txpc6.fnal.gov/~slee/emtiming/root2/203055aa-Time2.ps">203055</a> and <a href="http://txpc6.fnal.gov/~slee/emtiming/root2/202973aa-Time2.ps">202973</a> show <21,-17> and <9,17> as bad channels. Efficiency, threshold and width are OK, but there is slight excess in "Multiple OK Firings" just above the alarming threshold (rates: 0.11 and 0.12 respect.) and an excess in OOT hits (~80 hits) for <9,17> - but the rate (0.021) is below the alarming threshold of 0.04.
<!-- Author: peter -->
<!-- Comment: Sat Aug 27 12;04;58 comment by...peter -->
<pre>As for the diagnosis: Since there doesn't seem to be a problem with the turn-on curve it might be a bad (too low) resistance which causes double firings. </pre>


<!-- Comment: Wed Sep 21 10;54;54 comment by...peter -->
<pre>In fact 9,17 shows MultOk Firings ever since at least run 202739.
</pre>
<!-- Date: Wed Sep 21 10:35:35 2005 -->
<pre>See http://txpc6.fnal.gov/~slee/emtiming/root2/204257aa.summ: 
 
Corrected time shift for detectors CEM,PEM,CHA,PHA,WHA: 1.4 , 0.8 , 1.4 , 0.6 , 1.55 
wedge rapd Failures: 100%    Eff.  Thr.  Sigma  CorrT  CRMS  LowW MultiOk Fake OOT  Change Status 
------  Values: Eff.PMT0/1  FitEff sgm(thr) sgm(w) sgm(corT0Mean) sgm(corT0RMS) nFirLW nMultFr nFakes nOOT 
 
4     -15            00/00   0/0   1/0   0/0    0/0    0/0   0/0   0/0     0/0   0/0   New Problem 
------  Values: 1.002/1.001 1.000  23.834   82.272 0.087          0.781         0.000 0.000 0.000 0.001 
 
9     17             00/00   0/0   0/0   0/0    0/0    0/0   0/0   1/0     0/0   0/0   New Problem 
------  Values: 1.004/1.003 1.000  1.914    0.228  1.377          0.908         0.000 0.016 0.000 0.020 
 
13    16             11/11   0/0   1/1   0/0    0/0    1/1   0/0   1/1     0/0   0/0   Known Problem 
------  Values: 0.000/0.000 0.970  36.609   78.992 0.385          10.625        0.000 0.116 0.000 0.000 
 
Looking at the objectmon plots: 20,-15, 17,-15, 11,-17 and 4,-15 seem to be new problems for the threshold. 
Offline I cannot reproduce any of these problems (See plots below) 
 
</pre>
<!-- Author: peter -->


<!-- Date: Wed Sep 21 10:46:51 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-36&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-36' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-37&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-37' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-38&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-38' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-39&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-39' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-40&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-40' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-41&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-41' width='300'></a></center>
<!-- Author: offline plots of bad channels as reported in run 204257; peter -->



<!-- Date: Wed Oct 19 10:55:51 2005 -->
<pre>Run 205640 with 143146 processed events 
 
Bad/Improved channels summary: 
 
wedge rapd Failures: 100%    Eff.  Thr.  Sigma  CorrT  CRMS  LowW    MultiOk Fake OOT  Change Status 
9     17             00/00   00/00   00/00   00/00    0/0    0/0   0/0   1/0     0/0   0/0   New Problem 
11    2              01/00   00/00   00/00   00/00    1/0    0/0   0/0   0/0     0/0   0/0   New Problem 
13    16             11/11   00/00   10/10   00/00    0/0    1/1   0/0   1/1     0/0   0/0   Known Problem 
21    -17            00/00   00/00   00/00   00/00    0/0    0/0   0/0   1/0     0/0   0/0   New Problem 
 
--------------------------------------------------- 
 
ObjectMon looks fine to me as is. In particular the histograms turn red in the correct way... slide 3 shows the right picture b/c there are indeed no hits at high PMT energy in 13,16. 
As for the OOT hits, I still have no printout because the code was not updated last week... 
 
The turn-on curves are only printed if there is a problem with the fit parameters, i.e. if sth is wrong on slides 4,5 or 6. 
From the plots this is my guess on 11,2: 
slide 3 shows plainly that there is no hit recorded with energy > 6.25 GeV. Slides 4-6 show that there are hits below this energy and the turn-on curve of this channel looks fine. Slide 9 shows that the corrected mean is off. Combined with the OK rms in slide 10 and the missing entries in 11 shows that the slewing correction is not applied correctly because of a too large 
asymmetry between the 2 PMTs. So, from this run I'd think there is sth broken in the AdMEM line coming from PMT 1_11_2_1. Now, looking at the CEM PMT occupancy canvas of any recent run 
http://www-cdfonline.fnal.gov/~cdfdoc/Consumers/LatestConsumerSlides/yco_205720_03_cempmt.gif I see a blank box at this channel... 
 
 
</pre>
<!-- Author: peter -->


<!-- Date: Fri Nov 11 15:51:03 2005 -->
<pre>-----Original Message----- 
From: Peter Wagner [mailto:wagnp@fnal.gov] 
Sent: Friday, November 11, 2005 1:41 PM 
To: Max Goncharov 
Cc: David Toback 
Subject: channel <0,9> 
 
  
 
Hi Max, 
 
It seems that the slewing calibration tables might be doing strange things for the last couple of runs...  the corrected mean is about 2ns off with a good RMS, a good turn-on curve and a good mean raw time. 
please check if the calibration tables are right for CEM channel <0,9>? 
 
thanks, 
peter 
</pre>
<!-- Author: peter -->


<!-- Date: Thu Dec 8 13:56:11 2005 -->
There has been a large number of out of time (OOT) hits in CEM and, mostly, PEM towers in many recent high-luminosity runs, e.g. runs <a href="http://txpc6.fnal.gov/~wagnp/emtiming/root2/206989aa-Time2.ps">206989</a> and <a href="http://txpc6.fnal.gov/~wagnp/emtiming/root2/207080aa-Time2.ps">207080</a>; p11 shows the number of hits, p15 the fraction of OOT hits per tower (~2-4%). The hits are mostly clustered and occur in a broad range of events. For the log file with energy, time and tower number for each hit for run 206989 see <a href="http://txpc1.fnal.gov/wagnp/ObjectMon_plots/OOT/ObjectMon_206989_001.log">here</a> and <a href="http://txpc1.fnal.gov/wagnp/ObjectMon_plots/OOT/ObjectMon_206989_002.log">here</a>. Comparing the log file from an offline ObjectMon run by eye with the online log file I notice that all hits pass bstream triggers. 
 
<a href="http://txpc1.fnal.gov/wagnp/ObjectMon_plots/OOT/hits_time_2466.eps">Here</a> is a plot of OOT hits of PEM channel 1_6_17 in run 207080. 
 

<!-- Author: peter -->


<!-- Comment: Thu Dec  8 13;58;46 comment by...peter -->
<pre>from Dave's mail:


I propose two steps:

1) Pick a single tower in tower 17 and plot the corrected time and allow the
x-axis to go from -20 -> 100 (or whatever) and make it in log scale. Put arrows
to indicate the satellites on both sides of the main peak. Show this to Willis,
Pat Lukens and Rob Roser. I don't know if this will surprise them or if there
is anything we can do about it, but my guess its worth documenting. Either way,
we should start to monitor for satellite rate. The number they will ask you for
is is what fraction of events have a satellite in the plot you are showing. You
should get this number before showing them the plot.

2) We should start monitoring for satellites. This is really an ObjectMon task
and not an EMTiming Monitoring task. I think the right quantity of interest is
fraction of events with satellites. I think I would define the denominator as
being any event. I would define the numerator as being an event in which ANY of
the towers has a satellite hit (i.e., don't count number of satellite hits per
event, just set a flag if there is a satellite hit). I would define a satellite
hit as being any event that has one or more hits with 0 < abs(|t|-18) <6. This
covers the dominant two satellite bunches (the one before and the one after the
main bunch). We should plot satellite rate vs. something. I just don't know what
the something should be. Luminosity maybe? Rate for the last 1000 events
observed? We should think about this.

Thoughts anyone?

Dave


</pre>


<!-- Date: Mon Jan 2 14:14:32 2006 -->
<pre>Since runnumber 209262 channel (11,-9) has a too large mean corr. t0. (~4.5 in run 209262 and ~2.6 in run 209265) while the t0 RMS is just within good limits (<2.5). In run 209265 the threshold is with ~45 twice as high as normal (~20-25), the threshold width ~ 8x as high as normal (~0.7). No excess in the Out Of Time hits. 
Turn-on curves are e.g. at http://txpc6.fnal.gov/~wagnp/emtiming/root2/209373aa-Time2.ps. 
(I can't find anything about this in the cdf-log or the calorimeter log.) 
Maybe a broken PMT? 
</pre>
<!-- Author: peter -->


<!-- Date: Wed Jan 4 10:06:01 2006 -->
<pre>I am not sure what's going on with the one PMT in <11,2> starting around run 209489. The (2-PMT) turn-on curve looks fine (width and threshold is comparable with other channels). It is only that one PMT has no time measurements at high energy and the corrected time is shifted by +5ns. Maybe something is wrong with the energy measurement? (in particular because of the shift in the corrected time) 
</pre>
<!-- Author: peter -->
<!-- Comment: Tue Jan 10 16;47;39 comment by...peter -->
<pre>This tube is behaving badly since New Year (died, I think). Bob Wagner replaced the PMT base on Tue Jan 3. 
</pre>


<!-- Date: Mon Jan 30 18:04:56 2006 -->
<pre>Summary of access on 01/20/06 for channel 0_11_9_0: 
 
Turn-on curves available here (plotted as a function of energy of each PMT): 
http://txpc6.fnal.gov/%7Emaxi/EMTiming/Calibrations/Validation/Problems/0119_mpt1_bro_effic.eps 
http://txpc6.fnal.gov/%7Emaxi/EMTiming/Calibrations/Validation/Problems/0119_mpt2_bro_effic.eps 
 
PMT1 shows a slower turn-on curve (~7 times as large as PMT2) with a good threshold position, which indicates that there is problem on the ASD side somewhere between splitter and ASD board. 
It was decided that one should try unplugging and replugging the offending lemo in the TB. As no one in the group had met shift requirements, Steve Hahn did the repair. With Steve's help we took two test LED runs on Monday (RunType /Private/Maxi/MAXI_CEMLED) with only one PMT in this tower at full HV for each run. For the problematic PMT no timing hits were recorded when the HV for the other PMT was turned down which indicates that the channel has not been fixed. At that time the muon walls were closed to prepare for the new beam. 
 
We are on the access request list for the next shutdown. For now the plan is to unplug the problematic channel unless there is enough time to repair. 
 
</pre>
<!-- Author: peter -->
<!-- Comment: Tue Jan 31 23;25;06 comment by...peter -->
<pre>After looking into my notes again I notice that I probably confused the two PMT channels of 11,-9 which could be the reason for the unsuccessful access. Hopefully it works better next time...</pre>
<!-- Date: Tue Jan 31 10:33:19 2006 -->
<pre>From: Vadim Khotilovich [mailto:vkhotilovich@physics.tamu.edu] 
&gt; Sent: Monday, January 30, 2006 1:40 PM 
&gt; To: David Toback 
&gt; Cc: 'Peter Wagner'; maxi@fnal.gov 
&gt; Subject: Re: FW: TimeMonitor Notification for run 210914 
&gt;  
&gt; Steve Hahn was changing the clock delays last Saturday, and he posted the 
&gt; elog entry today in the morning. 
&gt;  
&gt; The new TimeMonitor is running from Jan25. 
&gt;  
&gt; Vadim 
&gt;  
&gt;  
&gt;  
&gt; </pre>
<!-- Author: peter -->



<!-- Date: Mon Mar 13 10:39:21 2006 -->
<pre>Access for channel 0_11_9_0 (right PMT) on Fri 03/10/06: 
I tested the channel with an oscilloscope on the TB side. Pulsing into the LEMO that goes to the splitter/PMT shows no problem. Pulsing into the TB shows an flaky, open connection. I plugged both 0_11_9-LEMOs into the next free upper TB channel (a test showed that this channel looks fine): TB Row #9 -&gt; #10 in slot 14 
 
The TDC board still has to be remapped for this.</pre>
<!-- Author: peter -->


<!-- Date: Mon Mar 27 15:37:44 2006 -->
<pre>We got 11 out of 12 modified EM TDC boards back (they did not finish one board yet: should be ready tomorrow). 
I've put them into the crate, reprogrammed and ran the tests. The results look fine.</pre>
<!-- Author: Vadim -->
<!-- Comment: Thu Apr  6 15;23;20 comment by...peter -->
<pre>I have reconnected the cables to the TDC on Friday as soon as all TDCs were put back in by Vadim.</pre>
<!-- Date: Wed Apr 5 18:02:27 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-42&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-42' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-43&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-43' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-44&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-44' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-45&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-45' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-46&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-46' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-48&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-48' width='300'></a></center>
<!-- Author: captions and explanations see below; peter -->
<!-- Comment: Wed Apr  5 18;03;30 comment by...peter -->
<pre>Checkout of the CEM channel repair 0_11_9_0:
(for the repair see http://www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=10:39:21 )

The turn-on curves from *before* the test are at http://www-cdfonline.fnal.gov/cgi-bin/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=18:04:56
After remapping the TDC board I took with Steve's help a CEM_LED run to test it (RunType /Private/Maxi/MAXI_CEMLED with 1000 evts) with only one PMT in this tower at full HV for each run. Runnumbers: 
214161 (icalir) for PMT0 disabled 
214164 (icalir) for PMT1 disabled 

Both channels work fine now. The results are shown above from timeMaker output. Here the captions:
1) Energy in ADC counts of PMT0 from the CEM_LED run 214161
2) Energy in ADC counts of PMT1 from the CEM_LED run 214161
3) Slewing corrected Time for LED run 214161. The LED fires at 2 times; this is the first set.
4) Slewing corrected Time for LED run 214161; second set.
5) Slewing corrected Time for LED run 214164; first set.
6) Slewing corrected Time for LED run 214164; second set.

Note that there is in fact energy coming from the "off" PMT, as it was not possible to completely turn off the voltage in the PMTs. However the energies are at the low end of the turn-on curve and the previous checkout showed no timing hits when the channel was still broken.
</pre>


<!-- Date: Thu Apr 6 15:20:18 2006 -->
<pre>Repair of PEM channel 1_13_16_0: 
 
On Tuesday Mike and I had an access to repair this channel. First I pulsed into the cable at the PMT box side towards the TB. There was a clear open end reflection about 70ns away which points to a TB problem. Then I pulsed into the channel on the TB side towards the PMT box; looked fine. When I pulsed towards the TB side, I noticed that the LEMO socket in the TB was loose, i.e. most probably not soldered correctly. (fyi: It took quite a long time (~2hrs), because (a) the problem was hard to find on the TB side for some reason; although there was a clear open end from the PMT side, things looked fine on the TB, unless one whiggles in the right way and (b) it is quite hard to unplug/replug the LEMOs out of the TB.) We pulled the board out and as it was decided that we fix the channel by soldering the socket, we brought it on Wednesday morning to Bob deMaat. I picked the board up this morning and tested it with a pulser (w/o ASD board) at the test stand. After that Max and I went down to the hall and put it back in, reconnected the LEMOs and tested it by pulsing from the PMT box side towards the TB. All channels looked fine. 
Thanks to Mike and Max who helped during the access. 
</pre>
<!-- Author: peter -->



<!-- Date: Thu Apr 20 18:07:21 2006 -->
<pre>When taking CEM_LED test runs wedge 20E shows up to be empty on efficiency plots; there is energy coming from the LEDs but there is no timing information. 
The mapping note tells me that there are 2 wedges going into the TB which both lead into the same connector. I checked the connector and checked if the mapping of the TDC channel IDs matches with the cabling at the TB/ASD board and it looks fine. Interestingly this TB is cabled differently than the others, but the difference is , as far as I can tell, correctly taken into account in the database. 
1) Vadim and I reloaded the FRAM of the TDC card and took a test run, same result (no timing info). 
2) We swapped cables and took a test. Now the other wedge (where the cable now leads to) shows up empty, in accordance with the different mapping of wedge 20: http://fcdfhome.fnal.gov/usr/wagnp/ObjectMon_plots/cem_timing_cableswap_11_1__10_1.eps (wedge 19 is empty because the TDC board is not mapped the same as the TDC board where wedge 20 usually goes in; wedge 14 is empty because that's where the cable of wedge 20 goes in) 
=&gt; The problem must be somewhere from PMT -&gt; TB -&gt; ASD -&gt; long cable 
3) we swapped 2 LEMO pairs on the TB side with another board: channel &lt;21,0&gt; -&gt; &lt;20,0&gt; , &lt;20,0&gt; -&gt; &lt;19,0&gt;. see http://fcdfhome.fnal.gov/usr/wagnp/ObjectMon_plots/cem_timing_LEMOcableswap_21_0__20_0___20_0__19_0.eps 
=&gt; there is a signal going into the TB of wedge 20. But there is no signal coming through the TB and ASD. 
For this run I also checked if the TDC connector is plugged in correctly. 
By the way, there is energy going through all channels: 
http://fcdfhome.fnal.gov/usr/wagnp/ObjectMon_plots/cem_energy_LEMOcableswap_21_0__20_0___20_0__19_0.eps 
4) I thought the timing window is too tight. The timing window of my plots is [-500,1000]ns. Here is a plot of the Em-Timing distribution (slewing corrected): 
http://fcdfhome.fnal.gov/usr/wagnp/ObjectMon_plots/cem_timing_allchannels.eps 
doesn't look suspicious. 
 
Tomorrow we will pulse into the TB and look at the output on the TDC side of wedge 20. If this doesn't tell more we might have to take the TB out... 
</pre>
<!-- Author: peter -->
<!-- Comment: Fri Apr 21 14;51;04 comment by...peter -->
<pre>The above issue turned out to be because I mistakenly swapped two TDC cables. </pre>


<!-- Date: Wed May 31 14:58:12 2006 -->
<pre>Test of PEM: 
 
The PEM has been tested using the run configuration Private/Maxi/MAXI_PLUGLASERFULL in run 216868.  
 
The timing efficiency at high energy 
http://txpc1.fnal.gov/wagnp/ObjectMon_plots/currentproblems/pem_timingeff_allchannels_highenergy.eps 
shows that there are no major problems; all towers (combined to one timing channel) are working. 
 
And here the "threshold": 
Note that the typical threshold is around 150-200 ADC counts. 
The max. ADC counts for no timing hit 
http://txpc1.fnal.gov/wagnp/ObjectMon_plots/currentproblems/pem_notiming_maxADC.eps 
shows that, for all channels in which the PMT ramped low enough not to trigger a timing hit, there are a few outliers which might well be statistical fluctuation, and is with a factor of 2 below what one would expect if there was a problem, from our experience. 
The min. ADC counts for a timing hit 
http://txpc1.fnal.gov/wagnp/ObjectMon_plots/currentproblems/pem_timing_minADC.eps 
shows the lower bound on the threshold and, combined, the approximate width. For all the channels that are not in the first plot the "min ADC" energy shows the lowest energy that the laser yielded. For those cases the energy is well above the approximate threshold that one would expect from a healthy channel, so we can assume they are fine. 
 
So, there is no hard evidence for broken channels. But at least one side in every channel is working. 
</pre>
<!-- Author: peter -->


<!-- Date: Mon Jun 19 21:29:32 2006 -->
<pre>On Thu, 15 Jun 2006, Kaori Maeshima wrote: 
 
&gt; 
&gt; Hi Vadim, 
&gt; 
&gt; ObjectMon crashes time to time, at the end of a run. 
&gt; (core files in the run area). 
&gt; It crashes in TimeMonitor, when doing some statictics calc. 
&gt; Would you please have a look? 
&gt; 
&gt; thanks, 
&gt; Kaori 
&gt; 
&gt; ps1: 
&gt; runarea these days are at: 
&gt; /cdf/onln/data/cdfdaq/consumer/runarea/ObjectMon 
&gt; Current default cdfsoftb0 is 6.1.4k 
&gt; 
</pre>
<!-- Author: peter -->
<!-- Comment: Mon Jun 19 21;30;26 comment by...peter -->
<pre>fixed in TimeMonitor.cc: 
http://cdfkits.fnal.gov/CdfCode/source/Consumer/ObjectMon/TimeMonitor.cc#3216
</pre>


<!-- Date: Mon Jun 19 21:31:25 2006 -->
<pre>On Wed, 14 Jun 2006, Peter Wagner wrote: 
 
&gt; Hi, 
&gt; 
&gt; I found why &lt;13,16&gt; is disabled. The calibration tables in 
&gt; b0gateway:/cdf/onln/data/cdfdaq/consumer/referenceFiles/ObjectMon/CalibTables/TableFiles/v2/TimeSlewing-PEM/TimeSlewing-PEM_195449_198154.dat 
&gt; show: 
&gt; 
&gt; 2912 
&gt; 0 -1 0 0 0 0 0 0 
&gt; 0 0 0 0 0 0 
&gt; 0 0 0 0 0 0 0 0 
&gt; 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
&gt; 
</pre>
<!-- Author: peter -->
<!-- Comment: Mon Jun 19 21;58;04 comment by...peter -->
<pre>I updated the calibration tables on the online machines with my latest version. For the latest runs the above channel is not zeroed, so it should show up in the ObjectMon plots.</pre>


<!-- Date: Tue Jun 20 11:04:43 2006 -->
<pre>There was what seemed like a time shift this night. See http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2006&action=copyentry&page=418&time=08:54:10.653 
 
It turned out that our latest tcl change was overwritten. I sent an email to Kaori to clarify. I reset the tcl to the pre-shutdown values (runObjectMon_physics.tcl_614i_wagnp). 
</pre>
<!-- Author: peter -->
<!-- Comment: Wed Jun 21 14;07;45 comment by...peter -->
<pre>Kaori responded; Usually the tcl files are taken from the CVS repository when a new release is introduced. the time shifts of course are not part of the CVS tcl, as it has to be adapted to the current status. So, what happened was a usual procedure...</pre>


<!-- Date: Wed Jun 21 14:18:57 2006 -->
<pre>After the shutdown we see 3 failures (see e.g. http://txpc6.fnal.gov/~wagnp/emtiming/root2/218658aa-Time2.ps, slide 3): 
1) CEM &lt;20,1&gt;pmt0 
turn-on curves see the next log entry. Comparing to a previous channel &lt;11,-9&gt; (http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/Validation/Problems/0119_mpt1_bro_effic.eps from http://txpc6.fnal.gov/~maxi/EMTiming/Calibrations/Validation/EmtValidate.html) this seems to be likely a flaky LEMO on the TB. 
 
2) PEM &lt;14,13&gt; and &lt;14,14&gt; 
this is likely a swap. Here a check that I performed on run 218176: 
If I compare the events in which the one tower fires and the other doesn't, I see cases in which the energy in &lt;14,14&gt; is sufficient to fire, but it doesn't, and in the same event tower &lt;14,13&gt; fires: 
&lt;14,14&gt; 
pmt2:      pmt2:      t0: 
72 *      1182 *     -9999 * 
&lt;14,13&gt; 
pmt2:      pmt2:      t0: 
79 *        72 * -302.5053 * 
note also that the corrected t0 is off. =&gt; that's likely a swap. 
 
</pre>
<!-- Author: peter -->
<!-- Comment: Wed Jun 21 14;55;27 comment by...peter -->
<pre>The PEM problem seems to be an old issue in fact: https://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=20:29:23
</pre>


<!-- Date: Wed Jun 21 15:05:27 2006 -->
<center><a href='/elog/notebooks/emtiming/Wed_Jun_21_2006_150315.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-52' ></a><a href='/elog/notebooks/emtiming/Wed_Jun_21_2006_150339.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-54' ></a></center>
<!-- Author: both turn-on curves produced from all beam-data runs after the end of last shutdown. PMT1 shows a possibly flaky LEMO channel on the TB; peter -->


<!-- Date: Fri Jun 23 10:21:14 2006 -->
<center><a href='/elog/notebooks/emtiming/Fri_Jun_23_2006_101816.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-56' ></a><a href='/elog/notebooks/emtiming/Fri_Jun_23_2006_101823.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-58' ></a><a href='/elog/notebooks/emtiming/Fri_Jun_23_2006_101830.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-60' ></a></center>
<!-- Author: ObjectMon plots to the 3 broken channels from run 218658; peter -->


<!-- Date: Mon Jun 26 13:26:36 2006 -->
<pre>TimeMontiro after the access: 
 
Run 219082 with 131333 processed events 
 
Bad/Improved channels summary: 
 
wedge rapd Failures:  100%      Eff.   Thr.  Sigma   CorrT   CRMS  LowW MultiOk  Fake  OOT  Change Status 
9     17             00/00   00/00   00/00   00/00    0/0    0/0   0/0   1/0     0/0   0/0   New Problem 
--&gt; doesn't look suspicious on the Objectmon plots 
 
11    -9             00/00   00/00   00/00   00/00    0/0    1/0   0/0   0/0     0/0   1/0   New Problem 
--&gt; fixed problem, have to update calibration tables 
 
12    -9             00/00   00/00   00/00   00/00    1/0    0/0   0/0   0/0     0/0   0/0   New Problem 
--&gt; no known timing problem. as only the mean t0 is shifted, it will be fixed by updating the calibration tables 
 
13    16             00/11   00/00   00/10   00/00    0/0    0/1   0/0   0/1     0/0   1/0   New Problem 
--&gt; fixed problem, have to update calibration tables 
 
14    -2             00/00   00/00   00/00   00/00    1/0    0/0   0/0   0/0     0/0   0/0   New Problem 
--&gt; no known timing problem. as only the mean t0 is shifted, it will be fixed by updating the calibration tables 
 
14    13             10/00   10/00   10/00   00/00    0/0    1/0   0/0   0/0     1/0   1/0   New Problem 
14    14             01/00   01/00   01/00   00/00    0/0    1/0   0/0   0/0     1/0   1/0   New Problem 
--&gt; above two channels are swapped. 
 
15    -3             00/00   00/00   00/00   00/00    1/0    0/0   0/0   0/0     0/0   0/0   New Problem 
--&gt; no known timing problem. as only the mean t0 is shifted, it will be fixed by updating the calibration tables 
 
17    -2             00/00   00/00   00/00   00/00    1/0    0/0   0/0   0/0     0/0   0/0   New Problem 
--&gt; no known timing problem. as only the mean t0 is shifted, it will be fixed by updating the calibration tables 
 
17    -1             00/00   00/00   00/00   00/00    1/0    0/0   0/0   0/0     0/0   0/0   New Problem 
--&gt; no known timing problem. as only the mean t0 is shifted, it will be fixed by updating the calibration tables 
 
20    1              10/00   00/00   11/00   00/00    0/0    0/0   0/0   0/0     0/0   0/0   New Problem 
--&gt; probably a flaky splitter/TB-LEMO connection? will be fixed in the next access 
 
 
Objectmon results for current run (may be not ready immediately): 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/219082aa-Time2.ps 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/219082aa.summ 
Objectmon results for bad channels reference run: 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/203015aa-Time2.ps 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/203015aa.summ 
Histogram reference file was: 
/cdf/onln/data/cdfdaq/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
</pre>
<!-- Author: peter -->


<!-- Date: Wed Jun 28 09:02:11 2006 -->
<pre>ObjectMon showed clock shifts after the shutdown. I compensated this in the tcl. Here is a complete history of time chift corrections: 
 
# CEM, PEM, CHA, PHA, WHA: 
Jul 18  2005:   shiftCorrTime set 2. 1.31 1.92 1.16 2.05 
Aug 29 2005: 	shiftCorrTime set 1.4 0.8 1.4 0.6 1.55 
Nov  6  2005:   shiftCorrTime set 0.02 -0.75 0.0 -0.74 0.2 
Nov 21  2005:   shiftCorrTime set -0.8 -1.52 -0.75 -1.45 -0.74 
Jan  9 2006:    shiftCorrTime set -1.52 -2.5 -1.75 -2.43 -1.5 
Jan 29 2006:    shiftCorrTime set -1.2 -2.1 -1.1 -2. -1.02 
June 20 2006:   shiftCorrTime set 3.0 2.6 3.0 2.7 2.9 
 
The last row indicates the latest setting after the shutdown. 
</pre>
<!-- Author: peter -->
<!-- Comment: Wed Jun 28 09;10;59 comment by...peter -->
<pre># 06/28/06:
    shiftCorrTime set 3.0 3.7 3.0 3.7 2.9

(due to a shift in the PEM mostly.)</pre>


<!-- Date: Tue Jul 25 15:32:23 2006 -->
<pre>Summary of the access today: 
 
As there was a - unplanned - power outage tonight, it was decided this morning to go into controlled access until the afternoon. Adam and I went down in the hall. We got access to both the central and the plug channels which were the only remaining channels with failures reported (http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=14:18:57). 
1) CEM &lt;20,1&gt; pmt0 
The problem was that the LEMO cable was loose in the LEMO connector. We took the connector off and crimped a new connector on the cable. Pulsing into the cable then showed no difference to neighboring channels, in particular no reflections. 
 
2) PEM &lt;14,13&gt; pmt0 and &lt;14,14&gt; pmt1 
After the plug rack was moved out we swapped LEMO cables 6 and 9, which correspond to those towers, on the TB side. I also swapped the labels on the cables, so that there is no confusion any more. 
</pre>
<!-- Author: peter & adam -->
<!-- Comment: Wed Jul 26 09;37;02 comment by...peter -->
<pre>Ad 1) The LEMO connector that was broken is the one on the TB.</pre>


<!-- Date: Wed Aug 2 17:27:52 2006 -->
<pre>Result of the last access: 
 
Run 220589 (http://txpc6.fnal.gov/~wagnp/emtiming/root2/220589aa-Time2.ps) is taken after the last access. The channels look fixed now - we have to update the calibration tables to make the corrected t0 look fine, i.e. to enable proper monitoring for those. 
 
1) CEM &lt;20,1&gt; pmt0  
For turn-on curves before the shutdown, see above entry (http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=15:05:27). The turn-on curve after the repair is shown below. 
 
2) PEM &lt;14,13&gt; pmt0 and &lt;14,14&gt; pmt1  
There is a clear difference in the 100% efficiency plots in slide 3 of e.g. http://txpc6.fnal.gov/~wagnp/emtiming/root2/220072aa-Time2.ps and the above run. As this was a swap I didn't make turn-on curves for this channel. 
 
 
Other potential problems: 
 
On page 5 I see one channel with slightly higher threshold &lt;2,7&gt;. This channel is not mentioned in the summ file (http://txpc6.fnal.gov/~wagnp/emtiming/root2/220589aa.summ), hence we didn't look at it in the last shutdown. Anyway, I made a turn-on curve to check, see below; it looks fine. 
 
</pre>
<!-- Author: peter -->


<!-- Date: Wed Aug 2 17:32:36 2006 -->
<center><a href='/elog/notebooks/emtiming/Wed_Aug__2_2006_173118.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-62' ></a><a href='/elog/notebooks/emtiming/Wed_Aug__2_2006_173135.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-64' ></a></center>
<!-- Author: Channel &lt;20,1&gt; after the repair during the last access; peter -->


<!-- Date: Wed Aug 2 17:35:07 2006 -->
<center><a href='/elog/notebooks/emtiming/Wed_Aug__2_2006_173255.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-66' ></a><a href='/elog/notebooks/emtiming/Wed_Aug__2_2006_173301.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-68' ></a></center>
<!-- Author: Turn-on curves for channel &lt;2,7&gt;. The channel looked suspicious in ObjectMon; but these plots show that all is fine. - Note that the points at efficiency 0 and 1 are not shown.; peter -->


<!-- Date: Fri Oct 27 15:03:54 2006 -->
<pre>ObjectMon shows a blank box for channel &lt;21,-1&gt; because it is disabled in the new calibration tables. To enable monitoring for this channel again I have copied the current "v2" calibration tables to "v2_0_21_1_fix" where I filled the disabled entry for channel &lt;21,-1&gt; with the slewing correction from the previous June_2006 table. I updated the tcl file correspondingly. 
 
</pre>
<!-- Author: peter -->


<!-- Date: Fri Oct 27 15:08:43 2006 -->
<pre>Here a short summary of recent problems: 
1) PEM &lt;11,-10&gt;: 
 
The EMTimining monitor http://txpc6.fnal.gov/~wagnp/emtiming/ shows PMT1 for the channel &lt;11,-10&gt; for runs 224481 and 224521 to be bad: 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/224481aa-Time2.ps 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/224521aa-Time2.ps 
 
These plots show the energy distribution of each PMT: 
http://txpc1.fnal.gov/wagnp/calibrations/all_0_11_10_pmt1.eps 
http://txpc1.fnal.gov/wagnp/calibrations/all_0_11_10_pmt2.eps 
Clearly PMT1 has no entries at high energy. The calorimeter log confirms that: http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=plug&action=copyentry&page=198&time=15:46:23 
 
 
2) CEM &lt;21,-1&gt;: 
 
This channel had to be disabled in the recent calibrations. As the turn-on curves appear normal, Adam is trying to find out for which run range the channel shows problems. 
[still investigating] 
 
 
3) PEM &lt;9,17&gt;: 
 
This channel has shown Multiple Ok-Width Firings in most of the recent runs even though ObjectMon shows a good turn-on curve. See e.g. http://txpc6.fnal.gov/~wagnp/emtiming/root2/224481aa-Time2.ps 
[still investigating] 
 
4) PEM &lt;18,13&gt;: 
 
This channel shows Multiple Firings as well but keeps floating around the threshold. We will keep an eye on it. 
[still investigating] 
 
</pre>
<!-- Author: peter -->
<!-- Comment: Tue Dec  5 17;37;51 comment by...peter -->
<pre>for the plug &lt;-11,-10&gt; channel see also http://www-cdf.fnal.gov/internal/cdfoperations/cal/pager/goodrun.html:

07-11 Oct 2006
     a) PEM 11W-10.0: Dead from plug HV problem. The group configuration
        memory for this channel in plug CAEN crate 4 slot 0 chan 0 got
        corrupted. It was fixed by power cycling and EEPROM resets.
        Runs: 224475-224694

</pre>
<!-- Date: Tue Nov 7 09:14:33 2006 -->
<table><tr><td><a href=/elog/notebooks/emtiming/Tue_Nov__7_2006_091422.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-70  align='top'></a></td><td>This plot shows why channel <1,-21> has been disabled in the last calibrations. its slewing curve shows a wavy pattern compared to the fit function which might point to a run range in which the channel was bad. Note that, as the channel looks good for the current runs, ObjectMon is using the old calibration data for this channel so that the channel can be monitored.</td></tr></table>
<!-- Author: peter -->
<!-- Comment: Fri Dec  1 17;57;51 comment by...peter -->
<pre>This is about channel &lt;-21,1&gt;, not &lt;1,-21&gt;.</pre>
<!-- Date: Fri Dec 1 17:32:59 2006 -->
<center><a href='/elog/notebooks/emtiming/Fri_Dec__1_2006_173219.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-72' ></a><a href='/elog/notebooks/emtiming/Fri_Dec__1_2006_173230.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-74' ></a></center>
<!-- Author: peter -->
<!-- Comment: Fri Dec  1 17;36;33 comment by...peter -->
Channel <-21,1> had to be marked bad during the last round of calibrations due to a bad slewing curve as shown above. This plot shows the slewing curve and a slice as indicated with the lines of the channel <-21,1> from runnumbers 218399-218713 where the channel was apparently good. 


<!-- Date: Fri Dec 1 17:40:43 2006 -->
<center><a href='/elog/notebooks/emtiming/Fri_Dec__1_2006_173720.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-76' ></a><a href='/elog/notebooks/emtiming/Fri_Dec__1_2006_173727.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-78' ></a><a href='/elog/notebooks/emtiming/Fri_Dec__1_2006_174008.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-84' ></a><a href='/elog/notebooks/emtiming/Fri_Dec__1_2006_173844.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-80' ></a><a href='/elog/notebooks/emtiming/Fri_Dec__1_2006_173857.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-82' ></a></center>
<!-- Author: peter -->
<!-- Comment: Fri Dec  1 17;57;01 comment by...peter -->
(continued from the <a href="http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=17:32:59">previous entry</a>)<br>
All shown Figures are for the run range 220217-220579 where the channel turned bad. (Adam found that the channel turns bad after runnumber 218713.) - The calorimeter log doesn't indicate anything suspicious other than a sourcing that happened around that day.<br>
In (a) a plot with the low-energy part of the slewing curve. The solid vertical lines indicate the energy slice for which a 1-dimensional plot of the raw time distribution is made. The PMT asymmetry distribution in (c) shows that both PMTs work fine. The scatter plot of time vs. asymmetry shows that the peaks are independent of the asymmetry. In (d) the time distribution integrated over the full energy range. Clearly there are maxima in a distance of roughly 4ns. So, there is most probably nothing wrong with the PMTs or the TB/ASD boards but more likely with the TDC. Maybe a stuck bit?
<br>
The Hadtdc folks have been contacted to get their opinion what the problem might be. Eric James ran a test on the board where he pulses 3000 signals into each channel from the backplane (w/o unplugging the TDC connectors) and reads out the mean and the RMS of the output times from the TDC. The result is that this channel is the only channel (as far as we saw) that has an RMS of greater than 1(unit in 10ns?). All others are at 0.6-0.9. Printing the histograms would require additional work and has not been done.
<br>
Bottomline: An access request is submitted to fix the channel by replugging the LEMOs and remapping the channel in the TDC board. I would suggest that if there is an access by next week we will fix it in the hall, if not we change the TDC board.





<!-- Date: Mon Dec 11 11:09:04 2006 -->
<pre>The CO reported a clock shift which I compensated with the tcl switches. Current settings: 
# CEM, PEM, CHA, PHA, WHA: 
#    shiftCorrTime set 1.4 0.8 1.4 0.6 1.55 
# 01/29/06: 
#    shiftCorrTime set -1.2 -2.1 -1.1 -2. -1.02 
# 06/20/06: 
#    shiftCorrTime set 3.0 2.6 3.0 2.7 2.9 
# 06/28/06: 
#    shiftCorrTime set 3.0 3.7 3.0 3.7 2.9 
# 10/02/06:  
#    shiftCorrTime set -1.0 -1.2 -0.4 -0.7 -0.5 
# 12/11/06: 
    shiftCorrTime set -2.7 -3.0 -2.1 -2.4 -2.1 
</pre>
<!-- Author: peter -->


<!-- Date: Wed Dec 13 13:26:23 2006 -->
<pre>We made an access today to fix channel &lt;21,-1&gt;.  We moved the LEMOs for this channel to an empty slot on the TDC.  We used the scope to verify that the channel itself was good.  Finally, we remapped the TDC board to account for our change. 
</pre>
<!-- Author: Adam -->
<!-- Comment: Thu Dec 14 13;53;09 comment by...Adam -->
<pre>Further explaination:

We moved the LEMOs for this channel to an empty slot on the TB. We used the scope to verify that the channel was good on the TB side (we pulsed into the TB and the LEMO - there was no indication that it was bad on either side). As the DAQ ACE told us there were CSL tests ongoing during the access such that we couldn't take an LED run to test the results.
</pre>



<!-- Date: Mon Dec 18 16:25:31 2006 -->
<pre>This run shows many fake firing hits because of a readout problem in the PCAL05 crate (see http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2006&action=copyentry&page=958&time=12:09:58.039) 
 
Run 230536 with 265824 processed events 
 
Bad/Improved channels summary: 
 
wedge rapd Failures:  100%      Eff.   Thr.  Sigma   CorrT   CRMS  LowW MultiOk  Fake  OOT  Change Status 
9     17             00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/1     0/0   0/0   Improved 
19    -17            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
19    -16            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
19    -15            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
19    -14            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
19    -13            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
19    -12            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
19    -11            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
19    -10            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -17            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -16            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -15            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -14            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -13            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -12            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -11            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
20    -10            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -17            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -16            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -15            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -14            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -13            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -12            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -11            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -10            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
21    -1             00/00   00/00   00/00   00/00    1/1    0/0   0/0   0/0     0/0   0/0   Known Problem 
22    -17            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
22    -16            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
22    -15            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
22    -14            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
22    -13            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
22    -12            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
22    -11            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
22    -10            00/00   00/00   00/00   00/00    0/0    0/0   0/0   0/0     1/0   0/0   New Problem 
 
Objectmon results for current run (may be not ready immediately): 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/230536aa-Time2.ps 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/230536aa.summ 
Objectmon results for bad channels reference run: 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/228763aa-Time2.ps 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/228763aa.summ 
Histogram reference file was: 
/cdf/onln/data/cdfdaq/consumer/referenceFiles/ObjectMon/TimeMonitor_physics.root 
</pre>
<!-- Author: peter -->


<!-- Date: Wed Dec 20 11:06:15 2006 -->
<center><a href='/elog/notebooks/emtiming/Wed_Dec_20_2006_110452.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-86' ></a><a href='/elog/notebooks/emtiming/Wed_Dec_20_2006_110518.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-88' ></a><a href='/elog/notebooks/emtiming/Wed_Dec_20_2006_110537.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-90' ></a></center>
<!-- Author: peter -->
<!-- Comment: Wed Dec 20 11;06;53 comment by...peter -->
<pre>Checkout of channel 0_21_1:
This channel had to be marked bad during the last calibration period, see http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=17:40:43
See this entry for information on the access: http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=13:26:23

The plots show the uncorrected t0 versus the sum of the PMT energies, the PMT asymmetry, and the uncorrected t0 (1-dim.).
Clearly they look different from the ones at http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=emtiming&action=copyentry&page=4&time=17:40:43 , in particular they don't show the ripple-pattern any more.
</pre>


<!-- Comment: Tue Jan 23 15;02;40 comment by...Adam -->
For more on this channel, go <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=4&frame=2&anchor=15:46:42'>
here</a>.
<!-- Comment: Mon Jan 29 16;29;40 comment by...Adam -->
<pre>The next entry for &lt;21,-1&gt; is at the Thu Jan 18 15:46:42 entry.</pre>
<!-- Date: Thu Jan 11 13:37:14 2007 -->
<pre>A new problem with channel &lt;5,6&gt; was first reported on Dec. 30th.  The problems in the channel include: bad efficiency in the 100% range, bad fit efficiency, bad 50% threshold, bad threshold width and bad mean and rms corrected time.  In addition, in some runs, there is a significant reduction in whole CEM efficiency.  This significant reduction points to a possible problem with the admem rather than the emtiming system.  Calorimetry experts report this as a hot channel in: 
http://www-cdfonline.fnal.gov/cgi/internal/elog/fixlist.pl?nb=fixlist&action=copyentry&page=1&time=01:03:35.519 
http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2007&action=copyentry&page=19&time=07:10:13.855 
http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2007&action=copyentry&page=18&time=17:44:37.980 
 
I'll follow this with supporting plots.</pre>
<!-- Author: Adam -->
<!-- Comment: Tue Jan 23 17;00;04 comment by...Adam -->
<pre>See the Jan 11 16:27:56 2007 entry for plots.</pre>
<!-- Date: Thu Jan 11 16:27:56 2007 -->
<center><a href='/elog/notebooks/emtiming/Thu_Jan_11_2007_162530.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-95' ></a><a href='/elog/notebooks/emtiming/Thu_Jan_11_2007_162541.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-97' ></a><a href='/elog/notebooks/emtiming/Thu_Jan_11_2007_162552.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-99' ></a><a href='/elog/notebooks/emtiming/Thu_Jan_11_2007_162602.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-101' ></a><a href='/elog/notebooks/emtiming/Thu_Jan_11_2007_162617.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-103' ></a><a href='/elog/notebooks/emtiming/Thu_Jan_11_2007_162637.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-105' ></a><a href='/elog/notebooks/emtiming/Thu_Jan_11_2007_162647.ps'><img src='/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-107' ></a></center>
<!-- Author: Adam -->
<!-- Comment: Thu Jan 11 16;45;01 comment by...Adam -->
<pre>These plots are consistent with the problem in &lt;5,6&gt; being associated with the ADMEM rather than EMTiming. From left to right and top to bottom:
1) This plot shows the asymmetry for this channel.  The channel is heavily asymmetric to the pmt2 side.  

2) This plot shows pmt1 vs. pmt2.  The shows us in more detail what plot 1 shows.  pmt2 has large energies when pmt1 has little.  The lines represent an asymmetry of 0.6 and -0.6.  Within the bounds of the lines, the energy distribution is similar to other channel.  This suggests that pmt1 is working properly and that pmt2 is causing the abberation.

3) and 4)  These are the turnon curves as a function of pmt1 and pmt2 energy, respectively where we require |asymmetry| &lt; 0.4.  Although the fits are not very good, we can see that there is a good turn on for both.  This tells us that when we exclude the anomalous energy from pmt2,  emtiming works properly.  Therefore, the anomalous energy is likely an over reporting of energy by the ADMEM.

5) This is pmt1+pmt2 where no timing hit was recorder and |asymmetry| &lt; 0.6.  Note that the only entries are before we expect the timing system to be fully efficient.

6)  This is pmt2 where a timing hit was recorded and pmt1&lt;100.
7)  This is the same as 6, but where there were not timing hits.  This indicates that emtiming only fires infrequently when pmt1 doesn't have enough energy to cause a timing hit on its own.  This indicates that most of the high energy spikes in pmt2 are due to the ADMEM.
</pre>


<!-- Comment: Tue Jan 23 17;02;58 comment by...Adam -->
<pre>See Jan 11 13:37:14 2007 for previous information
See Jan 18 16:03:55 2007 for the resolution of the problem</pre>
<!-- Date: Thu Jan 11 16:47:54 2007 -->
<table><tr><td><a href=/elog/notebooks/emtiming/Thu_Jan_11_2007_164747.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-109  align='top'></a></td><td>Turn on curve for channel <10,-11></td></tr></table>
<!-- Author: Adam -->
<!-- Comment: Thu Jan 11 16;48;53 comment by...Adam -->
<pre>This channel first reported a problem on Jan 10.  It appears that this problem is due to a fitting error rather than a real problem with the channel.</pre>

<!-- Comment: Fri Jan 12 16;59;37 comment by...Adam -->
Note:  This problem first occured in run <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=231712aa">231712</a>.  The ObjectMon plots for EMTiming can be found <a href="http://txpc6.fnal.gov/~wagnp/emtiming/root2/231712aa-Time2.ps">here</a>.




<!-- Date: Thu Jan 18 15:46:42 2007 -->
<pre>channel &lt;21,-1&gt;: 
 
I've re-run calibrations for this channel and inserted a new line for geomid=1346 
 
/cdf/onln/data/cdfdaq/consumer/referenceFiles/ObjectMon/CalibTables/TableFiles/v2/TimeThresholds-CEM/TimeThresholds-CEM_220272_222418.dat 
and 
/cdf/onln/data/cdfdaq/consumer/referenceFiles/ObjectMon/CalibTables/TableFiles/v2/TimeSlewing-CEM/TimeSlewing-CEM_220272_222418.dat 
 
This ought to fix the mean corrected t0 for this channel.</pre>
<!-- Author: Adam -->
<!-- Comment: Tue Jan 23 14;58;40 comment by...Adam -->
The previous history for this problem is <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=4&frame=2&anchor=15:46:42'>
here</a>.
<!-- Comment: Tue Jan 23 15;00;44 comment by...Adam -->
Oops...  scratch that.  The previous history is
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=4&frame=2&anchor=11:06:15'>
here</a>
<!-- Comment: Mon Jan 29 16;08;07 comment by...Adam -->
<pre>The resolution of this problem can be found at the Mon Jan 29 16:05:48 entry.</pre>
<!-- Date: Thu Jan 18 16:03:55 2007 -->
<pre>Channel &lt;10,-11&gt;: 
 
As expected, this problem has not reoccured.  This is consistent with the previous problem being a fitting error. 
 
Channel &lt;5,6&gt;: 
 
This turned out to be an ADMEM problem.  The problem was fixed here: 
http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=wedge&action=view&page=212&frame=2&anchor=11:08:04 
The problem is resolved for runs after 231905. 
</pre>
<!-- Author: Adam -->
<!-- Comment: Tue Jan 23 15;11;55 comment by...Adam -->
The previous history for <10,-11> is <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=4&frame=2&anchor=16:47:54'>
here</a>, and the previous history for <5,6> can be found 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=4&frame=2&anchor=13:37:14'>
here</a>
<!-- Comment: Tue Jan 23 15;21;36 comment by...Adam -->
<a href=http://txpc6.fnal.gov/~wagnp/emtiming/root2/232707aa-Time2.ps>Recent ObjectMon plots</a>  show that both <10,-11> and <5,6> can now be considered good. 
<!-- Date: Tue Jan 23 14:55:34 2007 -->
<pre>Over the weekend, a clock shift occured and the following change was necessary in the ObjectMon tcl: 
 
# CEM, PEM, CHA, PHA, WHA: 
# 12/11/06: 
#    shiftCorrTime set -2.7 -3.0 -2.1 -2.4 -2.1 
# 01/21/06: 
    shiftCorrTime set -3.0 -3.6 -2.5 -3.1 -2.4 
</pre>
<!-- Author: Adam -->
<!-- Comment: Tue Jan 23 17;27;27 comment by...Adam -->
Plots for the last run before the shift are <a href=http://txpc6.fnal.gov/~wagnp/emtiming/root2/232456aa-Time2.ps>here</a>
Plots for the first run after the shift are <a href=http://txpc6.fnal.gov/~wagnp/emtiming/root2/232459aa-Time2.ps>here</a>
Plots for the first run after the shift were corrected in the tcl are <a href=http://txpc6.fnal.gov/~wagnp/emtiming/root2/232551-Time2.ps>here</a>


<!-- Date: Mon Jan 29 16:05:48 2007 -->
<pre>channel &lt;21,-1&gt; :  The last discussion of this problem was at: Thu Jan 18 15:46:42. 
 
As previously discussed,  after fixing this channel in the detector hall, it continued to show up as having a bad corrected time since it had not been calibrated in the previous calibrations round.  As a first try, I ran the calibrations scripts and copied the line for geomid 1346 (corresponding to this channel) and pasted it into the calibrations tables.  This did not work.  I tried replacing the tables for the CEM with the new ones I generated, and this did work.  This is due to the fact that because of clock shifts, the calibrations for &lt;21,-1&gt; alone were shifted relative to the rest of the CEM.  The files I added were: 
/cdf/onln/data/cdfdaq/consumer/referenceFiles/ObjectMon/CalibTables/TableFiles/v2_0_21_1_fix/TimeSlewing-CEM/TimeSlewing-CEM_230965_232443.dat 
and 
/cdf/onln/data/cdfdaq/consumer/referenceFiles/ObjectMon/CalibTables/TableFiles/v2_0_21_1_fix/TimeThresholds-CEM/TimeThresholds-CEM_230965_232443.dat 
 
In addition, I had to add the line: 
# 01/26/07:                                                                      
    shiftCorrTime set -0.3 -3.6 -2.5 -3.1 -2.4 
to the ObjectMon tcl file (/cdf/onln/data/cdfdaq/consumer/runarea/ObjectMon/Consumer/ObjectMon/runObjectMon_physics.tcl) 
to compensate for the shift in the CEM corrected time relative to the PEM. 
 
Updated ObjectMon plots can be found at: 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/233097aa-Time2.ps 
 
The problem appears to be solved.  
</pre>
<!-- Author: Adam -->
<!-- Comment: Mon Jan 29 16;39;13 comment by...Adam -->
<pre>I also removed &lt;21,-1&gt; from the bad channels list.</pre>


<!-- Date: Mon Jan 29 16:53:45 2007 -->
<pre>At this time, there are no known EMTiming problems except channel &lt;9,17&gt;.  This problem was described on Sat Aug 27 11:58:53  and Fri Oct 27 15:08:43.  This channel has MultOk Firings; however, it does not cause a problem in the turn on curve.  As this does not cause problems and it isn't easily fixed, we do not believe this channel requires any action on our part.</pre>
<!-- Author: Adam -->


<!-- Date: Fri Feb 2 11:52:01 2007 -->
<pre>Channel &lt;17,15&gt; was reported as a new bad channel on 31 Jan. 2007.   
The channel was bad on the 50% threshold and threshold width plots; however, it was not bad in the efficiency in 100% range or in the corrected time plots.  These plots can be found at: 
 
http://txpc6.fnal.gov/~wagnp/emtiming/root2/233171aa-Time2.ps 
 
This suggests that it may be a fitting problem rather a problem with the channel itself.</pre>
<!-- Author: Adam -->


<!-- Date: Fri Feb 2 11:53:59 2007 -->
<table><tr><td><a href=/elog/notebooks/emtiming/Fri_Feb__2_2007_115339.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-111  align='top'></a></td><td>Turn-on curve for channel <17,15>.  It looks like one bin is a little low.  We will continue to watch this channel, but for now it looks like no actions is needed.</td></tr></table>
<!-- Author: Adam -->


<!-- Date: Fri Feb 9 11:39:47 2007 -->
<pre>There was another clock shift.  Peter corrected it in the ObjectMon tcl: 
 
# 02/08/07: 
    shiftCorrTime set -0.3 -4.2 -3.1 -3.7 -2.9 
 
The file with this change is called: 
runObjectMon_physics.tcl_614z_wagnp5</pre>
<!-- Author: Adam -->


<!-- Date: Fri Feb 9 11:54:06 2007 -->
<table><tr><td><a href=/elog/notebooks/emtiming/Fri_Feb__9_2007_115336.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=emtiming&action=view&page=-113  align='top'></a></td><td>In the course of calibrations, we found that the two lowest energy bins in the slewing plot for channel <20,0> are higher than normal.  We found that this is due to the time vs. energy distribution being non-gaussian for low energies.  We completed calibrations by refitting the slewing curve excluding the lowest energy bins.  This should be a satisfactory solution at this point, but this channel should be watched as this may be an early sign of a problem with the tdc as seen earlier for channel <21,-1>.</td></tr></table>
<!-- Author: Adam -->


<!-- Date: Fri Feb 9 15:47:19 2007 -->
<pre>Another clock shift.  I added this line to the ObjectMon tcl.  The new file name is runObjectMon_physics.tcl_614b_aurisano 
 
# 02/09/07:                                                                                                                                                   
     shiftCorrTime set -0.2 -7.2 -5.7 -5.9 -6.1 
</pre>
<!-- Author: Adam -->


<!-- Date: Tue Feb 13 18:36:41 2007 -->
<pre>I put the new calibrations into ObjectMon. This caused a reduction of the necessary shift value in the tcl.  The new values are: 
 
# 02/13/07 
     shiftCorrTime set -0.82 -0.94 -1.07 -1.37 -0.69 
 
these are found in: 
 
runObjectMon_physics.tcl_614c_aurisano</pre>
<!-- Author: Adam -->