<!-- Title: 14:58:38  Mon Feb  5 2001 -->
<!-- Crewchief: Evelyn Thomson -->
<!-- Op1: Jay Dittman -->
<!-- Op2: Jong-Young Chung -->
<!-- Op3: Christopher Neu -->
<!-- Op4: Richard Hughes -->
<!-- Op5: Brian Winer -->
<!-- Op6: Phil Koehn et al. -->
<!-- Notes: -->
<pre>New XFT logbook for February - 1 month to Run 2!</pre>


<!-- Date: Mon Feb 5 15:14:59 2001 -->
<pre>Reprogrammed finders with 3 miss designs last week. 
 
Sl13 finder in crate 00, slot 11, serial 13 in decimal, IAC was 
incompletely downloaded.  Reprogrammed flashram -> ok. Why did 
this happen?  I only reprogrammed SL1,2,3,4 chips, not the IAC  
chips?? 
 
Also see 2 new errors on 2 finderboards: 
 
L2 hit buffer bit 19 for chip 3a is always stuck high for the 
SL13 board in crate 02, slot 4 and serial number 8 in decimal. 
 
Pixel bit 5 for chip 4d is sometimes stuck high for SL24 board in 
crate 02, slot 15 and serial number 1 in decimal.  This is seen 
both in the finder L2 pixel buffer and on the linker.</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Mon Feb 5 17:38:09 2001 -->
<pre>Delay switch on LOM 14? 
======================= 
 
  word 2   word 3   word 0   word 1	 
|--------|---d----|-*------|-----------> time 
 
 
 
| = data changes from one output word to next at LOM 
 
d = default setting of 104.5ns (=64+32+8+0.5) delay should latch 
    word 3 data here, but instead I see no word 0 markers, 
    no difference between 4 words in an event 
 
* = setting of 96.5ns (=64+16+8+4+2+1+0.5) latches here just as 
    word 3 information of one event seems to be changing to word 
    0 of next event. 
 
No matter which settings I used, I could never get the right 
words latched.	Impossible to look at actual delay on the scope 
at b0 since there are no vias for the input data to the LOM. 
 
Replace delay switch on this board?  Is there something else that 
could be wrong?  	 
			      
		 
						</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Tue Feb 6 13:25:42 2001 -->
<pre>Problem with SL13 finder in b0xft02 slot 4 serial number 33 
============================================================ 
 
The bunch id in the l2 buffers is wrong, though the actual 
event data is correct 
 
Buffer 0/1/2/3 bunch id's are 9/10/9/10 or 17/18/17/18 etc 
 
=> L2 Header word block address line stuck low 
 
Buffer 0 is YY80 0000 
Buffer 1 is YY90 0000 
Buffer 2 is YYA0 0000	but seem to read YY80 0000 
Buffer 3 is YYB0 0000			 YY90 0000 
</pre>
<!-- Author: Evelyn Thomson -->
<!-- Comment: Tue Feb  6 15;01;03 comment by...Evelyn Thomson -->
<pre>Replaced with finder serial number 9, had to reprogram SL1, SL3 
and pixel chips.  Then had to download from IAC flashram to chips
on SL24 board in slot 13.  Are we talking to more boards than
we think we are?

List of known Finder problems
=============================
SL13 serial # 11 - possible timing problems on chip 1A.
	           See Dec 8 16.21 elog.  Must recheck this.

SL13 serial # 17 - pixels are 1 cell late arriving at both 	
		   linkers. See Dec 8 16:21 and Sep 22/25 elogs.

SL13 serial # 21 - hit error on chip 3a with bit 8 always stuck 
		   high.  See Dec 1 16:18 elog.

SL13 serial # 8 -  hit error on chip 3a with bit 19 always stuck
		   high. See above.

SL13 serial # 33 - reading L2HW addresses YY80 0000 and YY90 0000
		   instead of YYA0 0000 and YYB0 0000. See above.

SL24 serial #  1 - pixel 4d bit 5 sometimes stuck high. See above</pre>


