Repairing and Upgrading an old PM3320A - Including adding FFT!

[SaabFAN]

Okay, I think I give up.

I have now replaced all 63V or less rated the caps inside the PSU and readjusted the Reference-Voltage.
The 14V-Rail is now about 0,5V below spec, the 5V-Rail sits at 5,08 to 5,19V, depending on the measured test-point.
The Scope is a bit more stable, but it still locks up after some time.
Measuring the Status-Signal of the ADC and the DataAvailable-Testpoint on the DPU, I noticed that the DAVA-Signal stops when the trace-updates stop, and so does the ADC-Status Signal.
If increase the timebase, the ADC-Status Signal returns at the switch from 200µs to 500µs, but there is still no DAVA-Signal and the traces do not update.
I suspect the reason to be either clocks (I can't measure those, as the PM3350 only goes to 50Mhz and shows only a faint amplitude at the 100Mhz Crystal and almost nothing at the 125Mhz crystal), or the DPU itself, with a tendency towards suspecting the DPU.

@guido:
Unfortunately, I don't know exactly what the PLS is supposed to do. The Service-Manual only states that, together with the SRAMs, it generates control signals and a part of the instruction-addresses for the Data Processing Unit that is entirely made with 74-Logic chips.
Because the chip seems to work properly for at least a time, I think it could be possible to read it one or two times before it misbehaves.
I am currently trying to get another PM3320A (about half a year older than mine and with the FFT-Option), but it looks dark: Current bid: 215€ and 5minutes to go. - Didn't get it -.-

AAARRRRGH!
Why can't it decide whether to work or not??
I pulled the PLS-Chip and a 74LS125 out of their sockets (the only socketed ICs on the DPU-Control board), and carefully sprayed the contacts with Kontakt 60 Cleaning agent, cleaned it with a metal brush, sprayed Kontakt 2000Gold on it (Oil for connectors) and also botched a 10µF/16V SMD-Cap between the legs of a 100nF ceramic cap.
The scope ran for about 20minutes with the PM3350 and the DS203 connected to the Testpoints on the DPU-Control board, showing the various status signals.
The signals that disappeared when the trace-updates stopped were: Interrupt-Level 2, DataAvailable and TransferReady. Clock Register and EndConversion remained active.

I think this pretty much eliminates the possibility that there is something wrong with the clock and isolates the problem to the DPU-Control board, a.k.a. Module A8

[dom0]

I am currently trying to get another PM3320A (about half a year older than mine and with the FFT-Option), but it looks dark: Current bid: 215€ and 5minutes to go. - Didn't get it -.-

Sold for 217+20 €. Welcome to Germany, Gentlemen.

[SaabFAN]

I am currently trying to get another PM3320A (about half a year older than mine and with the FFT-Option), but it looks dark: Current bid: 215€ and 5minutes to go. - Didn't get it -.-

Sold for 217+20 €. Welcome to Germany, Gentlemen.

And that's small compared to the Hamegs^^

[tautech]

Shit you make this thread hard to follow when you edit a post in a major way 2 hours later. 

Make another post explaining changes and use the struckout strikeout.

[guido]

......, although the signal has a larger than unsual noise-ground, which is PSU-Related.

http://www.amplifier.cd/Test_Equipment/other/PM3320A.html: Im Bereich der beiden grossen quadratischen  CCD-Chips  sollten bei Problemen  mit der Signalqualität ebenfalls alle SMD Elkos gewechselt werden.

More capacitors

[SaabFAN]

More capacitors

Even more?
My unit looks a lot different to the one in your link btw. The newest IC I could find so far was the PLS105, which was manufactured in 1990. The Software was written in november 1989 and all the boards look a bit more modern than the one's in the pictures.
I will nevertheless try to replace more caps. At least on the digital boards. There are a lot of those plastic encapsulated polarized capacitors on there. I'm replacing them with SMD tantalum Caps of which I have about 1400 from my granddad
The other axial Capacitors on the analog boards on the bottom of the scope could be a problem though. Their footprint is too large to house a SMD-Cap and radial ones will probably not fit between the boards and the board and the casing. Replacing those will probably not solve the problem mit the Trace-update stopping though. So replacing those caps is a option once the scope runs, which it does now for about 10 to 20 minutes. Interestingly, activating Channel B reduces the time to a lockup.

I have now 4 suspects: Aquisition Control Logic (sits on the MRAM-unit and has no testpoints ), DPU Control Module (Probably something wrong with the PLS105-Chip - Most likely scenario), DPU Module (unlikely - all ICs are 74-Logic that should be pretty robust), one of the SRAM-ICs.
Tomorrow I will solder some test-leads onto the MRAM-Module and connect everything to the small USB Logic-Analyzer I got from ebay, while I'm watching the rest on the PM3350, DS203 and Rigol DS1054Z.
The scope once was owned by a testlab by the way, so it probably has logged quite a lot of hours. No excuse for failing caps though!

[tautech]

The scope once was owned by a testlab by the way, so it probably has logged quite a lot of hours. No excuse for failing caps though!

Yeah right. No way I could discount the caps in that situation. Even more cause to suspect them IMO.

No. 1 rule: get the PSU perfectly to spec, same goes for any local switcher as well.

[SaabFAN]

I meant that as a critique directed at Philips for using caps that do not stand the test of time in such a high priced instrument

There is only one thing I can manipulate at the PSU: The 10V Reference-Voltage. Everything else is hardwired.
5V-Rail is at 5,18V, the 14V Rail is at 13,6V with the Reference-Voltage at exactly 10V.
The other rails are regulated indirectly by regulating the 14V-Rail.

Something is loading down the 14V-Rail and the regulator tries to get it up to full power, while the 5V-Regulator is trying to get its rail back down to 5V. Probably the main cause for a lot of the noise on the supply-rails: 2 regulators working against each other. Even though I have managed to get that noise down to a level I would consider normal for digital electronics: About 20mV on the 5V-Rail. My PC has close to 5mV Ripple on the 1,4V Processor-Supply, which is a lot more in relation to the nominal voltage. (There probably is a lot more ripple there, as the CPU clocks at 4,5Ghz and the scope I used was a Vellemann 2Mhz scope^^)

[SaabFAN]

Meh!
I thought I had it isolated to the DPU Control Unit. Now with my DS1054Z finally here after almost 2 months waiting, I was able to measure even more signals at the same time and: Turns out the Aquisition Control Logic on the MRAM-Module might be the problem as well!
One of the Signals that vanishes, when the traces stop updating is DAVA (Data Valid), which comes from the ACL and is an input to the PLS-Chip on the DPU (which among other signals puts out TRRY, which in turn is an Input-Signal to the ACL  ).
This increases the count of potentially faulty PLS-Chips to 3! Assuming there is nothing wrong with the SRAMs, which I cannot test either.
I'm now going to add heatsinks and see if that increases the up-time beyond 1 hour.

[guido]

The signals that disappeared when the trace-updates stopped were: Interrupt-Level 2, DataAvailable and TransferReady.

Can't see DataAvailable, only DaVa; data valid. This seems to be an input to the PLS. If it's gone, it might explain why the other two are also gone. But TransferReady seems obvious, without valid data, no transfer. And when there is no tranfer, it cannot be ready 

Have a look at A5 where DaVa generated at D1819 and further upstream.

Addendum:
When i hit sent, i got the message that there was a new post. So you've seen that aswell. First have a look at the chip which generates DaVA. The inputs are clocked to sync them for the bus. Check if the input for DaVa still changes when the output hangs. Check the other signals on the chip. If Dava-in is also frozen, work your way back.

You don't want to increase uptime; you want to decrease it so you find the problem faster. Which might just be a bad solder joint, e.g. the backplane. With a bad ram chip, i would assume you get garbage on the screen. And i guess there's a ram test at start-up or in some test menu.

Complicated beast with a zillion options for a problem.

[tautech]

I meant that as a critique directed at Philips for using caps that do not stand the test of time in such a high priced instrument

There is only one thing I can manipulate at the PSU: The 10V Reference-Voltage. Everything else is hardwired.
5V-Rail is at 5,18V, the 14V Rail is at 13,6V with the Reference-Voltage at exactly 10V.
The other rails are regulated indirectly by regulating the 14V-Rail.

Think of it like this: The caps have well met and exceeded Philips intended instrument design life;

Something is loading down the 14V-Rail and the regulator tries to get it up to full power, while the 5V-Regulator is trying to get its rail back down to 5V. Probably the main cause for a lot of the noise on the supply-rails: 2 regulators working against each other.

Quite right.
Suspect Tag Tantalums and Electrolytics.

I'm now going to add heatsinks and see if that increases the up-time beyond 1 hour.

If it's heat related the finger test for LV might find the culprit or use some freeze spray.

[dom0]

I meant that as a critique directed at Philips for using caps that do not stand the test of time in such a high priced instrument

There is only one thing I can manipulate at the PSU: The 10V Reference-Voltage. Everything else is hardwired.
5V-Rail is at 5,18V, the 14V Rail is at 13,6V with the Reference-Voltage at exactly 10V.
The other rails are regulated indirectly by regulating the 14V-Rail.

Think of it like this: The caps have well met and exceeded Philips intended instrument design life;

History shows us, that it's hard to predict capacitor life. Just take the plague or radial (rot and failure) vs axial (40 years and still good) Sprague caps.

[tautech]

I meant that as a critique directed at Philips for using caps that do not stand the test of time in such a high priced instrument

There is only one thing I can manipulate at the PSU: The 10V Reference-Voltage. Everything else is hardwired.
5V-Rail is at 5,18V, the 14V Rail is at 13,6V with the Reference-Voltage at exactly 10V.
The other rails are regulated indirectly by regulating the 14V-Rail.

Think of it like this: The caps have well met and exceeded Philips intended instrument design life;

History shows us, that it's hard to predict capacitor life. Just take the plague or radial (rot and failure) vs axial (40 years and still good) Sprague caps.

Agreed. 
The more time I've spent on EEVblog has enlightened me to failures of "quality" brands of caps that I believed to be beyond question. 
In recent times I've found Philips caps suspect when I previously thought them OK.
Not a generalisation at all, just consider any caps usage and application, the ripple it has to smooth and the heat in it's location, all these factors determine reliability.
Great we can all share our experiences and help one another.

[SaabFAN]

Tomorrow I will check the CCD control logic on the bottom side of the scope. It is possible that the failure is located there, as the STCV (Start Conversion)-Signal on the MRAM-Unit disappeared right when the traces stopped updating.
The problem there: Last time I turned the scope upside down to get to the bottom side, it worked. So I put the IEEE-Unit back in (haven't done anything to that one) to increase the chances of it failing.
If the STCV-Signal does not disappear on the A33-Unit (CCD Control), the problem is somewhere between that one and the DAVA and TKSA-Output FlipFlop on the MRAM-Unit (A5), where the STCV-Signal comes through a inverting buffer and is then fed into the FlipFlop as a clock-signal.

Link to a datasheet for the PALs: http://pdf1.alldatasheet.com/datasheet-pdf/view/109841/NSC/PAL16R8AC.html

Btw. Does anyone know anyone who might be able to source a Service Manual for the last version of these scopes? My scope has a different ADC-Unit Layout than the one shown in the Service Manual, as well as a different MRAM-Unit (4 32K SRAM-Unit instead of 2 16K + 2 free places for optional ROMs).
I also found Chips with Datecodes from mid 1990 on some boards. But also 2 intel programmable Timer some from 1978

[SaabFAN]

Quick update:
I found out that the CKCDOC-Signal is vanishing, which provides a clock to the CCD-Output-Control Logic. Once that vanishes, the entire rest of the aquisition-logic stops working of course.
Search now continues to find out where this signal (generated by a AND-Gate that combines +5V and the CPU-Clock) disappears.
I suspect the processor-clock, as that would also explain the failing Memory Test.
While measuring, I also noted that the scope didn't trigger. I hope that problem is related to this problem as well, as I don't want yet another failure to fix^^

[guido]

Without main processor clock, i think the machine would be completely dead. It's generated on A6 with some logic. Connected to the XO by a pad. If the main processor keeps working, it can only be that buffer.

[SaabFAN]

I'm currently testing if one of the board causes the clock to vanish. A detailed report will follow once I'm finished with that (Adding one board after another with the CPU in Test-Mode to see if one board causes problems).
What I noticed when testing the scope so far (including all the other tests), is the fact that it seems to keep operating longer the more GND-Testpoints I interconnect with the probes. Not always, but there is a trend. Also if I fiddle around on the GND-Leads, the Scope is more prone to lockup.

[tautech]

Also if I fiddle around on the GND-Leads, the Scope is more prone to lockup.

Faulty interconnect cable? Broken cable conductor strands?
Cracked socket solder joint?
Dirty/corroded contacts?

[SaabFAN]

Also if I fiddle around on the GND-Leads, the Scope is more prone to lockup.

Faulty interconnect cable? Broken cable conductor strands?
Cracked socket solder joint?
Dirty/corroded contacts?

All the digital boards are connected via a Backplane. So the cracked Solder-Joint theory could be true.

So far the test of the Clocks on the Motherboard did yield the following result: The bare clocks on the board remain, but the trace-updates still lock up. (Took about 20 minutes).
I'm now soldering test-leads to the outputs of the 74F08 Quad AND-Gate on Unit A5 and check what's going on there, as this is currently the most likely failure-point.

[SaabFAN]

This thing is really starting to annoy me!
I checked the clocks on the boards - They are there. A bit distorted maybe, but they're there.
This leaves the Shift Logic and/or the Display Memory Unit as the most likely culprit. Although at this point, I'm not ruling out anything.

What I noticed when testing for the last 2 hours, was the fact that the scope started to act up quicker the more the display-memory was accessed. Either by the Math-Functions and especially when I install the IEEE-Option that also accesses the Display Memory.
I think, a safe bet would be to try and solve the problem with the Display Memory first.
Unfortunately, I need a logic analyzer for that. I have one of those cheap USB-Ones, but it only has 8 channels (I need 16 Channels for the address and 8 for the databus plus idk how many for status and handshake-signals) and I'm missing these test-clips. An extension-board would be nice too, but I'm pretty sure I can manage measurements on the databus without one.

[SaabFAN]

Well, I gave up!
So far I have narrowed down the problem to the A4 Unit (Display-Memory), the ACL on Unit A5 or some obscure part that also loads down the 14V Rail and does some other weird stuff and failed when the Capacitor in the PSU failed (I measured repeated spikes of up to 1,5V between GND-Testpoints on the Digital Boards).
I suspect Unit A4 because the Fault Find Routines point there.
A5 is suspect because a number of signals that vanish when the traces lock up originate here.
And the obscure part I explained above^^

Here is the ebay-Link if some of you want to try their luck with it: eBay auction: #251953449940

[dom0]

Well, you don't need to desolder cleanly. With those cheap chips you can just cut all the pins off and then solder each pin out individually, which is easy... because it's only one pin :-)

[SaabFAN]

Argh! Screw it!

I'll give this sucker one last chance! Just watched a PM3382A walk beyond my Budget and missed a PM3355 at 112€ after selling the PM3350, so I ordered some SRAMs and 74-Chips instead
I also devised a rudimentary LED and Mk. I eyeball logic-analyzer to check the address where the Memory-Test fails. The service-Manual states that the Processor will try to write/read the address at which the fault appears continuously. So in theory, the LEDs (connected to the Databus-Buffers) should show me the address.

The Saga continues! 


PS: Sorry to anyone here who was bidding on it.

[SaabFAN]

I've found a likely candidate:
Measured with DC-Coupling, the Rigol DS1054Z shows SLOT1-Line on Unit A8 to be sitting at 1,2V Average.
SLOT1 controls the Outputs of the Buffers between the Databus and the Instruction-Register DataBus, as well as the Read/Write-Mode of the Control-Memory. If I read the Schematics right, the Signal should be HIGH to set the RAMs to READ-mode and DISABLE the Buffer-Outputs.
According to the Datasheet, 1,2V is just below the threshold for Logic LOW at 4,5V Supply-Voltage. But the scope also shows a max of 1,8V on that Signal.
When the scope starts, I can see some activity on the line, probably when the Processor loads the Program-Instructions into the DPU-RAMs.

The chip generating the SLOT1-Signal is a 74HCT138 Demultiplexer, the Chips receiving the Signal are 74HCT541 and IMM2016AP S-RAMs.

There also is no CKIR-Signal (Clock for the instruction-register), as well as no SLSS4-Signal, which enables the CKIR-Signal. SLSS4 also comes from the SRAMs and with SLOT1 hanging there between LOW and HIGH, I suspect the other SLOT-Signals aren't any better.
Also I noticed all the signal-Lines on that board to have pretty high "LOW"-Levels - See attached picture.

[smjcuk]

I admire your persistence. I would have kicked it in by now.