HP 3455A repair help

[cncjerry]

I calibrate mine to a calibrated 3457a meter. I can get it close enough for basement work and that is good enough for me.  The ultimate value means less to me than relative anyway. The challenge with the 3455a meter is that they are old and many have run continuously for years, maybe decades, in lab environments.    I usually find more than one bug repairing them.  The one I just finished calibrating it to my dc standard while also measuring the same voltage with one of my 3457a meters is rock solid.  Ohms as well.  AC no matter what I try they are a little flakey and it could be my source ground loop.  This one had a weak U5, a 7406, on the A/C RMS board to boot. It manifested as a value of 1/10th while in 1 V range.

By the way I reseated my calibration module hard and my vref problem went away on that unit.  Make sure yours is all the way in before measuring TP7 and TP8. 

We will get yours running ok.  Make the checks and post here.  I would stop pulling FETs as the drivers and latches in my experience are 2:1 over FETs. 

Jerry

[Dragon88]

This morning I replaced the two FETs I had lifted, and re-seated the cal module hard a few times. Then I took some measurements.

After replacing those FETs, the reference rails returned to +/- 5.6V in code 11 in Test mode.

Sitting at code 11, U8 pin 13 reads 1.334V. The multiplex reads 1.347V. Pins 1, 2, and 14 reads -24.14V.

I switched on guard and grounded the multiplex to the inguard metal enclosure. The unit immediately bypassed code 11 and went to 10.


Is U8 just an LM339? I have an LM339N in my parts bin.

Thanks.

[Dragon88]

So I replaced U8 with the LM339 I had, and it didn't fix the problem. New chip is functional, but with the same problems/output as before.

I looked at the inputs to the comparator in question and traced the non inverting input back to a flip flop, where Q5 was floating. Data input 5 to that flip flop was also floating, so I traced backward to an inverter, which is acting as an inverting buffer for the data lines. All of the data lines seem to be floating, on the inputs and outputs of the buffer.


Tracing back from there, perhaps the inguard processor is dead....



Actual I don't know if the data lines are floating, I haven't put it on a scope yet. Does the inguard processor continue to use the data bus while sitting on an error code?

[Dragon88]

Nope, the flip flop and all that was a red hearing. Checking around with the scope and Group A procedures from the manual, the digital stuff is working fine.

So it's back to Q2 not getting turned on to ground the multiplex during code 11. But replacing U8 didn't fix it.

[cncjerry]

U8 controls Q2.  Tracing back, U12 Pin 15 as a latch should be nailed up and not pulsing to switch on Q2. So put a scope on U12 Pin 15 and it could be pulsing not at full TTL levels.  I had this problem where U12 pin 15 was pulsing so I went back and put a scope on pins 9 and 14.   U12 pin 9 is the enable pin. So if you sync your scope on U12 pin 9 and look at 14 during the 11 code, you'll probably see they coincide setting the latch so pin 15 should be nailed up.

So it looks like the problem could be in U12.  When you see U8 pin 13 at anything over zero, usually it is because the input pin 11 is pulsing from the latch.  A way to test this is to stop at the 11 code and ground carefully and quickly the input pin and and also try touching it to +5.  If that gives you the correct FET control  thru the U8 driver then the latch is bad, in this case, U12.  You can also check other latches to see the correct operation of the proceeding latch.

Whenever you see the driver inputs at anything other than 5 or 0, the prior latch is not latching.  You could have a bad U22 but unlikely.

I'll use my test box to stop on code 11 in an hour or so and give you the correct levels going back to U22.



 

[Dragon88]

Ok, after I get those levels from you I will measure and compare with the levels on my U12 and U22.

When I investigated U22 I assumed the data bus would be quiet while sitting on an error code, but this was quite wrong. There was a lot of activity from the processor actually. The average DC levels on the multimeter made me think several pins were floating, but the scope revealed the data signals.

I re-seated the processor just in case, and I snapped a picture while it was out. It's quite a nice IC. "They don't make em' like they used to"...

[cncjerry]

I often suspected those pins which are very, very soft, are like pure gold.  Careful when reseating it.

U8 Pin 11 should be a solid high, > 2.2V and usually at 3v or higher.  If you use the table on page 8-51, or page 141 of the PDF reader (which I have memorized all of the appropriate pages), you can see the levels for U8 when stopped on code 11.

If your U8 Pin 11 is lower than 2.2V then your U12 is most likely the culprit.  I've had to replace U12 on one and U16 on another so those latches are common failures.  I think what really happens though, is the driver as in your case U8, goes bad and feeds voltage back to the the latch.  So maybe replacing U8 was worth your time anyway.

Look at U8 11 with a scope.  If it is pulsing the U12 is probably bad.  You can tie U8 Pin 11 to +5 briefly without causing a problem in U12 since it is probably bad anyway.  When you touch U8 pin 11 to +5, U13 should go to 0 causing Q2 to turn on.

I have a feeling the problem with your ref voltage is that U12 also switches in the calibration resistors in the ref assembly.  So what happened in my case, was that U12 was bad causing the code 11.  Grounding the multiplex gets you to a code 10 because Q13 and Q14 are dragging down the multiplex and possibly your Vref as well.

When ordering, I would pickup a a couple of 74LS04, 74LS174 and some LM339s to keep on hand. They are cheap.

I'm kicking around restoring my parts box as well but I would need a ROM which is $25 from that guy on ebay.  The other thing I've been thinking about is taking out all that logic on my parts box and just switching it with a Nucleo micro board.  Half the logic is for autocal and the other for switching.  All it does is switch cycle the autocal in / out of the measuring circuits about twice a second and feed the gain adjusted value to the A/D converter.  I'll bet I can take all that 74LS out keeping the LM339 drivers in a couple of hours.

Once you have it working, you'll have a pretty stable DC voltage and resistance meter capable of some pretty accurate measurements.  The A/C RMS side of the meter is tough to calibrate.  I have to make some shielded cables because I get nothing but noise on the lowest two digits.

hurry up and test U12, dieing to see the results.

[Vgkid]

It looks like the die cover was set on fire.

[Dragon88]

Well, U8 pin 11 is sitting steady at 3.58V.

I checked out Q2. Indeed the gate pin is sitting at the 1.3 odd V from U8. I checked the ganged resistor R48 and it seems fine. I tried touching the gate of Q2 to ground quickly, while watching the multiplexer voltage. It jumped slightly from 1.32V to 1.45V while I was doing that, then back to 1.32. Strange.

[Dragon88]

However, when I dropped down to code 10, I noticed the -24 volts on the gate of Q2 was not steady. I checked back to the latch, and the Q5 pin seems to be pulsing. I'll have to put it on the scope to be sure.

[cncjerry]

so Q2 isn't capable of dragging the multiplex to ground.  I would go back to the code 11, print out page 8-51 and probe the table for code 11.  Start with the -24 pins and then the zero levels.  Once you find the wrong level look at the corresponding input pin for a pulse from the corresponding latch.  That should id the failing driver or latch in a minute or two.  If any of the latch pins are pulsing then I suspect the latch.  Alternatively, you can probe U6 down to U4 pins to see if any are pulsing.  That way you don't have to keep going back to page 51.

The gate bias floats the gate pins up to the multiplex level and that must be why you are seeing the positive voltage on Q2.  The gate bias can also cause the -24 to jump around a little.

[cncjerry]

Also, just for grins, pull the ref unit and see if it still stops on code 11 or goes to 10.  If it goes to 10, then check the gates of Q13 and Q14 for correct levels.  There are some really funky switching loops that happen when a latch or driver fails.

[Dragon88]

On code 11, I found several odd comparator outputs.

U4, pin 13, 5.5V instead of 9.5V.
U5, pin 13, pulsing
U9, pin 1, .5 V instead of -24
U9, pin 2, 1.3 V instead of -24
U9, pin 14, 5.5 V instead of -24

But I believe this traces back to more than one latch.

Yup, latches U12, U13, and U16.

[Dragon88]

On the scope, I found a pulsing output on U13, and one on U16. While sitting on code 11 again.

[cncjerry]

If you are stopped on code 11:

U4, pin 13, 5.5V instead of 9.5V.  <- ignore, it is wrong but because the multiplex is most likely wrong.
U5, pin 13, pulsing   <- problem with U16
U9, pin 1, .5 V instead of -24  <- problem with U13
U9, pin 2, 1.3 V instead of -24 <- maybe ignore because of gate bias float otherwise U12.
U9, pin 14, 5.5 V instead of -24 <- problem with U13.