<!-- Date: Wed Feb 7 17:59:49 2001 -->
<pre>2 of the problems (SL13 board 8 and SL24 board 1) appeared after 
reprogramming with 3 miss designs.  I've now gone through all the 1-2-3 
miss designs and tested them thoroughly.  I'm a bit worried that problems 
show up on downloading a different design.  Would you expect this since 
different parts of the chip or pins are being used? 
 
The hall of fame below describes the errors I found: 
---------------------------------------------------- 
 
(0) SL13 serial number 21 - error in chip 3A wire L2 buffer -
bit 8 is always stuck low.

--------------------------------------------------------------

(1)     SL13 serial number 8 - error in chip 3A wire L2 buffer - bit 19 is 
always stuck high. 
 
        ----------------------------------------------------------------- 
 
(2)     SL13 serial number 33 - It looks like an address line on the L2HW 
block is stuck low since the bunch counter is wrong in L2 buffers 2 and 3. 
The bunch counters for four consecutive events/buffers read 8,9,8,9 
instead of 8,9,10,11 or 13,14,13,14 instead of 13,14,15,16. 
 
L2HW buffer 0 is YY80 0000, buffer 1 is YY90 0000, buffer 2 is YYA0 0000, 
buffer 3 is YYB0 0000, so could bit 21 in the L2HW address be stuck? 
 
        ----------------------------------------------------------------- 
 
(3)     SL24 serial number 1 - chip 4d pixel bit 5 is sometimes stuck 
high. 
 
        ----------------------------------------------------------------- 
 
(4)     SL13 serial number 17 - we've looked at this before in December 
and September. The pixel information is correct on the finder, but is 1 
cell late when it reaches both linker, ie the linkers latch cell 0 
information into cell 1.  I tried changing the value in the clock delay 
register YY00 0020 on this board: 
 
Clock delay value       0->37 - data 1 cell late at linkers 
(decimal)               39->    data 2 cells late at linkers 
                        99-132  data 3 cells late at linkers 
                        133-149 data 4 cells late at linkers 
                        150-188 ***data correct at linkers*** 
                        189-255 data 1 cell late at linkers 
 
The default clock delay is 0 - what does this delay do on the board?  If 
the delay is set to something between 150-188, the board passes the finder 
to linker test.  Is it ok to use it or do you want to have another look at 
it? 
 
        ----------------------------------------------------------------- 
 
(5)     SL13 serial number 11 - bit 20 in chip 1A wire L2 buffer is 
definitely stuck high, other problems due to timing? 
 
eg 4 events in chip 1A L2 hit bufffer 
 
Event 0 cell 0 see fff7ff expect ffffff 
Event 0 cell 1 see ffffff expect ffffff 
Event 0 cell 2 see ffff77 expect ffffff 
Event 0 cell 3 see bfff7f expect ffffff 
 
Event 1 cell 0 see baaaaa expect aaaaaa 
Event 1 cell 1 see baaaaa expect aaaaaa 
Event 1 cell 2 see baaaa2 expect aaaaaa 
Event 1 cell 3 see baaa2a expect aaaaaa 
 
Event 2 cell 0 see 555d55 expect 555555 
Event 2 cell 1 see 5554d5 expect 555555 
Event 2 cell 2 see 55d555 expect 555555 
Event 2 cell 3 see 155555 expect 555555 
 
Event 3 cell 0 see 100000 expect 000000 
Event 3 cell 1 see 100000 expect 000000 
Event 3 cell 2 see 108000 expect 000000 
Event 3 cell 3 see 100000 expect 000000 
 
 
 
</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Wed Feb 7 18:02:44 2001 -->
<pre>Tested 20/24 connections between XFT and XTRP with 100 events 
from 00-03_ttbar2_3miss file.  NO errors!  Need 4 spare LOMs to 
test last 4 connections (slots 8,10,12,14 in linker crate b0xft01 
to slots 16 and 17 in xtrp crate).  These should arrive tomorrow 
or Friday.</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Mon Feb 12 11:48:47 2001 -->
<pre>We did finder to linker to xtrp test with 5 xtrp boards. 
ttbar2_3miss files were used. 100 events were tested. 
There were no errors. </pre>
<!-- Author: Evelyn and Jong-young -->


