<!-- Title: 21:55:29  Thu May  4 2000 -->
<!-- Crewchief: Steve Hahn -->
<!-- Op1: and -->
<!-- Op2: a -->
<!-- Op3: cast -->
<!-- Op4: of -->
<!-- Op5: thousands -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Hey, why not start a new general log for the merry month of May!!!


<!-- Date: Thu May 4 21:57:34 2000 -->
Motor generator #2 tripped off about 1800 this afternoon.  Rick Tesarek and I attempted to bring it back up, in the process it appears to be totally dead.  Have put in call to Pat Lukens so he can get electricians in here first thing tomorrow morning.
<!-- Author: Steve Hahn -->


<!-- Date: Fri May 5 09:50:17 2000 -->
<pre>The endplug crates b0pcal08 and b0pcal11 Dirac channels have been unmasked in the hardware database.  I.e., they are now  
*enabled* in the trigger.    
 
The entire east plug is now trigger enabled. 
</pre>
<!-- Author: W.Badgett -->


<!-- Date: Fri May 5 16:24:00 2000 -->
<pre>Unmasked CCAL channels in Dirac_13, Crate b0l1cl00, slot 19. 
(Left endwall channels) 
</pre>
<!-- Author: W.Badgett -->


<!-- Date: Fri May 5 16:48:48 2000 -->
<pre>The air conditioner in the third floor computer room 
has water leaks. The online computers will be shut 
off starting at 5 p.m. Friday, May 5. They will 
return sometime between Saturday evening and Monday, 
once the problem has been repaired.</pre>
<!-- Author: J. Patrick -->


<!-- Date: Sun May 7 19:39:44 2000 -->
boot parameters for b0l1cl00-05 and b0l2cl00-05: someone changed these to load and start the run control code at boot time. Since this code needs some cdfvme libs to function properly, I modified the boot procedure for these nodes to load these libraries, and also removed some more "vxworksb" relicts. The only noticable side effect is that some cot crates (those using "l2caltestb.table"!) now load the DCAS cdfvme library ...
<!-- Author: Arnd. -->


<!-- Date: Tue May 9 15:41:37 2000 -->
<pre>At about 13:00 all West Central Arch racks had a rack protection Trip CASWT, CASWB, CANWT, CANWT (b0ccal00-07).  There were blown fuses in APACS.  May be related to rack protection checkout in West Endplug.  All rcaks back up by 14:00.</pre>
<!-- Author: Peter Wilson -->


<!-- Date: Thu May 11 18:17:36 2000 -->
<pre>Unmasked all EndWall Dirac channels in the hardware database,  
since the AdMem->Dirac trigger cables have been recently  
installed. 
This includes the AuxSumEn0,1 fields.</pre>
<!-- Author: W.Badgett -->


<!-- Date: Mon May 15 13:29:05 2000 -->
<pre>Modified startup scripts for a bunch of the COT crates (those 
that have power+CPU right now, b0cot03,06,08,09) -> the new table 
file b0_cot.table is supposed to become the default for all COT 
crates as time goes on. Please direct any complaints/wishes to 
me.</pre>
<!-- Author: Arnd -->


<!-- Date: Wed May 17 09:02:25 2000 -->
Started CMU DAQ Testing
<!-- Author: Steve V. -->
<!-- Comment: Wed May 17 09;04;50 comment by...Steve V. -->
Details from yesterday:
 <a href=/cgi/elog/det-system-elog.pl?nb=cmu&action=view&page=1&anchor=15:50:56 target=_top><img src='/elog/gifs/gr_menu.gif' width=19 height=10 border=0></a>


<!-- Date: Thu May 18 07:49:53 2000 -->
<pre>Resuming CMU daq testing today. No partition available but will 
try to use ones that are de facto free. 
Grab partition 0 
Grab partition 4 
</pre>
<!-- Author: Steve  V. -->
<!-- Comment: Thu May 18 08;54;21 comment by...Steve V. -->
Working with Andrew Martin & Michael Schmidt. 
Problem with using partition 0 was traced to 
the TS. Suspicion is heavily on the driver
chips from the TS to the return xpoints. These
might be swappable with ones on the return crosspoints.
If so, problem could be patched today at price of some
minor havoc with system. Currently, partitions 0,1,2,4
all work.


<!-- Date: Fri May 19 17:39:07 2000 -->
<pre>The Collision Hall and Assembly Hall flammable gas alarms tripped this afternoon at about 4:20 with normal responses.  The fault was found to be a loose connection in the 24 VDC power feeding the Quadlog SDM module.  The module lost power and internal diagnostics set off the alarm.  The connection was repaired and on Tuesday we will physically test the other connections in the alarm system. 
</pre>
<!-- Author: Schmitt -->


<!-- Date: Tue May 23 15:24:05 2000 -->
<pre>Changed node names of b0vrb processors to follow 
the left to right convention of the event builder 
 
b0vrb04 -> b0vrb00 (muon) 
b0vrb05 -> b0vrb01 (trigger) 
b0vrb00 -> b0vrb04 (central cal) 
b0vrb01 -> b0vrb05 (plug cal) 
 
Modified the configuration in the "vrbtest" program</pre>
<!-- Author: patrick -->


<!-- Date: Wed May 24 15:03:55 2000 -->
<pre>Masked EM Tower 5 (0...5) on DIRAC_93, crate  
LEVEL1_CAL_05 slot 19 in the hardware database, due to noisiness (according to Carla) 
 
</pre>
<!-- Author: W.Badgett -->


<!-- Date: Wed May 24 15:20:35 2000 -->
<pre>Unmask EM Tower 5 (0...5) on DIRAC_93, crate   
LEVEL1_CAL_05 slot 19 in the hardware database, since  
Carla told me the wrong eta 
 
Try again, Mask: 
 
