Series defect on agilent 167xx boards?

• #125 Reply
  Posted by Hamster on 13 Apr, 2022 19:47
• @markL Check for broken traces on your chipsel error, see my post above, i have had several cards give this erorr and it was a trace at the back side of the board ...
  
  
• #126 Reply
  Posted by MarkL on 13 Apr, 2022 22:20
• Quote from: Hamster on 13 Apr, 2022 19:47

  @markL Check for broken traces on your chipsel error, see my post above, i have had several cards give this erorr and it was a trace at the back side of the board ...
  

  Thanks, but it was actually DogP's card that had the ChipSel errors.  I was just playing along and posting probe results from a working card trying to help.
  
  I agree that bad traces are the #1 problem on these cards.  But in this case DogP figured out it was a bad clock PLL chip.  Read back a few posts for the details on the symptoms and resolution.
  
  Thanks for posting your symptoms and the areas you fixed.  Hopefully they'll be of help to others.  I'm not surprised on the "COMP_ZOOM_ERROR" fix.  The traces you fixed go to the voltage reference input on some of the comparators.
  
• #127 Reply
  Posted by Hamster on 13 Apr, 2022 23:36
• Ahh..
  
  DogP did you ever source a SY89421V  ? I have a couple of 1675X boards that are "beyond" repair that can be scavenged off.
• #128 Reply
  Posted by DogP on 14 Apr, 2022 08:49
• Quote from: Hamster on 13 Apr, 2022 23:36

  DogP did you ever source a SY89421V  ? I have a couple of 1675X boards that are "beyond" repair that can be scavenged off.
  

  Yes I did... MarkL was kind enough to send one my way, which got it back up and running.
  
  A couple side notes -
  I was able to track down another set of cables, so now I've got a both 1675x cards running (master/slave) with a full set of cables.
  I also upgraded the HDD to CF by modifying one of the cheap ACARD AEC-7722 SCSI to IDE adapters.  That brought the boot time down from 3:25 to 2:55, and got rid of the loud OEM HDD... enabling fast boot knocked another 12 seconds off that.  I still need to permanently mount the adapter inside the chassis though.
  
  DogP
• #129 Reply
  Posted by MateKrisz on 06 Oct, 2022 20:56
• Hi all,
  
  I need reopen this topic, because of I have same problem with the cards.
  I have a HP 16702A, with the following cards:
  2x 16534A - both working fine.
  2x 16555D - primary is good, secondary is bad
  1x 16720A - bad
  
  The 16720A surface is looks good, no corrosion on the PCB.
  When I run the pv utility, the following tests are failed:
  loopback
  clock_test
  wait_test
  instint_test
  
  In case with 16555D I got the fail results when I ran the following tests:
  pld_dpath_stest
  vram_serial_stest
  encoder_stest
  
  Possible to find a schematic for these cards? I found a "service manual" but it is not highly detailed.
  
  MateKrisz
  
  
• #130 Reply
  Posted by MarkL on 07 Oct, 2022 14:58
• On the 16555D failure, I would re-configure both cards to be stand-alone (not as a master and expander), and re-run the self test on each.  This will at least give you an idea if the problem exists with the inter-card communication, or is isolated to one of the cards.
  
  The 16720A doesn't have runners on the bottom, so no surprise it's completely clean.  Is there a little gray ribbon cable installed, and in the correct position for single card operation?
  
  On both failing cards it might be useful to post the results of running pv on the first reported failure (modtest xxxx) with the debug options turned on.  If you haven't used pv yet, use the forum Advanced Search and look for "pv" from user "MarkL".
  
  Glad to hear both your 16534A are working.  I can't say I've had the same luck.  I would recommend removing the plastic runners and adhesive from these and all your cards before you get corrosion problems.  Heat is your friend, and you can search the forum for lots of ways people have done this removal.
  
  I'm not aware of any schematics or detailed troubleshooting for anything from the 165xx/167xx series.  The only thing available is the Theory of Operation section in the Service Guide.  I'd suggest you read those sections and absorb every word.  Although only a summary, they seem have been written by people very familiar with the internal operation of the cards (maybe even by the developers) and are very accurate in my experience.  Combining the information from the Block-Level Theory section and Self-Tests Description section can help make sense of what pv is reporting, and can sometimes lead to you directly to the failing area.
