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

[bson]

Today my Keysight 34470A arrived...

Same "axis numbering" problem on my brandnew 34465A:

2.5 , 2.5000 , 2.5001  - WTF? 

Isn't there enough place for:
2.49995 , 2.50000 , 2.50005

It's actually...
2.500 10
2.500 05
2.500 00

But, yeah.  Agreed on the for rounding and truncating axis labels in the first place.  You're not the first to trip over this!

[carl_lab]

Today my Keysight 34470A arrived...

Same "axis numbering" problem on my brandnew 34465A:

2.5 , 2.5000 , 2.5001  - WTF? 

Isn't there enough place for:
2.49995 , 2.50000 , 2.50005

It's actually...
2.500 10
2.500 05
2.500 00

But, yeah.  Agreed on the for rounding and truncating axis labels in the first place.  You're not the first to trip over this!

Yes, you're right. And it shows, keysight cannot even round correctly, they just truncated the values...
That's not what I expect, when I spend $1500 or more...

Is anybody here, who has a good contact to Keysight/Agilent/HP, who could ask for solving this bug?

BTW: How can I store a screenshot of the instrument's display?

[Andreas]

Yes, you're right. And it shows, keysight cannot even round correctly, they just truncated the values...

Shure?

Most probably their math package uses "round to nearest even" to avoid propagation of rounding errors e.g. in statistics mode.

With best regards

Andreas

[HighVoltage]

Is anybody here, who has a good contact to Keysight/Agilent/HP, who could ask for solving this bug?

I think this one has made it in to the requested changes for future FW updates.
Also, I would wanted to have the StdDv shown in engineering notation or proper units and not so many zeros.
Like the 34410A / 34411A has it shown.
5.67 uV on the 43410A instead of 0.000,005 V
Hopefully we will see this in a future update as well.
[/quote]

BTW: How can I store a screenshot of the instrument's display?

You can save it to a screenshot or use Benchvue or over the LXI web interface.
It is pretty easy and works well.
 

[carl_lab]

Yes, you're right. And it shows, keysight cannot even round correctly, they just truncated the values...

Shure?

No, maybe "round to nearest even" is used, you are right, but...

Most probably their math package uses "round to nearest even" to avoid propagation of rounding errors e.g. in statistics mode.

...on axis numbering, same result as shown in screenshot (2.5 , 2.5000 , 2.5001 is nonsense).

...I would wanted to have the StdDv shown in engineering notation or proper units and not so many zeros.
Like the 34410A / 34411A has it shown.
5.67 uV on the 43410A instead of 0.000,005 V
Hopefully we will see this in a future update as well.

+1

BTW: How can I store a screenshot of the instrument's display?

You can save it to a screenshot or use Benchvue or over the LXI web interface.
It is pretty easy and works well.

OK. I tried to save to USB and got only raw data...

[Dr. Frank]

Same "axis numbering" problem on my brandnew 34465A:

2.5 , 2.5000 , 2.5001  - WTF? 

Isn't there enough place for:
2.49995 , 2.50000 , 2.50005

It's actually...
2.500 10
2.500 05
2.500 00

But, yeah.  Agreed on the for rounding and truncating axis labels in the first place.  You're not the first to trip over this!

At first, yes, there is not enough space to display all these digits. It's a 4.7" LCD only, and for an old man like me, some numbers are already too small to read, sometimes.

2nd, the rounding usually is done properly with the latest FW 2.14 (a similar issue has already been addressed in a recent version).

It is disturbing, anyhow, as this often gives identical numbers for 2 of the 3 labels.

3rd, in this case the limits are more probably 2.499 95 / 2.500 00 / 2.500 05, which would precisely be rounded to 2.5, 2.5 and 2.5001, as displayed.

Instead of guessing about that, you may use the "Vertical Scale" menu, select 'Manual', and then set Low and High parameters.

Here, the real limits are displayed to 6 to 7 decimal places, I think, and you also can then define the appropriate Y=window, which often is not set optimally, when using AutoZoom.
Afterwards, you might leave this menu again, to have full view of the measurement window.

I've seen a better solution for that space vs. resolution problem, I think, it was on the KEI 7510, i.e. the 'base value' is displayed to one or two decimal places somewhere on a major tick, and the major ticks divisor is displayed separately at the top.
In this case , that would be displayed as '2.5' and major ticks as '5.0E-5', minor ticks then would be 1E-5.

Such an engineering format would also be useful for the StD value, to overcome the same problem of small differences, also.
So I totally agree to HighVoltage, that KS should make another update for that.

Frank

[Faith]

I've seen a better solution for that space vs. resolution problem, I think, it was on the KEI 7510, i.e. the 'base value' is displayed to one or two decimal places somewhere on a major tick, and the major ticks divisor is displayed separately at the top.

Yep >,<"... The DMM7510 solves this problem quite elegantly as demonstrated here:



Not my DMM! Could never afford this beast!~

But I also had a big face-palm moment when I first encountered this problem with my 34465A.

Also thank you for replying to my earlier message regarding the Trend Chart!~

[Dr. Frank]

BTW: How can I store a screenshot of the instrument's display?

