Tektronix TDS 544A issue : Acquisition RAM POST Errors

[Vince]

Hi group,

Just finished my first ever test gear repair, my Tek 2232 this week, after 2 months of work it was finally a success... thanks to all who helped, much appreciated. Now it's about time I turn my attention to my TDS 544A.

I bought it just a year ago, worked like a charm, but recently it started behaving strangely : it is become "sluggish", for want of a better term. The trace on the screen is refreshed only every second or two, then freezes, then is updated once, then freezes again etc etc... which make the scope unusable, hence why I my getting my act together and am attempting a repair...
Just like the 2232, this repair is both a necessity and an excuse/opportunity to learn from it, since I am new to repairing fancy stuff like this.

So I am opening this topic so as to share with other newbies that might be interested in these scope, and hopefully so that more knowledgeable and experienced people might help me along the way ! Any input most welcome ! 

Some background about this scope : 

Originates from the military. The cal sticker on it expired last July, at which point Paul, the gentlemen who sold it me, acquired it. He fixed it and a month later I bought it. So I have had it for 11 months now.

When he got it, the scope had plenty of errors, but mainly related to the acquisition board (I understand that's often the case, probably because that's where most of the leaky caps are located ?).

He removed each and every one of those leaky caps, which indeed had leaked all over the place, then all the boards (CPU, Acquisition and Front Panel) made two trips to the dish-washer with soap, to try and remove/clean the boards from the electrolyte as well as was possible.Then rinsed with clear water, then dried in the oven at 75° C. Then he replaced all the caps with MLCC type capacitors, so no leaks to be feared in the future. Then he had to replace a few discrete components (resistors, an op-amp...) because they had obvious signs of electrolyte damage. But other than this, after that the scope worked just fine, no error messages at POST anymore, all was fine, so he sold it to me, and I have been happy with it for almost a year until this weird problem appeared.

I started work on it today, and did some basic tests to try to narrow it down :

I fed it with a sine wave, and played with the controls for a while to try to see a pattern in its behavior. Pattern I found. I think I ruled out both the front panel and the CPU board/user interface, because as you can see in the video below, when I move quickly the knobs for the trigger level, the trigger marker on the right edge f the screen, reacts perfectly, it's responsive, no sluggishness at all. Same it I move the cursors : they are perfectly responsive, and the associated readout in the upper right corner of the screen, are also updated very fast, no problem there.
So the sluggishness doesn't seem to affect the user interface at all, no it appears to affect only the speed at which the signal trace itself, reacts to changes. Again in the video, you can see that I do a few quick changes in the trigger level. Watch the marker on the right edge of the screen, and notice that there is a delay before the trace actually reacts to this. Same things ahppens if you do whatever that would necessite the scope to redraw teh signal trace on the screen : for example if you change the vertical sensitivity, or the time base. In case of a time base change there are even TWO delays : when you turn the time base know, there is a first delay until the readout at the bottom of the screen is updated to reflect that change. Then once the readout is updated, there is again a delay before the signal trace is updated.
Actually, even if you don't touch anything on the front panel, the problem is still there, as you can see in the first video where I made a close-up shot of the trace. You can see that the trace is refreshed only infrequently. It is frozen 99?5% of the time, and then every now and then it gets refreshed/updated, just once, then freezes again.  The automatic frequency measurements is also updated only when the trace is. I guess this makes sense, you need to acquire a waveform then only can you run the measurements on it.

As I understand it (?), in these scopes, any scope I gather, the main CPU is only in charge of the user interface and overall control of the scope, but the processing and display of the waveform is actually done separately. So that makes sense. Would explain why the entire user interface, front panel, menus, cursors etc works just fine, but that as soon as something involves redrawing/refreshing of the signal trace itself, then I get problems.

So this means I guess that the CPU board is fine, attenuator board too, and that most likely it's the acquisition board playing up again. So that will be I guess my first destination...
Can also be related to the video display as well, maybe not the acquisition as such? I have not yet read the service manual far enough but the video processing is maybe done on the CPU board I don't know, so the latter might still be the problem. Will dig further.

What might confirm the Acq board theory, is the fact that most error messages Paul got when he fixed it the first time, were to do with the acquisition memory (see below). Two errors when testing read/writes to the acq memory. The other day I eventually got a failed POST, and the error log gave me the exact same old errors, back again. Exactly the same two R/W errors, at the same exact address location:  0x730000 and 0x732000
That might be a lead... need to figure out what chip on the board physically corresponds to this address.

However I ran an "SPC"/Signal Path Compensation procedure, which somehow cleared these Acq errors : restarted the scope afterwards, and no POST error anymore ! No new errors in the log either, clean bill of health. Restarted the scope a few times, still good. Not sure what's going on. Maybe these R/W errors are not that serious and are not the cause of the slow refresh rate.

Still, looks like the Acquisition board is the main suspect. So I guess I should first check voltages on it, then see if I can spot left overs of the old leaked electrolyte somehow. Paul told me that there was one area of that board that suffered more severely than the others, from the electrolyte (pictures below from him, showing before/after replacing the caps in that area). It's the " time interpolator and jitter ramp " section. So I will need to look that up in the service manual and the schematics.  For now the theory is that the electrolyte might have done enough damaged to actually seep into the PCB itself. Dishwasher maybe failed at removing 100% of it and the little bit that was left inside the PCB eventually ended up eating a trace somewhere in that area.

So I guess I will need to go straight at the Acquisition board, do an overall inspection, check supply voltages as you do, then start focusing more closely on that jitter/interpolator section, looking for corrosion again.

Oh, and one important thhing I noted : there is a pattern in this refresh rate problem : it's not jsut updating at random intervals, when it feels like it. No, just the opposite. It refreshed the trace at very regular interval, about 1.5second. I timed it by counting "123451234512345" in my heard, works every single time.
So this might be a clue to take into consideration as well.

I also noted ONE circumstance where it CAN refresh at normal/fast rate, if that helps at all : if I go in teh "Display" menu, and change between "dots" or "vector" mode for example. I switched back and forth between these two modes a few times just to see, and I noticed that once you select a mode, any of them, for a BRIEF moment, half a second, when the scope updates the trace to reflect this change in display mode, then for a half second it would refresh the trace at a normal rate, then it would become slow again.  Maybe I should do a video clip of this to make myself more clear. Yeah will do... wait a minute...



Anyway, the repair is now started, so any and all good souls are welcome to jump in to help out ! 

Will update as I go...

[andy2000]

When working on these, I usually find a number of open traces.  They tend to corrode underneath components, particularly where a trace connects to a solder pad.  Only careful inspection and continuity tests will find the open traces. 

[nctnico]

What happens after you reset everything to default? Maybe better: use the secure erase option. I'm thinking the trigger hold-off time might be set.

Edit: wait a minute.. you used ceramic capacitors? These don't work in these scopes. You have to use electrolytics! There are several circuits which depend on the ESR of the electrolytic capacitors to work correctly.

[Vince]

When working on these, I usually find a number of open traces.  They tend to corrode underneath components, particularly where a trace connects to a solder pad.  Only careful inspection and continuity tests will find the open traces.

Thanks Andy, will proceed... a game of patience but I am in no hurry luckily for me. This is not my primary scope, the 2232 is. So if takes me 6 months to check the entire Acquisition board, well so be it...

Oh, I just made the video I was talking about.  When I started the scope, yeah you guess it, POST was not clear anymore, the two Acqu and Acqu/Proc error messages were back. In some weird perverse kind of way, I somehow "prefer" this ! I mean I found it strange than an SPC procedure could fix a R/W issue in a memory chip !  I guess this error is random and due to a bad RAM chip (need to figure out which one it is, based on the address at which the errors occurred), or a half-dead corroded track which something to do one way or another, with that RAM chip.

https://youtu.be/k8w83db0Ep4

[Vince]

What happens after you reset everything to default? Maybe better: use the secure erase option. I'm thinking the trigger hold-off time might be set.

Whatever setting was at fault I don't know but one thing is for SURE : you FIXED IT !!!!!     

Thank you !!!!

It is now perfectly responsive again, a joy to use ! 


I still get those 2 POST errors and R/W Acqu RAM errors in the log, though, which I would still like to fix if possible, but at least the scope is actually usable again !

So looks like these Acqu RAM errors are not really vital, the scope can still work none the less... but still, it needs to be fixed what do you say ?........ so let's try to do that...

Edit: wait a minute.. you used ceramic capacitors? These don't work in these scopes. You have to use electrolytics! There are several circuits which depend on the ESR of the electrolytic capacitors to work correctly.

I didn't do anything... the chap I bought the scope from last summer, did.
You appear to possess a rather deep knowledge of these scopes ! Lucky me. Which part/sections of which board do you think might be affected by the swap to ceramic caps ? I might replace these then, as a precautionary measure. Would it be possible to at least replace them with Tantalum ? At least they don't leak...
If we knew exactly how much ESR is required, we could figure out what capacitance and voltage rating to use for, say, a tantalum, in order to achieve a similar ESR.

[cncjerry]

You probably had the record length up the the maximum.   I have a TDS784 (TDS744 upgraded) and it gets slow when you have the record length set too high.

[KE5FX]

Some linear regulators need a bit of ESR in their output capacitors, but if it worked for a year without acting up, the caps are unlikely to be the cause of any current or future problems.  Corroded trace(s) are a distinct possibility.  You're very lucky that board was salvageable at all.

You may be able to rule out regulator instability by probing the power buses, looking for oscillation in the form of excessive ripple. 

There's a lot to be said in favor of just ignoring any errors that don't cause observable problems.

[nctnico]

I have fixed a couple of these scopes and read quite a bit about them. The analog sections need electrolytics and IIRC especially the small PCB on the acquisition board (AFAIK the oscillator) needs electrolytics. Modern electrolytics won't leak unless severely overloaded. Still if the scope works with the ceramics I wouldn't mess with it.

I never tried this myself but you can create a serial debug port to the scope or use GPIB to get extended debug messages telling which RAM chip is bad. The TDS520B component service manual is a very good place to start.

[Vince]

You probably had the record length up the the maximum.   I have a TDS784 (TDS744 upgraded) and it gets slow when you have the record length set too high.

Oh oh ! That does ring a bell indeed !  I do remember that the last time I played with that scope, I spent some time trying to familiarize myself with the memory ! I did try each and every possibility, and most definitely turned on the entire 50K points memory, I remember that, as I was trying to capture some activity on the serial line that links the front panel and CPU board of a TDS 310 I am trying to repair !

So if it happens again, I will know what to do, and just reduce the record length once I am finished debugging.

Thanks for your input.

[Vince]

Some linear regulators need a bit of ESR in their output capacitors, but if it worked for a year without acting up, the caps are unlikely to be the cause of any current or future problems.  Corroded trace(s) are a distinct possibility.  You're very lucky that board was salvageable at all.

You may be able to rule out regulator instability by probing the power buses, looking for oscillation in the form of excessive ripple. 

There's a lot to be said in favor of just ignoring any errors that don't cause observable problems.

Yep won't mess with it then. But at least I can open the scope and do what you suggested, some probing around, just for peace fo mind and for educational purposes, to familiarize myself with that scope. Plus I still need to fix theses Acqu RAM errors anyway... if possible.

[Vince]

I have fixed a couple of these scopes and read quite a bit about them. The analog sections need electrolytics and IIRC especially the small PCB on the acquisition board (AFAIK the oscillator) needs electrolytics.   

Will check that for ripple then.

Modern electrolytics won't leak unless severely overloaded. Still if the scope works with the ceramics I wouldn't mess with it.

Good to know ! I guess though, that I would need to buy some reputable brand to be assured of this, not just some no-name caps from my local shop.

I never tried this myself but you can create a serial debug port to the scope or use GPIB to get extended debug messages telling which RAM chip is bad. The TDS520B component service manual is a very good place to start.

Yep GPIB is most definitely in the pipeline !  The chap who sold it to me also sent me an old MS-DOS software from Tek, used for servicing. I saw it referred to in the service manual today. This program being old only runs on MS-DOS and has built-in drivers only for the old ISA bus PC2 and PC2A GPIB Adapters. I do have an old computer with lots of ISA slots so I bought a couple ISA GPIB boards on Ebay. A no-name PC2 card, and also a genuine NI board which can b configured either as PC2 or PC2A. Read about these two controllers a bit, set the jumpers and DIP switches as best I cou ld understand but... no joy, the Tek software will not detect/recognize any of these cards, sadly. I must be doing something wrong again.... just don't know what !

but I will get there eventually...

[KE5FX]

I have fixed a couple of these scopes and read quite a bit about them. The analog sections need electrolytics and IIRC especially the small PCB on the acquisition board (AFAIK the oscillator) needs electrolytics.   

Will check that for ripple then.

Another problem with the high-capacitance ceramics is that they are almost like varactors.  If used anywhere near their rated voltage, the capacitance may be much lower than the rated value. Usually that will still be OK, but in a marginal application it can bite you.  Either way the symptom will be excessive ripple.

