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...
Home
Help
Search
Login
Register