LEVEL1_CAL_05 slot 18, tower 2 (0...5) DIRAC_92 
</pre>
<!-- Author: W.Badgett -->


<!-- Date: Fri Jun 2 16:33:44 2000 -->
<pre>b0dau30 crashed and would not reboot. It appeared the 
system disk was corrupted. In particular the 
passwd file was no longer there. 
The system disk was restored from a backup. 
b0dau30 now appears to be functional. It 
appears the oracle database is OK.</pre>
<!-- Author: patrick -->


<!-- Date: Mon Jun 5 12:45:25 2000 -->
<pre>starting b0cmu00 daq testing again. see muon logbook for details.</pre>
<!-- Author: Steve Vejcik -->


<!-- Date: Mon Jun 5 15:39:49 2000 -->
<pre> Mixed success with cmu00. Cabling problems on ASDs. 
see cmu logbook for details.</pre>
<!-- Author: Steve Vejcik -->


<!-- Date: Wed Jun 7 07:57:28 2000 -->
<pre>AJM returns with (old) 5th TS. Problem fixed (race condition in data clocked out from scheduler). New firmware (including that for timing in of system) should be put in today.</pre>
<!-- Author: Steve V. -->


<!-- Date: Thu Jun 8 08:03:29 2000 -->
<pre>Read out wedge 12 & 17 yesterday via softEVB. 
Continue work later today. 
Making changes to CMUDRY00 Run type this morning. 
(See CMU logbook for details.) 
Later work on moving Tracer with fix to fully stuffed COT TDC crate to double check Terri's craftwork. 
</pre>
<!-- Author: Steve V. -->


<!-- Date: Thu Jun 8 09:25:12 2000 -->
Due to much-needed installation of lighting under the central arches and electrician schedules, both south central arches will be turned off for about a half hour sometime this morning.  When I get an exact time, I'll enter it here and let people know.
<!-- Author: S. Hahn -->


<!-- Date: Wed Jun 14 14:38:00 2000 -->
<pre>Continued work on cmu readout. 
Small data file: run 93048 should have some 
data for those interested. 
see cmu logbook for details.</pre>
<!-- Author: Steve V. H.Kim -->


<!-- Date: Thu Jun 15 09:38:14 2000 -->
<pre>Ran with cal trigger & pulsed cmu asd+tdcs this morning. 
Took about 100k events in run 93092. look in cmu 
logbook for more details. Thanks to Andrew M. & Greg F. 
for details on trigger & ts. It'd be good to do this 
mode in integration tests.</pre>
<!-- Author: STeve V. -->


<!-- Date: Thu Jun 15 12:19:41 2000 -->
<pre>Installed modified Tracers in the following locations in the 
DAQ system. These Tracers have been modified to ignore short 
glitches in the VME signal DS1~, as seen in certain TDC crates. 
 
If these Tracers pass system integration type tests, we plan 
to implement this change (as well as modifications to the 
front panel intended to isolate the panel from digital ground) on all Tracers. These Tracers have already been bench tested. 
 
   Tracer  55 -> B0CCAL04 
   Tracer  83 -> B0ECAL03 
   Tracer  33 -> B0CMU00 
   Tracer 135 -> B0COT08 
   Tracer  40 -> B0L2CL01 
   Tracer 108 -> B0L1CL01</pre>
<!-- Author: W. Stuermer -->


<!-- Date: Tue Jul 11 11:10:58 2000 -->
Turned off Trigger Crosspoints and L1 Decision this morning to replace bridge plates for -5.2V power.  This was succesfully completed and crates are now back on.
<!-- Author: Peter Wilson -->


<!-- Date: Thu Jul 13 06:34:38 2000 -->
<pre>The Tracer -> VRB link for B0ECAL07 is now functional. 
_ 
Following is a list of crates which have a known VRB 
based problem. Fixing these problems will have to wait 
until the associated VRBs are fixed, or until I obtain 
temporary replacements. 
_ 
   b0imu00  (VRB 158, chan 0) 
   b0cmx01  (VRB 158, chan 7) 
   b0xft06  (VRB 148, chan 7) 
   All L2CL, L2DE, L2GL   (VRB 141) 
    
    
   </pre>
<!-- Author: W. Stuermer -->


<!-- Date: Mon Jul 17 16:14:38 2000 -->
Power to NW central arch crates now on.  This means all four arches are now powered.  See central e-log for more details.
<!-- Author: Steve Hahn -->


<!-- Date: Mon Aug 14 14:41:33 2000 -->
<pre>Doing CMU Threshold studies. Use SE Arch. 
b0ccal12 does not appear to be turned on. page expert</pre>
<!-- Author: Steve V. -->


<!-- Date: Thu Aug 17 08:57:43 2000 -->
<pre>TS-TXPT re-cabling is now complete. 
This should be the configuration needed to allow 
all systems to be timed-in for running.  Please let me 
know (ajm@fnal.gov) if there are any problems with TS 
signals getting to a crate or group of crates, including 
as much information as possible ( partition number is a  
requirement).</pre>
<!-- Author: Andrew Martin -->


<!-- Date: Thu Aug 17 10:12:34 2000 -->
<font=+2> 
B0CCAL01 is now using the Fiber ethernet. 
<p> 
The labels for fiber 
cable no 5 and 6 were reversed.
<!-- Author: W. Stuermer, JJ Schmidt -->


<!-- Date: Thu Aug 17 10:26:40 2000 -->
<font=+10> 
<p> B0CCAL01 is now using the fiber optic ethernet. 
<p> The labels for the no. 5 and 6 cables were reversed.
<!-- Author: W. Stuermer and JJ Schmidt -->


<!-- Date: Thu Aug 17 10:52:30 2000 -->
SW arch has been moved into central yoke; NW arch moving in is in progress.  Have reconnected power for SW arch, and reset DMACS; all crates are up and replying to DAQMON.  NW arch has been powered down, and the power monitor which Leon Beverly connected to the contacter removed.
<!-- Author: S. Hahn -->


