Series defect on agilent 167xx boards?

[dorkshoei]

Understood.  I left my runners off, and I dislike conformal coatings passionately.  Time will tell if I'm wrong.

I'm fairly accident prone by nature and just pulling the cards out over the last couple of days I had to be very careful as they *WILL* clash against each other (with the runners removed). 

My logic is that (if you read the webpage on replacing the runners) it was speculation by the 3M app engineer that this tape would work best.    I figure conformal coatings (I used silicone) are well proven wrt traces so I doubt very much they will cause an issue and maybe if there is a long term issue with the replacement 3M tape it will help prevent damage. 

Of course it took 20+ years for the issue to occur with the original OEM tape so I suspect I'll be well into senility before anything happens but ......

On the 16534A card again...

Besides the previous question on the self-test, are the cal errors associated with one channel or both?

Both.    I just removed the runners from the failing board.

It still works (both channels) connected to my Siglent function generator.  I tried a variety of waveforms and pulsing.   All worked.   Maybe slightly noisier than the fully working one.

I just re-ran calibration and didn't get the previously mentioned 'whoa this board has issues are you sure you want to continue' message and this time Trigger Delay passed but ADC, Gain and Offset still fail on both channels.

Same calibration T cable works fine on the other card.

You can probe two cards at the same time by using a 16701B expansion chassis, or a home-made card extender.  User DogP has some gerbers available for an extender that works well:

I'd seen this before.   I assume by "two cards at same time" one is via removing the unit cover.

I'd like a 16701B.  One of my units came with the cable to connect.  They're stupid expensive.   Max I'd pay is $50 and it would need to be local.

I'm parting out a couple of 16700Bs.    I think one has opt-003.   I've had zero luck selling them for $100.   Just mentioning it in case anyone wants any parts (for spares).   I'll probably keep the boards from one for spares for my 16702B.      I also have a 16702B that will be for sale (two logic cards (low end) with original runners replaced,  all cables/pods, optional pattern gen card) if anyone is interested.

[MarkL]

...
Besides the previous question on the self-test, are the cal errors associated with one channel or both?

Both.    I just removed the runners from the failing board.

It still works (both channels) connected to my Siglent function generator.  I tried a variety of waveforms and pulsing.   All worked.   Maybe slightly noisier than the fully working one.

I just re-ran calibration and didn't get the previously mentioned 'whoa this board has issues are you sure you want to continue' message and this time Trigger Delay passed but ADC, Gain and Offset still fail on both channels.

Same calibration T cable works fine on the other card.

It's good that you're getting a waveform showing that the sampling and horizontal stuff is working.  That can be really difficult to troubleshoot.

Does the offset work?  Can you make it trigger on different vertical points on the waveform edge?  And if either does work, are they displaying a sane voltage?

I'd check out the regulator outputs.  There's also some reference voltages common to both channels that are generated by the opamps near the DAC (U200).  You can compare with the working card.

Here are a few probe points that might help:

  https://www.eevblog.com/forum/repair/series-defect-on-agilent-167xx-boards/msg3994748/#msg3994748

Problems with the DAC, trigger, offset, and reference circuitry would show up there.  If it's noisy, maybe you have another bad cap on one of the voltage rails?

You can probe two cards at the same time by using a 16701B expansion chassis, or a home-made card extender.  User DogP has some gerbers available for an extender that works well:

I'd seen this before.   I assume by "two cards at same time" one is via removing the unit cover.

I'd like a 16701B.  One of my units came with the cable to connect.  They're stupid expensive.   Max I'd pay is $50 and it would need to be local.

I'm parting out a couple of 16700Bs.    I think one has opt-003.   I've had zero luck selling them for $100.   Just mentioning it in case anyone wants any parts (for spares).   I'll probably keep the boards from one for spares for my 16702B.      I also have a 16702B that will be for sale (two logic cards (low end) with original runners replaced,  all cables/pods, optional pattern gen card) if anyone is interested.