Read about these two controllers a bit, set the jumpers and DIP switches as best I cou ld understand but... no joy, the Tek software will not detect/recognize any of these cards, sadly. I must be doing something wrong again.... just don't know what !

When faced with a situation where you're sure the DIP switches are set correctly but you still aren't getting the expected result, check the DIP switches with an ohmmeter.  They tend to fail open.

[Vince]

Either way the symptom will be excessive ripple. 

Yep will defintely check all voltages for ripple. The servuice manual only goes to module level so no details about admissible ripple levels, but I will report what I find here and you can tel me what you think. I guess I can look at my 2232 service manual to get a general idea of the order of magnitude that is tolerated, as a starting point.

When faced with a situation where you're sure the DIP switches are set correctly but you still aren't getting the expected result, check the DIP switches with an ohmmeter.  They tend to fail open.

Thanks, will check that.

I think I will definitely get GPIB going ASAP, because you are right it may well help me figure out what RAM chip might cause trouble : I spent some time tonight looking at the service manual and schematics for this scope. The block-diagram of the CPU board (attached below for those who don't have it already...) clearly shows that Tek meant to use GPIB as a serious/low level debugging tool, because the GPIB controller is actually one of the rare peripherals that are real close to the CPU, tied directly the data and address buses. There is only a small boot ROM (256Ko), with a little 32KB static RAM to go with it, and the 7 segments error code display... and the GPIB controller. There is also the service port where technicians can plug their portable cartridge terminal like was common in those days (would be cool to get hold of one ??) and then of course U2000/2001, the two big interface chips required to access the memory controller/address decoder etc so that, I guess, if all goes well, it can then access the firmware inside the flash ROM, then put/copy it into the main memory then start the operating system from there and boot the scope. Well that's my best guess from what I see on this block diagram.

But apart from that, 95% of the CPU board is isolated from the CPU via the data & address buffers. So even if 90 % of the CPU board was wrecked somehow, the CPU should still be able to run from its little boot ROM and talk to me via GPIB !!!  That's marvelous. GPIB is then really a serious debugging tool in this scope, not just a high-level interface for fancy I/O like hard copies or wave form retrieval.  How cool is that 



So I am torn between the urge/will to get my hands dirty / open this scope to satisfy my curiosity/see how it's put together.... and the more reasonable reasonable objective of first getting GPIB working on my computer (and buying a GPIB cable too ! ).   What a difficult choice ! LOL
I know... I will do both at the same time ! LOL  After all even if I open the scope, I should still be able to plug the GPIB cable on the CPU board anyway.
Yeah, why choose !   

[Vince]

Still looking at the schematics, this time looking at the A10/Acquisition board, and making progress I think. I am starting to like this detective game, hmmm....

Attached a snippet of the schematics, representing only channel one, no point looking at the other 3 which are only duplicates and would make the PDF file too big to be uploaded here I think. 

So, I quite like like what I see on the block diagram of this board : each of teh 4 channel has it's own ADC and it's own acquisition memory ! So this decidedly might indeed explain how I get Acq RAM write errors,  yet the scope appears to work perfectly fine ! I only use the first channel most of the time, the first 2 sometimes, but rarely the 4 channels. I think the only time I turned them all on, was a year a go when I unpacked unpacked the scope and wanted to check the scope survived the transport, so I checked all 4 channels for peace of mind. But other than this...

So it's indeed possible that this RAM error is happening in some RAM chip I actually never get to use. Must be on channel 3 or 4 then.

At first I was scard/surprised because on sheet #9, I cna see only 16KB of RAM, x8 2KB chips, not quite enough I thought, plus all the chips were annotated as "NOT USED" ! Oops.... then much further down the file, at the very end, after lots of analog stuff, I found another sheet showing some acquisiotn memory, phew ! And this time we have more of it : 64K, sounds more like it I thought !  Plus, they are not annotated "NOT USED" this time ! So looks like this is the real deal.
8 chips of 8KB each.

So, in short, I have 4 channels with 8 chips each, that's 32 RAM chips, and one of them is bad... which one !  LOL

The good thing is, correct me if I am wrong because I am no expert/pro, but from what I can see on the CPU board block diagram, there is no "MMU"/memory management chip implemented here ? So there is no fancy address space "translation" going on here ? So, that means that the memory address indicated in the error log, ie 0X7300000 and 0x732000 are the actual / physical addresses as found on the CPU address bus... so this means that with some patience, by studying the schematics, I (might) be able to figure out the address decoding taking place here, and find my faulty chip ! Will see...

Other good news is that they are simple static RAM chips, so should be easy and cheap to find replacements for them. They also a very low pin count of course, so that will help a lot when comes time to remove them from the board.

So all in all, looks like there is hope !   

Only slight bad news is that board view found in this scanned PDF, must be partial only, since they don't appear to show all these RAM chips, so even if I can figure out which chip it is from the schematics, I could not locate it (easily), physically, on the board...

Also of interest, with regard to the previous discussion on ESR of the electrolytics being actually "desired"/engineered in some place of the scope like the VCO : well I attached the schematic showing that little daughter board carrying the VCO, and there are two of those 33uF electrolytics. One of them is just decoupling the positive rail, so probably not doing much more "harm" than all his friends spread all over the board. However there is another one which I think might indeed in a much more critical/sensitive part of the circuit. No expert but looks like a typical LC resonant circuit in a BJT, and well one of those 33uF has one of its terminal connected to the coil no less. So I can imagine that it might have some effect on things....

[nctnico]

You better look for repair threads about similar scopes. There is a way to make the scope tell which chip it is. If you want to go in brute force then it may help to check the solder joints on the large QFP chips and see if they are OK.

[Vince]

Yep will do that later. For now I enjoy looking at the schematics trying to figure it out, but I guess in an hour or two, I will get bored and will start working on getting my GPIB computer to work and tell me what chip it is 

[Vince]

Yep, address decoding is a lost cause, silly me : the acquisition memory we are interested in, obviously connects to the acquisition chips for that particular channel... not the main CPU of course, stupid me. So no way to figure things out then, I give up. 

One interesting thing I noticed in the process though, was who the memory array is arranged. As you can see those x8 8KB SRAM chips are not arrange in a typical 6KB fashion. No, the acquisition chip addresses them as one 8K of 64 bit wide words.  I wonder why that is ? Maybe these little SRAM chips were not fast enough to stand the required 1GS/s throughput at the faster time base settings, so by splitting the memory array this way, each individual memory chip only has to stand an 1/8 of the total throughput. Just a shot in the dark again... I welcome the input from more clued people, as always...

So indeed the repair is stuck until I get GPIB working on my old computer. Need to buy a cable to start with ! LOL
If I can't get the old ISA cards to work, will have to buy yet another GPIB controller, more modern this toe, which I can use on my main computer but that's more cost which I can't really justify right now, plus it would mean taking the scope downstairs in the living room, not very practical.

So, since I have already bought these two ISA controller cards, I will first try to get that to work since it means zero added cost for me.

[andy2000]

It was a few years ago, but when I had to find a defective SRAM chip in one of these, I deliberately created a memory error by shorting one address or data pin of a RAM chip to ground to see which address the new error had.  This let me figure out for sure which channel had the bad chip, and I think narrowed it down to one of a few chips. 

I do recommend backing up the Dallas NVRAM which holds the CAL constants. 

[Vince]

It was a few years ago, but when I had to find a defective SRAM chip in one of these, I deliberately created a memory error by shorting one address or data pin of a RAM chip to ground to see which address the new error had.  This let me figure out for sure which channel had the bad chip, and I think narrowed it down to one of a few chips. 

That's quite clever ! I will keep this technique in mind...

I do recommend backing up the Dallas NVRAM which holds the CAL constants.

Yep, I do intend to get a programmer so I can backup (or modify/play with) each and every memory chip of each and every test I gear I have and those to come... but like everything else, it's not free and there is so much stuyff I need/want to buy to set up my lab... makes my head spin. Well, my wallet at any rate...

I did have a quick look some time ago on Ebay to check prices. From what I recall there was a popular/wide spread unit that cost only 30 bucks or so, but I also remember a video on Feedbackloop's YT channel, where he worked on a couple TDS 5XX scopes, that he failed to read the Dallas NVRAM with the cheap programmers. The thing would actually act is it managed to read the chip, but later when he wanted to restore the NVRAM/write to it, he realized the programmer had read garbage during the backup....  So he had to find a different programmer that would actually work on these particular NVRAM chips used in the TDS5XX.  Can't remember what programmer it was, though....

[Vince]

Looking again at the schematics, I guess one quick way to figure out, as a first step, which channel/bank of chips is at fault, would be to play with the common chip select line : "CSA", driven directly by/from the acquisition chip, via its two CS signals, CS0 and CS1. They are both shorted together so it's safe to assume they are one-collector type, unlike the address lines which are probably totem-pole so might bit risky to short their output... though if you have done it I guess they can cope with it.

So, back to CSA. it is driven through this R491  27Kohms resistor, how convenient. So there is really no risk whatsoever, we can just pull the right side of this resistor to Vcc , that would disable the entire bank of SRAM chips for that channel, and the CS0/CS1 outputs of the Acq chip are safe : whatever happens, the current going through its ouputs would be limited to Vcc divided by this resistor, so under 0.2mA, no harm...

Plus, soldering to this resistor is probably less risky (more room around its pins) , than fine pitched memory chips, I guess. Well that said maybe they are through hole/DIP packages ? Given the small capacity/low pin count of these chips,  and the age of the scope, I guess that's possibility...

[AndyC_772]

It was a few years ago, but when I had to find a defective SRAM chip in one of these, I deliberately created a memory error by shorting one address or data pin of a RAM chip to ground to see which address the new error had.  This let me figure out for sure which channel had the bad chip, and I think narrowed it down to one of a few chips. 

I did something very similar on a TDS540. If I recall correctly, there's a big (1206) link next to each SRAM chip, connected to a chip enable or strobe, but as I later discovered, it's actually shorted out by a PCB trace somewhere, and the link itself is entirely redundant.

I found out the hard way. One end is connected to +5V, and the other does indeed go to the SRAM. So, I replaced the link with a resistor, then figured I could ground the end connected to the SRAM via a multimeter in current mode.

I blew two expensive DMM fuses before I realised what was going on. Good job I had actually used the DMM rather than just connecting a wire between the SRAM pin and ground.

So, top tip: if you want to ground any SRAM pins to assist in fault finding, check very carefully what they're attached to first!

[andy2000]

So, top tip: if you want to ground any SRAM pins to assist in fault finding, check very carefully what they're attached to first!

That's a good tip.  I usually like to add a series resistor for safety (10-100 ohms works for most low voltage circuits). 

[Vince]

Yep, better safe than sorry 

[Vince]

Just ordered a GPIB cable.. these things, used, go for silly prices for what thy are, IMHO !     But such is the market.

Just ordered a Chinese brand new one on Ebay, will see if it's any good. Not exactly dirt cheap at 20 bucks (for 1.5m) but still less than half the price of a 40 years old one so worth a try.
I paid a little extra for shipping, in the hope that maybe it will arrive in a month rather than 2 or 3.... we shall see.

This gives me time to get my bloody ISA controller card(s) to work, hopefully !

And I can't resist, I think I will open the scope... these schematics have me confused, sheet 9 showing only 16KB of Acq RAM and all chips being marked as "unused", and with shunt resistors all around as mentioned by you chaps, then sheet #25 showing 64KB which sounds more like it, but with no shunts anywhere. Plus the board view being only partial and not showing any of these RAM chips  !  :-/
So, I wanna see what ACTUALLY is in this scope ! 

I am tired of speculations... I wanna see the guts of the real thing at last, let's open this thing, I say !!! 

[alm]

Just ordered a GPIB cable.. these things, used, go for silly prices for what thy are, IMHO !     But such is the market.

They are still being sold new for about $100 by the likes of NI and Keysight. And since most new instruments people buy them for sell for well over $1000, I imagine the price of a GPIB cable is not something their customers care about. An intermittent cable in a production environment can easily cost much more than $100.

The used cables are still relevant for new(ish) instruments that people like us buy. So unlike a parallel printer cable, demand stays relatively high. Add to that that used cables are often scrapped for copper, so a much larger fraction of old oscilloscopes end up on eBay than cables and probes. And you have a price that is costs as much as some of the instruments it works with.

I got some Agilent-branded ones for under $20 shipped from this seller recently. Have not tested them yet, but they looked good with only some light corrosion on the screws. One had a tiny tear in the insulation that is easily fixed with some tape.

[Vince]

I got some Agilent-branded ones for under $20 shipped

A good deal for sure !

[Vince]

OK, the beast is opened ! 

Boy, I am so pleased !  This scope is a joy to look at and work on... in 10 seconds it was opened and the CPU and Acqu boards readily accessible, all the components being on the visible/out side, just waiting for you to probe around, a dream ! 

The components density is surprisingly low, there is plenty of space to probe around, solder wire to help with probing or do mods or repair tracks. And most of the components, are SMD so easy to remove without damaging pads even on high pin count chips, yet the pin pitch on the RAM chips for example, is very large, it will be easy to probe them and hack the area to try and find the faulty chip.

These board are both beautiful to look at, as much as they are pleasing to work on, I find ! I am in love with my scope even more now   

So, with such great design and accessibility, I just can't resist the temptation to fiddle with it ! 

I started looking at the Acq RAM chips of course. They match sheet #25 of the schematic as I thought, with 8 8KB chips per channel, rather than sheet #9 which shows x8 2KB chips.  However I do see some shunt resistor all over the place. So it's a mix between sheet #25 and #9, in this respect...
I will try to correlate the actual PCB with the schematic, to figure out what these shunt resistor do exactly on my scope, before I blow anything  ;-)

