Replacement display board for Keithley 197A

[alx2009]

The Keithley 197 / 197A is an old 5.5 digits bench multimeter. You can read about the multimeter here: https://www.eevblog.com/forum/testgear/keithley-197a-owners_-corner/

The meter is quite good but often the LCD display starts to fade, due to the zebra strip contacts failing, as documented in the previous thread. My own meter started to suffer from this problem. It can be mitigated temporarily, but eventually it reappears. I like this meter so I am looking to design & build a replacement display board.

Luckily rastro reversed engineered the display protocol (see https://www.eevblog.com/forum/projects/keithley-197-led-display-hack/msg493365/#msg493365), which makes the job a lot easier. Another forum user, Technogeeky, implemeted a decoder running on an Arduino https://github.com/technogeeky/keithley-197

this work inspuired me to build my own replacement board and I intend to document the design here. So lets start with my main requirements:
   - Must fit inside the case of the instrument without too invasive/ugly alterations

   - Given the effort, I want to add some new functionality. At a minimum data logging via external interface, serial or usb and a continuity test mode

   - I want to be able to update the SW without opening the instrument. This means it must have an external interface for programming

   - Another common problem for this meter is that the cluster of buttons at the left of the display require quite a lot of pressure, and it is getting worse. I wan tto improve that as well.

   -It should not cost more than a new instrument of the same class/capabilities... so obviously no fancy custom displays 

   - And last but not least, it must be safe! among other things, this means galvanic isolation of the programming/datalogging interface and due consideration for isolating the new display.
 
Ok, so what is the first step? Well, my experience with other projects is that developing on the instrument itself is not ideal. A mistake can damage the multimeter. Not to mention the hazard posed by the exposed mains and the fact the ground of the board under development is shared with the device under test.

I usually prefer to use a simulator, and verify on target occasionally until the design is mature (and hopefully safer to work on). In adition, a simulator can improve the stress testing (e.g. I can change the timing to make sure I have a good margin).

The good work done by  Rastro, Technogeeky and the information on the forum allowed me to design a simulator pretty quickly. I have used an Arduino nano on a breadboard. The original display board connect via a ribbon cable with a 16 pin IDC connector with 3x row spacing, like they have made it to fit on a breadboard - or more likely on the DIL 16 socket used in the multimeter

The picture below shows the simulator connected to the original display board:

Via serial monitor you can turn on and off any segment in the display. The image shows all segments turned on (which is unlikely to happen in practice, but I may want to test nonetheless).

I also connected another Arduino running the Technogeeky code (with some modifications suggested in the forum posts above) and it works (forgot to take any image, sorry)

I have published the complete simulator sketch, schematic and fritzing breadboard view on my gitHub: https://github.com/alx2009/displayBoardTester

Questions, comments and wishes for next posts are welcomed :-)

Otherwise in the next posts I intend to discuss the choice of the key components (display, microcontroller) and the overall design of the replacement board (actually boards as we will find out).

[free_electron]

The button problem is well know. take the pcb off, clean the pcb with alcohol and let it dry. most likely it will be solved. you can rough up the carbon contacts on the rubber membrane with a pencil eraser.

[alx2009]

Thanks free_electron for the comments! They are good tips, and they work - for a while. I have also use graphite spray as in my case the problem was more on the key itself than the PCB. That worked for more than a year, but now a couple of keys are acting again...

If this was the only problem I would probably clean the PCB/apply more graphite and continue. But I am going to replace the PCB anyway so instead I am going to use MJTP1140ATR SMD tactile switches from Apen, which I got from Digikey: https://www.digikey.se/short/rqn9h5mm

They are small enough that they fit perfectly under the original key. I have done a preliminary test and they seem to work quite well, adding a clear and satisfying feedback when the button clicks.

As it happens, the terminals have exactly the right size to be soldered on top of the original PCB contacts. So if someone is not satisfied with the other workarounds, this could be an option. Most likely there is a need to add spacers to account for the extra height, but not much: the switch itself is 1.5 mm thick but there is some play between the key and the PCB. Adding a spacer on the order of 0.5 mm should suffice, maybe even less. I have bought an extra button, so I can do a test if someone is interested.

[Brian of Romsey]

Hi,

  What a great project.  I have a 197A and would like to be considered as a beta testing site (I am in the UK now but may later turn up in Australia).  Happy to pay for things.

  Have you considered using the ESP32-S3 which would allow for adding Bluetooth connectivity at a later date?

  Thanks, Brian.

[tooki]

Great project, by the way. I’ve been meaning to do the same thing, once I have the time…

Wouldn’t tactile domes, or even thinner switches, be a better option than these switches and spacers? You can get ones under half a mm thick!

I don’t see how you could add continuity mode via the display. The update rate is what, 3-5 times per second? That’s useless for a continuity tester.

For data logging, it certainly seems to me like the GPIB option might be a better place to start. But it would work all the same. I’d skip a galvanically isolated electrical connection and use wireless, like Brian of Romsey said, if testing shows it doesn’t cause interference in the meter. (With the ESP32 on the display board, it might be too close for comfort. But if divided into two boards — an MCU board installed in the rear, where the original display cable plugs in, and a new display board — it’d probably be safe!)

[alx2009]

Thanks for the previous comments! The design is not made in stone at this point, and I was already thinking about adding Bluetooth or WiFi for datalogging (not sure about programming). I was concerned about noise so I didn't include in the requirements. Anyway, I like the suggestion to have two boards: one in the front with display and micro and one (optional) in the back with more options for variuous interfaces.

I will come back on this as well as the buttons, for this post I would like to focus on the display, which is what triggered everything.

Initially I looked at a custom display but I could not justify the cost. Then I considered using three 0.96" oledsin a row. I did some tests and I found some displays that could be mounted close enough. But then I found this oled display on Aliexpress: https://www.aliexpress.com/item/33013330192.html?spm=a2g0o.order_list.0.0.21ef1802HXu3oJ

It's a 2.8" 256*64 monochrome discpaly based on SSD1322. The display area is slighly smaller in the horizontal direction and slughtly bigger in the vertical direction, but only for a few pixel. The interface is SPI (once you move a few 0 ohm resistors) and is supported by U8G2 (https://github.com/olikraus/u8g2)

Here are a few pictures that I hope will show how I plan to mount the display on the PCB.



The white board you see in a picture is a mock-up based on current Kicad design. I am also including a perspex window between the display and the front panel, as I do not trust the display to provide the required isolation (there is no way enough clearance betwen the metal case of the display and the nearest track of the PCB).



Here you can see how it all comes together.



Side view of the assembly PCB + display. The plastic screws are not the ones I will use, and I will add suitable spacers in between, to avoid bending the PCBs. But I hope you can get an idea.

[alx2009]

Some more details...

In order to mount the display module as flush to the PCB as possible, I removed the plastic bit on the connector:

 
Here is a detailed picture of how the stack front panel/display module/PCB looks like:


as you can see, compared with the original display, the display module + perspex is a bit thicker than the original display assembly. Hence I need to add some extra spacer, as seen here:


About the buttons

This extra distance explains why I plan to use the Apen switches I mention above. They add the extra tickness I need to make up for the extra gap due to the ticker display assembly. Since I like their tactile feeling, I stand by my choice

That said, if someone see an advantage with the tactile domes I am interesting to hear. I thought about that initially and did some search, but didn't find something that would fit the space available and at the same time would be thick enough (possibly because I don't have any experiance with them, aside having see Dave's video).

If someone want to just replace the switches, there may be better choices of course.

[alx2009]

Ok, vacations and some business travel got in a way... but I am back now.

Some consideration regarding the power budget. We are replacing an LCD which doesn't consume much with more power hungry stuff. So this need to be addressed.

The K197 main board has a number of power rails, but the only one that is suitable is the digital +5V rail, readily available on the display connector. In the K197, the LCD display consumes a few uA. I have the A version, where the same +5V rails powers the backlight via a current limiting resistor. In my instruments I measured 50 mA current for the backlight. So this is the safe level for my power budget. As far as I can see the power supply of the 197A is the same as the 197, with the addition of the backlight current limiting resistor,  etc. So this should also be valid for the 197.

Looking at the K197 schematic, I expect to be able to draw a bit more, say up to 100mA without causing excessive ripple. However, the transistor doesn't have any heatsink, and it is already warm as it is... so I would not trust drawing more than 100mA.

From early test with the display, I measured a peak consumption of 83 mA + micro (AVR64DB28) while running the u8g2 display test example. So we are ok, I think. But I am not sure I would trust adding a ESP32, as I expect it to draw an extra 200 mA or so. But perhaps a dumber bluetooth moduile would be ok (I plan to do some tests with an HC-05).

