True RMS values

Forum for discussing PicoScope version 6 (non-automotive version)
Post Reply
jtk
Newbie
Posts: 0
Joined: Thu Apr 06, 2017 12:01 pm

True RMS values

Post by jtk »

I am interested in the new 4444 scope.
But I would really like the ability to display a TRMS curve of captured waveforms.

I know you can add a measurement for TRMS, but why can´t you have the program plotting a TRMS graph, or can you?
I should not be too hard to calculate RMS values from the captured waveforms?

Does anyone has a solution for this?

/Thomas

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: True RMS values

Post by Gerry »

Hi jtk,

Yes you can:
RMS Math Channel.png

Code: Select all

sqrt(integral((abs(A))^2)/T)
Regards,

Gerry
Gerry
Technical Specialist

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: True RMS values

Post by Gerry »

When using the above Math channel for RMS, you need to be aware of the following:

You need to have enough cycles of the signal waveform that you're measuring, to allow the Math Channel waveform to converge on a single value.

The pre-trigger has to be set to 0% (so that the yellow trigger diamond is on the far left of the screen) so that Time is always positive, and the calculation works as expected.

Math Channels only work on a complete waveform in the buffer, so zooming will remove the Math Channel from the display as the buffer will not contain the complete waveform anymore.

Regards,

Gerry
Gerry
Technical Specialist

bennog
Advanced User
Advanced User
Posts: 206
Joined: Mon Nov 26, 2012 9:16 am
Location: Netherlands

Re: True RMS values

Post by bennog »

Gerry wrote:Math Channels only work on a complete waveform in the buffer, so zooming will remove the Math Channel from the display as the buffer will not contain the complete waveform anymore.
You can zoom in on the math channels without problem
Is this an option that will removed ? I hope not because I use this future a lot.

Benno

lab!fyi
Newbie
Posts: 0
Joined: Mon Dec 12, 2016 6:58 pm

Re: True RMS values

Post by lab!fyi »

Hi,

additional info was added by Gerry because I spotted some weird stuff and informed support. But something still seemed not right so I did some additional tests. Seems that this specific formula completely breaks some "inner workings". While investigating "building blocks" separately all is ok but not together. Screenshot attached.

Basically non-zoomed and zoomed traces are completely different and depend on zoom level etc. If apply auto-measurements they seem to be taken from wrong trace (and even wrong place?) in both cases.

There is similar issue with filtered traces (LowPass etc). Zoomed window shows trace clipped at ends (while zoom overview shows entire) and auto-measurements do not work at all in both zoomed and non-zoomed cases.
Attachments
PS6__TRMS_math_bugs__revisited.jpg

Martyn
Site Admin
Site Admin
Posts: 4491
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: True RMS values

Post by Martyn »

Measurements work on the full waveform buffer, or cursor based subset of this, working on a specific data set retrieved from the device.

The difficulty with this particular maths channel is that it uses integral, and is display buffer based, but also references this against time, so zooming has an effect. We will play around a bit more next week as it gives useful input to the development team for future enhancements to both maths and measurements.
Martyn
Technical Support Manager

lab!fyi
Newbie
Posts: 0
Joined: Mon Dec 12, 2016 6:58 pm

Re: True RMS values

Post by lab!fyi »

Noticed made some errors myself on last screenshot. In fact theres not a single correct value shown :oops: TRMS for 1000mVpp (500mVp) is 353.6mV. Heres new one using non-triggered trace. Can clearly see that only way to obtain correct number is from settled part of non-zoomed trace using vertical cursor. Weirdnesses pointed out with red arrows. Tace is zoomed in right view to match settled trace from 30 to 40ms.
PS6__TRMS_math_bugs__revisited_again.jpg

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: True RMS values

Post by Gerry »

To answer bennogs comment, and to use this function correctly, you need to observe the additional caveats that I made, along with the correction that Martyn made to the last caveat (i.e. that Measurements apply to the data set currently in the buffer). When I first zoomed in the Math Channel did dissapear, but only temporarily because it was recalculating the trace using the new data in the buffer (re-acquired because of the new zoom level). So the last caveat should read "Math Channels only work on the current waveform data in the buffer, so zooming will create a new Math Channel in the display as the buffer will now contain a subset of the original waveform data".

