Author Topic: Series defect on agilent 167xx boards?  (Read 40369 times)

0 Members and 3 Guests are viewing this topic.

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #75 on: March 30, 2021, 03:25:38 pm »
Yep, Fixed the 16534.
Ah, great!
Quote
...
Any suggestions on best method to "Safely" remove the plastic runners without damaging traces?  i pulled up two pads removing one.. but they were just pogo pin test pads, so was able to repair without issue.
Heat.

Heating the runners and the board around them before trying to pull them off works best for me.  However, it usually leaves behind half of the adhesive strip.  So once I get all the runners off, I go back and heat the leftover adhesive and carefully scrape it while it is hot with a piece of plastic with a sharp edge.

For scraping, I've read some people use an old credit card cut down to size.  I've found I need to be a little more aggressive and use the edge on a length of 3/8" square PVC.  When all 4 edges get dull and don't dig into the adhesive, I cut the end off for a fresh four edges.  Keeping a sharp edge is key, because when the edge gets dull it will slip and head directly for some innocent passives.

I then clean up any remaining residue by repeatedly sticking Gorilla tape to the residue, and then finally wipe the runner areas with IPA.  If it becomes obvious that IPA will take forever with really stubborn residue, and I will resort to pro-strength Goof Off.  Goof Off never fails, but it's nasty stuff.

If the corrosion is wide spread, I will also scrub the whole bottom of the board with IPA and a soft brush.
 

Offline Hamster

  • Regular Contributor
  • *
  • Posts: 116
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #76 on: March 30, 2021, 04:07:31 pm »
Cool, i been using a blue "cell phone case separator" but will add some heat..

I have one board that i removed the two runners in the area i had damage on the one for the memory bus errors, but see no damage, so i may try out using some wd40 as its known to remove adhesive as well.

i had a 16534 ( working ) that didn't use the black adhesive, and shows 0 signs of corrosion, so its really just the ugly black adhesive
Arcade Board Repair Guru.  [ twitch: HammysHangout , youTube: Hammy Builds ]
 

Offline Hamster

  • Regular Contributor
  • *
  • Posts: 116
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #77 on: May 24, 2021, 04:09:41 pm »
Anybody have an ideas on this? 16911A PSync Fail , Card still works, but 1 channel seems to flop in the wind ( same have of card with U42 ) -- U42 has been replaced and still same result.

Here is the error, I am pretty sure its a bad via, Anybody know what the "PSync" Signal is? were its located? -- Would be helpful if we had some form of schematics or signal identification on these cards, If there are no longer supported and nobody is repairing them..