<!-- Date: Thu Aug 17 10:53:10 2000 -->
SW arch has been moved into central yoke; NW arch moving in is in progress.  Have reconnected power for SW arch, and reset DMACS; all crates are up and replying to DAQMON.  NW arch has been powered down, and the power monitor which Leon Beverly connected to the contacter removed.
<!-- Author: S. Hahn -->


<!-- Date: Thu Aug 17 10:54:12 2000 -->
Do not know why last entry was entered twice.  Will look into it.
<!-- Author: S. Hahn -->
<!-- Comment: Fri Aug 18 11;16;39 comment by...RDE -->
<br>Hey, why not start a new log book for the merry month of August?
(See first entry in *this* log book.)


<!-- Date: Tue Aug 22 11:55:38 2000 -->
<pre>b0dap30 hangs. 
Responds to ping, but no response at console or to <ctrl><alt><del>. 
Reboot by hardware reset button. 
On reboot, remote PCs cannot mount /cdf/code-Linux-2.0.34 disk. 
On b0dap30, note nfs mount daemon not running 
  (ps -ef | grep mountd shows nothing) 
So do /etc/rc.d/init.d/nfs stop 
      /etc/rc.d/init.d/nfs start 
This seems to correct the problem. 
Don't understand why the system hung, or why nfs crashed after reboot.</pre>
<!-- Author: patrick -->


<!-- Date: Thu Aug 24 11:11:44 2000 -->
<pre>Prior to 0700, the root partition on b0dau30 filled. 
The system was rebooted shortly after 0800. 
It is unknown what additional files were added.</pre>
<!-- Author: patrick -->


<!-- Date: Thu Aug 24 11:12:45 2000 -->
<pre>b0dap30 hung again, exactly as yesterday 
at about this time. It was reset, and again 
the nfs mount daemon was not running when 
the reboot finished.</pre>
<!-- Author: patrick -->


<!-- Date: Thu Aug 24 11:31:20 2000 -->
<pre>It is likely that the b0dap30 hangs were due to TrigSim++. 
This program has a memory leak, shortly after the reboot 
it was observed to be consuming 1GB of virtual memory 
and was still increasing when it was killed.</pre>
<!-- Author: patrick -->


<!-- Date: Thu Aug 24 19:30:25 2000 -->
<pre>Some items I did today: 
<p> 
Replaced the TRACER that had been removed by Jay Dittman due to a broken TDC CALIB Twin-Ax connector in b0cot06.  Fred Lewis has the bad TRACER, and gave me a replacement TRACER which he will enter in the database. 
<p> 
Turned off all power to both the east and west walls to cut the clock inputs to the TRACERs everywhere on the detector (and any other noise sources on the walls, Bill Orejuodos had already turned off all the COT crates) at 1835.  I have just turned everything back on (via DMACS) just now.</pre>
<!-- Author: S. Hahn -->


<!-- Date: Thu Aug 24 19:31:54 2000 -->
<pre>Damn!  After yelling at other people, I forget to put the last message in "HTML" like you should.</pre>
<!-- Author: S. Hahn -->


<!-- Date: Fri Aug 25 19:36:31 2000 -->
Entry made for Steve Chappa: clock was sychronized with single bunch proton store overnight.  Steve also widened the B0 signal from two RF buckets (37.4ns) to 4 RF buckets (74.8ns).  The leading edge should come 37.4ns before the leading edge of CDF_CLK.  This change was made to see if it will correct the bunch counter eerors in the L1CAL and L2CAL crates.   
 
The following is the email (received at 3am) from Steve detailing the work done: 
"Well, the store finally happen and I was able to get the Clock 
synchronized and the signals aligned to the IR (Interaction Region). I was able to get my offsets computed, downloaded and verified. Hopefully, the beams people will keep the marker relationship constant. End result: the CDF_CLK LVDS cables' output (@B_ZERO) to align up, in real time, to the position of the IR. 
 
"Second, the width of B_ZERO has been increased from 2 to 4 buckets and positioned as discussed. This was done for all programmed B_ZERO signals. 
 
"The Sequencer programs currently downloaded with these changes are: STCDF04A.INV and DYCDF04A.INV. Current communication with the Clock modules is now via the VME interface and the control program is Serguei's program. 
 
"Sometime early next week, the beams people will try to do another 
single-bunch store. This is so I can verify the timing work I just did. 
 
"And finally, I will not be here tomorrow (today now). I left the Clock running and synchronized to the Tevatron signals. If there are any problems with the errors or Sequencer Hold errors, you may want to just switch the PCC operating mode from Normal (Syncronized) to Free-Run mode."  
<!-- Author: Peter Wilson -->


<!-- Date: Mon Aug 28 12:22:46 2000 -->
<p>B0COT00 now passes the VRB link test. There was a break in 
the (fiber optic) data line, between the patch panel on the 
first floor and the VRB transition module. 
 
<p>We substituted the spare pair (no 11 and 12) for the pair with the broken fiber (labeled no 1 and 2). We have checked the pair for end to end continuity and tested these links with Jim Patrick's VRB test program.
<!-- Author: W Stuermer, JJ Schmidt -->


<!-- Date: Tue Aug 29 09:20:01 2000 -->
<pre>Mako Shimojima reports that b0dau30 hung last 
evening around 11, and he rebooted it. 
However, the RAID disk where /data1 resides 
did not appear. The machine was shut down 
and power cycled at 0830, following this the 
RAID disk is now accessible.</pre>
<!-- Author: patrick -->


<!-- Date: Tue Aug 29 10:27:16 2000 -->
<pre>b0dap30 hung at around 10:00 and was rebooted.</pre>
<!-- Author: patrick -->