<!-- Date: Mon Feb 12 16:48:21 2001 -->
<pre>We reprogrammed finders to 1 miss design. 
And ran 1220 events with ttbar2 files from finder to xtrp. 
We didn't have any errors.</pre>
<!-- Author: Evelyn and Jong-young -->


<!-- Date: Tue Feb 13 14:24:01 2001 -->
<pre>Test spare linkers that arrived from OSU last week: 
 
Board 18: SW701 567 SW702  4 off 
Board  0: SW701 567 SW702 34 off 
 
Both passed 33ns test and finder-to-linker test, also checking 
linkertester, with 00_ttbar2 files and 00_patt files.  We now 
have 2 spare linkers (11 and 18, 00 is in slot 12 boxft01). 
 
Previously, on Friday, we thought that boards 00 and 13 didn't 
work.  This was because we were setting the delay switches by 
referring to board 11.  Board 11 is the pathologic case, it's 
delays are 57 and 345 instead of the standard settings of 567 and 
3 or 4 or 34! 
 
Board 13 was sent back to OSU, Brian found that it worked 
perfectly there. 
 
--------------------------------------------------------------- 
 
Brian tested 3 LOMs that we sent back to OSU last week (LOMs 14, 
20 and 22).  He found that the pullup resistor for the delay 
switch was in backwards for one LOMs, and the 33ns clock was 
actually 132ns or 13ns on the other two LOMs. 
 
-------------------------------------------------------------- 
 
Brought back fixed boards from Scott: 
 
LOMs 6 and 16, which had messy solder on chips U101 and U100 
respectively.  Tested with finder-to-linker-to-linkertester,  
both passed 7 loops of ttbar2 file.  Now in slots 15 and 13 in 
crate b0xft01.  We now have 1 spare LOM (01). 
 
Linker board 10.  Scott fixed the short between pins 2 and 3 on 
channel link chip U410.  However, we still don't see a b0marker 
on the output. Send board back to OSU?  Replace chip U410  
completely? 
 
 </pre>
<!-- Author: Evelyn and Jong-young -->


<!-- Date: Tue Feb 13 14:32:43 2001 -->
<pre>Tested finders from Scott.  We replaced SL13 boards 14,28,23 in 
b0xft00 slots 4,5,6 with boards 26,32,1. 
 
SL13 board 26: Passed 25 loops of ttbar2 file, 1 missv3.  Scott 
couldn't find anything wrong with this board.  I'd reported that 
chip 3d pixel bit 0 was stuck low.  Need to try 2miss, 3miss and 
1missv2 designs too. 
 
SL13 board 32: Passed 25 loops of ttbar2 file, 1missv3.  Scott 
couldn't find anything wrong with this board.  I'd reported that 
I couldn't erase address 00c00000! 
 
SL13 board 1: Passed 25 loops of ttbar2 file, 1missv3.  Scott 
found an open on U41 and on config jumpers for U25.  
</pre>
<!-- Author: Evelyn and Jong-Young -->


<!-- Date: Tue Feb 13 15:37:01 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>
Ran ttbar2 files in a rotate test (24*25*4=2400 events) through 
finders to linkers.  No errors. 
 
HOW TO UPDATE HARDWARE DATABASE WITH NEW SERIAL NUMBERS/SLOTS:
 
(1) Type "setup fer devel" on any b0dap** 
(2) Type "java hdwusr.CardEditor"  
(3) Click cards, go to the XFT_FINDER and XFT_LINKER_00 crates and click to expand a crate. 
(4) Select card(s), then go to Edit menu, click "Edit/View selected cards", then GUIs will pop up for each card. 
(5) Check serial number versus slot.  If you need to make a change, go to File menu, click "Change Database connection".  You will be prompted for a username and password. 
(6)Type in the new serial number, click ENTER to commit change. 
(7) Go to File menu, click close. 
 
</pre></td></tr></td></table>
<!-- Author: Evelyn and Jong-young -->


<!-- Date: Wed Feb 14 16:49:49 2001 -->
<pre>Tested 4 spare SL24 boards.   
============================= 
 
SL24 board 22: Couldn't reprogram SL2 chip  
 