the most obvious error is the last one at 5.5V.  I had the same thing when I had a bad U13.  Look at U9 pin 9.  Try the ground and +5 trick with a jumper and see if you get the correct output.  If you do, then one problem is U13.   

By the way, does it look like the caps were replaced on the digital supply?  Could have been enough leakage to take out a chip.

When the unit stops on a code, it should halt the switching.  I haven't tried it, but when stopped on 11, hit the hold manual button and see if the pulse goes away.

If it was my unit, I would swap out U13 first and see if symptoms change.  The boards can take a lot of abuse.  I use one of those spring solder suckers on the bottom followed by braid on the top.  I also have an ice-pick like tool in a screw driver handle with the tip bent 90 degrees about 5/8ths down.  Once I suck the solder and push align the pins in the holes, I pry with that tool like a lever.  No problems so far.



U5 Pin 13 is strange. That is driven by Pin 11 and you can also test it by grounding and jumpering to +5. 

It is  not unusual to have two bad LM339 or latches.  Part of the problem is they all go around the same time.  The other problem is that you don't know who was in there before you.  Two of the boxed I had came with probe dimples all over the place.

That table on 8-51 should be your guide when it is stopped.  You can ground the multiplex, skip the code 11 getting to code 10 and then try looking at the pins from table 8-B-4 again to see if U13 or U16 are wrong.

This is developing into one of those very satisfying experiences when you fix it.

[Dragon88]

I have to put in a Digikey order this week so I will order some of those 74LS174s. I will replace U13 and U16 and check for improvements.

I do believe someone poked around in here before me. No signs of damage or replacement of parts, but the eBay seller indicated that they tried to fix it, and hoped someone else would have better luck. I'm out $50 if I never fix it so no biggie. But I would like to give it a second chance.

[cncjerry]

Don't give up.  I spent a ton of time on mine and ultimately fixed three.  I have a feeling it will be u13.

[Dragon88]

I replaced U13 and U16 today, but unfortunately there was no improvement. Same error messages and behavior.

[cncjerry]

Damn. I went back thru your data a couple of times since the last posts.  I have two on my bench right now and was trying to simulate your code 11 and as we know, your pins posted above were wrong. 

let's take another approach.  stop on code 11 and ground the multiplex.  that should take you to code 10. Look at the table again for code 10 and tell me what pins are wrong.  Also make sure to check the enable line on u16 and u13 pin 9. Check the voltage on both sides of resistor R4 as well as TP 7 and 8.

lastly, check u14 pin 4 with a scope for the clock pulse as well as pins 1,2,3,5 which are the device select lines.  They should look alike and not be floating.

On one meter I had to isolate the multiplex by clipping the solid wire on each side of R38. You can touch solder the wire back together.  On the code 11, something is holding the multiplex up; On code 10, something is keeping it from getting to 10v. 


Since those two large 100k resistors, r59 and r61 aren't used at this point in autocal, you can lift the blue and brown wires to isolate q13  and q14.  Q1 isn't used so you can lift that off the multiplex as well.

If we can get past code 11 and 10 to get the gate bias up on Tp3 we will know more.

[cncjerry]

Here's another one for the list of 3455a bugs: 

This one seemed to work ok until I tried to calibrate it.  10v and 1v were ok;  AC RMS as well;  1K ohm standard came right in;  When I tried to calibrate the 1M with which you use a 100k resistor, I ran out of range.  Another strange problem was that the lower ranges all read about the same but dropped about 700 ohms or so when switching higher.  I tried a couple of different calibration modules without luck.  I spent four hours on the ohms converter and got nowhere, maybe added about 200 to 300 ohms to the low reading.  Swapped the ohms converter boards, etc.

I went back and recal'ed the DC volts and I noticed it ran away on the 10v leakage test.  This points to Q5 or Q17.  I've had Q5 failures before but not this time, of course, it was Q17.  Once I swapped it out, everything came into calibration.  Go figure.

These meters can get the best of you sometimes.  They use about 30 or so FET switches which are prone to leakage and all kinds of intermittent failures.  It is not unusual to have more than one driver or preceding latch fail at the same time.

