True RMS values
True RMS values
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
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
Re: True RMS values
Hi jtk,
Yes you can:
Regards,
Gerry
Yes you can:
Code: Select all
sqrt(integral((abs(A))^2)/T)
Gerry
Gerry
Technical Specialist
Technical Specialist
Re: True RMS values
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 pretrigger 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
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 pretrigger 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
Technical Specialist
Re: True RMS values
You can zoom in on the math channels without problemGerry 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.
Is this an option that will removed ? I hope not because I use this future a lot.
Benno
Re: True RMS values
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 nonzoomed and zoomed traces are completely different and depend on zoom level etc. If apply automeasurements 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 automeasurements do not work at all in both zoomed and nonzoomed cases.
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 nonzoomed and zoomed traces are completely different and depend on zoom level etc. If apply automeasurements 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 automeasurements do not work at all in both zoomed and nonzoomed cases.
Re: True RMS values
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.
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
Technical Support Manager
Re: True RMS values
Noticed made some errors myself on last screenshot. In fact theres not a single correct value shown TRMS for 1000mVpp (500mVp) is 353.6mV. Heres new one using nontriggered trace. Can clearly see that only way to obtain correct number is from settled part of nonzoomed trace using vertical cursor. Weirdnesses pointed out with red arrows. Tace is zoomed in right view to match settled trace from 30 to 40ms.
Re: True RMS values
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 (reacquired 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 nonzoomed 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:
Regards,
Gerry
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 nonzoomed 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)
Gerry
Gerry
Technical Specialist
Technical Specialist
Re: True RMS values
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 Wrong graph, T_start=5ms 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.
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 Wrong graph, T_start=5ms 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.
Re: True RMS values
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 waveshape, 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 Yaxis 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 pretrigger 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 yaxis 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
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 waveshape, 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 Yaxis 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 pretrigger 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 yaxis 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
Technical Specialist
Re: True RMS values
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).
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).
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
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).
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 228 times
Gerry
Technical Specialist
Technical Specialist
Re: True RMS values
Little lifehack to make automeasurements work on TRMS trace:
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)
Code: Select all
sqrt(integral(A*A)/T) + freq(A)  freq(A)
 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 211 times
Re: True RMS values
Hi HrHunt,
Sorry I missed this post.
Nicely done. didn't think of using the shortcomings of fixed segment calculations.
Sorry I missed this post.
Nicely done. didn't think of using the shortcomings of fixed segment calculations.
Gerry
Technical Specialist
Technical Specialist