SL24 board 28 has missing pixels on chip 4a for bits 3-0. 
 
Finder4a   cell=0 Finder pixels=  5 Expect pixels=  d 
Finder4a   cell=0 Finder pixels=  0 Expect pixels=  3 
Finder4a   cell=0 Finder pixels=  2 Expect pixels=  a 
Finder4a   cell=0 Finder pixels=  0 Expect pixels=  2 
Finder4a   cell=0 Finder pixels=  1 Expect pixels=  3 
Finder4a   cell=0 Finder pixels=  c Expect pixels=  f 
Finder4a   cell=0 Finder pixels=802 Expect pixels=803 
 
Is the finder 4a chip working correctly on this board?</pre>
<!-- Author: Evelyn and Jong-young -->


<!-- Date: Thu Feb 15 17:42:42 2001 -->
<pre>Ran overnight finder->linker->5 xtrp boards: 38,400 events 
and 648,571 tracks found from ttbar2 1miss files! 
 
2 problems showed up: 
 
(1) Linker board 6 in b0xft03 slot 4 pt =5a instead of 5b, every 
25 loops except every 100?!?  Linker chips 4 and 5 don't look 
like they were cleaned properly, there is messy white solder 
around the chips.  Will take this to the cleaners! 
 
Replaced with board 11 in b0xft03 slot 4.  Saw a problem on 
output with highest pt bit on chips 6,8,10 and tfnd4 for chip 8.  
C15?  Check with XTRP tomorrow. 
 
(2) SL24 finder board 2 in b0xft00 slot 20 intermittent error 
showed up again (see elog from Jan 6).  L2 buffer data on board 
is correct, but pixels are not seen in either linker that this 
board is sending data too - all pixels are zero.  Only happened 
for 4 events out of 38,400 above.  Removed board -> Scott. 
 
Replaced with SL24 board 3 in b0xft00 slot 20. 
 
Also tested last 4 connections to XTRP: b0xft01 slots 8,10,12,14 
OK with 250 loops of ttbar2 files. 
 
Removed linker board 19 from b0xft05 slot 4.  The 2 flashram 
documentation registers on this board are set incorrectly by the 
altera code. eg 0001 and 0000 instead of 0000 and 0001 or 0000 
and 0002. The bits set depend on which slot the board is in. 
A VME write/read does set the correct bits.  Some kind of 
timing problem in the Altera code on the VME chip for this board 
alone?  
 
Tested spare LOM 28 - ok with linkertester and ttbar2 file.  This 
board is in b0xft05 slot 11 now. 
 
Tested linker board 24 - this is the one that needs linker chip 4 
replaced (always sets same track forever after receiving a 
certain pixel pattern as input). 
</pre>
<!-- Author: Evelyn and Jong-young -->


<!-- Date: Thu Feb 15 17:47:34 2001 -->
<pre>Spare status: 
============== 
Finder SL13 - 3 tested spares in 2nd floor rack  
Finder SL24 - 1 tested spare in b0xft06 
Linker - 1 spare: board 18 in b0xft06 
LOM - 2 spares: boards 1 and 24 in b0xft06 
 
Need to fix: 
============ 
Finder SL24 - boards 2,22,28 in b0xft06 
Linker - boards 6 (clean), 10 (replace U410) ,24 (replace U104) 
</pre>
<!-- Author: Evelyn and Jong-Young -->


<!-- Date: Fri Feb 16 17:15:11 2001 -->
<pre>Programmed 2 EPC2 boards on 14th floor and tested - ok. 
Changed VME design version number for boards 00 and 01 to 3. 
 
Set new default pipeline depths in hardware database, 
since they've moved the L1A 1 event earlier => pipelines 
1 event shorter: 
 
143 for finder pipeline depth (was 147) 
 36 for L2HW depth (was 37) 
 27 for linker VME pipeline depth (was 28) 
142 for input pipeline depth (was 146) 
118 for output pipeline depth (was 122) 
 
offsets stay the same at 7 for finder L2HW and 15 for linker. 
 
-------------------------------------------------------------- 
Had problems using these pipeline depths in the finder to linker 
test though.  It seemed that the finder hit pipelines and some 
of the finder pixel pipelines were being reset to the previous  
numbers.  This varied with the finder board we looked at (on a sample of 8).   
 
