New Siglent SDM4000A series Multimeter

[KungFuJosh]

I'll take one.

Spot this option ?

I do like the rear jacks, but I'm guessing that's not going to be on the -SC version. I'd prefer the rear jacks though, I'm not going to replace my DAQ6510.

[ass20]

I'll take one.

it is have LTZ1000 and  adc ftom SDM4065 ?

[S13]

So i was trying to do some device sleep current measurement with a SDM4065A and i was a bit disappointed with the zero offset that came with this multimeter. So im running at the 2A DCI range and i first tried to measure the zero current level by just shorting the input. Im reading a zero level of about 380uA. Hmm, yeah when you are trying to measure microamps sleep current of say a microcontroller or something, having an offset of 380uA seems like a lot. But ok, it seems to be within spec of the meter.
Maybe i was just expecting a little bit better calibration out of the box? 

The next histogram shows the results over a couple of minutes of measuring. It has a nice span of just 35.7uA, a std dev of 5.2uA and a distribution as you would expect. It even shows the distinct converter steps.



Anyway, we can obviously use REL mode to zero out the measurements. And as expected that puts the zero level in the right spot with just minor fluctuations.
The span, std deviation and distribution curve all look similar to the non-REL measurement so no problems here.



But then the SDM4065A has an AutoZero option. But what the hell is that supposed to provide us?
- It does not zero out the measurement at all, i get an average remainder of 85uA still
- The measurement noise increases a lot! A span of 122uA, std dev 24.8uA, and the curve is all over the place
- It obviously adds lag because of the additional zero measurement in between each normal measurement



So my question is, is there something wrong with AutoZero, or what is the purpose of it?

[S13]

Sidenote: i do realize the 2A range on the sdm4065a might not be the most accurate of the ranges. The 200mA range actually has way better specs and indeed shows less offset by default. I guess that is just a result of the hardware architecture.
The AutoZero noise and offset problem however is still present on the 200mA range.

[Kleinstein]

The SDM3065 or 3055 are known to use a TIA for the lowest current range(s). With such a configuation not current should use an open input and not a shorted pinputs. The current ranges should be similar to the 200 mV range, possibly even less voltage for full scale. So the 2 A range can be relatively noisy.

The SDM3065 uses a AD8622  (pA range bias low drift BJT based amplifier, a bit like an improved AD706), likely as initial buffers for the inputs. It is not so sure if these buffers are included in the AZ loop. One should be able to see if it is included: if the AZ cycle includes it, one would see spikes in the input current from AZ switching. If not there would be essentially no AZ switching spikes.
The input buffer could some low frequency noise and thus not so great 200 mV range.

The wrong zero in the current ranges could be a problem with the calibration. It may also need quite some warm up time to stabilize.

[S13]

The wrong zero in the current ranges could be a problem with the calibration. It may also need quite some warm up time to stabilize.

Warmup time wouldn't be the issue, the problem remains even after 4 hours of uptime.
But yeah I'm thinking calibration might be the problem. So the DCV ranges are all pretty well zeroed out by the factory cal with shorted input leads. Like +1 or +2 counts across the ranges. Its just the DCI and ACI ranges that have this high offset. Its a pretty consistent ~38 counts or ~380 counts depending on the range. So with 2A it has +380 counts offset, 10A has +38 counts. These 2 ranges seem to use the same internal pathway in hardware (same amplifier or shunt resistor?), so it makes sense the offset is also scaled by a factor of 10 between these 2 ranges. The same applies to the 200mA and 20mA ranges, they both utilize the same path. And again for the 2mA and 200uA range. 

So what zero offset do other users of 4065A or 3065A get in DCI?

The User manual mentions a "User" calibration option. So you can switch between Factory calibration and User calibration. But my user calibration has obviously never been performed, so it is completely wrong at the moment (its off by like -19000 counts or something in DCI 2A). And the menu doesn't allow you to execute a user calibration without a password. There is also no documentation available for user calibration, so its a bit of a mystery to me. Seems that Siglent still needs to do some work in this area. There is a file menu where you can browse for calibration files (.cal) but i have no idea how to use that. 

This is literally the only thing the User Manual mentions about calibration:

The multimeter provides two calibration modes: Factory and User .

• Factory: Perform factory calibration.
• User: Perform user-defined calibration.

[Kleinstein]

The instructions for the user calibration for the SDM3065 seem to only allow for a full calibration, not a partial calibration, especially not a separate zero adjustment. One may get away with editing an existing cal file, but this would still need a good one to start with. With the adjustment points it would still be difficult to change only the zero point.  One still has the possibilty to use the rel. function. So zero before use. This may be the way to go, especially if the zero is also drifting somewhat (e.g. use an extra BJT based amplifier outside an AZ correction).

[Martin72]

But ok, it seems to be within spec of the meter.
Maybe i was just expecting a little bit better calibration out of the box? 

