HP 3455A repair help

[Dragon88]

Hi,

New user here, though I have been a long time fan of the EEVBlog. I was hoping to get some help with repairing an HP 3455A. I picked this up for $50 and knew it had issues. I have done some basic troubleshooting so far, but I ran into a roadblock due to the very poor quality scan of the service manual available online. I may have to pick up a real copy on eBay. Anyway, this is what I'm seeing. Any help would be most appreciated.

-The unit powers on. The outguard section seems to work, the buttons and indicators all work. I can switch ranges etc. The display shows overload (OL) immediately after the autocal fails. It then sits on OL with the attenuation relays clicking.

- Pushing the test button and cycling through the failures, it shows 11 through 8, 6, 5 through 0, occasionally a number such as 6.1846, then it does a lamp test.

- After cycling through the failures at least once, the behavior seen on the display changes a little. The AC modes begin to show erroneous readings instead of just OL. The DC ranges still all show OL, EXCEPT for the 10V range. This shows a reading of about .6 Volts, which then slowly climbs toward a volt or so. If I short the inputs, it drops down toward .1 V.

- Test points 7 and 8, which I believe are the +/- 10V references, are +/- 5 to 6V.

- The large "pipe bomb" looking relay (K1?) does seem to work. I found this referenced in some google searching I did, so I checked it. In the lower ranges it passes the input through, higher ranges it does not.

- The electrolytics all look fine. The other power rails measure fine.

- The reference module in the back is present, though it powers on and behaves in the same way even if the module is removed. The upper 4 wire terminal on the front seems to have had something dropped on it, as it is bent downward a little. Otherwise the device is in good shape.

- I re-seated the removable boards inside.


I think I may have a shorted FET somewhere, especially if TP7 and TP8 really are the 10V references. Again, I don't have a readable schematic in hand, so I'm kind of shooting in the dark. Instead of starting to test every single component on the board, I was hoping someone with experience working on this model would have some ideas.


Thanks!

[Dragon88]