<!-- Date: Tue Aug 29 12:15:40 2000 -->
<p> Three of the COT crates, seem to have made miraculous 
recoveries. Each of these crates had a VRB link related 
problem. 
<ul> 
<li> B0COT01 works; was failing the "Busy On" test. 
<li> B0COT03 works; was seeing the "TDC / Bus error" problem in this crate. 
<li> B0COT09 works; was seeing a Taxi related problem. 
</ul> 
<p> Although I have done some fiber optic continuity test, and swapped transition cards in order to locate problems here, I 
don't see how these tests could have fixed these problems. 
 
<p>Based on previous experience, the fix in B0COT03 was most likely caused 
by someone removing or swapping one or more of the TDCs in this crate.
<!-- Author: W Stuermer -->


<!-- Date: Wed Aug 30 15:10:36 2000 -->
<p> B0COT09 now passes the TSI link test. There was a break in 
the fiber optic cable (label no 1) between the Tracer and the 
fiber patch panel. The spare cable is now being used to replace 
the broken cable. 
<p>The computing division has promised to loan 
JJ some equipment that can be used to locate the break; it may 
be possible to fix this fiber cable by reterminating it. 
<p> 
<!-- Author: W Stuermer, JJ Schmidt -->


<!-- Date: Wed Aug 30 16:45:33 2000 -->
<p>There is a problem with the TSI (TS to Tracer) link 
for B0CCAL08, B0CCAL09, B0CCAL14 and B0CCAL15. Each of 
these crates are seeing spurious triggers and they fail 
the TSI link test. 
<p>We have checked the end to end continuity of the TSI 
fiber optic cables for B0CCAL14 and B0CCAL15 and there 
appears to be no break. (B0CCAL08 and B0CCAL09 were 
inaccessible.) 
<p>This suggests that either there is a problem on the 
trigger crosspoint (TXTP) end or there is no clock going to 
these crates. I will continue looking at this. 
<p>
<!-- Author: W Stuermer, JJ Schmidt -->
<!-- Comment: Fri Sep  1 14;57;47 comment by...W. Stuermer  -->
Apparently, the problems with B0CCAL08,09,14 and 15 were caused
by the fact that power was disconnected from the clock fanout
module servicing the NE arch. See the note below, entered by
Peter. The problem has gone away now (yesterday).
<!-- Date: Thu Aug 31 09:12:28 2000 -->
Power to the North-East detector clock fanout crate was found to off this morning.  The power cordad been pulled out of the rear of the fanout crate.  It appears to have been knocked out by cables in behind the crate.  This was corrected about 9am.
<!-- Author: Peter Wilson -->


<!-- Date: Thu Aug 31 19:29:12 2000 -->
Clock Guy here. 
 
This Thursday's one-bunch store started at about 16:30 and lasted to 19:20 hours. During this time I was able to verify my timing that was set up during last Thursday's one-bunch store. 
 
Good news: the Tevatron markers stayed in one place and the alignment of the CDF_CLK @B_ZERO edge with the PW pickup signal stayed in the same place. So far, so good. I will then modify my timing diagram and put in the final delay numbers. This information should then be available  by the end of next week. 
 
Oh, thanks to Serguei for staying with me and helping with the software.
<!-- Author: Steve Chappa -->



<!-- Date: Fri Sep 1 15:48:59 2000 -->
<p>There was a problem with the TSI link to B0PCAL11. 
It appears that the problem was caused by certain 
problems with the CDF clock in this crate (such as 
a 25% duty cycle instead of the nominal 50% duty cycle). 
I ended up replacing the 6U/9U adaptor in this crate 
and this has corrected the observed problems. 
<p>I've put a longer note in the Plug logbook with some 
more details. 
<p>
<!-- Author: W Stuermer -->


<!-- Date: Sun Sep 3 02:26:13 2000 -->
The Hardware DB was modified. This affects the labeling of SVT wedges, swapping wedges 2 and 4 to comply with the non-standard cabling of Barrel4.
<!-- Author: Giovanni Punzi -->


<!-- Date: Tue Sep 5 16:48:28 2000 -->
<p>This entry describes work that was done last night (when there was still power on the detector). 
<p>I conducted the TSI link and VRB link tests on all of the COT 
crates. Four COT crates had errors in one or both of these tests. 
The TSI test was not performed on B0COT07. 
 
<ul> 
 
<li><b>B0COT09</b> had errors on both the TSI and VRB link tests. I was not able to resolve the cause of these problems. This crate is not going to be used to readout the COT during the next 6 weeks (due to a shortage of TDCs). 
<p> 
 
<li><b>B0COT10</b> had errors on both the TSI and VRB link tests. The CDF clock cable was unplugged from the Tracer. After this was plugged back in, this crate passed both tests. 
<p> 
 
