'wake up' measurements difference between JS and Keysight Power Analyzer

[thanos_vgenis]

Hi there Matt,

please assist on this.

We are trying to switch from our older go-to instrument Keysight N6705C DC Power Analyzer using N6782A autoranging SMU modules to the Joulescope, mainly because it’s so much faster in sampling rate.

Our systems are low power and the specific use case we are studying at the moment is a ‘go to low power mode and wake-up every 27 ms for a certain task and fall back to low power mode’.

JS and PowerAnalyzer measurements are considerably off w.r.t. each other. Main difference is that the JS captures many samples with negative current during the wakeup-activity that I am not sure are actually there. We are expecting capacitor discharging when activity is off and system goes back to low-power mode but here we see quite some oscillation at the start of the ‘wakeup’ period.

Attached you may find captures demonstrating the above, named *_event.jpg

Also, I have captures for the period between the events, called *_sleep.jpg where you can see that in the sleep steady state both JS and PA measure very similarly at around 680 nA.

Finally, in the PA_overall.jpg capture you can see the statistics for the whole capture for PA (overall statistics for JS are in all the other snapshots). You can see that PA measures around 2.2 uA overall average current whereas JS shows 1.4 uA for the same measurement. This can have quite some impact in the battery lifetime of our products. P2P values also show what I am describing with JS presenting a very high p2p value due to the negative values captured.

We tried filtering with ‘sinc1’ filter but the UI (or JS) became unstable and kept on resetting every couple of seconds.

For our JS measurements we set max value for autoranging at 180 mA.

Please advise on how we can identify the truth and move forward. The thing is that we don’t know which instrument is right here, though JS oscillation and negative values at the start of the event are a bit suspicious to me.

Thanks very much in advance.

BR,
Thanos

[mliberty]

Hi @thanos_vgenis - Great to hear that you are working to get Joulescope up and running for this measurement challenge. Thank you for the detailed description and images.

Those wake up pulses look quite short, which is the worst case for any autoranging instrument. Let’s try to capture “truth” for what those pulses look like. We want to select a fixed range to eliminate any artifacts (JS220 or system) caused by the JS220 autoranging.

Based on what you sent, it looks like your device consumes less than 18 mA. Can you select the JS220’s fixed 18 mA range, like this:

What does the Joulescope UI show for the current waveform wake pulse with the fixed 18 mA current range selected?

The next step will be to figure out how to get the measurement accuracy you need. The 18 mA range’s rated accuracy is likely not sufficient:

We don’t know of any issues with the sinc1 filter that would cause reset. If this happens again, can you select Help → Report Issue from within the UI?

[thanos_vgenis]

Hi there Matt,

many thanks for the reply.

Please find our captures with 18 mA fixed range setting below:

The activity portion seems ‘more reasonable’ now, but is this the truth? Can’t tell…

Yet, the ‘sleep’ portion of the capture is way off, as you predicted it would be.

Regarding the issue with sinc1, we filed a ‘report issue’ and you already replied! We tried 2 different JSs on two different windows PCs, same outcome, we’ll try 200 kHz tomorrow.

BR,
Thanos

[mliberty]

Hi @thanos_vgenis - So, that is a fast pulse. By counting the samples, I think that this was captured using 500 kHz sample rate.

Can you capture the same pulse with the fixed 18 mA range, but at 1 Msps sample rate?

Also, try using the Device Control widget to set the prefilter to sinc1. The wideband filter option is more “correct” from a frequency perspective, but it will add overshoot and ringing. The sinc1 will allow more aliasing and have a narrower bandwidth, but it will not add overshoot. Does the waveform look different when prefilter is set to sinc1 relative to wideband?

So, “truth” is a challenging thing to answer. All test instruments have a measurement bandwidth. If they are designed correctly, they will “smear” fast events near or above their measurement bandwidth over multiple samples.

The JS220 uses a 6th order analog Butterworth filter with 315 kHz bandwidth. The Joulescope JS220 User’s Guide contains details. As you can see, it will add ~15% overshoot.

315 kHz corresponds to 1.6 µs pulse, at least for the first harmonic. For a clear pulse capture, you typically want 5 odd harmonics, so 11 times the bandwidth or duration. This pulse is less than 1.6 µs * 11 = 17.6 µs, so the “true” pulse shape may be distorted by the JS220’s measurement bandwidth.

Note that distortion due to measurement bandwidth will flatten and stretch pulses near or above the measurement bandwidth. However, it will maintain the integral so the integrated charge and energy will still be correct.