16911A Logic Analyzer(A) running...
  System Clocks (J/K/L/M/Psync) Test running...
      TEST  1: JCLK routed to all chips...
      TEST  2: KCLK routed to all chips...
      TEST  3: LCLK routed to all chips...
      TEST  4: MCLK routed to all chips...
      TEST  5: PSYNC A routed to all chips...
      Slot A, Chip 0, RAM U42: MAC:0x000000, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000000 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000001, nPort 0 MSW, exp:0x2499 nActual:0x3499
    FAIL: mode=PIO addr=0x6208 sample=0x00000004 word=msw exp=0x2499 act=0x3499 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000003, nPort 0 MSW, exp:0x9924 nActual:0x8924
    FAIL: mode=PIO addr=0x6208 sample=0x0000000c word=msw exp=0x9924 act=0x8924 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000005, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000014 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000007, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x0000001c word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000008, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000020 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000a, nPort 0 MSW, exp:0x9264 nActual:0x8264
    FAIL: mode=PIO addr=0x6208 sample=0x00000028 word=msw exp=0x9264 act=0x8264 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000b, nPort 0 MSW, exp:0x2649 nActual:0x3649
    FAIL: mode=PIO addr=0x6208 sample=0x0000002c word=msw exp=0x2649 act=0x3649 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000e, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000038 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000f, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x0000003c word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000011, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000044 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000012, nPort 0 MSW, exp:0x2499 nActual:0x3499
    FAIL: mode=PIO addr=0x6208 sample=0x00000048 word=msw exp=0x2499 act=0x3499 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000014, nPort 0 MSW, exp:0x9924 nActual:0x8924
    FAIL: mode=PIO addr=0x6208 sample=0x00000050 word=msw exp=0x9924 act=0x8924 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000016, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000058 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000018, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000060 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000019, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000064 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00001b, nPort 0 MSW, exp:0x9264 nActual:0x8264
    FAIL: mode=PIO addr=0x6208 sample=0x0000006c word=msw exp=0x9264 act=0x8264 buf=0x00000000
    > Slot A, Chip 0: PSYNC with Chip 9 master  Test Failed!
      Slot A, Chip 0: Bad RAMs:  U42Bad Data: 0x1000
      TEST  6: PSYNC B routed to all chips...
      Slot A, Chip 0, RAM U42: MAC:0x000000, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000000 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000001, nPort 0 MSW, exp:0x2499 nActual:0x3499
    FAIL: mode=PIO addr=0x6208 sample=0x00000004 word=msw exp=0x2499 act=0x3499 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000003, nPort 0 MSW, exp:0x9924 nActual:0x8924
    FAIL: mode=PIO addr=0x6208 sample=0x0000000c word=msw exp=0x9924 act=0x8924 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000005, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000014 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000007, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x0000001c word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000008, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000020 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000a, nPort 0 MSW, exp:0x9264 nActual:0x8264
    FAIL: mode=PIO addr=0x6208 sample=0x00000028 word=msw exp=0x9264 act=0x8264 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000b, nPort 0 MSW, exp:0x2649 nActual:0x3649
    FAIL: mode=PIO addr=0x6208 sample=0x0000002c word=msw exp=0x2649 act=0x3649 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000e, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000038 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000f, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x0000003c word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000011, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000044 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000012, nPort 0 MSW, exp:0x2499 nActual:0x3499
    FAIL: mode=PIO addr=0x6208 sample=0x00000048 word=msw exp=0x2499 act=0x3499 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000014, nPort 0 MSW, exp:0x9924 nActual:0x8924
    FAIL: mode=PIO addr=0x6208 sample=0x00000050 word=msw exp=0x9924 act=0x8924 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000016, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000058 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000018, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000060 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000019, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000064 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00001b, nPort 0 MSW, exp:0x9264 nActual:0x8264
    FAIL: mode=PIO addr=0x6208 sample=0x0000006c word=msw exp=0x9264 act=0x8264 buf=0x00000000
    > Slot A, Chip 0: PSYNC with Chip 8 master Test Failed!
      Slot A, Chip 0: Bad RAMs:  U42Bad Data: 0x1000
      TEST  7: Each PSYNC routed to half the chips...
      Slot A, Chip 0, RAM U42: MAC:0x000000, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000000 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000001, nPort 0 MSW, exp:0x2499 nActual:0x3499
    FAIL: mode=PIO addr=0x6208 sample=0x00000004 word=msw exp=0x2499 act=0x3499 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000003, nPort 0 MSW, exp:0x9924 nActual:0x8924
    FAIL: mode=PIO addr=0x6208 sample=0x0000000c word=msw exp=0x9924 act=0x8924 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000005, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000014 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000007, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x0000001c word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000008, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000020 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000a, nPort 0 MSW, exp:0x9264 nActual:0x8264
    FAIL: mode=PIO addr=0x6208 sample=0x00000028 word=msw exp=0x9264 act=0x8264 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000b, nPort 0 MSW, exp:0x2649 nActual:0x3649
    FAIL: mode=PIO addr=0x6208 sample=0x0000002c word=msw exp=0x2649 act=0x3649 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000e, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000038 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00000f, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x0000003c word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000011, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000044 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000012, nPort 0 MSW, exp:0x2499 nActual:0x3499
    FAIL: mode=PIO addr=0x6208 sample=0x00000048 word=msw exp=0x2499 act=0x3499 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000014, nPort 0 MSW, exp:0x9924 nActual:0x8924
    FAIL: mode=PIO addr=0x6208 sample=0x00000050 word=msw exp=0x9924 act=0x8924 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000016, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000058 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000018, nPort 0 MSW, exp:0x9249 nActual:0x8249
    FAIL: mode=PIO addr=0x6208 sample=0x00000060 word=msw exp=0x9249 act=0x8249 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x000019, nPort 0 MSW, exp:0x2492 nActual:0x3492
    FAIL: mode=PIO addr=0x6208 sample=0x00000064 word=msw exp=0x2492 act=0x3492 buf=0x00000000
      Slot A, Chip 0, RAM U42: MAC:0x00001b, nPort 0 MSW, exp:0x9264 nActual:0x8264
    FAIL: mode=PIO addr=0x6208 sample=0x0000006c word=msw exp=0x9264 act=0x8264 buf=0x00000000
    > Slot A, Chip 0: PSYNC with both masters Test Failed!
      Slot A, Chip 0: Bad RAMs:  U42Bad Data: 0x1000
  ...System Clocks (J/K/L/M/Psync) Test ended. Result: Failed***
...16911A Logic Analyzer(A) ended. Result: Failed***


____ ALL OTHER TESTS PASS ____
Arcade Board Repair Guru.  [ twitch: HammysHangout , youTube: Hammy Builds ]
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #78 on: February 06, 2022, 12:47:35 pm »
This seems to be the place to discuss corrosion troubleshooting/repair for these boards, so here goes mine -

I've got a 16750B that had some corrosion (I removed the runners and cleaned everything up), and was failing quite a few self tests (Analyzer Chip Memory Bus Test, System Clocks Test, Analyzer Memory Bus SU/H Measure, Comparators Test, Zoom Acquisition Test, and Zoom Chip Select Test).  I repaired about a dozen corroded traces, and have everything passing except the Zoom Acquisition Test, and Zoom Chip Select Test.

Does anyone have thoughts on Zoom failures?  Comparing the non-Zoom 16715 to the boards with Zoom, I think the Zoom circuitry is the 5x 1NB4-5040 chips, and a couple other chips nearby.  I've inspected the areas around there very closely for corrosion under the microscope, as well as checked continuity anywhere I've seen anything suspicious looking... but haven't found anything.

Below is the output from pv (d=9, r=9).  It looks similar to the failure from this thread: https://www.eevblog.com/forum/testgear/agilent-16717a-comparator-and-zoomchipseltest-failures/ , though I'm not sure that was ever resolved.  From reading the log, it looks like maybe FISO #0 is working, but #1-#4 aren't (there's at least one FISO failed message for each, except #0).  The 0x8088, 0x888, and 0x808 regardless of expected data sorta gives me the feeling of a floating bus, like the chip isn't getting selected (especially since it's failing the chip select test).