<li><b>B0COT11</b> had errors on both the TSI and VRB link tests. Someone has arranged this crate for some sort of test, with the 
Tracer in slot 20 and a Testclk in slot 7. The Testclk was  
supplying the clock to the Tracer; the TSI fiber was not 
connected. I left the crate in this configuration. There were 
no TDCs in this crate for readout. 
<p> 
<li><b>B0COT16</b> had errors on both the TSI and VRB link tests. 
The clock cable was not plugged in the Tracer. After this was 
plugged back in, this crate passed both tests. 
</ul> 
<p>By the way, the clock cables in NE Top relay rack (B0COT10...B0COT12) are all over the place. It took me a while 
to find the clock cable for B0COT11. 
<p>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:27:57 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-5&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-5  width='250' align='top'></td><td>This is the CDF clock, as seen via the front panel connector on the Tracer, in the B0CCAL04 crate. The clock has the correct period and amplitude, but it should have a 50% duty cycle.  I've seen this same thing in B0PCAL11 and in that case removing (and replacing) the 6U/9U adaptor fixed the problem. B0PCAL11 showed symptoms of inconsistant function of the VRB and TSI links.  This data was taken last night, when there was still power on the detector. </a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:36:10 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-6&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-6  width='250' align='top'></td><td>This is the CDF clock, as seen via the front panel connector on the Tracer, in the B0CCAL12 crate. The clock has the correct period, amplitude and duty cycle, but as you can see there are some glitches. I would estimate that the glitches effect 1% of the cycles. These glitches may cause occasional problems in the TSI and VRB data links. This data was taken last night, when there was still power on the detector. </a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:45:03 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-7&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-7  width='250' align='top'></td><td>This is the CDF clock, as seen via the front panel connector on the Tracer, in the B0ECAL00 crate. The clock has the correct period, amplitude and duty cycle, but I see glitches on about 50% of the cycles. This data was taken last night, when there was still power on the detector.  </a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:47:44 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-8&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-8  width='250' align='top'></td><td>Same deal as the last entry, CDF clock seen in the B0ECAL01 crate.</a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:48:48 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-9&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-9  width='250' align='top'></td><td>CDF clock, seen in the B0ECAL02 crate.</a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:50:35 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-10&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-10  width='250' align='top'></td><td>CDF clock, seen in the B0ECAL04 crate.</a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:52:02 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-11&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-11  width='250' align='top'></td><td>CDF clock, seen in the B0ECAL06 crate.</a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Tue Sep 5 18:56:14 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-12&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-12  width='250' align='top'></td><td>CDF clock, seen in the B0ECAL07 crate. This image was taken with the oscilliscope with infinite persistence turned on.</a></td></tr></table>
<!-- Author: W Stuermer -->


<!-- Date: Thu Sep 7 18:31:42 2000 -->
<p>I have replaced VRB117 from the B0VRB00 crate, 
slot 10 with VRB177. This appears to have fixed 
the problem with the VRB readout of the B0CLC00 
crate. (The B0VRB00 crate is also known as the 
B0EB11 crate.) 
 
<p>This crate has now passed the VRB test with 
100 million simulated events without detecting 
any errors. 
 
<p>This same VRB is also responsible for reading 
out the CMU, CMX, CMP, IMU and MUSC crates. All 
of these links will have to be retested. 
 
<p>
<!-- Author: W Stuermer -->


<!-- Date: Fri Sep 8 12:38:51 2000 -->
<p>As mentioned above, yesterday I replaced the VRB in B0VRB00 
crate, slot 10. Today, I ran the VRB test on the other front 
end crates read out by this VRB. 
 
<p>The results are that B0CMU00, B0CMU01 and B0CMX01 crates 
<b>failed</b> the "busy off" test. 
 
<p>The other crates:B0IMU00, B0IMU01, B0CMP00, B0MUSC00, 
B0CMX00 (and B0CLC00) all passed the VRB test with 1,000,000 
simulated events each. 
 
<p> 
 
<p>I will be following up on this when I get back this 
afternoon.
<!-- Author: W Stuermer -->
<!-- Comment: Wed Sep 13 11;58;19 comment by...W Stuermer -->
Some of the channels going to the Taxi transition card
that services B0VRB00 slot 10 were in the wrong order.

After I fixed this, all of the channels on B0VRB00 passed
the VRB link test with the exception of B0CMX01.



<!-- Date: Fri Sep 15 08:59:27 2000 -->
<pre>The firmware in all installed non-SVX VRBs was updated 
to version VRB0901.HEX. (Except for the new SVT VRB).</pre>
<!-- Author: patrick -->


<!-- Date: Fri Sep 15 12:54:15 2000 -->
<pre>b0dap30 hung around 11:30 and was rebooted.</pre>
<!-- Author: patrick -->


<!-- Date: Sat Sep 16 11:46:11 2000 -->
<p>The problem with the VRB (Hardware Event Builder) readout 
of B0COT09 turned out to be a problem a VRB Transition card 
problem. I replaced TART 002 with TART 030. B0COT09 now passes 
the VRB link test. 
 
<p>I had misled myself when I swapped the transition module 
with a spare that turned out to have the same problem. 
 
<p>All of the COT crates now pass the VRB link test, except 
B0COT00. There is a note on the power supply for B0COT00 
saying that it should not be turned on. (B0COT00 has previously 
passed the VRB link test.) 
 
<p>
<!-- Author: W. Stuermer -->


<!-- Date: Mon Sep 18 16:19:54 2000 -->
<p>B0CMX01 passes the VRB link. This crate had previously failed 
this test, but before replacing the VRB I repeated the test 
with a total of 1100K simulated events with no errors. 
<p>As far as I know, there are no broken VRB links at this time. 
<p>
<!-- Author:  W. Stuermer -->


<!-- Date: Tue Sep 19 09:06:49 2000 -->
<pre>This morning the main ethernet switch was 
reconfigured to enable routing. 
An additional 48 ports were installed 
on the switch. 
Also, b0dau30 was reconfigured so that 
it has a larger system disk. This should 
reduce the frequency of the root partition 
filling up.</pre>
<!-- Author: patrick -->


<!-- Date: Fri Sep 22 17:42:09 2000 -->
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> 
<html> 
<head> 
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> 
   <meta name="GENERATOR" content="Mozilla/4.7 [en] (X11; I; Linux 2.2.16-3 i686) [Netscape]"> 
</head> 
<body> 
Modifications to CDF&nbsp;VIPA&nbsp;crate backplanes to improve CDF_CLK 
termination: based on studies done by Ted Liu, Scott Holm and Peter Wilson. 
<p>Exisitng termination consists of a divider network at both ends of the 
backplne which results in about 200Ohms to 3V at each end.&nbsp; This termination 
is done for both CDF_CLK and CDF_CLK*. 
<p>Replacement termination consists of: 
<ul> 
<li> 
330 Ohm pulll down resistors to ground for CFD_CLK and CDF_CLK* on TRACER</li> 
 
