开云体育

Look under "Surface Delamination."

Greg

Hi Wamor,

Would this work on a TDS620A?

Rafael

To me, that appears like someone has used an incompatible contact cleaner or such on it.

Russ

I would very much appreciate those scans

Mark
W7HPW

Real Radios Glow in the Dark

On Sat, Mar 22, 2025 at 07:39 AM, Dave Daniel wrote:

I have sent pp. 31, 6-22 and 6-23 to Mark, the OP.

Where and who is "Mark, the OP"? Could you consider uploading just those 3 pages, 3-1, 6-22 and 6-23 to TEKSCOPES files area? That would help anyone, including me, update the old manual until such time as Mark can insert those pages into that copy, where ever that is? Then I don't have to remember to update or download a newer copy at some time in the future.
Thanks so much for taking the time to do this,
Bill

On Mon, Mar 24, 2025 at 04:17 AM, Sigur?ur ?sgeirsson wrote:

I've never seen such a thing (/g/TekScopes/album?id=301415),
how strange. I wonder if anyone here knows what sort of plastic Tek used
for these?

I have some (PG506 for one, IIRC) cam switches that are cracked on the ends, and I expect they're on borrowed time. Nothing as bad as in Clark's photos, though.

I've never looked closely at one of those drums, but it looks to me that it
would be relatively straightforward to 3D print a replacement nowadays.

I've had the same thought, more recently with 7A29 cam lobes. Those are a slightly different beast, but suffer severely from cracking (and I have one that's missing entirely).

Thinking about this for the more typical long cam drums, I suspect one could convert the dotted alignment diagrams in the service manual to a table, and produce cam rings for an individual contact using a given column of on/off sequences for a given contact to generate the lobes (assuming equal intervals?) on a given drum diameter. I think this would be straightforward in OpenSCAD, but have never looked closely at the ramp geometry. Stacking those rings would give you the full cam drum, and then there'd be a mildly annoying detent gear and/or bearing section at the ends, plus grooves for circlips. I suspect that would be tedious, unless it could be parameterized somehow.

All purely academic speculation, as my free time is about to go towards outdoor chores instead of playing with the 3D printer.

Adam

I was fortunate to find an NOS replacement for one drum , 105-0509-00. That allows me to experiment with the bad unit; however, I am not sure where to start. One thought is to find a compatible resin, cyanoacrylate or epoxy to “rehydrate” and seal the parched surface. Hopefully I can find something to fill the cracks and create a smooth surface and restore internal strength. If successful, I can apply it to the other drum, 105-0510-00. If it doesn’t work, then I need to find or fabricate a replacement.

Last time I did serious IEEE programming was writing a driver using PLM-86 for one of the competitors in the MATE program.? That was a LONG time ago.? TMS9914 I think was the chip.

Harvey.

Hey Clark,

I've never seen such a thing (/g/TekScopes/album?id=301415),
how strange. I wonder if anyone here knows what sort of plastic Tek used
for these?

I've never looked closely at one of those drums, but it looks to me that it
would be relatively straightforward to 3D print a replacement nowadays.
I've recently dusted off my 2nd hand Prusa, so now everything looks like a
nail to me :). The commercial sintering services should be able to produce
a better part than the original. Even a lowly FDM printer should be able to
produce a usable part, though perhaps a little bit of beveling would be
necessary to avoid sharp overhangs.
The problem would be to produce the CAD design, maybe I'll go see if I have
something to play with in my box of mystery modules...

Siggi

On Sat, Mar 22, 2025 at 8:29?PM Clark Foley via groups.io <clarkfoley=
[email protected]> wrote:

I recently acquired a PG502 from Tek surplus (aka Country Store) and found
several setting to be intermittent. Expecting that a good cleaning would be
in order, I was astonished to find that cam switch drum appears to be
decomposing. It looks dull, powdery and parched like mud flats after a
dessert gully washer!
In fact, there was a lot of fine debris on the contact board. Cleaning the
board and the contacts made no difference because the cam lobes are
deteriorating. I have not touched the cam drum with any cleaner or other
chemicals.
This unit was used in the production test area; perhaps its entire life.
It was last cal’d June 2022. Perhaps it is the result of 45 years of
continuous up time in a rack.

I have never seen a cam drum look like this.

Has anyone seen such a thing?
(See photo gallery for “Decomposing Cam Switch Drum.”)

On Mar 23, 2025, at 13:15 , Adam R. Maxwell via groups.io <amaxwell@...> wrote:

