HP 4274A LCR Meter

[GRMPhD]

Hello everyone! I've been watching Dave since he was still making videos in his garage and have been an electronics hobbyist since I was a kid riding my bike up to radioshack. I just finished my Ph.D. in Electrical Engineering last year and I figured it was finally time to join this forum.

Background
I love collecting test equipment and am always trying to find good deals on broken equipment on eBay to repair. Like Dave, however, I think I am cursed since every time I buy something advertised as "broken" it ends up working perfectly fine. Anyway, about two years ago, I finally got lucky with this LCR meter though as it actually doesn't work. When I first powered it up it looks like this:


I did all the basic things at first (check for blown caps and bad voltages) with no issues to be found. So I dug up the service manual and saw that the troubleshooting info in the manual revolves around using a digital signature analyzer... I looked into getting one or possibly building one but at this point in time I was starting my final year of my Ph.D. and was a little too busy dealing with that and other life things. so the repair was shelved until last week.

The Repair
A few days ago I was thinking about the meter again and came across another thread https://www.eevblog.com/forum/repair/the-repair-from-he!!-hp-4275a-lcr-meter/?all where there was a suggestion that the ROMs could suffer from data loss. I've seen this happen with EPROMs before, but even the mask ROMs like I have can apparently suffer from rot. So I desoldered the ROMs and dumped them (included as an attachment) and compared them with the ROMs posted in that thread. The first 3 ROMs are the same as the 4275A that is being discussed there and mine matched perfectly, so that gave me some confidence that my ROMs were indeed OK. While I was waiting for some sockets to come in so I could reseat the ROMs and keep checking things I turned my attention to the schematics to learn more about how the display circuit actually works.

Here is the schematic for the Display and Key Control board:

What stood out to me is that the display information is actually stored in RAMs. U4-U6 and U10-U12 are HP 1820-0628 which cross-references as a standard 7489 64-bit RAM. I suspected this could be the issue since the display was multiplexing correctly but was stuck displaying the same thing as if the RAMs were just outputting whatever garbage they default to on power-up and never being programmed correctly. Since I was still waiting for the sockets, I figured I would try to see if they were the issue. So I desoldered them and threw together a quick Arduino sketch to run through all of the addresses and read and write data to them. Of course, every one of them tested fine. Except that two of them, I broke trying to get out of the board. 

So I was off to the local surplus store to see if they had any replacements in stock. Naturally, they didn't, but they did have some 54S189's which are the same as the '89 except for having tri-state outputs rather than open-collector, and they're in a nice less-likely-to-be-broken ceramic package. Annoyingly in this application, the outputs of the '89s are fed directly to the base of the driver transistors (U1-U3), so a '189 is not a simple drop-in replacement. To simulate the open-collector outputs I installed the '189s with the output pins bent up out of the board and Schottky diodes soldered into the board as shown below.

This allows the RAMs to pull the base of the transistors low when the output is low, cutting off the transistor, while also blocking the RAMs from driving the base of the transistors high, so they can be gently pulled up by the 4.7K resistors as intended. Schottky diodes are needed here to bring the base sufficiently low to actually turn off the transistors. This is not the prettiest solution but it ended up working fine. It's also nice because it's 100% reversible, unlike any solution involving cutting traces. I may eventually end up sourcing some actual '89s but they seem to be pretty difficult to come by today for a reasonable price.

When the sockets finally did come in I put the ROMs back and... same symptoms. Although now the displays showed different garbage. So again, it seemed that the display RAMs were still not being programmed. I then turned my attention to the main board A9:

Without a DSA I wasn't able to check any of the signatures or follow the flowchart in the service manual. So I went around various places with the oscilloscope trying to find something wrong. The main clock, the ROM selector, address lines, data lines, power-on reset? Nope. Everything was fine. I even started pulling out some of the ICs and tried testing them out. Everything I checked was good. At this point, I started to suspect that the main MPU was bad. So I started to focus my attention on the signals directly at its pins. The only thing that looked iffy was the signals on the data pins. Lows seemed fine but the highs were nowhere close to 5V, closer to 2V or so. Having never used an MC6800 before I didn't really know what to expect, so I assumed that maybe this had something to do with why there are buffers on most of the I/Os, or some other MOS to TTL interfacing weirdness. Now when I got to the R/~W pin I had a realization: although the CPU is sending out addresses, it might not be getting the data it's trying to read from the ROMs. When looking closer, the R/~W signal was making it all the way out through U33 pin 11. But it was not making it out of the NOR gate U19D. The other input to U19D was comfortably sitting low, but no matter the state of R/~W, U19D would not send its output high. I desoldered U19, plopped it into the minipro, and sure enough:

That was it. 
Luckily I had a board sitting around with a 74LS02 on it, swapped it into the 4274A, and boom, it fired right up. (This is why I keep telling myself that holding onto all this old junk is useful!)

Some measurements of each L, C, and R:


I really didn't expect such a simple problem with possibly one of the most jellybean of jellybean parts, and naturally, I made it more difficult by breaking some pins off those RAMs. But in my defense, those late 70s National Semiconductor packages are absolute garbage. I've never seen such terrible plastic and weak pins on a DIP package before  Plus, the culprit failed 74LS02 was also the same vintage National Semiconductor package.

Other Stuff
While I had everything apart, I also took some pictures of the boards. They could come in handy to someone someday. Or if not useful, I'm sure there's someone out there who'd just like to stare at them like I do. Check them out: https://github.com/gmulberry/HP-4274A/tree/main/Board%20Photos Here is a sample of one of them showing my A9 board.


And also, if you suspect your ROMs might be bad, I've attached mine to this post.

Happy troubleshooting!
Geoff

Edit: I guess I didn't attach the ROMs... You can find them here: https://github.com/gmulberry/HP-4274A/tree/main/ROMS

[wn1fju]

Nice repair! 

I am like you - I enjoy fixing up test equipment bargains from eBay.  I have often wondered what a seller would say if, after receiving a piece, I sent him a message like, "I would like a refund.  You said that this piece was broken, but it works fine."

[chilternview]

Well done! Yes surprisingly the old LS TTL ICs in these instruments do go, I had a failure of an 8 bit buffer on a HP4280A that was fairly random - the unit would work on powerup for a while, then fail after some time. I could narrow it down to one board and about a dozen possible ICs and it was, like yours, a case of removing and replacing them one by one until the problem went away. A good desoldering tool helped!