That is the crucial point.
As long as the values are within the tolerance range, everything is OK.
The meter is working correctly, and any calibration laboratory in the world would confirm that everything is fine with the device.
This can and may fluctuate over time; as long as it is within the specified tolerance, there is nothing to complain about.
If you need more accuracy, you will have to buy a better device.

[S13]

That is the crucial point.
As long as the values are within the tolerance range, everything is OK.
The meter is working correctly, and any calibration laboratory in the world would confirm that everything is fine with the device.
This can and may fluctuate over time; as long as it is within the specified tolerance, there is nothing to complain about.
If you need more accuracy, you will have to buy a better device.

But then the question remains, shouldn't AutoZero correct for this offset? Isn't that what that function is for?

[Furna]

AutoZero, or what is the purpose of it?

Pag.36 of the manual:

When the state of "Auto Zero" is ON:
The multimeter internally disconnects the input signal and measured circuit after each
measurement, and takes a zero reading. It then subtracts the zero reading from the preceding
reading (displaying the difference between the measurement value and zero value during the
measurement), in order to reduce the impact of offset voltage from input circuit on measurement
result.

[KungFuJosh]

Maybe AZ needs to be improved in the firmware?

[Kleinstein]

With the AZ part the question may be what part of the circuit is included. The AZ switching can not be all the way to the input - there is at least the protection in front and this can add some offset from thermal EMF. Other meters also choose to have the AZ switching only for parts of the circuit. E.g. with the Keithley 2000 (and likely also 2002) there is an zero drift buffer at the input and AZ switching only from after the buffer. So an offset of the input would not be corrected. There is still an extra zero adjustment for the input part that needs a short at the terminals and is usually done during adjustment / calibration.

Normally the AZ part is not that complicated. There could still be firmware issue, like insufficient waiting time when switching.
The issue may be more with the adjustment / calibration procedure, that AFAIK does not include zero but uses 2 small voltages at testpoints. It there is an ussue (e.g. with the calibrator) it can lead to a zero that is off.
Using the REL function to zero before use is usually a good work around. For really sensitive measurements it is anyway good practice to check the zero.

[TheDefpom]

New one is already released SDM4075A  7 1/2 digits with 50000 rdgs/s.

Shit... I purchased a Keithley DMM7510 a few weeks ago.

[S13]

With the AZ part the question may be what part of the circuit is included. The AZ switching can not be all the way to the input - there is at least the protection in front and this can add some offset from thermal EMF. Other meters also choose to have the AZ switching only for parts of the circuit. E.g. with the Keithley 2000 (and likely also 2002) there is an zero drift buffer at the input and AZ switching only from after the buffer. So an offset of the input would not be corrected. There is still an extra zero adjustment for the input part that needs a short at the terminals and is usually done during adjustment / calibration.

Yeah i guess that makes sense.
So i think the whole AutoZero is a bit pointless then. If it just adds noise, doesnt fully compensate for offset (not like REL or proper calibration), and makes the sampling much slower, its just not worth it. Yeah it could compensate for drift while making long measurements, but to be honest i dont think the meter drifts all that much in short timespans of minutes to hours. Maybe if you have wildly fluctuating temperatures its a different story, dont know...

Perhaps Siglent should have implemented a self-cal function on the 4065A. But since they didnt, they should definitely work on getting that User Calibration function working properly!
Then again, I guess the whole firmware is still a bit alpha. Maybe they are just working on getting the 4075A released first and then start working on refining the firmware. You would expect this whole calibration thing would be even more important on a 7.5 digit meter, right?

[KungFuJosh]

New one is already released SDM4075A  7 1/2 digits with 50000 rdgs/s.

Shit... I purchased a Keithley DMM7510 a few weeks ago.

Oh darn, looks like Scott is gonna have at least two 7.5 digit meters. 

[Kleinstein]

With the SMD3065 / 4065 the value of AZ mode may indeed be limited. The SD ADC chip already has quite good zero drift specs. With many MS-ADCs the ADC itself has quite some zero point drift and there is also low frequency noise. For these it absolutely makes sense to use the AZ mode. With longer integration (e.g. 50 PLC) it can already reduce the noise by suppressing much of the 1/f noise.

It depends on how it is implemented - the HP meters have AZ switching usually only the protection and a little signal switching before the AZ part. So they can compensate for most of the zero drift. It is mainly the thermal EMF from the protection that can't be corrected.

I have some hope that the 4075 could be a reason to improve on the calibration / adjustment points so that 0 V is included.
Quite some of the specs (especially speeds) still look similar to the 4065 and chances are it would be the same ADC, but with a better reference.

[dEdt]

There is a firmware update to version 0.0.0.20 (Release Date 10.10.25) available for the SDM4065A from Siglent, solving at least problems I had with setting the vertical scale of the trend chart (uA/nA input was not possible, had to type as mA value 0.xxxxxx).

[S13]