Another possibility would be to use the additional  secondary, which is available via the IEEE board connector, for Bluetooth. But that would add significant complications, also considering that the power switch on the front panel does not turn off the IEEE secondary winding.

[alx2009]

More on the other component selections, mainly the micro. As mentioned, I am testing with a AVR64DB28. This is a modern AVR, suppoported by dxCore (https://github.com/SpenceKonde/DxCore).

I started to look at the DB series because I was planning to re-use the AVR code already available, but I wanted to have a bit more flash and RAM (due to the graphic display). Searching on Digikey the DA and DB series looked like the best option from price and availability point of view (at least at the time). As a bonus, the DB series offers additional features that are quite useful in our case:
- No need for a crystal, the internal oscillator is more than good enough, even at high baud rates.
- One port in the DB series can work at a different I/O level from the rest of the chip. This is useful because the Keithley works at 5V but the Oled needs 3.3V.
- They have 2 independent SPI buses (which we need due to the different I/O voltage as mentioned above)
- it is possible to limit the slew rate of the output pins. This could help reducing the switching noise if it becomes an issue.
- low power consumption, in line and improving on the classic AVRs.

Plus a lot of more features (and peripherals) that we won't need... but they are nice to have (and may be useful for future projects).

The AVR64DB28 has 64K flash, 8KB of RAM in a breadboard friendly 28 pin DIL package (SOIC also available). If we find that we need even more flash/RAM, we could swap the chip for a AVR128DB28 (which doubles the flash and the RAM). 32, 48 and 64 pins packages are also available.

I also bought and tested a 128DB64, as initially I had some ideas that would have required more pins. But at the end the additional complication wouldn't have added any really useful functionality, so I scaled back my design considerably. In the next post I will present the current prototype and its schematic.

[coromonadalix]

i would focus to make something working before adding wireless stuff etc..   easy to get lost in ideas

If the source code is released, others  will be able to add the options they needs  loll
 

[alx2009]

I am planning to release the current SW soon. I just need to write down some of the key design decisions before I forget them :-)

Coming to the schematic, the AVR doesn't need much, it is a development board on a chip. In addition to power, a bare bone implementation would require only 7 connections to the micro: MOSI/SCK/CS from the Keithley main board and MOSI/SCK/CS and DC to the OLED. You could even use a single SPI bus in mixed master/slave mode at 5V, albeit in that way you would run the OLED outside specs.

The SW could be loaded with the chip on a breadboard, or connecting the UDPI programmer directly to the required pins using micrograbbers.

My schematic is a tad more involved, partly because I need to develop the SW, partly because I want to filter the buttons in the SW. I will release the Kicad project on my Github, but for now I have attached a picture at the end of this post.

I have a UDPI header for loading the booltloader and as a debugger interface. For programming via bootloader and serial output I have added a header for the USB to serial, with a second row of GND pins for future connection to the bluetooth module (it will be located in the back and then it is easier to use IDC connectors). A reset circuit (with autoreset from the USB adapter) and led is nice to have when developing SW. The circuits come straight from the AVR datasheet with the addition of the autoreset capacitor and the led.

The button cluster is connected to the AVR (PD5, PD7, PF0 and PF1), using the internal pull-ups. The button presses are passed to the Keithley via PD1-PD4 (transparently for now, but I may do some processing in future revisions). Admitedly, this may not work for entering the self calibration, since the buttons need to be pressed before power up. I am betting that the AVR will be quicker but I have not yet tested this. If it doesn't work I may need to review this part of the design.

I have added a 1K resistor on all connections between my board and the Keithley main board, in order to protect the instrument from programming mistakes, shorts while probing and such...

I do not show the power supply and decoupling but they are straightforward (I am using an APH 2114 3.3V. Overkill but it's what I had available, and it does the job).

[alx2009]

Ok, some pictures of the prototype, then a few more tests and the next post will be to announce the availability of the first SW beta on Github...

As mentioned before, my initial idea was to build a PCB and order from the usual PCB factories. However, the current design is simple enough that I thouight I should build a prototype at home first. I also wanted to try a new technique I have seen on a youtube video.

The first picture is the PCB after being engraved (manually).

I made a few mistakes along the way, but the final results still serve the purpose.



And it works as visible in the last picture. As a first release, I am just replicating the original functionality. I want to have that working before even attempting to add new stuff.

I have the board installed in the meter and working with just a few minor bugs. I plan to release the SW within the week!

[MikeK]

That's a good looking display.  I'm working on replacing the display in my Fluke 8050A with a cheap TFT, but I'd prefer your display if it wasn't so pricey.

[alx2009]

I am pleased to say that the SW is now released in my GitHub: https://github.com/alx2009/K197Display

 

Just be aware that it is not intended for production, yet :-)

