Repair worklog : Old rusty HP 3458A

[TiN]

Christmas time here.

Received few boxes of goodies today, one of which contained A3 PCBA.
Replaced A/D board in 3458A, and as you expected, it worked just fine. There was another fault - 204 : Level DAC Convergence, but that was due to dodgy EL2018 comparator on A2 AC board. After it's replacement - Self test PASS, calibration 0 passed, calibration 10V passed, calibration 10K passed.

Meter is assembled with shields and covers, I'll leave it running 24/7 to see if any other issues pop-up.

I also pimped up my A9 LTZ1000A reference to reduce temperature, prior to calibration:



Fancy 0.3ppm/K VHP101 custom-aged 95K000 resistor used on R114 location.

[TiN]

[Dr. Frank]

Fingers crossed, that it works now!

Additional cost for the A/D board..

Would be interesting to find out about ERR 114, ..convergence.. if that is related to the ASIC, then 3458A with error of that kind all need new board, not only the EL2018..

Hope, that you will now finally be in the club by tomorrow!
Was a real pain to see you suffering with these failures..

Frank

[Macbeth]

When this new board does work hopefully you will have another stab at finding what was wrong with the old one, e.g. swap U108 over. If that fixes it then try this new board with the old U108 (or whatever suspect) to make extra sure its just that part alone and not some mix of components all conspiring against you. 

If it's not an unobtanium part then maybe you can at least recoup some cost by fixing the old board. Besides, it's component level repairs I like to see, not board swapping   

Good to see you got a partner for it with the 3245A. Are you turning into a HP fanboy now? Poor Keithley...

[ManateeMafia]

I also have an A3 with the same 114 error. It originally was considered a good spare but ...  This is not the same A3 where the El2018 fixed the problem of no readings from the board.

 I have put off diagnosing it for a few days while working on other projects. I can confirm that temperature is a factor. It takes 30+ minutes for the first error then it consistently throws errors every couple of seconds with all covers on. With the covers removed, it will error once or twice an hour.

Cooling spray will be difficult due to the infrequent errors with it open. My thought is to set my hot air station to its lowest temperature and apply heat for a couple of seconds. My concern is the temperature may be 100C or higher.

I have confirmed that all voltages are good except for the LM358 (U170) is being fed ~ -16.8vdc. The datasheets list 16v as an abs max supply voltage for this IC. I have not replaced any parts yet but it was received without one of the EL2018's. I installed one but as expected, the error did not change.

If you have any tests to run, let me know. It would be great to find at least one cause for this error outside of U180.

Of course, I can use Macbeth's suggestion and swap the U180's with a good board.

The plan is to test it this weekend barring any changes in my work schedule.

[TiN]

You can call me chicken, but I'm not even looking on new board, leave alone swapping something on it, lol

Will have another peek on old board some-when in future, when get new ideas, but not involving new board. I have few ideas to try, but need finish all other projects which delayed due 3458A too .

[TiN]

Are you turning into a HP fanboy now? Poor Keithley...

I still have more Keithley's than HP's. Let's see. Four 2001's, one 182M, one 2400, one 2002, one 2000, one 2510, parted 7001 against HP 33120, 4263B, 3245A, 3458A. K wins.