Bad news is these RAM chips (datasheet attached below)don't appear to be available anymore, and I can't find a direct substitute for them. Nothing on Farnell, an don Digikey neither but a quick parametric search show they have 17 chips that might potentially cut it, though if you remove those that are only sold in bulk quantities, then only 6 or so remain, none of them in the appropriate package at that, but I guess I could adapt....    Still, would cost an arm and a leg to import from Digikey, for a 5 buck chip.

Can't believe a bloody SRAM chip is so hard to find.... 

Manufacturer :  "Performance Semiconductor Corp".   Part Number:  P4C164-20C JC 

They are 8KB ones as we know, CMOS, 5V supply, 28 pin 300mil SO package.   fast 20ns, as the part number suggests...

I can't find trace of this manufacturer, so either it went bankrupt, or it got taken over by a bigger player so tried to find the history of the company on Google to try and figure that out, but failed.

Anyway, let's start probing around ! Voltages and ripple.

I notice there are MLCC's only on the Acquisition board. The CPU board still has electrolytics, but the chap who sold it to me, which I just contacted, said he is sure he replaced all the caps, front panel included, however he says he might have replaced the CPU board with electrolytics again, but top quality Nichicon ones. It was a year ago so he is unsure... regardless, if ever they had indeed not been replaced, it would not be too much trouble doing so, since access is excellent and there aren't that many of them on the CPU board. Plus, I gotta make use of that little hot air station I recently bought, after all ! 

[Vince]

What do you know !!!  I tried my chance on Ebay and I found the EXACT same memory chip !   

http://www.ebay.fr/itm/P4C164-20JC-SemiConductor-CASE-SOJ-MAKE-PERFORMANCE-/162605837913

At 11 Euros a pop (shipping included thank God) though, I can buy 2 or 3 of them maybe but not more, I certainly can't afford tyo replace all 32 of them, so I really need to figure out what chip it is exactly that's faulty.

But I find it suspicious that this chip is available by some miracle on Ebay but not from the big players like Farnel or Mouser ?! hmm.... maybe these chips are just some crap that may not work proprerly. Maybe if I crack one open, I won't even find a die inside, it will just be a solid piece of plastic ! 

Still, I see no other source so no choice.

If really these chips are crap, I guess I can wait for a cheap donor Acq board to pop up on Ebay... and salvage all the RAM chips. At least some of them must be good...

OK so there are solutions out there, good...

[KE5FX]

Be sure to use a fan on that board when running without the case.  Some of those chips will get extremely hot if you don't.

[Vince]

Yep, seller told me he put a litel fan right by the hot chips, while trouble-shooting what would later be my scope.

However, thanks for reminding me, because I was gonna do without it at first, being over-enthusiastic as I am, and thinking taht the 5 minutes it xould take me to probe for voltages and ripple, would not be enough to endanger the power hungry chips.

But why take the risk, it's not worth it !  So, I will sort out a fan (or two) before I do any probing on this thing...

Have a dozen of old ATX desktop computer power supplies around, so they may become useful all of a sudden ! LOL  They come with either 80mm or 120mm fans I think, so I even the choice of the fan size. How nice is that. I could also dig out a small 60mm fan if that would be sufficient, because I have a couple left over from my recent Tek 2232 repair.

Oh, and about backing up the NVRAM, actually the seller did it for me ! I forgot about it, but he did, how nice from him.  I just ha da look at the dump. A big 512K RAM but mostly empty ! Maybe the bottom 15% and 10% from the top are used, but everything in  between is blank !  It's all binary data except for the full POST error log which is stored in plain ASCII in the bottom section of the RAM.

He also was thoughtful enough, you might notice it in the pics above if you look carefully, thoughtful enough was I saying, to solder a chip socket on the PCB, so that I can remove the NVRAM easily in the future ! How kind.

Ah, and the schematics make no sense with regards to this NVRAM !  On my PCB/actual scope, NVRAM is denominated U1108, which in the schematic is a 128KB RAM, not 512KB !  Also, next to the NVRAM I have U1107 which is another Dallas "tall" battery backed chip, marked "Watchdog", a DS1286. Downloaded the datasheet, it's the RTC of course, which has 64 registers and therefore only 6 address lines, but on the schematic this U1107 represents a 128KB RAM ! And I can't find the RTC in these schematics.  So I am well lost.... these schematics are supposed (says so in the footer of every page) to be specific to the 544A, my very scope, so I don't understand these inconsistencies... maybe they made variations of this scope but didn't bother telling anyone...

[Vince]

Alright ! Did some probing. Took my time to prepare the probing "session" as well as I could, so that it would hopefully turn out to be as uneventful as possible. I mean, sure I was excited to fiddle with this board, but at the same time pretty scared and anxious... that it would go wrong or that I would do something stupid and blow the thing and cry. First time I have the guts of such a complex piece of engineering on the bench, upside down, and having to keep it turned on and probing it for an extensive amount of time.

So I took my time to prepare the job carefully

1) Found a couple fans in the lab and made a little cable to go with them, some heat shrink, something tidy.  I didn't even have to dig out and dismantle my old computer PSUs: on the shelves I had something more straightforward. An old 3 phase beefy industrial inverter. had two 80mm fans on it, readily accessible, 10 seconds to take them off. Should provide enough airflow. Not too big not too small, two of them, sounded good. 12V DC, powered by the bench/adjustable power supply, I could vary air flow and noise level, impeccable, no overheating to fear, I would be able to safely probe for as long as I fancied, could afford to take all my time.

2) Looked at the "Power Distribution" schematic sheet (attached) to figure out where to probe. At first I thought I would do it quick and dirty by just probing straight onto the pins of the 40pins edge connectors coming form the PSU unit. Then when I looked at the schematic, I had to change plans if I wanted to do a good job : most of the rails had some LC filtering, so I would need to probe downstream of that, if my ripple measurements were to make any sense. Conveniently, most of these rails had test points associated with them, so I decided I would probe all of these... if only I could find them on that huge board !
I thought they would have to be next to the edge connector, but that was stupid from me. Actually all of these test points/LC filters, without any exception, where all the way to the other end of the board ! Makes sense now I guess : most of the board area, the first 2/3 of it, starting from the PSU edge connector, is the fast digital stuff/acquisition area. The sensitive analog stuff is all packed at the very end of the board. So if the LC filtering was done at the connector edge, then these clean rails would have to travel all over the board, traversing high-speed digital stuff, and once arrived at their destination in the analog area, they would not be so clean anymore, I guess ! So makes sense to implement the LC filtering after the digital area, and perform it locally, as closely as possible to the analog circuitry. That's how I understand it anyway.

Finding all the test points (9 of them) was a nightmare, time consuming and eye aching. Took me nearly well over an hour I reckon, brrr. So no way I was gonna go through that pain WHILE probing. I wanted the probing to be quick and efficient.  So I drew a quick sketch of the board, and every time I would manage to locate one of those test points on the board, I would mark it on my sketch, so I could find it easily and quickly, come time to probe it. Sounds like overkill ? Was well worth it to me, probing was then a breeze, I could concentrate on what I was doing and not waste time.

Once I had located all the test points, I made sure I had an appropriate grounding point for the ground lead of the probe to attach to. Last thing I wanted was to improvise grounding during probing, and end up stretching the lead and having the alligator clip maybe pop out and fly on the board, shorting things....
So, once I had the "map" of all my test points, I split them in two groups, and found a safe and efficient grounding point for both of them. First group of test points was in the bottom right corner of board... there happened to be an unpopulated coaxial connector there... was an ideal ground point !
Then the other group of test points was located a bit further north,  in the jitter/interpolator area, near the VCO. There was a PCB mounting hole there... so I just put back its corresponding screw, and the alligator clip had a good grip on it so I was happy.

Then prepared a table on paper, listing all the test points and what voltage was expected, and what DC level I found, and what ripple I found.

I tried to streamline everything so I could concentrate my brain and gestures on probing safely, nothing else.

Was well inspired, all went well and joyfully.

So powered up the scope, a bit anxious... seeing it naked and upside down on the bench, had me a little uneasy/anxious, somehow... so I applied a signal to Channel 1 just to see if it still worked.... and it did. Was at peace then, and I could start probing around....


Results are (see table below for the details)

1) DC levels : all fine. some 5V rails are a tad low but nothing to be worried about I think. 4.9V instead of 5.1V

2) Ripple/AC coupling : absolutely none ! A flat trace. OK, I used a x10 probe so even with amplifier cranked all the way down to 2mV/div, it was 20mV/div on the screen.. still, enough for any abnormal ripple to be visible, if there was any.  At some point, I diiiiid see a tinnnnny ripple, if I put the brightness to the maximum. See picture below. It's really minuscule, but buried in the noise I can see what looks like a periodic signal in there. Amplitude is next to zero so I don't care, but the period seems to be a tad more than one division, say 1.1. Time base is at 10us so that would make for a 90kHz signal, I guess it's in the range of typical SMPS operating frequencies... my Tek 2232 was running at 60kHZ for the preregulator, and about 20kHz for the inverter driving the main transformer.


Test point # |  Expected  | Measured | Ripple
--------------------------------------------------------
    515      |    +15V    |  +15.08  |  Dead Flat
    516      |    -15V    |  -15.01  |  Dead Flat     
    517      |    +5.1V   |  +4.87   |  Dead Flat     
    518      |    -5.1V   |  -4.99   |  Dead Flat     
   1559      |    +5V     |  +4.89   |  Dead Flat     
   1560      |    +5V     |  +4.90   |  Dead Flat     
   1562      |    -5V     |  -5.00   |  Dead Flat     
   1611      |    -5V     |  -5.00   |  Dead Flat     
   1616      |    -5V     |  -4.92   |  Dead Flat


So looks like these MLCC caps are not that bad I guess ?

Oh, TP1612 sorry I could not find.. spent 30minutes trying to find it, no joy !  I did find one that looooooked like it could have been it, see picture : silk screen buried under 2 resistors, couldn't read the TP number in full. Looked like it could potentially be the one, and it was in the expected area : near the inductor/LC filter that corresponds to it. But I did a continuity check with its inductor, which I could locate and... no joy, they are not connected, no luck.

