Using a uCurrent with Siglent SDS1204X-E or SDS1000X-E series (feature request?)

[cardre]

Hello,

This question probably applies to all of the Siglent SDS1000X-E (and possibly other models?) scopes.

Got a new Siglent SDS1204X-E and trying to do some battery lifetime estimates with it for a coin cell powered MCU device and associated sensors that I'm working on. So using a uCurrent (early version, not Gold, but good enough) to show current draw on wake from sleep and other events.

I've got the probe on channel 1 setup in 1X mode to reduce noise and connected it to the uCurrent. I've also set channel 1 to use A(mp) rather than the default V(olt) settings for measurements. All working well so far when using the uCurrent in 1mV/mA setting. I've setup an Integral Math channel that is nicely showing the energy usage in uAs or mAs when triggering on my different types of events.

When I put the uCurrent in 1mV/uA mode to measure some of the really low power events and sleeping, obviously all the measurements shown by channel 1 and the Math function are out by 1000.

On a GW Instek scope I've used, I'm able to use a wider range of probe multipliers, specifically 0.001X to then show measurement values in 1mV/uA mode. This means all measurements etc. are showing in uA instead of mA. This also includes the values the Math channel is calculating, which is great for getting on overall energy usage for battery lifetime estimations for different types of events. For example I have a series of low power sensor readings that take 583ms with different current levels being drawn throughout the period and the Math Integral function nicely accumulates all of this for me in the appropriate uAs or mAs depending on final value.

On the Siglent, while there are many multipliers for the probe/channel values to go much higher, e.g. 10X up to 10,000X, the lowest it will go is only to 0.1X. Even if I put the probe in 10X mode combined with 0.1X, I'm still only getting an effective division of 100, rather than the needed 1000 when using the uCurrent in uA mode. Also putting the probe in 10X is increasing the noise as well, so I want to avoid this as there are relatively fast changes occurring throughout some of the measured events.

Do I just need to resign to having to convert everything (div by 1000) when working in uA mode with the uCurrent on the Siglent SDS1000X-E series?

Or is this something that can be added to a firmware update to have additional channel multipliers for probes, ideally, down to .001X if possible? If so, who do I need to send this request to?

I realise also that I can have the Math channel do a multiplier on CH1 values to reduce the readings from channel 1 by 1000. But then I can't run another Integral Math channel on the first Math channel's result to get the overall energy usage for each event. I don't think these Siglent models have a powerful enough set of Math functions to combine it this way. So a better outcome would be to just use a channel/probe multiplier of 0.001X while running the probe in 1X connected to the uCurrent in 1mV/uA mode. Then all the measurements and Math functions will show the actual values I'm after.

Thoughts?

[BillB]

Sounds like a great suggestion.  I would think that this would be relatively easily for them to implement.

[Performa01]

I see your problem and agree that we should be able to handle a wider range of probes.

Rather than adding another bunch of random multiplication factors (that might or might not fit the particular purpose) to the probe menu, I would rather suggest one or more custom settings.

The SDS1000X-E cannot do math on math - even if it could, you cannot multiply/divide by a constant anyway.

[rf-loop]

I see your problem and agree that we should be able to handle a wider range of probes.

Rather than adding another bunch of random multiplication factors (that might or might not fit the particular purpose) to the probe menu, I would rather suggest one or more custom settings.

The SDS1000X-E cannot do math on math - even if it could, you cannot multiply/divide by a constant anyway.

If Siglent want they can implement user defined probe multiplier. Just enter example x8.0166  or x0.0188 or something else what ever user want. With this feature user can always adjust what ever probe (also diy probes) and "calibrate" it to match. Also this is good for current measurements with shunt in DUT circuit and many other applications. Just these normal fixed proble multipliers as they are and then user defined multiplier. Even ancient HP54522A have it (but not very fine steps). No need copycat anyone, walk your own roads. Idea can get of course from others and from others can learn  (otherwise we would still live in the cave) but do it better.

[Performa01]