Well, the trick is to get two cards powered up at the same time, and depending on the problem, configuring them the same or start them looping on the same test.  Sounds like you have enough chassis to do it.

I only have DogP's extender recently.  I've done most of my debugging from the underside by removing the bottom cover and mouse/keyboard card which exposes the bottom of the card in Slot E.  Almost all the signals on the logic analysis cards appear on one of those solder blob probe points on the bottom either because the signal transits there on a trace, or it's brought there on purpose for probing.  But it's not so on the scope cards and sometimes jumpers or access to the top is needed.

[dorkshoei]

Well, the trick is to get two cards powered up at the same time, and depending on the problem, configuring them the same or start them looping on the same test.  Sounds like you have enough chassis to do it.

I'd prefer two extension setups so both cards could be side by side on the bench outside of the unit.

Ideally there would be an extender card that slides into the chassis and then you could connect a ribbon cable to that and then the card-under-test to the ribbon cable.   Avoid having to open the cover (or grope inside to make any connections).     Of course a card this size is mostly empty space, would be $$$ to fab.

[ahakman]

Wow, another dead PLL.  Can you see any clock output from the dead one?
The PLL can be had on any of the 167xx cards with Timing Zoom except the 16715A.  It might help to know your country for anyone who can scrounge up a PLL.

I was going to check the PLL output with a spectrum analyzer, but I thought first I would do a quick experiment of swapping the chips, so I didn't actually measure the bad PLL yet. I suspect it's the same as the previous failed one in this thread - the data on the self test looked right, but clocked wrong, so I'm guessing it was running too fast / lost loop control just like the previous failed one did.

I'm in the US for anyone that might have a donor PLL board.

It's really better to check continuity via to via on all the traces running through or near corroded areas.  Extremely sharp probes pushed into the via holes at an angle works well.  On multiple occasions I've had traces with no visible breaks and it turned out the corrosion had gotten under the soldermask.  It can take some time to do the testing.  But you're right, it could also have eaten away the via hole plating, and that's happened to me too.

Yes, I probably need to get some better sharp probes for my DMM. I have fluke probes, but they have really crappy (worn) tips. I also have the push-on finer probe tip adapters that go over regular fluke probes - they're not exactly the sharpest, but they do poke through the solder mask on the vias with some prodding - having some nice sharp probes would be a nice upgrade though.

The HP-UX based analyzers are able to turn on detailed debugging output when running any of the verification tests (pv).  Is there any more detail from the windows version on which bit(s) and/or chips are failing during "Memory Unload Modes Test"?

Yes, on the windows analyzer, you can turn up the verbosity of the self tests to 9, which I think is equivalent to the max verbosity you can set in pv as well. I don't remember exactly now what the error is, but it's either a consistent byte missing, or a consistent word missing. I also seem to recall getting different results running the tests in order from the beginning to the unload test, vs running some tests after the unload test and then going back to the unload test. It still fails in the same way, but it seems to fail for a lot more data values if I come back to the unload mode test after running other tests further down - maybe it's just because of what data has been left in the memory from the other tests.

It is interesting to me that the memory address and data bus tests pass, so all of the paths from the memory controller FPGAs to the DRAMs are good, but a consistent failing byte or 2 bytes in the unload test sounds like a control signal problem between the memory controller FPGAs and the back plane CPLD/FPGA (whatever it is)

