Re: A 2465 teaser...

Tom Gardner
 

It would be interesting to know if the "glitch" amplitude depends
on the relative positions of the CH1/2 trace on the screen, with the
inputs grounded and with different DC inputs.

I would identify just about all the analogue switches (e.g. 4053s)
I could find, and see if any of those are being switched too slowly
and/or had too high a resistance and/or whatever was driving their
signals had become too high resistance. Maybe there's a mechanical
failure somewhere in that chain.

I would use another scope to find where the glitch /doesn't/ exist
- trigger on any control signal vaguely associated with the glitch,
potentially even the readout vert/horiz signals diagram 48 and 49
- work back from the Y output deflection voltage, through U600, U400
- then to U100/U200
- then control signals VS1/2/3/4 from U650, checking particularly
if there is any difference between VS1/2 and VS3/4

On 10/11/17 14:19, Chuck Harris cfharris@... [TekScopes] wrote:

Hi Tom,

It looks just like what you would see if you had a fast
marker pulse, and you sped up the timebase. At slow
timebase settings, it is just a spike, at faster settings,
it is a fast rise, with a much, much slower decay.

The "hooks" are about 5us in duration. The risetime is
very fast, but the decay takes most of the 5us.

I believe that I am looking at two things. Probably issues
with the channel switch:

1) a glitch that is leaking through whenever the sweep starts
drawing CH1/CH2 on the screen.
2) a stream of display glitches that leak through whenever the
channel switch switches between CH1/CH2 and the CH5, the
display.

I have zero doubt that the random looking grassy pulses are
the transitions when the display takes over the beam from CH1/CH2.
They disappear when the display is turned off.

Everything is complicated by the display timing logic. The 2465
tries to avoid the "holes" in the traces that happen when the
display has to happen, so it has 4 or 5 different modes that
range from alternating display and trace, to random display
writing, to writing display full time. The display timing logic
makes these decisions based on how long it has been since it has
refreshed the display.

-Chuck Harris

Tom Gardner tggzzz@... [TekScopes] wrote:
On 10/11/17 06:37, Chuck Harris cfharris@... [TekScopes] wrote:

An additional clue is the leading hook's decay curve changes
slope with sweep speed, but the scope will not trigger on
this signal, nor on any of the random grass that appears on
the trace. That indicates that it is getting injected after
the trigger pickoff.
By that do you mean that when you change the timebase
the decay curve is the same time or the same number
of divisions?

I am pretty certain it has something to do with the display
readout logic.
That was the feeling I got from reading your description.

To see whether it is correlated with the display readout
timing, I would try either of two tests:
1) apply an external signal and adjust its frequency to be
the same as (a harmonic or subharmonic) the display
readout frequency so that any "twinkling" in the traces
is more-or-less stationary. (Start with a timebase of
~200us/div). Then see if the hooks are stationary w.r.t.
the intensity variations. If they are, then the display
readout is involved.
2) without an external signal and a ~2ms/div timebase,
change the holdoff until the twinkling is stationary,
and look for the hooks as above.

If display readout is involved, I would find out what is
happening when the display is switching from trace
to readout. I would observe the Y waveform and blanking
signals after the display sequencer IC and near the
display blanking IC. Trigger on either the blanking
waveform or the Y-waveform.

I would be looking for either the blanking signal to
be mistimed or the Y-waveform to be changing too slowly.
I would suspect the latter, so then it is a case of moving
"away from the output" until you find where it isn't
changing too slowly.

Be careful with probe tips around there; I know they
can short signals and destroy ICs :(

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