If Siglent want they can implement user defined probe multiplier. Just enter example x8.0166  or x0.0188 or something else what ever user want. With this feature user can always adjust what ever probe (also diy probes) and "calibrate" it to match. Also this is good for current measurements with shunt in DUT circuit and many other applications. Just these normal fixed proble multipliers as they are and then user defined multiplier. Even ancient HP54522A have it (but not very fine steps). No need copycat anyone, walk your own roads. Idea can get of course from others and from others can learn  (otherwise we would still live in the cave) but do it better.

That's exactly what I've suggested to Siglent product management yesterday

I don't think the rather long list of predefined probe attenuation factors makes much sense, we could drop most of them as no one will ever use them anyway. It should be sufficient to have x0.1, x1, x2, x10, x20, x100, x200, x1000 and four custom probes A, B, C, D.

The custom probes store arbitrary attenuation factors and should be permanent, just like the reference traces.
A wide range from e.g. 1E-6 to 1E6 with at least 3 digits precision should cover all conceivable practical needs.

[tautech]

If Siglent want they can implement user defined probe multiplier. Just enter example x8.0166  or x0.0188 or something else what ever user want. With this feature user can always adjust what ever probe (also diy probes) and "calibrate" it to match. Also this is good for current measurements with shunt in DUT circuit and many other applications. Just these normal fixed proble multipliers as they are and then user defined multiplier. Even ancient HP54522A have it (but not very fine steps). No need copycat anyone, walk your own roads. Idea can get of course from others and from others can learn  (otherwise we would still live in the cave) but do it better.

That's exactly what I've suggested to Siglent product management yesterday

I don't think the rather long list of predefined probe attenuation factors makes much sense, we could drop most of them as no one will ever use them anyway. It should be sufficient to have x0.1, x1, x2, x10, x20, x100, x200, x1000 and four custom probes A, B, C, D.

That should be enough to cover the Siglent passive, current and differential probe range where each of the active probes have 2 attenuation settings. 
https://siglentna-qwavztc8hvq2w.stackpathdns.com/wp-content/uploads/2017/12/SIGLENT__Probe_Datasheet_V15_Diff_Probe.pdf
https://siglentna-qwavztc8hvq2w.stackpathdns.com/wp-content/uploads/2017/12/SIGLENT__Probe_Datasheet_V15_Current_Probes.pdf

[nctnico]

I'd suggest Siglent looks carefully at GW Instek. It is not just probes but think about current shunts which can go as low las 1mV/A (1:1000) so it makes a lot of sense to support a wide range of probe factors.

[rf-loop]

I'd suggest Siglent looks carefully at GW Instek. It is not just probes but think about current shunts which can go as low las 1mV/A (1:1000) so it makes a lot of sense to support a wide range of probe factors.

Siglent do not need copycat anyone.
Fixed set of coefficients (as now) and freely adjustable "user defined" coefficients for every channel will solve all user needs. If need 1:1087 then set 1:1087 (or what ever).

[nctnico]

I'd suggest Siglent looks carefully at GW Instek. It is not just probes but think about current shunts which can go as low las 1mV/A (1:1000) so it makes a lot of sense to support a wide range of probe factors.

Siglent do not need copycat anyone.

And take very long to figure out a wheel is supposed to be round just like everybody else's  Re-inventing the wheel is not innovation! Innovation is improving what already exists.

[iMo]

That allows 1:21 with the wide-band 1kohm probe

[rf-loop]

I'd suggest Siglent looks carefully at GW Instek. It is not just probes but think about current shunts which can go as low las 1mV/A (1:1000) so it makes a lot of sense to support a wide range of probe factors.

Siglent do not need copycat anyone.

And take very long to figure out a wheel is supposed to be round just like everybody else's  Re-inventing the wheel is not innovation! Innovation is improving what already exists.

If you read discussion where you are talking...
https://www.eevblog.com/forum/testgear/using-a-ucurrent-with-siglent-sds1204x-e-or-sds1000x-e-series-(feature-request)/msg1473411/#msg1473411

