Keithley 199 repair FIXED another one

[samofab]

Hello everybody.

A while ago I bought a badly beaten Keithley 199 from Israel. I found it hilarious that I used hammer to fix a precision instrument, but none of the internals were broken and after a good hammering it powered on and all of the functions worked. In addition it seemed that it is within spec as far as I could test it (<0.09%).

It did have one problem, and that was that it displayed UNCAL when powered up and refused to save any settings when powered off. I thougth to myself: just a broken E2PROM - order a new one a I have a fine instrument (i did check the usual suspects before: supply rails voltage, noise, signals on PROM). Well, it turns out that replacing Xicor X2816C doesn't help - it still didn't save any settings (in addition beeing completely uncalibrated with empty PROM). So I put the old one back inside and used the instrument as is. It was slightly annoying, but for observing small current changes in microcontrollers it was perfect. And you can read the display from the next building :-D

Still it bothered me and as I had some free time, I hooked up signal analyser and tried to figure out what is its problem. Turns out that data and address lines are pushing data around and that timings on OE, WR and CE required for writing to PROM look within spec.

The only possibly weird thing is signal from PAL address decoder to CE - see attachment, all other signals are nice squares when using oscilloscope.

When saving settings (GPIB address, line frequency and MUX) there isn't a lot of data to push to PROM, but my OpenBench logic sniffer makes it hard to look at it as Keithley is writing a byte every 100ms. The first four bytes are 0x00, 0x0, 0x0, 0x01, I doubt that there are many more (write cycle finishes in less than a second).

Does anybody have any ideas? Am I looking at completely wrong place?

[staze]

Boy that's some noisy data. So, where is that scope trace taken from?

Since I recently fixed my Keithley 199, I kind of wonder if it might be a similar issue. Mine, the hex inverter between the analog and digital board was bad, and producing crap. But, I'm guessing that's not bad in this case since the meter works, you just can't save data to the eeprom.

Do all the voltage rails check out fine (again, guessing so since the meter works)?

[samofab]

Scope trace is taken from pin 15 of PAL address decoder wired to CE input on PROM. All of the other outputs on PAL are nice signals.. I'm wondering how PAL's fail... Because if this one failed, it did so in a very non-destructive way as reading from PROM wouldn't be possible without working CE. Signal is suspicious, but I doubt that this is the root of the problem. Trouble is I have nothing to compare it to. Perhaps it is normal for CE signal to occur once every 100ms on write. And even though it's an ugly signal, it's still above treshold for logical 1 all the time (.. when it should be).

If you have a working K199, perhaps you can put the scope to this pin and see if behaves similiary when storing settings.

All of the power supply voltages are fine, even when measured directly on the chips - no significant noise or voltage drops.

It's a complete overkill, but without a better logic analyser, I'm thinking of wiring a microcontroller to data pins and dump the exact bytes that get written (should get written)...

Thanks for reply...

[staze]

Scope trace is taken from pin 15 of PAL address decoder wired to CE input on PROM. All of the other outputs on PAL are nice signals.. I'm wondering how PAL's fail... Because if this one failed, it did so in a very non-destructive way as reading from PROM wouldn't be possible without working CE. Signal is suspicious, but I doubt that this is the root of the problem. Trouble is I have nothing to compare it to. Perhaps it is normal for CE signal to occur once every 100ms on write. And even though it's an ugly signal, it's still above treshold for logical 1 all the time (.. when it should be).

If you have a working K199, perhaps you can put the scope to this pin and see if behaves similiary when storing settings.

All of the power supply voltages are fine, even when measured directly on the chips - no significant noise or voltage drops.

It's a complete overkill, but without a better logic analyser, I'm thinking of wiring a microcontroller to data pins and dump the exact bytes that get written (should get written)...

Thanks for reply...

I'll see if I can pull my 199 off my bench this weekend and scope that pin. I'm guessing it should look better than that...

weird.

What are you grounding off when measuring? hmmm.... I'll take a look at the schematics too... but yeah, that does seem weird. And I'd obviously assume you're using a 10x probe, and 1M scope termination (just making sure the scope isn't dragging down that pin).

And sorry, what is the designation of the PAL? U1? Have you checked C1? Or any of the other pins out of U1? I'd be curious if any other pins are showing bad signals. It also looks like pin 23 on U8 should be a clock? Same as pin 16 on U1 (the PAL). I'd be curious how that looks. Pin 17 should also be a clock, that feeds U16 (74HCT374 pin 11), and U15 (same pin, logic chip).

Actually, looking at the schematic, I'm kind of curious about U17 (74HCT02). Looks like it controls the reset, as well as the NVRAM write enable.

All that said, I'm just stabbing in the dark since I didn't deal with the digital board much on mine. But I'll try to check pin 15 on U1 when I have a chance. I just kind of wish U1 wasn't such a black box...

[samofab]

When measuring, I'm grounding the probe on the nearest chip ground. So in the case of U1, I have ground on pin 10. Using x10 probe. All of the other outputs on U1 are nice squares.  I also measures power supply with oscilloscope exactly over pin 10 and 20, which corresponds to C1, too. No way to be really sure if C1 is OK unless I take it out, but I reckon that bad C1 would produce some artifacts on the power line directly on the chip.