• #131 Reply
  Posted by MateKrisz on 07 Oct, 2022 18:52
• Yes, I tested the 16555D cards separately. When I tested it as master-slave combination, the test said a big FAIL for both card. Later I made two primary card, and tested them. so one working and one bad.
  
  On the 16720A the gray ribbon cable is on good postiton. J8 and J9 connected. I checked it in the manual.
  I made some pictures about the pv utility output. You see the loopback test output.
  
  I found the manual little info about the self-tests:
  Internal Loopback Test.
  The internal loopback test verifies the operation of the module backplane interface IC. A walking ones pattern is written into module memory at a specific memory location, read, and compared with known values. Passing the internal loopback test implies the module backplane interface IC is functioning and the system is able to write to module memory.
  
  The clock test is fail also and the wait test too. I think problem with the module backplane interface IC on the board. This chip is the big one like  Altera (U52) near the 50M clock (U72)?
  

  ---

  

  

  

  

  
• #132 Reply
  Posted by MarkL on 11 Oct, 2022 17:48
• On the 16555D card, I wouldn't bother trying to get it to work in a pair with the good card until you figure out what's wrong with it in the stand-alone configuration.  Please post the pv results for the bad card by itself, both the summary of all tests, and then the first test that failed with debug options turned on.  There might be clues there.
  
  
  On the 16720A, I don't have much experience troubleshooting that card since mine has always worked.  I agree that it could be the FPGA (the Altera MAX), but there's plenty of other possibilities surrounding it that could be preventing the loopback from working.  Given that some of the other tests are actually passing, I wouldn't be inclined to suspect it right away.
  
  I think I would try to figure out exactly what the system is doing during the loopback test.  The manual says it's trying to write a pattern to memory and read it back.  The first set of debug output implies it is doing byte read/writes.  The only memory I see on the board is the Micron SDRAM (48LC4M16A2) and there are 8 of them.
  
  I would try to find which SDRAM chip(s) it's trying to read/write to by looking at the write enable pins on each.  If you have enough probing capability, you could even try to figure out the data pattern that's being attempted (looks like it might be 0x00, 0x55, 0xff, 0xaa from your diagnostic output).
  
  The manual says 6 of these chips are used for data, so I'm guessing the other 2 might be used for sequence control, and probably it's the two nearer the clock circuitry which would be U121 and U117.  It's only a guess, but you could start your probing with those 2 since the errors being reported are only byte sized.
  
  Another technique to try to localize where the errors are coming from is to lift legs on chips, particularly the memory chips, and correlate it to what new errors start appearing.  Useful signals for this test would be chip select, write enable, and a data I/O line or two (not all at the same time).  This might be a good option, considering how long the loopback test runs (at least couple of minutes on my system).
  
  A similar technique is to hold down various signals with a 50ohm or smaller resistor.  The size resistor can be determined by watching on a scope to make sure you've ruined the switching levels enough to cause an error.
  
  Also note the large number of LVTH245 chips.  My guess is that they are probably controlling access for each memory chip to a common bus, which is how the memory is read and written by the system.  Perhaps lifting a leg or two on these could induce interesting errors that might correlate to the loopback errors.  Maybe one of these is sick, but it depends on how they've laid out the memory addressing.
  
  
  It's not easy debugging these cards with no schematics and no documentation for the debugging output, especially if you don't have a working card to compare with.  Sometimes it's just easier to buy another card.
  
• #133 Reply
  Posted by MateKrisz on 11 Oct, 2022 21:20
• Hi MarkL,
  
  Thank you for your answer and your tips. I checked again my 16720a board under magnifier, and I found lot of hidden dirty area around the FPGA. Looks like first time I need to wash the PCB with IPA. Some days ago found a topic where the guy has a problem with the oscillator (U72). After I read it I ordered one quickly, I was lucky I found one on low price, and the seller live relative close to me. If the board is cleaned and the oscillator replaced by myself, I will re-run the pv tests maybe something changing. I will tell you the pv outputs here. Some days and the oscillator will arrive.
  
  Tomorrow I will send you the 16555D pv outputs. First time I need remove the plastic things from the back side, and I replace the 4 pcs 3300uF capacitor. Maybe some has bad ESR value.
  
  MateKrisz
  
  
• #134 Reply
  Posted by MarkL on 12 Oct, 2022 14:32
