TDS540 repair; drifting vertical position at start-up


visitslovenija
 

Hi guys,
Another question for you on my TDS540 repair mission;

When switched on from cold the traces are all off the bottom of the screen, but the trace indicator icon is in the right place. Over the next few minutes, no more than about 5min, the traces slowly rise up and eventually settle in the right place. With a test signal applied, the triggering starts once the traces reach the trigger level.

So I’m assuming I have yet another open circuit track to find.

Since this affects all traces, I’m thinking it is nothing to do with the attenuator board. But what area on the acquisition board should I be looking at? What signal is it that defines the trace vertical position?

Thanks a lot,
Ralph


Ozan
 

On Sun, May 8, 2022 at 11:30 AM, visitslovenija wrote:


Hi guys,
Another question for you on my TDS540 repair mission;

When switched on from cold the traces are all off the bottom of the screen,
but the trace indicator icon is in the right place. Over the next few minutes,
no more than about 5min, the traces slowly rise up and eventually settle in
the right place. With a test signal applied, the triggering starts once the
traces reach the trigger level.

So I’m assuming I have yet another open circuit track to find.

Since this affects all traces, I’m thinking it is nothing to do with the
attenuator board. But what area on the acquisition board should I be looking
at? What signal is it that defines the trace vertical position?
First thing to check is if any of the supplies has the same pattern. If supplies look good, one area that affects all the positions (and other control voltages) is sheets <18> and <19> "DAC Control". On two TDS520s with leaking caps I repaired there was a lot of residue and broken traces around U900.

For debug: TP901 is the reference of the DAC and should go to +10V very quickly. TP912 voltage is muxed to all control voltages by CD4051 muxes in sheet <18>. For example if you look at sheet <1>, "-Vin1" voltage is the offset voltage of the channel coming from those muxes. Voltages at TP1402/1403/1404 and output of U1401C shouldn't drift over time. Similarly in sheet <5> ADC reference voltages TP855 and TP858 shouldn't drift over time. If any of these voltages has the same drift you are observing you can narrow down the debug area.

Ozan


visitslovenija
 

Brilliant, thanks Ozan. I'll see what I can find out from that.

Ralph


visitslovenija
 

Hi Ozan,

Have narrowed it down to the level amps on Sheets 1-4. So yes, the levels on TP1402 etc are changing along with the trace drift.

From a cold switch-on, the level on pin 3 of U943, as an example, (the OFFSET1 signal) starts off high and slowly drops down to zero. The supplies are stable, so it seems the output from the multiplexer on Sheet 18 (U932) is causing the problem, which doesn't make a lot of sense really.

I know you said to check TP912, but this is a multiplexed signal so not easy to correlate with the level used to set OFFSET1.

Any ideas?


Ozan
 

On Tue, May 10, 2022 at 11:36 AM, visitslovenija wrote:


Hi Ozan,

Have narrowed it down to the level amps on Sheets 1-4. So yes, the levels on
TP1402 etc are changing along with the trace drift.

From a cold switch-on, the level on pin 3 of U943, as an example, (the OFFSET1
signal) starts off high and slowly drops down to zero. The supplies are
stable, so it seems the output from the multiplexer on Sheet 18 (U932) is
causing the problem, which doesn't make a lot of sense really.

I know you said to check TP912, but this is a multiplexed signal so not easy
to correlate with the level used to set OFFSET1.
I would start checking TP901 to make sure it goes to +10V quickly and stays there.
TP912 should be moving around for setting each voltage but shouldn't be too far off from +/- 1.71V across all the steps. If it is following the same fault pattern:
1) check pin 3 of the TL072 (can't read the refdes, probably U903A) which should be +/- 1.71V to rule out a bad TL072.
2) Check TP911 for +/-1.72*(1+11k/2.21k)

Given all the channels move same way I expect the issue to be around TL072. However, if TP912 is good next step is to pick one of the muxes e.g. U932 and look at its input (pin 3) and look at one of the drifting signals (e.g .pin 13) and see if the drift is happening at the input or output. If address inputs are somehow misbehaving the muxes may not be passing the signal properly.

Is there a chance this scope had cap leakage issue? If you look at DAC area do you see a black residue on the pins of U900 and surrounding components?
Ozan


visitslovenija
 

Hi Ozan,
The 10v on TP901 is solid. Don't see any problems there.

The output of U903, the OpAmp, is swinging +/-1.7v and TP911 on U900 is +/-10v, so that also looks to be ok.