At this point, anything could be bad as far as I'm concerned, including my reasoning to get to the VR as a potential problem.

I ran the 492 long enough for it it wake up again, and tried swapping a cold VR module in…and it kept working with a full scale peak, which ruled out the VR (and calls into question my notes on power levels).

After powering off for a 1/2 hr or so, it was back to showing the 100 MHz reference as -50 dBm instead of -20 dBm. I'm now fairly sure the 829 MHz 2nd converter is the culprit:

More careful power measurements (paying attention to ref level setting), the 110 MHz IF out from the 829 MHz second converter is -55 dBm when working, and -70 to -65 dBm when not working. Both seem low; I have -40 dBm out from the 2072 MHz 2nd converter IF output, in the working and non-working cases, and my reading of the schematic (drawing <14>) is that it should not be losing that going to P232.

I think this points back to the IF select section inside the 829 MHz 2nd converter, which was my original hypothesis at the start of this dumb thread. For grins, I heated the converter up gently with a heat gun and actually saw the peak jump 30 dBm. Cooled the converter down with cold packs and lost that 30 dBm again, then heated back up with a heat gun and gained it back, so the experiment is repeatable.

What I don't know is if this points to a bad solder joint? I thought semiconductors generally behave badly when heated.

thanks,
Adam

Have you checked its functions, or are you too scared ?????
;-)

On 2025-03-23 11:46 AM, Harvey White wrote:

IIRC, an IEEE-488 address can be any number from 1 to 32. (0 is reserved).

Almost. Valid addresses are 0 thru 30, with 31 reserved for Untalk or Unlisten.

Steve Hendrix

On 2025-03-23 10:19 AM, Radu Bogdan Dicher via groups.io wrote:

My initial question was meant to ask a slightly different thing though (I
did a bad job explaining). Is it customary to just plug GPIB into a running
instrument while making sure the address is different than any other
(previously) connected instrument, and then start to talk to the
instrument through it? Or doing it while the instrument is off is a safer,
"best practice" procedure?

If your incorrect address of 4 instead of 14 was written in hex or octal rather than decimal, I'd suspect a bad DIP switch. But IEEE-488 addresses are usually stated in decimal, and context in the rest of your post suggests decimal, so that's probably the wrong explanation.

There should be no problem with hot-plugging, unless there is a data transfer occurring at the same time. Indeed, an instrument would probably be least likely to disturb a transfer in progress if it were powered for at least a few seconds before plugging it in. There's a spec for what fraction of instruments on a bus are allowed to be unpowered - I forget now but it's something like 1/3 or 1/2. As long as you're not actively transferring data at the time, there's no harm in hot-plugging. The original spec calls out terminating resistors to both Vcc (5V always, in that day) and Gnd. I have found that newer instruments sometimes use a simple 1K to 3.3V, which is a very rough Thevenin equivalent.

Thanks for the compliment on my KISS-488 manual!

Steve Hendrix

Hi Mark,

On Mar 23, 2025, at 11:04 , Mark Vincent via groups.io <orangeglowaudio@...> wrote:

Could the transistors be bad? The 2N5179 replaces ones on this board of the p/n, 151-0282-00. If you have component cooler, use that to briefly spray on the transistors to see if cooling them some makes a difference.

At this point, anything could be bad as far as I'm concerned, including my reasoning to get to the VR as a potential problem. Without extenders, I don't think there's enough room to spray anything inside the VR assembly.

I forgot to mention that two VR modules have the same gain issue, which might point a finger at what's controlling them (the microcomputer).

thanks for the ideas,
Adam

On Sun, Mar 23, 2025 at 9:49?AM fenugrec via groups.io <fenugrec=
[email protected]> wrote:

Tek really messed up when they killed the old site. Maybe if more people
complained (I did, a bit) they would backtrack ?

I dumped all my notes and screenshots to my website,

It looks like archive.org captured at least some of the threads you
reference:





Maybe you could update the links on your page?

Adam,

Could the transistors be bad? The 2N5179 replaces ones on this board of the p/n, 151-0282-00. If you have component cooler, use that to briefly spray on the transistors to see if cooling them some makes a difference. If any transistors are bad, Mouser has the transistor in stock. The two 68mfd decoupling condensers for the B+ supplies on this board could be high in ESR.

Mark

Radu Bogdan Dicher <vondicher@...> added the photo album Tektronix TDS754D - acquisition board issues ( /g/TekScopes/album?id=301426 )