I'm guessing nobody knows which pin is the chip select, or where it comes from, right?

I guess if everything except Zoom works on this board, that'd still be usable... but of course I'd rather fix it if I can. :)

Code: [Select]
pv> x zoomAcqTest
  Slot A: FISO 4 - Data Bits Stuck HIGH: 0xf7
> Slot A: Zoom Acquisition Data Lines Test Failed!
  Slot A: FISO 3 - Data Bits Stuck LOW:  0xf3
  Slot A: FISO 3 - Data Bits Stuck HIGH: 0xf7
  Slot A: FISO 2 - Data Bits Stuck HIGH: 0xf7
  Slot A: FISO 1 - Data Bits Stuck LOW:  0xf7
  Slot A: Chip9: edgeCount=1623, exp=811
> Slot A: Chip9: Zoom Acquisition Data Frequency Test Failed!
  Slot A: Chip8: edgeCount=0, exp=811
> Slot A: Chip8: Zoom Acquisition Data Frequency Test Failed!
Mod   A: TEST FAILED       # "zoomAcqTest" (4, 4, -1)


Code: [Select]
pv> x zoomChipSelTest
  Slot A: Filling FISOs for Pods #1 with zeroes...
    Slot A: Checking FISO #4...
    Slot A: Checking FISO #3...
    Slot A: Checking FISO #2...
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
      Actual = 0x8808, Expected = 0xadff
     Slot A: FISO #2 failed.
    Slot A: Checking FISO #1...
    Slot A: Checking FISO #0...
  Slot A: Filling FISOs for Pods #2 with zeroes...
    Slot A: Checking FISO #4...
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
      Actual = 0x888, Expected = 0xffff
     Slot A: FISO #4 failed.
    Slot A: Checking FISO #3...
    Slot A: Checking FISO #2...
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
      Actual = 0x8808, Expected = 0xdaff
     Slot A: FISO #2 failed.
    Slot A: Checking FISO #1...
    Slot A: Checking FISO #0...
  Slot A: Filling FISOs for Pods #3 with zeroes...
    Slot A: Checking FISO #4...
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
      Actual = 0x888, Expected = 0x5aad
     Slot A: FISO #4 failed.
    Slot A: Checking FISO #3...
    Slot A: Checking FISO #2...
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
      Actual = 0x8808, Expected = 0xffad
     Slot A: FISO #2 failed.
    Slot A: Checking FISO #1...
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
     Slot A: FISO #1 failed.
    Slot A: Checking FISO #0...
  Slot A: Filling FISOs for Pods #4 with zeroes...
    Slot A: Checking FISO #4...
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
      Actual = 0x888, Expected = 0xadda
     Slot A: FISO #4 failed.
    Slot A: Checking FISO #3...
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
      Actual = 0x808, Expected = 0xad5a
     Slot A: FISO #3 failed.
    Slot A: Checking FISO #2...
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
      Actual = 0x8808, Expected = 0xff5a
     Slot A: FISO #2 failed.
    Slot A: Checking FISO #1...
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
      Actual = 0x808, Expected = 0xffff
     Slot A: FISO #1 failed.
    Slot A: Checking FISO #0...
> Slot A: Zoom Acquisition Chip Select Test Failed!
Mod   A: TEST FAILED       # "zoomChipSelTest" (1, 1, -1)



I also have a 16533A that sometimes passes some or all tests, and sometimes fails some or all tests.  I pulled the runners, though didn't see any corrosion that looked like it needed repair.  I haven't dug into this one at all yet (plan to double-check for corrosion), but if anyone's got tips to check for this one, I'd appreciate it as well.

Thanks,
DogP
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #79 on: February 06, 2022, 10:55:18 pm »
...
I'm guessing nobody knows which pin is the chip select, or where it comes from, right?
...
Well, I have a good guess.

From some troubleshooting I did on these boards a couple of years ago, it appears that pin 43 is the chip select on the 1NB4-5040 zoom chips (U27 U34 U42 U49 U55).  They go to the Altera FLEX FPGA (U26) near the backplane connector:

  Pin 43 (CS)     U26 pin
  -----------     -------
     U27            138
     U34            136
     U42            137
     U49             10
     U55             95

Since FISO 0 is the only one passing the test, perhaps its CS is floating and it's not getting off the bus while the other chips are being accessed.  I don't know which of the zoom chips is FISO 0, though.

If it's of any use, the data bus pins on the 1NB4-5040 appear to be 46, 48, 51, 53, 55, 57, 60, and 62.  But there's no other clues on that bus to be able to guess at the D7:D0 labels.

Another thing you could do is set up a script to loop the zoomChipSelTest in pv and watch the various pins on the zoom chips with a scope and compare between chips, or if you have it, with another card that's working (or at least passes that test).

While looping tests, another trick is to perturb various signals with a 50R or 22R resistor to ground (use whatever value clearly causes a logic low).  This technique can help sort out what's working and can be used to identify data bit positions by watching the effect on the detailed debug output.

I would also check that the two regulators near the pod connectors, U20 and U21, are putting out the right voltages.  They are not present on 16715A cards which do not have zoom feature, so they have something to do with the zoom chips that get populated.

To save you from unsoldering the heatsinks, U20 is an LM2991S and U21 is an LT1086CM.  U20 should have -1.8V on its output, and U21 should have +3.3V on its output.