Has something changed in how we set finder pipelines?  Why can I 
change some of them and not others?  How are they getting reset 
to something else?  I did a vme write to set a pipeline depth 
before the test started and the pipeline was back to the original 
number after the test, though the test should only know about new 
number!!!</pre>
<!-- Author: Evelyn and Jong-young -->
<!-- Comment: Fri Feb 16 17;27;52 comment by...Evelyn & Jong-young -->
<pre>Jay suggested that a SOFTWARE_RESET could do this. The  finder
designs contain the original pipeline depths.  Doesn't explain
why only some of them go back to the old number though!

I think we have to do a SOFTWARE_RESET after downloading a
pattern to the input chip.  Will confirm this.  If so, then
will have to set pipeline depths after each SOFTWARE_RESET!
</pre>


<!-- Comment: Mon Feb 19 17;37;26 comment by...Evelyn & Jong-young -->
<pre> We do have to issue a SOFTWARE_RESET to get the test to work.
Just resetting the Input chip dooesn't work - errors show up
during the test, not just at the start.

So, we now set the pipeline depths after each software reset!
Checked with 6 finders to 2 linkers and it seemed to work.

Have 6 spare finder boards back from Scott, will test these tomorrow.</pre>
<!-- Date: Mon Feb 19 17:33:20 2001 -->
<pre>Programming of EPC2 chips in all the boards in three cretes   
 
Today, We brought all the EPC2 chips which we have now 
-24 chips in all three crates and some others in spare crates 
to Wilson hall. Reprogramed them, all of them were successful 
except only one, which was failed friday. serial number 02 
We did again with 02 but it still didn't work. 
 
</pre>
<!-- Author: Evelyn and Jong-young -->
<!-- Comment: Mon Feb 19 17;34;04 comment by...Evelyn and jong-young -->
<pre>vme design is V3.</pre>



<!-- Date: Tue Feb 20 16:20:36 2001 -->
<pre>Tested 5 fixed SL13 and 1 fixed SL24 in b0xft04 
 
Slot	New serial # (fix - problem) 
------------------------------------------------------- 
4	21	(nothing wrong - 3a wire bit 8 low) 
5	17	(delay chip bad - pixels 1 cell late) 
6	33	(nothing wrong - bunch id wrong L2HW?) 
7	11	(replaced U78 - 1a wire bit 20 high) 
8	8	(fixed - 3a wire bit 19 high) 
13	22	(U83 loose pins- SL2 unreprogrammable)  
 
Passed 25 loops of ttbar 2, running long-term test</pre>
<!-- Author: Evelyn & Jong-young -->