[scopeman]

Hello,

I have used the math power with my LeCroy scopes to do this exact type of measurement of a system that used a primary lithium battery.

In general I used the BNC output of a modified HP428A magnetometer based D.C. Milliammeter (Hall effect devices are way too noisy for this). The output was scaled so it would read current in the desired ranges.

I then would capture the current waveform over the desired time and then use the cursors and the scope math to calculate the number of nano-coulombs used during each operation of the processor. Then when the firmware for the product was developed these values were used to predict the battery life for the product. IIRC the overall accuracy was better than 5% assuming fresh batteries were used at the start. 

Sam
W3OHM

[Performa01]

I've got the confirmation from Siglent today that the probe menu will be expanded with four custom probe factors.

Thanks for the report.

After an internal discussion, we decided to add Custom A, Custom B, Custom C, Custom D but keep the existing items unchanged.

This will be integrated into some new coming release.

This will give us the flexibility to properly scale and even calibrate all kinds of probes, sensors and test point voltages. We might not always get the correct units - quite obviously whenever something other than voltage or current is measured originally.

[cardre]

I've got the confirmation from Siglent today that the probe menu will be expanded with four custom probe factors.

Thanks for requesting this and following through on it.

I'm hoping this won't take a long time for a big next release and rather is a small incremental update. I'm needing this functionality to measure uAs now while using a uCurrent. Possibly even nA in the future.

Happy to be beta tester if it helps!

[BillB]

Cool!  As long as it doesn't slow down the SHS release 

[17_29bis]

That's exactly what I've suggested to Siglent product management yesterday

Sorry for hijacking the thread, but  Performa01  do you happen to know the status of the bug fix that should cure the problem with truncation/incorrect output of the long decoded data. That should be pretty easy to fix since Siglent already knows how to output multiline text in a table, now they should simply do it right, i.e. skip 2 first columns and put the data to the 3rd column only. I mean the following (all details have been provided in a different thread):

[Performa01]

I've got the confirmation from Siglent today that the probe menu will be expanded with four custom probe factors.

Thanks for requesting this and following through on it.

I'm hoping this won't take a long time for a big next release and rather is a small incremental update. I'm needing this functionality to measure uAs now while using a uCurrent. Possibly even nA in the future.

Happy to be beta tester if it helps!

Siglent never have released quick hacks in the past - even for beta testers - unless some really serious priority 1 bug pops up.

There is some time consuming process preceding any public firmware release; from my experience, regular firmware updates can be expected about every 6 months for new products.

Nevertheless Siglent has already started to implement the new probe menu with custom probe factors and is willing to release an updated firmware version very soon, so that you need not make do with a workaround for too long. The current plan is to get a new release out by the end of April (if everything goes smooth and nothing gets into the way, that is).

[Performa01]

Sorry for hijacking the thread, but  Performa01  do you happen to know the status of the bug fix that should cure the problem with truncation/incorrect output of the long decoded data. That should be pretty easy to fix since Siglent already knows how to output multiline text in a table, now they should simply do it right, i.e. skip 2 first columns and put the data to the 3rd column only. I mean the following (all details have been provided in a different thread)

I certainly remember that issue and I'm sure I have pointed Siglent R&D to it. I've requested several fixes and improvements for the various serial decoders myself and know for sure that they have been worked on. Given all that, there is a chance indeed that your issue might be fixed in the upcoming release.

I have asked for the status and will get back to you when I have reliable information.

EDIT: Just received the confirmation from Siglent that this bug will be fixed indeed.
 

[17_29bis]

Hello Performa01,

EDIT: Just received the confirmation from Siglent that this bug will be fixed indeed.

That's great news, thanks!  Those long data packets can be encountered in many situations, for example in case of decoding of LCD communication protocol where data is written by pages. Therefore, while it is not a critical bug it's still nice to have it fixed!
I hope Siglent will not just truncate the displayed data (that would be the simplest, 1 second fix to display only one line text ) but instead they will  choose to properly display relatively long decoded packets.
As a side note : it would be really cool if they could fix the horizontal scrolling of the decoded data as well (sorry if I am asking too much for a 1000 Canadian dollars oscilloscope).