While I'm at it, the other mystery chip associated with the zoom feature, 1821-4731 (near U27, I don't see a U designation), appears to be a differential clock distribution driver.  When you gang these boards together, this chip on the master board becomes the master clock for all the zoom chips on the other boards.

A hint on probing: I believe (but can't prove) all signals are accessible somewhere on the bottom of the board on round pads domed with solder.  You'll see a lot of vias from the top that go underneath just to connect to a probe pad.  Nice touch by HP/Agilent.  It makes it easier to turn the whole chassis over, take the bottom off, and probe these cards from the bottom.  Maybe they were for automated testing.

If you probe from the top, all the TPxx hooks soldered into the board are GND for convenience.

Quote
I also have a 16533A that sometimes passes some or all tests, and sometimes fails some or all tests.  I pulled the runners, though didn't see any corrosion that looked like it needed repair.  I haven't dug into this one at all yet (plan to double-check for corrosion), but if anyone's got tips to check for this one, I'd appreciate it as well.
Like the above, I would check ALL the regulator outputs.  The output voltages are labeled near the regulators.  I've had more than one 16533A/16534A with way out of spec voltages because of resistors in the regulator's feedback network that had gone bad.  In a couple of cases it caused erratic behavior (like would pass calibration only some of the time).
 
The following users thanked this post: oPossum

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #80 on: February 07, 2022, 12:49:18 am »
Thanks a TON for that info.  I'll dig into this more tonight... hopefully I can track this down.

I've had more than one 16533A/16534A with way out of spec voltages because of resistors in the regulator's feedback network that had gone bad.  In a couple of cases it caused erratic behavior (like would pass calibration only some of the time).
I decided to take another look at the scope card... today, it seems to be consistently passing the FISO test, but failing everything else.  What kind of tolerance on these voltages is OK?  I pulled the bottom off the chassis and checked the voltages... at the regulator outputs I'm getting:
+6V = +6.11V
-6V = -6.19V
+7.3V = +7.31V
-2V = -2.12V
+2V = +1.84V

So... not TOO far off, but not dead-on, if that matters.

I did find several vias that looked pretty bad.  The two in the first picture look like they go to GND, and I still get continuity from the top to GND, so I'm not too worried about those.  I'm not sure about the other two... the one goes from the outer layer to an inner layer, and the other goes from an inner layer to another inner layer.  So I don't know where they're supposed to go, nor whether they're actually getting there.

Is there a way to get better debugging info from the oscilloscope self-test?  Even with d=9 r=9, I only get verbose output from testTrigger.  I assume the third number is the return code... are those meanings defined anywhere?:
Code: [Select]
pv> x modtests
Mod   C: TEST passed       # "testFISO" (1, 0, 1)
Mod   C: TEST NOT EXECUTED # "testADC" (0, 0, 0)
Mod   C: TEST FAILED       # "testDAC" (1, 1, -3)
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Qual
Fail Holdoff
Fail Holdoff
Mod   C: TEST FAILED       # "testTrigger" (1, 1, -2047)
Mod   C: TEST FAILED       # "testTimebase" (1, 1, -3)
Mod   C: TEST FAILED       # "testIMB" (1, 1, -1)
pv> x testADC

1.  Disconnect all stimulus from Channels 1 and 2.
2.  Press OK to continue. [OK]

Mod   C: TEST FAILED       # "testADC" (1, 1, -1)

I saw your post about the DebugScope file, but that didn't seem to give any additional troubleshooting info.


BTW, did you ever make your right angle adapter board concept from this thread: https://www.eevblog.com/forum/testgear/agilent-16717a-comparator-and-zoomchipseltest-failures/msg3094078/#msg3094078 ?

Thanks,
DogP
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #81 on: February 07, 2022, 11:01:13 am »
I looked into the 16750B card some more... I confirmed continuity of the chip select pins you mentioned.  I inspected the traces more, checking continuity across all traces going across/through the runner sections, and looked for any signs of corroded vias (didn't see any).  I also checked the voltages at the two regulators... they're 3.31V and -1.74V (seems like they should be close enough).

I also noticed that I get this error in pv, but it only shows up the first time I run the tests (right before zoomAcqTest fails).
Code: [Select]
Mod E: Unable to Detect WRAP Flag.  Possible Board Fault.

Do you know anything about the WRAP flag?

Thanks,
DogP
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #82 on: February 07, 2022, 08:57:40 pm »
Ok, we've got two things going here...  First the 16533A.

But pre-first, a few general comments:

- If you haven't done so already, I'd strongly recommend reading the Theory section in the Service Guide for the cards you're trying to fix.  I've found they're very accurate and must have been written by the hardware and software developers.  It's the only service info us mere mortals have, so every little detail can be (and usually is) important.

- And along with that, read the Self-Tests Description.  Like the Theory section, every word can be valuable when trying to decipher the debug output.

- When running pv, I've found that it's almost always the case that the first thing that fails is the thing that has to be fixed first.  pv doesn't understand failure dependencies, and it will try to use a failed sub-system to do further validation, which in all likelihood will cause those subsequent tests to also fail.  I'm not saying to ignore the subsequent failure output, but take it with a grain of salt and scan the output for further clues regarding the first failure.

Ok, now back to the 16533A.  I would focus first on the DAC.  Those regulator voltages look ok to me.

I agree that for the scope cards the pv output and the DebugScope output are fairly worthless.  There's some tantalizing strings to be found in the 16533A/16534A pv driver (different that the operational driver) that implies there's more debugging to be had.  I can't figure out how to access it.  (Anyone up for some assembly-level reverse engineering?  DDE is provided on the system.)

If the scope card will run enough to give you a trace or at least let you onto the configuration screen, you can start to experiment with the DAC.  Move the trigger up and down and the trace offset up and down (even if the trace is off the screen).  Watch the trigger and offset DAC outputs to see if it's responding.

The DAC is U200, HP part 1SJ2-0102, a 24-pin narrow DIP.  I have figured out this much:

     Pin        16533A/16534A Function
  ---------     ----------------------
   1 CH13       Ch2 Trigger Level
   2 CH14       Ch1 Trigger Level
   3 CH15
   4 DIN
   5 DCLK
   6 DGND
   7 DVDD       5V
   8 DAC_CLK    19.66080MHz
   9 DL_EN
  10 CH0        Ch1 Offset
  11 CH1        Ch2 Offset
  12 CH2

  13 CH3
  14 CH4
  15 CH5        "Startable Oscillator"?
  16 CH6
  17 CH7
  18 AVDD       +5.000V
  19 AGND
  20 CH8        DC Cal
  21 CH9        ? (is either 0V or 5V)
  22 CH10
  23 CH11
  24 CH12

It's a PWM DAC, so you won't see a nice analog voltage on the output pins unless you have a DMM with a good filter.  The 3478A is in that category.  If a DMM doesn't work for you, you can look with a scope, or you can reverse-engineer the PWM filter on the output and look at the voltage after the filter.

pv moves around the DAC output voltages to force triggers, so if the DAC is failing, this is a good example of why subsequent tests will also fail.

There's more than anyone will want to know about this DAC in the Feb 1992 HP Journal, page 48:

  http://hparchive.com/hp_journals

There's also a CLIP for the 546xxA digital scopes which use the DAC.  The schematic could be helpful.  This particular site looks a dubious, but you can search around for the file name for other locations:

  http://bee.mif.pg.gda.pl/ciasteczkowypotwor/HP/546XXA_CLIP_Package.zip

I've encountered bad resistors in the DAC area.  Alexandre Souza did a nice blog on one particular resistor that has been reported as bad 4 times:

  https://tabajara-labs.blogspot.com/2019/05/repair-of-hp16533a-and-for-that-matter.html

Did you try a calibration?  It will fail, but it goes through different steps and puts a lot more info in the DebugScope directory if you have it enabled.  Maybe there's some clues lurking there with what fails or what it puts in the debug files.

I never got around to making the angle adapter.  I kept finding ways to troubleshoot cards from the underside.  I thought I could find a 0.1" male angle header with long enough pins but I couldn't.  It's going to need a short PCB and I got lazy.

It looks like you still have copper on those vias.  They're probably ok but we can get back to them.  The first is in the timebase area and the other next to an ADC.  They shouldn't affect the operation of the DAC.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #83 on: February 07, 2022, 09:15:15 pm »
I looked into the 16750B card some more... I confirmed continuity of the chip select pins you mentioned.  I inspected the traces more, checking continuity across all traces going across/through the runner sections, and looked for any signs of corroded vias (didn't see any).  I also checked the voltages at the two regulators... they're 3.31V and -1.74V (seems like they should be close enough).

I also noticed that I get this error in pv, but it only shows up the first time I run the tests (right before zoomAcqTest fails).
Code: [Select]
Mod E: Unable to Detect WRAP Flag.  Possible Board Fault.

Do you know anything about the WRAP flag?

Thanks,
DogP
I agree those voltages are fine.

I haven't heard of the WRAP flag before.

I suggest the next step on the 16750B is to start looking at the data pins and the chip select on the zoom chips with a loop test running in pv.  Make sure they look like good TTL levels.  I'm sure there's also a R/W pin there too, but I haven't looked for it.  It can probably be identified by looking on that side of the chip as a signal that's in sync with CS or the data lines and gets set up before CS goes true.

Other possibilities is that one of the zoom chips is misbehaving or some of the pins on the FPGA are not working.  I have seen both, and both times manifested themselves as bogus logic levels on the bus.  But I think we're far from concluding it's a dead chip at the moment.
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #84 on: February 08, 2022, 12:17:28 pm »
Once again, thanks for all that info!  I didn't have time to look at the DAC today, though I did try the calibration, which passed ADC, Gain, and Ext Trigger Skew, but failed everything else.

Not sure if it helps any... but it does seem that the scope is at least somewhat working.  When I press run, it sits at "Waiting for Prestore", but if I press stop, it does show the waveform.  And the waveform of both channels seems to be correct (I tested with a roughly 10kHz 2Vp-p sine wave, and it looks correct).

Attached is a zip of the debug output directory.  The one that jumps out at me is logictrig.file:
Code: [Select]
freq = 0, startable osc DAC = f800
Max Delay: No Trigger found
Min Delay, Rising Edge: No Trigger found
Trouble! Speeding up the startable oscillator to 1.08108e+08 Hz.
freq = 0, startable osc DAC = 8000
Error! Could not speed up the startable oscillator. Setting it to its maximum.
Min Delay, Higher Frequency : No Trigger found

Based on the frequency mentioned, I assume this is the 100 MHz oscillator referred to in the theory of operation?  I see your DAC notes say CH5 goes to the "Startable Oscillator", so I think you're right that I need to start by looking at the DAC.  It sounds like the sample clock comes from the 100 MHz oscillator, so I'd expect that the oscillator itself is working.

relay.file also had a couple error lines:
Code: [Select]
  Relay Errors Channel[0] =    112

  Relay Errors Channel[1] =    113

I had seen that post about the bad 100K resistor, and was one of the first things I checked.  I desoldered it, it measured 100K out of circuit, so I put it back.

So, I plan to look at the DAC next, but please let me know if you have any other thoughts.

Thanks,
DogP
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #85 on: February 08, 2022, 07:06:01 pm »
Ah, it's good that you at least have traces on the screen.  The waveform capture and the signal path to the ADCs is working.  That side of things is a real bear to troubleshoot.

Does the offset control move the traces around?  The fact that the traces are somewhat near the middle of the screen would imply the offset might be working.

My initial guess is that there's a problem with the trigger level.

Will it trigger on the other channel?  Probably not, based on the calibration output.  If not, we're probably looking at something in the DAC area that's common to both channels.

Can you get it to trigger by giving it a very large signal that's way off the screen?  Can you get it to trigger by moving the trigger control to the + and - extremes?

One thing you can do is look at the trigger level input to the analog trigger chip/section.  There are at least 3 versions of these boards.  Some have the analog trigger implemented with discrete ECL.  Can you post a picture of the top of your board?

Although better to probe the trigger level at the analog trigger section, you can also probe the trigger level in the DAC area.  Attached is a photo of the probe locations.  Do the trigger voltage levels change when you move the trigger control knob/menu?

Here are my notes from one particular card.  Your values are going to be a little different and depend on the stored calibration values.  It's probably obvious, but the scope must be running (acquiring) for it to update the DAC with any new trigger and offset values as you are changing them.

  Trigger position outputs from DAC area
    Condition Ch1/Ch2: Offset = 0.000V, 1.0V/div
 
      Trigger Level               Ch1 (V)  Ch2 (V)
      -----------------------     -------  -------
      Top graticule (+4.0v)       +0.297   +0.265
      Center graticule (0.0V)     +0.055   +0.027
      Bottom graticule (-4.0v)    -0.187   -0.211
 
  Offset position outputs from DAC area
    Condition Ch1/Ch2: Trigger = 0.000V, 1.0V/div
 
      Offset Level                Ch1 (V)  Ch2 (V)
      -----------------------     -------  -------
      Top graticule (-4.0v)       -0.177   -0.173
      Center graticule (0.0V)     -0.032   -0.026
      Bottom graticule (+4.0v)    +0.114   +0.121


Here's a good calibration from logictrig.file, if it helps:

  freq = 9.99985e+07, startable osc DAC = 7000
  Max Delay: No Trigger found
  Min Delay, Rising Edge: Yes Trigger found
    DurationCount = 1  DurationClock = 1
    DurationCount = 1  DurationClock = 0
    DurationCount = 0  DurationClock = 1
    DurationCount = 0  DurationClock = 0
    DurationCount = -1  DurationClock = 1
    Delay Adjust = 31
    Delay Adjust = 15
    Delay Adjust = 23
    Delay Adjust = 19
    Delay Adjust = 21
    Delay Adjust = 22
  DelayAdj = 22  DurationCount = -1  DurationClock = 1

I've attached all the files from a good calibration from two cards.  I'll take a look through your files and post again if I see anything that might help.

There's a lot of opamps in the DAC section.  One quick troubleshooting method is to get the pinout for each opamp and compare the inverting and non-inverting inputs.  The difference should be 0V.  This is a good first pass that can catch failing feedback networks, assuming none of them are being used as comparators which I haven't found to be the case (at least yet).

Another thing to check is the DC Cal output.  You can set the BNC to any voltage from 0 to +5.000V.  Try some different voltages and makes sure it works.

...
Based on the frequency mentioned, I assume this is the 100 MHz oscillator referred to in the theory of operation?  I see your DAC notes say CH5 goes to the "Startable Oscillator", so I think you're right that I need to start by looking at the DAC.  It sounds like the sample clock comes from the 100 MHz oscillator, so I'd expect that the oscillator itself is working.
To this day I'm still not sure what's meant by "Startable Oscillator", but you can certainly check the sample clock by setting up scope debug mode and then in the Calibration window new choices appear for the BNC output.  One of them is the 100MHz sample clock.  But given that you see waveforms, I think it's ok.

I think the first priority is to verify the trigger levels from the DAC.
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #86 on: February 09, 2022, 03:17:37 am »
Thanks!  I just did some quick testing, and here are some quick answers... I'll dig deeper later tonight.

>Does the offset control move the traces around?
Yes (though I assumed that was just where the software draws the trace on the screen).

>Will it trigger on the other channel?
No, neither channel will trigger.

>Can you get it to trigger by giving it a very large signal that's way off the screen?
It doesn't seem like it... I put a large sine wave going in, which looked like a square wave on the screen, but no trigger.

>Can you get it to trigger by moving the trigger control to the + and - extremes?
Again, doesn't seem to.  I tried min, max, and 0 at min and max scale on both channels, but doesn't seem to trigger.  I also tried trigger immediate, which I would have expected to just work (doesn't depend on a trigger level or anything), but it didn't.  Also tried both "All" and "Partial" Acquisition Memory to Display.

>Can you post a picture of the top of your board?
Attached.

>You can set the BNC to any voltage from 0 to +5.000V.
Yes, this does work.  The manual says this is one output from the 16-channel DAC... does that mean the DAC is probably OK?

Thanks,
DogP
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #87 on: February 09, 2022, 04:28:59 am »
It looks like you still have copper on those vias.  They're probably ok but we can get back to them.  The first is in the timebase area and the other next to an ADC.  They shouldn't affect the operation of the DAC.
I think one or both of these vias might be my problem.  The picture kinda sucks (slightly better ones attached), but there's definitely no copper pad left on the bottom of the one, and the other is missing the copper pad on both the top and bottom.  With no copper pad on both the top and bottom, I assumed there's little or no via plating left either.

On the one with a pad still on the top, I put a small dot of solder, and let it flow down into the via a bit.  On the one with no pads, obviously solder wouldn't stick to anything... so I took a piece of 30 AWG wire and poked it into the hole, and put some solder on it.  It wouldn't go all the way through, so I pushed a wire in both sides, hoping maybe the solder would flow to any exposed copper left in the hole.

Anyway, I had little hope, but I popped it in, and IT WORKS.

So, any chance you can trace where those two vias connect to, so I can do a better permanent repair?  Theoretically, I can trace them right now... but I have little confidence in this hack reliably making contact while I'm pressing my DMM probe against it.

To this day I'm still not sure what's meant by "Startable Oscillator"
I guess my assumption was that it's an oscillator with an enable line, but leave it to HP to complicate such a simple concept. ;)
https://patents.google.com/patent/US3921095A/en
Also discussed in the August 1978 HP Journal (and a few other HP Journals as well - I don't see any references outside of HP though)

Thanks,
DogP
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #88 on: February 09, 2022, 11:46:50 pm »
That's great you got it working!

Perhaps step #0 should be: "Always fix everything that appears it might be bad, even if it looks like it has nothing to do with the issue you're chasing."  That's one from the software side, actually.

I buzzed out those two vias.  I called them A and B.  Photos attached.

I don't know their function, but maybe I'll set up the chassis again and see what signal is on them.  They certainly both go to the timebase area.

If you manage to break it again in the process of fixing the vias, would you mind seeing if the external trigger input and the external trigger output are working?  I think we would have found the trigger levels from the DAC were (and are) working properly, and this would have been the next step.  It could provide a little insight for next time someone has a trigger issue.  Thanks!
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #89 on: February 10, 2022, 02:34:56 am »
>I buzzed out those two vias.  I called them A and B.  Photos attached.
Thanks!  Though the damaged vias don't visibly connect to anything, so there should be at least two endpoints for A and B, right?  Any idea where the other end(s) connect to?  Hmm... maybe the hybrid(s) since they're suspiciously close by?


>If you manage to break it again in the process of fixing the vias, would you mind seeing if the external trigger input and the external trigger output are working?
The odds seem pretty good that I'll break it again in the process, so yep, I can try that (especially likely if the one with w/ my wire through it is the cause).  Though I've never used external triggering on these scope cards... what's the best way to test?

It triggers on ECL levels, right?  I don't have much ECL stuff... can I drive it w/ a function generator, and what are safe input levels?  The manual seems to just discuss using those for daisy-chaining cards.  Is that an SMB connector?


Thanks,
DogP
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #90 on: February 10, 2022, 03:47:17 pm »
>I buzzed out those two vias.  I called them A and B.  Photos attached.
Thanks!  Though the damaged vias don't visibly connect to anything, so there should be at least two endpoints for A and B, right?  Any idea where the other end(s) connect to?  Hmm... maybe the hybrid(s) since they're suspiciously close by?
...
Yes, sorry for not engaging brain before posting.

Below is the other end of A, and one other place where B shows up.

I believe B is actually the -2V (-2.1V) supply.  It has a very low resistance to the output leg on the regulator.  If you look at the two locations where I found B in the bad area, it's connected to a decoupling cap to ground and a 68.1R resistor to a signal trace.  So B appears to be providing power to some ECL terminations.  Since the -2V supply is everywhere, it's really hard to say where that specific via goes on a working board.  The closest connection is what I've shown, which is my best guess.  It's not on any pins under the hybrid.

If your continuity on the via gets broken while you're fixing it, you'd be in a better position to verify the actual connectivity.

I would consider it a last resort, but it is possible to excavate the via if you can't get a reliable connection from the top or bottom.

EDIT: Oh, and one further note.  I did take a look at A and B with a scope.  Unsurprisingly, B doesn't move.  And A appears to be TTL and changes state while calibrating the logic trigger.  Not very exciting.
« Last Edit: February 10, 2022, 03:51:07 pm by MarkL »
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #91 on: February 11, 2022, 04:49:16 am »
Awesome... thanks for checking these!  Hopefully I can make a permanent repair to this tonight.

I haven't made any useful progress on the 16750B... I don't have any cables for these boards, so I can't test with any real signals at the moment.  I ordered a 16716A (parts board) w/ cable set, so I plan to put this repair on hold until the cables arrive.  I'm hoping if I can drive some signals into it, I'll be able to see what's actually working/not working better.

Of course, then I'll have a (likely dead) 16716A, which I'll want to try repairing too. :-P

I do plan to dig through some binaries and see if I can figure anything out on the WRAP flag.  I'm wondering if it's specific to the zoom chips, is it connected to the FLEX FPGA or another chip, etc.  Then maybe I can see how many of the zoom chip pins are shared, and which go back to the FLEX, and compare between the A and B boards that I have.

Thanks,
DogP
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #92 on: February 11, 2022, 01:11:29 pm »
Any chance you could double-check the measurements?  In my "currently working" state, I measured to confirm mine was actually making a good connection, even in the poor hacked state.

I get 0 ohms to your first point 'A', but would briefly get a beep on the 2nd point 'A', but showed about 230 ohms steady state.  If you can confirm this is 0 ohms on yours, I'll just add a jumper wire.

On 'B', I was getting about 9 ohms.  I probed around a bit, and found this ferrite near U502 that actually looked like 0 ohms.  Though I didn't find any other places this went, so I wonder if my repair is only half connected.  Can you see whether you get similar measurements with that ferrite, and if there's anywhere else you find it connected?

You might be right about excavating the via.  Since I've already soldered to mine, it's a bit messy and hard to see... if you shine a bright light behind your vias, can you see a trace leaving the sites, and if so, in which direction?  With the ground and power planes nearby, it's probably tough to see.

Thanks again!
DogP
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #93 on: February 11, 2022, 03:13:37 pm »
On the two "A" points I'm getting 1.2R, which is not too unreasonable but perhaps a bit high.

On B I'm getting 0.133R.  There are a lot beads in this section which are going to be low resistance and it's hard to tell which side we're on.  I used a high current across the two B points (1.5A limited to 0.4V) when I was searching and I couldn't find any components that had voltage drop across them, and an IR camera did not light up on anything.  It seems likely that the B via near the edge would have another leg or two coming off it given where they put it.

Do you know a friendly dentist or vet who would xray these areas for you?

If you want to hold on making any permanent repairs, I can do this later today:

- I will try to find the exact card type you have and double check the continuity.  I have a pile of these cards, and all of them are (or at least were) working.   I've been testing with a card that is the same as yours in these sections, but who knows.

- I will try a different tracing method.  I have a PCB track current probe (I-prober 520) and I will inject a signal between the seemingly connected points to follow the exact path of the buried traces.  I'll try to find and trace all the end points with this method too in case the signal splits into multiple paths at the damaged vias.
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #94 on: February 11, 2022, 05:40:10 pm »
If you don't mind doing further tests, I can certainly wait... but I appreciate the confirmation!  I just wanted to make sure it wasn't a case of quickly probing w/ a DMM continuity checker without noting the actual R value.  Of course I wonder why mine is higher resistance, but maybe it's just part of my board's defect(s).

>Do you know a friendly dentist or vet who would xray these areas for you?
Unfortunately, no... I tried to convince my boss to buy one a few years ago, but couldn't justify it.  I personally have a scintillator, but no xray source (nor safe way to operate one!).  Someday... ;)

Thanks,
DogP
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #95 on: February 11, 2022, 09:49:53 pm »
Is your board a 16533-66504 on the stickers in the lower right?  I have one, but before I dig in I wanted to confirm because it's not clear in your photo.
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #96 on: February 11, 2022, 11:27:31 pm »
Is your board a 16533-66504 on the stickers in the lower right?
Yes, that's correct.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2132
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #97 on: February 12, 2022, 12:43:22 am »
Ok, I've done the verification with my 16534-66504 board.  It's the same as your 16534-66504 except for the model setting resistors, as far as anyone knows.

I can confirm the resistances are the same for both the A and B vias that I posted before.

After tracing with the I-prober...

The A endpoints are correct as previously shown.  I was unable to find that A goes anywhere else.

The B endpoints are numerous.  In most locations where you'll find B, you'll also find a 68.1R termination resistor and an MLCC.  That's no surprise.  There's a ton of them on the back near the center of the board.

The internal trace at the broken B via goes horizontally in both directions parallel to the edge of the board.  I was not able to find any trace that went vertically coming out of the broken via.  If you look at the photo, there's another B via to the right.  I'm guessing the purpose of the broken B via was to change layers, and then probably went back to the original layer with the B via on the right.  From that via, the B trace continues on towards the front of the card, turns up until it gets to the external trigger output, and then dives back towards the center of the board where it appears to power most, if not all, of the ECL terminations.  I can image lots of things would break if these terminations did not have power.  Most likely this was your trigger failure.

My suggestion would be to jump the left B via/traces and the right B via shown in the photo near the bottom edge of the board.
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #98 on: February 12, 2022, 01:39:11 am »
Awesome... thanks SO much for all this info!  Hopefully I'll get this fixed up tonight.  And hopefully the seller on ebay gets around to shipping the LA card/cables that I ordered sometime soon, so I can get that other board repaired, and start putting this machine to use. :-P

Thanks,
DogP
 

Offline DogP

  • Regular Contributor
  • *
  • Posts: 95
  • Country: us
Re: Series defect on agilent 167xx boards?
« Reply #99 on: February 12, 2022, 10:36:03 am »
Got this board repair wrapped up... added the jumper wires as you recommended, tacked it down with some nail polish, and everything seems to be 100%.

BTW, it looks the 9 ohm measurement on my board was the connection from the left 'B' to the middle 'B'.  I had 0 ohms from the middle 'B' to the right 'B'.  Weird...

Thanks again for all the measurements, pics, etc!  I'll post if I make any progress on the 16750B, WRAP flag, etc.

DogP
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf