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

[floobydust]

I find a ton of 66kHz on mains from PC power supplies (office building) and a lot of FM radio (~100MHz) when I look with a spectrum analyzer.

[mightyohm]

Is it just me, or is it surprisingly hard to find information on counts / resolution of the new Keysight meters?  It doesn't look like they've published this information in the datasheets or user manuals for the 34461A/34465A/34475A.

[ruairi]

After seeing a simple capacitance measurement noisy and then perfectly quiet with no test leads, I wrongly assumed these have mains-SMPS contributing noise. What else could it be, as no other gear in the lab suffers from this.

Bought two 34461A's to replace aging 34401's and thoroughly disappointed.  Would not purchase again.
Sorry, I am not a fanboy of these meters.

Sorry if you detailed it earlier in the thread but what was your capacitor test?  I can try to repeat on my 34465a.

[floobydust]

I'd been using a 47nF and 100nF disc capacitor. The least-sig digit is always bouncing around and worse if it also toggles the next digit., then you have two sig-digits bouncing around.
I connected the cap to the end of the test leads.

Compare with putting the cap (leads) right in the input jacks. I bend them into a "J" and poke them in.

This is with the (latest 34461A) firmware version: 2.14, Release Date: 2016-04-27;

[Someone]

Is it just me, or is it surprisingly hard to find information on counts / resolution of the new Keysight meters?  It doesn't look like they've published this information in the datasheets or user manuals for the 34461A/34465A/34475A.

In almost all situations the accuracy is much worse than the available resolution, so most users are not concerned with this as the readout resolution is excessive in their use cases (you can manually reduce the number of digits if desired). Otherwise there is a short section towards the end of the data sheet showing the tradeoff between digits and integration time.

[mightyohm]

In almost all situations the accuracy is much worse than the available resolution, so most users are not concerned with this as the readout resolution is excessive in their use cases (you can manually reduce the number of digits if desired). Otherwise there is a short section towards the end of the data sheet showing the tradeoff between digits and integration time.

Ok, that makes sense.  Maybe this is a dumb question, but given that the accuracy specs across many ranges are the same between the 34465A and 34470A, why pay for the extra digits?

Edit: I should clarify, I was looking at the current ranges.  The voltage measuring accuracy of the 70A is considerably better than the 65A, so I assume that's what folks are paying for.

[cellularmitosis]

Yeah, this is much more cryptic than it used to be.  Compare the 34401a manual to the 34465a manual:

[Someone]

In almost all situations the accuracy is much worse than the available resolution, so most users are not concerned with this as the readout resolution is excessive in their use cases (you can manually reduce the number of digits if desired). Otherwise there is a short section towards the end of the data sheet showing the tradeoff between digits and integration time.

Ok, that makes sense.  Maybe this is a dumb question, but given that the accuracy specs across many ranges are the same between the 34465A and 34470A, why pay for the extra digits?

Edit: I should clarify, I was looking at the current ranges.  The voltage measuring accuracy of the 70A is considerably better than the 65A, so I assume that's what folks are paying for.

I think you've come to the conclusion yourself, a higher model might only be improved in some areas and not all. This is common across multimeter series both bench and handheld.

[Dr. Frank]

Ok, that makes sense.  Maybe this is a dumb question, but given that the accuracy specs across many ranges are the same between the 34465A and 34470A, why pay for the extra digits?

Edit: I should clarify, I was looking at the current ranges.  The voltage measuring accuracy of the 70A is considerably better than the 65A, so I assume that's what folks are paying for.

Please read inside this thread, that the 34465A and the 34470A are virtually identical in hardware, and also in performance.
The only physical difference is the voltage reference, i.e. LM399 versus LTZ1000A, respectively.
That makes the '470A more stable and less noisy in DCV, as reflected in the specification, and by our common noise measurements.

All other parameters are identical, and over the bus, the resolution of both instruments is identical, too.
This is in contrast to the resolution specification in the user manual.

The '470A displays 7 1/2 digits in most, but not all modes, when using the instrument 'on the bench'.
But this additional resolution has nothing to do with accuracy or stability, see my review of 465A vs. 470A, also:
https://www.eevblog.com/forum/testgear/keysight's-new-34465a-(6-5-digit)-and-34470a-(7-5-digit)-bench-multimeters/msg889215/#msg889215

Therefore, you pay double the price for an LTZ1000A reference (about 350$ as spare part), and the 7 1/2 digits feeling, only.

Frank

[tomeo.gonzales]

