Repairing and Upgrading an old PM3320A - Including adding FFT!

[SaabFAN]

As you might remember from the Test Equipment-Subforum, I bought a PM3320A about 2 weeks ago.



When I turned it on, it worked and showed no sign of the defects the seller mentioned.
I thought: Well, maybe nothing wrong with it afterall/transport-knocks have solved the problem.

As we say in Germany: "Pustekuchen!"
Today I finished the first part of a self-made "Almost All-in-One Bench-Tester" (Will contain Signal-Gen, LCR-Meter, Multimeter, 10W Amp to simulate Generators, etc.) that grew out of the desire to build something to sort of calibrate my PM3350, and wanted to test it with the PM3320A.
On a hunch I checked the Battery Compartment and yep: The batteries (Ni-Cd Accumulators) were done for! 300mV on the first one, 600 on the second one. And the contacts were corroded. Some time in the past, batteries must have leaked in there.
After cleaning the contacts and replacing the batteries, I turned the scope on and thats when the trouble started: I had previously observed some pretty rough calibration-waveforms when I first turned the scope on, but now that the RAM was wiped, the scope didn't start with the stored parameters, but instead started a "Auto Set"-Routine set everything up. And it hangs up during that routine.

So I opened the case and started measurements with the 5V-Rail.
The result was kinda expected: Highly contaminated with random noise: In analog-mode the trace is just a 2 divisions wide blurred green band. Digital Mode shows it jumping all over the place.
(Yes, the new LCD for the PM3350 arrived. Thx again to JohnnyBerg. I just didn't have the time to install it )

The upper trace is Channel A, which measures 5V on the Display Memory-Board, the lower one is Channel B, which measures 5V on the Processor-Board.

Next I measured the Calibration-Output: The 1Vpp 2Khz Square-Wave was horribly garbled and also modulating around something else. I suspect Mains-Frequency, but didn't measure it. Maybe I do tomorrow.
You can see how both look like in this video: https://youtu.be/oz7jPVhGgyU


At the time I have three culprits:
- Reference-Voltage (5V-Rail is regulated by a LM358 that uses the Reference to compare the output-voltage):


- 5V Regulator (Something might be wrong here, hopefully not the LM358, because its not socketed and I hate desoldering DIP-Packages^^):


- Capacitors inside the Power Supply:


As you can see, one of the Caps has what appears to be a scorch-mark. I don't have a IR-Thermometer and I won't go anywhere near that PSU when the scope is powered up with my fingers or a thermocouple, but I guess that cap deserves a treatment at the recycling plant.
I think, I'm going to replace all the Electrolytic capacitors with "Old New Stock" my dad got from Philips when he worked there 20 years ago. They are the same style and should fit without problems. He even has 2 of these big fat "Mother-of-Caps" beasts with several hundred µF and rated for over 200V


Do you guys have any more ideas where to look for sources for that kind of problem?

[tautech]

A few thoughts, no particular order:

Why on earth would you be scared of the PSU, don't you have a DMM?  Measure the voltage potential to Earth and then you know if it is dangerous or not.
Little on the secondary side should bite.

Well you can't see or conclude much @ 20 ms/div.
It seems to be a repeditive waveform, so at what frequency?
SMPS frequency would be my guess, ~40 KHz.
Smells like a cap or diode not doing it's job.


2 KHz Cal waveform ?? most unusual.

Removing DIP's.
Snip leads, remove package, desolder pins, install new package.

Scorch mark, more likely a soldering iron burn mark.
Measure the voltages across some of those caps, if not high, don't be scared to touch them and with your other hand behind your back. (no voltage path risk across your body)

I'd be reluctant to replace those fine Philips caps without reason.

IMO forget everything except getting the PSU to Service manual spec at the test points specified.
Then worry about other problems if there are any.

Keep up the good work and post your fixes. 
I've got a 3070 (100 MHz) to fix up in the next few months and all your experiences will be a welcome help, meanwhile I keep watching. 

[PA0PBZ]

Scorch mark, more likely a soldering iron burn mark.

That's what I was thinking, but then look at the lead, it's blackened. Almost as if it spilled the guts and corroded the lead.

[dom0]

Those blue axial Philips caps are notorious for failing. I'd replace them all.

[SaabFAN]

Scorch mark, more likely a soldering iron burn mark.

That's what I was thinking, but then look at the lead, it's blackened. Almost as if it spilled the guts and corroded the lead.

Yep! It literally spilled its guts. (See Picture). That cap is done!
Now I have to get the board out, which isn't so easy^^

On another note: The board n the rear plate shows no sign of corrosion. So the battery-fluid hasn't reached it.
At the moment I'm thinking that, while I'm in there anyway, it might actually be a good idea to replace the Voltage Reference Diodes and upgrade them in the process. The ones used are the C-Version of the BZX79 and the BZV12. They are both about 2% accurate, which surely can be improved with today's available silicon, right?

[Wim_L]

I think, I'm going to replace all the Electrolytic capacitors with "Old New Stock" my dad got from Philips when he worked there 20 years ago. They are the same style and should fit without problems. He even has 2 of these big fat "Mother-of-Caps" beasts with several hundred µF and rated for over 200V

Be careful, electrolytic capacitors that were left unused for many years can become very leaky. They may require reforming before they're good again. At least check them before you install them.

[SaabFAN]

Well, the cap is out and not surprisingly, it had no remaining capacity whatsoever. Instead it had resistance: Fluke stabilized at 2,5kiloOhms after about 30seconds.

So I went to the parts-box and searched: 680µF at 10V. Guess what: Not in there!  And Conrad doesn't have them in stock either.
So I took a Radial one instead. Doesn't look pretty, but should do the job. Its a Yageo (don't know if that brand is any good, didn't have anything better available) 1000µF/16V, Datecode: 11/07.
I don't know if I'm going to order a batch of caps from Farnell, or just go with the radial option for the rest of the caps. There is enough space inside the case to house the radial ones, but it won't look so pretty anymore

Soldering the board is really easy by the way. I have the iron (Weller WECP-20) at about 275°C and the leads almost come out/go in on their own. 


@Wim_L: What's the correct procedure for reforming them? Haven't heard of that before.
I have tested a few of the 1000µ/6,3V Caps with a Component-Tester from ebay (don't know how much I can trust it, but it's based on the circuit of the AVR Transistortester from the german Forum Microkontroller.net: https://www.mikrocontroller.net/articles/AVR_Transistortester). They show a bit high capacitance and 0,2Ohms ESR. Interestingly the Fluke shows OL in Capacitance Mode...

EDIT: What I just noticed: Many of the caps have copper-colored spots where the lead meets the can. Normal or sign of imminent faillure?

[tautech]

Soldering the board is really easy by the way. I have the iron (Weller WECP-20) at about 275°C and the leads almost come out/go in on their own. 

The joy of leaded solder when it comes to rework. 
Nice tidy job with the radial, you could sleeve the leads and make it better.

If you have the correct value but a higher voltage AND it fits....use it.

And because you have the PCB out AND have a cap tester, pull them all and check them.

Google "reforming capacitors"

[SaabFAN]

Update on the caps: I decided to look for replacement-parts and there are basically 2 brands: Vishay (which cost at least 1,50€ per piece) and Multicomp, which cost 0,23€, but don't fit the footprint. So it is either a quite big investment, using radial caps, or make a adapter-board out of the approx. 2 square-meters of prototyping-board and build arrays with some of the 1000 47µ/10V SMD Tantals I have from my granddad
Does anyone know a cheaper source? So far I checked Conrad and Farnell. I don't have a Mouser or Digikey account and don't know if I can get them to sell me stuff as a private customer.

I also measured some more caps: They all check out fine so far: Capacity within Spec (nominal +50%, -10%) and ESR about 0,2Ohms. About the value: I didn't have the exact Value, but the caps are all specified as "+50%, -10%", so a modern 10% 1000µF cap as a replacement for a 680µ shouldn't move the circuit out of spec. Don't know much about flyback-converters, but they seem to rely a lot more on the actual values of the components than the DC-DC Converters I am used to (Step Up, Step Down and SEPIC).

By the way: What kind of trace-material did they use? I guess copper, but its strange looking through the solder-mask: All matte black. All the PCBs I had in my hands so far had rather bright, shiny looking traces. Did they use some kind of special isolation back in the 80s?

Sidenote: While hunting for more bad caps, I found a chip on the memory-board that was made in 1978, according to the datecode. Its an Intel-Chip. Didn't google the number yet though.

[SaabFAN]

And another update:
After replacing the cap, I put it back together (had 1 screw left over  ) and powered it up after verifying that all connectors were correct and searching for the place where the one screw had to go for about 10 minutes.
It worked! The trigger had a few issues, as the seller told me, but it displayed a waveform and ran quite fine actually.
Then I pressed the "Auto" Button and it locked up in Calibration-Mode.
Cycling the power brought me back to where I started: Stuck in Auto Set-Mode and with all kinds of crazy stuff on the waveform-display.

I then checked the voltages I could reach: 7V-Rail showed 7,45V. The negative one showed -7,44V. The 5V-Rail showed 5,1V. The rest I couldn't reach with the probes of the multimeter.

With my little DS203 I then measured the 5V-Rail on the memory-board and was able to capture what looked to be some kind of 250khz-signal in AC-Mode. The analog-part of that small pocket-scope is not the best, but maybe just because of that, I was able to see that 250khz component. It was rather low peak to peak: Just 6mV, but again: The analog-part of the DS203 is pretty crappy so I don't trust measured height of the amplitudes. They claim 8Mhz, but as early as 2,5Mhz, a square-wave is becoming heavily distorted and getting more and more sine-like. At 6Mhz it also drops in amplitude.

In conclusion: The fault probably lies a lot deeper than just inside the PSU. I just hope the damaged cap, which was sitting on the negative 7V-Line, didn't drag any of the ASICs with it to the grave. That would probably mean the end of any repair-attempts as those parts are most likely out of production for 2 decades now.
What I also noticed was the temperature the digital components reached pretty quickly. Especially the ceramic-package ROMs were getting quite warm, as did the processors (socketed 68k CPUs in ceramic package with metal cover over the die). I find it a bit odd, because the CPU in my Sega Mega Drive-II is also a 68k, running at a little more than half the clock-speed and I can barely feel it warming up at all.
While I'm on the topic of temperature: The Tantal-Caps on the processor-board and the IEEE-Board were also getting a bit warm. Are those (they are drop-shaped) caps prone to loosing capacity over time too?

Attached:
5V Ripple - Measured with the DS203 on the Memory-Module

[dom0]

drop-like tantals are also very prone to failure. If they get hot they are probably shorted internally ; a common failure mode for them.

They claim 8Mhz, but as early as 2,5Mhz, a square-wave is becoming heavily distorted and getting more and more sine-like. At 6Mhz it also drops in amplitude.

That's the meaning of 8 MHz (-3 dB) bandwidth

[tautech]

drop-like tantals are also very prone to failure. If they get hot they are probably shorted internally ; a common failure mode for them.

Bead tantalums are reknown as problematic, especially older ones like yours. Either they are having to cope with excessive ripple on the rail, or are failing.
Check the rail for ripple at the leads of the known hot units to be sure.
Then remove and test for piece of mind.
Substitute temporarily if necessary for comparison.

It may be that failing tants are stressing the PSU and the main smoothing caps are struggling to manage the increased ripple from a higher than "designed" PSU currents. This may explain the high ripple on the PSU in the OP.
Detective work required. 

If it where mine I'd replace all tants with modern manufacture Bead Tants.
Watch for polarity.
Try to get a voltage rating 2x the voltage they are exposed to for long service reliability.
AFAIK They are only available to 50V rating.

[SaabFAN]

Okay, I did more measurements: The scope did work for a while btw. (about 5minutes before it stopped updating the traces) It seems that the RAM has to truly forget everything to come out of that boot-lock. But once the scope tries to go into calibration-mode, it locks up.
I attached a few pictures for you to see what it measured. Probeswere in x10-Mode during measuring.
The supply-rails are still noticeably contaminated with noise, but what I also discovered: The 10V Reference-Rail is 0,5V too high and also full of noise - About 300mV. Of course the Adjustment-Pot is right in the middle of all that high voltage-stuff -.-
The other voltages I could measure so far:
7V: 7,45V
-7V: -7,44V
5VDigital: 5,1V
10V Reference: 10,48V
I guess, this is the reason why the scope stopped updating the traces: Some part overheated. Probably the ADC.

I guess, that scope has had quite a lot of hours logged on it, so I'll probably have no other choice than to replace ALL the caps.
As Tantalums are way too expensive, I'm going to use 100µF/25V caps to replace them all. The axial Caps in the PSU will be replaced with radial ones and kept from vibrating with hot glue.
There is a problem replacing the small axial Caps though: Radial Caps won't fit and axial caps with the same specs aren't available. So I came up with a small adapter-PCB that fits the footprint and can be populated with SMD components.

Btw. the cheapest tantalum I could find with the right specs was 78cents
The cheapest Aluminium Cap I found: 4cents!

[SaabFAN]

Okay, I adjusted the 10V Reference-Voltage and the scope is much more reliable now. Although the 5V-Rail on the digital-boards is now down to 4,83 and 4,91V.
But it is kinda running now for about 4 minutes. Then the trace-updates become erratic. Sometimes it recovers, but after a few times, there are no trace-updates anymore. So I guess there is a problem with the ADC or the associated circuits, which means I have to get into the bottomside of the scope to take measurements.
Also the ADC-Chip on the A11-Unit is getting pretty hot. I can just barely touch it and the longer I leave the scope off, the longer it updates the traces.


I was able to get the Service-Mode running (Push the top and the bottom soft-button on the scope at the same time)
Can anyone with a PM3320A (Software-Version: 4.2 L. v. 0s 89-12-01) verify these Checksums?
D1724:84FC
D1726:A75C
D1727:715F
D1728:7DC5

The Software-Tests also indicate a faulty Display-RAM board - When I select the Display RAM Test, all the leds start blinking.
So there are at least 2 parts faulty or at least behaving erratically: Display-RAM and ADC.

Edit: When its cold, the Display-Memory tests "OK". I'm tempted to give it the "PC-Treatment": Add heatsinks!

And about the SMD-Adapters: Would anyone here in the Forum be interested in them too? When I order a batch at ShenZhen2U, I'll probably have a few hundred of them and I probably won't need all of them.
There will be 2 versions: Large electrolytic Caps with more than 7mm diameter and small ones that fit in the places of the smaller caps. They can be populated with 0805 ceramic caps and electrolytic caps and will have at least 2, maybe even 3 different lengths of pins available to fit as many footprints as possible. If they are too long for a footprint, the uneccessary parts of the PCB can be broken off easily.

[SaabFAN]

Okay, I think I'm going to call it on this one. I'm out of ideas.
I managed to get the excessive Ripple under control, readjust the voltages (10V Reference was 0,5V too high), recapped and added caps on the digital boards and most of the power-supply, which also brought down the heat generated in the chips, but still no luck. It works for a few minutes, then the traces fail to update.
Diagnostics-Software shows Display Memory Error, but the display-tests (which draw all kinds of patterns on the display) show no problems.
On top of that, the Service-Manual seems to be for a slightly different model: Mine has 2 Coax-Cables going into the ADC-/T&H-Board and also has 2 adjustment-pots, whereas the Manual only shows one cable and no adjustment-points.

Does anyone of you have any more ideas where the fault could be? Otherwise I'm going to sell this thing. It would be nice to get this scope working again, but I have another project I have to finish and also got to do something for the university so I don't have the time to check every little component.
The CRT is still in pretty good condition and puts out a crisp and bright picture. The front-panel has no damages and the PSU, as well as the Modules A4, A5, A6, A8, A9 and A11 have been equipped with new capacitors where feasible. So I'd say, 70€ should be a fair price.

Edit: WTF?!
I turned it upside down to reach the sandwiched boards on the bottom-side and decided to turn it on.
It now ran for about 10 Minutes and didn't stop updating the traces. I'm using my DS203 and the PM3350 as Signal-Generators and both traces display nicely and I can do measurements and everything. Display Memory-Test still fails though.
Blows my mind to be honest. I was ready to give up^^
I'll let it run for about 30 minutes now to check if there is still hope for this thing. I did spray a good amount of Kontakt Gold 200 oil onto the Euro-Card connectors btw.
There are some parts on the bottom-side that are too hot to touch by the way. The quadratic heatsink right behind the Power-Knob for example.
Because I now had a lot more time to test the scope, I also discovered that the Ground-Level receives an offset of almost +2 divisions when the timebase switches from 200ms/div to 500ms/div.

[macboy]

You should be able to calibrate out the offset. In the service manual there are different adjustments for different timebases. This is because of the way the CCD sampler works, as it samples the ground level every other sample in order to digitally compute the signal level w.r.t. ground after the ADC pulls the samples out of the CCD. I guess this is due to some drift while the samples sit waiting to be shifted out of the CCD. At slower timebases, the ADC operates directly on the input signal, bypassing the CCD.

Mine has about 0.5 division offset when switching to the slower timebase. It bothers me but I haven't gotten around to trying to calibrate it yet.

[SaabFAN]

Ah, thanks for the insight. Once I get it to actually run, I'll do that.

While poking around on the bottom of the powered scope, I managed to come across 12,58V where 14V should be.
So I ordered 8 10.000µF/16V and a few 63V and 100V Caps to replace the last few caps in the PSU. I hope that will bring the voltages back to spec and then it will be put on ebay. Found another one, which, according to the Number, has the FFT-Option installed! (I'll of course only sell it if I can't repair it or get the other one )

One thing I don't understand though: Why is the damn Display Memory failing the Memory-Test after about 30seconds after a cold start, but the display shows no graphics-glitches?

[dom0]

Display memory might not mean the frame buffer, but for example the memory of the display processor. In that case corruption can occur without any visible artifacts.

[SaabFAN]

Display memory might not mean the frame buffer, but for example the memory of the display processor. In that case corruption can occur without any visible artifacts.

You might be right about that. It would also explain, why it sometimes restarts updating the traces when I play around with the settings.
If the fault lies on one of the DPU-Boards, I have a serious problem: On the DPU Control Unit (Module A8), there is a programmable logic device calles PLS105N. It is part of the Start/Stop-Logic and generates control signals for the DPU. It also is the only chip that has a maximum Rating on the inputs of 5,5V, close to the voltages I measured when I first poked around with the multimeter.
The chip is socketed, so I can get it out and a new one in (they are available on ebay), but how do I get the programming out of that chip and into a new one?
There is also a sticker on that chip, reading: "D1457  8719.1"

[dom0]

PLS are essentially a PAL with a few bits of feedback data storage. Or, with other words, they can directly implement a state machine.

The hard part might not be to find a working chip to copy from, but rather to find a programmer capable to do so.

[smjcuk]

This one sounds like an 'FMH' job (F*** Me Harder). I've got a Tek 453 that is doing this to me. I've come across a rationale to manage effort on such things. I draw five lines and £50. I write down the problem on the first line and fix it then I write the next problem down and so forth. If I run out of budget, it gets stripped for parts and disposed of. I'm on problem 5 and £47 on the 453 now. Its hanging by a thread. Currently waiting on obscure FETs to arrive from the US. Failing that, it's a source of quality pots and carbon resistors (low parasitic inductance ones unlike modern carbon film ones).

As a side note, I've had nothing but trouble from Tek scopes. They really dont deserve the reputation they have. Might start a thread on this. And as for philips, the power supplies are total trouble as well. I worked in the TMM department at a large company and there was a stack of dead PM kit always. Usually PSU problems.

As for your problems I reckon one of the boards is probably knackered if its fixed by orientation. Not sure if they're multilayer but if they are its probably a write off.

Good luck though.

[SaabFAN]

Yeah, especially as now a functioning PM3320A/41 (the one's with FFT) and a PM3382A popped up on ebay.

The idea with the lines and the max. budget is a good one.
So far I have nailed down the problem to two places: PSU and the digital boards, probably the DPU. Because the rest of the scope seems to work fine, although the signal has a larger than unsual noise-ground, which is PSU-Related. Even when the Display-Memory-Test fails, I can select the display-adjustment-menu and it displays the different test-waveforms (with which one can adjust the huge amounts of Pots on the DAC and Amp-Board) without any problems. I'm giving this thing one more chance with the 10.000µF-Caps I ordered and will remove the old electrolytic caps (they are in blue plastic enclosures on the digital boards) to reduce possible leaking-currents - This brought down the heat-generation on the Processor and Processor-RAM boards significantly. Now the ROMs produce almost no heat at all. If it's not running, I'm selling it. I bought it for 70 and invested about 30€ in Caps by now.

[smjcuk]

Not a bad investment even if it doesn't work. At that price you can shift it for what you paid for it

[SaabFAN]

While waiting for the caps to arrive, I did some research on the PLS105-Chip I suspect to be fishy.

It seems as if that type of chip was the first or at least one of the first FPLAs and was called 82S105 for a time and produced by Signetics, as well as Texas Instruments.
The datasheet states that it is compatible with Jedec Design Software and therefore I think it should be programmable with a universal programmer.
Unfortunately, the only compatible programmer I found were the really expensive ones for 800€ and higher. Does anyone here have a programmer that could read and write that chip, or knows how to make the much more affordable TL866 compatible with that chip?

[guido]

Those PLS things loose their content.... Similar to "ROM-rot" with old Mostek ROMs.

I can read/program them (acient All-07 from hilo). I can even "assemble/disassemble" the contents. In case it is (partly) empty, that only works if you know wat needs to go in (if it is simple or well described, maybe the logic rules could be figured out). However, if that is clear you could also replace it with a more generic GAL or so.

They are also used a lot in Tek 27xx spectrum analysers (in SMD variants). But for those machines, at least somebody has dumped the contents. Maybe somebody has done that also for this one, try google...

[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.

[SaabFAN]

Well, it was sitting here in my room, waiting to be sold, looking at me, daunting: "You can't fix me!  " 
I can't have something like this.

Also a more accurate idea where the problem lies could fetch a better price on ebay, so I gave it one last shot. ^^

But now it's available on ebay again, because I had the opportunity to get another PM3320A (With FFT ) and I took it.
That one works. It's a little out of spec and needs adjustment, but nothing blew up in there and distributed the faint smell of magic smoke everywhere.

FFT is apparently only added via Software btw. The A10-Slot in the working unit is unpopulated.

[macboy]

...
FFT is apparently only added via Software btw. The A10-Slot in the working unit is unpopulated.

Interesting. Do you have an programmer to dump and compare the ROMs? I wonder if swapping ROMs from an FFT unit would be all that is necessary. It could also be as simple as a jumper on the PCB. CPU reads the state of an I/O pin or two and sets options accordingly.

[SaabFAN]

No, but I'm planning on buying one of these TL866 Universal programmer-thingies from China next month.
I can't read the programmable logic chips with those, but they basically can read and write 99% of all the available types of EPROMs.
Once I have it, I'll create som ROM-Dumps.

On the CPU-Board, there also are 5 Jumper. 4 are being used to set normal operation or testing-modes. The 5th one isn't explained in the Service Manual.

[dom0]

I can't read the programmable logic chips with those

Thinking about it only the software is missing but I never tried (yet) to create a new IC definition for it.

[SaabFAN]

What needs to be in the IC-Definition? Voltages, Position of I/O-Pins and Supply-Pins? Anything else?

Reading the programmable Logic Chips might be a bit difficult though, even if an IC-Definition exists and the TL866 can access the chip: The ICs have protection-fuses that prevent the readout of their program-memory if set. If Philips has set those fuses, the only way to get the content of the memory would be to try all possible combinations of inputs, keeping the internal registers in mind (Previous State and Next State) and record the output.

By the way: The Programmable logic ICs in both Oscilloscopes have been programmed with a program from 1987.
Seems like the programmable logic remained the same throughout the production-cycle and only the Software for the 68k-Processor was updated.

[dom0]

What needs to be in the IC-Definition? Voltages, Position of I/O-Pins and Supply-Pins? Anything else?

The software will also need some kind of protocol definition to know how to read or write bytes. If I were to write a programmer software I'd separate protocol and devices using them into separate entities, there is also an open source software for the TL866 around so you'll probably gain some insight there.

Regarding trying to reverse-engineer the PAL contents this should be possible with the TL866, too, since it's essentially just an I/O interface with some perks (programming voltage generator etc). But you'd probably need to roll your own software for that.

[SaabFAN]

I have now received the TL866CS and am about to open the Scope (the Okay one) again to get to the ROMs and download the images.

Question now: Where can I upload the ROM-Dumps? The scope is 25 years old, so the Software inside could probably considered as Abandonware, but I'm not sure if that is enough to put a zip-file here.

[dom0]

http://www.ko4bb.com/manuals/

[tautech]

http://www.ko4bb.com/manuals/

+1 

[SaabFAN]

I just uploaded the ROM-Binaries. They should be available shortly on KO4BB.com.

The Firmware-Version of these ROM-Files is 4.1 for both the Scope and the GPIB-Module.
The Chips are 27C010 on the GPIB-Module and 27010 on the Processor-Module. There are 2 EPROMs on the GPIB-Module and 4 on the CPU-Module.
I couldn't read the PLS-Chips and the GALs though; My Programmer is not advanced enough for that (a TL866CS).

From what I learned during the repairing-attempt, the FFT-Option is added via Software only. So programming any PM3320A with these binaries should add that functionality.

[tautech]

I just uploaded the ROM-Binaries. They should be available shortly on KO4BB.com.

From what I learned during the repairing-attempt, the FFT-Option is added via Software only. So programming any PM3320A with these binaries should add that functionality.

Do you think it is a FFT switch/option to be enabled from a "service" mode?
That is, options are all installed in software to be enabled in Service mode or with SPI commands as many scopes are. 

[SaabFAN]

I don't think so. There are only EPROMs on the boards as Non-Volatile Memory. And the Service-Manuals show no 12,5V Supply for programming the EPROMs or any other circuitry able to do that.
The only way to add FFT seems to be reprogramming the EPROMs.

[SaabFAN]

It should be possible by the way, to upgrade the earlier models to the later ones. The Service-Manuals show some differences, but the basic circuitry remained the same. It seems that all that is required to upgrade to the later versions is the addition of 2 ROMs (And all 4 ROMs programmed with the right software of course) on the CPU-Board and 2 RAM-Chips on the MRAM-Board.

[Stonewerk]

Hi! I'm new to the board, and I thought I'd report on the status of my firmware upgrade attempt (using the files uploaded to ko4bb by SaabFAN) and to seek assistance with an associated problem...

Firstly, my PM3320A is model PM3320A/80 - rack mount, with the GPIB/RS232 option installed - and was manufactured late 1988 (from IC & firmware date codes). The original firmware, as indicated by the service menu, is V02 G. v. 0s 88-05-18.

I successfully programmed and installed the 4 CPU ROMs, and the service menu now indicates f/w version FV4.1 L. v. 0s 89-05-09 with correct checksums for all 4 ROMs. So, at least initially, everything seemed fine.

However, when I traverse to the MATHEMATICS menu, the Histogram and Filter selections are there, but F.F.T. selection DOES NOT APPEAR. (I cannot recall if the histogram and filter selections were available with the old firmware, and I haven't reinstalled the original firmware to check.)

Other comments: The MRAM (A5) board is fully populated (HM62256 x 4), so I don't believe memory is the issue. Also,  I did not update the firmware on the GPIB/RS232 board, as I didn't think it's relevant.

I am hoping this is a user issue, and that I'm not using the menu correctly.

The following is an example of the procedure I am using to attempt to access the FFT function:
1. Apply scope CALibrate signal to Channel A.
2. Press AUTO Setting
3. Select CURSOR
4. Select MATHEMATICS
5. Select MORE

The HISTOGRAM and FILTER selections appear, but the FFT selection does not. (If I repeat the procedure with the signal applied to both A and B channels, the DELAY CHAN option appears, as expected).

What am I doing wrong?

[SaabFAN]

Have you checked the Checksums of the ROMs?
On my scope they are:
D1724:4CEC
D1726:A422
D1727:2961
D1728:F10F

Can you also check the PLS-Chips, or essentially any chip with a sticker on it and post pictures here? If they were evil at Philips, they programmed some kind of switch inside those chips that enables/disables the FFT-Function. But I doubt that.

[Stonewerk]

I did confirm that the ROM check sums match - the parts programmed  correctly, and the CPU ROM images that you uploaded  to ko4bb are 100% correct.

There are 2 PLDs on the A5 MRAM board; I'd expect that the labels on the 2 Signetics PLS105F devices are different from yours at least by merit of manufacturing date. I don't think that there's anything we can conclude from this, short of (not) being able to actually read the devices.

I agree that a PLD implemented feature "switch" would be evil, but then again, that would be characteristic of an "active" marketing organization, eh?    I do hope this is not the case....

Nevertheless, on the A6 CPU board, there are a number of jumpers - and unused jumper positions  - that merit comparison.

((( This is my second attempt at posting a reply. In my original reply, I had attached detailed images of the 2 PCBs, without noticing this forum's stringent file upload size restrictions. The 5 images were ~4000kb each.  I've reduced the images for upload, hopefully without losing detail...))))

[SaabFAN]

So far I can't see any difference between my Scope and yours. Apart from the warning-sticker (on my unit it is in english ). The jumpers on the board set several Debug/Test Modes and Turn On/Off the Watchdog-Timer.

The FFT-Function should appear at the second spot down from at the side of the screen.

Unfortunately I am currently busy with a University-Project, so I don't have the time to compare the stickers on the MRAM-Board, but I think they were also identical to yours.

The only thing I could think of now is the DPU and DCU-Boards (Units A8 and A9). Those two form a programmable DSP, which might be responsible for at least some of the calculations.
Did anyone else here try to upgrade a PM3320A to add FFT-Capability?

[SaabFAN]

CORRECTION!
I had the image of the PM3320 Service-Manual in my head and just looked over the schematics for the PM3320A again: There are 2 PCB-Jumper that seem to be located on the backside of the A6-Module. These 2 Jumpers decide how the 3 Lines UPAB17 - UPAB19 are are connected to the addess-decoder that controls the 2 lines SLRO0 and SLRO1 that connect to the Chip-Select lines of the SRAMs.
The Service Manual for the PM3320A even states: "If software releases with 64k x 8 ROMS are used, then the soldering joints J1701 and J1702 should be changed over". As my ROMs are 128K-ROMs, I guess the 64K-ROMs are the version without the FFT and other stuff.

So I'd suggest changing them and see what happens.

[Stonewerk]

I have repaired both models,  the PM3320 and PM3320A hardware are sufficiently different to merit having service manuals for both models. (This statement made for the benefit of those reading this thread, and not SaabFAN - who's already been through all this...)

Anyway, the original firmware (V2) in my unit is on 128k parts (27010), so the trace jumpers should already be correct. I've attached an image of the relevant area on the back on my A6 uP Board - it should match your board.

A question just occurred to me -  is there a board installed the A10 position (Option 2) of your PM3320A? There is none on mine.

[Stonewerk]

Oops! I just reread the thread, and see the answer in an earlier post - A10 is unpopulated in your unit, too.

Hmm, if there is a change in a PLS device, that's a bit problematic. I don't have anything in my lab that can read or program PLS105/82S105 PLDs (PALs and GALs - yes - but not the PLS') , but I may be able to get access to a compatible programmer from my former cohorts in engineering.

Can you get access to a suitable programmer over there - perhaps in you university EE department?

[SaabFAN]

Unfortunately, I am studying 3D Game Art, which is pretty far away from anything related to EE and my university has no engineering department (I'm studying at the SAE). So no luck there.
And I don't know who to ask at the big universities here (Universität Hamburg and Hochschule für Angewandte Wissenschaften). But maybe some other people here in the Forum know the right people to ask

[Stonewerk]

Okay. At this point, I'll consider the issue closed.

Without further input from those who have attempted the firmware change, the following conclusions are drawn from this experiment:

• Replacing the v2 firmware with the v4 firmware is practical -  the scope  powers up and passes its self test without error
• Some minor functions are added with the firmware change, e.g., the ability to change cursor markers from a "+" to "x".
• However, the firmware change alone fails to  enable the FFT math function.
• No detrimental impact to scope operation has been observed.

In my opinion, without a documented revision history, the benefits of upgrading the firmware are unclear. The differences appear subtle, with no performance improvements (nor degradation) noted. In other words, the change is likely unnecessary. On the other hand, I have not (yet) performed a comprehensive differential comparison.

Nevertheless, I would not expect the manufacturer to make firmware changes without significant purpose(s) - e.g., bug fixes, accuracy improvements,  additional functionality, etc.. But again, these are unknown.

I would encourage other owners of a PM3320A with older firmware to perform the firmware "upgrade" and to relate their findings here, noting any quantifiable differences. 

Meanwhile, I think we all owe SaabFAN a big ol' hunk of gratitude for taking time out from his studies to make the effort to post the  firmware images from his scope!

By the way, if anyone has - or knows where I can get - an extender card for this scope, please PM me. Thanks!

Danny Stone
Folsom, CA
USA

[SaabFAN]

I think the best way, and probably the cheapest, is to get some Europa-Format Vero-Boards with provisions for 96Pin-Connectors and build one yourself. Buying such cards is, at least in Germany, crazy expensive (over 100€ for such a card).
I found 96pin-Connectors for 5 to 9€ on ebay.

An alternative, which could also feature measurement-points, would be to design a PCB in Circuitmaker (or any other CAD-Software without limitations on size and Pin-Count) and let one of the cheap chinese manufacturers produce them. Shouldn't be too expensive and you have several boards to test several modules at the same time or sell those you don't need.

[tautech]

.
An alternative, which could also feature measurement-points, would be to design a PCB .....

I've done this on old CRO's with plugins and used ex PC IDE cables for the extender chopped up to suit.
You just need to identify the power terminals and ensure conducters are heavey enough to carry the current. 1 mm² should normally do the job.
The only other tricky bit is identifying and finding the correct socket.

[SaabFAN]

The traces on the boards are all pretty thin, so IDE-Cables should be able to handle the currents.

On another note: How much noise does your Unit show, Stonewerk? I get pretty consistent 1,2mV of noisefloor in all timebase-settings at 5mV/div. I don't know if that is good or just at the corner of going bad, but my Rigol DS1054Z has about 600µV of noise at the fastest timebase and increasingly higher noise at slower timebases.

[Stonewerk]

Actually, ~ $100 for a high quality, multi-layered extender card for boards of this size is not unreasonable.

As you're aware, the connectors are not the issue.

A good extender card should have good power/ground planes, guarded signal routing, etc. so as not to introduce further problems into the signals that you are testing/adjusting.

Yes, I've considered this route, including sourcing for the connectors (not an issue) and executing a suitable layout. However, fabrication with a trusted (i.e., quality) vendor does place the price significantly below $100.

And at this stage, I don't want to execute a group fab / sell deal - 'been there, done that, and was really a giant pain in the hintern 

The main issue here - across the pond - it that it's difficult to find really *any* accessories for this 'scope.

I think the best way, and probably the cheapest, is to get some Europa-Format Vero-Boards with provisions for 96Pin-Connectors and build one yourself. Buying such cards is, at least in Germany, crazy expensive (over 100€ for such a card).
I found 96pin-Connectors for 5 to 9€ on ebay.

An alternative, which could also feature measurement-points, would be to design a PCB in Circuitmaker (or any other CAD-Software without limitations on size and Pin-Count) and let one of the cheap chinese manufacturers produce them. Shouldn't be too expensive and you have several boards to test several modules at the same time or sell those you don't need.

[Stonewerk]

Good? Bad?

From my perspective as an engineer, an answer to your question "depends' and can be a bit complex, and my first statement would be an inquiry into the instrument settings, configuration, terminations, exactly how you're making the measurement and interpreting the results. Also, I'd inquire about the type and characteristics of the signals you're measuring, the equipment and environment you're measuring, your test objectives, etc.) But that's not what you want, eh?   

Some people have said that  I look like Yoda, so I'll say, "Not what is good, not what is bad, but what is." The application the suitability is... 

So I'll make some assumptions and answer this way:

• With nothing connected (no signals, probes, etc.), I press "auto" and let the unit autoset.
• After the routine completes, I set the displayed channel (A) to maximum vertical gain - 5mV/div - and minimum timebase (5 ns/div).
  
• Other Vertical / Horizontal settings are unchanged.
• The observed peak variation in the trace height is not significantly larger than the trace itself, (which is around 1/10 division, approximately 0.5mV), therefore something around 0.5 - 1mV peak-peak.
• Enabling channel cursor and select Measure. Amplitude, Peak, the peak value varies from about 0.97mV to 1.17mV.

Is this what you're asking? I'd deem the performance of this parameter is quite reasonable.

The traces on the boards are all pretty thin, so IDE-Cables should be able to handle the currents.

On another note: How much noise does your Unit show, Stonewerk? I get pretty consistent 1,2mV of noisefloor in all timebase-settings at 5mV/div. I don't know if that is good or just at the corner of going bad, but my Rigol DS1054Z has about 600µV of noise at the fastest timebase and increasingly higher noise at slower timebases.

[Stonewerk]

The following is an addendum to my earlier comments, regarding the PM3320A firmware images posted to K04BB by SaabFAN:

I have also made a cursory test of the ROM firmware for the PM8956A (A7 IEEE/RS232 Option Card).

After updating and testing the CPU firmware to v4.1, the existing firmware for the IEEE/RS232  was replaced with the newer firmware. Operation with the new firmware appears unaffected, meaning that original functionality does not appear to be adversely affected. However,, no new functions or options appear, nor have any performance improvements been observed. As before, a comprehensive differential comparison has not yet been performed.

Note that it was not necessary to update the IEEE/RS232 firmware. The original (B744.1, B743.2) PM8956A firmware seems be to compatible with the updated (v4.1) CPU firmware, without any operational or performance issues (with the caveat regarding depth and breadth of testing, etc.)

The check sums for the updated IEEE/RS232 ROMs, posted by SaabFAN:

D112: E709
D113: 7C10

The compatibility of the new IEEE/RS232 firmware was not tested with the older (v2) CPU card firmware.

This completes my initial assessment of the newer CPU and IEEE/RS232 firmware. In summary, it appears that the new firmware is compatible with older hardware as noted (see earlier posts for details) although enhancements and improvements appear to be limited.

I am now operating my PM3320A with the updated firmware for both the CPU and IEEE boards as provided by SaabFAN. If any issues are found (or significant improvements observed), I will post them here.

[SaabFAN]

Yes, that was exactly what I was doing on both units to observe the noise-floor of about 1.2mV.
Given that your unit has pretty much the same amount of noise, I don't think that a complete Recapping of the PSU will be necessary any time soon. But I have a lot of SMD Tantalums available in my part-boxes and from the defective scope I know that these caps fit almost perfectly

About accessories: I think the only accessory worth getting are probes with a Sensor-Ring to tell the scope if the 10x-Attenuator is active or not. And maybe an RS232-Cable. Software, if you can even find some, is probably unable to run on anything but MSDOS, but I have seen drivers for the PM3320A on the National Instruments website. But I guess the prices for Software from that place can pay for an entire lab-setup
Do you have the RS232/GPIB-Manual btw.? It holds detailed information about how to communicate with the PM3320A, as well as all commands available. They even put some examples for driver-programs in there!
I have also thought about using an Arduino to build some kind of a digital Plotter, but stopped that project for the moment, because for now taking pictures with my smartphone is still good enough

[SaabFAN]

I just had enough of modeling and texturing for today and opened the scope to make pictures of the boards.
They are a bit big though, so I had to upload the High-Resolution Pictures on google: https://goo.gl/photos/jmf11acvXfQHRyx69 The pictures attached here have reduced resolution.
Unfortunately, I haven't seen anything that would point towards a hardware-switch for the FFT-Function. The only thing that I noticed is a diode that connects from Pin 9 of D1723 to Pin 11 of D1746.

About the noise: I just recognized that it increases linearly when I increase the V/div. The Rigol doesn't do this, which leads me to believe that the noise comes from either the analog circuits or the Track&Hold-Circuits in front of the ADC.
The Service Manual also doesn't state any noise-standards, but states an error of 2 to 3% to be within spec.

[SaabFAN]

And more pictures.
Again no obvious Hardware-Switch, but as the Philips Engineers decided to put the Trigger Address Comparator (part of the DPU-Control) the MRAM-Unit, I wouldn't be suprised to find the switch on an entirely different board^^

[Stonewerk]

Yes, that was exactly what I was doing on both units to observe the noise-floor of about 1.2mV.
Given that your unit has pretty much the same amount of noise, I don't think that a complete Recapping of the PSU will be necessary any time soon. But I have a lot of SMD Tantalums available in my part-boxes and from the defective scope I know that these caps fit almost perfectly

I agree.... I don't think they'll be any improvement, and the chance of something breaking - becoming broken - rises dramatically   

[Stonewerk]

...
About accessories: I think the only accessory worth getting are probes with a Sensor-Ring to tell the scope if the 10x-Attenuator is active or not.
...

IMO, the probe attenuation display's not a big deal, and you'll likely get along fine without it (i.e., it'll be pretty obvious when readings are 10x or 100x off...) It's set by a fixed resistance between the sensor ring and ground. If you want, I 'll provide details (I need to look it up - I hate quoting off the top of my head and giving wrong values...)

Less for the display, but especially for performance, it's HIGHLY desirable to have probes that are designed specifically to  match the characteristics of the vertical amplifier for which they're matched. That said, it's ridiculously difficult to find '3320 accessories on this side of the pond, unless one's willing to pay out of the traditional orifices... 

[Stonewerk]

Do you have the RS232/GPIB-Manual btw.? I

The part number for the RS232/GPIB interface is (Philips) PM8956A/01 or simply PM8956A (search key). Yes, I have a scan, but I can't remember where I downloaded it from - I thought it was from K04BB, but I can't find it on there, now...

SO I just uploaded the manual to KO4BB. If you can't wait for the document to show up, PM me and I'll happily email you the manual.

[Stonewerk]

I have also thought about using an Arduino to build some kind of a digital Plotter, but stopped that project for the moment, because for now taking pictures with my smartphone is still good enough

Camera/phone etc. is easiest (and quickest), but if you want a plot, it's really easy and you probably already have what you need! Basically, (I'm assuming you're familiar with connecting and configuring RS232 - if you're not - PM me):

Setup Computer:
1. Connect the scope to your pc via the RS232 interface.
2. Bring up a terminal program on your PC - I use Realterm, available on SourcefForge. Configure it to capture data from the port.

The transfer will be HPGL commands, so text capture is fine. I suggest 19.2k 8N1 for the interface parms.

Setup PM3320A:
RS232 interface first:
3. Select Display DISPLAY / OPTION / INTERFACE / RS232-C
4. Config to match PC FRAME, OUTPut Speed, INPut Speed (19k == 19.2k)
Setup Plotter next:
5. Select Memory SAVE/PLOT / SELECT / DIGITAL / PLOTTERS, then choose one of the HP plotters (doesn't matter which...)
6. RETURN / PLOT (This may already be selected by default)
7. RETURN / RETURN (To get back to main SAVE/PLOT menu)

Now you're ready to plot!
On PC:
8. Begin port data capture.
On PM3320A:
9. Select DIGITAL (This is at the top level of the SAVE/PLOT menu, it should display PLOT R0 in the middle of the menu bar)

The plot should begin immediately, with a ***PLOTTER ACTIVE*** at the bottom of the screen, and data should be transferring to the PC.  The scope will display (be patient, this'll take a few minutes) A message will be displayed when the plot is complete.

On PC (when plot has completed):
10. VERY IMPORTANT: End the capture, and SAVE the captured file.

You know have an HPGL file containing your plot. You can view this with an HPGL viewer, such as HPGLView, and or send it to your printer (if it handles HPGL), or do a screen capture from the viewer.
 
The process sounds complicated, but it's really easy and intuitive once you do it... It helps to have the manual, of course....

I've attached a sample plot below - text file from the capture, and a jpg from a screencap of the HPGL viewer. The display is the CAL connected to Ch A. (Quick and dirty - I haven't configured pens, etc.)

[Stonewerk]

...
... terminal program on your PC - I use Realterm, available on SourcefForge. ...
...
....is with an HPGL viewer, such as HPGLView...
...

Sources:
Realterm: http://realterm.sourceforge.net/
HPGL_View: http://service-hpglview.web.cern.ch/service-hpglview/hpglviewer.html

I'm very pleased with the operation of both of these utilities...

[Stonewerk]

... Software, if you can even find some, ...

Controlling the scope through the RS232 interface is relatively straightforward - when you get the manual, it'll become clearer.

I wrote some simple scripts to setup and capture data from the scope via the RS223 i/f, and a utility to convert the data to CSV format to import in Excel. Then I use Excel to perform analysis on the data, such as FFT, etc.

I posted a separate thread on the forum to inquire how others are making use of the IEEE/RS232 interface - no replies, yet, just lurkers...

[Stonewerk]

...
Then I use Excel to perform analysis on the data, such as FFT, etc.
...

I've attached one of my Excel files - this is a 2 channel FFT data analysis, with a sine wave on one channel, and a square wave of the same amplitude and frequency on the other. This is a good example, as it shows how to process data from both channels. There are seven tabs (worksheets) in this file, the first containing the scope display plot, and the last containing the FFT analysis. The sheets in between show the underlying progression... 

I'm posting this to help users realize that they are not limited by the math functions provided on the scope... 

[SaabFAN]

Okay, I'm going to revive this thread to have everything about the PM3320A repairs in one place here.

I'm currently waiting for the first board-revision for my bachelor-project and have some time on hand to do some maintenance on the big boat anchor.

The main problem is: It is drifting A LOT!
Another problem: The GPIB isn't working, but RS232 is running flawlessly (the biggest issue: Get the PC to cooperate ).
Third problem: The clock is wrong several seconds after a few hours and leave the scope off for 3 days, it is out by a several minutes.

The drifting is especially noticeable when the instrument is cold and starts warming up. The high speed mode, which utilizes the CCD-Chips, and the low speed-mode drift apart and also the measured values drift up to 0.7 divisions.
I've used the internal tools to check the alignment of the screen and that stays rock solid, so no problem there.

This means, the problem is sitting on the big main board in the bottom of the unit, which is a really massive board.
By now I've recalibrated the unit about 6 times and it takes only a few days for some drift to become noticeable. The drift from cold to warmed up is there from the beginning, but that's to be expected.

What I suspect to be the source of the problem: The potentiometers. They don't look like they're sealed, so most likely dust and other stuff crept in there over time. Especially because they're right in the airflow-path. They're also really twitchy when trying to adjust them.
Is there some way to clean those with some chemicals/oils, or are carbon track-potentiometers uncleanable and need replacement?

[tautech]

What I suspect to be the source of the problem: The potentiometers. They don't look like they're sealed, so most likely dust and other stuff crept in there over time. Especially because they're right in the airflow-path. They're also really twitchy when trying to adjust them.
Is there some way to clean those with some chemicals/oils, or are carbon track-potentiometers uncleanable and need replacement?

You mean preset pots right ?
Unusual that they impact on drift but yes old ones can be sensitive to adjustments.
When I find this I give them a good workout that helps the wiper contact to the track. Skeletal presets can be a mongrel in this regard and it's not unheard of that replacement is needed.

WRT drift, have you monitored the PSU voltage and ripple as the unit warms up ?
Tired caps ?

[dom0]

carbon track pots can be cleaned with brake cleaner, but not on the PCB. I find it easier to just replace them when I have to get them out anyway.

[bd139]

Interesting thread. I had the predecessor of this unit for a bit, the PM3315. The same CCD capture device in it but was a lot less fancy. Terrible aliasing problems and noise and the mains filter exploded. It drifted too. Never got to the bottom of that. Most complicated scope I’ve ever seen inside. When I got it, the PSU was tripping instantly. Turned out to be one of those blue axial Philips caps on the motherboard. Replaced it with a Vishay/BC unit (direct descendent of the original) and it sprang into life.

Couldn’t stand the bloody thing so got rid of it.

[SaabFAN]

I've spent yesterday troubleshooting the GPIB-Board.
All the electrolytic caps were bad (Capacity about 100µF instead of 220 and between 1 and 4 Ohms ESR), so I replaced them.

Afterwards I ran the built-in tests and discovered that the RAM-Test fails.
So I desoldered both chips and checked them with the TL866 programmer. Both got a clean bill of health. Not sure what's going on there... Serial communication works - I can plot screens and it understands and reacts correctly to the commands i'm sending.
Supply-Voltage on the GPIB-Board is 5.06V, which shows basically no drift from cold to warm.


The other issues, regarding calibration-drift, are probably related to bad caps. Out of curiosity I soldered 330µF caps in parallel to the 100µF caps on the +/-15V Rail on the ADC-Board and got a significant reduction in noise. So I'm going to replace all the capacitors and, if I can find replacements, the potentiometers.

[SaabFAN]

I have replaced all the electrolytic capacitors on the ADC-Board.
Just ONE measured ok (Right capacity, ESR lower than 1 Ohm).

Unfortunately, I managed to install one of the caps (C664) backwards across the negative supply of D616. At first the signal drifted upwards on the screen, but now it is always at the top of the screen and the signal seems to disappear after R719. The Outputs of D616 stay at 1.5V and the ADC sees a constant 7,5V at its input.

I suspect that the wrong negative supply somehow killed the multiplier, which would be quite bad, as I havent been able to find that part anywhere on the net. Not even datasheets are available...

Transistor V621 tested ok and the transistor-tester showed a hfe of about 370.

Would it be possible to replace the multiplier with some other part?

[SaabFAN]

After a day of tinkering, I've managed to get the trace back on the screen - The -14V Rail was gone because a resistor failed open. Most likely because of mechanical stress due to it sitting right next to the Mainboard-Connector.
But there's still no signal going from the CCD-Board to the ADC.

Right now, after unsoldering and socketing the Multiplier-Chip, I'm not so sure anymore that that chip is dead. All the PN-Junctions are ok (0,7V in one direction, open in the other).
I'm not familiar with analog multiplier-circuits, but I think it might be possible that I misinterpreted the measurements and there won't ever be any voltage-change at Pin 17 of D616 because the signal is represented as a current going either into Pin 17 or through V621.
The fact that Pin 15 was constantly sitting at +1,5V might have been caused by the missing -14V-Rail (-14V-Rail was at +2,8V).

I have also discovered that the coaxial cables have seen way better days. The plastic inside feels stiff and can be much easier damaged than the stuff inside the cables I'm used to. I've also discovered that the center connector of the cable sending the CCD-Data to the ADC had broken off and was just barely making contact the entire time. And the shield seems to have never made contact with more than one tiny wire.
So if I'm able to get what's left of the issues with the ADC-Board sorted out, that cable has to go too.

[SaabFAN]

I finally got it working again.

The Multiplier-Chip didn't go bust and the last problem was the coaxial cable that broke about 4cm from the board. 

Now I have to replace the caps on the big board on the bottom and then recalibrate the entire unit. Right now I have 3 divisions difference between direct and P2CCD-Mode.

[bd139]

Keep up the good work  . Sounds like good progress!

[SaabFAN]

Yes, now that I have (kinda) understood how the circuit works, I realized that I chased ghosts for the better part of the day and completely unecessary desoldered the multiplier. 

With a bit of luck, the big CCD-Board and the Managment-Unit, as well as the frontend will react a bit more kindly to the maintenance-work

[Bashstreet]

If not already after visual inspection of the whole scope i would go and measure all the resistors as matter of course in such equipment.
Also i would change if not all at least the smaller caps close to any heat source.

Good quality electrolytics are fine unless you want to spend some money.

Sorry to jump in like this if what i am saying has already been evaluated my apologies.

[macboy]

Interesting thread. I had the predecessor of this unit for a bit, the PM3315. The same CCD capture device in it but was a lot less fancy. Terrible aliasing problems and noise and the mains filter exploded. It drifted too. Never got to the bottom of that. Most complicated scope I’ve ever seen inside. When I got it, the PSU was tripping instantly. Turned out to be one of those blue axial Philips caps on the motherboard. Replaced it with a Vishay/BC unit (direct descendent of the original) and it sprang into life.

Couldn’t stand the bloody thing so got rid of it.

I had never known about the PM3315. That bears little resemblance to the PM3320A. Notably, the PM3320A has aliasing detection that actually works. A warning LED "lights if the sampling frequency is smaller than twice the trigger pulse frequency". Actually, I really like my PM3320A. Clearly, it was a very capable machine way back when, and served me well until I bought a more modern (still >15 year old) Lecroy. I still like its razor sharp CRT and high resolution rendering of waveforms.

Although the PM3320A is rated for 200 MHz and 1.75 ns rise time. I measured mine at 375 MHz (-3 dB point) and < 1.2 ns rise time.  That's nearly double the specified bandwidth! Combined with the 10 GS/s at the fastest time base, it's a capable sampling scope, if you can deal with its limitations (especially 4k sample memory).

I hope SaabFAN is successful in the repair, it will be a useful instrument in the end.

[bd139]

The PM3320 was a generation more advanced than the PM3315 so that's not surprising really. The 3315 had a considerably less powerful 8085 embedded system in it which couldn't do anything fancy other than reproduce the data it had captured. Also no readout which is why the front panel was slathered in displays and controls. The internal construction is about the same; the PM3315 was a large analogue board on the base with a whole rack of cards inside it.

There's a paper on the PM3315 design here: http://www.extra.research.philips.com/hera/people/aarts/_Philips%20Bound%20Archive/PTechReview/PTechReview-40-1982-055.pdf

I found some pictures of the guts of mine:

[SaabFAN]

That kinda looks simple and easy to understand, compared to the Monster the PM3320A is.

They even made an upgraded Version: The PM3323, which had more sophisticated software, 500MS/s and 300MHz analog bandwidth.
While they used through hole with SMD-Chips on breakout-board like modules in the PM3320, the PM3323 used a mix of SMD and Through Hole on the main boards.
Unfortunately, I didn't have enough money today, otherwise this thread would have covered the PM3323 too (someone just sold one on ebay, which looked like it had terrible noise - almost always because the SMD-Caps have dried out).

Most of the same technology was also put to use in a 2GHz Scope: The PM3340.
That one is restricted to RF-Stuff though, as the inputs can only tolerate 5V maximum if I remember correctly.

Back to my unit: I've just finished the calibration-process as well as I could with what I have available here (Feeltech FY3224 Signal Gen, Rigol 1054Z). Really complex procedure to calibrate the P2CCD-Part, which slows down the fast signals arriving at the instrument.
What I find really interesting: Add, Inverting, MIN/MAX-Mode are done in the analog domain. This makes it stand out from the other scopes of thze time, but also adds massive amounts of potentiometers and components to the boards, wich are stacked in several layers on the bottom of the instrument.
The analog parts didn't drift that much btw. Only the CCD-Part required a rather comprehensive adjustment after which the rest was almost immediately in spec, so I didn't go through the whole process of adjusting the analog frontends. Partially because the signal generator leaves a lot to be desired.

So far, I'd call the work on the scope done for now. I've recapped the PSU when I got the unit and recapping the ADC-Board reduced the noise level significantly and about to the same level present in my Rigol.
Tomorrow I'll post some more pictures and I might even be tempted to make a video, explaining the calibration-process

Btw. If anyone here has a PM3323, I'd love to buy it. Or at least post some interesting pictures and give a short review - These Philips-Scopes are kind of underdogs here it seems and they feature really interesting technology.


Also, I'm kinda curious if it is possible to replace the processors with 68010 CPUs, which are pin-compatible but not 100% software-comptabile.
To this end, I'd like to examine the Firmware to see if the Firmware makes use of the instructions that don't work with the newer CPUs.
I haven't found a good script to combine the ROMS yet, however. And a good 68k Disassembler seems to be either very expensive, or unable to create "readable" Assembler-Code

One more addition, just FYI: The datecodes in the digital section range from 84 to 91 (not counting the GPIB-Board, as that looks like it hasn't been installed in the factory - board has kinda different color).

[SaabFAN]

I've attached some pictures of the ADC-Board and my solution to repairing the broken 1 Ohm Resistor, as well as the socket for the OQ0146, which can be found basically everywhere on the bottom side btw.


Also some high res (well, as high as my Nexus 5 can go ) photos of the bottom boards and the sample clock generator-board:


Vertical amplifiers.


P2CCD Chip - The SMD-Soldering looks kinda strange on the picture, but doesn't look like that in reality.
I'd say the board was reflowed, btw. because there are no pads to suck solder away from a solder-wave.


The analog processing board. The potentiometers calibrate gain, offsets, MIN/MAX-Mode, etc.


Sample Clock generator. This board creates a 100 MHz and 125 MHz clock (the two oscillators with the crystals), which can be doubled or divided to get the desired sample-rate.
Unfortunately, the Scope doesn't show the sample-rate on screen.

[bd139]

That’s an absolutely beast!  Thanks for posting the pictures.

I’ll let you know if I see any of these scopes floating around.

[SaabFAN]

I've installed a MC68010R10 processor on the processor-board now.
So far the scope-software seems to be stable, but the speed didn't really improve.

Only the Multiply and Divide function felt a bit faster. I've yet to analyze that on the video I made (which would be expected, as these operations work faster in the MC68010).

FFTs are maybe a tiny bit faster, but half or three quarters of a second faster doesn't really matter.

With aquisition running normally and updating the trace on the screen (with which the CPU has almost no involvement) it took about 15 seconds with the old CPU and 14 with the new one (varies by about half a second) to perform FFT on a full sweep (4k Samples).
With Aquisition stopped, FFT took about 10 seconds with the new CPU. I didn't took any measurements with the old CPU in this mode however.

Unfortunately overclocking is out of the question, as the Clockgenerator for the CPU also generates the base clock for the rest of the scope.
Locking that clock to an external reference would be cool though. Between the card-cage and the PSU is enough space for a PLL-Board and the back has enough holes for the BNC-Connectors

[macboy]

I've installed a MC68010R10 processor on the processor-board now.
...
Unfortunately overclocking is out of the question, as the Clockgenerator for the CPU also generates the base clock for the rest of the scope.
...

Don't be so quick to discount overclocking on this beast.

I've had a good look at this thing and the 68k architecture. Honestly, it should be easy to improve performance, maybe very substantially. The main reason it that the 68k uses an asynchronous bus. So instead of having a pre-determined number of wait states hard-coded into the firmware for things like ROM or RAM access timing, it uses a handshake. When reading or writing RAM/ROM or anything else on the CPU bus, it puts out the request, then waits for the acknowledge handshake to come back from the addressed device. This means that you are free to increase the speed of the CPU itself, without affecting the timing of any bus accesses. In other words, you won't be overclocking the RAM or ROM or I/O devices.  You can find 68010 up to 25 MHz in PLCC68 packages. A simple PLCC68 socket can be plugged into the PGA socket to convert it. You should be able to tap into UPCK16 (16 MHz) in place of UPCK (8 MHz). Or you could hack up a simple frequency multiplier (e.g. ICS511) to increase the 8 MHz clock by 2x, 2.5x, 3x, 3.33x, etc.

But wait, there's more! If we increase the speed of the RAM, we can increase performance, especially with a faster CPU. While the program ROM for the 68K is on the A6 CPU board, its RAM is located on the A5 MRAM board. The RAM used is relatively slow 120 ns SRAM. we could swap it out for much faster ones, say 35 ns. That alone won't affect anything, but now we are free to tweak the timing of the bus handshake. Since this RAM should be much faster, we can assert the transfer acknowledge signal much sooner. In the description of the A5 board, the service manual states:
"The delay of the CKAB signals (R1802 and C1851) ensures stable data on the address bus and the data bus when they are clocked in.
The delay of DATRAKLT (R1839 and C1852) ensures enough data setup time for the RAM."
In other words, the two CKAB signals (CKAB--LT and CKAB--HT, active low and high respectively) control a delay between receiving a write request and activating the write on the RAM, to ensure stable address and data signals. The DATRAKLT is the bus transfer acknowledge sent back to the CPU for both reads and writes.  In theory, with faster RAM, at least the DATRAKLT delay can be reduced (by reducing R1839). This speedup will help performance regardless of whether the CPU is overclocked or not. Access to data in RAM should be a bottleneck for operations such as FFT which are data heavy.

Similar gains may be possible with ROM as well, especially when using a faster CPU speed, since it will need to fetch instructions at a higher rate. The 68k has no cache and always needs to read from ROM every single instruction executed (though it only manages to execute roughly 1 instruction per 10 clock cycles). With the installed slow 200 ns ROMs, a faster CPU will likely frequently stall as a pre-fetch ends up waiting for the Ack to ROM accesses. Compatible EPROM or EEPROM with speeds better than 50 ns can be had. I haven't yet figured out how the timing delay on the EPROM access is done, it doesn't seem to be a simple RC delay as with the SRAM.

I'd be up for trying some of this stuff on my PM3320A as well. It seems like fun. I'll dig around to see what kind of SRAMs and EPROMs I have...

[cvanc]

I actually have a still-in-use PM3323.  You do NOT want to know what it would cost to ship to Germany - it's a beast.

[SaabFAN]

Don't be so quick to discount overclocking on this beast.

(...)

I'd be up for trying some of this stuff on my PM3320A as well. It seems like fun. I'll dig around to see what kind of SRAMs and EPROMs I have...

That sounds really interesting.
I've already found a MC68010FN25 CPU on ebay for quite reasonable 12€ including shipping from spain.
The PLCC-68 sockets I have here don't fit in the socket for the processor, however. Are there different types?

Going through the circuit descriptions, I don't see any parts that would be aversly affected by this modification. The DPU transfers data via its private bus to the Display Memory.
Because the DPU can continue to update trace-data, I guess the CPU copies the entire 4k of trace-memory to the A5 Processor-RAM and then starts the number-crunching, so no interference from the Display DAC and the DPU.
Additional Speedup might come from replacing Address- and Data-Buffers. Stock are 74LS245 with  up to 40ns enable-time. 74ACT245 can reduce the enable-time to just 10ns and propagation delay from 8 to 4ns (typ.).

Do you have a logic analyzer, macboy?

[SaabFAN]

I've done some calculations and also measured the time between start and finish of a RAM-Access.

I've calculated that the RAM-Board requires about 270ns to have valid data on the bus.
The RC-Timer and other timing-stuff should give the RAM-Board about 300ns to complete the task.

As you can see on the attached screenshots from my Logic Analyzer, the time varies between 265ns and 498ns. I'm guessing it is the difference between read and write-operations. After looking at the timing diagrams in the Reference-Manual of the 68k (Link:https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf) it seems like the CPU spends quite a lot of time waiting for the RAM to finish working. Most likely 2 or even 3 full clock-cycles are wasted with wait states.
Simply upgrading the RAM and reduce the timing constants of the data acknowledge-signals should speed up things considerably.

I've also took the time to mark the signals that are required to select the RAMs and ROMs and where the acknowledge-signals are being created on the schematics.

[SaabFAN]

Here's the schematic of the Processor-Board

[SaabFAN]

Holy crap, that is really an improvement!

To see what happens when I speed up the Data Acknowledge, I replaced the 1k Resistors with 860 Ohm resistors.

The result: Single channel FFT (full 4k-Points) takes about 9.5 instead of 14 seconds and the FFT on one channel when 2 Channels are active (at 200µs/div) takes 5.5 instead of 7.5 seconds!
So there's really a lot of room for improvement!
Also the MRAM-Board runs noticably - How that is possible, I have no clue.

I had to replace the resistors on the MRAM-Board and the CPU-Board btw. Both have timers whose outputs are OR-Wired with open collectors and on the MRAM-Board there's also the Aquisition Control Logic, which does not have its own DataAck-Signal.
So far I've not identified any components on the data-bus and the address-bus that wouldn't be able to handle much faster times (almost all are 74-Latches or D-Type FlipFlops and the few special chips can handle at up to 8 or even 10MHz on the Data-Bus.

I'm going to order some RAMs from Digikey (45 or even 12ns ones) and solder them on adapters to be put into the scope. Is there a difference between 61 and 62-SRAM Chips? So far I've not been able to find one in the datasheets.

Btw. The DataAck-Signal for the ROM is generated by a simple delay via two NOR-Gates. Basically the ROM has the data ready faster than the CPU needs it.
Could be different at 10, 12 or even 16MHz CPU-Clock.

[macboy]

I had noticed the PGA socket issue after posting too. Sockets are available of course, and if one looks hard enough, adapters exist too. They were available for 68k debugger/emulator systems.

I have only one of those saleae clone 8 bit ~25 MHz logic analyzers. A while ago I passed on a really nice HP logic analyzer with dozens of 100 MHz inputs, which I could have bought at roughly scrap cost. The cost wasn't an issue, but I lacked the space and approval from SWMBO.

I dug around and found some nice fast RAMs, some W24M257AK-15 which had been used as cache memory on a '486. They are 32Kx8 at 15 ns (not 150 ns which might also be the case for a -15 suffix), so 8 times as fast as the originals (and a decade newer). I also found some IDT7164S in really pretty side-brazed ceramic DIP package with gold plated everything, but they are only 8Kx8, so too small, and slower as well (35 ns).  I might have a set of 120 ns EPROMs, not the exact type, larger capacity and still 32 pins. I'll need to check pinouts.

I've never been into my PM3320A, I've never had a need to open it. I just had a quick look at the thing. Photo below. I may be mistaken, but that looks like an unbroken factory seal! (Fluke owned Philips T&M when this one was made).  Unlike much of my equipment, this one didn't have calibration stickers and seals on it when I got it, so I suppose can believe that it was never calibrated. Amazing that it is still relatively accurate.

SaabFAN, your service manual is definitely better than mine, I can hardly read signal and component names on mine. Your scans look much better. Also yours seems to show four SRAMs on the MRAM board, mine shows two plus two optional ROMs. Can you share? I'll give you a link to a folder on my Google drive where you can upload it.

[macboy]

Holy crap, that is really an improvement!

To see what happens when I speed up the Data Acknowledge, I replaced the 1k Resistors with 860 Ohm resistors.

The result: Single channel FFT (full 4k-Points) takes about 9.5 instead of 14 seconds and the FFT on one channel when 2 Channels are active (at 200µs/div) takes 5.5 instead of 7.5 seconds!
So there's really a lot of room for improvement!
Also the MRAM-Board runs noticably - How that is possible, I have no clue.

I had to replace the resistors on the MRAM-Board and the CPU-Board btw. Both have timers whose outputs are OR-Wired with open collectors and on the MRAM-Board there's also the Aquisition Control Logic, which does not have its own DataAck-Signal.
...

Very nice!
I am not surprised at the improvement, the slow SRAM was clearly a bottleneck. The amount of improvement is more than I expected, especially without actually installing faster SRAM.

The 200 ns EPROM might or might not become an issue with a faster CPU clock.

I had noticed the ACK generated on the CPU board for I/O devices. I wonder if it is or could be gated depending on the addressed device?

FWIW I've heard of people overclocking 68k CPUs to 50 MHz. I think Amiga forums might be the best source of info on that.

[SaabFAN]

I made a mistake when measuring the times after changing the resistors - I had Rectangle Window and Linear Scaling on, instead of Hamming and Logarithmic. With Hamming and Log scaling I've managed to shave off "just" about another second on a full FFT, which means they take now about 13 seconds instead of about 15 seconds in original configuration.

Unfortunately, I didn't take any measurements with Rectangle Windows and Log scaling before changing the CPU or reducing the timing of DataAck. But it feels quite a bit faster than before.
Also it seems like the difference between execution times with Rect. + Linear scaling and Hamm + Log. Scaling seems to be bigger with the improvements.
I'm guessing that Hamming Window and Log Scaling is more CPU heavy than Rect. Window with Linear Scaling (Log scaling adds one additional pass for every data-point to scale it, which takes A LOT of CPU-Cycles). So CPU-Overclocking will most likely have a bigger impact here than Memory-Upgrades.

I'm going to use these ROMs for the Upgrade:https://www.digikey.de/product-detail/de/microchip-technology/SST39SF010A-70-4C-PHE/SST39SF010A-70-4C-PHE-ND/2297826 and these RAMs: https://www.digikey.de/product-detail/de/issi-integrated-silicon-solution-inc/IS61C256AL-12JLI/706-1030-ND/1555403 They should fit on SOIC-28 Adapter-Boards available on Ebay for 50cents a piece.

I'm guessing that it should be possible to cut the timing constants for Data Acknowledge on the Processor-Board in half, if the RAMs on the MRAM and DISPLAY-RAM Board are replaced with faster ones (DISPLAY-RAM Board does not generate its own Acknowledge-Signal for the CPU).
Anything faster is going to require dedicated circuitry to disable the DataAck-Circuit on the processor-board during RAM-Access.

[texaspyro]

Maybe try replacing the RAMs and EPROMs with fast units and ground the DTACK signal so everything runs at the max speed. 

There used to be a 68000 enthusiast magazine called "DTACK Grounded".  Parts of the magazine were printed on dark red paper that made photocopying difficult.

[macboy]

I love the idea of the 68k magazine called DTACK Grounded.

I broke the seals and opened it up. Amazing how little dust is in there. Obviously very few hours of use, which also jives with the fact that it was never calibrated.

My ROMs are v4.2 for main board and v4.1 for GPIB board. I'll dump them then maybe update to v5.0 seen here. I have a UV eraser and TL866 so why not.

The RAMs I found and mentioned earlier are narrow body so I'll need to either make or buy adapters. I think I'll stick a pot across those timing resistors for easy tweakin'.

[SaabFAN]

The fast rams and roms are ordered and should arrive sometime next week.
I'm currently designing a small board that will allow adjusting the CPU-Frequency and is also going to contain a circuit that will replace the circuit on the CPU-Board that generates the Acknowledge-Signal when the Aquisition Control Logic on the A5-Module is accessed.

I'm also designing an adaptor from PLCC to PGA-68.
Schematics and PCB-Layouts will be posted later this day.

@macboy, can you upload your 4.2 ROMs? My scope has the 4.1 Software. Would be interesting so see what's different between both releases.

[macboy]

The fast rams and roms are ordered and should arrive sometime next week.
I'm currently designing a small board that will allow adjusting the CPU-Frequency and is also going to contain a circuit that will replace the circuit on the CPU-Board that generates the Acknowledge-Signal when the Aquisition Control Logic on the A5-Module is accessed.

I'm also designing an adaptor from PLCC to PGA-68.
Schematics and PCB-Layouts will be posted later this day.

@macboy, can you upload your 4.2 ROMs? My scope has the 4.1 Software. Would be interesting so see what's different between both releases.

I can upload the v4.2 ROMs. I'll try to find time later today.

The ACK that is produced on the CPU board itself ... are you talking about DTARAKLT? I thought this is only for I/O space accesses. D1734 is a big NAND gate that only produces the postive output when one of the eight I/O select signals is active. Once of those is active when D1744 decodes an I/O space address. Since the CPU bus DTACK signal is driven as open-collector, the first device to assert the Ack will cause it to be recognized.

[SaabFAN]

Yes, you are right. There's no need to create DATRAKLT anywhere else than on the MRAM-Board. I confused Active HIGH and LOW (again)

So the only circuit needing speedup is the one on the MRAM-Board that generates DATRAKLT after a memory-access has occured, which can be done by replacing one resistor.

[SaabFAN]

I've sped up the DATRAKLT by an additional 50ns, so the Acknowledge happens now after 220ns instead of 330ns.
I didn't do any measurements on the speedup because I have also started modifying the CPU-Board.

As you can see on the attached pictures, there are a few modifications necessary to isolate the CPU-Clock from the main clock generator.

Driving the CPU with my signal gen, the maximum stable clock is 9.5MHz with the 68010 and the mentioned modification to the circuits that generate DATRAKLT.
To have the fine control necessary, I've scrapped the circuit that used a 4046 for the PLL and I'm now using an Si5351 PLL that is controlled by an Arduino Nano.
The required 5Vpp clock-signal is being generated by a 74S74 FlipFlop, which receives the clock from the PLL, divides it by 2 and then sends it out via an SMA-Connector through a coax-cable to the processor.

[macboy]

Firmware version 4.2 for PM3320A, PM3323, and PM3340.
The zip contains 4 x 128 kB ROMs, which are DIP 32, Intel 27C010, 200ns speed grade in my machine.
I have the FFT option as well as the GPIB/serial (PM8956A) option, which itself has v4.1 ROMs.

I plan to desolder the slow 120 ns SRAMs and replace them with the faster 35 ns SRAMs I mentioned in an earlier post. The new SRAMs are pin compatible but narrow DIP28 so I will need to create some adapters for them to fit the wide DIP28 footprints.

I'll also desolder the IC which drives the CPU clock, and place it into a custom made "interposer" socket, which will allow me to disconnect just the CPU clock signal for injection of another one. I'd rather do this than cut PCB traces. I think some of the 74LS series might be replaced with 74ALS for speed improvement (less propagation delay especially). I think 74F is too power hungry in general. 74ACT is another option to look at, they are very fast as well. I am thinking in particular about the bus transceivers, address decoders, etc. which can be bottlenecks for the RAM/ROM access times.

I like the idea of hacking a 68030 into this thing. The instruction and data caches could mean significant performance gains. Might even get to something like real-time FFT (~1 per second) which would make it so much more useful. I need to investigate whether the system actually uses the mc6800 (sic) style peripheral bus that the 68000 offers, but the 68030 (68020) does not. That would be a showstopper as I don't have the inclination to build the external logic necessary to implement that. Otherwise it might not be too hard, as Motorola did a great job of making each CPU in the series a "proper superset" of the previous ones. The ROMs also have plenty of empty space to implement a new boot vector with code to set up the 68030 (turn on caches, set up MMU for cacheable/non-cacheable areas) prior to jumping to the original boot vector.

[SaabFAN]

I don't know if the software actually uses the MC6800 style Peripheral Access, but there's circuitry on the Processor-Board that creates signals on the VAP-Input Pin.
These signals end at one of the pins of the Bus Arbiter-Chip and seem to have something to do with the master/slave-timing.

The 68030 would be a nice addition to the scope. The fact that it has cache and a pipelined architecture suggests quite a bit of speed-improvement.
It is going to be tricky to get it in mechanically, though. There really isn't much space between the cards.
What's a bit annoying is the fact that it seems like there's no datasheet out there for the bus arbiter-chip on the board.
If anyone knows what a Signetics C2606N exactly is, please share. Judging by the lack of online documentation, I'm currently guessing that it is some kind of ASIC.
I think getting a 68030 in there will require a new board with all or most of the logic implemented inside an FPGA, or is at least easier than trying to get that processor inside the cramped space between the CPU-Board and the GPIB-Board.


In other news, I've installed the clock-generator. As mentioned earlier, it uses a Si5351 PLL to generated the clock for the system. I didn't had any switches readily available and wanted to see if it worked, so I just wrote a very simple Arduino-Sketch to set the PLL to 19MHz, which is divided by 2, set to 50% Duty and scaled to about 4Vpp by the 74S74-Chip, sending 9.5 Mhz to the CPU and the shift-register that is responsible to create the Acknowledge-Signal when a write-operation takes place.
The display does nothing btw. I thought I could use it to display the current frequency, but it somehow didn't work and can't be seen inside the scope anyway, so pretend it isn't there

[SaabFAN]

It definitely was the ROMs holding the CPU back.
With the new 70ns FLASH-ROMs installed, I was able to clock the CPU up to 10.5 MHz. Anything above that and it instantly crashes. I'm guessing this time the 10 MHz rated 68010 CPU is the limiting factor.

I'll have to see how much further this can go with faster RAMs (I'll desolder the old ones this weekend). At 10.5MHz, a wait-time for !DTACK of about 220 to 270ns should result in 2 or 3 wait states each time RAM is accessed.
Reducing that wait-time to just 100ns should reduce the wait states to one or perhaps even no wait states at all.

The 4.2 Software holds some interesting features by the way.
New is the possibility to delay a channel by a specific amounts of data-points.
Also the Results-Page doesn't include the time anymore just the date. If you want the time on screen, you have to enable the clock in the Option, which now will stay on screen instead of vanising after returning from the Options-Menu.
I haven't checked any further, but updating to 4.2 is definitely worth it.

The fact that the software is the same for all PM33XX-Scopes also gives further indication that the Key or Configuration-ROM for the options and the scope-type is hidden somewhere inside one of the programmable logic sequencers (precursor to FPGAs). Unfortunately reading and burning those chips requires equiptment more expensive than a good used Tektronix or Philips-Scope with FFT.

On a side-note I've found out why the RAMs run cooler now: They require about 120mA as long as their !CS-Line is pulled low. The shorter that line is pulled low, meaning the quicker the RAM-Access, the lesser is the current draw of the chips.
All in all I'm amazed how much more performance I was able to get from the scope without changing anything but the CPU, which was readily available back in 1987 when this scope-series was released.
Either Philips was trying to save money on components, or the engineers decided to play it extra safe and added massive safety-margins.

PS: According to the internal clock, FFT is down to 9 Seconds with Hamming Window and Logarithmic Scaling turned on / 5 seconds with Rectangle Window and Linear Scaling @ 10.5 MHz and 220ns Wait-Time for !DTACK during RAM-Access.

[Emo]

Hi SAABfan, interesting upgrade job. My unit came with V5.1 and is appears also to be universal 3320A/23/40
Will try some of your tricks soon

Eric

[SaabFAN]

Well, the new RAM-Chips don't work. Individually, they test as OK in my programmer, but inside the scope they don't work.
I suspect they don't have the driving-capability for all the TTL-Inputs on the bus, or the pins of the adapters don't make good contact (when buzzing them out, I saw no problems).

The chips I used were these: IS61C256AL-12JLI

I'll try it next with some other, older chips, but I've got to get them first

[SaabFAN]

I think I have reached the end of what I can do with the Scope at this point.
I have reduced the wait-time for DataTransferAcknowledge to about 130 - 140ns (delay-timer + propagation-delays in the logic-gates) and there hasn't been any real improvement. I could try to reduce the delay even further, but I think the improvement will be marginal at best and reducing the delay to anything below 80ns is most likely impossible because of the enable-times and propagation-delays of the address and data-buffers.

Getting even more speed than now requires a different CPU that can be clocked at higher speeds than 10.50 MHz. There are 25MHz rated ones available on ebay, but they are in a PLCC-Package, which would require a custom adaptor and probably the removal of the PGA-68 Socket due to height-restrictions inside the card cage. Something I'm not comfortable with.

Btw. has anyone of you guys had more luck finding a datasheet for the bus arbiter? If there is, it would be possible to cram the entire Processor-Board into an FPGA or CPLD and put everything on an "accelerator-board". That would be pretty awesome. 

[wazoo]

hi all

SaabFAN mention me this thread because we have a PM3323

past year I recue it from road to the trash from my workplace , because of "unused / stored for years / out of calibration"   
today we will let it give it a chance    thanks to the great job of SaabFAN

for the first power up we saw a completely noise screen, without test signal.  bootup test relays sound and text screen looks fine.
after replacing 90% of axial capacitor with radial version , and all SMD capacitor in P2CCD board, we can see a noise but clear test signal.   
oohhh good news!!!  can we repair it ?? it looks like we are on the good way.

thankU SaabFAN for your hard job.  we will follow your steps.

first power up....



after cap replacement...



capacitor removed with leakage near


new capacitor and cleaned section




some axial cap replaced with radial version

[wazoo]

wwwooowwww   SaabFAN  it is really fantastic and very hard your work.   
finally I have finished reading all thread   

our scope is in my brothers home.
I will try to make 4K photos  to show you how this unit is inside. and the ROM versions.

Some years ago, when I was a bit younger  ,  I liked to "overclock" my first 486 computer that starts from 25Mhz and changed crystal to 33Mhz.   
This processor is older tecnology, I know, but it's fun to hear that you are trying to squeeze the processor some ns   

I am not an engineer but can see that this oscope is really a "heavy" tool 

we will follow yours and macboy colleague progress

this is our PM3323  P2CCD board before capacitors change.



other boards





and these are our CPU boards with 4.2 and 4.1 ROM version

[SaabFAN]

Do you have another Oscilloscope?
If so, check the PowerSupply-Rails on the large bottom board. I guess that there's quite a bit of noise there.

The next place would be to check the signal that arrives on the ADC-Board.

[bd139]

I think all the problems I had with my PM3315 were knackered Philips Axial caps on the main board. If you don't have a scope but do have a reasonable DMM you can trace them out on low ohms range - they usually go short.

[wazoo]

yes SaabFAN , I have a rigol 1054z like you   
my brother is checking power supply capacitors
step by step we are changing all capacitors.   

[SaabFAN]

Also check the Clock-Lines to the P2CCDs and all the other control-signals. The CCDs are analog devices and it is quite likely they're sensitive to the clock-level.

The clock is generated on the driver-board that sits on top of the CRT. The one hidden beneath the shielding. That board also contains a lot of SMD capacitors that need to be replaced.

[SaabFAN]

Now that I also have a PM3323, I have started a new thread specifically for the problems of the PM3323: https://www.eevblog.com/forum/repair/repairing-the-aquisition-system-of-the-philips-pm3323-oscilloscope/msg1380244/#msg1380244

The reason behind that is that the PM3323 seems to be suffering from far worse capacitor-problems than the PM3320A. Most likely because the PM3323 runs a lot hotter because of the higher Clock-Frequencies.

Issues with the digital systems and the upgrade-attemps will remain here, but also apply to the PM3323, as that scope shares the majority of the components with the PM3320A.

[idrenth]

...
... terminal program on your PC - I use Realterm, available on SourcefForge. ...
...
....is with an HPGL viewer, such as HPGLView...
...

Sources:
Realterm: http://realterm.sourceforge.net/
HPGL_View: http://service-hpglview.web.cern.ch/service-hpglview/hpglviewer.html

I'm very pleased with the operation of both of these utilities...

Hello everyone. I just own this scope also and would like to try out the rs232-c connection.  I just use the fdti232r and configure it on 5v. When I connect the TX,RX and ground so that would be on the DB25 connector pin 1 GND, 2 TXD and 3 RXD. Do I miss something? I use the same software and configure also the baud rate correct. Do I miss a step ? I send something but I don't get anything in the hyperterminal from realterm

[tunk]

It could be because it's using RS232 voltage levels, and not 5V:
https://en.wikipedia.org/wiki/RS-232#Voltage_levels

[idrenth]

That could be, but still what did they use and is the only 3 pin connection enough to work ?

[SaabFAN]

If I remember correctly, you need at least 2 handshake-Signals.

I'm not sure about the signal-levels, though. Better check it first before you fry your chip and/or a USB-Connector of your PC.

[idrenth]

I have the cable now working from db9 to a db25.  I use pinout from pm8956A. Next plan is to get the FDTI232 chip working for this connection. I am also thinking about to upgrade my unit with version 5.1 it still runs on v2 Waiting for some new eproms to program them.

[texaspyro]

The standard signal connection to bypass handshake signal requirements on a piece of equipment with a DB25 connector is:
   4-5
   6-8-20

[idrenth]

So have it now working with a pl2303 chip and goes to USB connection to my laptop. That works fine. Now was wondering you guys have maybe some nice things to use on the rs232 connection prog's to read out more out the PM3320A device? I am also thinking about the gpib connection to the readout. any benefits between the both ? any good suggestion software to use with this scope?

[idrenth]

You mean to jumper them on a db25 so link pin4 and 5   also link pin 6 with 8 and 20? is that way I only need the rx tx and gnd connection still? because I have it now in an otherway to get it working from db25 to db9.

[SaabFAN]

GPIB has the advantage of a much higher bandwidth. About 1 MBit/s I think.
Unfortunately, the GPIB Firmware inside the scope doesn't know some standard commands (like ID?) that were introduced around 1990, so several programs might have difficulties talking to the scope. So it might be a bit of a hassle to set up some modern software.

So far I've been using only a terminal program and HPGLviewer to capture and display data from the scope. Don't know about any other programs that can use the serial port. There seem to be some programs out there in the wild that can make use of the GPIB-Interface, though. Haven't checked that out though, since so far I didn't want to spend money on an expensive GPIB to USB Interface and didn't find the time to make one with an Arduino

[idrenth]

I have gpib pci card from national instruments and a usb own made gpib cable. So far I know there where 2 commands for ID? and IDN? I remember that because there was HPIB and GPIB. Also I remember that fluke use IDN? and most HP and other use ID?. So make sense if you need for the philips/fluke PM3320A  also maybe the command IDN? I have to check that later out. Maybe that somebody already had it working. So I could look how to use it or maybe can use it instead of redo all the research. Maybe I can look it up in the manual from the PM8956A for the command list.

[idrenth]

In the manual from the 8956a is also written that it has a command known as the "IDT ?" so the scope has it also. With the GPIB I had response "IDT PM3320A.V02 /PM8956A.V01"

When I send the command over rs232 I got a response back "IDT PM3320A.V02 /PM8956A.V01"

[SaabFAN]

Right, I remember now. That command works, but when I tried out the National Instruments-Software for a GPIB-Card I had bought for my Retro-PC, the software kept using the "IDN ?" command to search for devices, which resulted in Bus Timeout-Errors.

That's what I meant by my earlier comment. More modern software seems to assume devices understand the 1990 GPIB Standard Commands and when they don't, it leads to issues

Would be interesting to see if the software for the PM8956A-Card (the one that makes RS-232 and GPIB possible) can be updated to understand newer commands. Best case would be if the engineers at Philips used some sort of look up-table that can be easily identified by looking at the firmware in a Hex-Editor or with a Disassembler.

[idrenth]

Right, I remember now. That command works, but when I tried out the National Instruments-Software for a GPIB-Card I had bought for my Retro-PC, the software kept using the "IDN ?" command to search for devices, which resulted in Bus Timeout-Errors.

That's what I meant by my earlier comment. More modern software seems to assume devices understand the 1990 GPIB Standard Commands and when they don't, it leads to issues

That wouldn't be a problem you can change the string that send or replace that string in the blocks with your own made block.

Would be interesting to see if the software for the PM8956A-Card (the one that makes RS-232 and GPIB possible) can be updated to understand newer commands. Best case would be if the engineers at Philips used some sort of look up-table that can be easily identified by looking at the firmware in a Hex-Editor or with a Disassembler.

It doesn't really matter to have disassembler, because the commands are written in the manual should be possible to change the command in the newer programs config files. I thought it called file *.ieee488. Philips had a program to communicated with it called "BINPROG" I don't own this program but also not sure if that would be better now this days.

[idrenth]

So, I also upgrade my scope with V5.1 cpu board. I was wondering does someone have a picture where the FFT function should be? because I already had the Histogram option or is that the same for your FFT function? Maybe picture possible or a step by step to see?

[idrenth]

Here some captures from it.

[SaabFAN]

The FFT-Function should be right underneath the Histogram-Function in the menu.

It is enabled somewhere else in the instrument, but I haven't been able to figure out where yet.

[idrenth]

Does someone have an image how it looks? because I only see talking about it but no one has an image or a video to get there ? can somebody provide that with the 3320A? if so I will think it would be at ccd part. that is doing the calc part. but I first want to see who has it with some images and if possible a video would be nice how to know where to see the FFT.

[idrenth]

So do you have that on a PM3320A? possible make foto and maybe video so that we can see it?

[SaabFAN]

Yes, I have the FFT on my PM3320A.

Here are two screenshots of my Scope.
The FFT-Function is on Page 2 of the Mathematics-Functions.

[idrenth]

Yes, I have the FFT on my PM3320A.

Here are two screenshots of my Scope.
The FFT-Function is on Page 2 of the Mathematics-Functions.

I might think it get unlocked from the ccd part. because that is math calculation area. There wasn't a way to make rom dump from that one? because I also have version 5.1 on it now so the only place would be the ccd part.

[idrenth]

So there is some time past by again and I went back to see what is the differences compare with my board. I know it should be in the ccd part because that is the math area. I saw 2 things different can others confirm if this is correct? @Saabfan or others?

I saw there is a bridge wire on one of the chips and there is firmware number 2 on the chip.

Can someone make a backup from the chip with a D8303 B720.2 on it for me ?

I hoop we can make this upgrade now possible for this scope after a long time.

[SaabFAN]

Funny that you're just now continuing to work on your scope. Yesterday I livestreamed the aftermath of my repair and the calibration-process of my PM3323 on Twitch. The old boat-anchor is now working and performing well, despite me having no way to generate the low frequency Square-Wave and no way to verify the high frequency square-wave for its characteristics. Once I have the Signal-Generator running, that shouldn't be a problem anymore though

You're right, there are version-numbers on those chips. My D8303-Chip Label on the PM3323 shows D8720.2.
According to the Service-Manual, these Chips are 20R8, which are 20L8 (easier to google) with Tristate-Outputs. It might be possible to replace them with GALs from Atmel or Lattice if they support Tristate-Outputs. Unfortunately, I haven't been able to read the chips with my TL866 Programmer (I get a Read Error 31 and then a Warning about wrong Serial-Number with a link to the Website of the Manufacturer). The newer programmers also don't list the chip in their Supported Chips-List. Maybe it is possible to read the chip with an Arduino. But I haven't investigated that possibility beyond one google search.
I do have a defective P2CCD Board of a PM3323 here though. If you want to, I can ship it to you. It's the board that had a transistor release the magic smoke due to a dead P2CCD-Chip on Channel B. I have held onto it to salvage it for parts or sell separately.

Pretty interesting that they have put the chip that enables FFT onto the P2CCD-Board. Either the other chips were full, or they needed to record the Samples in a different way to be able to process them for an FFT later.

Btw. I have made another interesting discovery today: When I closed my PM3323, I transfered my modified A5 and A6-Boards from the PM3320A to the PM3323, which resulted in a crash.
I have identified the problem to be the CPU-Card A6, which seems to have some hidden configuration-jumpers that select whether it is a PM3323 or PM3320A (I didn't find the Jumpers in the Service Manual). I have then transferred the 68010 and the ROMs from the PM3320A to the PM3323 A6-Board and installed it and it works fine.
Installing the A6 Card in the PM3320A makes the Scope think it's an PM3323. I can also ship the A6-Board from the PM3323 I have disassembled. Maybe you can trick it into believing it's a PM3320A, or you can find the hidden configuration-switch for FFT if it isn't on the P2CCD-Board.

[idrenth]

That would be nice to test both cards. p2ccd print and the a6. Did you also saw in the image the jumper wire? it's front from the p2ccd board. Do you also have there a wire bridge on your chip ? It's on the first image bottom with a red arrow on it.  Because I remember you had one pm3320a with fft. So we maybe can figure this out.

Also bad that it happens with magic smoke on the board.

I would like to have that fft function

[idrenth]

I am not sure you can read the 20R8 as the same as the other PLD chips. Philips have their own chips: SIGNETICS(PHILIPS)   so this one PLUS20R8-7   PLCC   dip24   PA28PL24D2P6-YA. So it could that is why you had an error. I am also not sure which one can read that chip out. I have tl866 also but not the cheap version from that.

[idrenth]

Update I found now out the chips is from MMI brand (Monolithic Memories Inc) that is bought over in years 90s by AMD. So I also found the conversion table maybe that helped from TI. Only problem my TL866A only read 1's but didn't give any error.

So first image is from the chip D8303 DB720.1 version without the fft version. PAL20R8AJCS chip.

in the second image was the closes version I could find from AMD
PAL20xxACNS  --->  TIBPAL20xx-25CNT

I check the conversion what tl866a programmer Maybe have listed. 3rd image
GAL20V8B-25LP    <-----  TIBPAL20xx-25CNT

TL866A knows lattice GAL20V8B IC and I selected that one.

It readed the chip but I didn't get any thing back. only 1's

[Chris56000]

Hi!

Sorry if I'm interrupting the party, a couple of Members have mentioned that the PM3320 and PM3320A Service Manuals differ – could someone tell me where I can get a PM3320A Service Manual please?

I'd like to have a read of them both to see if I can spot how the F.F.T. option comes on/is enabled, but so far I've only found the original '3320 S.M. for download in k04BB!

Chris Williams

PS!

I've just realised I had it – it's actually included in the 3323 Service Manual rather than being separately produced!

[Chris56000]

Hi!

Reading back all "1s" with GAL devices usually means the device has had the security bit set – although occasionally, depending on the particular device type, you may read a row of "zeros" on the last or last but one row of the fuse–map even if the device is secured!

There has been a circuit published that can determine the Boolean expression for each o/p of a GAL but unfortunately it will NOT work if the device is the "registered" type, denoted by "R" in the middle of the type number!

My experience with GAL devices in industrial fault–finding is that they're not all that unreliable, and when they do fail it is usually an obviously defective input or output pin that can be found with a simple "V–I" or component–tester type device, nearly always a very low resistance compared to the good pins, or a fairly obvious internal o/c!

Obviously the usual caveat applies, make sure the +5V digital logic supplies powering the PCB under investigation are in perfect condition and all internal decoupling is in good order – unfortunately it does look like Philips do secure their programmable devices, so your only option is a parts mule or replacement board of the same type as the suspect unit!

Chris Williams

[idrenth]

I am not sure yet. maybe the programmer can't read it because the gal needs a clock osc. without the clock it can't get anything out of the gal because it will give 1's. I remember to program a GAL chip with abel in the past and you can get a state table to check if everthing is correct. Problem I don't have that old program and the gallep 4 programmer. Still more research is needed to find this out.

[idrenth]

Had talk today with @SaabFAN and share info and we talk about the options. Till we talked about diffrences on the CPU board and there is a diode parts on logic chip what I had on the 3320a and I didn't. Maybe this unlock the FFT option and says which CPU it is. In the bottom, the board is the pm3320A without the FFT and top on with PM3323 CPU board it looks like the left one is for saying the pm3323 and right one is for the FFT option. We didn't confirm this yet. But would help to figure this out maybe to the next step.

[SaabFAN]

I can confirm now that the FFT and most likely all the other Options are being configured by connecting Diodes from the Select-Lines that originate at D1746 on the CPU-Board to the Databus-Lines connected to D1723.

So far I have identified two config-diodes.
- D1723 PIN 2 ->|- D1746 PIN 18: SELECT PM3323
- D1723 PIN 9 ->|- D1746 PIN 11: ENABLE FFT


In the Service Manual there's also a table that lists the Address-ranges for some of the Options (See Attachments).

So if you own a PM3320A, PM3323, or PM3340, you can apparently enable the FFT-Function by simply connecting a Schottky-Diode from Pin 9 of D1723 (74LS245) to Pin 11 of D1746 (74LS541) on the CPU-Board.
For the PM3320 (early Version without the "A"), there might be additional modifications necessary. For example upgrading the Firmware from 2 ROMs to the 4 ROM-Version and upgrading the RAM.

[idrenth]

Nice!! we finally found it. I saw it was a Bat85 same as V1707 diode. So i will use that one. Now I will also test it if it doesn't have any problems with the 3320A pld chip has the firmware D8303 DB720.1 or D8303 DB720.2 is needed because I have PM3320A with D8303 DB720.1.

[idrenth]

I can also confirm now if you have the D8303 DB720.1 or D8303 DB720.2 firmware on your P2CCD board the FFT get unlocked from the PM3320A with signal Schottky diode Bat85 between D1723 PIN 9 to D1746 PIN 11. I place temporary a 1N5819 on the back from the board because I rather don't place soldering on the side from the ic if there is space left on the back. I will soon replace them with the right components what philips use BAT85.