TEK 485

[EC8010]

Try the horizontal*10 mode, and see if part of the scan is off the side.
Try horizontal position control to see if you can move part of the trace off the side.
If you can, the deflection voltages are correct and the the issue is is merely the adjusting the sweep width as per the manual.

It's the deflection amplifier, perhaps an output transistor. Assuming that was a genuine square wave, each half of the cycle should be the same width, but it isn't. Nonlinear sweep. Fuggered X amplifier.

[EC8010]

Blimus! I've just looked up tggzzz's reference and seen all sorts of ludicrous characteristic impedances. And I thought there were just a few... "For there is nothing either good or bad, but thinking makes it so." Yup, Shakespeare knew about transmission lines too.

[tggzzz]

Next question: why are there 50, 51, 52 ohm cable specs?

Bonus points: why 61.8ohms for the cable in my lab? I was told the reason it couldn't be anything else, but I've never had the information to verify it.

[tggzzz]

Try the horizontal*10 mode, and see if part of the scan is off the side.
Try horizontal position control to see if you can move part of the trace off the side.
If you can, the deflection voltages are correct and the the issue is is merely the adjusting the sweep width as per the manual.

It's the deflection amplifier, perhaps an output transistor. Assuming that was a genuine square wave, each half of the cycle should be the same width, but it isn't. Nonlinear sweep. Fuggered X amplifier.

Both high and low look like 2.8 divisions wide.

I don't think this 485 has been working recently, so it could still be simple "x-magnification" tweak correctable as per manual. Or not, of course.

I did once have a faulty Y amplifier that I managed to fix. An internal resistor was open circuit, but I could attach an external SMD resistor in parallel, It worked, but the risetime was 1.25ns rather than 1ns.

[EC8010]

I've just held a rule up to the screen; so much for my eyesight! You are correct.

[vk6zgo]

I've been known to take one to hamfests, to see whether cables were 50 or 52 ohms

52 ohm? I used 75 for baseband video at the Beeb. 50 ohm is de rigeur for most RF stuff. Nuclear energy spectrometry is 91 ohm. But 52 ohm?

Just different compromises----another was 51.5 ohm!

When we dragged the 1959 Marconi Transmitters at ABW2 moaning & screaming into the brave new world of 1970s PAL colour, one of the changes was to match the 51.5 ohm Sound & Vision Tx into the new Filterplexers & combining units which were made by AWA & were 50 ohm.

To this end, we had quarter wavelength sections of, from memory, 50.7448ohms.----a rather "nice little earner" for AWA, as all they needed to achieve this impedance was the services of a lathe operator.

They were a compromise, of course, as the old analog Ch2 in Oz was 7 MHz wide, with the Vision carrier at
64.25 MHz & the Sound carrier at 69.75MHz.

[tggzzz]

A compromise implies splitting the difference between two necessities or requirements. So what were those?

The 61.8ohms apparently wasn't a compromise

[MED6753]

Let's clear up some confusion and I found the reason for the compressed trace.

First, the trace is linear as shown. Second, there's a vertical issue too. At that attenuator setting (1V/Div) that trace should be 5V or 5 divisions high. It's barely 2.5 divisions. I verified on another scope that it is indeed 5V.



As I stated I found the issue. That prior pix was taken with the 15kV disconnected from the CRT. In other words....there is no 15kV. My hunch was correct. But to be absolutely sure I will measure it with the high voltage probe.



So apparently U1600, the X6 multipler, is bad. I have a parts unit and I'll rip into to find out how difficult it will be to remove that module. And hopefully it will be good. If it proves to be too difficult this project might come to a screeching halt.

[MED6753]

He's dead Jim.

[MED6753]

Gang, the party is over. The following pictures are the parts unit with the trigger board and PSU board removed. U1600 (X6 multiplier) is located in that board right rear with the shield. There is no way to get that board out without nearly disassembling the entire scope. And to add insult the manual provides absolutely no disassembly instructions. I've mentioned that before in prior adventures with repair of 485's. If I didn't already have a 485 in my collection I might attempt further disassembly. But since I have two fully functional 485's I really see no sense to it. So now I'll have two parts units. These 400 scopes, 465/475/485, are a marvel of engineering but are packed so tight that repairs can be a nightmare. This repair is a nightmare I'm not going after. And it really sucks that I diagnosed the failure but can't easily repair it.




If I was able to get the board out I would just swap it over.

[Cubdriver]

Bummer.

-Pat

[tggzzz]

Can't say I blame you.

One of mine had a fault near there and I chickened out of disassembly. It is now a mule.

Sometimes life is just too short.

[MED6753]

Here's one of the functional 485's on top of a 2235. The later series of portable TEK scopes tend to be much easier to service with the advent of LSI circuitry. Those 465/475/485's were still packed with discrete components.



And now that bench 2 is cleared Harley wasted no time reclaiming it.



Oh and Blondie came into the lab and said it's dusty. Get to it buddy. Yes m'am.

[tggzzz]

Here's one of the functional 485's on top of a 2235. The later series of portable TEK scopes tend to be much easier to service with the advent of LSI circuitry. Those 465/475/485's were still packed with discrete components.

IMHO the 4[6,7,8]x semiconductors and ICs are all pretty similar. Sometimes the mechanical construction of the 485 makes it a real pig to service, though.

[bd139]

Here's one of the functional 485's on top of a 2235. The later series of portable TEK scopes tend to be much easier to service with the advent of LSI circuitry. Those 465/475/485's were still packed with discrete components.

IMHO the 4[6,7,8]x semiconductors and ICs are all pretty similar. Sometimes the mechanical construction of the 485 makes it a real pig to service, though.

