Simulink signal mean without zeros

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?

[Mathieu NOE]

hello

you want to have it embedded in the simulink file or you could export the data and post process in matlab script ?

Answer 1

[Andy Bartlett]

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