Generally speaking I would have to say that after a while looking at the silk screen of that huge board, you eventually get to a point where you are not as lost/overwhelmed as you were at the beginning, because it turns out that Tektronix used a clever numbering scheme for all the components and test points. Components which belong to a similar sub-circuitry, usually possess a similar "prefix". For example in a given section (channel 1, 2, 3, 4, jitter 1, jitter 2, VCO... you would get for example component numbers which all start with the same digit (for a 3 digit number) or the same 2 digits (for a 4 digit number). So this way you can quickly find your way in this large board : you just have to look for the prefix on the silk screen, and you can "navigate" on the board quite efficiently.  I like it, thanks Tek !   Yeah I know, you will tell me it's a common practice in the industry and that all the manufacturers stick to this naming "convention"... if this is the case then that's great ! 

As you can see on the schematic, the digital 5V rail has no test point associated with it, probably because it's so easy to locate / probe it anywhere... so many digital chips all over the board ! Most importantly, we can see that unlike all the other rails (being sensitive analog stuff), it is NOT LC filtered ! So I thought if I had to witness some ripple, it would have to be there. So I checked DC voltages directly on the power pin of each and every of the numerous 74XX logic chips I could see on the board. 5.08V for 5.1, perfect. Then I did the same in the Acquisition area : checked the power pin of each and every one of the 32 SRAM chips : a solid 5.08V again, no worries. Then for dessert, I checked for ripple with the scope... AH, I knew it, HERE we have some measurable ripple ! Identical on all 32 SRAM chips.
Was quite noisy and a bit unstable, so switched to store/digital mode and applied averaging, 16 samples. That got me a perfectly stable and clean/sharp trace, so I was able to take pretty decently accurate measurements using the cursors.  See pics. Amplitude is 22mVp-p . Service manual doesn't go to component level so they don't bother giving ripple figures sadly. however if I take the specs for my 2232 as a rough guide, then I would say the TDS is alright. Tek 2232 allows only a few mV of ripple for the analog rails, as you would expect. Only 8mVp-p for the positive rail and even much less, 1.5mV, for the negative rail. However for the beefy 5V rail supplying the storage/digital board, it's less critical : they allow up to 20mV (peak to peak again). So here we have 22mVp-p ... so I guess it's nothing catastrophic and I should be happy....
Ripple is around 30kHz BTW.


So, that was my first probing session on a large digital board... overall thanks to the prep work, it went extremely well and was quite enjoyable. I now feel much more confident about trouble-shooting this scope, doesn't scare/intimidate me any more. You just need to know what you are doing and do things calmly and be organized/plan things.

Thermals : as can bee seen on the pictures, I put the two fans right in front of the heat sinks. I regularly finger checked the heat sinks of course, not knowing what to expect exactly, but I am glad to report that after what must have been almost an hour or so of probing, an extensive amount of time at any rate, the hottest chip, by a small amount, was on channel #1, probably because it was the only active/turned on channel, and even then I would be hard pressed to say that it was "hot". It was somewhere between plain cold and sliiiightly warm-iiiiish. Really barely warmish !  So quite happy. And the fans were not even running full speed, very far from that : 5V for a nominal 12V ! Much more ear friendly, yet plenty enough air flow to keep the chips from overheating.
As soon as I turned off the scope, I flipped it back in the upside position, to check how hot the CPU board had gotten. CPU was dead cold. Only the video controller was a little bit warm, but again nowhere near something I would even remotely consider calling "hot".
So I was quite surprised to be honest !  Pleasantly so, of course.

So now I know I can probe this scope for any amount of time, it will be just fine !

Finally figured it out with the previous owner/seller : yes, he did indeed replace all the electrolytic caps on the CPU and front panel and serial interface board...by Nichicon caps. So still electrolytics, but brand new ones and top quality. So she will be alright won't she.


So quite happy overall with this first intimate contact with this complex machine. To all the newbies like me out there : don't  be afraid of these beasts, you can do it ! 

[Vince]

BTW,  although this 20mV ripple does not look like much on the screen, one must consider the x10 probe here, so in fact all the scope had to work with was a tiny 1mV signal, PEAK, yet it could display a stable and clean trace on which we could actually take useful/meaningful measurements.

For a 30 year old "old tech" scope I think it's nothing to be ashamed of !  So I am really glad I have this little 2232 scope, more than happy to have spent 2 months fixing it recently.. he deserved that attention and paid me back today... So, I say we ought to show some appreciation to these old scopes, they deserve a big pat on the back.....

[Vince]

Progressing : after 48 Hours of a very rough road (learning as I go...) I have finally got GPIB working on my old 200MHz Pentium. The NI's ISA GPIB controller card I bought works just fine. Downloaded drivers, utilities and application software from NI's website, for both MS-DOS and Windows 95.
Got it to work just fine in both environments.

So now that old Tektronix GPIB service software has the legacy hardware it required to connect to the scope.... and I also have the practical/user friendly GUI on Win95 to easily connect to any GPIB instrument, set up experiments, scan the bus, do whatever you can do with GPIB instruments, all in on nice easy to use interface. Can't wait to receive my GPIB cable and start playing with it !  Hopefully it will tell me what RAM chip is bad exactly....

While waiting for the cable to arrive from China, which may take a month or more, I will keep trying to find the faulty chip "by hand". 

I also just found this interesting thread on a specialized Tektronix forum, " Tek.com " :

https://forum.tek.com/viewtopic.php?f=568&t=137307

.. where someone explains how to connect to the internal "service port" of the CPU board, using a serial cable/terminal.
I have bags of old serial cables no worries, so I am very tempted to try this out, to see if the scope might spit out useful debug information during boot... and if not, well would still be fun to try !   

[KE5FX]

Progressing : after 48 Hours of a very rough road (learning as I go...) I have finally got GPIB working on my old 200MHz Pentium. The NI's ISA GPIB controller card I bought works just fine. Downloaded drivers, utilities and application software from NI's website, for both MS-DOS and Windows 95.
Got it to work just fine in both environments.

Looks good.  Does the software support all of the TDS 5/6/7 scopes, or just the 544A?

I also just found this interesting thread on a specialized Tektronix forum, " Tek.com " :

https://forum.tek.com/viewtopic.php?f=568&t=137307

.. where someone explains how to connect to the internal "service port" of the CPU board, using a serial cable/terminal.
I have bags of old serial cables no worries, so I am very tempted to try this out, to see if the scope might spit out useful debug information during boot... and if not, well would still be fun to try ! 

That's actually Tektronix's official customer support forum.  It's not too active, but some very knowledgeable people occasionally pop up there.

[Vince]

Looks good.  Does the software support all of the TDS 5/6/7 scopes, or just the 544A?

The version I have, according to the release notes, was the initial release, v1.5, which supported only the 544A. You've got start somewhere.
But then I also have a copy of the next revision of the software, v1.65, whose release notes say taht they added support for the the rest of the 'A' series, as well as "vanilla"/original 500 series. You just have to select the model you want to work with, in the "DUT" menu (see top left of the screen). I looked at the files and basically they just added new definition files for each model, and then you just load the one you want...

If that software worked on the original and then on the 'A' series, I don't see why they would not have kept it using it for the later models.... but then I don't know where to find definition files for the other models. I just happened to have the 544A because the gentlemen who sold the scope to me was kind enough to supply it, as well as a backup of the NVRAM, and the schematics.

I attached below a copy of what I have so you can see for yourself.

That's actually Tektronix's official customer support forum.  It's not too active, but some very knowledgeable people occasionally pop up there.

Thanks, good to know.

[alm]

I imagine similar software may also exist for the TDS 600/700 series. Whether it is publicly available is a different matter. Looks like most of it is attached to this post.

Not sure if the link has been posted yet, but there may also be some helpful software on Hakan H.'s site.

[Vince]

Thanks for the links alm, didn't know about them.. bookmarked now.

As I go , I realize there IS lots of info, tips and tricks, experiences etc on these scopes.. but it's scattered all over the place, either here or in other forums like Tek.com or Tekscope, so one is likely to miss 90% of it, which is sad because these scopes are popular, for good reasons, and will continue to be popular for quite some time I feel, just because they represent such excellent value for money compared to a similar spec new Tektronix. Prices just don't come down, even 25 years later, and there is no reason to believe they ever will : Tektronix has to make a living !

So I think it would be worth creating a central resource, a focal point, a "sticky" thread or whatever... where all the interesting info is gathered in one place, so that people who get one of these scopes can get up to speed quickly, efficiently, and not miss potentially interesting or useful information.

[alm]

The TekWiki might not be a terrible place for some of that. A wiki is easier to keep up to date and organized than a thread. I am not sure if the mods want a sticky thread per model, but that is not my call to make. I usually search both the eevblog forum (the built-in search engine sucks) and the TekScopes Yahoo! group archives for information.

[Vince]

I thought a sticky thread on EEVBlog would be the easiest for people to contribute too, and the best place (most traffic happens on EEVBlog these days, it's quite a famous forum now). Less formal too, I mean this wiki site looks more like a very polish and static "museum". We would need something less formal but more practical oriented. A Wiki needs much more discipline (and technical knowledge) to contribute to, than a standard forum like EEVBlog, this would limit the number of people that would actually be able to contribute to the document. Tek.com has not enough traffic as I was justs told, and Tekscope/yahoo is technically a pain to deal with, too cumbersome. To teh point that I actually see people there pointing newcomers to thread on HERE.
So in all I think EEVBlog is the best place, and a simple sticky would be just fine, in the "repair" section of the forum it would be at home.


Anyway, for now I will just have to do like you and everyone else, ie search this forum and Tekscope and Tek.com.


Ah, I could not resist : just bought another GPIB Cable ! From the seller in the UK who had wa few for sale. His auctions ended just 5 minutes ago. Starting prince was reasonable so I tried my chance 30 seconds before the end of the auction, and what do you know, there were no bidders on these cables !  So I got one, yeah !  He had several for sale, picked a 2 meters long one. Also had a molded type one, but I preferred this one he had too, that's the one I bought :

http://www.ebay.fr/itm/322614513374

...because although the picture is crappy, it looks like the connectors are metallic and screwed, not molded. So this way if the cable does not work, or works unreliably due to a bad connection or broken wire, I might be able to open p the connector and fix the wires.

So that's too cables in the mail now !    Both there advantages and disadvantages. The one forom  China is new... but might be crap/useless and may take a very long time to come. Used one is... old, so probably better construction/better quality. Possibility of bad wires but as I said offset by the fact that it might be possible to open it up to fix it. But also, cable is in the UK so not far from France, so should arrive much more quickly. 
With these too cables hopefully one of them will be good/usable, and if both turn out to be good well, no worries, the whole point of GPIB is to use several cable to chain instruments ! 

Oh, the NI GPIB software on Windows is driving me mad already : at first I installed it with the controller card configured to used the older PC2 controller. Was all fine. Then I tried ti improve things and switch to the newer PC2A not PC2. Works perfectlty under MS-DOS, but on Windows the NI software, when I deleted the PC2 interface and tired to add a PC2A instead... well see screen cpatur bleow ! How odd ?!  It COMPLAINS, and "STRONGLY" asks me to revert to the older PC2 ! What the ?!

What's point of me buying a nice genuine NI's hybrid PC2/PC2A controller card, if their software then forces me to stick to the old PC2 ? Weird.

So I reverted to PC2 non choice.

I ma not worried, it's gonna work just fine I bet, but if PC2A was brought to market then I guess that's because it introduced some desirable things.. better performance and/or more features. I am logically wondering what the differences are exactly, so that I know what I will be missing !

If anyone knows... might post on the forum about that. Couldn't find info on Google somehow (OK I didn't try for hours...).

[andy2000]

The Tek calibration software has its own built in driver, so you don't need to worry about the DOS and Windows drivers unless you want to use other software with it.  That's the reason the calibration software only works with those specific cards.

[Vince]

The Tek calibration software has its own built in driver, so you don't need to worry about the DOS and Windows drivers unless you want to use other software with it.  That's the reason the calibration software only works with those specific cards.

Yep that's what I thought too. However I still needed/wanted/welcomed NI's DOS utility tools so that I could, by trial and error, figure out how to set an undocumented dip switch on the board.  I bought a genuine NI board, NI has a 68 pages long "getting started with GPIB" guide which is based on my very board, but somehow they decided to skip completely the one and only switch that was not obvious. DMA/INT/base address sure, covered, but that other switch, I had to figure out myself. So once I was sure that the card was configured properly and working well, then only I could start looking at the Tek software. Thing is, this software too gives me headaches : when you run the installer, it asks you about some mystery switch on the GPIB board, but really I couldn't make sense of it/figure it out. So, had I failed to get that Tek software running, I wouldn't have known if it were because the default value offered for this mystery switch, was not the right one, and/or if the GPIB board was defective (it 's 25 year old untested unit after all ! )and/or mis-configured and/or some problem with the host computer.

So once was I  sure, thanks to NI test/diag programs, that the board was 1) not defective 2) configured properly, then at least I knew that the Tek S/W, if it failed, would not be because of my board, but more likely due to me not knowing what to do with the mystery switch setting it would ask me about. I still have non clue what this switch is for, and I will most likely never know, but luckily the software decided to work so I guess the offered default value was good enough !  Phew.




Anyway, I made some progress on the repair, so much so that actually I think I may well have fixed it ! 
A tad presumptuous I know, only time will tell if I really fixed it or not, I guess...
If it behaves for 3 or 6 months, I will call it a success... let's be modest because it's the first time I work on such a complex piece of gear, I mean it's no toaster or coffee machine for sure !


Lots to say, so let's stick to chronological order so as not to get lost in too much digression.

-  I was again studying the schematics to try to figure out a safe way to individually disable these SRAM chips. So in order to safely do that, I had to REALLY understand how it was all put together. If you just want to skim the surface then it's simple : the board was meant for 8K chips (28pins) so as to cater for the largest memory these 500 'A' series could have, i.e. 50K points (schematic sheet #25, for channel A as an example), but could also be fitted with the smaller 2KB chips (24 pins), as seen on sheet #9, as posted earlier. The 3 shunt resistors we see are not there to help you debug in any way, I think, but more to "patch" the PCB so that it can be modified on the fly on the production line to accept either memory chips. That's scratching the surface.
Now when I tried to dig deeper to REALLY 100% understand what was going on, I failed, because I ran into inconsistencies between those two schematic sheets, and saw things that I just could not make sense of. So, I probed around on the board, to try to suss it out, but this only revealed even more inconsistencies ! So, I gave up, at least for the time being.
One thing was for sure though : as was hinted at by someone earlier on, the shunt resistor that runs from Vcc to the active high chip select line... is indeed redundant : I removed a couple of them on some random SRAM chips, just to see for myself, and indeed there is a trace inside the PCB (not on the visible/top layer), that shorts the pins, so no need for this resistor, you might as well remove them all and make the scope a little lighter  ! LOL