• Did you test U72 and have determined it's bad?
  
  And test the 3300uF capacitors?
  
  If not, I wouldn't start replacing components without having determined they're definitely bad, or at least you've exhausted all other reasonable possibilities.  Swapping out components can often make the situation worse by inadvertently introducing additional problems.
  
  Can you provide a link to the post about the oscillator?  There are at least two more clock chips on the board that I found (PLLs) if you're looking at the failed clock test.
  
  On the analysis cards, the pv tests are (for the most part) in order of dependency, meaning that a failed test could make later tests also fail.  I don't know for sure, but I would suspect the 16720A pv test routines are structured in a similar way.  That is why I would focus on the loopback failure first.
  
  If you found a post that makes you suspect U72, then sure test it.  But if ok, don't pull it off the board, and return to looking at the loopback failures (in my opinion).
• #135 Reply
  Posted by MateKrisz on 12 Oct, 2022 22:29
• I read this "solution" in the groups.io mail list some weeks ago if I remember well. When my LA not arrived yet, until then I readed some article about my cards. I bought this on eBay: eBay auction: #254489501566 Will arrive from England. I checked today, and I not found the topic in my browser history (total chaos here, tons of opened site in my history), I will search it again for you.
  
  On the 16555D card I checked the capacitors with my HP 4274A and the ESR values are higher than usual. So I replaced them. After I re-run the pv util, but same tests are failed. I ran with debug, you see the output the post bottom.
  
  Back to 16720A. Good idea localize on the 16720A what memory chips are bad. I would like to start with U121 and U117 and later LVTH245. Which legs need to lift up as pair? I found the chip datasheet here: https://www.micron.com/-/media/client/global/documents/products/data-sheet/dram/64mb_x4x8x16_sdram.pdf
  So when I uplift the "chip select" leg, like 19, need to lift up another legs or just this? Sorry, It's not clear to me.

  ---

  
• #136 Reply
  Posted by DogP on 23 Oct, 2022 09:02
• Like MarkL, my 16720A has always worked, so I don't have any first-hand tips for troubleshooting it.
  
  Regarding your 16555D - it looks like maybe Chip 1's bit 1 is floating.  All of the errors shown seem to be related to bit 1 (e.g. expected: FFFF actual: FFFD, expected: 0000 actual: 0002, etc.), but not always stuck low or high.
  
  I don't have a 16555D to get any better information for you, but looking at closeups from an ebay auction, it looks like the two main chips are U25 and U26.  So logically, my best guess would be Chip 0=U25 and Chip 1=U26.  The board appears to have the plastic runners, so definitely remove those, and look for corrosion.  It looks like a runner goes right over the traces between U26 and its RAM, so that's where I'd inspect closely first.
  
  If you have the unit apart enough that you can access the cards during test (or have a card extender like discussed earlier in this thread), I'd try running the test while touching the pins of U26 with your finger (and maybe U25 and the RAM as well), and see if you get any noticeably different errors.  That may help pinpoint the trouble area.
  
  DogP
• #137 Reply
  Posted by MarkL on 24 Oct, 2022 15:05