<li> 
50 Ohms <i>between&nbsp; </i>CDF_CLK and CDF_CLK* at opposite end of backplane 
from TRACER&nbsp;slot</li> 
</ul> 
With this termination change Ted Liu made run of 100,000,000 events (Calib 
Continuous) overnight on Sept 20-21.&nbsp; Used b0l1cl05 with modification 
and b0l1cl00 without modification.&nbsp; Had 0 bunch counter errors in 
b0l1cl05 and 9 in b0l1cl05.&nbsp; Previously b0l1cl05 had error rate of 
about 1 in 100,000.&nbsp; Similar improvements seen in XFT&nbsp;linker 
crates. 
<p>See scope picture in following entry for before and after pictures of 
clock signals. 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
</body> 
</html>
<!-- Author: Peter Wilson -->


<!-- Date: Fri Sep 22 17:45:38 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-13&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-13  width='250' align='top'></td><td>Scope picture using differential probe looking at CDF_CLK on  backplane of b0l1cl05 at slot 2.  Top trace is with original  termination (see preious entry).  Bottom trace is for modified backplane termination (see above).  </a></td></tr></table>
<!-- Author: Peter Wilson -->


<!-- Date: Fri Sep 22 17:54:42 2000 -->
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> 
<html> 
<head> 
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> 
   <meta name="GENERATOR" content="Mozilla/4.7 [en] (X11; I; Linux 2.2.16-3 i686) [Netscape]"> 
</head> 
<body> 
Modified CDF_CLK backplane termination on 17&nbsp; crates.&nbsp; See previous 
entry and scope picture for expaination of improved termination.&nbsp; 
The folowing crates had termination modified and TRACERs swapped with ones 
which have pull downs on CDF_CLK and CDF_CLK*: 
<ul> 
<li> 
b0l1cl00-b0l1cl05 - L1 caborimeter crates</li> 
 
<li> 
b0l2cl00-b0l2cl05 - L2 calorimeter crates</li> 
 
<li> 
b0xft00, 02, 04&nbsp;&nbsp;&nbsp; - XFT&nbsp;Linker crates</li> 
 
<li> 
b0cot17 - COSEB-2</li> 
 
<li> 
b0ccal05 - CASWB-2 (has central showermax and preamps installed)</li> 
</ul> 
Awaiting results of operation of b0ccal05 and b0cot17 to determine immediate&nbsp; 
need for this modification. 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
</body> 
</html>
<!-- Author: Peter Wilson, Roberto Davila, Scott Holm and Jay Dittmann -->


