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!