Bench DMM Noise & Stability Comparisons with TestController

[Kleinstein]

Why the SDM4000 is more noisy would be a separate investigation. I would start with comparing the shorted case and than also check the AZ on / off and 1 and 10 PLC mode. With the SD ADC the real aperture is usually not a hard start and stop and the reading rate for AZ mode can be a bit lower than normally expected for a meter with MS ADC. The speed of the readings could give a hint how the AZ part is done. It may well be a bit slower.

The shorted input would exclude the reference and related amplifier (and gain corrections) as noise sources and this way give an idea where the noise is coming from.

From the reference (LM399) and ADC (AD7175) it should not be that noisy. The amplifier should also not contribute that much.
There are other meters (like most Keithley meters) that get extra noise from poor firmware. Maybe they copied more than just the look.

[KungFuJosh]

Maybe they copied more than just the look.

They need to copy a lot more.

[KungFuJosh]

Why the SDM4000 is more noisy would be a separate investigation. I would start with comparing the shorted case and than also check the AZ on / off and 1 and 10 PLC mode.

Well, it looks like there's more than 1 AZ bug with the SDM4065A. 9uVpp is reasonable for a 6.5 digit DMM. It's not outstanding, but it's acceptable.

Thanks,
Josh

[KungFuJosh]

And again....

May be you can explain the different statistics every time 

First, make sure you're using SI7 or SI8 for 6.5 digit meters. I usually use SI8 on mine. Keep this consistent between meters of the same digits.

Second, make sure you have a lot of warmup time for both the meter and the reference.

Third, flatline usually means the meter is no longer reporting. You will need to restart the test. I usually use the save to menu function in TC, then restart TC and run the script.

Beyond that, you will need to include more meters to understand what is happening. For my reference, I've used the same reference for 8 or 9 bench meters, with up to 5 or 6 connected at 1 time. This gives me a solid baseline to know what the best results might be.

I start with 2-minute tests, and let them run longer. Each test number is the same test sequence (Test 1- 2 minutes, 5 minutes, 30 minutes; Test 2- 2 minutes, 5 minutes, 30 minutes; etc. - I just take new screenshots at each test time).

If you're using a single ref with a single meter, it's hard to know where the inconsistency is. It helps if you can use a calibrated voltage standard.

It would also help if you're able to monitor ambient temperature. Temperature change is the most common reason (besides a broken device) to see instability in your measurements.

Thanks,
Josh

[KungFuJosh]

The Cnt: was still counting, so it did not crash.

That's not correct. TC still counts, that doesn't mean the meter still tells anything to TC, or triggers correctly, or whatever the issue. Flatline means no accurate communication.

I have to make a better setup. I have temperature meters enough 

Will report back cannot do it now.... 

lol, I'm sure you're not short on test devices.

[HKJ]

The Cnt: was still counting, so it did not crash.

That's not correct. TC still counts, that doesn't mean the meter still tells anything to TC, or triggers correctly, or whatever the issue. Flatline means no accurate communication.

TC nay accept a few missing measurements (See configuration), but will usually switch to show missing value after a short time.
It will not stop logging and you may need to look in the table to see the missing values (Depends on configuration)

I want logging in TC to be robust, i.e. it do not stop, just because there are some minor issues with a device, but it will generally show it in the table if the issue stretches over a couple of samples.

[KungFuJosh]

I've not checked the table when that's happened in the past, but the simplest answer* would be that a device might stop triggering, and when a SCPI command asks for the LAST reading, it will not change without a new trigger. So, communication is still good, TC still logs, but nothing new is accurately reported.

* That happened to me a few times when the SDM4065A stopped triggering when I tried to adjust AZ remotely.

Thanks,
Josh

[HKJ]

I've not checked the table when that's happened in the past, but the simplest answer* would be that a device might stop triggering, and when a SCPI command asks for the LAST reading, it will not change without a new trigger. So, communication is still good, TC still logs, but nothing new is accurately reported.

That is a very likely explanation.

[Salient666]

Ok, I'm slowly finding out how TestController works and wanted to compare my 34465A and DMM6500.
I am using my DMMCHeck Plus. I warmed up both the meters and the DMMCheck for approx. 1 hour, put the DMMCheck in some kind of foam compartment and started the test.
See the attached photo for how it is setup and connected.
Both meters are at 10PLC and with Auto-Zero ON.

Could I already conclude my DMM6500 is (a lot?) noisier than my 34465A ? Or am I missing something/doing something wrong? (see screenshot).

[HKJ]

Could I already conclude my DMM6500 is (a lot?) noisier than my 34465A ? Or am I missing something/doing something wrong? (see screenshot).

And it probably samples 10 times faster than you 34465 meter.
Sample rate affect noise in a big way.

[Salient666]

Could I already conclude my DMM6500 is (a lot?) noisier than my 34465A ? Or am I missing something/doing something wrong? (see screenshot).

And it probably samples 10 times faster than you 34465 meter.
Sample rate affect noise in a big way.

But both are set to NPLC=10. Or is there another 'sample rate' thing?

[HKJ]

But both are set to NPLC=10. Or is there another 'sample rate' thing?

NLPC is the thing and if that is configured to the same value, it is not the issue. AutoZero may affect the result, but that is sort of valid difference.

With NLPC you will get increased noise when it goes below one and that is not due to the meter (A fraction of it might be), above one noise is usually due to the meter.

Also note that meters may have other ways to suppress noise (6500 have a filter setting), that is a way to improve the meter and will mask it native performance.