That said, I did test it with all ranges and features. It works reliably, except I cannot enter the test mode (press the dB button and power on). This is due to the delay introduced filtering the push buttons, especially with the bootloader waiting 1s at the start.

There are a couple of solutions I am going to try, but I think I should release the SW nonetheless so you can play with it...

[Brian of Romsey]

Any chance of a short video (five to ten seconds) of the display in action?

Thanks, Brian.

[alx2009]

Here are three videos I just recorded. I did not have time to wait for the meter to warm up properly, still not too bad. I did the same measurements and more with a warm meter and I could not find any significant difference compared to the same measurements in the past.

Which surprised me because I expected that I should add some more filtering on the 5V rail, as the OLED is generating quite a bit of noise (that was expected). But it doesn't seem to affect the analog rail and certainly not the measurements itself.

Anyway, here are the videos:

Volt (10V reference source, model 389-2): https://youtu.be/YzpeCB8JcYY

Resistence (Vishay Foil resistors, 100R and 5K): https://youtu.be/ki4QMtsXNpM

Current (DIY current source based on LT3092)): https://youtu.be/Ddy7erbVUQo

Not much to add, I hope it helps!

[alx2009]

 @MikeK: Thanks! The display does look good, but keep in mind OLED displays look especially good in pictures because of the high contrast. The difference with the LCD may not be too significant in real life. Initially I was looking for an LCD myself, because OLED generate quite a lot of noise on the power line. But I could not find anything with a reasonably big display area and that could fit inside.

[coromonadalix]

maybe  try to fiddle an shield cage around it


anyway  thats a good job to keep this meter running .... now  go everyone   these meter prices will rise  lolll

[MikeK]

the OLED is generating quite a bit of noise (that was expected).

This guy mitigated his OLED noise with an active decoupler (capacitance multiplier):

[Brian of Romsey]

Hi,

  If you are concerned about noise, then supplying pin 7 of the display connector J1006 with an independent supply that is separately regulated down from V+ might be the way to go.  You would have to assume that V+ is around 12 Volts.  So whatever 5 Volt regulator you choose, based on the current required, will most likely require some sort of heat sink.  It will be hard for noise to come backwards through the regulator to then penetrate from V+ to the analogue supplies.  For more protection add a multiplied capacitor between V+ and the new regulator's input pin (as well as the usual 100 nF capacitor close to the input and output pins).  Another idea would be a common-mode choke (like you find on the mains side of a SMPS) on the display board's +5 Volts and ground: pins 7 and 4 of J1009.

[alx2009]

Just to clarify, I am not too concerned about the OLED noise - now that I know that it is not affecting the measurements. Still, the suggestions are quite good and I will make some further tests when I can. I am especially keen to use the V+ as Brian suggests. The entire display module use around 30 mA at the lowest contrast setting, with all digits displayed and a limited number of annunciators. The power consumption goes up quickly and at maximum contrast is about 110 mA. I would need to dimension for about 1W power dissipation worst case.

I remember other posts in EEVBlog where adding 300uF directly on the display module would help. And another that modified the initialization commands for the display driver to move the noise into a different frequency band. Maybe something to try as well.

About noise, I have found another source that really surprised me. I have used a bluetooth HC-05 module (more on that later) and I noticed that when it is powered but not connected the least significant digits fluctuate. As soon as I connect from PC, tablet or phone the instability is gone.

Initially I blamed the radio, but this was counter intuitive. Radio emissions should go up when connected. After much trial and error, the blame fell on the blinking led. When the module is not connected the led blinks at a frequency of a few Hz. I have been able to replicate the problem blinking the debug led that I have on the display board.

Increasing the frequency of the blinking from 1 Hz to 100 Hz, I found that the most sensitive frequency is 1 to 12 Hz. At 50Hz or greater there is no problem. Now, the led is powered from +5V via an AP2114H-3.3. If I probe the voltage at the output of the AP2114 I cannot see much noise at all. But if I probe the+5V upstream of the regulator then I can see quite a bit of noise.