Standard Tektronix. The Perl of oscilloscopes. Write/Build only. Modify/repair is hell.

[Zenith]

Standard Tektronix. The Perl of oscilloscopes. Write/Build only. Modify/repair is hell.

A lot of scopes are the same. Hameg, which is poles apart from Tek, are also a pain to dismantle, so repairs which should be simple, such as replacing capacitors, require either keyhole soldering, or an amount of disassembly and reassembly, which makes you think twice. At least Tek have comprehensive manuals, whereas Hameg manuals are rudimentary.

The best I've seen from the point of view of modular construction and ease of maintenance with decent manuals are Hitachi. Hitachi were getting on towards a top end brand. Topward are surprisingly good. I haven't had to deal with loads of others such as HP and Philips.

[tggzzz]

Here's one of the functional 485's on top of a 2235. The later series of portable TEK scopes tend to be much easier to service with the advent of LSI circuitry. Those 465/475/485's were still packed with discrete components.

IMHO the 4[6,7,8]x semiconductors and ICs are all pretty similar. Sometimes the mechanical construction of the 485 makes it a real pig to service, though.

Standard Tektronix. The Perl of oscilloscopes. Write/Build only. Modify/repair is hell.

Yeah

I looked at PERL, thought thank the <deity> I don't need to implement parsing/ETL/CRUD, I'll stick to using awk and/or a decent language.

[Zenith]

I always liked PERL. A mixture of C, shell scripts and a few bits of its own. I thought it was maintainable as long as it was properly commented.

[MED6753]

More 485 drama.

I pulled out my 2nd 485 to give it a dust off and power up and the A Triggering was nowhere to be found. So I took the "low road". I pulled the trigger board out of the 485 I condemned yesterday and installed it. Problem fixed.




The old board. Don't know what's wrong with it and don't care.

[EC8010]

Shame about the unfixable 485, but at least it's proven its worth by repairing another. My 485's EHT died completely, leading me to suspect the transformer or drive transistor rather than associated rectifiers, but I hit the same problem that it was buried and I had another (brand new) 'scope (TDS3032).

However... The TDS3032 fell foul of the Dallas memory issue, starting by losing the date/time and eventually forgetting how to save files to floppy disk. Getting inside the TDS3032 isn't too bad (weird twiddles with the handle detailed in the Tek manual). A chap on Fleabay sells a programmed replacement that has an external (and rather larger) lithium cell. Desoldering the Dallas abomination without damaging the PCB was tricky. Desolder wick worked for most pins but the diagonally opposite corner pins that (presumably) connect to power and ground planes don't have enough thermal relief, so I had to gently lever the IC out whilst heating those pins. After that, it was easy, and careful defluxing made it look as though nobody has interfered. In summary, the fix was nerve-wracking but worthwhile.

Edit: That's a handsome cat reclaiming its territory.

[MED6753]

Shame about the unfixable 485, but at least it's proven its worth by repairing another. My 485's EHT died completely, leading me to suspect the transformer or drive transistor rather than associated rectifiers, but I hit the same problem that it was buried and I had another (brand new) 'scope (TDS3032).

The failure on that trigger board was most likely the one of two tunnel diodes. But I have seen that large custom TEK chip on the board lower right fail too.

[tggzzz]

I had a problem on the trigger board that wasn't a TD. Can't remember what, but I suspect I documented it here or at the other place.

[bd139]

IMHO the 4[6,7,8]x semiconductors and ICs are all pretty similar. Sometimes the mechanical construction of the 485 makes it a real pig to service, though.

Standard Tektronix. The Perl of oscilloscopes. Write/Build only. Modify/repair is hell.

Yeah

I looked at PERL, thought thank the <deity> I don't need to implement parsing/ETL/CRUD, I'll stick to using awk and/or a decent language.

I use a parser generator (I wrote one) for that and a proper language. The only way. Some of the stuff I see people parsing with awk/perl is horrifying.

[mansaxel]

I use a parser generator (I wrote one) for that and a proper language. The only way. Some of the stuff I see people parsing with awk/perl is horrifying.

awk makes for a pretty powerful and always efficient parser if your file format is remotely decent. Latest thing I wrote for money in it is a thing that parses DNS replies as formatted by dig; you start out with a prefilled error count of 3, and as the parser eats the reply, correct results deduct from the error count. If you have 0 errors at the end of parsing, the host will keep being attractive to clients; if there are errors left, the BGP daemon will be soft reloaded with a configuration that prepends its own AS number once, instantly removing all traffic to the node, while keeping it running but "farther away" in routing topology. If all other nodes have failed in the same way, they will be kept in service to prevent a blackout.
This is run from cron fairly often. There's also a script run slightly less often that will restart the daemon and if it gets good results remove the prepend.

[bd139]

I use a parser generator (I wrote one) for that and a proper language. The only way. Some of the stuff I see people parsing with awk/perl is horrifying.

awk makes for a pretty powerful and always efficient parser if your file format is remotely decent. Latest thing I wrote for money in it is a thing that parses DNS replies as formatted by dig; you start out with a prefilled error count of 3, and as the parser eats the reply, correct results deduct from the error count. If you have 0 errors at the end of parsing, the host will keep being attractive to clients; if there are errors left, the BGP daemon will be soft reloaded with a configuration that prepends its own AS number once, instantly removing all traffic to the node, while keeping it running but "farther away" in routing topology. If all other nodes have failed in the same way, they will be kept in service to prevent a blackout.
This is run from cron fairly often. There's also a script run slightly less often that will restart the daemon and if it gets good results remove the prepend.

I guarantee I can break this if I have access to add DNS records

Possibly a classic case of trusting conformance rather than validating conformance in there.