- So I came back to my earlier idea : if I couldn't isolate individual chips safely, at least maybe I could narrow it down to a particular channel/bank of chips, by taking control of that 'CSA' line, coming from the MUX chip, which enables the entire bank of chips at once. There is conveniently a resistor in line, which I could remove. This would isolate all the chips from the MUX CS output and I could then safely drive this common enable pin at will. So, WHERE is this resistor ?
Couldn't find it anywhere... had to be on the UNDER side of the board, my luck !    Just what I did NOT want to do : touching these 8 tiny and fragile looking coax connectors so I can flip the board ! 
So before I did that and potentially did some irreversible damage to these connectors... I decided to at least try and confirm the existence of these resistors, and that they were not shorted or god knows what, again ! This scope being full of surprises...
So I used the ohmmeter, probing the top side of the board to blindly search for this resistor... and luckily I was able to demonstrate it's existence, YES, at last something that goes according to the schematics ! LOL....  or almost : it's not a 27.4 K resistor, no.. it's a 27.4 OHMS one ! What looks like a 'K' on the schematic, is in fact an 'R' with its head chopped off, go figure.

So, knowing that this resistor, and the hopes that were associated with the debugging it would allow, did indeed exist... I decided to take the risk to unplug/mess all these coax connectors.

- Debugging could commence !  I removed the resistor from Channel 4, just because it was the closest to me so was more convenient...
Then powered-up the scope, as soon as it had booted up, I ran to the utility menu to see the error log. This mod caused about a page and a half of new errors ! Sure I expected "some"... just not THAT many ! LOL  Luckily most of them were memory related which made sense isn't it... But the most important were the last two lines, the very last lines... guess what ? Yep, there were my usual 2 R/W AcqMem errors again, at 0x7300000 and 0x7320000 (from memory, pun intended).
So this kinda demonstrated that I could isolate the faulty RAM chip this way. So, I kept going, disabling CH4 + CH3, still got my 2 usual errors. So disabled Ch4 + Ch3 + CH2.. still there. Great I thought, found it, the faulty chip is on Ch1 !  But, because I wanted to be real sure... I disabled Ch1 as well... juuuust... to see.
Glad I did, somehow : the errors would still show up ! Yes, even with ALL 4 channels disabled ! Then I spent quite some time doing more trials, trying out pretty much all 16 different possibilities of enabling/disabling channels. Not all 16 of them, but at least 10 that's for sure. The 2 errors would not go away.

- So at this point, it kinda implied that the root cause of the problem maybe was a bit more upstream. Still on the Acq board, but a bit more upstream.. or even why not, even further up, on the CPU board. After all the POST always displayed TWO error categories : "Acquisition" and "Acquistion / Processor".
So, from the start it kinda implied that maybe, just maybe, the problem was somewhere at the interface of these two boards, in some way.
Still, point is : it looked like the problem was not related to the RAM chips, it was now something vague that I had absolutely zero idea how to trouble shoot ! I thought I would probably end up with an expensive door stop, and cry. I thought with some luck, GPIB would be able to give me a clue/starting point, though I was not really counting on it, trying to be realistic...
So, since the GPIB cables are not there yet, and before I put the scope on storage while waiting for them to arrive, I decided to do 2 things, as a last, desperate attempt. First I reflowed the big MUX chips, and all 32 SRAM chips, just in case, though I was not holding much hope since they all looked quite nice to me. But why not. Then, I gave the underside a quick visual inspection, even though there is nothing on there but a bunch of tiny passive components, and definitely no bulky and leaky electrolytic caps. So I just didn't to see anything suspicious on that side of the board. Still, again, for good measure and because I was desperate....
As expected, not much to look at. I only noted maybe a small group of components whose solder joints looked less shiny than the rest of the board, but really nothing dramatic, at least with my naked eyes. So for good measure, I put some IPA on there, and scrubbed the components with and ESD safe "tooth brush", that made the joints looks a bit better. Then I reflowed all the area with my cheap and newly acquired hot air station... if just to justify its presence in my lab ! LOL
Really didn't think much of any of the above two actions.  So flipped the ACQ board and reconnected all the ribbon and coax cables. Powered up the scope..... what do you know, clear POST and no new errors in the log ?! 
Too good to be true, for sure ! So I put the cover back on, so I can have the thermals right and do some proper/further testing. Powered up the scope, started to boot, OK, graphics routines displaying funny things as always, no worries, OK... was eagerly waiting for POST to complete and tell me the result !!!  ... but.... the boot sequence did NOT complete ! Halfway, the screen turned all black, and the scope froze in mid air ! WHAT ?!!!  Oh no !!!!!

So, put the scope back on the bench, opened it up... turned out I had connected the 'D1' board upside down ! That's the board/"cable" that sends the CPU data and address buses to the ACQ board and the Video trigger board if you have this option.  Yes, it is actually possible to plug this board the wrong way, and the scope WILL power up and start booting, it will NOT blow up... but it will never complete the boot sequence either. So just in case this happens to someone... no need to panic, just check that board ! LOL

So, corrected that, put the cover back on again, started it... OK works now, phew !!!!
POST is still clean but, hey wait a minute... there is not graticule on the screen, and no trace at all, what the ?!
Rushed to see the error log.... flooded with all kinds of weird and wonderful things ! NOOOOOO !!!!
At this point, I hesitated between committing suicide and/or throwing the scope out the window !!!
I was totally desperate. Then I thought hmmm... why not try that "Tek Secure Erase" thing that one of you taught me the other day, which did wonders.... and sure enough it did wonders !  That cleared all the errors, trace was back on the screen and all was fine again ! 
Retrospectively, I guess it was obvious : I had put the D1 board back to front so obviously the data and address buses, and lots of control signals of all kinds, were all mixed up. So no wonder this led to bags of errors, which I would later see once I had corrected my mistake and the scope had actually a chance to boot and display them. So since I had now corrected my mistake, all that was needed was to clear all these errors. Sounds logical afterwards, but in the heat of the action, trust me I could not think clearly that's for sure... I was overwhelmed by this feeling of helplessness and despair !    Lack of sleep didn't help either, I wasn't exactly at my best, at 5AM again.


So, cleared the errors, cycled the scope, a clean POST would follow, and still no new errors showing up in the log... looking good. Cycled the scope 2 or 3 times, still good. Did a quick sanity check on all 4 channels, displaying a 1MHz sine wave, trying all the basic stuff, looking good. So decided to give it a good run : I let it run/warm up for 8 hours, while I was getting some much needed sleep. When I woke up, scope was still running fine. Checked the error log, no errors were triggered during these 8 hours. Cycled the power, still good. Sanity check still good. So then I turned it off and let it cool down for about 2 hours. Then powered it back up again, still clear POST and no new errors in the log, sanity check still good.  So.. I decided that I would call this a "fix" for now !!!

I mean, I don't think it's just shear luck ? When I was playing with the ACQ board, disabling/enabling channels for literally hours, I got my 2 errors EVERY SINGLE TIME !  And then, I reflow the chips, and brush up and reflow a few passives and all is well I must have done something right ! Well, something that helped at least. I don't think it was reflowing the digital stuff that helped, because of everything I said above. However I think that the few passives I brushed on the underside of the board, are more likely to be the culprit :

1) When I looked at them with my naked eyes, they didn't look that bad. Sure not very shiny, but really nothing to write home about, or so it seemed. But I took macro pics of these joints just so I can document this thread, and because well.... I like macro PCB "porn", I admit  LOL  So, looking back at these components, this time on the PICTURES... boy, sure enough those joints were crap !!! Oh dear...

2) The corresponding area on the top side of the board, is actually in the analog section, the part of the board that got 99% of the damage from the electrolyte. There are like 2 or 3 dozens vias in this small area (like 10 square inches or so, see pictures), so maybe the electrolyte managed to seep into these via and get to contaminate the underside of the board this way. Don't know.

3) Analog part it might be (mostly a couple TL074 quad op-amps), but according to the schematics this affected area is none the less firmly involved with the acquisition circuitry (well, its the ACQ board, admittedly ! ). The sheet is named "CLOCK DAC BUFFERS  & ACQUISITION CLOCKS"....  these op-amps drive two fancy ECL logic chips that have to do with the acquisition clocks of all 4 channels, so surely must be important 


So I could have left it at that and moved on... but that's not me, I needed more out of this repair... so I looked at the macro pictures and realized that one of the two TL074 chips had one of its side heavily reworked with lots of ugly flux residue, it seemed to me.  No way I would leave the scope like this, so I pulled the cover again, cleaned that up, then realized that in fact there was flux residue all over the analog part of the board, the part that got the initial electrolyte damage. So I cleaned that up too, taking care not to damage the many tiny wires that had had been soldered in many places to repair broken traces.

Then I thought well, for extra peace of mind, why not check some voltages in this op-amp area, to make sure the scope is indeed feeling OK and not "on the verge, may fail again any time ! ".  So I looked more closely at the schematic, that's sheet #20, then wanted to get a broader picture/understanding, so I rewound the signal path upstream, and landed on sheets #19 and #18. All 3 attached below, so you can follow me along.
I quite liked this section, found it interesting somehow (a mix of analog and digital, and simple text-book design that even I could understand), so I decided to do more than the bare minimum, and meant to spend say an hour probing around, once I had first ensured that vital signs were doing well.  The service manual does not go component level, so if one wants juicy details, one has to probe around and figure out things by himself. So I did.

So, this section spans these 3 sheets. This is how I understand it :  at the beginning (sheet #19), we have a DAC, U900. This DAC produces analog voltages for a whole slew of signals, 4 of them being the ones we are interested in here (sheet #20) : "ADLY, BDLY, CDLY and DDLY". The DAC output is symmetrical and has a peak amplitude of 10.24V.  I checked, it's good. Uses a 10V reference as well, this one is good too (9.990V). The output is then scaled down by a simple voltage divider (R903/R904), then "buffered" by an op-amp wired as a voltage follower, as you do. Test point TP 912 at its output indicates 1.71Volts, I get that too, no worries.
From this point, this 1.7V signal is the analog source signal that will then be fed all over the place, to a bunch of analog 1 to 8 switches/demux, in the form of simple 4000 CMOS chips, 4051 to be precise. You can see one of them near the DAC of course, but also many more on sheet #18. So basically, the DAC produces various voltages, its output is constantly changing (see pictures) . The CPU drives this army of analog switches, and the DAC, in unison: it selects a particular analog line via these many switches, then it asks the DAC to produce the appropriate voltage for that particular signal, whatever it might be. Then, CPU switches to the next analog signal, asks the DAC for a different output, and so on, it goes round all the analog signals one by one, round and round. The switch we are interested in here, is U941, bottom right corner of sheet #18, so I probed that one. I probed its INH(ibit) pin, so I could see 1) for how long a particular output would be turned on and 2) the "refresh rate" of a given output : how often does the switch serve a given output/signal.  See pictures below, from the Tek 2232. I didn't both measuring precisely using the cursors, I just wanted to get an idea, but you can see for yourself easily enough, the readout indicates gain and time base settings.  So, it turns out that a given output is "ON" for about 60/65us, and is "refreshed" every 6ms or so. So it's "ON" only 1% of the time.
That's bad I thought... we want presumably a stable/DC voltage, not some chopped off signal ! My fears were soon to be cleared, once I switched back to sheet #20. Here we can see that the 4 signals, one for each of the 4 input channels of the scope, and the first thing see we see in the path, is a little 10nF capacitor, which I guess is all it takes to hold the charge/voltage steady, in between refresh cycles. Indeed I measured it, it's a perfectly flat/steady voltage, no worries. The capacitor symbol is a weird looking 3 terminal thingy. I thought well, must be some kind of special purpose component, designed for this type of application. Cool I thought, I will learn something. So I looked at the board, searching for a 3 terminal thing...nothing to be found, in practice they used a bog standard 2 terminal cap, nothing special whatsoever ! Was kinda disappointed.

Obviously, before going any further, first thing they did was again put a voltage follower op-amp, before doing any further processing. Then the next op-amp is wired as an inverting amp, again a text book example, which does some signal conditioning. It does 2 things at once from what I can see (other than inverting the signal, obviously) :  1) it scales the signal down, from a 3.4V span (+/- 1.7V again), down to a 1.5V excursion (from -3V to -4.5). Then it adds some negative offset, so that the signal is negative at all times. I measured that, works fine again. Have a -3.0V output for a -1.7V input.

And that's about it, we have reached the end of our little journey : this signal is then fed to the input of that ECL logic chip, which then turns this single-ended signal into a differential clock output. Multiply all this by 4 of course, for all 4 channels of the scope.

Now we can sit back and wonder about a few little things we noticed along the way :

1) The DAC appears to be 12 bits (12 bit wide data bus at least, according to the schematic), but looks like the CPU only uses 8 bits : the bus driving the DAC is only 8 bit wide : the upper 4 bits are repeats of the lower 4 bits. Well maybe the CPU is writing to the DAC in two steps, a byte first, then the remaining 4 bits. Haven't pulled the DAC's datasheet/dug any further (it's an AD 667 ) to see if it's a possibility.
However, the CPU is a 68020 IIRC, so full 32 bits data bus, so plenty capable enough to write the 12 bit word in one single step, why break it down into two accesses ?  Less data lines on the Acq board maybe meant easier routing and /or less digital noise to deal with, especially since that DAC is in the middle of the sensitive analog area of the board, so it must keep it quiet so to speak, I guess   As always, any knowledgeable input is most welcome ! 

2) The DAC outputs a symmetrical 10V signal, but I don't see any negative supply voltage going to it ?? I only see the positive 10V reference voltage, which I measured.  There is a capacitor connected to it though, so maybe, just maybe but I find it very unlikely, it uses a charge pump MAX232 style, to produce its negative 10V by himself, locally ? Silly I know, forget I said that ! LOL

