The Tek calibration software has its own built in driver, so you don't need to worry about the DOS and Windows drivers unless you want to use other software with it. That's the reason the calibration software only works with those specific cards.
Yep that's what I thought too. However I still needed/wanted/welcomed NI's DOS utility tools so that I could, by trial and error, figure out how to set an undocumented dip switch on the board. I bought a genuine NI board, NI has a 68 pages long "getting started with GPIB" guide which is based on my very board, but somehow they decided to skip completely the one and only switch that was not obvious. DMA/INT/base address sure, covered, but that other switch, I had to figure out myself. So once I was sure that the card was configured properly and working well, then only I could start looking at the Tek software. Thing is, this software too gives me headaches : when you run the installer, it asks you about some mystery switch on the GPIB board, but really I couldn't make sense of it/figure it out. So, had I failed to get that Tek software running, I wouldn't have known if it were because the default value offered for this mystery switch, was not the right one, and/or if the GPIB board was defective (it 's 25 year old untested unit after all ! )and/or mis-configured and/or some problem with the host computer.
So once was I sure, thanks to NI test/diag programs, that the board was 1) not defective 2) configured properly, then at least I knew that the Tek S/W, if it failed, would not be because of my board, but more likely due to me not knowing what to do with the mystery switch setting it would ask me about. I still have non clue what this switch is for, and I will most likely never know, but luckily the software decided to work so I guess the offered default value was good enough ! Phew.
Anyway, I made some progress on the repair, so much so that actually I think I may well have fixed it !
A tad presumptuous I know, only time will tell if I really fixed it or not, I guess...
If it behaves for 3 or 6 months, I will call it a success... let's be modest because it's the first time I work on such a complex piece of gear, I mean it's no toaster or coffee machine for sure !
Lots to say, so let's stick to chronological order so as not to get lost in too much digression.
- I was again studying the schematics to try to figure out a safe way to individually disable these SRAM chips. So in order to safely do that, I had to REALLY understand how it was all put together. If you just want to skim the surface then it's simple : the board was meant for 8K chips (28pins) so as to cater for the largest memory these 500 'A' series could have, i.e. 50K points (schematic sheet #25, for channel A as an example), but could also be fitted with the smaller 2KB chips (24 pins), as seen on sheet #9, as posted earlier. The 3 shunt resistors we see are not there to help you debug in any way, I think, but more to "patch" the PCB so that it can be modified on the fly on the production line to accept either memory chips. That's scratching the surface.
Now when I tried to dig deeper to REALLY 100% understand what was going on, I failed, because I ran into inconsistencies between those two schematic sheets, and saw things that I just could not make sense of. So, I probed around on the board, to try to suss it out, but this only revealed even more inconsistencies ! So, I gave up, at least for the time being.
One thing was for sure though : as was hinted at by someone earlier on, the shunt resistor that runs from Vcc to the active high chip select line... is indeed redundant : I removed a couple of them on some random SRAM chips, just to see for myself, and indeed there is a trace inside the PCB (not on the visible/top layer), that shorts the pins, so no need for this resistor, you might as well remove them all and make the scope a little lighter ! LOL
- So I came back to my earlier idea : if I couldn't isolate individual chips safely, at least maybe I could narrow it down to a particular channel/bank of chips, by taking control of that 'CSA' line, coming from the MUX chip, which enables the entire bank of chips at once. There is conveniently a resistor in line, which I could remove. This would isolate all the chips from the MUX CS output and I could then safely drive this common enable pin at will. So, WHERE is this resistor ?
Couldn't find it anywhere... had to be on the UNDER side of the board, my luck !
Just what I did NOT want to do : touching these 8 tiny and fragile looking coax connectors so I can flip the board !
So before I did that and potentially did some irreversible damage to these connectors... I decided to at least try and confirm the existence of these resistors, and that they were not shorted or god knows what, again ! This scope being full of surprises...
So I used the ohmmeter, probing the top side of the board to blindly search for this resistor... and luckily I was able to demonstrate it's existence, YES, at last something that goes according to the schematics ! LOL.... or almost : it's not a 27.4 K resistor, no.. it's a 27.4 OHMS one ! What looks like a 'K' on the schematic, is in fact an 'R' with its head chopped off, go figure.
So, knowing that this resistor, and the hopes that were associated with the debugging it would allow, did indeed exist... I decided to take the risk to unplug/mess all these coax connectors.
- Debugging could commence ! I removed the resistor from Channel 4, just because it was the closest to me so was more convenient...
Then powered-up the scope, as soon as it had booted up, I ran to the utility menu to see the error log. This mod caused about a page and a half of new errors ! Sure I expected "some"... just not THAT many ! LOL Luckily most of them were memory related which made sense isn't it... But the most important were the last two lines, the very last lines... guess what ? Yep, there were my usual 2 R/W AcqMem errors again, at 0x7300000 and 0x7320000 (from memory, pun intended).
So this kinda demonstrated that I could isolate the faulty RAM chip this way. So, I kept going, disabling CH4 + CH3, still got my 2 usual errors. So disabled Ch4 + Ch3 + CH2.. still there. Great I thought, found it, the faulty chip is on Ch1 ! But, because I wanted to be real sure... I disabled Ch1 as well... juuuust... to see.
Glad I did, somehow : the errors would still show up ! Yes, even with ALL 4 channels disabled ! Then I spent quite some time doing more trials, trying out pretty much all 16 different possibilities of enabling/disabling channels. Not all 16 of them, but at least 10 that's for sure. The 2 errors would not go away.
- So at this point, it kinda implied that the root cause of the problem maybe was a bit more upstream. Still on the Acq board, but a bit more upstream.. or even why not, even further up, on the CPU board. After all the POST always displayed TWO error categories : "Acquisition" and "Acquistion / Processor".
So, from the start it kinda implied that maybe, just maybe, the problem was somewhere at the interface of these two boards, in some way.
Still, point is : it looked like the problem was not related to the RAM chips, it was now something vague that I had absolutely zero idea how to trouble shoot ! I thought I would probably end up with an expensive door stop, and cry. I thought with some luck, GPIB would be able to give me a clue/starting point, though I was not really counting on it, trying to be realistic...
So, since the GPIB cables are not there yet, and before I put the scope on storage while waiting for them to arrive, I decided to do 2 things, as a last, desperate attempt. First I reflowed the big MUX chips, and all 32 SRAM chips, just in case, though I was not holding much hope since they all looked quite nice to me. But why not. Then, I gave the underside a quick visual inspection, even though there is nothing on there but a bunch of tiny passive components, and definitely no bulky and leaky electrolytic caps. So I just didn't to see anything suspicious on that side of the board. Still, again, for good measure and because I was desperate....
As expected, not much to look at. I only noted maybe a small group of components whose solder joints looked less shiny than the rest of the board, but really nothing dramatic, at least with my naked eyes. So for good measure, I put some IPA on there, and scrubbed the components with and ESD safe "tooth brush", that made the joints looks a bit better. Then I reflowed all the area with my cheap and newly acquired hot air station... if just to justify its presence in my lab ! LOL
Really didn't think much of any of the above two actions. So flipped the ACQ board and reconnected all the ribbon and coax cables. Powered up the scope..... what do you know, clear POST and no new errors in the log ?!
Too good to be true, for sure ! So I put the cover back on, so I can have the thermals right and do some proper/further testing. Powered up the scope, started to boot, OK, graphics routines displaying funny things as always, no worries, OK... was eagerly waiting for POST to complete and tell me the result !!! ... but.... the boot sequence did NOT complete ! Halfway, the screen turned all black, and the scope froze in mid air ! WHAT ?!!! Oh no !!!!!
So, put the scope back on the bench, opened it up... turned out I had connected the 'D1' board upside down ! That's the board/"cable" that sends the CPU data and address buses to the ACQ board and the Video trigger board if you have this option. Yes, it is actually possible to plug this board the wrong way, and the scope WILL power up and start booting, it will NOT blow up... but it will never complete the boot sequence either. So just in case this happens to someone... no need to panic, just check that board ! LOL
So, corrected that, put the cover back on again, started it... OK works now, phew !!!!
POST is still clean but, hey wait a minute... there is not graticule on the screen, and no trace at all, what the ?!
Rushed to see the error log.... flooded with all kinds of weird and wonderful things ! NOOOOOO !!!!
At this point, I hesitated between committing suicide and/or throwing the scope out the window !!!
I was totally desperate. Then I thought hmmm... why not try that "Tek Secure Erase" thing that one of you taught me the other day, which did wonders.... and sure enough it did wonders ! That cleared all the errors, trace was back on the screen and all was fine again !
Retrospectively, I guess it was obvious : I had put the D1 board back to front so obviously the data and address buses, and lots of control signals of all kinds, were all mixed up. So no wonder this led to bags of errors, which I would later see once I had corrected my mistake and the scope had actually a chance to boot and display them. So since I had now corrected my mistake, all that was needed was to clear all these errors. Sounds logical afterwards, but in the heat of the action, trust me I could not think clearly that's for sure... I was overwhelmed by this feeling of helplessness and despair !
Lack of sleep didn't help either, I wasn't exactly at my best, at 5AM again.
So, cleared the errors, cycled the scope, a clean POST would follow, and still no new errors showing up in the log... looking good. Cycled the scope 2 or 3 times, still good. Did a quick sanity check on all 4 channels, displaying a 1MHz sine wave, trying all the basic stuff, looking good. So decided to give it a good run : I let it run/warm up for 8 hours, while I was getting some much needed sleep. When I woke up, scope was still running fine. Checked the error log, no errors were triggered during these 8 hours. Cycled the power, still good. Sanity check still good. So then I turned it off and let it cool down for about 2 hours. Then powered it back up again, still clear POST and no new errors in the log, sanity check still good. So.. I decided that I would call this a "fix" for now !!!
I mean, I don't think it's just shear luck ? When I was playing with the ACQ board, disabling/enabling channels for literally hours, I got my 2 errors EVERY SINGLE TIME ! And then, I reflow the chips, and brush up and reflow a few passives and all is well
I must have done something right ! Well, something that helped at least. I don't think it was reflowing the digital stuff that helped, because of everything I said above. However I think that the few passives I brushed on the underside of the board, are more likely to be the culprit :
1) When I looked at them with my naked eyes, they didn't look that bad. Sure not very shiny, but really nothing to write home about, or so it seemed. But I took macro pics of these joints just so I can document this thread, and because well.... I like macro PCB "porn", I admit LOL So, looking back at these components, this time on the PICTURES... boy, sure enough those joints were crap !!! Oh dear...
2) The corresponding area on the top side of the board, is actually in the analog section, the part of the board that got 99% of the damage from the electrolyte. There are like 2 or 3 dozens vias in this small area (like 10 square inches or so, see pictures), so maybe the electrolyte managed to seep into these via and get to contaminate the underside of the board this way. Don't know.
3) Analog part it might be (mostly a couple TL074 quad op-amps), but according to the schematics this affected area is none the less firmly involved with the acquisition circuitry (well, its the ACQ board, admittedly ! ). The sheet is named "CLOCK DAC BUFFERS & ACQUISITION CLOCKS".... these op-amps drive two fancy ECL logic chips that have to do with the acquisition clocks of all 4 channels, so surely must be important
So I could have left it at that and moved on... but that's not me, I needed more out of this repair... so I looked at the macro pictures and realized that one of the two TL074 chips had one of its side heavily reworked with lots of ugly flux residue, it seemed to me. No way I would leave the scope like this, so I pulled the cover again, cleaned that up, then realized that in fact there was flux residue all over the analog part of the board, the part that got the initial electrolyte damage. So I cleaned that up too, taking care not to damage the many tiny wires that had had been soldered in many places to repair broken traces.
Then I thought well, for extra peace of mind, why not check some voltages in this op-amp area, to make sure the scope is indeed feeling OK and not "on the verge, may fail again any time ! ". So I looked more closely at the schematic, that's sheet #20, then wanted to get a broader picture/understanding, so I rewound the signal path upstream, and landed on sheets #19 and #18. All 3 attached below, so you can follow me along.
I quite liked this section, found it interesting somehow (a mix of analog and digital, and simple text-book design that even I could understand), so I decided to do more than the bare minimum, and meant to spend say an hour probing around, once I had first ensured that vital signs were doing well. The service manual does not go component level, so if one wants juicy details, one has to probe around and figure out things by himself. So I did.
So, this section spans these 3 sheets. This is how I understand it : at the beginning (sheet #19), we have a DAC, U900. This DAC produces analog voltages for a whole slew of signals, 4 of them being the ones we are interested in here (sheet #20) : "ADLY, BDLY, CDLY and DDLY". The DAC output is symmetrical and has a peak amplitude of 10.24V. I checked, it's good. Uses a 10V reference as well, this one is good too (9.990V). The output is then scaled down by a simple voltage divider (R903/R904), then "buffered" by an op-amp wired as a voltage follower, as you do. Test point TP 912 at its output indicates 1.71Volts, I get that too, no worries.
From this point, this 1.7V signal is the analog source signal that will then be fed all over the place, to a bunch of analog 1 to 8 switches/demux, in the form of simple 4000 CMOS chips, 4051 to be precise. You can see one of them near the DAC of course, but also many more on sheet #18. So basically, the DAC produces various voltages, its output is constantly changing (see pictures) . The CPU drives this army of analog switches, and the DAC, in unison: it selects a particular analog line via these many switches, then it asks the DAC to produce the appropriate voltage for that particular signal, whatever it might be. Then, CPU switches to the next analog signal, asks the DAC for a different output, and so on, it goes round all the analog signals one by one, round and round. The switch we are interested in here, is U941, bottom right corner of sheet #18, so I probed that one. I probed its INH(ibit) pin, so I could see 1) for how long a particular output would be turned on and 2) the "refresh rate" of a given output : how often does the switch serve a given output/signal. See pictures below, from the Tek 2232. I didn't both measuring precisely using the cursors, I just wanted to get an idea, but you can see for yourself easily enough, the readout indicates gain and time base settings. So, it turns out that a given output is "ON" for about 60/65us, and is "refreshed" every 6ms or so. So it's "ON" only 1% of the time.
That's bad I thought... we want presumably a stable/DC voltage, not some chopped off signal ! My fears were soon to be cleared, once I switched back to sheet #20. Here we can see that the 4 signals, one for each of the 4 input channels of the scope, and the first thing see we see in the path, is a little 10nF capacitor, which I guess is all it takes to hold the charge/voltage steady, in between refresh cycles. Indeed I measured it, it's a perfectly flat/steady voltage, no worries. The capacitor symbol is a weird looking 3 terminal thingy. I thought well, must be some kind of special purpose component, designed for this type of application. Cool I thought, I will learn something. So I looked at the board, searching for a 3 terminal thing...nothing to be found, in practice they used a bog standard 2 terminal cap, nothing special whatsoever ! Was kinda disappointed.
Obviously, before going any further, first thing they did was again put a voltage follower op-amp, before doing any further processing. Then the next op-amp is wired as an inverting amp, again a text book example, which does some signal conditioning. It does 2 things at once from what I can see (other than inverting the signal, obviously) : 1) it scales the signal down, from a 3.4V span (+/- 1.7V again), down to a 1.5V excursion (from -3V to -4.5). Then it adds some negative offset, so that the signal is negative at all times. I measured that, works fine again. Have a -3.0V output for a -1.7V input.
And that's about it, we have reached the end of our little journey : this signal is then fed to the input of that ECL logic chip, which then turns this single-ended signal into a differential clock output. Multiply all this by 4 of course, for all 4 channels of the scope.
Now we can sit back and wonder about a few little things we noticed along the way :
1) The DAC appears to be 12 bits (12 bit wide data bus at least, according to the schematic), but looks like the CPU only uses 8 bits : the bus driving the DAC is only 8 bit wide : the upper 4 bits are repeats of the lower 4 bits. Well maybe the CPU is writing to the DAC in two steps, a byte first, then the remaining 4 bits. Haven't pulled the DAC's datasheet/dug any further (it's an AD 667 ) to see if it's a possibility.
However, the CPU is a 68020 IIRC, so full 32 bits data bus, so plenty capable enough to write the 12 bit word in one single step, why break it down into two accesses ? Less data lines on the Acq board maybe meant easier routing and /or less digital noise to deal with, especially since that DAC is in the middle of the sensitive analog area of the board, so it must keep it quiet so to speak, I guess
As always, any knowledgeable input is most welcome !
2) The DAC outputs a symmetrical 10V signal, but I don't see any negative supply voltage going to it ?? I only see the positive 10V reference voltage, which I measured. There is a capacitor connected to it though, so maybe, just maybe but I find it very unlikely, it uses a charge pump MAX232 style, to produce its negative 10V by himself, locally ? Silly I know, forget I said that ! LOL
3) "our" analog switch, U941, uses only its first 4 outputs, so technically you only need the two lower order select pins, the third select pin can just be tied to ground, but go figure they decided to drive it anyway ?! OK, out of 7 switches, it's the only one that doesn't require all 3 select inputs to be driven, so maybe they just wanted to rationalize/streamline the routing/design, I don't know.
Anyway, I quite enjoyed working on my scope, love it more than ever now that I saw its guts up close and got my hands dirty, and am glad I could fix it.
Goes to show that indeed, a thorough visual inspection is the first thing to do, always. Alllllll- ways. That said, again I could not see much with naked eyes, I just got lucky. It definitely motivates me to get a microscope (meant to anyway) so that I can easily look at solder joints in detail and not miss any thing. Had I had a microscope, I would have taken the board out of the scope first thing, and inspected it from edge to edge, and sure enough I would have spotted these horrible joints right away, in a matter of seconds, no dicking around for weeks or months, chasing red herrings again (my specialty, trademark ! LOL ) like these RAM chips or whatever else might have been next !
So if the scope fails again, I will go straight at this ACQ board again and inspect all the joints really, really well. Hopefully by the time it fails (though there is no obligation to do so, please, little TDS ! LOL ), I will be better equipped. My lab is still in its infancy, getting a bit better by the month, but still ways to go.
Time for the attachments. I put a pic of the underside of the board, highlighting the area of concern/dodgy joints, in red. Also a pic of the top side. The red area corresponds to the red one on the underside of course. There you can see the two Quad op-amps TL074.
In yellow it's the area that initially got damaged by the electrolyte. This is where the chap who fixed the scope prior to selling it to me, had to do a lot (a lot) of rework/fixing. So that's all over this area that I found flux residue, which I cleaned. In light blue is the area corresponding to the section spanning the 3 schematic pages that we just "studied"/probed, i.e. the original red area + some more.
So this is it, scope is fixed ! So now I can switch to the more "fun" stuff : connect to the GPIB port as soon as I get my cables, so I can :
- recover the FFT feature / Advanced Math / Option 2F , which is supposed to be standard on the 544A I gather, but which somehow is missing on my particular scope ! I hear it's just a bit to flip in the NVRAM, so let's do that. Try at least.
- see if there are some more cool options I could activate via software.
- back-up my firmware which is revision 3.8.3, and upgrade it to the newest revision : I see on KO4BB site, that there is a 3.8.4 release. No idea what got changed in that release, though ! Any idea ? There is just the FW image, no accompanying "Readme" file.
- see if there is some hack available to improve the scope. I seem to remember that this scope can be upgraded to 4GS/s sampling rate ??
- As for analog bandwidth/front-end, I saw somewhere that a simple H/W hack (adding 4 resistors on some existing but unpopulated footprints, somewhere, (Attenuator board I guess...), is all it takes to upgrade from 1GHz to 2 or 4GHz can't remember. Sounds too good to be true but well, if Rigol did such things, why not Tek at the time....
I guess it makes sense to design for the high-bandwidth scopes, only one front-end / R&D cost to pay for, then limit it artificially on the lower end/cheaper scopes, rather than design a purposefully limited/lower spec front-end.
However I don't recall if this applied to the 500A series, or the 700 series, not that I know what are H/W differences between a 500 and 700 anyway, or with the 600 series even, for that matter ! Still a lot to learn eh...
Home
Help
Search
Login
Register
