Simulink signal mean without zeros

4 ビュー (過去 30 日間)
Fabian Brüßler
Fabian Brüßler 2021 年 12 月 7 日
編集済み: Andy Bartlett 2021 年 12 月 7 日
Hey guys,
I need some help with a problem in Simulink.
I have a signal that is zero most of the time and sometimes has spikes that are not zero for one timestep. I want to get the mean of those spikes without including the zeros. So basically the mean of the signal when it's not zero.
Any idea how I could achive this?
  1 件のコメント
Mathieu NOE
Mathieu NOE 2021 年 12 月 7 日
hello
you want to have it embedded in the simulink file or you could export the data and post process in matlab script ?

サインインしてコメントする。

回答 (1 件)

Andy Bartlett
Andy Bartlett 2021 年 12 月 7 日
編集済み: Andy Bartlett 2021 年 12 月 7 日
Two key ideas.
  • Use unit delay block to hold calculated values so far
  • Use conditional logic to control when math does or does not happen
First, model a running mean. Accumulated sum of all inputs so far, divided by a count of the number of inputs so far.
Use a unit delay block to hold the accumulated sum so far, and create a feedback loop from that into a sum block where the other input is the current value of the signal you are creating a mean for.
Likewise use a unit delay block to hold the count of the number of inputs so far, feed that back into another sum block where the other input is the constant one (or feedback into Increment Real World block).
Second, once you are happy with that implementation stick it inside an enable (or triggered) subsystem. The signal that controls whether that subsystem is enabled (or triggered) would be the output of the Compare to Zero block. A search of Simulink documentation for enabled and triggered subsystems should produce some instructive examples.
If you don't want to use enabled or triggered subsystems, you could also use switch blocks to control whether the unit delay blocks got a newly computed value or just held their old values.
A key weakness of this approach is that the accumulated values of the running sum and count could eventually get really big. This might lead to overflows. If floating-point is used, there could also be precision issues because the round off error of half an eps will get bigger as the value gets bigger. For example, suppose the count was kept in an single precision floating point data type. If the count ever reached as high as flintmax('single') = 16777216 which as an eps value of 2, then attempted increments of the count would round back to the original value and the count would be stuck at 16777216 forever. You may need to think about how big the values used in the running mean can get, and you may want to think about having a mechanism to reset the running mean back to zero.
>> priorValue = flintmax('single')
priorValue =
single
16777216
>> nextValue = priorValue + 1
nextValue =
single
16777216
>> nextValue = priorValue + 1
nextValue =
single
16777216

製品


リリース

R2021b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by