<!-- Date: Tue Feb 20 16:27:38 2001 -->
<pre>Linker Vme design version 3: works apart from a documentation 
problem in 2/24 boards: registers 24 and 28 should contain 
information on the design downloaded on the board - from lower 
flashram block (1) or from upper flashram block (2) or from VME 
(8 character ASCII code 
 
Board in crate 1 slot 12 has 0001 0001 intially, correct code 
after VME download, stnd1027 after flashram reprogram. 
 
Board in crate 3 slot 8 has unknown design, correct code after  
VME download, 0o0d0022 after flashram reprogram. 
 
Suspect timing problem when latching data into these registers -  
maybe enable is changing when clock transition happens?  We saw 
this with 1/24 boards with version 2, thought it was a board 
problem.  Fix and go to design version 4 very soon... 
</pre>
<!-- Author: Evelyn & Jong-young -->


<!-- Date: Tue Feb 20 16:37:09 2001 -->
<pre>Status @ FNAL (all tested): 
--------------------------- 
24 SL13 finder + 8 spares  
24 SL24 finder + 2 spares  
24 linkers + 1 spare (#18) 
24 LOMs + 2 spares  
 
To be tested: 
------------- 
2 SL24 finders (#28 and #32 from Scott) 
2 SL24 finders (currently in Jay's TDC teststand) 
1 linker (#6 from Scott) 
 
To be fixed: 
------------ 
Linker 10 - replace U410 
Linker 24 - replace U104</pre>
<!-- Author: Evelyn & Jong-young -->


<!-- Date: Tue Feb 20 17:12:50 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>
HOW TO MAKE A GLOBAL UPDATE IN THE HARDWARE DATABASE 
===================================================== 
For new pipeline depths or vme design versions. 6 easy steps - 
remember the semicolon!  Use the card editor (other highlighted 
how-to in this elog) if you're unsure of what the database field 
names are. 
 
(1) setup oracle_client v8_1_6  (on any b0dap** machine) 
 
(2) sqlplus thomsone@cdfonprd 
 
(3) SQL> select distinct pipelinedepth from cards where card_type='XFTFINDER'; 
 
This shows the current value of pipelinedepth  
 
(4) SQL> update cards set pipelinedepth=143 where card_type='XFTFINDER'; 
 
This updates the value of pipelinedepth to 143.  A message like 
"48 rows updated" will be printed out - useful to make sure 
you've changed the right number of boards! 
 
(5) SQL> commit;  
 
This will commit your change!  (rollback; would reverse it) 
 
(6) SQL> exit;</pre></td></tr></td></table>
<!-- Author: Evelyn Thomson -->
<!-- Comment: Fri May 18 18;02;43 comment by...Evelyn Thomson -->
<pre>useful finder commabds

select distinct FLASHRAMLABEL1 from cards where
 bt_boardtype='051'; for SL24 finders

FLASHRAMLABEL1
-----------------------------------------------------------
fn3sl2_3v4.hex


update cards set FLASHRAMLABEL1='fn1sl2_3v5.hex' where 
 bt_boardtype='051';</pre>
<!-- Date: Wed Feb 21 17:46:05 2001 -->
<pre>Reprogram of EPC2 & testing with design v4. 
------------------------------------------- 
 
EPC2 in 24 linker boards of 3 crates and spares except #06 
has been reprogramed with vme design v4. 
 
Green lights of all the boards turned on when power on. 
 
I checked if correct labels of linker design are read. 
 
We had problems in  
 
 b0xft01 slot12  serial number 00 
 design 00010001 
 
 b0xft03 slot08  serial number 09 
 design unknown 
 
with V3. 
 
Now that boards are OK, But other boards have such problems newly. 
 
 1) b0xft01 slot04 serial number 23 
     design 00010001 
 
 2) b0xft05 slot04 serial number 13 
     design unknown 
 
 3) b0xft05 slot10 serial number 15 
     design 00010000 
 
 
 In the cases of 1) and 3), VME download gave correct labels. 
 But when downloaded from flashram again, it gives incorrect value again. 
 
 In the case of 2) VME download gave correct label. And after this, 
 download from flashram didn't cause problem again. 
 
 I found one problem more. in the case of 2) actual serial number of board 
 is #13, but if I read flashram label, #3 was read instead of #13. 
 
</pre>
<!-- Author: Jong-young -->


<!-- Date: Fri Feb 23 17:55:18 2001 -->
<pre>unmasked error disable for b0xft01 and b0xft05.  
Checked by taking a run.  
 
Masked b0xft03 since the tracer in b0xft03 has an error light  
which is always on, even after a coldstart.  Will swap tracer on  
Monday to find out if it is a tracer or linker board problem. 
</pre>
<!-- Author: Evelyn & Jong-young -->


<!-- Date: Fri Feb 23 20:22:38 2001 -->
<pre>XTC to XFT test : 
 
Today Jay reserved the COT crates until noon again, continued  
XTC to XFT test. we continued all the day though. 
 
Several XTC to Finder test failed. 
 
 
 b0cot00 8 0 
 
 b0cot11 14 0 
 b0cot11 14 1 
 
 b0cot04 6 1 
 b0cot04 11 1 
 
These are TDC list which had proplems. 
And b0cot04 6 1 showed same pattern repeatedly. 
 
b0cot04 6 1  1b' cell=0 Finder=     0 
b0cot04 6 1  1b' cell=1 Finder=820820 	  
b0cot04 6 1  1b' cell=2	Finder=28a28a  
b0cot04 6 1  1b' cell=3 Finder=492492  
 