A small update. I found a good pdf of the service manual online, and that has helped a lot. (http://bama.edebris.com/manuals/hp/3455a/)

I am focusing on the area around test points 1 and 2. There is about 140 ohms between them, which seems very unusual based on the schematic. Also, TP2 is 38 ohms to ground. That node being shorted to ground would load down the 10V reference I believe.

I got excited when I found 38 ohms across capacitor C24, so I lifted it, but of course that was not the short. I then lifted Q36 since that was the next likely fault to ground, but no dice. I may lift Q35 next. There are 140 ohms from drain to source. Either this is the culprit, or there's another path between TP1 and TP2 I'm not seeing, or I'm chasing a red herring...

[Vgkid]

First thing I would do is check the PSU, on my 3456 it caused a large amount of the self test errors. 

[Dragon88]

The +5, +9, +/- 15, +30, and -24 V rails all measure spot on. They also look clean on the oscilloscope.

[Dragon88]

I think I'll have to put this away for a while. I did remove Q35 and that was a bit of progress. The reference rails measured +/- 10.00V on all but the 100 mV range afterward. However, I don't think Q35 was the problem, it just cut one node off from another node that does have a problem.

Attached is a picture where I'm working.

I hope I can fix it one day. It's nice and clean inside and it deserves another chance.

[pelule]

Did you get your problem solved?

If not, please check ALL supply rails first (use Power Supply Schematic Figure 8-H-39 for reference, means +30V,~29.3V (J3 pin 11), -24V etc.). Only if ALL voltages are ok, continue your analysis.

Next step is to note all error codes in "Test" mode (Cal# error constants).

Next could be to use the table 8-B-7 (8-54) to select the possible cause of the error.
Alternative you may use the Cal-Step procedure to step to the 1st (highes) Cal# error and to compare the values with the give ones in the entire tables.
Or go step by step according with the Auto Cal troubleshooting diagrams and tables.
Its the best method to detect the cause of the problem and not to be misleaded.

The slow rising value at not-shorted inputs is caused by the leakage currents in the analog circuit. The rising time defines, if the leakage is in spec or out. See the special chapter for leakage tests.

[Dragon88]

No, I have not fixed the problem. I also haven't worked on it in several days.

The power rails all measured fine, except for the +/- 10V reference rails as I mentioned above. They were being loaded down and drooping to +/-5-6V. Lifting Q35 stabilized them to the correct values, but again I don't believe this transistor is the problem. It just isolated the reference rails from the node that does have the short, as far as I can tell.

I'm fairly certain I have a shorted FET somewhere. I did record the error codes and consult the table in the Service manual. I checked every part mentioned in the table, but in-circuit I was not able to find anything out of the ordinary. I also tried shorting the multiplexing node to ground as mentioned in the manual to remove the OL, but that did nothing.

My next step would be to continuing tracing back from Q35 in the schematic and checking/lifting parts.  Past Q35 on one node I had something like 200 ohms to ground, which seemed suspicious. I wish I had a better plan than this, but I don't at the moment.

Again, thanks for any suggestions.

[Luddi]

my HP3455 had the driver ICs for the J-FETs in the inputpath blown. Check the driving signals for the J-FETs.
Check page 8-51 Table 8-B-4.

I think i replaced U4 and U5, LM339.

[pelule]

You mentioned, you have noted the cal# errors during test.

Cal# errors are listed from the highest (#13) to the lowest number (#0), possibly followed by some dot digit values, if the calculation routine at the end of the test calcs wrong values.

The first cal# error shown, is the first one detected by the test procedure (cal constant measurement value not as expected) and thus the one to solve/repair first.
Lower/later errors may just a site effects of that first one.

3455A MUST out of "test" mode and "AutoCal" MUST be OFF to do senseful measures at stable conditions. Otherwise the 3455A continuesly measure/switchs.

Step to that "cal constant measurement" of that cal# err (see 8-B-11 Cal Constants Service Procedure, ~page 140).

Now follow the trobleshooting diagram (chapter H) for the given cal# err.
For example: for cal#13 it is Figure 8-H-3 (~page174)

I have repaired severals of HP 3455A and this is by far the best way to detect a possible root cause.
It also includes possible defects of comparators (LM339, U9[pin 1] driving Q35).

Please note the LM339 has open drain outputs, it just shorts the gate of the FET to -24V (FET HiZ/OFF) or let the gate flow to the G.B. level (Gate Bias) supplied to the gate via a 100k (FET low/ON). Gate driver is U1 (TP3), the Gate Bias Amplifier.

Just a short list of errors I had in the past (listed by occurence, highest first):
- most often a bad/defekt electrolytics (1000µF) in the inguard supply
- damaged LM339 (output shorted to -24V)
- FET shorted to drain/gate
- FET had too high leakage current (FET is highly temperature sensitive)
- defekt 5V6 Z-Diode

[cncjerry]

I have 4 3455s and only one works.  One I use as a parts box after blowing the CPU.  I've spent hours on the others and the most recent has an FET problem I can't find.   There are quite a few that tap the 10v reference and once it gets drug low it is very hard to find. Even with a working one sitting next to me I can't find the the  shorted,  or at the least leaking,  FET.

If your PS  voltages are OK with acceptable ripple then don't touch them.   Work from the highest error on down using the simplified switching diagrams.   This worked for me in the past until I hit this one as an error 10 is the kiss of death for me.

Leaking FETs plague these boxes and the other problem I found is that the switching is consolidated in a ROM that blows as well causing what looks like a multiple FFT shorting problem.

They are great when working.   I have four 55s,  two 56s and two 57s. I love the red led display as my vision is bad.   One of these days I'll get another 55 working.

I'm going to go back and look at the recommendations in this note as well.

Jerry

[cncjerry]

After reading and posting yesterday I got motivated to pull another one out.  This one has a more perplexing problem in that the Gate Bias, which goes quite a few places (every switching FET) is low.  Probing to ground on a working 3455a is 3.5M; on this one it is 75k.

Since the GB connections are all in parallel, I can't locate the problem.  At first I assumed the most likely candidate would be an FET that had a GB resistor of less than 100k.  As all but one of the GB resistors are 100k, if the FET was shorted, I was thinking that I should read the GB resistor resistance as a minimum.  The only GB resistor that is less than 100k is R37 feeding Q1.  Since Q1 accounts for about 1/2 the 3455a failures after the PS caps, I lifted the GB connection to no avail.

The other place GB goes is to the cans of some of the metal cased FETs.  Again, I looked for a metal FET with GB connection and a path to ground of 75k without luck.

 So the only thing I can think of now would be to lift each subsequent GB connection unless someone has run into this before?

Any other 3455a engineers out there?

thanks,

Jerry

[cncjerry]

Contributing further to the 3455a problems people have, I fixed my GB problem by replacing U1.  Interesting though as I still have errors.  Something is dragging the multiplex low.  I suspect this is what blew U1 as a grounded multiplex or low value multiplex will heat U1.  Using the switching diagram as well as the autocal tests, I've made a list of the possible switches that will drag the multiplex low.  Sitting here in a meeting waiting to fly home and check the switches...

The other issue is the expense of the parts.  Using a donor parts box is the way to go but the shipping of same is high; purchasing original parts is crazy due to the cost.  If anyone wants to part with another 3455a parts box, let me know as I would like to get three of my original four working.  I have a pretty good handle on the inguard board now but it has taken a long time and lots of study. 

If anyone has a cheap FET switching alternative, please post.  Need dual FETs as well.

thanks,

Jerry

[tautech]

The other issue is the expense of the parts.  Using a donor parts box is the way to go but the shipping of same is high; purchasing original parts is crazy due to the cost.  If anyone wants to part with another 3455a parts box, let me know as I would like to get three of my original four working.  I have a pretty good handle on the inguard board now but it has taken a long time and lots of study. 

If anyone has a cheap FET switching alternative, please post.  Need dual FETs as well.

Have you tried Sphere?
Link to them in the first post in this board.

[cncjerry]

Yes, tried Sphere; $25 for an FET.  Overall cheaper to just purchase another parts box.  Three of the 3455s I purchased were less than $50.  There has to be a cheap FET that can be used as a replacement after all these years.

Fixing this old gear is actually pretty fun and rewarding but I am trying to keep the costs down.     i could probably replace the entire outguard with an STMF4 micro development board like a nucleo as well as most of the switching in the inguard.  Then replace the ADC with a modern 24bit chip and get really carried away...

[sync]

Yes, tried Sphere; $25 for an FET.  Overall cheaper to just purchase another parts box.  Three of the 3455s I purchased were less than $50.  There has to be a cheap FET that can be used as a replacement after all these years.

I saw 2N4117 FETs as switches in a bench DMM. But it looks like they were selected. The SMD version (MMBF4117) is cheap.

edit: look at this thread: https://groups.yahoo.com/neo/groups/hp_agilent_equipment/conversations/topics/13073

[Vgkid]

Do you have a part number for the fet, In know the 439X are popular. Vishay/LIS(Liear integrated Systems) does sell low leakage variants

[cncjerry]

1855-0308, 1855-0247, 5081-7047, are all available on eBay but I can't help but think there are later, lower noise variants that would fit the bill. All they are are somewhat higher voltage low noise switching FETs and while I am in there I would swap the entire multiplexer if I could find cheap enough parts.

I love the meters as I can see them across the room. The challenge is that I only paid $50 for each meter, at most, so the thought of spending that much more to  get them working doesn't make sense.  They are quite a puzzle to fix but once you understand their switching logic they are pretty easy to fix. Like I said, more of a challenge than an economic value.

[pelule]

As far I could figure out, the single 40V switch JFETs are 2N4119A (ultra low gate-drain leakage less 100 nA) special for HP selected for extra ultra low leakage. I used standad 2N4119A from a good brand (Siliconix). They are still offered at the bay for acceptable price & shipment costs.

http://www.ebay.de/itm/2N4119A-Ultra-High-Input-Impedance-N-Channel-JFET-Ampli-BY-MOTOROLA-/301445968609?pt=LH_DefaultDomain_0&hash=item462f9472e1

[cncjerry]

This box is a mess.   So far U1, Q5 solved the gate bias problem,  Q4, U6, Q2 which solved the first part of a code10, and now the driver for Q13,  U17 if I remember,  is bad.   This last one with Q13  was dragging the multiplex down just like a Q2 failure.   During autocal,  Q2 switches on to ground the bus or you get an 11. If it doesn't switch off,  it will also drag the bus down. In my case,  both Q2 and Q13 because of the driver,  caused the multiplex to be loaded down.

I had to open my second parts box to fix this one,  sort of sad,  now I am down to two out of four.

Thx

[cncjerry]

All things come to an end and I finally have this one up and running. 

The last problem was the driver for Q13, U8.  Well, almost last as it had a bug in the ADC board.  In default resolution it read low and wouldn't jump out of 10v in auto range.  I don't know what provoked me to hit the high resolution mode but that fixed the problem.  I swapped the ADC and all is well.

I checked the calibration and had to dial it in a little and it is humming away. Hardly any flipping of the last digit at all, very stable for something that old.

Sorry for hijacking the thread but there are a lot of these meters out there and it would have been great to have one spot for all things 3455a.  I spent months fixing this one but had I read all the theory before diving in I would have saved a ton of time.

I am going to miss working on it.  There for a while it was my arch enemy and I almost gave up on it.  The killer is that it had essentially two sets of unrelated problems (not including the ADC) and the boards hadn't been reworked from what I can tell. There were a lot of probe divots all over the place so maybe someone took a shot before me.

My plans are to button this one up and start on the next.  I'll need some FETs to replace those I took out to fix the next one.  If I had a processor and ROM I would go back and restore my parts unit.  It needs about $20 in opamps, FETs and drivers plus processor and ROM so maybe I'll find another broken one and go that route.  There must be something wrong with me to spend so much time on a meter this old...

Jerry

[tautech]

All things come to an end and I finally have this one up and running. 
There must be something wrong with me to spend so much time on a meter this old...

Your determination is an admirable trait. 

[cncjerry]

Getting back to OP's problem, I suspect that the problem is in the Q2 driver U8.  Keeping the unit in test and stopped at the 11 code, measure the voltage on A10U8 pin 13.  It should be zero volts switching on A10Q2 which grounds the multiplex, U8 pin 14 -24v, Pin 1,2 also -24.  This corresponds to A10U8 pins 4,7,9,11 being H,L,L,H respectively.  If you need a U8 let me know.

Additional troubleshooting:

While stopped at 11, put AC 2v on the input and measure both sides of K1.  You should see AC on one side and not the other as it shouldn't be picked.  Continuing to the multiplex, you should not see AC as on code 11, Q1 is not switched on as well as K1.  If you do see AC, this furthers support for U8 as that drives both Q1 and Q2 but this also means K1 is stuck which is not uncommon.  When a driver fails, you will see either a short of -24v on the gate resistors switching them off, or a floating 0v switching them on.  Any positive voltage on the gate means that, in my experience, the driver is bad.

As someone mentioned, stopping on a code using test isn't proper in that the multiplex could float to the value being tested and move to the next code.  If the failure is hard, though,then stopping during test is OK as you can be sure that the system test is at the right code.  Your code 11 means that Q2 isn't switching on hard enough to ground the multiplex and I suspect it is floating due to the U8 failure.

The next step if the previous doesn't work is to measure the multiplex during the code 11. There should be no AC (assuming you still have the 2v AC on the input) and the multiplex should be at zero. if it is and Q2 is switched on then the code 11 is false and there is a problem upstream in the ADC of the main amplifier which is rare.  If the multiplex is floating, ground it with a lead to the A10 ground point or press the guard button and you can use the metal of the inguard section.  Grounding the high impedance multiplex line is ok and recommended for OL testing.  With the multiplex grounded, the code 11 should be bypassed and stop on code 10.  Taking the machine out of test with the multiplex grounded, the OL condition might clear.  If it does, then you have a leaking FET.  You usually don't get an 11 with a leaky FET because the switched on Q2 should be strong enough to ground it out.  That's why I am pointing at U8; it isn't switching Q2 to ground the multiplex.  It has to stop on code 10 because it switches 10v vref onto the multiplex and measures it.  With the multiplex grounded, the 10v will be measured as 0v.  You can see that solving a code 11 followed by code 10 will clear most OL errors.

Post the results of the tests above and we can go from there. The 3455a is quite a bench meter for the money.  Simple to calibrate and I think you can actually swap calibrated modules from others.  The simple math functions allow you to measure current with an external sense resistor.

Jerry

[cncjerry]

I think I set a record fixing two in two days.  I worked on these things for months prior to committing myself to reading the book!  I threw some parts in my third meter and shot the bugs one at a time.  It had a blow U6 driver which manifested as a code 10,5,0.  Once I fixed that, the 10v ref was low and that turned into a calibration module problem which I swapped out. Once I got the 10v ref up, I still had the 10,5,0 and I traced that to U12.  At first I thought it was U8 but I lightly touched the input to the driver and the suspect driving voltages were correct which pointed me to the latch.  I swapped in an FET for Q1 and up it came, not as stable as the other two but getting better as it warms.

So my inguard skills are growing and I wish I had parts for the fourth meter but this one has been butchered. 

Anyone needs help with a 3455a, pls post here or send me a PM.  I have a fair amount of parts including a complete outguard.

Jerry 

[cncjerry]

- Test points 7 and 8, which I believe are the +/- 10V references, are +/- 5 to 6V.

One other point on this one.  I mentioned that I had the same problem with TP 7 and TP 8 reading low, approximately the same as yours.  That problem is in the calibration module.  When I swapped the failing one with a good one, it all worked fine.  If you trace the circuit, +VREF goes a lot of places but feed at least a 100k gate resistor, for instance, so the fact that it is low means a failing module.    I have one that failed the same way and will open it today to see if I can isolate the problem.  There is an oven baked zener diode (or the like) inside and don't know if they are available.

I am in the SF bay area and if you are as well and you would like me to take a look at it, send a PM.

Jerry

[Dragon88]

Jerry, thanks for all of your detailed replies. When I have time, hopefully in the next few days, I will pull this beast out and report on the measurements you suggested. I did consider a failed calibration module, and that would be quite unfortunate. I did open it up and check visually for anything grossly wrong when I first started troubleshooting. If I can't find any likely issues in the inguard section, I'll have to pull that out again and start measuring.

Out of curiosity, have you gotten any of your repaired units calibrated? I have nothing remotely capable of calibrating a 6 1/2 digit multimeter. If I fix it I will considering taking it to the local cal lab, but the cost would probably be 3x what I paid for the unit...