Tektronix TDS754D - acquisition board test fail

[Rax]

Hi all,
I recently got this TDS754D with issues and am now trying to assess and hopefully repair it.

It'd fail, initially, the startup tests with an acquisition board failure (see first image below), but now it'd cursorily pass the startup tests, but fail its acquisition board checks if I run the full tests. So it seems very clear where the issues lie.

I enclose the log from the recent tests. March 17th is when I got this, so that's the area of interest for my own observations. Per these logs, it seems U207, U208, U214, and U216 seems to be repeat culprits, though there's some odd variability from test to test in what it returns in the failure log.

In rather general observations, CH1 seems the most able to display a waveform (in DPO mode), while the other three seem more cranky. In non-DPO mode, though, things seem pretty stable. DPO mode brings a ton of "snow" and garbage on the screen (see image included).

Here's some thoughts I put together:

• This unit's not impacted by the notorious caps failures in some of the related units. Additionally, I see no leaky caps (at least on the top side)
• I'm considering replacing the ICs mentioned above with 71024S12TYG. Has anyone gone through this? I have a Pace TT-65 which I think fits the bill (though I need to identify and purchase an appropriate tip for the job...)

I welcome input on where I should head next.

[denimdragon]

Check your power rails. That power supply is due for some service. I use
to repair a lot of these old scopes. The 754D is one the best in that TDS5,6,7XX series.

[Rax]

Check your power rails. That power supply is due for some service. I use
to repair a lot of these old scopes. The 754D is one the best in that TDS5,6,7XX series.

I also always start with the power supplies in a repair. "Unfortunately," I think in this case they check out. Per Table 6-5 at p.6-66, all rails under load seem to be in spec.

I wonder if others have found the errors logging system to reliably report faulty ICs. I'm trying to assess whether I should trust my error log - indicating likely culprits are U207, U208, U214, and U216 - enough to go ahead and replace them. From what I'm learning, others have needed to dig deeper than just that, in order to nail down the faulty parts. But maybe I'm reading too much (or not keenly enough) in prior casework I was able to find.

[TERRA Operative]

I have a TDS794D that had bad RAM chips, it presented as the waveform on the display dropping to zero periodically as the faulty memory cells were stuck at 0.

I have a bunch of spare good chips that I pulled from salvage boards and have tested (I used a Retro Chip Tester Pro), so I can re-test a handful of them and send them your way if you need some.

[Rax]

I have a TDS794D that had bad RAM chips, it presented as the waveform on the display dropping to zero periodically as the faulty memory cells were stuck at 0.

I have a bunch of spare good chips that I pulled from salvage boards and have tested (I used a Retro Chip Tester Pro), so I can re-test a handful of them and send them your way if you need some.

I'm not convinced that's what I'm seeing here, as to me it seems my symptoms are pretty random; I don't see much of a pattern - though I should probably take a closer look. They're still my main culprits either way. How did you determine which ones were bad?

I appreciate your offer, and will keep it in mind. I think the 71024S12TYG are available in the US at the "big box part stores" - are those reasonable replacements? Not sure what others have tried with good success. Or why you felt you needed to reuse those ICs - other than already having them at hand.

But if you removed and maybe replaced some of these, I could use some direction on how to go about that. What worked, what didn't work so well? I think these are on an SOJ package, which I'm not so familiar with.

[TERRA Operative]

