Keithley 197 LED display Hack

[rastro]

This is my initial attempt to retro fix a Keithley 197 bench DMM with a LED display.  These units use LCD which is non-back lit for the 197 and marginally back lit for the 197A models.  This might also be adapted to the Keithley 175 since they use the same LCD driver chip (NEC uPD7225).

The hardware I'm using is an Arduino Nano V3 and an 8-Digit LED module from eBay.
http://www.ebay.com/itm/131045999957?ru=http%3A%2F%2Fwww.ebay.com%2Fsch%2Fi.html%3F_from%3DR40%26_sacat%3D0%26_nkw%3D131045999957%26_rdc%3D1

The nano using SPI hardware reads the 15-byte control transmission from the CPU to the NEC uPD7225 and remaps the 8-LCD segments to the 8-LED segments.
I have also decode the status light bit map so hopefully I can rig-up all the mode status indicators. 

Currently I just have the 6-digit display along with floating decimal and negative sign.  Any alpha characters sent to this part of the display are also rendered.
I'll attach a picture of the LED module running in parallel with the units display.

rastro

[Smokey]

This is really cool.  Good job.

[rastro]

Thanks Smokey.

I thought I posted some additional information.  Apparently it did not get posted.  So here's a re-post.  I'm also attaching the Arduino sketch.
One other wrinkle is I'm running the SI (serial in) through a 100pF cap to D13 on the Nano - Otherwise the DMM seems to hang at power up.  Alternatively if I leave D13 disconnected during power cycle and then reattach D13 works normally.  Perhaps this has to do with the unknown state of the nano's pins during power initialization.  This requires further investigation the capacitor is a working kluge for the moment.



Project to replace (DMM) Keithley 197 (175?) LCD display with LED driven display.
Although this is specific for the 197 the 175 CPU also uses the same display chip and 15-byte display update.
Hardware: Arduino Nano V3 and 8-Digit LED module (uses 2 74LS959 shift registers)
Seven of the 8-Digits is used to display the decimal, negative-sign, and six numbers.
The 6 digits assigned to the numbers are also used to display alpha-numerics - same as original LCD display.
The program captures SPI data stream between the DMM CPU and original driver chip and remaps the bits to the LED display.
In normal operation 15 bytes are sent for each display update to the units LCD driver chip (NEC uPD7225)
0 through 4 are configuration instructions for the  LCD driver chip (NEC uPD7225) - data not needed* for LED display
5  mode indicator lights
6 through 12 represent six alpha-numerics with floating decimal point
13 mode indicator lights
14 mode indicator lights
One known exception* is during self-test (power-on unit while pressing "dB" key) the CPU only sends 7 bytes during display test
This program recognizes that self test condition by looking at the first control byte 0x30 is normal mode 0x20 is display test
During display test the program uses a diffent indexing scheme when accessing the captured data array

Mode Indicator Lights Bit Mapping:
Byte  Bit        7       6       5       4       3       2       1       0
----  ----------------------------------------------------------------------------
 05             "-"    "BAT"   "REL"    "AC"   "dB"    "STO"   "REL"   "AUTO"
 13                           "m"Amp   "K"ohm   "V"    "u"Amp  "M"ohm  "m"Volt
 14                                                    "A"     omega   

The current program version only dives the 7-digits of the LED display;
For development purposes dumps of the 15-byte display control in hex format is sent to a serial monitor via the nano's USB
FOLLOW UP:
1) Map mode indicator lights to unused segments of the LED display module.
.. The LED module has 15 unused LED segments which can be used to drive free standing LED's representing each indicator
.. Initial tests show that the 74LS959 can drive a small LED in parallel with it's normal segment
.. Reallocated LED segments can be blacked out to avoid distracting from numeric readout or possibly hacked/removed.
2) Hardware implementation possible PCB to replace drive PCB assembly - need to accomodate 4 units 4 mode switches.
3) Compatability with 175? 
.. I suspect it's very similar just ignore one of the digits being sent
4) Port program to use Pro Mini atmega328 - smaller foot print/no USB

WIRING LIST
Nano_V3      DMM(J1006)      LED_Module    Description
4 (GND)                      1 (GND)       GND to LED_Module
10 (D7)                      4 (SCLK)      Serial Clock for shift register
11 (D8)                      3 (RCLK)      Latch data for shift register
12 (D9)                      2 (DIO)       Serial Data In
13 (D10)    14 (CS)                        Chip Select for DMM display chip
14 (D11)    13 (SI)                        Serial In for DMM display chip
15 (D12)                                   No Connection SPI MISO signal is not used
16 (D13)    12 (SCK)                       Serial clock for DMM display chip (acitive LOW)
27 (+5V)                     5 (VCC)       Power for LED_Module
29 (GND)    04 (GND)                       GND for DMM display chip