All HP gear is calibrated against my Keithley 2001 (which was cal'd by Tektronix in Feb/2014). After few months of running 3458A (hopefully, issue-free), I'll get some confidence and will take 3458A to local metrology institution to calibrate against JJA. After than unit will be sealed permanently and will be used as primary 24/7/365 realtime online monitoring for voltage reference bank.  .
At least, that's the plan for nearest future.

[TiN]

This morning is sunny here, ambient temperature raised up to +30°C, meter internal temperature read +39.7°C, sampling 10V at NPLC 50, no problems second day. 

[Dr. Frank]

This morning is sunny here, ambient temperature raised up to +30°C, meter internal temperature read +39.7°C, sampling 10V at NPLC 50, no problems second day. 

 

With the original fan, and a cleaned filter, the interior heats up 13°C above ambient, instrument sitting free on table top.

Yours only rises 10°C.
Did you install a stronger fan than the original one?

Frank

[TiN]

I got same rating fan, but not exactly same model/vendor, so it might be bit stronger with overdrive at +15V. I think I listed exact fan Digikey P/N before.

Or your fan become old and dropped it's speed perhaps

EDIT: I don't have fan filter installed atm, that's probably why.. 

P.s. still good, running EZGPIB script to capture short DCV noise

[TiN]

Tested noise with simple AWG26 copper wire short. Still running script for faster NPLC's.
Added ManateeMafia's data from July 2015 on his 3458A for reference (red lines on graph).

This is standard deviation data, not RMS values.

100mV range. I wonder what's up with that dip at NPLC 50 and slower.



1VDC range, same dip.



10VDC base range



100VDC



1KV range

[Kleinstein]

The increasing noise at more than 50 NPLC likely come from something like 1/f noise. This could be directly from the FETs or due to thermal effects. If no auto zero is used this would be some kind of slow drift that get visible. If Auto zero is used, it is just too long in between.

[TiN]

1/f noise? Why other unit is not showing it then? 

[Jay_Diddy_B]

Hi,

Is your unit open?

You may need to shield (the reference) from air currents??

Regards,

Jay_Diddy_B

[TiN]

No, everything is assembled and closed, as it should be.

[OldSchoolTechCorner]

You can call me chicken, but I'm not even looking on new board, leave alone swapping something on it, lol

Will have another peek on old board some-when in future, when get new ideas, but not involving new board. I have few ideas to try, but need finish all other projects which delayed due 3458A too .

Curious to see what failed on that A/D board.

[Kleinstein]

LF noise due to thermal effects (much of this depends on local  thermal drift) and 1/f noise of JFETs are not the same on all units. Some may be better than others.

As the effect is larger in the low voltage ranges, this is very likely an effct of the input amplifier or input circuit, definitely not from the reference voltage.

In many applications one can get around this, by using the instrument at something like 10-50 PLC and do averaging after this. 

[TiN]

It might be different amount of samples. I had 10 minutes sample window, while reference data is 30 minute sample window. Should not impact so much though.
I also ran other NPLCs, including fast ones, note step when A/D changes slew rate just at 0.006 NPLC (100us), following graph in HP 1989 Journal 

Also 200NPLC point not following 1/f noise theory...

[TiN]

Few photos I forgot to post before:





I did replace front/rear switch, as original one had missing locking spring to keep position. Also who knows how good were original contacts....



New switch was ordered from Keysight, 55$.

Now meter is sampling AD584KH 10V output with NPLC 200 using Raspberry Pi + Python script:

Code: [Select]

# xDevs.com Python test GPIB app
# http://xdevs.com/guide/ni_gpib_rpi/
import sys
import Gpib
import time

with open('10v.csv', 'a') as o:

    inst = Gpib.Gpib(0,1) # Instrument GPIB Address = 17
    inst.clear()
    #inst.write("*CLR")
    inst.write("PRESET NORM")
    inst.write("OFORMAT ASCII")
    #inst.write("BEEP")
    inst.write("DCV 10")
    inst.write("TARM HOLD")
    inst.write("TRIG AUTO")
    inst.write("NPLC 200")
    inst.write("NRDGS 1,AUTO")
    inst.write("MEM OFF")
    inst.write("END ALWAYS")
    inst.write("NDIG 9")
    inst.write("DISP MSG,\"                 \"")
    inst.write("DISP ON")
    #data = inst.read()
    #print data
    o.write("date;hp3458a;data;\r\n")

    min = 0
    while min <= 10000000:
        min+=1
        inst.write("TARM SGL,1")
        data = inst.read()
        time.sleep(5)
        print time.strftime("%d/%m/%Y-%H:%M:%S;") + ("[%8d]: %9.8f" % (min, float(data) ) )
        o.write (time.strftime("%d/%m/%Y-%H:%M:%S;") + ("%d;%9.8f;\r\n" % (min, float(data) ) ))

Good idea to use DISP MSG command to output empty spaces, so you will not kill VFD too quick when running long data capture sessions. Only problem, bottom line like "SMPL", "MRNG" segments still lit. DISP OFF command disables them, but it outputs "-------" dashes on main line instead 



I'll be out of town this weekend, so meter will be left on, running this piece of code for 2 days.

[ManateeMafia]

Maybe a peek inside the ROM code will show where the dashes are and a hack to replace them with spaces can be made.

[Jwalling]

Maybe a peek inside the ROM code will show where the dashes are and a hack to replace them with spaces can be made.

Couldn't that screw up the checksum so it will fail self test? I suppose it could be possible to make a change elsewhere to compensate...
Jay

[PA0PBZ]

Maybe a peek inside the ROM code will show where the dashes are and a hack to replace them with spaces can be made.

They probably do:

Code: [Select]

dash = 16
while dash > 0
output '-'
dash--
wend

so it would be hard to find...

[ManateeMafia]

Maybe a peek inside the ROM code will show where the dashes are and a hack to replace them with spaces can be made.

They probably do:

Code: [Select]

dash = 16
while dash > 0
output '-'
dash--
wend

so it would be hard to find...

I did a quick search and found two instances of 16 dashes in the ROM (Rev 9)

Couldn't that screw up the checksum so it will fail self test? I suppose it could be possible to make a change elsewhere to compensate...
Jay

Definitely yes as the system has error codes for ROM checksum. Looking through the code I could not easily determine where the checksum is stored. Presumably it is contained in the last several bytes of the file (last several non FF bytes).

Is it worth the effort? Maybe not, but it might be an option once the 3458A is discontinued and replacement displays become unobtanium.

[TiN]

I'll look into firmware, should be rather easy to hack into.

Meanwhile, ran script to capture noise on short ppm/range once again, this time with 30minute sample window and LFILTER ON.



Much closer to MM's 3458A, but still away from Dr.Frank (his results not using scripts, nor autozero, also no NPLC1000).

One thing I noted from reading manual that actual NPLC >10 is not increasing integration time, but just doing averaging of NPLC10 samples. There is other way to set speed, using APER command, with maximum integration time as 1 second. Should try that.

Running now without autozero, 5min window. No errors from meter so far. 

If anyone with 3458A want to jump in, just get this EZGPIB script and EZGPIB itself. It takes 17 hours to complete run on all ranges/NPLCs. It can be quicker if reduce window

Code: [Select]

const duration=30;                // Acquisition time in minutes / cycle

Final internal view on both sides of meter before shields installed:

[VK5RC]

@TiN, MM and Dr F, I think you have a lot to answer for ! (HiHi)
I have just bought a 3458A that needs a little love (1 Fault = RAM Test Low) for a reasonable "Australian" price (in Australia at present everything is really expensive for us, so a good place for you guys to visit for a holiday). I have a lot to read about memory management in general and about a 3458A. If I get stuck I may ask for some help but it may take me some time - i.e. weeks (in between pesky but paying day job) to get my head around these issues