PAL's are not entirely blackmagic. They are stateless in the sense that if you have 10 inputs and 8 output, all you need to do is walk all input combinations and record the outputs.. not that it helps in my case as I'm not sure if it works correctly :-D (And I'm not really an expert, I might be completely wrong..)

Pin 23 on U8 is not clock, but the same CS (chip select) system that tells the chip that address/data on the bus is intended to it. Well it may work as a clock in the sense that its transition from low to high is used to latch data (not sure if that is the case on this particular chip). (again nice squares on this pin with oscilloscope).

I was thinking about the function of U17 and I think that it partly reponsible to make sure that writing to PROM is disabled on power up. There is a combination OE/CE/WE mentioned in the datasheet to this effect. Beeing a simple gate, I checked it and it most certainly works as it should.. NORing all the way :-D

I'm thinking of pulling U20 out and see if the weird signal persists (PAL may not be guilty). And while I have it out of the board, I might as well find a programmer to read its contents and write them to the spare PROM that I own.

Anyway, if you would be so kind to look at that signal and tell me how it looks on your end, that would eliminate a lot of guesswork. And I'm principally not interested in the analog domain, but how this signal behaves when writing.. will you see the same single drop to 0 on start, and then 100ms of silence, or is it supposed to push out something more. I guess in principle that it might be possible that PAL got one additional fuse blown in the course of its heavy life and that there are two side effects: weird signal in analog domain and more importantly: decoding less than it should.

[macboy]

I've attached a set of traces from one of my 199's which is in good working order.
There are 4 traces, basically one trace for each of 4 consecutive triggers. The levels are roughly 0 and 5 V and there is little noise. I measured at both U1 pin 15 and at U20 pin 18 with exactly the same result. I also noted that the /CE line is toggled whenever the instrument reads or writes (not only on writes); this is as expected. I hope this helps.

[samofab]

So the pin 15 of PAL address decoder wired only to CE input on PROM. And thanks to mcboy I now knew that logic signals on that pin are OK. So I cut this trace and looked at the signal on the pin with oscilloscope. It was a nice signal. I reattached the trace and pulled out the PROM and looked at the CE pin.. signal was nice again. That left me with the only possible explanation that PROM is bad (which was my initial diagnosis years ago).

I already tried to replace it with no success, but I still had the spare one and I didn't recall beeing very thorough. As I recall I replaced the PROM, tried to save settings and power cycled the unit. So I replaced it again, checked the signals: they were all nice. Tried saving settings to no avail. Then I went trough calibration precedure for 300mV, 3V and 30V ranges... powered the unit off and voila! the calibration held. Then I tried to save normal settings and it worked.

So there you have it.. 100 years data retention period gurantee by Xicor is invalid :-D it was PROM all along.

I guess now I have to find somebody here in Slovenia who can calibrate it for free :-D It would be very interesting to see how stable is it in the long term after my torchure and  some 23 years of  service.

I'll post some pictures before I close it up.

Thanks everybody!

[macboy]

That is great news and I am happy that I could help.
As you know, the calibration is done electronically (no trimmers internally) and is not too difficult. The basic accuracy of the meter is about 0.007% (on DC). If you can find someone with a meter that is at least 6.5 digits and 3 or 4 times better (0.002%) and known to be "in calibration", then you can use that as a transfer standard. A true "volt nut" would not think this is good enough, but for hobby use it surely is.

[alm]

You also need voltage and current sources with sufficient short term stability. My experiences with cheap bench supplies haven't been too great. Getting anywhere close to 300 VDC is quite tricky. You can calibrate using any arbitrary value, so you can use a stable 273.93 V source, but calibrating the 300 V range with 24 V won't be good for accuracy. AC gets more interesting, since you need frequencies up to 300 kHz or so, at voltages up to 300 Vrms (though not both at the same time). A stable 3 Arms 1 1kHz AC current won't be trivial either.

I have rigged up stuff with bench supplies put in series, function generators and power resistors (I don't care about accuracy, and heating will be much lower, so less drift) in the past to do a performance verification. I wouldn't do adjustments based on such contraptions if I could help it, though.

If that's all you got then so be it, but don't expect great accuracy.

[flolic]

This morning my beaten Keithley 199 arrived from Israel too (for less than 3 days from Israel to Croatia!  )
It has the same UNCAL problem, so hopefully will be easy to fix 

[samofab]

In the mean time I managed to convince guys at   http://www.siq.si/ to calibrate it in the name of science and curiosity (and goodwill) for free. And we will repeat the procedure in a few months to see if holds to specification.

I promised some pictures and here is one :-D Hooked up to HP 6632B which was likely calibrated a few years ago by its Finnish ebay seller - I didn't expect to see numbers match like they did.

[flolic]

While waiting 2816 EEPROM to arrive, I created this contraption 
It is Li Ion battery powered Hyundai 6264 SRAM memory. I copied calibration data from "dead" EEPROM to it, go through 30V range calibration on dmm, and my old Keithley is now working as new 

[samofab]

Beautiful! 

[macboy]

Glad to see that the 199 is up and working. They are a great instrument.
I've had one for a few years, and I picked up another off eBay about a year ago "for part/not working" for only $20. It wouldn't take any readings, only display "------". I took a chance (at only $20, a small risk). So what was wrong and how did I fix it? I pushed the Trigger button!  The only fault was the previous owner's lack of knowledge on how to use it. It needed a calibration for better accuracy but then it was perfect. You don't come across deals like that often.