Keysight's new 34465A (6.5 digit) and 34470A (7.5 digit) bench multimeters

[rosbuitre]

It's nice to see they can be very reactive to the bugs that you find. Please do the 34461A owners a favor and ask them to fix the continuity bug.

Well, your wish is my command..

Jim Durr just confirmed, that they've already solved this known problem, and it will be on the next FW release.
Watch for the Keysight Technology Support site, he promised to post that information there, too.

Frank

 

[TheSteve]

Dr Frank to the rescue, thank you sir.

Please, that's not my merit at all.. I just asked Jim Durr about this issue, and he told me that they already had solved it..

Anyhow, it will take some time for the official release, due to their strict Q.A. system, and PV process, i think

I realize you're not there updating the source code but your post was the first time there has even been an acknowledgment that the problem exists. As of a few minutes ago Keysight has posted on the support forum about the fix as well but before that they never gave any hint that they cared.

btw, I think it is great that they have a strict QA process but it does make one wonder how they missed the problem to begin with.

Anyway, enough about this issue as it isn't even the proper thread for it.

[sotos]

It's nice to see they can be very reactive to the bugs that you find. Please do the 34461A owners a favor and ask them to fix the continuity bug.

Well, your wish is my command..

Jim Durr just confirmed, that they've already solved this known problem, and it will be on the next FW release.
Watch for the Keysight Technology Support site, he promised to post that information there, too.

Frank

Nice   

[plesa]

Free memory upgrade for FG and DMM
www.keysight.com/find/remember_bench

Eligible Models:
     Performance DMM : 34465A, 34470A
     Function Generator : 33511B, 33512B, 33521B, 33522B, 33611A, 33612A, 33621A, 33622A
Purchase Period : 1st Jan 2016 until 30th Sept 2016
Registration Period : 1st Jan 2016 until 31st Oct 2016
Form below valid for US , Canada, Latin America.  Use the black/white globe in top right of this page to select your country.

[dadler]

Bah, punishing early purchasers. Sorta 

[SKPang]

Thank you plesa, just registered my 34470A for the free upgrade. 

[sotos]

Why it’s not for everybody?

[plesa]

Why it’s not for everybody?

I have no idea. Maybe someone from Keysight can explain it.

[Blue]

Mem upgrade for my 34465a worked also for customers in The Netherlands.

The process is a bit flaky, you need to be logged in before you can enter the website they emailed you after registration. You will obtain a pdf with two codes and instructions to go to a website. Then you will receive the *.lic file to your email addresses you wrote on that site. Please write more that 1 email address - just to be sure you will receive it.

Use a fat32 usb stick to program your dmm. ntfs did not work for my dmm.

[nctnico]

Another thing they could fix is automatic filename increments for screendumps. I see some use for making screendumps from the various plots but having to input a filename and selecting the USB stick first is a tedious process.

[HighVoltage]

Another thing they could fix is automatic filename increments for screendumps. I see some use for making screendumps from the various plots but having to input a filename and selecting the USB stick first is a tedious process.

Yes, I totally agree and I have sent this request to Keysight a while back.

[AndyC_772]

Have I just missed it, or is there actually NOT a simple way to grab a screen capture via Ethernet?

[6thimage]

Have I just missed it, or is there actually NOT a simple way to grab a screen capture via Ethernet?

You've missed it - the command is 'HCOP:SDUM:DATA?', which will return the file (either in png or bmp, depending on 'HCOP:SDUM:DATA:FORM').

Below is the python class that I use for ethernet (works in both 2.7 and 3.4) - the web option does the same as the java applet's monitor mode, where you can access the data remotely but without placing the meter into remote mode.

Code: [Select]

import socket

class instrument(object):
    def __init__(self, ip_addr, web=False):
        if web:
            port=5042
        else:
            port=5025
        self.socket=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.socket.connect((ip_addr, port))
        self.socket.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
        self.socket.settimeout(10)

    def write(self, msg):
        self._write(msg+'\n')

    def _write(self, msg):
        self.socket.send(msg.encode('UTF-8'))

    def read(self):
        resp=''
        while True:
            resp+=self._read().decode('UTF-8')
            if len(resp)>0 and resp[-1]=='\n':
                return resp[:-1]

    def read_dlb(self, UTF_decode=True):
        # definite length block
        # starts with a '#', followed by a single digit representing the number of characters
        # used to represent the data size, which is followed by the data
        # get header
        header_size=self._read(2).decode('UTF-8')
        if header_size[0]!='#':
            raise ValueError('DLB missing header, data returned {0}'.format(header_size))
        header_size=int(header_size[1])
        # get size
        dlb_size=self._read(header_size)
        dlb_size=int(dlb_size.decode('UTF-8'))
        # get data
        data=self._read(dlb_size)
        while len(data)<dlb_size:
            data+=self._read(dlb_size-len(data))
        # clear new line
        self._read(1)
        if UTF_decode:
            data=data.decode('UTF-8')
        return data

    def _read(self, buf_size=4092):
        return self.socket.recv(buf_size)

    def ask(self, msg):
        self.write(msg)
        return self.read()

    def take_screenshot(self):
        """ Takes a screenshot from the instrument, using the current format.
            This returns the data for the caller to write to a file
        """
        # request the image
        self.write('HCOP:SDUM:DATA?')

        return self.read_dlb(False)



[Dr. Frank]

After about 1/2 year of investigation, I present my Performance Review on the 34465A / 344470A DMMs.
This comprises specification conformance checks, stability and noise figures, A/D linearity and resolution.
The differences between the hardware of the 34465A and '470A were examined.

I also discovered 3 bugs on the 100V/1kV DCV ranges, an unexpected behaviour of the OCOMP function of my 3458A, and how to handle these delicate offsets on the 100mV range.


Each instrument comes with a Test Report. These always appear to be similar, as the instruments are at first calibrated to a Fluke 5720A / 5725A, and then were verified directly afterwards. The acceptance level at the calibrator is a fraction of the 24h specification.



10V is the most stable DCV range, usually on all bench DMMs. As expected, this range was spot-on for both 34465As on arrival, confirming about 1ppm DCV uncertainty in my lab.


The other ranges were always comprised of resistive amplifiers/dividers, so being more uncertain to a few additional ppm.
The 100mV range gain check requires a very accurate offset correction on both the DUT and the 3458A, as a 1µV thermal offset already gives 10ppm of error. At first, this did not work out well, due to the confusing OFFSET / STAT math function of the 3458A. In the end, I achieved an agreement of the gain constant of the 34465A within a few ppm, also.



The DCV initial verification table shows the first error on the HV ranges, i.e. a reversible +3ppm shift when setting the input impedance flag to 10M. This software error has been corrected by FW 2.10 / 2.11.

'HighVoltage' kindly lent me his 34470A. This instrument had been running continuously for about 10 months already, so its internal LTZ1000 reference drifted +5 ppm, in accordance to the 8ppm/yr. specification, and the known negative drift of the LTZ1000A. Consequently, all DCV ranges exhibit this same +5ppm drift.


As a second bug, all three instruments feature an identical systematic deviation on the HV ranges of about +10ppm on the 100V range, and a little bit less on the 1kV range.

On the first 34465A, I tried a re-calibration on these 100V and 1kV ranges. Directly after calibration the reading was spot on, but after engaging the ACAL function, the reading immediately jumped back to these +10ppm.

As a consequence, these ranges cannot be calibrated properly, in conflict to the Test Report.
It has to be emphasized, that the instruments are still inside specification limits.


Recently, I found a third error on the self heating compensation of the HV 100:1 divider. Directly after power up, the heater of the 100:1 divider is not operated properly on the HV ranges. Depending on the power on state (Factory Default or Last), either the divider would not be heated at all, or be heated permanently in the 1kV range.
This malfunction vanishes by changing range or input impedance flag, or by triggering ACAL.

This malfunction leads to a -10ppm shift of the divider ratio, very probably being identical on all instruments. Therefore, this error can be assigned to the systematic +10ppm gain shift, as this may occur during HV calibration.
This error has been fixed by FW 2.12.

When I finally re-calibrated the 100V and 1kV of my 2nd 34465A, this +10ppm shift  did not show up any more, even after engaging ACAL, so that the HV ranges were now spot-on.

The ACAL function in the end works extremely well at lab temperature, bringing all DCV ranges back to their initial reading, about +/-1ppm for 10V, and +/-2..3ppm for the other ranges.


The uncertainty of the Ohm mode does not depend on the internal voltage reference, but relies on its internal resistors only, especially the 10k VHP101 and a TaN resistor array for the current mirror. See e.g. the schematics for the 34410/411A.



All ranges were spot on, especially the 10k Ohm range on all 3 instruments deviated less than 1ppm from my own 10k reference resistors. The ACAL function also resets small temperature drifts to about +/- 1ppm deviation.

By comparing a 100k resistor on my first 34465A vs. my 3458A, I discovered an undisclosed failure mode for the OCOMP function.
This mode always requires delays of 1 sec or 5 sec for the 10k or 100k range respectively, to compensate for common relaxation effects on the DUT resistor. The normal delay settings in the msec range on most OCOMP instruments usually create errors on the order of several ten ppm.


The verification of different modes and ranges show that both instruments are still inside the 24h specification, despite the firmware bugs, and the timely drift on the 34470A!

 

[Dr. Frank]

The 34470A 10h stability test suffered from an initial temperature change of about -4°C for the first 2 hours, as it was initially sitting on a warm 3458A. The decreasing temperature reveals a T.C. of about 1ppm/°C.



