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.

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.

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 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.

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:

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.

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.

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.