[Smokey]

I've got a couple of these meters.  This would be a really cool data logging method if they were missing the GPIB option.

[rastro]

I agree, logging would be a good feature.  My current setup is only mapping the segments - not interpreting any decimal values.  There are some technical reasons for going this route.  However converting the segments to decimals is certainly possible.  In fact the raw HEX data is already available on the nano's USB port and can be seen on a serial monitor. 

A more intriguing possibility is communicating with the DMM's CPU through the J1008 plug that connects to the GPIB option PCB.  The GPIB option Model 1973/1972 includes a top cover and PCB but doesn't appear to have an update PROM.  This suggests that the facility is already available in the non-GPIB unit.  However it would probably be helpful to have a GPIB unit in able to monitor the 2 communication pins on J1008 in order to understand the protocol.  Then it may be possible to achieve the same GPIB functions with an emulator such as the nano.

Right now I'm going through a learning curve with KiCad since any prototype PCB will be larger that Eagle (free version) can produce.

[timb]

I’ve got a 197A with the GPIB option installed. I’d be more than happy to help reverse engineer the protocol! In fact, it’s something I’ve thought about doing in the past but just hadn’t gotten time for. (I’m already finishing up a LiPo Battery controller to replace the factory NiCad pack option.)

The nice thing about the GPIB board is you don’t even need to hook it up to a GPIB controller to get data, as the 1973 also outputs a 0 to 2V voltage signal that’s relative to the range you’re in; that indicates the board is getting data regardless of the GPIB status! (That analog output was designed for chart strip recorders or enabling you to easily take high voltage or current or resistance measurements with an oscilloscope.)

Anyway, from memory, it’s just a serial interface of some kind (only two signals and it *must* be bi-directional). The first four pins of P1008 are 5VD, DGND and an auxiliary tap from the transformer. The 5VD line powers the sending side of an optocoupler for one of the two data lines; the board itself has its own bridge rectifier, filtering and regulators. (This is required for the high level of galvanic isolation required by the IEEE-488 specification.

So, I imagine that we could not only *read* the meter, but also fully control it as well! Imagine designing a USB interface for a 30 year old piece of test gear? This could be awesome!

[timb]

Okay, I probed the signal from the 197A’s MCU to the GPIB board! It seems to send a burst of data every 350ms or so:



Here’s one of the data bursts in full (4ms/div down from 200ms/div in the first image):



Finally, here’s two different locations zoomed in to 200us/div:





I also dumped two of the captures, if anyone wants to have a look. The voltage on screen of the meter at the exact time of Sample A was 4.9975V; Sample B was 4.9976V. I figure knowing the voltage might help decode how the data is sent.

Sample A - Ch. 1 - 4ms/div - 125K Samples - CSV Format - 3.3MB

Sample B - Ch. 1 - 200ms/div - 1.25M Samples - CSV Format - 33.3MB
Warning: Sample B is a large download!

If anyone wants specific probes under specific conditions, let me know!

By the way, I think I’ve found a really nice OLED display that’s the *exact size* of the original LCD. I’m thinking this would be the best course of action as you can easily replicate all the symbols and such.

[hugo]

"By the way, I think I’ve found a really nice OLED display that’s the *exact size* of the original LCD. I’m thinking this would be the best course of action as you can easily replicate all the symbols and such."

Do you have any updates ?
What is the model of the OLED display ?

Thanks

[tooki]

"By the way, I think I’ve found a really nice OLED display that’s the *exact size* of the original LCD. I’m thinking this would be the best course of action as you can easily replicate all the symbols and such."

Do you have any updates ?
What is the model of the OLED display ?

Thanks

Indeed, this would interest me, too!

[tooki]

We really need to get something done on this -- it seems to me it would be entirely feasible to roll a brand new PCB to replace the original one. I'm still a noob, but if I can help somehow, I'd like to!

[rastro]

Just posting some additional information prompted from an email information request.
Picture of Nano V3 hooked up to ribbon cable connector  going to display chip.
-- Also some of the wires also go from the nano to the targeted LED display.

I am not actively working on this project and haven't really looked at the code in over a year.
I am going to post 2nd and last version of the arduino sketch if it helps.  It is renamed to a .txt from .ino because otherwise I gets rejected when I post it.

[rastro]

Here is the LCD Driver chip (NEC uPD7225) data sheet.