This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

iircas5 coefficients, yet another discussion

I've been struggling to get my coefficients correct using IIRCAS5/dsplib on the C5535. As with everyone else, I'm dealing with the issue of an a1 coefficient in the range +/-2 rather than a range of +/-1.


Here's an example:

ans =
    0.0875    0.1514    0.0875    1.0000   -1.0871    0.4190
    0.6841    0.2179    0.6841    1.0000   -0.3044    0.9220
    0.3761    0.2815    0.3761    1.0000   -0.5902    0.7092

This is the floating point representation of a 6th order LPF in second order sections. The matlab representation of the LPF looks like this:

Nice and clean.

Now, a number of documents I have read simply suggest converting to Q2.14, which is achieved (I think, maybe I'm crazy here) with a simple multiplication of my coefficients by 2^14 and rounding.

This produces a new SOS representation of:

ans =
        1434        2481        1434       16384      -17812        6864
       11209        3569       11209       16384       -4987       15106
        6163        4613        6163       16384       -9669       11619


Which, when evaluated, produces the same transfer function.Unfortunately, iircas5 chooses a value of 1, not 0.5 for a0, which means that my poles are different than this. To test, one can multiply column 4 by 2, to get:

ans =
        1434        2481        1434       32768      -17812        6864
       11209        3569       11209       32768       -4987       15106
        6163        4613        6163       32768       -9669       11619

This, when evaluated produces a transfer function like this:

Which perfectly matches what I see on my DSP, when I order my coefficients for the iircas5 and run it on a network analyzer.

So can anyone explain to me what the heck I'm missing here? It seems like half the people who start these threads wander off and never explain what clarified their confusion. I've looked at a number of other threads and discussions (including the one with the German PDF which didn't really clarify too much for me, unfortunately).

Thanks a ton, any kind soul who takes a moment to answer this!

  • Hi,

    We are working on this and will provide us our suggestions on the same.

    Thanks & regards,

    Sivaraj K

  • Sivaraj,

    Thanks. I look forward to hearing back. I will be sure to post my final conclusions here once it is resolved for the benefit of others.

  • William,

     

    I try to understand the problem.  Here is my guess, tell me what you think

    Q14 arithmetic in 16 bit machine implies that the largest positive number is 0111 1111 1111 1111 which is 2 – 2**(-14)  and the most negative number is 1000 0000 0000 0000 = -2

    In that case, 1 is represented by 0100 0000 0000 0000 =  16384    (and not 32768)

     

    Do you agree with me?

     

     

    Ran

  • Agreed. It seems however, that scaling all coefficients (or all feedback coefficients) as Q14 produces an incorrect result.

  • Are you sure?

     

    From your posting I understand that if you use the coefficients

     

    ans =
            1434        2481        1434       16384      -17812        6864
           11209        3569       11209       16384       -4987       15106
            6163        4613        6163       16384       -9669       11619

    and 16384 is 1 (which iircas5 assumes), then the transfer function is correct

     

    Ran

  • Ran,

         That is exactly the problem, those coefficients produce the incorrect results, but instead produces a response that matches the transfer function for the following coefficients:

    ans =
            1434        2481        1434       32768      -17812        6864
           11209        3569       11209       32768       -4987       15106
            6163        4613        6163       32768       -9669       11619

    -Bill

  • OK, so your theory is that either the source code for the IIR filter is not correct or we do not know how to use it

    I need to think what the next step is

     

    I assume that if you take the fixed point coefficient, convert them to real value and run a simple C IIR filter routine you get the correct results

  • Hello,

    I am running into a similar problem using the iircas5 function. Did you find a solution to this problem?

    Thank you,

    Pedro

  • Edit iircas5.asm.  On line 139 or there abouts you'll find a constant called 'SCALE'.  Set it to '1'.  You should now be able to use Q14 parameters.  Note all your filters will have to be this way; if you want different scaling you'll have to reimplement the function to take SCALE as an input or copy the code into another file.

    Regards,

    Bill

  • Bill Finger said:
    Edit iircas5.asm. On line 139 or there abouts you'll find a constant called 'SCALE'. Set it to '1'.

    What version of dsplib are you looking at? In version 3.00.00.03 which I think is the latest, iircas5.asm does indeed have a SCALE parameter on line 182, but it appears to be completely unused by the code.

  • This would be version 2.40; sorry I don't update very often once I've worked out the bugs.

    Anyway on line 201 I have:

    MOV #SCALE, T2                   ;scale factor

    and then 219-220 I have:

    MPYM *AR1+, T3, AC0                       ; AC0 = b2*d(n-2) (3)
     ::MOV HI(AC0 << T2), *AR3              ; d(n) replaces d(n-2)

    So you see, the scale factor is used to shift the delay before storing it.