To answer HrHunts comment, when considering the whole trace the RMS calculation is never 100% correct because the instantaneous average of the squared sample values during the early part of the waveform is much smaller than the eventual average squared sample value that it will converge on. So, the region where that convergence is ramping up needs to be kept as short as possible for a good (but not perfect) representative True RMS trace (which you will notice I originally did by using a large number of cycles). However, if you only consider the latter portion of the RMS Math Channel trace, where it has already settled at the average value, the RMS calculation will be 100% accurate and, if you are making a measurement, you clearly need to make sure that the rulers are only placed in this region, to get the correct measurement.

Bearing all of that in mind, you CAN zoom in and still get the correct measurement done, but only if you are able place the rulers on a portion of the RMS trace where it has already converged/settled on the average value. If you zoom in too far, you will get a different measurement value, which will not be the True RMS value (as seen in your last post, in the zoomed view the curve starts at zero and doesn't even get to 200mV, while in the non-zoomed view, between the rulers, the curve starts and ends at 354mV, so the areas under the curves divided by the time, or the average values are completely different). So, the first caveat applies here, i.e. "You need to have enough cycles of the signal waveform that you're measuring, to allow the Math Channel waveform to converge on a single value".

Also, for some reason I posted an earlier version of the function. Absolute values are not needed if already squaring, so it should just be:

Code: Select all

sqrt(integral((A)^2)/T)
Regards,

Gerry
Gerry
Technical Specialist

lab!fyi
Newbie
Posts: 0
Joined: Mon Dec 12, 2016 6:58 pm

Re: True RMS values

Post by lab!fyi »

Overall cannot accept zoom somehow messing with math. Zoom should be GUI, not data processing feature. This is considerable limitation for large memory models.

But even presuming current situation ok and explanations, I stand by claim that something is still completely broken with initiation of zoomed trace math. Observe attached screenshots. Zoom factor is same in both cases. But only zoom window starting with buffer T_start=0ms shows correct math trace. Zoom window scrolled T_start=5ms does never settle to correct value. At the same time zoom overview displays correct trace in both cases.

Also, in T_start=0ms case settle time is very fast and graph has to do with actual math involved, while in T_start=5ms case math trace has wrong shape in principle.

Correct garph, T_start=0ms
PS6__TRMS__settle_time_zoomed_non_scrolled.jpg
Wrong graph, T_start=5ms
PS6__TRMS__settle_time_zoomed_scrolled.jpg
Note that in T_start=0ms case graph starts seemingly at +infinity, while in T_start=5ms case graph starts at 0. I have pointed out long ago that something seems to be wrong with math trace initialization code + integrals.

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: True RMS values

Post by Gerry »

Hi HrHunt,

You raise a fair point saying that the function will not converge. I've checked and found that there's only very limited zooming that will converge (basically because the divisor needs to be large at the start).

Working on the data for zooming, rather than the GUI, is the only way to go in order for it to be as responsive as it is. The hardware PicoScope only transfers as much data as is needed, to be able to draw the trace to the full resolution of the display. So, initially you get an overview that appears quickly, because only selected data points of the complete buffer need to be sent to the PC in order to represent the complete wave-shape, then when you zoom a smaller section of the waveform data in the hardware buffer, but in a bit more detail is sent to the PC to be displayed, which again reduces the USB traffic and processor overhead required, so that the display can change quickly.

What is needed is a means of being able to refer to the offset between the start of the Y-axis in the zoomed window and Time T=0, to be able to start the calculation at T=some other value. In the functions currently available with Math Channels there is no way to refer to this (there is an absolute offset, but not one relative to the zoom position).

So, unfortunately, it looks like there is no practical way to get the function to converge (the only way would be to apply a fixed time offset to A to get it to start at zero, i.e. typing the start time value of the zoom window into an offset of A in the Math Channel, every time you zoom). So, I stand corrected, there is no practical way to get the function to provide an accurate value of True RMS when zoomed in, unless zoomed in near the start.

So the factors to consider when using this function need to be updated as follows:

1/ The pre-trigger should be set to 0%, (with the yellow trigger diamond positioned on the far left of the screen), and be greater than zero, so that Time is always positive, and the waveform is meaningful.

2/ There needs to be enough cycles of the signal waveform, to allow the Math Channel waveform to converge on a single value. If using measurements, only rulers placed on the converged DC portion of the Math Channel will give correct measurement values.

3/ The RMS Math Channel will not converge quickly enough when zooming in, unless you're zooming in near the start (the only way to change the function so that it does converge quickly would be a not very practical, manual correction to the function itself every time zoom is used).

4/ Also, the y-axis scaling of a Math Channel is not automatically proportional to the input channel/channels being used, so you may need to adjust it to match the Input Channel scaling.

Regards,

Gerry
Gerry
Technical Specialist

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: True RMS values

Post by Gerry »

As an update to my last post, you CAN zoom in vertically if you use all of the horizontal axis. This is useful for being able to accurately position a ruler on the converged waveform to verify that it is close enough in value to the automatic measurement of True RMS (as shown in the below screenshot).
RMS zoomed.png
This becomes more relevant when, for instance, using the RMS values of voltage and current to calculate Apparent Power as 'RMS current x RMS voltage' (as shown in the data file below).
RMS V A & Apparant Power.psdata
(1.92 MiB) Downloaded 770 times
The Apparant Power is given by Vrms x Irms which looking at the measurements is:
1.386 x 7.256 = 10.06 (or 10.07 depending on the 4th decimal places) and close enough to the automatically measured DC average value, and manually measured converged value.

Regards,

Gerry
Attachments
Real & Apparant power.psdata
(2.15 MiB) Downloaded 757 times
Gerry
Technical Specialist

lab!fyi
Newbie
Posts: 0
Joined: Mon Dec 12, 2016 6:58 pm

Re: True RMS values

Post by lab!fyi »

Little lifehack to make auto-measurements work on TRMS trace:

Code: Select all

sqrt(integral(A*A)/T) + freq(A) - freq(A)
This will gate function to area where freq is known. This has following benefits:
- whole trace measurements more accurate since "wild ride" in beginning is excluded
- gated measurements start to work, for example Min/Max are now accurate (look cursors), while with original formula they can be considered non functional (PS 6.13.6.3775)
Attachments
PS6_TRMS2.psdata
(18.35 KiB) Downloaded 725 times
PS6_TRMS2.jpg

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: True RMS values

Post by Gerry »

Hi HrHunt,

Sorry I missed this post.

Nicely done. didn't think of using the shortcomings of fixed segment calculations.
Gerry
Technical Specialist

eemarty
Newbie
Posts: 0
Joined: Wed Nov 02, 2022 8:56 pm

Re: True RMS values

Post by eemarty »

This is an old thread but I was searching for how to plot a running RMS value of a probe and this was a the best option that came up. I found that using the low pass filter function in place of the integral allowed me to calculate a rolling RMS math channel without some of the drawbacks mentioned above.

Code: Select all

sqrt(LowPass(A*A,15))
You need to choose a reasonable value for the low pass frequency. In this case, my input signal is at 60Hz so I chose 15Hz to capture about 4 cycles in the average.

This waveform is the inrush current (measured through a half ohm shunt) for a small residential fridge compressor. It starts high and drops over the course of a few seconds. This function shows how the RMS current changes with time. You can also see that the values correlate well with the "AC RMS" measurements at the ruler points. I hope this is helpful to others.
Attachments
Capturepico.PNG

Gerry
PICO STAFF
PICO STAFF
Posts: 1145
Joined: Mon Aug 11, 2014 11:14 am

Re: True RMS values

Post by Gerry »

Hi eemarty,

This is a very late response to your post (better late than never). I won't waste time explaining why there hasn't been much activity on my part.

Thanks for the update. That's a very neat solution to the caveats that need to be applied when using the integral() function, as you mentioned. It works well with single values such as voltage and current.

Unfortunately, it can't be applied to complex calculations such as power calculations, because you can't multiply 2 filters together in PicoScope 6 or PicoScope 7 (which may have something to do with the fact that, data is decimated by the filter).

Regards,

Gerry
Gerry
Technical Specialist

Post Reply