# Difference between revisions of "Discrete Filter"

(4 intermediate revisions by one user not shown) | |||

Line 6: | Line 6: | ||

<table> | <table> | ||

− | < | + | <div style="text-indent:12"> |

− | Discrete | + | <br> |

− | + | Discrete Transfer Function: <br> | |

− | + | A.z + B<br> | |

− | + | -------<br> | |

− | + | D.z + C<br> | |

− | + | where A, B, C, D are real numbers.<br> | |

− | where A, B, C, D are real numbers | + | <br> |

− | + | Or, alternatively<br> | |

− | The output of the function is defined as | + | <br> |

− | + | Discrete Filter:<br> | |

− | + | A + B.z<sup>-1</sup><br> | |

− | + | ----------<br> | |

− | Where | + | D + C.z<sup>-1</sup><br> |

− | + | The output of the function is defined as <br> | |

− | In. | + | Oz<sup>0</sup> = A/D*In.z<sup>0</sup> + B/D*In.z<sup>-1</sup> - C/D*Out.z<sup>-1</sup><br> |

− | In.z-1: previous input | + | Where <br> |

− | </ | + | In.z<sup>0</sup> : current input<br> |

+ | In.z<sup>-1</sup>: previous input<br> | ||

+ | <br>NOTE: these 2 specifications are equivalent, one form is used by control engineers and the other is used by filter designers. <br> | ||

+ | The output function definition is the same regardless.<br> | ||

+ | </div> | ||

</table> | </table> | ||

− | |||

==Approach== | ==Approach== | ||

To represent this in TTM it is necessary to state the semantics in terms of a function of current cycle input values and a previous cycle computed state variable (or multiple previous cycle state variables, in the case of z-equations of orders greater than 1). This requires the equation to be in a form similar to the expressions used to perform such a filter computation, computing the primary output and also computing a state variable output that you would also reference as an input (from the previous cycle's output computation). | To represent this in TTM it is necessary to state the semantics in terms of a function of current cycle input values and a previous cycle computed state variable (or multiple previous cycle state variables, in the case of z-equations of orders greater than 1). This requires the equation to be in a form similar to the expressions used to perform such a filter computation, computing the primary output and also computing a state variable output that you would also reference as an input (from the previous cycle's output computation). | ||

Line 51: | Line 54: | ||

:"Block X shall compute the signal Y passing the raw signal through a debounce with persistence time of 0.5 seconds" | :"Block X shall compute the signal Y passing the raw signal through a debounce with persistence time of 0.5 seconds" | ||

− | A user could define the constants A, B, C, and D with proper values for | + | A user could define the constants A, B, C, and D with proper values for their specific requirement. |

## Latest revision as of 15:28, 20 February 2007

TTM is a generic modeling tool, and although it is not really meant for any specific application domain such as control/filter expressions that are more naturally specified in a tool such as Simulink, the concept of FUNCTIONS, now supported in TTM 3.x and higher, make it possible to represent things like Discrete Filters. This should allow users to create libraries of TTM models (to be included via the model-includes mechanism).

## Contents |

## Example Function

For a general first order filter specified as follows:

Discrete Transfer Function:

A.z + B

-------

D.z + C

where A, B, C, D are real numbers.

Or, alternatively

Discrete Filter:

A + B.z^{-1}

----------

D + C.z^{-1}

The output of the function is defined as

Oz^{0}= A/D*In.z^{0}+ B/D*In.z^{-1}- C/D*Out.z^{-1}

Where

In.z^{0}: current input

In.z^{-1}: previous input

NOTE: these 2 specifications are equivalent, one form is used by control engineers and the other is used by filter designers.

The output function definition is the same regardless.

## Approach

To represent this in TTM it is necessary to state the semantics in terms of a function of current cycle input values and a previous cycle computed state variable (or multiple previous cycle state variables, in the case of z-equations of orders greater than 1). This requires the equation to be in a form similar to the expressions used to perform such a filter computation, computing the primary output and also computing a state variable output that you would also reference as an input (from the previous cycle's output computation).

## Model

The "firstOrderFilter" function is defined generically in terms of filter coefficients A, B, C, and D and values for the previous input and previous output, as shown in the image below. This Function can be referenced by the output table called Discrete_Filter.

### First Order Filter Function

### Discrete Filter Condition Table

The coefficients are modeled as TTM constants. The state variables representing previous input and previous output are modeled as "inputs" to the model. The model for the output "Discrete_Filter" is specified in terms of these inputs so that they can be considered to be variables that wrap around from the output of one cycle to the input of the next cycle.

### Other Comments

Additional aspects of filter-oriented requirements should probably be added to this model, such as an input representing the current RealTime Clock and the passing of an execution cycle (that is, the passing of a time duration value representing the "sample time" for the filter). But those extra details would make this example more confusing.

### How to Use

If someone wanted to know how it would be possible to model debounce functions for the following example:

- "Block X shall compute the signal Y passing the raw signal through a debounce with persistence time of 0.5 seconds"

A user could define the constants A, B, C, and D with proper values for their specific requirement.