It is possible to buy the reference from 34470A and use it in 34465A for better noise and stability performance?
The part number for reference is 34470-66303 (PCA, Reference, Tested) and on Keysight web site they say:

Products using part  34470-66303
  •34465A
  •34470A

So it seems they have a single part number for both devices.
The price is 381$

[kj7e]

Your also paying for the calibration with the 34470A.

[Dr. Frank]

Your also paying for the calibration with the 34470A.

..which is identical for both instruments.

[GlowingGhoul]

Your also paying for the calibration with the 34470A.

..which is identical for both instruments.

It's quite simple really. If you have decided to add a 6.5 and a 7.5 meter to your product lineup, you design a 7.5 and downgrade the same design to a 6.5. When it comes to pricing, the higher spec, niche product bears a higher amount of the development costs in it's pricing, as well as the slightly higher material costs.

To argue that the only difference in price should be the material cost shows why engineers are rarely involved in selling anything.

And consumers win too, because invariably the lower end product is better than if it were not derived from a higher spec design, without paying a premium.

[cellularmitosis]

Market segmentation is great and all, but be careful with creating artificial market segmentation when your primary market is engineers.  In addition to leaving a bad taste in their mouths, they tend to find a way to hack around it anyway.

[0xfede]

Hi all,

I think I may have discovered a bug in the SCPI command of the 34465A.
I'm trying to store png picture using SCPI over telnet issuing the command:
HCOP:SDUM:DATA:FORM PNG
HCOP:SDUM:DATA?
and I found that the output data is partially corrupted.
As an example the PNG header must be (hex) 89 50 4E 47 0D 0A 1A 0A and I receive 89 50 4E 47 0D 0A 1A 00.
Even If I restore the header the PNG is still garbled.
Of course if I try to download the data (I tryed even 1M samples) values are correct.
Firmware version is A.02.14-02.40-02.14-00.49-02-01

I've already submitted a support request to keysight and I'm waiting for an answer from them.

Anyone here knows something?

[0xfede]

Update:

after a few mail with Keysight and a couple test the telnet bug is obviously still there and probably they wouldn't take care of.
I used Wireshark to demonstrate that the bug is on the server (DMM) side, data is corrupted before entering the client.
For anyone interested in remoting those multimeters don't use telnet but use socket instead.

After wasting some days trying figure out what's wrong I'm very disappointed by Keysight.

Regards,
0xfede

[Kean]

This sounds like it is due to the way Telnet protocol is designed to handle certain binary data (OOB signalling, etc).
There are things you can negotiate in the protocol that could possibly get around this.  You'll need to read the appropriate RFC for more info, it has been nearly 20 years since I last implemented a telnet client and all the DO/DONT/WILL/WONT crap.
It could also be a limitation on the underlying telnet server implementation they've used, and I'm not surprised if they'd class this as a "wont fix" if there is a pretty simple workaround.

[0xfede]