The yellow track is the led turning off, and the other track is the +5V probed at the IEEE connector (J1008). The big swings are due to the OLED... the noise due to the led switching off is tiny in comparison (the led is high efficiency, it only consumes around 300 uA). Crazy that it is the led that affects the measurement!

The reason I do not see the noise downstream of the 3.3V regulator is the fact that the AP2114 is affective from zero to around 100 KHz. But it still has to provide the required current, and it can only come from upstream. The regulator circuit of the Keithley seems to work at frequencies from 50Hz to maybe a few KHz at most (not surprising). This means that the "current noise" becomes visible as voltage noise on the 5V rail. But it is only the low frequencies that affect the measurement.

Short term I am going to keep everything as it is. I have powered the bluetooth module using the backlight switch, so I can turn it off when not in use (I have protection resistors on all inputs and outputs, plus at startup I disable Serial if I cannot detect the module). And the led on my board is staying off unless I need to troubleshoot something.

Longer term I would like to do more tests to reduce the noise overall, and also do some basic EMI tests.

Finally, something about the bluetooth module. It did exceed my expectations. These HC-05 modules have been around for sometime but for me it was the first time I used bluetooth on a microcontroller project. There are plenty of instructions around (google hc-05 bluetooth module arduino). Most of them make it sound more complicated than it is, at least if you get a module that have all the requisite connections (apparently some modules don't connect the state or enable pins correctly).

Once the module is correctly setup I found that it is very easy to pair and connect from Android, Windows 8 and Windows 10. The autoreset circuit is connected to the "state" pin and works flawlessly with the Arduino IDE. Only occasionally I get a connection error and it is solved restarting the IDE.

The situation is very different on Linux. After some trial and error I could connect via a terminal program, but not via the Arduino IDE. Reading around this may be due to a known bug in the kernel but I couldn't find any solution. This is not a dealbreaker for me, but it may be for others.

As next step I would like to add a function to log data to bluetooth. I would also like to connect the "state" pin to one of the (few) free pins in order to read the connection status and display it. Not essential given that so far I did not have any issue, but nice to have. 

[Brian of Romsey]

Hi,

    Being able to read and display the Bluetooth state seems like quite a useful feature.

    Cheers, Brian.

[alx2009]

I am pleased to announce that the SW that is now published on GitHub (https://github.com/alx2009/K197Display) recognizes the BT connection status and displays "<->" next to "BT" when connected. For this to work the "BT_STATE" pin of the BT module must be connected to pin PA5.

When the HC-05 module is configured properly, the BT_STATE pin goes low when connected. My SW reads PIN5 in loop() and updates the display accordingly.

In my case the BT_STATE is also connected to the reset line via a 330R resistor and 100nF capacitor. This means that when a connection is established the SW is reset. After the reset "BT <-->" is displayed. At disconnection the BT_STATE goes back to high, and only "BT" is displayed.

Next in my todo list is data logging to bluetooth. For my need a basic serial terminal is good enough, but if someone can recommend an app for Android and/or Windows that is able to log and display volt/ohm/etc. let me know (assuming the API is available). I do not have iPhone or Mac, but if someone can provide me an API then I can implement that on the meter side (albeit you may need a different bluetooth module. I have the impression the Apple side requires BT low energy).

[trobbins]

Nice progress indeed!

My 197 has the 1972 option (IEEE-488 + analog output), and the RF probe option.   It was displaying jitter on the last 2 digits, and initially that was alleviated by replacing the main 2,200uF 16V bulk filter cap on the 1972 pcb.  But the jitter was still noticeable, so recently I disconnected the AC power to that pcb (leaning one of the 10Vac isolated winding interconnect long pins over) and that removed the remnant display jitter. 

I'm not sure how the 1972 pcb loading on an isolated transformer winding couples back to the main instrument (as the 5Vdc supply is still connected through), as I was unable to locate a service schematic for that accessory pcb, but I could confirm the LM340 on that isolated rail had enough raw headroom not to fall out of regulation.  So I haven't gone further with identifying how disturbances were coupling to the main board, but it may have some similarity with your observed LED disturbance issue.

[Brian of Romsey]

Hi, any news to report?