On the 1675x cards I think the acquisition memory access path from the backplane is through one of the FPGAs near the backplane connector (I think it's the Altera MAX), up to the Virtex FPGAs on top, and then back down to the actual DRAM chips.  On the 1671x cards, it goes direct from the backplane controller FPGA to the memory chips (there are no Virtex FPGAs acting as a memory controller layer).

[MarkL]

I'm in the US for anyone that might have a donor PLL board.

I have some hopeless cards and can send you a PLL if you want to email me a self-addressed shipping label.  Send me a PM and we can work out the details.

Yes, I probably need to get some better sharp probes for my DMM. I have fluke probes, but they have really crappy (worn) tips. I also have the push-on finer probe tip adapters that go over regular fluke probes - they're not exactly the sharpest, but they do poke through the solder mask on the vias with some prodding - having some nice sharp probes would be a nice upgrade though.

I have a pair of Pomona 6275 with the SS tips.  You can also get them with pogo tips, but the SS tips are not spring loaded and you can really jam them into the soldermask if needed.  Replacement tips are available.  They're great when they're working, but one down-side is that they tend to go bad after too much flexing where the wire enters the probe body.  I'm on my third pair.  Some people like the ProbeMaster 8152/8153 and I might try them next.

For probe sharpening, I found this (thanks to your previous pointer):

  https://northridgefix.com/product/grinding-stone-to-straighten-and-sharpen-tweezers/

It's a sharpening block with a slot in it which makes sharpening the SS tips fast and easy.

Yes, on the windows analyzer, you can turn up the verbosity of the self tests to 9, which I think is equivalent to the max verbosity you can set in pv as well. I don't remember exactly now what the error is, but it's either a consistent byte missing, or a consistent word missing. I also seem to recall getting different results running the tests in order from the beginning to the unload test, vs running some tests after the unload test and then going back to the unload test. It still fails in the same way, but it seems to fail for a lot more data values if I come back to the unload mode test after running other tests further down - maybe it's just because of what data has been left in the memory from the other tests.

It is interesting to me that the memory address and data bus tests pass, so all of the paths from the memory controller FPGAs to the DRAMs are good, but a consistent failing byte or 2 bytes in the unload test sounds like a control signal problem between the memory controller FPGAs and the back plane CPLD/FPGA (whatever it is)

Hmmm...  I could be wrong about the testing path, or maybe only some of the signals are routed through the Virtex.  I'll have to take a closer look at that.

Because the same test fails in different ways it implies something could be floating because it's severed.

[MarkL]

...
Hmmm...  I could be wrong about the testing path, or maybe only some of the signals are routed through the Virtex.  I'll have to take a closer look at that.

I'm remembering now where I got the idea the memory access goes through the Virtex FPGA chips on the 1674x and 1675x cards.

I looked again on a 1675x card that has a Virtex FPGA (U52) and an acquisition ASIC (U45) removed.  Along with a continuity tester, I can tell that the memory address, data, and control lines go to the Virtex by way of the (many) 33R resistor packs in the vicinity of the Virtexes.  They are series termination resistors for the memory signals.

A data/control bus from the Altera MAX runs up the top of the board in the center, ducks under to inner layer(s), and goes to the Virtex pads (different pads than the memory).  I believe this is the path for memory access from the backplane.  There appear to be a couple of traces that are also part of this bus that run on the bottom center with another bus.  They are on the outside edges of the other bus.

The "other" data/control bus on the bottom services the acquisition ASICs.  It appears to be a 16-bit bus.  It also services the DAC AD7841AS (U39).  Since the DAC has a known pinout, it's possible to figure out the specific bit assignments for the bottom bus, if it was useful to know.

FYI.

[fpgaarcade]

I managed to get hold of a couple of very duff cards and I'll start to reverse engineer the front end.
I've been chatting to Keith who took these excellent pictures :
https://www.techtravels.org/2021/02/hp-agilent-5382a-tear-down-with-photos/

Here is a picture of the termination network inside the flying wire "blob"
The documentation says it's a 250R to the signal, and then a 90.9K in parallel with a 8.2pF cap.

I removed the cap, and the resistor values measure as expected.

What's also interesting is the wire to the tip is just a normal unscreened wire, and the longer one is two core, not coax.

I don't destroy these cables lightly, they were a bit damaged... 

Looking at replacement cables,  the long run is lossy coax, measuring 178R for 135CM, so about 130R/meter.  Given the 90K on the tip, lossless coax probably isn't going to make too much difference to the levels.
(Samtec can't provide lossy)

[fpgaarcade]

And a nearly in focus picture of the front end.
6 components in the rx termination network. I'll remove and figure out how to measure.

[alm]

Looking at replacement cables,  the long run is lossy coax, measuring 178R for 135CM, so about 130R/meter.  Given the 90K on the tip, lossless coax probably isn't going to make too much difference to the levels.
(Samtec can't provide lossy)

It's not for the levels, it's to improve flatness of the frequency response, or in other words to dampen any ringing due to impedance mismatches between the coax and both ends. Using regular Z0 coax would distort the edges with reflections bouncing up and down the long coax. See the 1969 publication Tektronix Oscilloscope Probe Circuit Concepts book starting at page 14.

[fpgaarcade]

Hi,
I'm aware of the reasoning behind the lossy coax, it's discussed somewhat in the patent https://patents.google.com/patent/US4777326

My view, and this is yet to be proved in practice, is a standard 50R cable such as the samtec EQCD will work "good enough" - certainly better than other hobbyist probing solutions.
We transport GHz signals over these at work, but they are correctly terminated.

I think there is a enough resistance in the existing termination and matching networks that it will be sufficiently damped. I was worried that 180R less cable resistance would throw off the comparator levels but the difference is tiny over all.

As I can't source lossy coax ribbon, the only solution is to add a series R ~50Ohm at either end of the cable. Any other ideas are most welcome.

I plan to run some simulations when I have measured the front end component values, but really testing with a pulse generator and high bandwidth 'scope measurement at the comparator input will be needed.

/Mike

btw that Tek book is a useful reference, thanks.

[fpgaarcade]

Does anybody know the characteristic impedance of the agilent cables? I can attempt to measure it when I'm back at work.

For reference, the samtec 50R cable I'm considering a play with https://suddendocs.samtec.com/notesandwhitepapers/tcf-3650f-xx-txx_datasheet.pdf

Once we know more about the cable used I can ask around some of my China contacts for lossy micro coax - but full custom gets expensive quite quickly.

[MarkL]

If this is just a one-off project...

You could salvage the lossy coax from 40-pin probe cables (ribbon, not woven).  The ribbons peel apart easily if you want to get down to individual or smaller groups of coax.

If you want regular coax (not lossy), the newer 90-pin probe cables could be salvaged and also peel apart easily.  I've measured the coax impedance to be 93R (+/- an ohm or two).

[fpgaarcade]

Thanks for the impedance info, that's higher than I expected.

I have sourced some cables now for personal use.  I'm concerned if I make an FPGA board available for others, the demand for these rare cables would increase even more.
If we could find a reasonably priced modern solution which worked (nearly) as well it would help.

I've taken this thread off topic, sorry. I'll start a new one when I have more info.
Cheers,
Mike.

[fisafisa]

hi.
Was trying to fix a 16720a for a long time.
it came without cables. Was planning to make my own.

When i saw that a jumper could make the card working, I couldn't believe it.
I had been reverse engineering the card recently and spent many hours  producing a kicad schematic and testing the card on a bus extension.
The main issue I was seeing is that no read clock was arriving to the serial ram.

I tried the fix and immediately it was clear that things were different.
some of the failing tests now simply hung, some passed.

I then tested the card functionally and it worked!

Something is still wrong, as the self test does not pass, but functionally I could not find a problem yet.

 Many thanks

[MarkL]

...
I had been reverse engineering the card recently and spent many hours  producing a kicad schematic and testing the card on a bus extension.

Can you post your schematics?  There's so little documentation on these cards that every little bit helps.  Thanks!

[MateKrisz]

Hi,
I have problem problem with the 16720A. I tested it without cables, jumper on the clock pod.
The following tests failed:
do_loopback
do_clock_test
do_wait_test
do_instint_test

Passed tests:
do_ram_test
do_dram_test

Can you share the schematic? I will try to fix my card.
Thank you!

[aeg]

A few pictures for fans of corrosion

[MarkL]

A few pictures for fans of corrosion

Mmmm... impressive.

Looks like a 16710A/11A/12A?

Are you going to attempt repair?

[aeg]

Looks like a 16710A/11A/12A?

Bingo! 16711A.

Are you going to attempt repair?

there i fixed it

Code: [Select]

Mod   A: TEST passed       # "testEPLDpath" (1, 0, 1)
Mod   A: TEST passed       # "testLoadFPGA" (1, 0, 1)
Mod   A: TEST passed       # "testCableDetect" (1, 0, 1)
Mod   A: TEST passed       # "testFPGARegs" (1, 0, 1)
Mod   A: TEST passed       # "testChipRegsChip0" (1, 0, 1)
Mod   A: TEST passed       # "testChipRegsChip1" (1, 0, 1)
Mod   A: TEST passed       # "testChipRegsChip2" (1, 0, 1)
Mod   A: TEST passed       # "testChipRegsChip3" (1, 0, 1)
Mod   A: TEST passed       # "testChipRegsChip4" (1, 0, 1)
Mod   A: TEST passed       # "testChipRegsChip5" (1, 0, 1)
Mod   A: TEST passed       # "testZCal" (1, 0, 1)
Mod   A: TEST passed       # "testAdCntrs" (1, 0, 1)
Mod   A: TEST passed       # "testAdCntrRecords" (1, 0, 1)
Mod   A: TEST passed       # "testChipStateClocks" (1, 0, 1)
Mod   A: TEST passed       # "testChipTimingClocks" (1, 0, 1)
Mod   A: TEST passed       # "testChipCal" (1, 0, 1)
Mod   A: TEST passed       # "testMemsDataLines" (1, 0, 1)
Mod   A: TEST passed       # "testMemsWalkingOnes" (1, 0, 1)
Mod   A: TEST passed       # "testMemsAdrsLines" (1, 0, 1)
Mod   A: TEST passed       # "testMemsFullMeas" (1, 0, 1)
Mod   A: TEST passed       # "testRecordFlags" (1, 0, 1)
Mod   A: TEST passed       # "testOscillator" (1, 0, 1)
Mod   A: TEST passed       # "testComparators" (1, 0, 1)
Mod   A: TEST passed       # "testI2Csimple" (1, 0, 1)
Mod   A: TEST passed       # "testResources" (1, 0, 1)
Mod   A: TEST passed       # "testOtherPsyncs" (1, 0, 1)
Mod   A: TEST passed       # "testArmsTrigs" (1, 0, 1)
Mod   A: TEST passed       # "testEncoders" (1, 0, 1)
Mod   A: TEST passed       # "testHiSpeedMACs" (1, 0, 1)
Mod   A: TEST passed       # "testMemoryCal" (1, 0, 1)


[Hamster]

i have a bunch of these older 167** cards that have failed, i gave up on them, i have since moved onto 169xx cards

gg's on fixing the card, good job!

[MarkL]

Congrats, aeg, on the repair!  I would have bet that one was a goner.

i have a bunch of these older 167** cards that have failed, i gave up on them, i have since moved onto 169xx cards
...

Have you found that the 169xx cards do not have the corrosion problem?

[Hamster]

i have not found any with issues yet, however, i am guessing its because they have not had heaving use?

I did notice on the 1691x cards they level of tracing running under the runners is substantially lower.

[Hamster]

i have 1 16911 that gives me issues, but there is zero trace damage under it.. so it honestly became a parts board and testing things with..

[aeg]

i have a bunch of these older 167** cards that have failed, i gave up on them, i have since moved onto 169xx cards

Any chance you're looking to part with one of the dead 167** cards? I have a 16751B with a bad comparator IC and bad pod cables, waiting for a card to pull parts from.

[MarkL]

i have a bunch of these older 167** cards that have failed, i gave up on them, i have since moved onto 169xx cards

Any chance you're looking to part with one of the dead 167** cards? I have a 16751B with a bad comparator IC and bad pod cables, waiting for a card to pull parts from.

Don't know if you worked out a deal with Hamster, but if not I can give you some comparators for postage.  PM me if interested. 

Unfortunately I don't have any extra pod cables, but sometimes they can be repaired depending on the location of the break (assuming you're talking about the coax ribbon cable).  If you mean the flying leads, those are individually replaceable.