Since this is turning out to be an involved problem, some more background information on the 'scope might be helpful:
It was an eBay buy, sold as faulty.

When first checked, the triggering was not working, though signals were seen from the inputs. It showed a lot of evidence of cap leakage, so I have re-capped the processor, the acquisition and the front panel boards and given everything a good clean. So far I have found 3 open circuit tracks (two around the U1601, U1603 OpAmp collection and one on the front panel board).
The triggering is now working. Another major issue that I have still to tackle, but may be related; if I open up the timebase to the point where interpolation is needed, then the trace starts to break up. So there is a memory problem I guess.

On start-up it fails;
Acqu/Proc Interface
Acquisition
Atten/Acqu Interface

Perhaps significant to this particular issue, if I do a restart after it has warmed up and these drifting signals have stopped, the Atten/Acqu Interface fail goes away. So presumably the problem is here somewhere.

I don't have any kit here at the moment to connect via the GPIB interface, so can't get a detailed look at the error log. (can it be done via the RS232 interface?)

Ralph


Ozan
 

Hi Ralph,
My comments are below.

On Wed, May 11, 2022 at 03:06 AM, visitslovenija wrote:

……
Another major issue that I have still to
tackle, but may be related; if I open up the timebase to the point where
interpolation is needed, then the trace starts to break up. So there is a
memory problem I guess.
This may be another open trace or control voltage issue. Interpolator makes heavy use of calibration voltages.


On start-up it fails;
Acqu/Proc Interface
Acquisition
Atten/Acqu Interface
I had similar errors on TDS520’s that cleared up once reference voltages cleaned up. Some of the system timing is calibrated by using DAC voltages, if calibration voltages are off acquisition system timing flags errors.


Perhaps significant to this particular issue, if I do a restart after it has
warmed up and these drifting signals have stopped, the Atten/Acqu Interface
fail goes away. So presumably the problem is here somewhere.
This is good news, says the scope is mostly fine and once you fix the voltages many of these errors will go away.


I don't have any kit here at the moment to connect via the GPIB interface, so
can't get a detailed look at the error log. (can it be done via the RS232
interface?)
I believe you need to tap into console RS232 with a special card with UART, connector J40 in Sheet <2> of A11. However, it is not that useful in this case given that you already know control voltages are off.

Following is just a suggestion, not something I had to do on my unit:
We know TP1402 is drifting. Is it still +/- 1.71 or goes off this range?
TP1402 comes from DCBAL1 output of <18>, pin 15 of U932.

Assuming PC[7:0] is scanned incrementing by one in a binary fashion:
If you trigger your scope on pin 6 (INH) in NORM (not AUTO) mode, put one channel on pin 3, one channel on pin 15, and one on pin 11 you should see a repeating pattern. Timebase should be set long enough to show 4 pulses of pin 11 and some more. Each H and L of pin 11 is one time slot (LSB of the address counter), DCBAL1 is 3rd time slot. Whenever 3rd slot is selected DCBAL1 should match pin 3.

Depending on whether pin 3 drifts, or DCBAL1 drifts you can further narrow down the issue.

Ozan


visitslovenija
 

Hi Ozan,

Thanks again for your input.

Trying to get a sensible picture of the various signals has been challenging: what I need to do it is the scope I'm working on :) ......

However, while working on this, I realised that some of these control and reference lines, as well as drifting, have a sawtooth component on them. I've added a photo to the TDS540 Front Panel album I have which shows this. This is on the input to U1101 <4>. It struck me that this is a typical RC decay kind of waveform which just should not be there. One explanation would be that the inputs of the TL074 were not a high impedence, which they should be of course with JFET inputs. So I was wondering if the electrolyte corrosion had made a mess of these inputs.

Since my main focus so far has been on Channel 1, I removed its 074, U1401 (not easy as they seem to be glued down) and found heavy corrosion on the pads for pins 2 &3 - in fact, they just disintegrated when removing the IC. It's a wonder it worked at all.

I cleaned everything up, fitted a new 074 and made new connections for the bad pads and the drift problem on this channel has gone. Nice. I'm guessing that there was some leakage from the supply lines that caused this drift offset.

So looks like my next task is to remove and replace the other 074's that are anywhere near an electrolytic capacitor. In fact it is probably a good idea to remove, clean, and replace all IC's that sit in the 'spill zone' from an electrolytic.