[cncjerry]

Adding to the 3455a repairs:

Found a black face 3455a on eBay, with shipping I paid $72 for it.  It was listed as defective - blows fuses.

The first thing I did was check the various voltage test points to ground finding the +5 to be nearly a short.  I used a slow-blow fuse to power on/off quickly and the +5 wasn't coming up.  The 4200uF cap on the inguard +5 was shorted so that fix went pretty quickly.

Once I got the unit up and powered, the meter was reading 3x the known value in all cases.  This pointed to the reference.  Inspecting the reference I found the 29.3v was low, sitting around 3.5V.  Somebody had replace a few glass diodes with the wrong type installing one backwards to boot.

I brought the unit up and found I wasn't able to get the range I needed to calibrate it.  I swapped in another A/D converter which solved that problem so I guess I have to dig thru that to have as a backup.

Anyway, once I got it sorted out, it calibrated really easily.  This particular meter must have blown the +5V cap early on and then sat.  It had some salt stains on the aluminum frame, a couple of buttons needed cleaning, but it is very, very stable with a nice bright display.

Hope this helps someone in the future.

Jerry

 

[stevopedia]

I know this thread is old, but since I've got another HP 3455A with problems it seemed more sensible to me to post in this thread than to start a new one.

So I've got a 3455A that's gradually developed an odd fault. A few years ago I replaced all the power supply electrolytics and the original fan with a modern 12 V one, since the original's bearings had failed and squealed horribly. It ran beautifully well afterwards, until very recently when it would seem to lose its mind: wildly varying measurement results, even with the input shorted; unsteady trigger rate when set to internal trigger, etc. Power cycling would reliably restore the DVM to proper operation.

I started to investigate that behavior. My first thought was that the communications between inguard and outguard were faulty, so to that end I scoped A3TP1 and TP4 and the corresponding pins on A10U26, being careful of grounding. When I first set that up, the meter was working properly and the waveforms matched, indicating the communications were working. I decided to leave it with the scope running over the weekend. On Monday I found the instrument completely halted: the "sample" LED was lit continuously, and there was a continuous stream of data from the outguard to the inguard while the inguard-to-outguard line was held low. After power cycling the instrument, it behaved exactly as if I'd unplugged A1J7, the cable that carries the data between the inguard and outguard: blank display, all the front panel LEDs lit. There was no traffic at all on the lines between inguard and outguard.

I followed through the flowcharts in Service Group H, and finally landed at the flowchart labeled "B" on pages 8-115/8-116. It appears that the device select process isn't working properly--U26 only makes device select pulses on two of the four pins specified. The 1-of-8 mux appears to be working correctly, so that leaves me with unfortunately the very worst of two choices: either the inguard CPU or ROM is bad. How do I tell which it is? The PA lines look OK, and the Data lines look okay-ish, though D2 looks particularly ugly to me. I'm very much hoping that it's the ROM, since that at least appears to have a modern replacement available from D'Asaro Designs http://www.dasarodesigns.com/product/replacement-ingaurd-rom-for-the-hp-3455a-voltmeter-hp-pn-1818-2270/.

Has anyone here had a similar fault with the 3455A before?

[pelule]

I had similar error (caused by socket of the ROM). Cleaned it, and failure was gone.
Is your ROM soldered or is it on socket - you have to careful desolder it to check the ROM.
Are you able to read out the ROM content (for plausibility)?
/PeLuLe

[stevopedia]

It's soldered in, so I can't imagine that would be the problem. The CPU is socketed, though... Hmm... I'll try cleaning its socket and see what happens. Good thought, thank you!

And, as a footnote to add to the weirdness, I tried the instrument again this morning and started right up, like nothing was ever wrong. Thermal expansion or whatever causing contact weirdness? I'd believe it.

[GregDunn]

I have seen so many computers and even analog gear develop intermittents over the years due to socket issues.  It's gotten to the point that if a piece of equipment starts acting up, I will always at least partially remove and replace socketed items (depending on accessibility) to wipe any oxidation off the contacts before moving on to other tests.  It works more often than not.  These days, a tiny drop of Deoxit on socketed pins after cleaning and before re-insertion is not a bad idea.