Measurement Discrepancy Between Software Versions

Same EUT under identical conditions shows 31mA average current under 0.70 and 40mA under 0.50. Is this expected and due to some algorithmic refinements, or is it unexpected? I’ve really come to depend on this instrument, but I need to be able to trust it!

5

Hi @JuliaTruchsess

The 0.6.8 software introduced a new glitch removal filter. When Joulescope autoranges, it has a few samples of invalid data that need to be ignored. Previous versions were not fully ignoring this invalid data. The glitch filter defaults are usually good enough, assuming you have sufficient (> 10 µF) capacitance on your target. You can change the defaults under FilePreferencesCurrent Ranging. Prior to 0.6.8, the filter was samples_pre=0, samples_window=3, samples_post=1.

It looks like your application has enough activity that you can double-check by disabling Joulescope’s current auto-ranging. Select the fixed 180 mA current range and compare the results. Note that the specs for the 180 mA current range are 180 mA ±0.3% ±150 μA with 15 μA resolution, which is sufficient to measure 31 mA to ±243 μA accuracy = 0.8%.

However, Joulescope’s offset error is very conservative to account for all aging and temperature effects. If you remove IN and short OUT+ to OUT-, you can measure the offset error directly. I just measured 3 random units I have at my desk, and all were under ±10 μA for the 180 mA range.

Sorry, I meant to say µA, not mA in my previous post. Auto-ranging shows 38µA, but fixed range shows 66µA - that’s the difference between 3 years and 5 years of battery life :open_mouth: The Current Ranging pref appears to have no effect on the displayed average when auto-ranging in this case.

My trusty 50,000-count DMM confirms the higher number, darn :cry:

Hi @JuliaTruchsess

Thanks for posting the gif. Your device looks to be a torture case for Joulescope’s autoranging. It looks like your device is turning on quite frequently for very short durations. If you are able to share, I would be very interested in seeing two JLS files: one captured at the fixed 180 mA range and one captured with autoranging. If you pause capture, you can can use the dual markers to save just over 0.2 seconds of data from each case. Note that JLS files are currently truncated to 0.2 second multiples, so you need to select just over 0.2 seconds. You can share here or DM me.

I will inspect the JLS data for how Joulescope’s autranging performs for your case. You can see this yourself by clicking on the Waveform Settings button (could be called options :wink: ) → Addcurrent_range. One improvement that a few people have requested is to manually restrict Joulescope’s autoranging so that it can perform even better. For example, your measurement likely only needs to 180 mA, 18 mA, 1.8 mA and 180 µA ranges.

As an aside, right clicking on the y-axis and selecting Range → Manual only affects the waveform display. It does not affect Joulescope’s current range.

It’s not really an exotic use case - it’s just a PIC with a ZigBee module. Even when “asleep”, the Zigbee seems to do some kind of very brief network access periodically. The PIC wakes up every 250ms, checks a few things, then goes back to sleep.

I’ll see if I can capture the JLS files for you.

Regarding ranging, the large gap between 180mA and 2A is unfortunate, because my spikes top out at around 400mA :frowning:

FWIW, what confused me a lot early on regarding the right-click “Range” control is the use of the word “Range”, which at first seems to conflict or be redundant with the actual “Range” control set up in the control bar. The right-click control is really a “Scale” control, not a range control. You’ve already used the word “scale” for the log/lin setting, which I guess is why you used “range”, but my suggestion would be to rename the log/lin control (or better yet, just move log/lin selection to the top level of the contextual menu instead of it being in a submenu) and use “Scale” for the display scaling control.

So it turns out that all those spikes are not due to the radio module, but rather to a switching regulator. Thanks to Joulescope I became aware of the issue and have come up with a design improvement that will extend battery life by 50% :slight_smile:

1 Like

Great to hear that Joulescope helped find the issue! 50% is a big improvement. Nice work!

I am still interested in taking a look at the JLS files from before the fix, if it works out.