3) "our" analog switch, U941, uses only its first 4 outputs, so technically you only need the two lower order select pins, the third select pin can just be tied to ground, but go figure they decided to drive it anyway ?!  OK, out of 7 switches, it's the only one that doesn't require all 3 select inputs to be driven, so maybe they just wanted to rationalize/streamline the routing/design, I don't know.


Anyway, I quite enjoyed working on my scope, love it more than ever now that I saw its guts up close and got my hands dirty, and am glad I could fix it.

Goes to show that indeed, a thorough visual inspection is the first thing to do, always. Alllllll- ways.  That said, again I could not see much with naked eyes, I just got lucky. It definitely motivates me to get a microscope (meant to anyway) so that I can easily look at solder joints in detail and not miss any thing. Had I had a microscope, I would have taken the board out of the scope first thing, and inspected it from edge to edge, and sure enough I would have spotted these horrible joints right away, in a matter of seconds, no dicking around for weeks or months, chasing red herrings again (my specialty, trademark ! LOL ) like these RAM chips or whatever else might have been next !

So if the scope fails again, I will go straight at this ACQ board again and inspect all the joints really, really well. Hopefully by the time it fails (though there is no obligation to do so, please, little TDS ! LOL ), I will be better equipped. My lab is still in its infancy, getting a bit better by the month, but still ways to go.


Time for the attachments. I put a pic of the underside of the board, highlighting the area of concern/dodgy joints, in red. Also a pic of the top side. The red area corresponds to the red one on the underside of course. There you can see the two Quad op-amps TL074.
In yellow it's the area that initially got damaged by the electrolyte. This is where the chap who fixed the scope prior to selling it to me, had to do a lot (a lot) of rework/fixing. So that's all over this area that I found flux residue, which I cleaned.  In light blue is the area corresponding to the section spanning the 3 schematic pages that we just "studied"/probed, i.e. the original red area + some more.


So this is it, scope is fixed !  So now I can switch to the more "fun" stuff : connect to the GPIB port as soon as I get my cables, so I can :

- recover the FFT feature / Advanced Math / Option 2F , which is supposed to be standard on the 544A I gather, but which somehow is missing on my particular scope ! I hear it's just a bit to flip in the NVRAM, so let's do that. Try at least.

- see if there are some more cool options I could activate via software.

- back-up my firmware which is revision 3.8.3, and upgrade it to the newest revision : I see on KO4BB site, that there is a 3.8.4 release. No idea what got changed in that release, though ! Any idea ? There is just the FW image, no accompanying "Readme" file.

- see if there is some hack available to improve the scope. I seem to remember that this scope can be upgraded to 4GS/s sampling rate ??

- As for analog bandwidth/front-end, I saw somewhere that a simple H/W hack (adding 4 resistors on some existing but unpopulated footprints, somewhere, (Attenuator board I guess...), is all it takes to upgrade from 1GHz to 2 or 4GHz can't remember. Sounds too good to be true but well, if Rigol did such things, why not Tek at the time.... 
I guess it makes sense to design for the high-bandwidth scopes,  only one front-end / R&D cost to pay for, then limit it artificially on the lower end/cheaper scopes, rather than design a purposefully limited/lower spec front-end.
However I don't recall if this applied to the 500A series, or the 700 series, not that I know what are H/W differences between a 500 and 700 anyway, or with the 600 series even, for that matter  ! Still a lot to learn eh... 

[Vince]

Just noticed on the waveforms above. I measured (roughly) the "ON" time of a individual port of our switch to be 65us.   I thought well, I could just as well have measured it at the output of the DAC, from its "stepped" waveform, you can easily see how long it holds the voltage for a given signal. So I thought well it should match what I measured on the switch. But not quite... the DAC holds it for what, 100us ? And the switch for only 65us, 35us less ?

I guess the CPU is allowing for some setup and hold time here, at the switch ??  Plus the timing required by the CPU signals to actually drive the control pins of the switch.   Would be easier if we could arrange a meeting with the engineer(s) who designed the thing, sure I would learn lots of interesting stuff... and hopefully understand all the little things that puzzle me every time I look at some schematic...

At any rate at the end it all checks out : the "OFF" time of the switch, appended to the "ON" time (duration between too successive falling edges of the INH pin) as we can see, all adds up to the same 100us we see at the DAC output, so all is well, of couuuuurse, how else could it be...

[alm]

1) The DAC appears to be 12 bits (12 bit wide data bus at least, according to the schematic), but looks like the CPU only uses 8 bits : the bus driving the DAC is only 8 bit wide : the upper 4 bits are repeats of the lower 4 bits. Well maybe the CPU is writing to the DAC in two steps, a byte first, then the remaining 4 bits. Haven't pulled the DAC's datasheet/dug any further (it's an AD 667 ) to see if it's a possibility.
However, the CPU is a 68020 IIRC, so full 32 bits data bus, so plenty capable enough to write the 12 bit word in one single step, why break it down into two accesses ?  Less data lines on the Acq board maybe meant easier routing and /or less digital noise to deal with, especially since that DAC is in the middle of the sensitive analog area of the board, so it must keep it quiet so to speak, I guess   As always, any knowledgeable input is most welcome ! 

From the datasheet:

Microprocessor compatiblity is achieved by the on-chip double-buffer latch. The design of the input latch allows direct interface to 4-, 8-, 12-, or 16-bit buses.

My guess is that the performance gain from going to 12-bit was irrelevant, and eight signals are easier to route.

2) The DAC outputs a symmetrical 10V signal, but I don't see any negative supply voltage going to it ?? I only see the positive 10V reference voltage, which I measured.  There is a capacitor connected to it though, so maybe, just maybe but I find it very unlikely, it uses a charge pump MAX232 style, to produce its negative 10V by himself, locally ? Silly I know, forget I said that ! LOL

According to the same datasheet, it should be powered by a symmetric +/- 12V or 15V power supply. You should measure a positive voltage between pin 8 and pin 16, and a negative voltage between pin 10 and pin 16.

[Vince]

According to the same datasheet, it should be powered by a symmetric +/- 12V or 15V power supply. You should measure a positive voltage between pin 8 and pin 16, and a negative voltage between pin 10 and pin 16.

Stupid me (again) !  As usual the power pins are not represented, of course... but I guess my brain thought that a special case might be made for a "hybrid" part like a DAC is, and that if the Vref_in input was represented then why not the power supplies.

But.... just had another look at the schematic and do you see something interesting ? Yes.... at the bottom left corner they put a table summarizing, for each chip present on that sheet, what voltage goes to what pin....  one just needs to read, indeed as makes sense, it's supplied with the +/- 15V , on pin 8 and 10 as you said.  Depends on the vintage of the scope it seems. For this TDS they give the power supply pin in a little table on eah schematic page, but on my Tek 2232 instead, they gather every power supply pins in the "Power Distribution" sheet.

I guess I should stop working on gear so late into the night, it just keeps biting me but somehow I just can't help : as long as I can keep my eyes open, and as long as I don't run out of ideas on what to do next... I just won't stop working on the thing. Then I see the sun rise and ohhh... might be time to go to bed !   

But that's just because I am on vacation... one more week to go then I will have to be more reasonable and not work so late into the night on these things. The error rate should then hopefully drop a bit ! 

[andy2000]

Your posts have prompted me to finally finish my own 544A that I started to recap a few months ago. 

On powering it up for the first time after the recap it has errors at 0x7300000 and 0x7320000.  It's also reporting "Dac Range Test.** DAC system failure".  Based on your experience, it looks like those memory addresses aren't part of the acquisition memory.  They might be related to addressing U900.  I'll start my trouble shooting in that area and see what I find. 

At the moment, it has no trace on any channel.  I think the lack of a trace is caused by a trigger issue because the armed LED is on solid regardless of the trigger mode. 

A complete memory map for these scopes would be useful.  Did you happen to make a note of the addresses for each channel when you were disabling memory?

[Vince]

Your posts have prompted me to finally finish my own 544A that I started to recap a few months ago. 

Hell, glad all the crap I write actually is of use to someone, I am pleased ! 
Even more so considering that ultimately, YOU were the one that led me to getting this scope fixed ! I mean, trying to use your technique of forcing control lines to purposefully trigger errors to try to get more clues.... was what led me to looking at the UNDER side of the board, and ultimately finding the corroded joints that were the root cause of the problem !  So thanks 

On powering it up for the first time after the recap it has errors at 0x7300000 and 0x7320000.

Oh, interesting indeed, those two particular addresses again !

It's also reporting "Dac Range Test.** DAC system failure".  Based on your experience, it looks like those memory addresses aren't part of the acquisition memory.  They might be related to addressing U900.  I'll start my trouble shooting in that area and see what I find. 

Yep sounds like the plan !

At the moment, it has no trace on any channel.  I think the lack of a trace is caused by a trigger issue because the armed LED is on solid regardless of the trigger mode.   

Sounds quite a reasonable assumption to say the least, go for it !

I mean, anyway, the analog part of the board is not that huge. Do'nt waste time lie I did, trying to trouble-shoot it from the top side, probing arouind, trying to elaborate convoluted theores.... when it all it was corrosion again !
So just go tstraith at it : removed the ACQ board from the chassis, so you can inspect both the top AND underside of it. Look at the analog /right-most third of the board area, for any dull-looking joints, any that don't shine as much as there surrounding borthers, then go straight at any such joints with a microscope if you have one, or any other means of magnifying the view. As you saw on my pictures, a sa get go, the macro mode from my cheap compact camera was good enough to clearly see the actual, sorry state of these joints !

But really I don't see the point of wasting time doing any-troubleshooting until this thorough inspection of all solder joints, is performed. Otherwise you will end up like me, chasing red herrings, one after another, for months and months probably... do yourself a favor and skip these painful steps, go straight at the joints, show them no mercy ! ;-)

A complete memory map for these scopes would be useful.  Did you happen to make a note of the addresses for each channel when you were disabling memory?

No, as I explained in my post the errors gave me no obvious clue about this, sadly !  The very first channel/RAM bank that I disabled via this "CSA" signal, led to a page and half of errors, which I can take pictures of, if you want, but I couldn't find anything obvious in there, was full of very diverse things...
And then for all further disabling/enabling channel combination I tried, somehow none of them led to ANY errors, other than the original two 730/732 ones of course, which would show over and over again, every time.

BTW, I now have an awful lot of errors in the log, and I notice the scrolling on the screen is painfully SLOW/unresponsive... I wonder why that is ? I mean if it were a 100KHz 4 bit CPU processing the strings, and pulling them out of a dog slow I2C EEPROM... maybe I could understand if it were a bit slow... but here we have a hell of a CPU, a 68K, pulling the strings from the NVRAM which is a parallel / fast static RAM, so should be lightening quick at retrieving and displaying these ASCII strings ! I don't understand....  This scope is good at displaying graphics, but looks like handling ASCII strings is really not its thing...

Now that the scope is fixed, I hope GPIB can delete the entire log from the NVRAM, so that I start from a clean sheet of paper, and that if the scope fails again in the future, the new error messages will clearly stand out and not force me to scroll through 4 pages of old errors every time ! 
Yes, this must be doable, I guess...

[andy2000]

This should be able to clear the error log via GPIB.  Let me know if it doesn't because I know I have a utility somewhere for this.

[Vince]

Thanks ! 

Will try it out the minute I receive my GPIB cable from the UK, hopefully this week, only the channel to cross, shouldn't take long !

[Vince]

Just a quick update on GPIB, as I just received my (used/old) cable yesterday, so started to fiddle with things. Didn't go very far because I ran into a couple problems... but still, I got the ball rolling so I will just keep pulling on the string now...

First problem was under MS-DOS. Got it working just fine when I left the computer a few days ago.... but neither of the two Tek S/W (CAl/FAs or err clear) would work : FAS still loads fine and does not complain about a missing scope... at first, but the S/W hangs/freezes, and if you wait long enough, a minute or so, it will become responsive again, only to tell you that "Sorry, can't find any scope connected to the GPIB bus ! ". Oh no....
Then the Err clear S/W, it loads , only to print a couple lines of text just to identify itself, then freezes solid, needs  a hard reboot.
So I ran to the Diag S/W, what do you know, what was working just fine last time... no longer works ! It complains that the IRQ test failed. Tried all the usual stuff, no luck. Only way I found to make the diad S/W happy was to disable IRQ operation altogether !  Still, the Tek S/W would not budge, so the problem must be somewhere else... so I reactivated interrupts so as to get back a normal setup.