[cardre]

Nevertheless Siglent has already started to implement the new probe menu with custom probe factors and is willing to release an updated firmware version very soon, so that you need not make do with a workaround for too long. The current plan is to get a new release out by the end of April (if everything goes smooth and nothing gets into the way, that is).

That sounds great. Thanks again for letting us know.

I'm hoping this will mean that the Integral Maths function based on a channel in A(mp) mode will correctly accumulate uA when using a probe/channel multiplier in the new custom 0.001x range for a uCurrent running 1mV/uA setting.

This will definitely save time in working out low power energy usage by just reading out the end result directly off the scope.

[Performa01]

I'm hoping this will mean that the Integral Maths function based on a channel in A(mp) mode will correctly accumulate nA when using a probe/channel multiplier in the new custom 0.001x range for a uCurrent running 1mV/nA setting.

Of course the math functions should use the correct units and that is also the reason why it would not be straight forward to add more measurement units to the channel menu (which might be handy for sensors/transducers representing some physical measurement as a voltage).

For an integral of current we would expect to get ampere seconds [ As] or Coulomb [ C] as a result, likewise volt seconds [ Vs] or Weber [ Wb] as a result for the integral of voltage. It gets even more complicated when two channels are involved, as there’s a bunch of combinations for the result with just multiplication/division already: V*V [ V²], V/V [-], V*A [ W], V/A [ ], A/V [ S], A*A [ A²] and A/A [-].

For your example of the uCurrent however, if it actually outputs 1mV/nA (which would be equivalent to 1V/uA = 1MV/A), then you need a probe multiplication factor of 0.000001 = 1E-6. This would be at the edge of the range that I’ve suggested (1E-6 to 1E6).

EDIT: It's a pain if one wants to use special characters or symbols in a posting. Initially the omega looked good in the preview, but turned into a ? after saving. Hopefully everything is reasonably readable now...

[iMo]

@Performa1: Why the scope vendors (ie your friends at Siglent) do not publish a "beta versions" of their firmware? Why to wait 6 months for a release??
The best testers are the users it seems
Even large motherboard's vendors do it..

[cardre]

Sorry for hijacking the thread, but  Performa01  do you happen to know ... [SNIP] ... I mean the following (all details have been provided in a different thread):

Maybe it would be better to mention the 'different' thread and continue the conversation there?

Thanks.

[cardre]

For your example of the uCurrent however, if it actually outputs 1mV/nA (which would be equivalent to 1V/uA = 1MV/A), then you need a probe multiplication factor of 0.000001 = 1E-6. This would be at the edge of the range that I’ve suggested (1E-6 to 1E6).

Here's a couple examples of what I was doing with a GW Instek scope that I'd like to be able to do with my new Siglent 1204X-E.

First one is easy as its 1mV/mA and I can do this now with the Siglent...


This is the one with the uCurrent in 1mV/uA mode and needs the new probe/channel multiplication factor...

This is my project in deep sleep with the accelerometer waking up 1/sec to see if its orientation has changed.

As noted above, at the moment, I'm having to just manually calculate this. I just need to be careful with units as sometimes when it accumulates enough, it can jump to the next magnitude up.

[cardre]

For your example of the uCurrent however, if it actually outputs 1mV/nA (which would be equivalent to 1V/uA = 1MV/A), then you need a probe multiplication factor of 0.000001 = 1E-6. This would be at the edge of the range that I’ve suggested (1E-6 to 1E6).

Thanks Performa01, I realised that I had used the wrong units (nA) instead of (uA) in my example, so I've corrected this above in my post.

You're spot on, of course, and it would need a 1E-6 for the nA mode of the uCurrent. If Siglent can provide down to that level and keep the units correct, this will help with those even lower current measurements down at that scale. I'm still (just) in the uA range with my current project, so I should be happy with even just 1E-3, but who knows in the future!