• (I haven't vanished; just preoccupied with a large number of non-electronics things...)
  
  I had a chance to lift and hold high the DQMH and DQML legs on both U117 and U121 DRAM chips (4 "do_loopback" tests).  Results attached in the .zip below.  Each test failed within a few seconds.
  
  The "Expected 0x55 got 0x00.." errors are exactly the same in each test even though I was messing with a different signal each time.  I was not expecting this.
  
  The second set of errors (walking ones) were different each time, and seems to represent bits in the DRAM, which makes sense although they are not strictly in order.
  
  And as suspected, the "do_clock_test" also fails when DQMx is held high (test not shown), which says pv may be depending on a successful memory loopback test to verify the clock.
  
  Not sure what all this means yet since your walking ones look ok, but thought I'd share.
  
  
  And on the 16555D, I agree with DogP you're definitely looking at a single-bit error.  Since the expected level is not consistent, it's likely open (flapping).  Once you get the runners off and cleaned up, inspect for corrosion and broken traces.  Use sharp probes to pierce the soldermask and test continuity for all traces passing under and near the runners end-via to end-via.
  
  If DogP's finger test doesn't show anything interesting, you can try holding down some of the signals with a resistor as described above.  Put the test that's failing into a loop and observe what fails.  You can try this looping script here:
  
    https://www.eevblog.com/forum/testgear/agilent-16717a-comparator-and-zoomchipseltest-failures/msg4434136/#msg4434136
  
  The signal traces on the 1675x cards are generally in order.  I would expect the 16555D to be the same, so you will know when you're getting close when you see the bits failing from the resistor hold-down getting closer to the bad one.
  

  ---

  u121_u117_dqm_tests.zip
• #138 Reply
  Posted by MarkL on 26 Oct, 2022 15:32
• I've made an interesting discovery:
  
  If the CLK pod cable is not plugged into the module (header J7), my card fails with the same do_loopback and other errors as yours.  With the CLK cable plugged in, everything passes.
  
  On further inspection, all the pod cables (data and CLK) have pin 18 shorted to 20.  This may be providing some kind of enable to the rest of the circuitry when the cable is plugged in, but it only seems to matter for J7.  So, perhaps this is some kind of enable specifically for the clock.
  
  All tests also pass if a jumper is installed on J7 between pins 18 and 20.
  
  Do you have the CLK cable plugged in when you get the errors?  If so, try a jumper on J7 instead.  If you still get failures, we may need to look closer at the circuitry associated with J7 pins 18 and 20.
  
  

  Code: [Select]

  --- unplugged clk pod cable J7 ---

pv> x do_loopback
Enter CTRL-C to stop
0x0000000c: Expected 0x55 got 0x00
0x0000000d: Expected 0xff got 0x00
0x0000000e: Expected 0xaa got 0x00
0x0000001c: Expected 0x55 got 0x00
0x0000001d: Expected 0xff got 0x00
0x0000001e: Expected 0xaa got 0x00
0x0000002c: Expected 0x55 got 0x00
0x0000002d: Expected 0xff got 0x00
0x0000002e: Expected 0xaa got 0x00
0x0000003c: Expected 0x55 got 0x00
0x0000003d: Expected 0xff got 0x00
0x0000003e: Expected 0xaa got 0x00
0x0000004c: Expected 0x55 got 0x00
0x0000004d: Expected 0xff got 0x00
0x0000004e: Expected 0xaa got 0x00
0x0000005c: Expected 0x55 got 0x00
0x0000005d: Expected 0xff got 0x00
0x0000005e: Expected 0xaa got 0x00
0x0000006c: Expected 0x55 got 0x00
0x0000006d: Expected 0xff got 0x00
0x0000006e: Expected 0xaa got 0x00
0x0000007c: Expected 0x55 got 0x00
0x0000007d: Expected 0xff got 0x00
0x0000007e: Expected 0xaa got 0x00
0x0000008c: Expected 0x55 got 0x00
0x0000008d: Expected 0xff got 0x00
0x0000008e: Expected 0xaa got 0x00
0x0000009c: Expected 0x55 got 0x00
0x0000009d: Expected 0xff got 0x00
0x0000009e: Expected 0xaa got 0x00
0x000000ac: Expected 0x55 got 0x00
0x000000ad: Expected 0xff got 0x00
Card 0
00000000: 0101 0101 0101 0101 0101 0101 0101
00000001: 0202 0202 0202 0202 0202 0202 0202
00000002: 0404 0404 0404 0404 0404 0404 0404
00000003: 0808 0808 0808 0808 0808 0808 0808
00000004: 1010 1010 1010 1010 1010 1010 1010
00000005: 2020 2020 2020 2020 2020 2020 2020
00000006: 4040 4040 4040 4040 4040 4040 4040
00000007: 8080 8080 8080 8080 8080 8080 8080
00000008: 0101 0101 0101 0101 0101 0101 0101
00000009: 0202 0202 0202 0202 0202 0202 0202
0000000A: 0404 0404 0404 0404 0404 0404 0404
0000000B: 0808 0808 0808 0808 0808 0808 0808
0000000C: 1010 1010 1010 1010 1010 1010 1010
0000000D: 2020 2020 2020 2020 2020 2020 2020
0000000E: 4040 4040 4040 4040 4040 4040 4040
0000000F: 8080 8080 8080 8080 8080 8080 8080
00000010: 0101 0101 0101 0101 0101 0101 0101
00000011: 0202 0202 0202 0202 0202 0202 0202
00000012: 0404 0404 0404 0404 0404 0404 0404
00000013: 0808 0808 0808 0808 0808 0808 0808
00000014: 1010 1010 1010 1010 1010 1010 1010
00000015: 2020 2020 2020 2020 2020 2020 2020
00000016: 4040 4040 4040 4040 4040 4040 4040
00000017: 8080 8080 8080 8080 8080 8080 8080
00000018: 0101 0101 0101 0101 0101 0101 0101
00000019: 0202 0202 0202 0202 0202 0202 0202
0000001A: 0404 0404 0404 0404 0404 0404 0404
0000001B: 0808 0808 0808 0808 0808 0808 0808
0000001C: 1010 1010 1010 1010 1010 1010 1010
0000001D: 2020 2020 2020 2020 2020 2020 2020
0000001E: 4040 4040 4040 4040 4040 4040 4040
0000001F: 8080 8080 8080 8080 8080 8080 8080

Total of 33 errors
Mod   B: TEST FAILED       # "do_loopback" (1, 1, -1)
pv>

--- plugged in clk pod cable J7 ---

pv> x do_loopback
Mod   B: TEST passed       # "do_loopback" (2, 1, 1)
pv>

--- jumper between pins 18 and 20 on J7 ---

pv> x do_loopback
Mod   B: TEST passed       # "do_loopback" (3, 1, 1)
pv>


  ---

  
• #139 Reply
  Posted by MarkL on 26 Oct, 2022 16:12
• A small follow-up on the J7 jumper thing...
  
  If the jumper on J7 pin 18 to 20 is in place, and a failure is induced by holding U121.39 DQMH high, the failures reported for both sections of do_loopback begin to make more sense.
  
  Also note do_clock_test succeeds in this case.
  
  I'm guessing that maybe to perform byte reads and writes to SDRAM (as opposed to the full 16-bit width for the SDRAM), the clock needs to be enabled.  The first test in the do_loopback output is byte oriented, and the second set is the full memory width.  Without the clock enabled, the byte oriented output had no relation to what was actually happening with the SDRAM.  Now, with the clock enabled, SDRAM failures do have an effect for both byte and word error sections.
  
  

  Code: [Select]

  U121.39 DQMH held high, J7 18 to 20 jumpered

pv> x do_loopback
Enter CTRL-C to stop
0x00000001: Expected 0x00 got 0x80
0x00000002: Expected 0x00 got 0x80
0x00000003: Expected 0x00 got 0x80
0x00000004: Expected 0x00 got 0x80
0x00000005: Expected 0x00 got 0x80
0x00000006: Expected 0x00 got 0x80
0x00000007: Expected 0x00 got 0x80
0x00000008: Expected 0x00 got 0x80
0x00000009: Expected 0x00 got 0x80
0x0000000a: Expected 0x00 got 0x80
0x0000000b: Expected 0x00 got 0x80
0x0000000c: Expected 0x55 got 0xd5
0x0000000f: Expected 0x00 got 0x80
0x00000010: Expected 0x00 got 0x80
0x00000011: Expected 0x00 got 0x80
0x00000012: Expected 0x00 got 0x80
0x00000013: Expected 0x00 got 0x80
0x00000014: Expected 0x00 got 0x80
0x00000015: Expected 0x00 got 0x80
0x00000016: Expected 0x00 got 0x80
0x00000017: Expected 0x00 got 0x80
0x00000018: Expected 0x00 got 0x80
0x00000019: Expected 0x00 got 0x80
0x0000001a: Expected 0x00 got 0x80
0x0000001b: Expected 0x00 got 0x80
0x0000001c: Expected 0x55 got 0xd5
0x0000001f: Expected 0x00 got 0x80
0x00000020: Expected 0x00 got 0x80
0x00000021: Expected 0x00 got 0x80
0x00000022: Expected 0x00 got 0x80
0x00000023: Expected 0x00 got 0x80
0x00000024: Expected 0x00 got 0x80
Card 0
00000000: 0101 0101 0101 0101 0101 0101 8101
00000001: 0202 0202 0202 0202 0202 0202 8202
00000002: 0404 0404 0404 0404 0404 0404 8404
00000003: 0808 0808 0808 0808 0808 0808 8808
00000004: 1010 1010 1010 1010 1010 1010 8010
00000005: 2020 2020 2020 2020 2020 2020 8020
00000006: 4040 4040 4040 4040 4040 4040 8040
00000007: 8080 8080 8080 8080 8080 8080 8080
00000008: 0101 0101 0101 0101 0101 0101 8101
00000009: 0202 0202 0202 0202 0202 0202 8202
0000000A: 0404 0404 0404 0404 0404 0404 8404
0000000B: 0808 0808 0808 0808 0808 0808 8808
0000000C: 1010 1010 1010 1010 1010 1010 8010
0000000D: 2020 2020 2020 2020 2020 2020 8020
0000000E: 4040 4040 4040 4040 4040 4040 8040
0000000F: 8080 8080 8080 8080 8080 8080 8080
00000010: 0101 0101 0101 0101 0101 0101 8101
00000011: 0202 0202 0202 0202 0202 0202 8202
00000012: 0404 0404 0404 0404 0404 0404 8404
00000013: 0808 0808 0808 0808 0808 0808 8808
00000014: 1010 1010 1010 1010 1010 1010 8010
00000015: 2020 2020 2020 2020 2020 2020 8020
00000016: 4040 4040 4040 4040 4040 4040 8040
00000017: 8080 8080 8080 8080 8080 8080 8080
00000018: 0101 0101 0101 0101 0101 0101 8101
00000019: 0202 0202 0202 0202 0202 0202 8202
0000001A: 0404 0404 0404 0404 0404 0404 8404
0000001B: 0808 0808 0808 0808 0808 0808 8808
0000001C: 1010 1010 1010 1010 1010 1010 8010
0000001D: 2020 2020 2020 2020 2020 2020 8020
0000001E: 4040 4040 4040 4040 4040 4040 8040
0000001F: 8080 8080 8080 8080 8080 8080 8080

Total of 33 errors
Mod   B: TEST FAILED       # "do_loopback" (1, 1, -1)

pv> x do_clock_test
Mod   B: TEST passed       # "do_clock_test" (1, 0, 1)
pv>

• #140 Reply
  Posted by DogP on 11 Nov, 2022 07:41
• Great troubleshooting information as always!
  
  Quick question - has anyone opened up one of the riveted pod housings (drilling out the rivets I assume), and have any tips on getting it closed back up and looking nice and keeping it usable?  Any idea where to buy small replacement rivets like that?  I'd prefer that over replacing with a screw and nut, though I guess that's an option.
  
  Basically, I noticed I had a few dead channels on one pod... I built a simple pattern generator to logic analyzer pod adapter to test all my pods, and also make it convenient to test various pattern generator sequences I was using.  After a little bit of testing, I found the channels are all working on the cards, but my A1 cable seems to have a few breaks in it near the 40-pin connector.  Wiggling the cable back and forth makes channels come and go.  I figure there are probably a few broken wires or solder joints that I could fix, rather than replacing the whole cable.
  
  Thanks,
  DogP

  ---

  

  

  

  

  
• #141 Reply
  Posted by TK on 12 Nov, 2022 03:57
• Quote from: DogP on 11 Nov, 2022 07:41

  Great troubleshooting information as always!
  
  Quick question - has anyone opened up one of the riveted pod housings (drilling out the rivets I assume), and have any tips on getting it closed back up and looking nice and keeping it usable?  Any idea where to buy small replacement rivets like that?  I'd prefer that over replacing with a screw and nut, though I guess that's an option.
  
  Basically, I noticed I had a few dead channels on one pod... I built a simple pattern generator to logic analyzer pod adapter to test all my pods, and also make it convenient to test various pattern generator sequences I was using.  After a little bit of testing, I found the channels are all working on the cards, but my A1 cable seems to have a few breaks in it near the 40-pin connector.  Wiggling the cable back and forth makes channels come and go.  I figure there are probably a few broken wires or solder joints that I could fix, rather than replacing the whole cable.
  
  Thanks,
  DogP
  

  Check the wires for damages before opening the POD
• #142 Reply
  Posted by DogP on 13 Nov, 2022 11:50
• Yeah, it appears that the cable is broken internally close to the pod (if I flex the cable near the end, the channels come and go).
  
  I popped open the pod, and each wire is a very small coax cable terminated inside the pod, and covered in a conformal coating.  So, I guess I can cut the cable back an inch or two until I get past all the breaks, and then re-terminate the cable... though it looks like it'll be a pretty tedious job.  For <$100 shipped I can get another L/A card with two more sets of cables (4 pods), which might just be worth it.  And I have 7 working pods (112 channels), so I guess it isn't that critical to get this last pod up and running immediately.
  
  To directly answer my previous question on rivets though... it looks like they're 1/16" diameter semi-tubular steel rivets with an oval head.  I think they should be 3/8" long (hole of pod assembly is ~0.330" deep, plus 0.040" clinch allowance), though this is the closest I found for sale, keeping the other specs correct: https://www.rivetsonline.com/steel-plated-semi-tubular-rivets-116/t060s00406o .
  
  DogP

  ---

  

  

  

  
• #143 Reply
  Posted by dorkshoei on 13 Nov, 2022 17:55
• I'd look on AliExpress for the rivets.  They'll be cheap. Maybe not exact but do you really care?
• #144 Reply
  Posted by MateKrisz on 16 Nov, 2022 21:57
• MarkL:
  I just now can reply, because of I was far away from my LA and I can't confirm your answer. Now back to work
  Good news that you found this. I always tested the board without cables. I have the cable set but the PODs are missing for me. I will test the card with your solution. Before I read your messages, I was thinking about how easiest the test the memory chips on the board. These chips used on the simple PC100 RAMs around the P1-P2 era. I bought a 32MB (4x8 MB) and a 64MB modules. My idea that I move 1 chip to ram module and test it with simple memtest x86. But first time I will check your idea, I hope some test will be PASS.
  
  DogP:
  The 16555 card restoration delayed because I got a 16557 also in untested condition. If it's pass I use it with 16555 both as standalone. Anyway what better? 2x 16555 as Master-Slave or 1x 16555 + 1x 16557 as standalone?

  ---

  
• #145 Reply
  Posted by MateKrisz on 16 Nov, 2022 23:21
• Hi MarkL,
  
  I followed your insturctions. Here is my results:
  Jumper on J7, 18-20. Only do_ram_test and do_dram_test is PASS others failed extept 100,180,300,ext tests they are untested.
  I plugged the cables. Only the cables because of the PODs is missing for me. Results is same with the previous test.
  I'm surprised that my LA ignored the J7 jumper settings.
  
  
• #146 Reply
  Posted by MateKrisz on 16 Nov, 2022 23:42
• I ran the x modtest on the 16557D board. All passed extept the do_comparator_stest is failed. I will check the traces on this board. Maybe find somthing broken trace.
• #147 Reply
  Posted by hackwell on 20 Nov, 2022 17:47
• Hi everybody
  
  I ran into the same issue yesterday with my 3 16718A modules. I didn't notice the failures until I tried to use pods 2 and 3 which failed on the 3 boards.
  This tread helped me a lot , and I was able to fix 2 out of the 3 boards. Sure enough a bunch of tracks were sent to the 9th dimension and I had to do some heavy sewing but things went quite well.
  So now I'm left with one module with an error on U2 U13 and U64 U67. This seems not to be related to corrosion and may have occurred a long time ago. maybe a faulty DRAM of bad Xilinx chip. I guess I'll have to build an extension cable and use my Tek LA to troubleshoot that one.
  
  but I still have an issue with the allegedly good boards : they both pass all the tests individually (with vp and the GUI) , but my 16702B throws an error when using pods 3 and 4 of the master card when it's used in multicard configuration. The other one works just fine on all 4 pods
  
  the thing is that when vp is ran against a multicard setup it relies on the master, and tests the expander through it.
  weirdly enough , the failing pods 2 and 3 are located on the master card , and it passes all the self tests...
  
  I'm a bit lost here
  
• #148 Reply
  Posted by hackwell on 22 Nov, 2022 17:47
• A quick follow up to my previous message : I found another open track which was responsible for the memory error of my third card.
  It was located between the 2 FPGAs. It seems that this interconnection is used to access the whole memory space from the backplane bus , if it makes sense
• #149 Reply
  Posted by MateKrisz on 27 Nov, 2022 17:33
• Hi MarkL,
  
  I little waiting because of I ordered a HDMI 51mp microscope and I would like to check the traces after this is arrived.
  I tested the PC100 RAMs, I have two module, both is 100% tested with Memtestx86. So if need spare memory IC I have lot of.