Hi Kean, when I first saw the problem I looked into RFC854 (telnet) to see if the client implementation was wrong.
The only special character that needs to be managed differentely is the IAC (0xFF). Since there is no such value in the stream (before corruption) there is no reason for data to get wild.
From RFC854 (https://tools.ietf.org/html/rfc854, page 14):
'....only the IAC need be doubled to be sent as data, and the other 255 codes may be passed transparently....'

I don't know what's wrong with their server implementations but if they are not interested in fixing this bug they should avoid citing telnet compatibility in the manual.

Best,
0xfede

[exe]

Market segmentation is great and all, but be careful with creating artificial market segmentation when your primary market is engineers.  In addition to leaving a bad taste in their mouths, they tend to find a way to hack around it anyway.

I totally agree with you, but... Most equipment manufacturers target at corporate sector where it works a bit differently. Companies don't care about cost of equipment as long as it pays back.

PS I've seen people claiming "one repair justifies a new $500 soldering station" or "if you don't have a $5k+ scope then you are a bad engineer doing low-qualified work". I dunno how common is this, I'm just a hobbyist. But these guys are often selfish jerks scamming their customers. Or lucky bastards

[lukier]

I totally agree with you, but... Most equipment manufacturers target at corporate sector where it works a bit differently. Companies don't care about cost of equipment as long as it pays back.

And guess who makes the purchasing decisions in this corporate sector? Usually, the engineers recommend the equipment to the management to push it through the purchasing department. I might not be able to select a particular distributor, as corporate policies might limit that, I might not care about the cost (as much as I would do personally), but still, the equipment purchasing is not always a random process.

It might be different in the public sector (think university labs) where the contracts are won by the price alone and often there is no competent engineer in the loop. Hence the popularity of Tektronix in many labs.

PS I've seen people claiming "one repair justifies a new $500 soldering station".

That is partially true, a lot of stuff gets thrown away if it is not under warranty because often there is nobody that could (legally!) do the repairs and make it economic (it doesn't make a sense for a senior engineer waste their time doing repairs).

[Kean]

0xfede I agree - but telnet just isn't really the right protocol for transfer of binary data.

It is important to remember (or discover) that telnet has a lot of history behind it trying to support so many different needs of another era - such as teletypewriters (tel-net as in "teletype network"), as well as raw, line mode, and even block mode (3270) CRT terminals.  And of course many systems back in the heydays of telnet could only really support 7 bit ASCII (or maybe EBCDIC), even if TCP/IP & telnet protocol required 8-bits.  Protocols like X/Y/Z-modem and Kermit were still heavily used for transferring text or binary files between wildly different systems, even after networks became commonplace.  Side note - I still know of companies using my Windows terminal emulator client & the embedded/automated Kermit file transfer features.

Beyond RFC 854 there is at least another dozen RFCs trying to nail down the specification for implementation compatbility, any subset of which may have been actually implemented (let alone tested) in a particular "host" (such as the 344xxA).  e.g. RFC 856 is specifically about binary transmission, and 1123 section 3.3.1 deals with EOL stuff which ISTR was a pain across the various Unix platforms I was dealing with many years ago (let alone echo and backspace weirdness).

Glad to hear that you seem to have sorted this out by using a socket connection instead. 

Moral of the story: There is a reason the documents are called "RFC"s and not specifications or standards!   

[Echo88]

Just did a quick bias current measurement of my Keithley 34465A, just to check my new Triax-Banana-adapter-cable. Conditions: 10VDC, 10NPLC, AZ Off, Input Z Auto. Input-Voltage was 10...-10V, bias current measured with a Keithley 2500. Dont know if anyone can use this measurement, but i found it interesting.

Volt  Current
10   -7.4pA
9   -6.1pA
8   -5.0pA
7   -4.1pA
6   -3.2pA
5   -2.1pA
4   -1.2pA
3   -0.2pA
2   -0.1pA
1   +0.0pA
0   +0.7pA
-1   +1.9pA
-2   +3.3pA
-3   +4.7pA
-4   +6.0pA
-5   +8.8pA
-6   +9.2pA
-7   +10.9pA
-8   +13.9pA   
-9   +15.8pA
-10   +19.0pA

[fonograph]

In dmm noise thread,High Voltage posted comparsion where both 34470 and keithley 7510 set to 10V DCV range and he is measuring warmed up stable reference.It shows 7510 gets stable in 40 seconds while 34470 needs 20 minutes to reach stability due to warm up.

Can someone do the same tests? I am specificaly curious if 34465 with its lm399 reference warms up faster.

[fonograph]

How linear are the 34460,61,65 and 70 adc? I read on 65,70 brochure that they are 0.5ppm.Keithley 7510 datasheet shows 1ppm + 1ppm of range.

1. What is adc linearity of 34460?
2. What is adc linearity of 34461?
3. What is adc linearity of 34465?
4. What is adc linearity of 34470?
5. What is this "1ppm +1ppm of range"? I dont understand it,how is it different to just 2ppm linearity?

edit: I found another brochure,this one is from Testequity and it says 61 = 2ppm,65 = 1ppm,70 = 0.5ppm
Interesting,I thought they 65 and 70 have same adc,I tought only difference is that 70 have ltz1000,correct me if I am wrong but voltage reference doesnt have anything to do with adc linearity?

http://www.testequity.com/documents/pdf/keysight/34461A-34465A-34470A-ad.pdf

34460 isnt mentioned there,what is its linearity?

[Kleinstein]

Even if they use the same ADC circuit, and maybe even the same board (except for the reference module), there can be still a difference in the parts used. This might not be visible, like selected better ones. Another difference that is not visible is a tighter testing: so the 470 might have gone through an extra test or a more stringent test to guarantee the 0.5 ppm linearity spec.

The LTZ reference in the 470 should not take so long to stabilize. It is more like other part on the board that need to stabilize to get full or near full stability. The amount of temperature drift can vary between units, so there can be better ones too.

The DMM7510 seems to use extensive temperature measurement and numerical corrections. This way the performance can be good, but not perfect even before reaching thermal stability. It might also be lower TC by itself. However the AZ Implementaion sucks and thus quite some extra LF noise.