I will need to order some spare parts, so it will be a while before I can report back on this again. But, heck, it is nice to feel like I've made some progress! And in no small part due to your help, so thanks again.

Regards,
Ralph


Ozan
 

Hi Ralph,

On Fri, May 13, 2022 at 01:29 PM, visitslovenija wrote:
...
However, while working on this, I realised that some of these control and
reference lines, as well as drifting, have a sawtooth component on them. I've
added a photo to the TDS540 Front Panel album I have which shows this. This is
on the input to U1101 <4>. It struck me that this is a typical RC decay kind
of waveform which just should not be there. One explanation would be that the
inputs of the TL074 were not a high impedence, which they should be of course
with JFET inputs. So I was wondering if the electrolyte corrosion had made a
mess of these inputs.
This is most likely because of a leakage path from U1101 input to negative supply.

Did you wash the board after unsoldering bad caps? Everyone has their own recipe but 50% vinegar-water solution sprayed on the board, then cleaning with dishwashing soap and toothbrush, rinsing in the sink with plenty of running water, final application of distilled water, and blow drying worked well for me.

...
I cleaned everything up, fitted a new 074 and made new connections for the bad
pads and the drift problem on this channel has gone. Nice. I'm guessing that
there was some leakage from the supply lines that caused this drift offset.
I agree with your conclusion.

So looks like my next task is to remove and replace the other 074's that are
anywhere near an electrolytic capacitor. In fact it is probably a good idea to
remove, clean, and replace all IC's that sit in the 'spill zone' from an
electrolytic.
I added an album:
https://groups.io/g/TekScopes/album?id=275055
to show some of the damages I have seen on TDS520A for inspiration.

Ozan


visitslovenija
 

Hi Ozan,

I have read in various threads about these ‘scopes that washing the pcb’s thoroughly was recommended, but mixing water with a complex board just made me queasy! So I’d stuck to using IPA and a foam cleaner I have used successfully before. However, after reading your post I decided to give it a try. So have given both main boards the vinegar, dishwasher treatment.

So far though, I can’t see it has had any effect. Having seen the corrosion under two of the 074’s so far, I’m not really surprised.

Mind you, I have managed to short two output pins on one of the multiplexers (now busted), so there is a chunk of circuit not working at the moment (idiot) and will have to wait until the spare parts arrive before I can be sure how things now look. Sigh.

Ralph


Ozan
 