<!-- Date: Tue Sep 26 07:34:30 2000 -->
<pre>right after the backplane&tracer modification with the 
new termination on Friday afternoon (see previous message),  
all L1CAL and L2CAL crates (12 of them were included in one partition and took a long run with about 105,000,000 events  
over night (rate about 3kHz,continuous calibration). no bc 
mismatch error found. 
 
similar test also done with all three XFT_LINKER crates: 
XFT_LINKER_01, 03, 05. LINKER 03 no longer shows bc mismatch 
error(was at 10**(-5) level), but LINKER 01 has error rate at 
2*10**(-7) level (most recent test done 09/26/, morning, owl 
shift. this crate had error rate at 10**(-6) level before 
modification). LINKER 05 still has many bc mismatch errors. 
This morning I looked at both the B0 and cdf_clk signals from 
the backplane for all three crates, they all look about the same. 
The error rate difference among the three crates is not  
understood. looking at the error messages, it seems most of the events with bc mismatch were close together in time (within a few 
mins, sometimes within a few events). This seems to be also true 
for all the bc mismatch errors seen from other crates in the past. 
 
Note that b0l1cl00 had very high bc mismatch errors in run 99125 
on Sat. 09/23/ around ~1-2pm. This is AFTER the new termination and the long test. the cause for that is unknown (according to the E_log, there was one filled bunch in the machine while this run was taken). </pre>
<!-- Author: Ted Liu -->


<!-- Date: Thu Sep 28 07:16:58 2000 -->
<pre>I have done some study on the bunchcounter mismatch problem 
for LINKER crate 1 (after the new termination). posted the 
results on shift E-log and also XFT E-log. but just realized  
that it should be posted here (see previous messages about 
backplane termintation and bc mismatch errors). 
 
see next entry.</pre>
<!-- Author: Ted Liu -->


<!-- Date: Thu Sep 28 07:17:36 2000 -->
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> 
<html> 
<head> 
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> 
   <meta name="GENERATOR" content="Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686) [Netscape]"> 
</head> 
<body> 
&nbsp; 
<br>******* L2 buffer address bits problem on LINKER-01 backplane ***** 
<br>************&nbsp; more study on bunchcounter mismatch problem ******* 
<p>&nbsp;(1) what have we learned about bunchcounter mismatch problem so 
far? 
<p>Before and after the new termination modification on the backplane and 
tracer for 
<br>all L1CAL, L2CAL and LINKER crates, many extensive tests have been 
done on 
<br>all these crates in continuous calibration mode. All of the L1CAL and 
<br>L2CAL crates (12 of them, b0l1cl**,b0l2cl**) didn't have any bunchcounter 
<br>mismatch error for more than 100,000,000 events runs after the new 
termination, 
<br>while before the modification, they typically have bc mismatch errors 
1 out of 
<br>10,000 (readout) events. The same can be said for LINKER-03 (b0xft03) 
crate. 
<br>However, we still have the follow problems: 
<p>(a) LINKER crate 1 (b0xft01) still have bunch counter errors, even in 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continuous calibration mode. 
<br>(b) DIRAC crate 2 had bunch counter mismatch errors in some high trigger 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rate runs (when there was beam). 
turning off (&amp;on) the crate power 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; seems to fix the problem (see 
E-Log, Owl shift Wed. Sept. 27). 
<p>(2) trying to understand problem (a) tonight: 
<p>Yesterday afternoon Chris Neu showed me some of his test results on 
<br>LINKER crate 1 for the events with bc mismatch errors, with detailed 
<br>information on each buffer bunch counts. and I found those events 
<br>could have been caused by L2 buffer address bit problem. 
<br>tonight while on owl shift I have done some study on this. What 
<br>I found is quite interesting, and our SciCo (Mike Lindgren)&nbsp; asked 
me to 
<br>post the results here. 
<p>What I found is that the L2 buffer address bit (1)&nbsp; signal 
<br>on the backplane for LINKER crate 1 looks very different from LINKER 
<br>crate 3, and can potentially cause the data to be saved into a wrong 
buffer. 
<p>the details will be described below. 
<p>To make it easier to understand, let's start with Myron mode.&nbsp; 
This picture 
<br>below shows&nbsp; (from top to bottom)&nbsp; the CDF_L2B1*, CDF_L2B0*, 
CDF_L1A* 
<br>and CDF_CLK (* means active low) signals for one event in Myron mode 
<br>triggered on L1A.&nbsp; Note all the signals are evaluated at the rising 
edge of 
<br>CDF_CLK. So we can see there are 4 consective L1A over 4 CDF_CLK 
<br>ticks, and the L2 address bits (0&amp;1) indicate which buffer (0, 
1, 2, 3) the 
<br>data in the L1 pipeline will be saved.&nbsp; All the signals are directly 
from the 
<br>backplane on LINKER&nbsp;crate 3 (which doesn't have bc mismatch problem). 
<p>This is one might call "Beautiful Myron Mode" event.&nbsp; Now let's 
take a look 
<br>at crate1. To make it easier to compare, I will just replace the cdf_clk 
signal 
<br>with the CDF_L2B1* from crate 1. see the next picture. 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-226&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-226' width='251' 
                         height='206' align=middle></a> 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<p>Still in Myron mode, replacing the cdf_clk signal with the CDF_L2B1* 
from LINKER&nbsp;crate 1 (which has bunchcounter 
<br>mismatch problem). This is shown in yellow (below).&nbsp; This way 
we can compare the CDF_L2B1* 
<br>from both crate at the same time. Note that the two crates are i n 
one partition driven by 
<br>exactly the same L1As. In principle, the L2 buffer(1) from the two 
crates should be identical. 
<br>but they are NOT! as can be seen clearly below.&nbsp; there are two 
extra pulses before and after 
<br>the CDF_L2B1* strobe associated with the L1A. Looking on scope while 
triggered continuously, 
<br>the two pulses jump around.... 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-227&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-227' width='251' 
                         height='206' align=middle></a> 
<br>&nbsp; 
<br>&nbsp; 
<p>The picture below is the same as above, but zoomed out in time. Now 
you can see that there 
<br>are lots of stuff going on on CDF_L2B1* line from crate 1 (the problem 
crate). it looks almost 
<br>as if someone else is also driving it (crazy).&nbsp; This is again 
in Myron mode. next we will look at 
<br>events in normal data taking mode. 
<br>&nbsp; 
<br>&nbsp; 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-228&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-228' width='251' 
                         height='206' align=middle></a> 
<br>&nbsp; 
<br>&nbsp; 
<p>Below is a good event which shows the L1A along with the L2 buffer bits 
(0&amp;1) from crate 3 (working crate), 
<br>indicating buffer #3. the yellow line is the L2 buffer bit 1 from crate 
1 (problem crate).&nbsp; Note that I&nbsp;have compared 
<br>the L2 buffer bit 0 signals from both crates, they look the same. Only 
L2 buffer bit 1 signals are different. 
<br>&nbsp; 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-229&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-229' width='251' 
                         height='206' align=middle></a> 
<br>&nbsp; 
<br>&nbsp; 
<p>Now zoom out intime, again one can see there is extra pulse on L2 buffer 
bit 1 from crate 1. 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-230&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-230' width='251' 
                         height='206' align=middle></a> 
<br>&nbsp; 
<br>&nbsp; 
<p>zoom out more, see below. 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-231&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-231' width='251' 
                         height='206' align=middle></a> 
<br>&nbsp; 
<p>below is a single shot for an event with the extra pulse very close 
to the actually L2 buffer bit 1 strobe 
<br>from crate 1. 
<br>&nbsp; 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-233&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-233' width='251' 
                         height='206' align=middle></a> 
<br>&nbsp; 
<br>&nbsp; 
<p>here I&nbsp;actully captured an event where the CDF_L2B1* (L2 buffer 
address bit 1)&nbsp; is HIGH on 
<br>crate 3 (working crate), while it is LOW (active) on crate 1 (problem 
crate). &nbsp;In crate 3, the 
<br>data in the L1 pipeline will be saved into buffer 1 in the LINKER&nbsp;boards, 
in crate 1, the data 
<br>will be saved in buffer 3 due to the glitch !&nbsp;&nbsp; Events like 
this one will cause lots of trouble 
<br>downstream in the DAQ&nbsp;chain. 
<br>&nbsp; 
<a href='/cgi/elog/elog.pl?nb=2000&action=view&page=-234&button=yes' 
                      target='xxx' onclick='jswindow()' ><img 
   src='/cgi/elog/elog.pl?nb=2000&action=view&page=-234' width='251' 
                         height='206' align=middle></a> 
                         height='206' align=middle></a> 
<br>&nbsp; 
<br>&nbsp; 
<p>Such much for the pictures (I&nbsp;have more if you want to see). So 
WHY?&nbsp; what's going on&nbsp; in crate 1 
<br>causing CDF_L2B1* to be so different... I haven't had time to find 
out exactly what causing the 
<br>problem,&nbsp; but I&nbsp;can tell you what I have done: 
<p>(a) swap the Tracer on the two crates, the problem stay with crate 1.&nbsp; 
so it's not the Tracer. 
<br>(b) turn off power of the crates and measure the impedance of CDF_L2B1* 
wrt, say, +5V 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (the backplane termination is such that 
all TTL&nbsp;signal lines&nbsp; are terminated into +5V with 330 Ohm, 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and to GND with 470 Ohm).&nbsp; 
The measured value is ~150 Ohm for CDF_L2B1* line on crate 1, 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while it is 195 Ohm on crate 3. 
(and the measured value for&nbsp; all other TTL&nbsp;signal 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lines is ~195 Ohm on both crates, 
which is what expected).&nbsp; So at least the termination for 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CDF_L2B1* on crate 1 is different 
from that of crate 3 (and all other CDF-style crates I checked). 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; so this is a clue.... 
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; By the way, I have unplugged all 
the Linker boards and Tracer, repeat the measurement, it is still 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ~150 Ohm. So the problem 
has nothing to do with LINKER&nbsp;boards. 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note that the new termination 
modification was only done for CDF_CLK , which is PECL signal. 
<p>(c)&nbsp; also tried to find out who is driving the CDF_L2B1* line in 
crate 1. I have looked at all the other 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CDF specific&nbsp; signal 
lines on J2 backplane, none of them looks like CDF_L2B1*. The only lines 
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; left are the VMEbus address/data 
lines, but one cannot access them from the back... 
<p>tomorrow I&nbsp;will ask someone (maybe Scott Holm) to take a hard look 
at the backplane&nbsp; (J2) for crate 1. 
<br>I am on owl shift so will not be here during the day. I will also take 
a look at DIRAC and other crates later. 
<p>Anyway,&nbsp; enough for now. it's 6:30am. 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
</body> 
</html>  
<!-- Author: Ted Liu -->


<!-- Date: Fri Sep 29 18:19:54 2000 -->
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> 
<html> 
<head> 
   <meta name="GENERATOR" content="Mozilla/4.7 [en] (X11; I; Linux 2.2.16-3 i686) [Netscape]"> 
</head> 
<body> 
Work from yesterday's access: investigated problems with crates that had 
backplane clock termination modified in last weeks access (Sept 22). 
<ul> 
<li> 
b0ccal05 - this crate had syptoms of an incorrect clock frequency.&nbsp; 
Obsereved with a scope that there were many spurious clock edges.&nbsp; 
The TRACER&nbsp;was swapped and clcok signal returned to a clean 7.6MHz 
square wave.&nbsp; Observed the clock in persistent mode for 5 minutes 
and saw no incorrect edges.</li> 
 
<li> 
b0cot17 - this crate was not getting correct responses from the return 
XPT.&nbsp; On investgation found that the Return XPT&nbsp;cable was not 
completed sated.&nbsp; Upon seating teh cable, crate operates correctly.&nbsp; 
See TDC&nbsp;logbook entries for additional work done on this crate.&nbsp; 
See next logbook entry for scope picture of clock signal on cot17 backplane</li> 
</ul> 
 
</body> 
</html>
<!-- Author: Peter Wilson -->


<!-- Date: Fri Sep 29 18:24:51 2000 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-14&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=general&action=view&page=-14  width='250' align='top'></td><td>Scope picture of clock signal in b0cot17 using differential probe on CDF_CLK and CDF_CLK* on backplane.  Note that this crate had backplane termination modified on 9/22/00.</a></td></tr></table>
<!-- Author: Peter Wilson -->


<!-- Date: Fri Sep 29 18:25:47 2000 -->
<pre>Put entries for Linearized Energy Response (LER's) for  
calorimeters into online production database. 
 
table               values 
--------------------------------- 
CEMLinEResponse     All set to 1. 
PEMLinEResponse     All set to 1. 
CHALinEResponse     All set to 1. 
WHALinEResponse     All set to 1. 
PHALinEResponse     results from sources+testbeam see CDF5418 
 
As values become available for the components other  
than PHA, the values can be update, but this gives  
us a starting point for getting the crates reading  
the LER's from the database for calculating the  
lookup table.</pre>
<!-- Author: Jack Cranshaw -->


<!-- Date: Mon Oct 2 11:17:14 2000 -->
<pre>DATABASE/VIEWS/HARDWARE/DBANA 
 
Cut the following views into production database cdfonprd. 
 
date_runlist_view 
cal_channel_view_calor 
cal_channel_view_cem 
cal_channel_view_pem 
cal_channel_view_cha 
cal_channel_view_wha 
cal_channel_view_pha 
cal_channel_view_cot 
 
- This is the first time that the calorimeter hardware views  
have been defined in the production database. 
 
- The cot view is now owned by the application cdf_views_prd. 
 
- The problem with displaying the time of day in DBANA is fixed  
by a change to date_runlist_view.</pre>
<!-- Author: Jack Cranshaw -->


<!-- Date: Tue Oct 3 14:53:31 2000 -->
<pre>Added 'General Information' to Ace calibration page 
/ace2help/acecalibrations.html</pre>
<!-- Author: Jack Cranshaw -->


<!-- Date: Wed Oct 4 10:23:20 2000 -->
<pre>CONSUMERS/CALIBRATION/LED/QIE 
 
There seem to have been several times that the QiePed  
consumer was started up and connected to a partition  
providing LED events. This can be checked by doing  
 
  grep LEDD ~cdfdaq/consumers/log/*QiePed* 
 
This affected runs 
 
 98055 
 98058 
 98059 
 98763 
 98764 
 99570 
100216</pre>
<!-- Author: Jack Cranshaw -->