wrong Performance after subtract

[operator110]

Example Code:

<phyphox version="1.11" locale="en">
  <data-containers>
    <container size="450">accZmsWithG</container>
    <container size="450">accZms</container>
    <container size="450">accZ</container>
    <container size="450">accT</container>
  </data-containers>

    <input>
    <sensor type="accelerometer" rate="450">
      <output component="z">accZmsWithG</output>
      <output component="t">accT</output>
    </sensor>
  </input>

  <analysis sleep="0"  onUserInput="false">
        <subtract>
            <input as="minuend">accZmsWithG</input>
            <input as="subtrahend" type="value">9.81</input>
            <output as="difference">accZms</output>
        </subtract>
        <multiply>
            <input as="factor" clear="false">accZms</input>
            <input as="factor" type="value">0.101971621297793</input>
            <output as="product">accZ</output>
        </multiply>
    </analysis>

  <views>
    <view label="Graph">
      <graph label="Accelerometer z" aspectRatio="2.5" style="lines" lineWidth="1" color="yellow" partialUpdate="true" history="1" labelX="t" labelY="a" labelZ="" unitX="s" 
      unitY="m/s²" unitZ="" logX="false" logY="false" logZ="false" xPrecision="3" yPrecision="3" zPrecision="3" scaleMinX="auto" scaleMaxX="auto" scaleMinY="auto" scaleMaxY="auto" 
      scaleMinZ="auto" scaleMaxZ="auto" minX="0" maxX="0" minY="0" maxY="0" minZ="0" maxZ="0"  mapWidth="0"       >
        <input axis="x">accT</input>
        <input axis="y">accZ</input>
      </graph>
    </view>
  </views>
</phyphox>

If the subtraction block is used, the performance is drastically reduced.

[Staacks]

What do you mean with "performance"? The reaction time of the app?

There are a few things I would note about that configuration, although they are probably unrelated:

• Setting the rate to 450 Hz might not exactly do what you expect. This limits the data rate to a period 2.2222ms (1/450Hz) and depending on the actual timing of sensor events, the resulting frequency might be close to 450 Hz, a bit less (even if the sensor is faster) or significantly less (if the sensor is slower). Just wanted to point this out, because this number is so specific and so high that it seems important to you.
• You are deleting your measured accelerometer data all the time. If I am not mistaken, each of the accZ buffers is deleted in each loop of analysis. accZmsWithG is cleared after each execution of subtract, accZms is cleared by the result of subtract and this again replaces the content of accZ after multiply. You might want to add another clear=false to accZmsWithG to recalculate the entire data set each time. This is the "simple" solution, but will eventually give performance issues as more and more data points need to be recalculated each time. Alternatively, if you do not need the raw data, you could add a clear="false" to the output of multiply to aggregate the calculated data there (that is until the 450 value buffers are filled, but the analysis sequence will run much more often than once per second).

At the moment, you would only see a few most recent data points in accZ with shifting 450 data points in accT. Depending on the maximum supported rate of the sensor and the performance of your phone, you will see a few points at the left edge of the graph with a large empty space to the right (because of the many values in accT only matching the first few values in accZ).

Is this what you are seeing?

[operator110]

Your description of the graph is absolutely correct. Perhaps there is also a problem of understanding on my part. The smartphone used can generate data at a frequency of 500 Hz. If only the multiplication is carried out in the analysis block, there are still many values (450 hz)for the acceleration. If, however, the subtraction block is also used, these are reduced so drastically (2 Hz) that the attribution of the phenomenon to the smartphone performance seems abstruse to me.

[Staacks]

If, however, the subtraction block is also used, these are reduced so drastically (2 Hz) that the attribution of the phenomenon to the smartphone performance seems abstruse to me.

Nope, that's not what I wanted to attribute to the phone's performance. Actually, in my opinion there is no performance issue here (if I understand what you are confused about).

The entire analysis sequence is executed about 50 times per second. If you only have the subtract block (and I assume that you then directly feed the data from the sensor to its input), the data-container (sorry, sometimes I call them "buffer") at the input is never cleared and will always be filled with its maximum capacity of 450 values.

If you add the subtract the way you posted it here, the data at its input is deleted after each use and its output also deletes the data of the container attached to the multiply-input. So, you only get the few values that have been recorded between the last iteration of the analysis sequence and the current iteration. If you collect data at about 450 Hz and the analysis sequence runs at about 50 Hz (not sure about the exact value right now and this in fact depends on the performance, too), you get around 9 new data points and those will be the only ones you see.

Add clear="false" to the input of subtract. I think this should fix the problem :)

[Staacks]

Since there has been no response in a while, I will close the issue. Feel free to comment and reopen if it still persists.