On Sun, May 15, 2022 at 07:46 AM, visitslovenija wrote:
I have read in various threads about these ‘scopes that washing the pcb’s
thoroughly was recommended, but mixing water with a complex board just made me
queasy! So I’d stuck to using IPA and a foam cleaner I have used
successfully before. However, after reading your post I decided to give it a
There is some chemistry reasons (I don't remember the details) for some deposits not dissolving in alcohol. I also found these boards to have so much electrolyte residue it was difficult to completely rinse it off without running water. When I tested the residue with litmus paper it was very basic so the reason for vinegar to neutralize somewhat. After running tap water I use distilled water before drying off with air (I use a shop vac in reverse).

try. So have given both main boards the vinegar, dishwasher treatment.

So far though, I can’t see it has had any effect. Having seen the corrosion
under two of the 074’s so far, I’m not really surprised.
At least it should prevent further corrosion.


Mind you, I have managed to short two output pins on one of the multiplexers
(now busted), so there is a chunk of circuit not working at the moment (idiot)
and will have to wait until the spare parts arrive before I can be sure how
things now look. Sigh.
As long as fixes are more than damage it is still progress.

Ozan


visitslovenija
 

Hi Ozan,
After a bit of a gap, I managed to spend some time again with the TDS540. After the pin shorting incident, I had to replace U1101 OpAmp and U934 Demux to restore this part of the circuit to proper operation.

I now have a situation where Channels 1 and 2 are more or less working ok, but both Channel 3 and 4 have some kind of spiking interference that I have not been able to track down. If I connect a scope probe to the test signal on the front panel, this spiking gets superimposed on it. So the signal path is working.
I have added a photo of it to the TDS540 Front Panel album I was using before.

From my reading of the circuit, Channels 1 and 4 and Channels 2 and 3 share the same ADC, and since 1 and 2 are ok, I'm assuming the ADCs are not involved.

So far I have not found a signal on the board to explain it. Any ideas?

It is frustrating that there are no test points for the input and output of the U1100 first amp. Or the input to the ADC and with the pins so close together, proding around seems like a bad idea!

Ralph


Jared Cabot
 

I just repaired a TDS794D a couple days ago with spikes superimposed on the displayed waveform. It turned out to be a few bad RAM chips, apparently it's not overly uncommon for some of the RAM to go bad occasionally.

You can find my thread in this group.


visitslovenija
 

Hi - thanks for that.

It does indeed look very similar. Will have to see if I can narrow it down to which chips are causing the error. Don't have any kit to connect to the GPIB, but can you download the error log from the RS232? That I can probably hook something up to.....


Jared Cabot
 

I just checked my TDS784D and in the scope menu it looks like the serial port is only for hardcopy output or a foot-switch of some description.
You might have to install the Wavestar software to see if you can talk to the scope.

You can see the error log from the menu though, but clearing it needs the command 'errlog clear' to be sent via GPIB (Unless anyone knows of a secret button combination to do it from the front panel?)

What errors do you have in the error log? Anything that looks like it could be RAM? Sometimes you get lucky and it'll tell you the chip number on the PCB to look at.


visitslovenija
 

Hi,
Took a photo of the error log and have added it to the TDS540 Front Panel album I have been using.

I'd say yes, memory fault. But no sign of the IC designators. But always address 734008. Any idea which memory bank this mmight be?

Thanks.


Ozan
 

On Fri, Jun 10, 2022 at 02:44 AM, visitslovenija wrote:


Hi,
Took a photo of the error log and have added it to the TDS540 Front Panel
album I have been using.

I'd say yes, memory fault. But no sign of the IC designators. But always
address 734008. Any idea which memory bank this mmight be?

Thanks.
Some of TDS series look similar, there could be clues in this message chain (Jared's repair):
https://groups.io/g/TekScopes/message/193787

Ozan


visitslovenija
 

Time for a quick update on progress.

The big trace excursions I was seeing on Channel 3 and 4 were, based on threads elsewhere, blamed on SRAM chip issues in the acquisition memory. Couldn’t really make any sense of error messages to pin down which IC’s were to blame, so went ahead and replaced chips 1 to 4 of the set of 8 on Channels 3 and 4.

Happily this has got rid of these big waveform errors.

So I now seem to have a scope that is working pretty well at lower frequencies. I can happily play around with signals on all 4 channels down in the kHz region. However, it still flags up 2 accqu errors at start up and the trace waveforms show various problems if I wind up the timebase to faster settings. Up into the MHz area things don’t look so good.

So my next task I think is to look closely at the extended trigger circuitry. Does that make sense?
It could also be that there are still bad SRAM chips and that I need to get the hot air gun out again……

Ralph


Siggi
 

There’s also interleaving to look at, depending on where this starts.
There’s a chip somewhere in the sample clock distribution whose sole
purpose in life is to skew the sample clock to align interleaved samples
IIRC.

Þann sun., 26. jún. 2022 kl. 14:34 skrifaði visitslovenija <
musto102@...>:

Time for a quick update on progress.

The big trace excursions I was seeing on Channel 3 and 4 were, based on
threads elsewhere, blamed on SRAM chip issues in the acquisition memory.
Couldn’t really make any sense of error messages to pin down which IC’s
were to blame, so went ahead and replaced chips 1 to 4 of the set of 8 on
Channels 3 and 4.

Happily this has got rid of these big waveform errors.

So I now seem to have a scope that is working pretty well at lower
frequencies. I can happily play around with signals on all 4 channels down
in the kHz region. However, it still flags up 2 accqu errors at start up
and the trace waveforms show various problems if I wind up the timebase to
faster settings. Up into the MHz area things don’t look so good.

So my next task I think is to look closely at the extended trigger
circuitry. Does that make sense?
It could also be that there are still bad SRAM chips and that I need to
get the hot air gun out again……

Ralph







Jared Cabot
 

On Mon, Jun 27, 2022 at 03:33 AM, visitslovenija wrote:

So I now seem to have a scope that is working pretty well at lower
frequencies. I can happily play around with signals on all 4 channels down in
the kHz region. However, it still flags up 2 accqu errors at start up and the
trace waveforms show various problems if I wind up the timebase to faster
settings. Up into the MHz area things don’t look so good.

It could also be that there are still bad SRAM chips and that I need to get
the hot air gun out again……

Ralph

What are the two errors exactly? I would be looking deeper into the SRAM's as they are a known failure point. (I just repaired a TDS794D with bad SRAM a couple weeks back).