I knew which banks were bad as only inputs 1 and 4 were affected (Note, the 4 banks of RAM and Acquisition chips DON'T line up with the physical order of input jacks!)
Then from what errors I had, I took some educated guesses as to what actual RAM chips needed to be replaced.
A bit of hot air and a fine soldering tip and I swapped out the chips one by one until I had no more errors or distortion of the displayed trace.

I had some salvaged boards from scrapped scopes so the chips were free, so I tested them and kept all the good ones to use which allowed me to just swap out chips freely until the scope worked.

I can also pull other chips if you need them too. I still have the scrap boards here.


It looks like the RAM chips are about $3.50 each from Digikey/Mouser, but if you want a bunch I won't ask nearly that! Postage from me to you will be pretty ok for a small parcel I think, so PM me and we can compare which way is cheaper if you want.


[EDIT]
I found my notes. The error I had was "ERROR: diagnostic test failure, dsyRastModeV0Walk, raster fail @ 1,1 read: 8, expect: f" and I've attached the display I was getting with no input.
You can see the spikes from the bad RAM. (I said things were stuck at 0, the error message has the correct details, but the RAM was bad regardless).

[shakalnokturn]

RAM seems to be a common failure although I've never encountered it myself.
I don't know if the solders to the RAM MUXed fail, try applying pressure to MUXes and RAM while it's working to see if that affects the displayed traces.

[Rax]

I also always start with the power supplies in a repair. "Unfortunately," I think in this case they check out. Per Table 6-5 at p.6-66, all rails under load seem to be in spec.

Maybe I was glazed over that too quickly. DCV levels seem fine, but the ripple on the 25V rail doesn't seem so OK to me - see enclosed scope screenshot. This is done with my scope (HP 54522A) over a 10x probe, but my Fluke 189 agrees with this about 160mV level of ripple. If this is not such a smoking gun as it seems to me, I welcome input.

There's some healthy level of disassembly, so I won't go ahead with this tonight after a "week-tail-end" day at work, but I plan taking apart the LV PS board and taking a closer look at what may be off on it. Before doing that, I'll probably also look at the "no load" ripple levels on the various rails (in case some module is spilling this crap on the 25V rail). I am using the "component level" SM from the 520B, which is supposed to have some good resemblance with this scope.

The ripple on the other rails is in the mV ACV range (for instance, about 8mV AC on the 5V rails).

[TERRA Operative]

These PSU's are known for bad caps occasionally, so you may be making a shopping list for new ones soon...
There's also the possibility you have a version of the PSU that absolutely needs at least one cap replaced regardless.

[Rax]

Check your power rails. That power supply is due for some service. I use
to repair a lot of these old scopes.

These PSU's are known for bad caps occasionally, so you may be making a shopping list for new ones soon...
There's also the possibility you have a version of the PSU that absolutely needs at least one cap replaced regardless.

Thank you both for this direction. Is the PS quite as dead on at the core of the whole unit as I'm finding it? I think there's a minimum of two maybe three major other modules that have to come out whichever way I go about this (and I am reading the manual, which has about four different sections on pre-pre and prerequisite to disassembly, and will follow its steps).

Any good tips?
(aside from "stop complaining and get to it!!!"  )

[Rax]

I did exactly what my last statement above indicates and here's a pic of my actual PS board.

[Rax]

On further work on this, I seem to have a PS board (nearly?-)identical with the TDS520B. Yes, that one - the closest scope to this still supported with component-level SM.

So, if I were to believe that, the 25V may - possibly - be a 1V lifted version of the 24V rail on the 520B? The current rating seems to match. I'll examine the corresponding parts.

[Rax]

Further report - replacing C21 (for which I used a UC KYB 1000uF/50V) and C102 (Nichi HE) - the two electrolytics on that rail - hasn't improved anything. The ripple on the +25V is still about 160mV, and the acquisition tests still fail.

I think I'll call it a day and think further where I am with this in the morning.

[Rax]

I finally got to get back to this. Some pieces needed to fall in place:

• Get the right Pace tips for SOJ packages
• Get chips from Terra Operative (Thanks a bunch!!  )
• Read a lot and watch a ton of Pace vintage videos! A feast in their own right, to be fair.

So I'm half way through the job (though something tells me I may have at best done a third?...) and have removed the suspect chips (207, 208, 214, 216).

I welcome any good tips on soldering the replacement SOJ chips. I do have some low-temp Chipquick paste, plenty of syringe-disposing flux, thin regular solder, etc. I do have a hot air tool (cheapo thingie I am not in love with but works OK). I am thinking of cleaning the pads very well (Pace SX-90), be generous with flux on the clean pads, then try to use a chisel tip with careful application of thin solder and run through the pins at deliberate speed. The alternative is to use the Chipquick and the hot air tool, but I have far less confidence I'm not going to end up with bridges and maybe even loose stuff going stray in there. There's some chips in there that get very hot and low-temp solder may get a bit too excited with that in time.

[TERRA Operative]

Looks like you got the old chips extracted pretty well.

I used my Hakko hot air gun to remove the chips, then solder sucker to clean the pads. To install the replacement chips, I used 0.3mm solder and a conical tip on my iron to solder the legs one by one.
I position the chip, solder one corner, adjust then solder the opposite corner, then finish the rest once the chip is perfectly positioned.

Lots of flux to make soldering easy, followed by lots of isopropyl alcohol to clean it all up at the end.

[Rax]

0.3mm solder and a conical tip on my iron to solder the legs one by one.

Do you use lead-free solder for this? I'm thinking, if lead-free was used in manufacturing it, it may be a good idea to stick with that so one wouldn't mix them.

[Rax]

I'm having a hard time soldering these on. I have tried both a very fine chisel tip, a long and fine conical, plenty of flux on the board. The solder just doesn't seen to want to go on there.

• Maybe the .3mm solder I'm using is not very good. An AMZ purchase, terrible product design by using a sticky label which left glue residue on the solder. I've unwinded about 2/3rds of it and I think it's clean, but maybe the product is even worse than I thought? Meaning the rosin core missing in spots, etc.
• Maybe I should just switch to new chips as maybe the pins of these used ones are no so friendly to rework? To be clear, Terra Operative sent them pristine clean and NOS looking (so this is as far from a complaint as can be). But maybe there's stubborn oxide on those legs?
• Maybe I should use lead-free solder, in case the original manufacturing of the board used that (which I didn't think would be the case).

Oh, I wish this would take a turn to the smooth path!... Pretty exhausting and frustrating.

[Rax]

Well, no luck with the overall repair... I replaced those 4 SRAMs - I think work is good, see pics (I've further cleaned up the flux from there, BTW) - but I still have acquisition board errors (see log). Just maybe different errors - U200 demux now?... Or maybe just errors in its module.

[TERRA Operative]

I just used regular leaded solder with additional standard Hakko rosin flux. Nothing special at all and the solder flowed nicely when I replaced the chips in my TDS794D
If your board is clean then you might have bad solder..... I'd get new stuff and reflow the joints to make sure you don't have a dry joint there somewhere.

Once you have that sorted, then we can dive deeper.

[Rax]

Once you have that sorted, then we can dive deeper.

Soldering completed successfully, as per my prior post. I've had to look close with a magnifier and eliminated a few bridges. I'm very thorough, so I'd never turn it on before being as certain as I can the work is good. My back hurts more from examining than the actual soldering.

Though probably my "finished" pic doesn't quite depict it well, the solder joints I've done here as good as anyone's, I wager.

[Rax]

Anyway, so I'm back at the drawing board and there's just a lot of scratching my head is all.

[Rax]

A couple of notes on the rework:

• I think the .3mm solder I have is indeed crap. I switched to my default .8mm good quality solder, and I had to judiciously distribute each load across a few pins. Abundant rosin helped do that relatively easily. So, my solid belief quality tools and materials is everything is reinforced.
• The TT-65 and the SOJ tip made the desolder job very enjoyable. It's not a cheap solution, but I'm certain it cut down my time on that part of the job by a sizable percentage.

[Rax]

As I evaluate the next steps here, I am trying to read the entirety of the error message. I am positive I read a while back a thread where this issue was discussed - can't recall if clear directions were presented - but can't find it now for the world.

I'd appreciate pointers on how to read the entire body of the individual errors.

[TERRA Operative]

Ok, all good on the soldering, sounds like you got it all sorted.

To get the entire error messages, you'll need to read them out via GPIB. I also have no idea why Tektronix couldn't get the text to wrap properly on the scope display...


Here's how to read out the errors:

To read the first line of the error log via GPIB, send the command 'errlog:first?'
To read out subsequent lines, send the command 'errlog:next?' per line in sequence.
To clear the error log, send the command 'ERR CLEAR' via GPIB.


I would suggest clearing the error log first, then reboot the scope and manually run a full self test and SPC to generate a fresh set of error logs.

[Rax]

To read the first line of the error log via GPIB, send the command 'errlog:first?'
To read out subsequent lines, send the command 'errlog:next?' per line in sequence.
To clear the error log, send the command 'ERR CLEAR' via GPIB.


I would suggest clearing the error log first, then reboot the scope and manually run a full self test and SPC to generate a fresh set of error logs.

This is great, thank you. I was able to initially read an error from the dawn of time, but as trying out different things to read the last didn't work, I resorted to what you recommended and reset the error log. Then ran diagnostics again, and got this:

"SUN MAY 19 19:11:48 2024  ERROR: diagnostic test failure, digDataFormatDiag,  ERROR!!BYTE mode, in demux 200 ,i= 7 memBaseAdr 0x7380010=  data = 800, expectedData = 5500"

Looking forward to interpretations from those with experience on this instrument - as for me, I am headed now to do some reading.

[Rax]

BTW - not to jinx it, but I feel stronger and stronger that replacing those four SRAMs was called for, because there seems to be just one error now and those RAMs don't pop in there at all anymore.

[TERRA Operative]

Yeah, looks like you had a few errors to deal with, at least you are making progress!

I'll have a search and think about your current error. My feeling is to either track down that address to a RAM chip and replace it as well (if not already done) or figure out what is controlling that RAM chip and stare intently at that.
I'd expect that if it was the chip passing the data to the RAM chips, it would be a periodic error across multiple chips rather than just one RAM chip in that case due to how the RAM is written to with bank switching etc.

One way to find the right RAM chip is to ground/apply 5V (have to double check which one) to the WE (Write Enable) pin one chip at a time and see what errors are thrown on self test due to that chip not being enabled to be written to.
If you get new errors on the same address range as your latest error, you found the chip.

[Rax]

After running SPC, I got:

"SUN MAY 19 20:07:47 2024  ERROR: Internal adjustment range exceeded, ( 3 @   7464): DIGc gain = -0.400113, bal = 1.113079"

Bad news?... 

[TERRA Operative]

oooeerrrr.... Either bad cal (unlikely) or something is bad on that channel. Maybe as simple as a bad relay on the hybrid. It's not too hard to swap hybrids between channels, just need to be extra careful not to crack the ceramic PCB.
Relays aren't toooo difficult to replace, I have a video on Youtube about it.
youtube.com/watch?v=b0P1sJBomDQ

Is that the only error after clearing via GPIB?
Can you run SPC maybe 5 or 6 times to exercise the relays, then clear all errors, self test and SPC once more and list the entire error log here?

[Rax]

something is bad on that channel.

Would that be CH3? The error body is a bit cryptic to me.

Is that the only error after clearing via GPIB?

Those two errors above, yes. The second error occurs if I run SPC.

Can you run SPC maybe 5 or 6 times to exercise the relays, then clear all errors, self test and SPC once more and list the entire error log here?

Been doing a few of those, and the error seems pretty persistent.

I should also say, I don't feel there's anything very specifically wrong going on with CH3 - if that's the one found faulty by SPC. If anything, CH4 seems a bit choppier and there's a bit more freezing and vertical bars "noise." But they all work pretty well, their measurements are accurate as much as my other meters think. It just fails tests. Oh, and DPO mode doesn't work very well - there's a good amount of "video noise" - color pixelation ("snow") on the screen when that's enabled.

[TERRA Operative]

I think the firmware sees the chanel numbering as 0 indexed, i.e. 0, 1, 2, 3 corresponds to physical channels 1, 2, 3, 4. So I would look for problems on channel 4

Try swapping the channel 1 and channel 4 hybrid (don't forget the thermal paste on the chip on the hybrid module!) and see what happens.
I keep saying it and will say it again.... Be careful with the hybrids, and make sure they are perfectly seated in the metal holder before screwing it to the PCB!

Easy tests are easy, so may as well rule out bad relays or bad hybrid module.