[tautech]

@Performa1: Why the scope vendors (ie your friends at Siglent) do not publish a "beta versions" of their firmware? Why to wait 6 months for a release??
The best testers are the users it seems
Even large motherboard's vendors do it..

This is the release version:
http://www.siglent.com/ENs/gjjrj-xq.aspx?id=2323&tid=15

We got an earlier beta version and I strongly suspect there were versions before that.
Where do you get 6 months ? 
They were only released in late Nov 17.

[Performa01]

@Performa1: Why the scope vendors (ie your friends at Siglent) do not publish a "beta versions" of their firmware? Why to wait 6 months for a release??
The best testers are the users it seems
Even large motherboard's vendors do it..

Sorry if I have been unclear.

My "friends at Siglent" are the relevant persons in product management and R&D that I'm pushing really hard to make these entry level scopes as good and flawless as possible - to the benefit of all current and future users out there. That's the one and only purpose why I have this scope and provide extensive reviews.

Beta testers receive non-public versions of the firmware prior to the release of a new product or a new major feature for an existing product - but even they don't get quick hacks within a couple of days after a feature request.

Regular firmware updates are about every 6 months and it might be a bit more frequent in the introduction phase.

In this particular case I have asked whether it's possible to provide a quick intermediate firmware release very soon as there is member cardre who needs a certain feature right now. Mind you, we're not talking about a bug fix, just additional support for a third party (kind of) probe. Siglent takes this seriously and have agreed to make a new release available as soon as possible. Getting a new feature within a couple weeks after the initial request is not too shabby in my book.

[Performa01]

For your example of the uCurrent however, if it actually outputs 1mV/nA (which would be equivalent to 1V/uA = 1MV/A), then you need a probe multiplication factor of 0.000001 = 1E-6. This would be at the edge of the range that I’ve suggested (1E-6 to 1E6).

Thanks Performa01, I realised that I had used the wrong units (nA) instead of (uA) in my example, so I've corrected this above in my post.

You're spot on, of course, and it would need a 1E-6 for the nA mode of the uCurrent. If Siglent can provide down to that level and keep the units correct, this will help with those even lower current measurements down at that scale. I'm still (just) in the uA range with my current project, so I should be happy with even just 1E-3, but who knows in the future!

The 1E-6 to 1E6 range for custom probe multiplication factors is what I've proposed to Siglent and from their reply I have no reason to believe we won't get that - maybe even more, who knows...

When looking at measurements and math, we can see all sorts of unit prefixes, at least down to pico, but I think I've even seen femto at times. So I'm positive we'll see anything from (at least) pA up to (at least) MA whenever measurement or math results call for that.

[Performa01]

I did some tests with the current 7.6.1.20R1 firmware just to make sure prefixes and units are handled correctly. I could see prefixes ranging from pico to mega as expected, which should cover all practical use cases for this DSO. I did not see femto though, so this must have been on some other scope.

First I tried simulating high currents by using 100V DC with a 10k probe factor.


SDS1104X-E_Int_DC_MA

Channel settings are displayed in kA, while math, automatic and cursor measurements use MA as required.


With the 0.1x probe factor, the lowest setting can be 50uA/div, but standard deviation in the measurement statistics is in nA and on a fast timebase, the integral can be brought down to the pAs range.


SDS1104X-E_Int_Pulse_uA

After these tests, I am positive that units and prefixes shouldn’t be an issue with the custom probe factors – but we’d need the femto prefix, see below...

I’ve also spotted a potential improvement for math functons in general and the integral in particular: the range for the Scale parameter could be a little wider than it is now.

The 2nd example uses the maximum sensitivity, which is 500pAs/div for 0.1x probe factor. Even though this should just be enough for real world applications, I would still think that it wouldn’t hurt to be able to go down to 100pAs/div (equivalent to 1nAs/div for 1x probe factor).

For the new probe factors down to 1E-6, we have to go much lower and would need the femto prefix indeed:

Probe Factor   min. Scale
1E+6               1 mA/div
1E+5               100 uA/div
1E+4               10 uA/div
1E+3               1 uA/div
1E+2               100 nA/div
1E+1               10 nA/div
1E0                 1 nA/div
1E-1                100 pA/div
1E-2                10 pA/div
1E-3                1 pA/div
1E-4                100 fA/div
1E-5                10 fA/div
1E-6                1 fA/div

There is also an issue in the first example, where I’ve used the highest Scale of 200kAs/div and this is not enough to get the entire math trace on the screen. I’m not entirely sure how the maximum Scale is determined, yet generally it appears to work just fine - just not in that particular case, where maybe some hard upper limit comes into effect.

In order to demonstrate that the upper Scale range is usually wide enough, I’ve tried the most extreme situation by setting a -2A offset in the 500uA/div range (1x probe factor). The integral can be scaled to fit the screen just fine:
 

SDS1104X-E_Int_DC_Offset_1ms

I have also tried a 1s/div timebase setting, and the math Scale automatically changed to 5As/div, just as it should be.

[iMo]

Does the scaling work with FFT result too?

[Performa01]

Does the scaling work with FFT result too?

If you mean the probe multiplication factors, they affect the FFT level results indeed.

Here are two examples for 1x and 10x probe factors:


SDS1104X-E_FFT_1x_-13.86dBV


SDS1104X-E_FFT_10x_6.14dBV

The difference of the two measurements is 20dB, just as it should be.

[cardre]

In this particular case I have asked whether it's possible to provide a quick intermediate firmware release very soon as there is member cardre who needs a certain feature right now. Mind you, we're not talking about a bug fix, just additional support for a third party (kind of) probe. Siglent takes this seriously and have agreed to make a new release available as soon as possible. Getting a new feature within a couple weeks after the initial request is not too shabby in my book.

Wondering if there's any further update on when the new probe factors firmware update being released?

Thanks.

[Performa01]

In this particular case I have asked whether it's possible to provide a quick intermediate firmware release very soon as there is member cardre who needs a certain feature right now. Mind you, we're not talking about a bug fix, just additional support for a third party (kind of) probe. Siglent takes this seriously and have agreed to make a new release available as soon as possible. Getting a new feature within a couple weeks after the initial request is not too shabby in my book.

Wondering if there's any further update on when the new probe factors firmware update being released?

Thanks.

Not sure if I understand this question correctly...

This is an intermediate update and it certainly will not be the last one.

If you mean whether this update includes more improvements and fixes than just the custom probe settings, then this is a "yes" as well.
We know at least that some issues with the serial decoders have been addressed, one of these has even been discussed briefly in this thread.

Several other issues should have been addressed as well, the majority of them not detected/reported by anyone else but me, so Siglent might decide to not include (all of) them in the public changelog.

I do not know by now what exactly the new release includes.

Btw, as you have noticed, the new firmware is delayed - probably due to the fact that I've requested that the fixes for the probe menu and the I2C decoder meet certain criteria and all this might have introduced additional effort that hasn't been anticipated right from the start.

Anyway, we can expect the release within the next couple of days. I got a notification that it is in the final production testing right now.

[cardre]

In another thread its been mentioned a new 1204X-E scope was just purchased with a .20 R2 firmware version. I can't find this new version to download anywhere yet. Does anyone know how to get this updated release?
Thanks.

[Performa01]

You'll not get a 7.6.1.20R2 firmware.

It would not be the first time that new units had a firmware with just one minor change compared to the (then) current official release.

The coming release will be much more than just the minor step from a R1 to R2. For instance, apart from the things we already know, like the custom probe factors and the fixes/improvements for the serial decoders, it will include an improved web server, several new SCPI commands and the hardware implementation of the X/Y mode (to speed it up significantly - as I've announced in my review back then).

[Performa01]

Finally the new firmware has passed the production test at Siglent and is ready to be released. It contains quite a bit more changes than the fixes discussed in this thread. See the following posting for more details:

https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/msg1555936/#msg1555936