Do you want to share your scripts, please? I'm very interested!
Another question, did you get a detailed calibration report, as it should be for such an instrument?
And welcome to the forum.
I can share the script, sure. But before exposing my trick to display 7+ digits I want to make sure that spying(
) Keithley guys won't have this "feature" fixed in the new firmwares
I received a "Traceable calibration certificate" with a certificate no but I don't know where to find the detailed report.
I was surprised when I first saw the calibration data. .... the multimeter can return such values, but not on the display.
How did you access the cal data?
Nice hanks, but that's 7.5 digits .
You are right that it doesn't show 8.5 digits, but I can see 8 digits in the big display mode (first digit can be 9). Let's call it 8.0 digits. Deal?
Yes, a couple of Blue Screens and some Bugs here and there, but it's liveable, though, the biggest design flaw is the FAN !
(Personal opinion )
Totally agree. I'm very sensitive to noise and thus I replaced the fans of my NAS, my lab power supply and while building my beefy 32-core dual xeon system I made sure the fans are super silent. This device is the biggest noise maker in the entire house now. I'm tempted to replace that fan with a silent Noctua fan but probably won't touch it while it's newly calibrated.
The digits beyond about 7 digits have no real value. The noise and INL error of the DMM is likely larger than that. From some point it's also just a floating point number scaling a limited resolution value. So there will be some steps no to allow all possible values in between.
There is a little value to the 7 th digit in that one can see drift direction a little earlier and does not get extra rounding or quantization error. So it's OK for the computer to use those extra digit(s), but when writing things down by hand it's usually not worth it.
I'm pretty sure that the internal representation is 64-bit floating point: I'm seeing value differences that require at least 42 bit mantissa, way smaller than the 32-bit float's 23-bit mantissa can provide. As you said that extra resolution won't provide extra accuracy or even precision for sure. But I think there is a use for that in some specific scenarios like the one I'm working on. I'm not very sure about how the sense and input terminals are actually digitized internally for the volt ratio, but looking at the graph I can definitely see some concurrent jumps in both channels, which are probably from the DMMs internal noise, and I see jumps only on a single channel, which suggests that coming from the DUT. So with some digital signal processing I can hopefully extract some stats for those 3 devices separately. We'll see.
With large NPLC and filtering values I can get a very stable 7th digit. Although a single ADC output won't have a useful info in the 7th digit, with averaging I think 7th digit is usable for some limited cases. I can see the direction of the change as you suggested in the 8th digit (probably showing the direction of the low freq noise).
I also realized another small bug: when you export a buffer to CSV, the "extra" channel isn't written with enough digits. Main reading values contain full 64bit float though. (see the images)
9.999981650865,Volt DC,...,6.984300,Volt DC,
9.999980233491,Volt DC,...,6.984298,Volt DC,
9.999979931922,Volt DC,...,6.984298,Volt DC,
As a workaround I can change my script to write the second voltage to a separate buffer instead of storing in the extra channel of the same buffer but It'd be waste of space unnecessarily.
And thanks for the warm welcome messages