I added a couple of pictures here:
/g/TekScopes/album?id=301426. Please note:

1. CH 1 seems to be able to display the square wave from the
test/adjustment terminals.
2. CH2 and CH3 display a flatline, but no square wave (not quite sure
why).
3. CH4 - the one with the main issues, by all signs - doesn't display a
waveform at all.

Radu.

On Sun, Mar 23, 2025 at 9:37?AM Radu Bogdan Dicher via groups.io <vondicher=
[email protected]> wrote:

I'm reviving this thread, because I seem to have a very similar issue and
am not sure how to progress.

This is a 754D that had a plethora of errors, most of which got solved by
replacing SRAMs serving U200 (so, if the sequencing described by Jay
applies to this acquisition board, that'd be CH4, but it seems to impact
all channels apparently). The root cause was (possibly alongside other
types of failures of the SRAMs) a low-resistance condition between pins 2
and 3 of those SRAMs (corresponding to A16 and A14, all addresses being in
parallel across the eight ICs) of about 10 ohms. I had to remove seven of
the eight chips before this condition was eliminated (one original SRAM
left on that channel). Once I did that, all errors pointing to specific
U201 through U216 went away.

I've also reflowed all pins for U200 to eliminate cold joints being as a
possible cause.

I have on error left: "diagnostic test failure, digDataFormatDiag,
ERROR!!BYTE mode, in demux 200 ,i= 4 memBaseAdr 0x738000a= data =
fffffa00, expectedData[i] = aa00" This seems to generate some spurious
peaks, just like Jared seemed to experience (I'll enclose a picture
shortly).

Not sure what else to look for to narrow down the issue left.
Radu.

I'm reviving this thread, because I seem to have a very similar issue and am not sure how to progress.

This is a 754D that had a plethora of errors, most of which got solved by replacing SRAMs serving U200 (so, if the sequencing described by Jay applies to this acquisition board, that'd be CH4, but it seems to impact all channels apparently). The root cause was (possibly alongside other types of failures of the SRAMs) a low-resistance condition between pins 2 and 3 of those SRAMs (corresponding to A16 and A14, all addresses being in parallel across the eight ICs) of about 10 ohms. I had to remove seven of the eight chips before this condition was eliminated (one original SRAM left on that channel). Once I did that, all errors pointing to specific U201 through U216 went away.

I've also reflowed all pins for U200 to eliminate cold joints being as a possible cause.

I have on error left: "diagnostic test failure, digDataFormatDiag, ERROR!!BYTE mode, in demux 200 ,i= 4 memBaseAdr 0x738000a= data = fffffa00, expectedData[i] = aa00" This seems to generate some spurious peaks, just like Jared seemed to experience (I'll enclose a picture shortly).

Not sure what else to look for to narrow down the issue left.
Radu.

Continuing my diary of 492P woes in case it's helpful to some other poor schlub reading the archives in future.

On Mar 20, 2025, at 22:00 , Adam R. Maxwell via groups.io <amaxwell@...> wrote:

Another problem possibly found: it's been starting up deaf when cold (no zero spike, just baseline noise), and suddenly comes alive. Tonight I plugged the 100 MHz output into a 7104 when I started the 492 up, and the 100 MHz oscillator was dead. Also swapped that out, but the replacement doesn't quite make -20 dBm.

At least one version of the service manual says you can replace select resistor A34A1R1018 if output of the 100 MHz reference oscillator is low. Schematic shows it as 309, and this one had over twice that. Adjusted for correct amplitude by setting the 100 MHz peak to a -20 dBm peak from my 8640B (set using a power meter).

The original has an air variable cap in the middle fully meshed, which seems fishy.

"Tuning capacitor C3031 in the collector circuit serves to adjust for maximum output." It was adjusted for maximum output, so no problem there. Still takes ~5 minutes to start.

In spite of this progress of sorts, a -20 dBm signal is still 30 dB below the top of the display, so I'm still missing something.

I left it running for a couple hours yesterday while cleaning up the shop, and noticed that the 100 MHz reference had suddenly regained 30 dBm. Checking power input to VR module, it was -25 dBm. This morning, it was once again down 30 dBm on the display, and power to VR module was about -26 dBm, so I'm thinking all the RF plumbing on the bottom is fine.

At this point, I'm thinking it's probably temperature-related, but I'm stuck until I can fabricate extenders to poke at the VR while it's operating. Ideas welcome.

Adam
KK7ASV