8/19/2025 0.0.0.20
1. Supports SMB and NTP functions.
2. Optimized noise after AZ is enabled.
3. Optimized noise after 100PLC is enabled.
4. Supports saving readings, statistics, and histograms in the scanner card function.
5. Supports relative value settings, statistics, and histograms in the dual display function.

6. Bug fixes
a) System crashes when entering the wrong password during recalibration.
b) Statistics occasionally show 0 in math.
c) Fixed an issue where overload values were recorded during probe-hold.
d) The digitizer would freeze at certain sampling rates and readings.
e) Device malfunctions occurred when using the scanner card's universal remote control command function.
f) File path errors when browsing when holding readings.
g) Selecting uA in current mode did not work.

I think Siglent is following this thread! 

[S13]

I can confirm that the AutoZero noise has been improved. Compared to my previous measurements at 2A DCI, im getting about a 45% reduction in noise (~13.4uA stddev vs 24.8uA). But this is still twice as much noise compared to non AutoZero mode.

Still a welcome improvement i would say 

[Martin72]

I think Siglent is following this thread! 

Looks like it...

[Kleinstein]

I can confirm that the AutoZero noise has been improved. Compared to my previous measurements at 2A DCI, im getting about a 45% reduction in noise (~13.4uA stddev vs 24.8uA). But this is still twice as much noise compared to non AutoZero mode.

Still a welcome improvement i would say 

The AZ mode trades more short time noise for less drift and less low frequency noise.
To really compare one would want to look at the allan deviation curve. There is usually a cross over time from which on AZ mode is better.

[S13]

The AZ mode trades more short time noise for less drift and less low frequency noise.
To really compare one would want to look at the allan deviation curve. There is usually a cross over time from which on AZ mode is better.

True, but i dont see the meter drifting that much in the span of hours or days (which i assume is the timespan where most of the data logging is done). That cross over point is probably way beyond that. Unless there is maybe temperature drift influence i suppose?


Anyway, i did some more measurements today, including some CSV exports of captured data. I see they fixed the timestamp bug in the CSV file that i mentioned earlier. It now properly displays the start timestamp with milliseconds, microseconds and nanoseconds (!) 

I am a bit puzzled though by the available memory for storing measurements in Normal mode (so not Digitize or Datalog). It appears the data just keeps logging and logging forever. The trend plot and histogram keep plotting correctly to well over 100 million samples! That is actually amazing! 
But no idea where the limit is to be honest...? (im up to 197M as we speak...) Maybe until that 512MB internal Ram is full?
So for histogram you obviously dont need to store all of the samples, but what about the trend plot and stddev calculation? Is siglent doing some smart sample decimation for the trend plot to keep the screen data valid? Interesting!

*** New bug report ***
When trying to save acquired samples in Normal mode (not Digitize or Datalog) to a USB stick you only get 2 million samples maximum in the CSV file. I assume that this 2M number is what is stated in the user manual. But here is the thing: If the meter has acquired more than 2M samples (as shown in the statistics window), the CSV file becomes corrupt. You do get the 2M samples in the CSV file, but at a random location the timestamps become corrupt (even negative timestamps). Im not yet sure what happens to the data, i will try to analyze that in more detail later.
Note: If the meter has acquired less than 2M samples, the CSV file is correct.

[Kleinstein]

With more conventional DMMs with MS ADC the cross over where AZ mode gets better than non AZ can be quite low, like 1 or 10 seconds.
The later the cross over, the more sensible to use non AZ mode. I don't know the front end details, but in the SDM3065 there are AZ OP-amps directly at the ADC and it looks like AD8622 BJT based low bias OP-amps at the input.  The current ranges may have extra amplification and may not be the best example for judging the meter. Where the cross over happens can also depend on the range.

Already 2 M data points in a CSV file is quite a lot. One rarely need such long datasets. 197 M points would not really fit in 512 MBytes, even with just 24 bits and no compression.  One can calculate the std. dev. without saving all data. It only need a few more sums independ on the number of points.

[2N3055]

Having Samba is very convenient to directly save to network share...
Also web control (VNC) is too, because when doing something sensitive where you don't want to come close too much you can nicely have things under control from afar..

[S13]

Ah yes i see there exists a Running std deviation method, that would solve that issue.

And for the trend plot, as you say it is virtually impossible to store all those samples in memory and plot them on the chart. So there must be decimation going on, at least for the higher sampling frequencies (in my test I was running at 50ks/sec). I assume it is something similar to peak-detect mode of a scope.

Already 2 M data points in a CSV file is quite a lot. One rarely need such long datasets.

True, but it is nice to know the limitations. And obviously if you do exceed the limit by accident you wouldn't want the data to become corrupted in the CSV. With 50ks/s you reach that limit in just 40 seconds.

What would be the preferred behavior with this 2M limitation?
Should the meter only memorize the first 2M data points after the start of an acquisition, and ignore subsequent measurements?
Or should it behave more like a 2M FIFO, so you always store the last 2M measurements?

Tbh i dont care which implementation is chosen, but it should at least be clear for the end user, so you know what data you end up with.