I got it nonworking and hope to be able to get it back to life.
Here you have some basic characteristics of this system, taken from the Tektronix WEB
I got the unit without hard disk and missing all the knobs:
I found it had a factory mod on Channel 1. And part of the mod was somewhat damaged:
This is quite a complex unit, with lots of processors and programmable logic inside. Here you have some views of it:
It has inside two computers: a PC one (Pentium-III class) and a PowerPC one. The top one is the PC, with the PowerPC just below it (not visible in the picture):
On the rear panel you could see the common PC connectors and also the CD-ROM:
Originally it had a Celeron 566MHz CPU, with 256MB RAM:
I upgraded RAM to 512MB, as it had a free RAM slot. This is the maximum supported by the mainboard.
As I had not got the original operating system, I tried several kind of systems on the unit: Linux, Windows 98, Windows XP. But of course the unit needed an special version of the OS to work.
But it was curious to boot the unit with those OSs. Windows XP reverted to the external monitor I had connected also to the unit.
It is not uncommon for proprietary software, such as Mapcon CMMS software, to require a specific OS to operate. CMMS is a maintenance management system used to monitor equipment in certain modern industries and facilities.
Thanks to some wonderful people, I was able to get a copy of the CSA8000 and TDS8000 Instruments Operating System Rebuild, so I was able to install a proper OS to the unit:
The OS matching this hardware (there were older Windows 98 units) is an special version of Windows 2000, as you can see:
Once the OS was installed, I did the same with the applications software, which can be downloaded from the Tektronix WEB:
Once installed, I started it:
And I got the first errors on the initial self test:
But as the errors were located all on Channel 1, and it seemed a modified one, it could be just OK... But no, later I got plenty of other errors:
But they were not consistent and, sometimes, unit passed loop tests for hours.
As I had no sampling head available (and didn't think it was a reasonable buying, being very expensive), I upgraded the unit. I had already added 256MB RAM prior to install Windows 2000 and now I replaced the Celeron 566 with a Pentium III 1GHz I had in an old PC:
And it booted!
Sometimes miracles do happen... as when, one day, I got an e-mail from a fellow test-equipment fan, regarding my works on the CSA-8000. He asked if I was interested in a possibly bargain priced sampling head, which could be OK. YES!!!, I said. And after some struggle with US postal system... eventually it arrived to Spain :-). Thanks Mark for all your help on this!
It is an 80E03, 20GHz, 2 channel unit. Only missing thing is front label. Not a big deal, I would say!
So I was able to plug it in the mainframe... and hope for the best!
Yes, it was properly recognized!
And preliminary tests were very promissing.
This is a 1 MHz signal:
But this kind of repairs is never easy... Upon checking at other frequencies (100 MHz in this case), I found some problems:
The discontinuities were some kind of digital artifacts.
I did some extra tests to find that discontinuities happen exactly every 2.7ns, on any input frequency (I put the cursors on adjacent discontinuities, changed frequency and they showed always on same position)
It happened exactly the same on both channels of the 80E03, so it was not channel related.
And also the error was the same using channels 3 and 4 than using same plug-in as channels 5 and 6, so this also reduced the possible culprits.
Here you have some samples of the problem, with the timebase fixed and changing just the signal frequency:
So there seems to be a problem in the acquisition system... and I am stopped here as there is very little information about the CSA-8000 innards.
In order to try to fix the problem, I have been reading all the technical information about this system. There is very little technical information, without even a semi-detailed block diagram, which would help quite a lot. So I am thinking on doing it by myself, studying the functional blocks of the acquisition PCB which has lots of repetitive areas. Some are 8 groups, corresponding to acquisition channels but some are 4 or 2 groups, which I need to properly identify in order to be able to diagnose and, hopefully, fix the mainframe.
Well, one thing is clear: the acquisition system multiplexes in time different analog to digital converters (ADCs), as it can be seen in the previous images: each discontinuity (which happen always every 2.7ns) is the start of one ADC section and the next is the end of it and the beginning of next one. At first, I thought that there should be good and bad ADC sections. But, after carefully observation, I have found what I think is the real culprit: acquisition is too fast. I found it by looking at a 1GHz signal, which in a 2.7ns period has more than a full cycle. I measured with cursors the period between peaks inside a section, which should be, inverted, equivalent to 1GHz. But not, it is about 1.19GHz!. So, yes, it seems that sampling is too fast.
So I thought there could be a problem with the internal 10MHz reference oscillator and I set up a GPIB connection and, following the Service Manual, calibrated the internal oscillator. I will write here the exact way to do it, as manual is not clear enough regarding spaces. If you put extra spaces, command is just ignored by the mainframe (don't ask me how I know ;-))
Please, read the details from page 3-5 on Tektronix CSA-8000/TDS-8000 Service Manual (reference 071-0438-06)
The correct sequence to follow is this:
(do procedure as manual instructs)
CALCOMP:DOUBLE "Internal10MHzRefFreq",(new value)
Please, note that there are NO spaces between ':' and commands but there is one space before the text argument.
OK, so I did that and got an slightly better adjusted time base, but there was no noticeable change in the trace. So I changed to use a 10MHz external reference, but the result was the same than before. I played modifying the 10MHz external reference up and down the nominal value and, yes, the signal changed, but the sampling error is so large that I was unable to fully correct the problem. But trace changed in the different sections, so I think I am on the right track ;-)
To graphically see what I am referring to, regarding the fast sampling problem, look at this image:
In the first period, at the left, signal is sampled too fast so it eats part of the next section (it is too advanced on the wave). Then that middle section goes also too fast, so it ends after it should and, again, third section starts in a point already sampled incorrectly by previous section.
Now my question: is this a calibration problem?. I guess the fine tunning could be made by software (even if the error is very large, about 20%). If not, it would mean that some clock signal, derived from the main 10MHz reference, is acting up.
I have no clue yet about how the sampling clock is generated... I will need to investigate it. What seems OK is the distance among sections (2.7ns) as, thanks to a Tekscopes list member, I found a book which clearly says that CSA-8000 series uses a 2.7ns internal clock period, as you can see on the footnote of this page:
So, well, I don't have yet the answer but I am closer than before ;-)!
I am afraid I was WRONG from minute zero :-(!!!
The unit IS TELLING ME what happens...
When it runs internal diagnostics, it fails with 20+ errors on Acquisition 1 test. I had assumed that this was related ONLY with Channel 1 of the oscilloscope so, as other Acquisition tests passed, I thought that I could work with the unit except for Channel 1.
Well, I have looked to the diagnostics and Acquisition 1 has LOTS more error sub-sections (in Area and Test levels) than the other Acquisition tests, so I guess that these may be common to other channels, not just to Channel 1!
So, if I can't get rid of these faults, I have nothing to do :-(
These are the complete results for Acquisition 1 tests:
BTW, running the compensation for the mainframe and monitorizing with the serial port on the PowerPC board (which manages acquisition), I have got some interesting errors, which at least have something to do with my ideas about the system using more samples than it was intended to use:
As a sample, for Channel 7 it says:
0x2aca040 (aCalDiagExecutor):  C: 637,11948:17:19,37.50,73A,GO Alt HLUT: Ch 7, HLUT EndPt, FAILED - endCode=9318, max=8191
(a similar error is shown on all Channels but 1, which fails on STROBE)
I would say that EndPt has something to do with memory range / stored samples.
Well, all in all, I am facing the crude reality: this mainframe could be doomed :-(
But I will do my best to get some life out of it. Keep tuned!
Well, I am not always successful in my repairs. And this seems to be one of those cases :( . And, for sure, one which has left me with a bitter taste.
After spending lots of time digging for information (little available), reading technical docs of other similar sampling scopes (as the 11801 and the CSA-803A), checking components datasheets, probing on the PCB, using both the serial terminal from the PowerPC board and the GPIB from the PC one and trying to understand what was happening to get the failures I got, I was sure that the problem was one of the 8 DSPs the unit has. Let's call it DSP#1. It manages the Channel 1 acquisition but also some other general things, as the NVRAM and some time and voltage references. The other 7 DSPs manage only their corresponding acquisition channels, 2 to 8. So the circuit around DSP#1 is more complex than the others, retaining the same common part.
I resoldered DSP#1 along the PLD closest to it and so pertaining to Channel 1. I got no difference on tests, same 23 errors. After some (lots!) troubleshooting hours, I decided to let it go by now... but then, upon reassembling the Acquisition Board on the mainframe by the Nth time, I started the unit (I wanted it to be the last time for a while) and thought an alternate way to locate the problem: there were some things on DSP#1 which worked OK, as the host communication. So I tried to make it fail instead of making other tests perform OK, as was my previous approach... and I got it to fail!!!. If I pressed a bit over one side of the PLD, I could make the DSP host communication fail. So I finally had a clue!
There should be something wrong there... but I had already resoldered it. Well, I tried to get one of the error codes out doing the same... and, eventually, I could get some OK tests!!!. So, again, the Acquisition Board was out of the mainframe and ready to get another soldering session. I did it with the outmost care, insisting on the PLD and also redoing all the vias along that area.
And then... the system no longer properly detects the Acquisition Board (and it is not a matter of power supply rails; it is a 'logical' thing). I have checked the soldering in and out about 10 times, with magnifying, measuring and so on. I can't find nothing wrong. But it seems that DSP#1 is needed to start the unit, as it checks NVRAM for cal data and, looking at the system log (generated by the serial terminal), this is the first thing which is different to the previous logs I had, when unit started OK. So it seems host communication is not working. And it worked fine before!
So, all in all, and deeply frustrated, I had let it go. I can't spend more time now on this problem. It is a pity as I am almost sure the problem is on that PLD. It could be an internal pin contact which, upon resoldering, is now always bad. That board has eight similar PLDs, but I am afraid the other 7 could have same programming on it but this one, being connected to the 'special' DSP#1, which does some housekeeping besides managing Channel 1, as I have commented, could have another programm on it. So I can't just remove another one and replace this.
My only way to deal with this is to find a damaged acquisition board with a good PLD#1 on it... of course, I would pay for that a reasonable amount. Please, keep this in mind in case you know of a CSA-8000 parts unit in the future.