So, frustrated I was... but not that much because actually, looking at the help files (stored as plain text, easy to look at...) there are numerous cool Cal routines, but nothing in terms of uploading or backing up the Firmware and/or NVRAM contents, nor write to memory locations, nor clear error codes... so not that useful outside of a pure Cal procedure... which then would required specific gear, also connected to GPIB, which I don't have.

So, that was it for the DOS side of things. Then moved on to Windows 95. Better luck there : GPIB working just fine. I connected all of my GPIB instruments, 4 of them, very diverse : Tek TDS 544A, my old Tek 2232, a weird WaveTek Arb Gen that won't go faster than 1kHz, and a Metrix GX5000 (50MHz Pulse generator). I connected them one by one, then scanned the bus usuing the NI S/W. Worked a treat,  the sofwtare has no problem scannign the bus, takes a split second, and it could find  all the instruments regardless of their address, just fine.  They respond instantly and return an ASCII string to identify themselves... except for the 2232 which is not well mannered and return nothing but a single garbage Character. Maybe it's "normal" (ie Tek didn't give shit back then), or the FW of the scope is corrupted somehow. Might investigate that.... I came across the 2232 FW on some website recently, might have a look at it with an Hew file to see if it contains a different ID string.

Sadly I could not do much more than this, because I don't have the GPIB litterature pertaining to the TDS 544A... so I don't know what command are available etc. 

However the regular user manual for my WaveTek ArbGen DOES include the GPIB details, so I could go a little farther. Not THAT much farther, because I still don't know how to use GPIB at large, but still : NI provide a little "terminal" window where you can type ASCII commands, and it provides a little window to display whatever the instruments returns. All the commands are still very mysterious to me at this point, but the manual sounded simple enough about one of them : "If you type any text inside quotes or double quotes, it will display it on the instruments front panel". So, tried that, and what do you know, it works ! Yeah, I managed to talk to the instrument and got it to obey ! How cool is that.... I like this thing already  !   

I gather that there is no simple way to write "scripts" : if you want to do more than a couple simple commands in the "terminal" window, then you have no easy and simple way/straightforward way to write more complex and/or longer sequences of commands. Instead, it looks like you have to actually right a full blown/regular program, compile it and run it ! Sounds overkill just to write a few byte a loop for a few iterations to gather some measurements or whatever... was hoping that the NI S/W was there precisely to assist you in setting up test sequences in a more user friendly manner ?! I mean, if all it does is scan the bus to list the devices... then it's not worth the 50MB it weighs ! And that's 50MB on the install disk.... god know how much disk space it actually uses once uncompressed.
The NI software provides.

Anyway, still a bit rough around the edges, but I am well motivated, I will get there...

So the plan now :

- Keep digging about this NI sofwtawere, it must do more than scannign the bus... need to find out what it can be used for exactly. Maybe I can install "LabView" and I can find a "Virtual instrument", already made by some good soul (or provided by Tek or NI back then, who knows) about the 544A, or at least 540 or 520... something to play with...

- Dig further about writing programs : under DOS, they provide a few sample programs for BASIC and (Turbo) C. Basic I don't know, C much better, so will go for C. Under Windows, in the "terminal Window I clicked some button which displayed a sample program, written in C. It gives the basic blocks one needs in every GPIB program: header file/ API to load, setting up the bus/opening the device, how to adress a device, then how to close the device cleanly, and some basic error handling routines. Will look into that. So looks like if one wants to do ANYthing with GPIB... one must first get/install a C compiler !  So I guess I need to find one, that runs under Windows 95 if possible, but not a necessity I guess... I just need a compiler, not a full blown/fancy IDE.

- Searched for a copy of the "Programmer Manual" for the TDS 500 series. Surprisingly they are actually easy to find, quite a few of them for sale on Ebay ! Nice original binder versions, some even come with the original floppy diskette ! "Obviously" most/all are in the US so it ends up quite expensive once you add the cost of shipping to Europe, as per usual. Might still treat my self with one, for X-Mas....   In the meantime, Google found me a PDF version of it ! Downloaded that. nearly 400 pages of GPIB Goodness !  I should be covered ! LOL  Mind you, maybe not all of it pertains to the 544A, because the documents apparently treats a whole slew of scope models !!!  The entire 'A' series/generation of scope ! 400A, 500A, 600A and 700A !  Well I guess 99% of the commands are similar to any scope in the world after all... setting a vertical gain or time base setting has no good reason for being performed differently from one scope to another.... no reason not to make it consistent across all Tek scope old and new. Hell maybe it's somewhat standardized across different grands/makes of scopes ! That would be cool. Maybe there is some norm about this...

- Try to figure out what's wrong under MS-DOS, drives me nuts....
I do have another PC2 controller card ready, if need be... just no a genuine NI one, though. But ought to be a drop in replacement, should be transparent to any software trying to make use of it.  It's just a PC2 controller, S/W doesn't need to know more than this...


BUT... first... before I can do any further experiments, I must fix my cable ! LOL  Grrr.... already broken : when I tried to connect it to the 2232, didn't work because on this scope the GPIB connector is on the side of the cabinet, not at the back, meaning the connector is recessed, not protruding like it normally is. The connector of my cable is a tad too large, end up clashing with the edge of the metal work, can't engage fully.  So, I removed the connector shells, since they are just held by screws. Worked... but then when I put the shells back on, cable started working intermittently ! Opened it right back up... yep, sure enough I goofed it up, looks like I managed to pinch two of the wires while reassembling the two shells.  Will try to fix that, but if I can't (not much play in the wires to work on them...), then I would have to wait for my other cable, brand new this one, to arrive from china. Might take up to 3 weeks normally.

In the meantime I will resume work on fixing my TDS 310. Thing is totally unresponsive to any input from the front panel... even though said front panel seems to be working just fine whatever I probe on it !  Good thing is : now that I have worked on the 544A, this TDS 310 now suddenly looks a whole lot less "impressive" than it used to !  So it's time to work some more on it I think... been 4 years since I bought it ! 

That's all folks ! 

[alm]

The 2232 likely pre-dates the SCPI (IEEE 488.2) standard that defines the *idn? command to identify itself. So not poorly behaved, just too old for a particular standard. SCPI was introduced in the late eighties, while GPIB/HPIB was introduced in the late sixties, so there are a large number of instruments with GPIB but without SCPI. You recognize SCPI by its CONF:FOO:BAR? syntax which is mostly generic across instruments of a particular type (e.g. scopes). Older instruments all used different commands that were often closely tied to the front panel layout. You needed to read their (programming) manuals to learn which.

No, the NI software did not ship with any scripting language. They wanted you to buy LabView or LabWindows/CVI (if they existed back then). You could look at EzGpib if it supports ancient Windows versions. It is a Pascal-like scripting language. If you have installed NI-VISA (or even just the older and more cryptic gpib32.dll), you should be able to interface to it from C. Maybe try digging up an old version of MS Visual C?

An alternative scripting language might be Python with PyVISA (requires NI-VISA). Again no idea about support for ancient Windows versions.

[andy2000]

I did some more work on my TDS544A.  I found one open trace, but repairing it made no difference.

Next, I probed around to verify basics like clocks and power.  I found that U501 (acquisition clock buffer for channels 1 and 2, part number 234-0718-40) had no output.  It's twin for channels 3 and 4 (U502) did have an output.  After verifying the inputs to U501, I removed both U501 and U502, then installed U502 in place of U501.  U501 now has a good output, so I know the IC was bad.  With a good U501 (and no U502) it cleared the DAC system failure error, but it still has no trace, no trigger, and those two memory errors.

The other problems could be related to the missing clocks, or may be a different problem.  Either way, more troubleshooting is wasted time without a replacement 234-0718-40.

[Vince]

Alm, thanks for shedding some light.

I do have this "VISA" thing installed, that's the 50MB package I downloaded from NI's website. It also installed with it, this "MAX" software you see in my screen captures. MAX stands for "Measurement and Automation Explorer".  "Automation"... kinda implies it can do a little bit more than just scanning the bus, so I will dig into it a little, though not holding much hope obviously...

Labview, well maybe NI was kind enough to let go on their old Win95 variant, maybe they offer it for download nowadays, will check.  If not, will see if it can be found it "elsewhere".... if nowhere to be found, I think I heard there are similar products, cheaper, and even maybe a free and open-source alternative. So will look into all that.

I did play a bit with Labview nearly 20 years ago I remember. In 1999 I was doing my industrial placement as a student in some small company in the UK, "Webtec Instruments", specialized in the hydraulic industry, designing and manufacturing valves and manifolds, as well as some field/portable test equipment for maintenance/trouble-shooting to go with it . Boss wanted me to start the initial prototyping work on what would later become this thing :

https://www.webtec.com/products/ITT4LB16

Basically measures flow, pressure and temperature, computes power from that, and displays it on a 4x20 LCD screen. The finished product they sell now is less ambitious than what I was working on at the time, though. This one is a stand alone unit and records data locally, but what I was working on was to daisy chain several of these guys using a serial bus, and retrieve data over the bus to some hypothetical terminal/master unit that was yet to be drafted...
So I had to write ("draw"...) a little driver/virtual instrument for this on Labview. Driver would allow for up to 6 instruments. I think I have a picture of this somewhere ! Yeah, digital cameras were not quite widespread and cheap back then...

Anyway, getting my hands back on to Labview 20 years later, brings a little tear to the eye, trip down memory lane ! 

As for language I will stick with C, the only thing I know. Plus it's old enough to be used also under MS-DOS, NI provided bindings for C for his DOS driver,  should I wish/need to, and C will probably still be around in 20 years time... I bet.

I do have a book on GPIB which I bought 20 years ago while at school... could make a lot sense of it; not having any GPIB stuff to practice with... 20 years later I do it appears ! LOL  So reading it a second time, but this time with a much more hands-on/real world perspective ! 
Have only read the first few pages of it, covering low level stuff to start with, what every individual line of the bus is for and how it all works together... not quite necessary for practical, but I want a solid ground on which to build ;-)

Anyway, I am all excited about this GPIB thing, and all the things you can do with it, and the fact that this bus was implemented on even very old instruments, so even ancient '70's instruments can be connected to it, along with your '80's instruments, '90's gear as well, and I see that even brand new mega expensive STILL come (at least as an option) with GPIB, somehow !!! Obviously I understand it's for backward compatibility, but still, the point is that GPIB is worth investing your time  in it, as it's really useful to connect a extremely wide variety of instruments, both very old and brand new, all on the same bus ! I find this fascinating, in a world where all things come and go so quickly now.

[Vince]

Either way, more troubleshooting is wasted time without a replacement 234-0718-40.

Ah, getting there ! 

Is this ECL chip custom ??  Worst case, I guess you could always salvage that chip from a cheap (pun intended) Acq donor board from Ebay ??

Your Avatar doesn't not state what country you live in, but if you are in the US like most on this forum, then buying from Ebay is very cheap since you don't have to pay for silly shipping fees and import related taxes like other people have.

[andy2000]

Either way, more troubleshooting is wasted time without a replacement 234-0718-40.

Ah, getting there ! 

Is this ECL chip custom ??  Worst case, I guess you could always salvage that chip from a cheap (pun intended) Acq donor board from Ebay ??

Your Avatar doesn't not state what country you live in, but if you are in the US like most on this forum, then buying from Ebay is very cheap since you don't have to pay for silly shipping fees and import related taxes like other people have.

The chip is branded Tektronix and only has their part number on it, but I haven't done any research yet to see if it might be an off the shelf part. 

I am in the US, so I'm sure I'll be able to find a donor sooner or later.    It's a low priority "fun" project, so I'm in no rush.  I already have several better scopes. 

There's nothing cheap on ebay at the moment.  If anyone has a scrap acquisition board, please contact me.  I think the TDS540 and 520 should have the same part.

[Vince]

It's a low priority "fun" project, so I'm in no rush.  I already have several better scopes. 