[KungFuJosh]

Ok, I'm slowly finding out how TestController works and wanted to compare my 34465A and DMM6500.
I am using my DMMCHeck Plus. I warmed up both the meters and the DMMCheck for approx. 1 hour, put the DMMCheck in some kind of foam compartment and started the test.
See the attached photo for how it is setup and connected.
Both meters are at 10PLC and with Auto-Zero ON.

Could I already conclude my DMM6500 is (a lot?) noisier than my 34465A ? Or am I missing something/doing something wrong? (see screenshot).

Please add the grid panel (as I described earlier) so we can see PP and SD values for the noise comparison.

Please also do 2 minute, 5 minute, 10 minute tests.

Thanks,
Josh

[Salient666]

Please add the grid panel (as I described earlier) so we can see PP and SD values for the noise comparison.

Please also do 2 minute, 5 minute, 10 minute tests.

Thanks,
Josh

Here it is.
But I find one thing odd; The Keithley doesn't show SD and PP in uV, so now it's not really comparable I think?
I did not change any settings when creating the grid/dashboard. Somehow the Keysight IS showing that stuff in uV.

[KungFuJosh]

Please add the grid panel (as I described earlier) so we can see PP and SD values for the noise comparison.

Please also do 2 minute, 5 minute, 10 minute tests.

Thanks,
Josh

Here it is.
But I find one thing odd; The Keithley doesn't show SD and PP in uV, so now it's not really comparable I think?
I did not change any settings when creating the grid/dashboard. Somehow the Keysight IS showing that stuff in uV.

Are you using an old version of TC? Or do you have an old driver loaded?

The most recent driver definition I made for it has SI7 as the default.

What you're seeing is that the wrong value type is used. You can right-click the DMM6500 in the Current values tab and manually choose SI7.

If your TC version is old, please update it.

If you're still using an old driver file, please remove it and use the attached one, or copy the devices from the latest TC version that already includes the attached.

Thanks,
Josh

[Salient666]

I changed the setting. It seems that it is reflected in real-time so now I have a 20 minute test.

[Kleinstein]

Some DMMs have switching spikes from the DMM that can effect sensitive references. This might effect some not so well build references and thus way cause more noise for a parallel connected meter. The offending meter may be less effected and wait just the short time after switching.
So ideally one would check if there is interaction between the meters and also do a short test with one meter at a time.

Ideally one would not just look at the standard deviation, but plot the Allan deviation curve. Alternative one could use a FFT to see how th noise depends on the frequency. Some meters are different in this respect. E.g. quite some Keithley meters have relatively high low frequency noise also in AZ mode, while HP/KS meters usually have nearly white noise in AZ mode. So the comparison is not that easy.

[KungFuJosh]

I changed the setting. It seems that it is reflected in real-time so now I have a 20 minute test.

Those look good. I think both are performing better than my equivalent meters. Do you have any filter or sample count running on either? (your reference might also be more stable, I dunno)

Thanks,
Josh

[Salient666]

Some DMMs have switching spikes from the DMM that can effect sensitive references. This might effect some not so well build references and thus way cause more noise for a parallel connected meter. The offending meter may be less effected and wait just the short time after switching.
So ideally one would check if there is interaction between the meters and also do a short test with one meter at a time.

Ideally one would not just look at the standard deviation, but plot the Allan deviation curve. Alternative one could use a FFT to see how th noise depends on the frequency. Some meters are different in this respect. E.g. quite some Keithley meters have relatively high low frequency noise also in AZ mode, while HP/KS meters usually have nearly white noise in AZ mode. So the comparison is not that easy.

I never realized that in parallel measurents like this there would be such issues. I only kind of knew they would affect eachother by their input impedance, so the absolute measurement could be off a little.
Never to old to learn something new

[Salient666]

I changed the setting. It seems that it is reflected in real-time so now I have a 20 minute test.

Those look good. I think both are performing better than my equivalent meters. Do you have any filter or sample count running on either? (your reference might also be more stable, I dunno)

Thanks,
Josh

I don't have any filter enabled on either.. just Auto-Zero and set to 10PLC. I wonder how stable a DMMCheck Plus actually is. I want to repeat this test with my Circuit Valley ADR1399, which should be more stable (I hope so, the price would suggest this..   

[Martin72]

Your hope is probably well-founded; I have the same reference.

[KungFuJosh]

I don't have any filter enabled on either.. just Auto-Zero and set to 10PLC. I wonder how stable a DMMCheck Plus actually is. I want to repeat this test with my Circuit Valley ADR1399, which should be more stable (I hope so, the price would suggest this..   

Please do test that! I'm thinking about building one or two of those.

Just to confirm, when you open the Setup box for the DMM6500, it shows filter off and sample count 1? If so, that's good to know. I know my DAQ6510 is noisier than it should be. Having something to compare is helpful.

Thanks,
Josh

[KungFuJosh]

Your hope is probably well-founded; I have the same reference.

Break out the grid panel so we see those numbers please!

Without the grid panel, you can only compare the noise on screen, and don't get any comparable data.

Thanks,
Josh

[Martin72]

It's too late to do that now; I've already loaded the saved table of measurement values.
But you can still see that the reference isn't the worst.

[Salient666]

I will do the test with my ADR1399 reference tomorrow.
I will also do the test with an Ali-Express LM399H just for fun. I have built that in a small enclosure so that it is a little more wind-proof