It's explained in the RTFM, or in the HELP menu.
Press <Shift> DISPLAY, and then there should be an item inside the file management items, labelled as screen shot.
(Don't have my instrument at hand right now.

The display content, just before you press <shift> will be stored.

Frank

[KE5FX]

I dunno.  That looks like ass, IMHO.  With a wide-aspect display like this, it certainly wouldn't have done any harm to spend a few horizontal pixels replicating the +5.04 at every graticule line.

Graph rendering isn't a ripe subject for "innovation" unless you're absolutely certain you're improving things.  If this labeling method didn't catch on in the 400 years since Descartes, what are the odds that it's the right thing to do now?

[carl_lab]

BTW: How can I store a screenshot of the instrument's display?

Press <Shift> DISPLAY, and then there should be an item inside the file management items, labelled as screen shot.

Thank you!

At first, yes, there is not enough space to display all these digits.
2.499 95 / 2.500 00 / 2.500 05

OK...?
I had no problem to find space for the additional (one) digit, see attachment.
(The red marked distance is unchanged, but could be reduced, too.)

[Faith]

OK...?
I had no problem to find space for the additional (one) digit, see attachment.
(The red marked distance is unchanged, but could be reduced, too.)

I believe the reason for that extra space is to account for the worst-case-scenario for the following two extra characters: one for when you go down to the lower ranges (I believe the number will get suffixed with m/u), and another for the extra digit on the 34470A.

Yes I do also believe that this is all pretty ridiculous but that is how the UI was designed it seems; to have a fixed size and to account in advance for the most amount of characters which need to be displayed. Would prefer if this was implemented better.

As has been said already numerous times already; the screen isn't all that large. But all the more important that screen real-estate is utilised in a more efficient manner, no? So I really have no idea why the graph doesn't just scale horizontally to cater to what's required.

[KE5FX]

I dunno.  That looks like ass, IMHO.  With a wide-aspect display like this, it certainly wouldn't have done any harm to spend a few horizontal pixels replicating the +5.04 at every graticule line.

Graph rendering isn't a ripe subject for "innovation" unless you're absolutely certain you're improving things.  If this labeling method didn't catch on in the 400 years since Descartes, what are the odds that it's the right thing to do now?

Also, what's going on in the last few lines, where the scale goes from .184 ... .096 ... .008 ... .920?  Am I supposed to mentally apply the "+5.04" prefix to all of these?  That's a worse bug than anything in the Keysight screenshots.

[Faith]

Also, what's going on in the last few lines, where the scale goes from .184 ... .096 ... .008 ... .920?  Am I supposed to mentally apply the "+5.04" prefix to all of these?  That's a worse bug than anything in the Keysight screenshots.

Oww >,<"... did not see that. That's bad. Sigh.

[Dr. Frank]

Well,
Now, that I'm sitting in front of my 34465A, I have to admit, that my advice, setting the Vertical Scale manually, does not fully work.
The resolution is the very same, as the automatic graph scaling, for 2.500 00V, it's also 10µV only:



But anyhow, manual scaling will set Low and High to even values, and setting Center / Span instead, gives a better control over the window in most cases.



For such small differences, I found a better approach. By using the Math Scale function, you might either substract the average value (B = 2.500 000V), with a resolution of 1µV, and the window is now controllable in Center and Span to fractions of µV. Note also, that the instrument displays down to the resolution of the A/D, about 8 digits, or 100nV.




By scaling with M = 0.400 000 and B =1, you will get a tidy readout in ppm, for the deviation from 2.500 000V.
That's really cool, viewing NPLC 10 vs. NPLC 100 in 0.1ppm resolution.
Note, how stable the 34465A performs.



Frank

[Dr. Frank]

Another extreme zoom, 10V from Fluke 5442A, displayed in +/- 0.1ppm window, 0.01ppm resolution.

Regarding short term stability, the 34465A performs like a 7 1/2 DMM, isn't it? 

[dr.diesel]

I realize this isn't a Keithley thread, but if anyone would like to see similar screenshots from the k7510 for comparison I'd be happy to post them.

[Dr. Frank]

I realize this isn't a Keithley thread, but if anyone would like to see similar screenshots from the k7510 for comparison I'd be happy to post them.

That would be great.. I would appreciate seeing examples from your instrument, here.
The 7510 can do scripts, which may overcome some of the formatting problems, probably.

For sure, it can do something like this, expressing the whole statistics in ppm.. gives much bigger resolution for the StD value..




That's 10V from the 5442A, reading is 1.9ppm high, but about 0.097ppm StD, which really is worth 7 1/2 digits.. 34470A and 34465A are identical in hardware, aside from the reference.
I've simply chosen M = 100,000, B = 1,000,000, and ppm as unit.

Frank

[bson]

For such small differences, I found a better approach. By using the Math Scale function, you might either substract the average value (B = 2.500 000V), with a resolution of 1µV, and the window is now controllable in Center and Span to fractions of µV. Note also, that the instrument displays down to the resolution of the A/D, about 8 digits, or 100nV.

Ooh, that's nice.  Why didn't I think of this!

[dr.diesel]

For sure, it can do something like this, expressing the whole statistics in ppm.. gives much bigger resolution for the StD value..

mx+b is a built in math function, but outside of the program area/scripts, I can't change the unit.   

[Keysight DanielBogdanoff]

Is anybody here, who has a good contact to Keysight/Agilent/HP, who could ask for solving this bug?

Howdy. I'll pass this thread along, although I'm pretty sure this team monitors the forum.

[carl_lab]

Thanks, Daniel!

[Alex Nikitin]

Received the 34465A today. After ACAL it agrees within 1ppm with our HP3458A Opt002 meter (calibrated in January) on my self-made 10K reference and on 7.16V from LTZ1000 . Quite impressive for both meters to agree that nicely.

Cheers

Alex

[HighVoltage]

Congratulations on your 34465A and nice comparison to the 3458A.
What 10 k Resistor did you base this on, to be so perfect on the mark?



 

[Alex Nikitin]

Congratulations on your 34465A and nice comparison to the 3458A.
What 10 k Resistor did you base this on, to be so perfect on the mark?

Thank you!

This one. .

Cheers

Alex

[bson]

As a note, it's very easy to grab screenshots onto a USB stick.  No need to point a phone at it.