Better scopes ?! Lucky you, I envy you !   
This TDS 544A is my beast, spent 500 Euros for it (that's roughly at least as many US dollars), which was a real bargain considering it was recapped and the seller was willing to prove that it actually worked. That's extremely rare.

My dream scope would still be a TDS, but the later 'D' series, so as not to suffer from leaky caps, and have better analog BW and sampling rate. Would love a TDS 784D or 794D, with a memory option, but 700D models are mega rare over here, and when they show up it's usually anywhere between 1500 to 4000 bucks, with just a pic of the unit powered off, laying outside on a wet ground, text saying just "very good condition", take it or leave it ! LOL
Yeah right.... 


I think once I will be in a market for one of those, I will buy from Ebay US... shipping will be silly expensive but it will still end up vastly cheaper than buying one locally, and I would not have to wait 10 years to find one, and I would be able probably to find a cheap one for repair,, instead of paying 1500/4000 for a unit that's described as "in great condition !", like it were some piece of furniture or something, but which in reality is most likely faulty !!!


Anyway, played some more with GPIB, my dodgy GPIB cable was kind enough to behave for a couple hours, so could exploit all the good stuff I found in the "Programmer Manual" I just downloaded. several hundred pages thick, and all pertaining to my 544A at that (all commands are common to all the 'A' series it appears, great), but none the less an easy/quick read : just a dozen pages at the start to explain how the syntax works, then just a long list/catalog detailing every available command, nicely sorted by type. So I could quickly find the commands of particular interest, and played with them all.

Of particular interest : the scope has an "Application" menu, a dedicated button on the front panel. On my scope this menu is completely empty. Kinda annoyed me at first, I thought the Firmware and/or NVRAM might be screwed in some way, and I might be missing some cool features, how frustrating !
But it turns out that no, I am not missing missing anything, it's normal for this menu to be empty. This menu is meant to work with GPIB only. It's only purpose in life is to offer a way for the operator/user to interact with the GPIB setup : you can create custom labels/menu entries in this menu, then the operator presses the soft buttons to select them, the scope then tells the GPIB controller/computer which button was pressed, and the computer can then run a GPIB program/ to make the scope perform such or such test procedure.  So I played with that, see below 

You can also display a message window with you own text in it, and you can customize the width/height/position of the window as you desire, can even be full screen if you like.

Now the bad news : this Programmer  Manual as thick/comprehensive as it is, does NOT tell you what's the command to clear that bloody err log !  Grrr....  quite disappointed, I am.  You can run diag procedures, and retrieve the results, just like you can do from the front panel, but you can not clear the error log, nor even simply read it actually.

So, I am kinda annoyed that I can't get working this little dedicated DOS utility you gave me Andy ! Still, it's only 10KB so I ha d a go at it. Looked at tit in a hex file editor, thinking all it does is probably sending a single command over GPIB, and since they are all plain/legible ASCII text, I should logically be able to see it in the executable file !  Well... yes and no ! As you can see below, one can see an interesting " sendcmd{ " string ! So the GPIB command must folliow the opening "curly bracket", mustn't it ! Sadly no ! As you can see, all that follow the opening bracket is just a long string ofr random characters, most of which are not even printable ones !  And we can't even see the matching closing bracket !  So... could it be that the text string containing the command name and arguments if any, has been scrambled/encrypted in some way, for security purposes, to avoid simple hacks like what I was trying to do ? Could Tek have been THIS paranoid ?!     Can'"t believe it, there must be some other explanation.... just don't know what it is, yet.

So Andy, you said you might have another software that might be able to clear this bloody error log ? I am all ears !   

Anyway, making progress on GPIB then, this first approach was a success I think ! And I am glad because it might be put to good use real soon : might help me repair my TDS 310 !!!  I mean, it's front panel is become totally unresponsive but the scope is otherwise working. So GPIB would be ideal to let me take full control of the scope despite the lack of front panel ! But.... that's assuming this scope does have GPIB ! That was hardly a given, considering it was a TDS 300 series hence bottom of the TDS range, and to top it all, the TDS 310 I have is, I think, possibly, the lowest spec 300 one can possibly think of !!!  I mean, has only 2 channels, only 50MHz of analog BW and a mere 200MS/s, almost a toy in other words ! LOL  But well, I looked at its butt just in case, and what do you know, it DOES have a GPIB port, YEAH !!!! Even has serial and centronics ports as well.  I am over the moon. Can't wait to resume work on this repair.

[Vince]

Looking at the hex dump of the error log clear S/W..  trying to make sense of this scrambled ASCII string.

I thought maybe it's not encrypted, maybe it's just compressed... maybe somehow this S/W doesn't load straight into RAM "as is", maybe it uncompresses some block of data... but how ridiculous that would be, the executable is only 10KB so it could run on a pocket calculator, no need to compress anything.

Then, I searched for the strings that the program prints on the screen when you load it, like "Tektronix (c) 1993 Error Log Clear program for the TDS Family", something like that.... surely this is hardly sensitive information, so no reason whatsoever to scramble/disguise it... yet.. it IS scrambled ! ARRRRRRGH ! I am lost.

Thought maybe my Hex editor is playing up, though I don't see how it could have gotten this wrong, but what do I know. So I searched for another Hex editor in my package management software. Saw a program by teh name of "Bless", but whatever. Point is... there were some reviews attached to this software, and some people complained that "it lacks EBCDIC support, not all text is ASCII encoded ! "   Ah ? Might be on something there ! Maybe the strings in that executable are stored in some weird format other than ASCII ! So searched for that EBCDIC format. It's an old format that was used in the early days of computing, when main frames were still using punch cards :

https://en.wikipedia.org/wiki/EBCDIC

Found a site that gives conversion tables :

http://www.simotime.com/asc2ebc1.htm

Unfortunately, unless I am using these tables incorrectly, I would say that these strings are not in EBCDIC format either... hmmm... some other encoding then, but what might it be....


TDS310 : plugged it to GPIB, no response whatsoever, the GPIB controller fails to find it when it scans the bus, front panel still unresponsive to user input, but appears to react appropriately to stimuli from the main scope/main board. Also, I notice that the front end is trouble some too : fails to display any signal, all the screen show is a tiny 1mV signal, and on top of that it progressively shift up and up. Starts at teh bottom of the screen and over the course of a few minutes, it ends up off screen at the top. I say that's one very sick puppy ! I think I will open a new thread for him, looking like an interesting repair...

[Vince]

Not sure if the link has been posted yet, but there may also be some helpful software on Hakan H.'s site.

Thanks (again) for this link alm !  SUCCESS !!!

On this page :

http://hakanh.com/dl/

8th link from the top, is listed an error log VIEWER for the TDS scopes, clicked on it anyway, then saw a screen cpature of its user interface and noticed that... oh... what do I see there, am I dreaming or what.... there is also a CLEAR error log button in there ?!
And the software runs, for a change, on Window 95 not MS-DOS, and requires NI' back-end ? Just what I needed !

ANdy, was that the other software you had in mind ?

Installed that software, ran like a dream, pulled the full error log from the scope in an eye blink, 71 errors no less, and it cleared them all in a split second, good boy ! That's some good S/W, and it's home made as well !  Must send the guy an e-mail to thank him for bothering writing such a useful piece of code, and sharing it on his site. That's one good man !   

The error log in the scope is now a beautifully... empty window, success ! Quite strange actually, never seen it empty before ! LOL

So, the scope is fixed, and the error log is clean, the scope starts from a clean sheet... I call this repair done, what do you say ?! 

Thank you to all who helped in one way or another ! 

Now on to my TDS 310 repair... a new thread soon to be created I feel ! 

[andy2000]

I've never tried that Windows error log viewer, but now that you mention it, I have heard of it. 

I'm sure it was a DOS program I used.  I'll have to pull out my old portable DOS computer which I set up for GPIB.  I only used it once for my TDS784D.

Keep an eye out on ebay.  My 784D came from Israel, and was a bit of a project to say the least (bad CRT, missing front panel, broken BNC connectors,...).  Fortunately, the processor and acquisition boards were good, and it even had the hard drive option.  The replacement parts I needed are common to all of the 700 series scopes, so weren't hard to find.  I paid about $500 for it, including shipping (5 years ago).

I like the "digital phosphor" mode of the D series.  It's excellent for viewing chaotic signals such as a TV video signal.

[Vince]

Israel ?! Now you mention it, I do remember coming across  many adds on ebay for cheap "as is" instruments, that all came from a specialized company precisely in Israel. Isreal is a lot closer to me than to you in the US, so the better (for shipping fees...).  Nice to hear from someone who has actually experience of this company, I will be less hesitant to use them then, if they were good to you. I mean the scope was in a sorry state but advertised as such, so they didn't lie on its condition, and they actually shipped the product to you, rather than just taking your money and giving you the middle finger.

That's quite encouraging... I will dream of my future 784D every night now, until I can afford to get one 

[Jwalling]

I did some more work on my TDS544A.  I found one open trace, but repairing it made no difference.

Next, I probed around to verify basics like clocks and power.  I found that U501 (acquisition clock buffer for channels 1 and 2, part number 234-0718-40) had no output.  It's twin for channels 3 and 4 (U502) did have an output.  After verifying the inputs to U501, I removed both U501 and U502, then installed U502 in place of U501.  U501 now has a good output, so I know the IC was bad.  With a good U501 (and no U502) it cleared the DAC system failure error, but it still has no trace, no trigger, and those two memory errors.

The other problems could be related to the missing clocks, or may be a different problem.  Either way, more troubleshooting is wasted time without a replacement 234-0718-40.

I have three TDS540 or A scrap boards that succumbed to leaky caps. These are the ones you need?
Send me a PM. You can have 'em both for the cost of postage if you email me a shipping label from USPS
for a "small flat rate priority mail" box.

[Jwalling]

A close up. looks like the right part.

[Vince]

Yep they are the ones indeed. Andy lucky you... can't wait for you to solder these chips in place and report back on your repair 

[andy2000]

I decided to try connecting the outputs of the good IC to the pads of the missing one.  Much to my surprise, it now has a trace, triggers, and even passes SPC.  As expected, there are some timing errors, but it's encouraging.  It still has the two memory errors, but I now know those are unrelated to the other problems.

[Vince]

Hey clever, why not, it paid it appears !   

Making good progress then, great ! Go change this chip and keep working at it, looking good so far !

[andy2000]

I replaced the bad U501, and now it seems to be working properly!  I'm not sure if it was a coincidence, but it didn't give me the two memory errors when I booted it, or when I manually ran the self test. 

Thanks to all those who helped, and I hope this will help someone in the future. 

[Vince]

SUCCESS then !!!   Great Andy, that's TWO 544A fixed in one thread ! 

Glad to hear that !   

[andy2000]

The CRT is good, but there are some bad spots on the LCD color shutter.  The early CRTs like this one have an optical gel between the CRT and shutter.  Later ones just have an air gap.  I think the gel puts slight pressure on the LCD panels which can cause damage over time. 

If anyone has a weak CRT with a good LCD shutter, I'd be interested in it as a parts donor. 

[Vince]

The CRT is good, but there are some bad spots on the LCD color shutter.

Yeah noticed that on your pics... yours seems quite bad indeed, sadly   
Mine does it as well but it's very slight, not really noticeable unless you know about it and look for it... so I will just leave it like that I think...

The early CRTs like this one have an optical gel between the CRT and shutter.  Later ones just have an air gap.

Good to know ! One more reason for me to favor a later model when I can a TDS 700...

[andy2000]

So, I decided to try removing the optical gel to take the pressure off the color shutter.  It was a messy process, and at first there was only a slight improvement.  After a few weeks of sitting, the bad spot has almost completely disappeared.  First it went from about 12mm in diameter to just a few mm.  After 5 more days, it's now less than 1mm.  I think it will be gone in another week.

The gel is a very sticky viscous substance.  To break the bond with the front of the CRT, I injected some air with a hypodermic needle.  Just be careful to put the needle between the shutter and the CRT, not between the two layers of the shutter.

[Jwalling]

So, I decided to try removing the optical gel to take the pressure off the color shutter.  It was a messy process, and at first there was only a slight improvement.  After a few weeks of sitting, the bad spot has almost completely disappeared.  First it went from about 12mm in diameter to just a few mm.  After 5 more days, it's now less than 1mm.  I think it will be gone in another week.

The gel is a very sticky viscous substance.  To break the bond with the front of the CRT, I injected some air with a hypodermic needle.  Just be careful to put the needle between the shutter and the CRT, not between the two layers of the shutter.

Ugh! Yeah, that's one of the worst things you might have to deal with on these scopes other than the leaking caps. Oddly enough, Goo Gone works well to remove the stuff after getting most of the snot off with a plastic scraper. The hypodermic needle is something I never tried - Excellent and thanks for that!

Only the older TDS scopes had that stuff, newer ones did not. Makes me wonder why they thought they needed it to begin with.

Edit: Oh yeah, you just said that (is there an echo in here?)

[andy2000]

Just one final update.  It took a while, but the purple spot is completely gone.  I reattached it to the CRT with some black silicone, and it now looks perfect.  It was definitely pressure form the gel that caused the purple spot. 

[Vince]

Thanks for the update Andy !  Very nice to hear that this horrible problem can be fixed efficiently.. as well as very cheaply  ! These two things usually don't get along very well do they...

I will leave mine alone for now, as the problem is there but only very slightly, so I am worried I am might do more damage than anything if I attempt the repair... but will not hesitate should the symptoms become really visible and annoying...

Too bad you didn't take a few pics of the process, so I can better understand what is involved exactly. I guess it becomes obvious once you start the job, but I would have like to know before hand what I would be in for...

[andy2000]

I probably should have taken some pictures, but there's a good description of the process here.  Overall it was the same, except that I injected air to break the vacuum bond of the gel.  The gel is very sticky!  I managed to keep more of the original silicone intact which made reattachment easier. 

http://jvgavila.com/tds524a.htm

[Vince]

Ahhhh.... I see now !  Thanks for the great link, very helpful indeed ! 

Looks doable no doubt ! 

[charlyd]

dont forget the leaky caps away....or better ALWAYS.. recap the complete 500 series..