The 7h stability comparison indicates much higher stability for the 34470A and a lot of popcorn noise for the 34465A. The root cause lies in the different references, i.e. the LM399H in the 34465A versus the LTZ1000A in the 34470A.






These measurements were used for an Allan Deviation diagram, also in comparison to a 35h measurement of the 3458A.

Allan Deviation gives an idea about stability capabilities for different time scales, which also identifies different noise or instability sources.

All three instruments are on par for a single NPLC 100 measurement, giving about 0.03ppm stability.
The 3458A approaches 0.01ppm / 8 digits stability at more than 20sec averaging.
34470A and 34465A follow closely, reaching below 0.1 ppm/ 7 digits level. Their different voltage references cause the better stability of the 34470A, again.






The noise performance for 0V input, 10VDC range, mainly tests A/D noise. Both instruments behave identical, maybe a factor of 5 worse, than the 3458A.

For a 10V input, noise and stability of the internal references, plus the external 5442A are characterized. At NPLC 10 and NPLC 100, the superior LTZ1000A reference again makes the difference.




In summary, both mainboards of the 34465A/470A seem to behave identically.

[Dr. Frank]

The linearity specifications are 1ppm of range plus 0.5ppm (34470A) / 1ppm (34465A) of reading.
The passes with label (neg.) indicate that the linearity of the DUT had been tested with the 3458A being reversed, so that a possible non-linearity or asymmetry would be discriminated.. obviously there is none... the 3458A is linear to about 0.02ppm of F.S.

The linearity specifications are well met. There's obviously no quality difference, in fact the 34465As seem to perform better than this particular 34470A. This also indicates, that hardware / components are identical on both instruments.

Regarding this parameter, both instruments are worth 1ppm / 6 digits only.









In the TrueVolt DMM manual, the resolution of the 34470A is specified better than the 34465A.



Very obviously, the firmware limits the resolution of the 34465A on the main display to 6 digits and to 7 digits for the statistics display, whereas the 34470A displays 7 and 8 digits, respectively.

The raw data from the A/D is transferred over the bus, as full 8 digits were output for each model.

So I tried to determine the real resolution from binning the stability data.

For the 3458A, you see a typical, quite narrow Gaussian distribution for the 10V measurement.
At 10x magnification, an irregular binning appears, with 7 different values per 0.01ppm, which gives about 17.5nV median resolution, or 0.00175 ppm, nearly 9 digits.






The 34470A shows a very similar stability distribution as the 3458A, as explained already for the Allan Deviation.
Its binning equals 0.01ppm of resolution, or 8 digits, as specified.



The 34465A has a much broader distribution, reflecting its worse LM399H reference, concerning noise.
The binning shows exactly the same resolution of 0.01ppm, like the 34470A, therefore the Keysight specification is busted.




This finally proves, that both instruments share exactly the same hardware, and only their references and the display resolution by software make the difference.


As a conclusion, both instruments are very precise and stable, with many new versatile features as ACAL, OCOMP, graphic representation of readings, data logging and digitizing.

Both instruments perform much better than the specification, especially after application of the firmware updates.
Keysight engineers gave a very quick feedback and solution on these 3 bugs, so I'm very satisfied with my new 34465A.

Frank

[quarks]

Hello Frank,
very interesting read.
Thanks a lot for sharing.

[saturation]

Thanks Dr Frank, for all the good data.

[Vgkid]

Thanks for the very informative post, Dr. Frank.

[dadler]

Any ETA on the 2.12 public release?

[Dr. Frank]

Any ETA on the 2.12 public release?

I received preliminary FW 2.12 on 13th of February. I estimate, that the SW validation will take another month.

Jim Durr told me later, that the continuity beeper problem will also be addressed, so there will be an official FW 2.13, containing both changes, I suppose.

Frank

[Messtechniker]

In consideration of your excellent review Dr. Frank, I gave my
34465A a pat on its back.

Yours - Messtechniker

[Andreas]

Hello Frank,

for the excellent support of their quality department they should have given at least a brand new 34470A to you.
(or perhaps the still in development? 8.5 Digit 34480A)

With best regards

Andreas

[Dr. Frank]

Hello Frank,

for the excellent support of their quality department they should have given at least a brand new 34470A to you.
(or perhaps the still in development? 8.5 Digit 34480A)

With best regards

Andreas

Hi Andreas,

a set of Keysight pencils and a Keysight drinking bottle also did the job, I suppose..

Frank

[TiN]

Hi Frank,

Very nice data and testing, thanks for all the efforts! May you share few more details on linearity testing methods? You measured 5440 output with both meters and calculated difference between 3458A and 344xx readings? In return I'm interested of doing similar test with other meters, like K2001/K2002.