Higher order transfer function precision issue

Hi,

I'm creating a transfer function at higher order (to the degree of 80) by multiplication of many 2nd order transfer function. However, when I get this final transfer function, the result returned is NaN.

I suspect it is due to the precision error in MATLAB, and tried to use vpa commend. It didn't solve the problem by giving errors.

Could anyone advise me a solution please? thank you.

Steven

num_bnotch=vpa([1 4*0.20*pi*19.5 (2*pi*20.04)^2]); den_bnotch=vpa([1 4900.88 1.5855e+004]); bnotch=tf(num_bnotch,den_bnotch)

??? Error using ==> tf.tf at 251 The values of the "num" and "den" properties must be row vectors or cell arrays of row vectors, where each vector is nonempty and containing numeric data. Type "ltiprops tf" for more information.

[Landon Beutler]

I had the same issue with high order numeric transfer functions, but got around it by transforming models to space state form, combining them, and then converting the combined model back to a transfer function.

sys_combined = tf(ss(sys_1)*ss(sys_2))

[Paul]

Hi Landon,

Converting from state space to transfer function isn't the right way to go (maybe there's an exception I'm not aware of?). Of the various model representations in the Control System Toolbox, the tf is probably the worst to deal with from a computational perspective, particuarly for high order models. Check out Using the Right Model Representation.

Answer 1

[Walter Roberson]

vpa() does not return numeric values: it returns symbolic numbers. tf() is complaining because you are passing it symbolic values.

You might be out of luck with trying to get a symbolic transfer function; see http://www.mathworks.com/matlabcentral/answers/48958-how-can-i-get-symbolic-transfer-function-from-block-diagram

[Steven]

Thanks for the answer. In this case, vpa seems not a good solution to my issue. Basically, I'm creating multiplying many transfer function using Matlab script. The result I get is NaN, which I guess due to precision problem. Do you have any idea to get around this please?

[Walter Roberson]

NaN would not usually be directly due to a precision problem. You could, though, somehow end up getting 0 divided by 0 through underflow of both the numerator and denominator.

If you are multiplying transfer functions, perhaps you could instead add their logs ?

[Steven]

Thank you, Walter.