The N6782A only samples at 200 kHz. I did not see a spec, but that likely means the N6782A has 80 kHz bandwidth or less. The JS220 will give you a much closer view of pulse shape “truth” than the N6782A.

For a clearer view of pulse shape “truth”, you can use an instrument with higher measurement bandwidth. A 100 MHz oscilloscope is pretty inexpensive these days. If you can float your circuit by using a battery or isolated power supply with no other connections, you can easily use an oscilloscope to measure directly across a shunt resistor. If you circuit is not isolated, you need to be careful with the oscilloscope ground which is usually earth-ground referenced.

---

Once we have a clear waveform of this pulse, the next step is to figure out how to use the JS220 to accurately measure the system energy consumption. This pulse may be too fast for the JS220 to measure at the accuracy you want without some minor modifications. The JS220 autoranges in 1 µs, but then uses the 10A range for about 5 µs as it switches to the max range, which we could probably set to 18 mA. However, the error in the 10A range is too high for what you want, and it occurs too frequently so the error accumulates. We may want to try to limit the system bandwidth so that the JS220 can stay in the 180 µA or even 18 µA range. While this would further distort the pulse shape, it makes the measurement more accurate. The easiest way is to add a resistance (which may even be the JS220’s shunt resistance) with more bypass capacitance across the target. For example, selecting the 18 µA range (1111 Ω) and adding 10 µF of capacitance across your target is likely good enough to allow the JS220 to stay in the 18 µA range. Is this a viable option for your test setup?

[thanos_vgenis]

Hi there Matt,

many thanks for all the valuable information. Sadly, I don’t have that much to contribute today, apart from:

1. inline resistance test was a failure, the waveform ended up looking severely filtered, couldn’t extract any useful information.
2. got the extra captures you asked for
   here is the 18mA 1 Msps
   
   

and here is the auto range 1Msps sinc1

sinc1 didn’t do much regarding the shape of the activity compared to ‘wideband’ which was our first capture shared.

Will come back tomorrow with short nice cables to see if some of the oscillation goes away.

Many thanks.
Thanos

[mliberty]

Hi @thanos_vgenis - That pulse is very short and contains a very small amount of charge. The whole window is 25 nC.

When the JS220 autoranges from 18 µA to the 18 mA max range you have set, it uses the 10 A range to fill in the samples until the 18 mA range converges. For most measurements, this increased error is small compared to the signal. The error and noise on the 10 A range is what you see for a few samples. On my JS220 without anything connected in the 10 A range, I see p2p 7.76 mA over 6 seconds. Here is an example of the 10 A noise zoomed in:

Unfortunately, the 10 A range error and noise is significant compared to this signal of interest.

You then see a few small glitches of charge injection as the JS220 autoranges back to 1.8 mA, 180 µA and finally 18 µA (not shown on the second capture). This real charge injection due to MOSFET gate capacitance for the Joulescope shunt selection gets cancelled out over the long term.

We try to make Joulescope behavior fully observable. You can turn on the r signal in the Device Control widget and on the Waveform widget.

We are working on our third generation Joulescope product now. In addition to overall accuracy improvements, it will be able to more accurately measure short low-charge pulses like this. It’s still many months from launch, so it unfortunately cannot help you today.

For (1), you said that “the waveform ended up looking severely filtered, couldn’t extract any useful information”. However, the original goal was to compare the measured average values. The PA measured 2.2 µA while the JS220 measured 1.4 µA in autoranging configuration. What did the JS220 measure with the fixed 18 µA range (assuming it never saturated) with the additional 10 µF capacitance?

10 µF is overkill but a good place to start. You can select a different capacitance so that the signal just barely does not saturate whatever range you end up using. The 1.8 mA range may provide just enough accuracy if you let the JS220 warm up and perform a current offset trim calibration. The trim calibration allows the JS220 to significantly outperform the ±1.5 µA rated accuracy in the 1.8 mA range.

[thanos_vgenis]

Hi there Matt,

thanks again for the reply.

I’ll address more of your points on Monday, now let me state that with a bit care we managed to improve things and align with the PA which, kind of ups the confidence level regarding the consistency of our previous measurements compared to the current.

What I did was:

• limit max auto range to 18 mA
• use super short cables (ditching the extra long that were used previously)
• replace the PA that was used as a power supply with a good old dumb bench power supply. PowerAnalyzer modules are regulated (SMU…) so we have an extra control loop there with some, inevitable oscillations (that the PA itself is too slow to capture)

Each step of the above reduced oscillations and helped the average measurements.

I’ll come back, but we are ok for the time being!

Many thanks,
Thanos