Hello!

It appears that decabling a large number of ADF->TAB cables is unnecessary!

This afternoon, following the suggestions of many of you, Ted Zmuda and I made some substantial progress on our LVDS issues. As you might expect, it appears we had several problems that needed to be addressed as an "AND" before progress could be observed.

SUMMARY:

1)  The TAB timing with respect to the ADF was too tight.  This was of course the very first thing I tried two weeks ago, but, for reasons I don't understand yet--possibly involving the new firmware and the initial master reset--it wasn't having the desired effect.  In any event, the timing has now been backed off to good effect.  For now I have moved it exactly 132 ns, we will have to see if we can get by with less as this is comparable to our latency budget.

2)  The desquewing sequence is *essential*.

3)  One of the four ADF crates (ADF crate B) is misbehaving, we have
    powered it down, and will keep it so until Dan arrives on wednesday.

4)  There are then several single channel issues:
    -> bent pins on TAB/GAB backplane (not yet fixed!)
        -> some ATC/ADF outputs appear to be invalid,
           and have been swapped with their neighbors.
        -> some cables appear to be bad, and have been
           replaced with spare cables, run informally.

We test after 10 seconds on one TAB the following on board status bits for each input:

 -> parity:  xor of data equals transmitted parity word
 -> sync:    bit is high for least significant bit
 -> bc err:  transmitted BC equals BC TAB receives from SCL.

After all of these fixes, we finally see some nice results! The only errors (non zero status) on one TAB are sync and BC errors, all confirmed as coming from the one ADF crate which is powered down, or from unplugged cables with visible bent pins on the TAB/GAB backplane.  There are no parity errors.

Here we show the parity, sync and BC ERR status after 10 seconds, for each of the three inputs of each of the 10 sliding windows chips of a TAB in slot 3 (count from 1):

CHIP  PARITY  SYNC    BC ERR
0:    0 0 0,  0 0 0,  0 0 0
1:    0 0 0,  0 0 0,  0 0 0
2:    0 0 0,  0 1 1,  0 1 1    <- 2 bent pins
3:    0 0 0,  1 1 1,  1 1 1    <- down ATC crate
4:    0 0 0,  0 0 0,  0 0 0
5:    0 0 0,  0 0 0,  0 0 0
6:    0 0 0,  0 0 1,  0 0 1    <- down ATC crate
7:    0 0 0,  1 1 1,  1 1 1    <- down ATC crate
8:    0 0 0,  0 0 0,  0 0 0
9:    0 0 0,  0 0 0,  0 0 0

We have tested two TABs in this slot with identical results.  Also, no new errors emerge after 100 s instead of 10 s.  Even longer tests will follow soon.

We have also tested another slot, there are about two problems evidently of type (4) above that we will need to address.

CONCLUSION/PROJECTION:

We seem to have found the systematic problem(s)!

However, there still appear to be problems on a few individual channels per TAB that will have to fixed individually.  We will get firmer numbers, but it appears that the 30 spares that have been ordered will be sufficient.

If anyone has any questions, I will be in a Chicago pub trying to forget the past two weeks!

cheers,
mike

















master reset is not needed before the SCL delay can be adjusted.