Re: TDS520 problem


alfa beta
 

wow Siggi !
I'm going to check the beast with a varying DC on CH2 Will post the pics in the album

----- Original Message -----
From: Sigurður Ásgeirsson siggi@undo.com [TekScopes]
To: TekScopes@yahoogroups.com
Sent: Friday, November 06, 2015 3:31 PM
Subject: Re: [TekScopes] TDS520 problem



Hey Adri,

check this out:
https://docs.google.com/spreadsheets/d/1e0dgVVgFcP2gGTa8Z8X4Z88gdzFuHal3OJlJbwn8spE/edit#gid=777902241.
This is a simulation of a stuck second-order bit on one of the ADC's two
outputs. Bears a likeness to your images - right?

So, given this, I'm pretty sure now that you have a stuck second-order bit,
the question is where.
The options are:

1. An open on one of the ADC's output channels.
This would manifest as a problem on every other sample, when you're
going at 250MS/s (the max sampling rate for one ADC).
2. A bad RAM chip.
This would manifest as a problem on every eight sample, probably
irrespective the sample rate, but for sure at 250MS/s.
3. A bad MUX.
Let's hope this is not the case, as I don't think these are easy to come
by.
4. A stuck bit somewhere else.
I can't think where there could be a stuck bit manifesting precisely
like this, so let's ignore that possibility :).

Note that varying the input offset and magnitude of the input will hange
the manifestation of the stuck bit, and hopefully you can repro the trouble
with DC.
I forget (or never knew) whether this scope will inject a DC offset to the
input channel when you adjust the trace position, but for sure it'll inject
a DC offset when you adjust the input offset in the vertical menu.

Siggi

On Thu, 5 Nov 2015 at 22:08 Sigurður Ásgeirsson <siggi@undo.com> wrote:

> The other possibility that'd fit the facts so far, is if there's a stuck
> bit on the ADC outputs, due e.g. to a broken trace or such. Did you do any
> repair in the vicinity of U700?
>
> Again, playing with DC inputs will help, as that'll narrow the options. A
> stuck line from the ADC should manifest in every other sample, and at lower
> speeds, it's possible that only half of the output lines are used
> (explaining why this doesn't hit at all settings, all the time on CH2).
>
> So, ET off, both channels on (to force interleaving off), sin(x)/x off,
> dots mode if available, 1M input impedance.
> Input DC on CH2 and vary voltage or offset to full scale positive and
> negative. If this reproduces the issue, take note of whether it affects the
> entire sample record, or a fraction. What's the distance between anomalous
> samples?
> Take note of whether and how the trace follows the input voltage.
>
> On Thu, Nov 5, 2015 at 18:48 Sigurður Ásgeirsson <siggi@undo.com> wrote:
>
>> On Thu, 5 Nov 2015 at 15:11 'adri' tncdrn@gmail.com [TekScopes] <
>> TekScopes@yahoogroups.com> wrote:
>>
>>> So you think it might be a defective memory IC
>>>
>> I don't see anything inconsistent with that hypothesis in your pictures.
>> Looking at the A10 schematic, it looks like there are eight distinct CS
>> lines, and the RAM is written four-byte (64 bit) wide.
>>
>> If you look closely at your captures, I think you'll see that on CH2,
>> every fourth sample is bad, for half of the total capture record.
>> When this hits on CH1, you should see every eight sample is bad, again
>> for a total of half the waveform record.
>>
>> To look at this closer, turn ET off, turn sin(x)/x off, if this scope has
>> a dots mode, turn that on (instead of vectors), and you should be able to
>> count pixels/samples.
>>
>> ... time passes ...
>>
>> Actually, looking closer at your pictures, I'm starting to wonder,
>> because it looks like the "noise" always hits at the top and bottom of the
>> signal. If this is a RAM chip, then that'd mean the same chip is getting
>> hit for the same portion of the signal each time, and I can't think why
>> that would happen.
>>
>> I think we should be able to distinguish RAM vs DAC/MUX failure by
>> playing with DC inputs to the scope - see below.
>>
>>> Do you know if the ICs are currently available ?
>>>
>> I'd be very surprised if they aren't - these are just 2K (or 8K) static
>> RAMs.
>>
>>> And what about raising one (or more) pin to re-create the problem and
>>> validate the hypotesis ?
>>>
>> You could do that, but there are 64 total pins to try :/.
>> Can you reproduce this problem with a DC signal, and do you have a second
>> (storage) scope to diagnose this?
>>
>> Try putting your signal gen on AUX (or CH1) and trigger on it there, then
>> look whether you get a messed-up waveform on screen with DC on the input.
>> From your pics it looks like you might have a stuck bit, so play with the
>> DC input. You can also ground the input and play with the input offset for
>> the same effect as inputting DC.
>>
>> Assuming you can provoke the problem with a DC signal (or offset) you
>> could narrow this down to a chip by looking at the data lines (there's 64)
>> and looking for the the bit that looks bad.
>>
>

[Non-text portions of this message have been removed]

Join TekScopes@groups.io to automatically receive all group messages.