Others Finder hits are 0. 
 
See detail in ~thomson/xft/xftdaq/ALL100TTBAR.log 
 
We also tried XTC to XFT to XTRP. but XTRP bunch ID was not 
correct. Nathan returned to old clock board again. New clock  
seems to have problem, Nathan said. We should test again next week.</pre>
<!-- Author: Evelyn and Jong-young -->


<!-- Date: Mon Feb 26 18:16:01 2001 -->
<pre>3 Linker Boards and 3 LOMs: 
 
We tested two linkers (#19, #03) and LOMs (#20, #14, #22)  
from OSU last thursday, and linker #06 from wilson hall. 
 
1) Linker 
 
Linker #19 and #06 looked good. 
Linker #03 failed. 
 
Event 1  Finder2b' cell=0  Linker pixels= 800  Expect pixels=  0 
 
Bit 11 seems to stuck high  always.   
 
And we tested one of linker (#19 in b0xft03 slot 4) with  
linkertester. 
 
 Observed =  wrd:   1  tfnd:  1  phi:   4  pt:    6f  sht:    0 
 Expected =  wrd:   1  tfnd:  1  phi:   4  pt:    2f  sht:    0 
  
Similar problems were found before, Evelyn thinks this is due to 
J3 backplane C15. When we tested LOM #22 in slot 11 same errors 
happened again. 
 
2) LOMs 
 
LOM # 20 in slot 7  in b0xft03   -> passed 
LOM # 14 in slot 9  in b0xft03   -> passed 
LOM # 22 in slot 11 in b0xft03   -> failed 
 
We think problems in #22 was due to same reason as above linker 
#19 case. 
 
3) Change of TRACER in b0xft03 and b0xft05. 
 
We swapped Tracer in b0xft03 with one in b0xft05. We wanted to 
check if the problem in b0xft03 (tracer error light always on = 
cdf error line always on) was due to the tracer or some 
other board in b0xft03.   
 
Didn't get a chance to check this today (1 - needed special 
version of front-end readout code to get past coldstart due to 
check of current design downloaded for boards with problems with 
v4; 2 - run and hardware databases were down (took forever to 
talk to them and many, many errors in run control afterwards) 
 
 
</pre>
<!-- Author: Evelyn & Jong-young -->


<!-- Date: Tue Feb 27 15:51:34 2001 -->
<pre>        In the middle linker crate (b0xft03), slots 4 and 10 have open C15 
sockets on the front of the J3 connector.  Last time, slots 15 and 19 had 
the same problem.  I tried putting each board into slot 6 - none punched a 
hole in C15, so it doesn't seem to be caused by a specific board. 
 
        Almost all of the boards are out of the crate for now so that the slots 
can be fixed easily.  (Fred Lewis and Peter Wilson have suggested 
replacing the backplane in this crate) 
 
</pre>
<!-- Author: Evelyn Thomson -->


<!-- Date: Wed Feb 28 17:06:25 2001 -->
<pre>We only used one linker and one finder crate today. 
crate 04 and 05. 
 
Ran about 18624 events of ttbar, No errors.</pre>
<!-- Author: Evelyn & Jong-young -->


<!-- Date: Thu Mar 1 13:57:47 2001 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>   

So, I think I might know what happened to the Cal backplanes we
used in the linker crate. 
 
I think we received a bad batch of backplane from the 9th/14th
floor.  I have 7 Cal backplanes in my office.  Five of these
backplanes have damaged pins!  Most of the damaged pins are in
row "C" column 15, but not all of them. 
 
If I recall correctly, we had the last batch of backplanes
assembled by someone on the 9th floor.  I think this was the
first time this was done. Bob Demaat may be able to verify this. 
There may be a problem with the way the connector were inserted
in the backplane, or, the jig may be damaged.  I do remember that
there was some problem with the assembly. 
 
I am not sure how many of these backplanes have been installed,
but, I will try to find out.  We will replace the damaged pins on
the backplanes we have and we are in the process of installing a
good backplane in your crate. 
 
- Fred 
 
</pre></td></tr></td></table>
<!-- Author: From Fred Lewis -->