AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

Hello,
I=B4m doing a timedomain convolution using the DSP_fir_r8 function from
DSP_LIB. I=B4m using different blocklegth NR and filterlength NH.
For errorchecking I use coefficients where h0 =3D 32767 and the rest
zeros, so I=B4m expectiing to see the delayed input signal on the output.

Now I noticed a strange behavior of the function: if I increase the
filterlength to NH =3D 4096 and the blocksize to NR >=3D 32, I see a short
distortion every block, watching the output signal with a scope.
It seems that always the last sample in a block is wrong.
With NR =3D 24 there are no problems.
There are also other configuration with the same result, like NR>=3D8
with NH =3D 16384, and NR>=3D92 with NH =3D 1024.

Has anybody noticed these things before and is there a solution for this?

Im using the DSK6416 with CCS 3.1.

Bye, jonas

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Tr=
anscoding Solution for Commercial & Consumer End Equipment:
www.ti.com/dm64=
67

=20

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Jonas-

> I´m doing a timedomain convolution using the DSP_fir_r8 function from
> DSP_LIB. I´m using different blocklegth NR and filterlength NH.
> For errorchecking I use coefficients where h0 = 32767 and the rest
> zeros, so I´m expectiing to see the delayed input signal on the output.
>
> Now I noticed a strange behavior of the function: if I increase the
> filterlength to NH = 4096 and the blocksize to NR >= 32, I see a short
> distortion every block, watching the output signal with a scope.
> It seems that always the last sample in a block is wrong.
> With NR = 24 there are no problems.
> There are also other configuration with the same result, like NR>=8
> with NH = 16384, and NR>=92 with NH = 1024.
>
> Has anybody noticed these things before and is there a solution for this?
>
> Im using the DSK6416 with CCS 3.1.

First I would ask how you can have block length less than filter length?  Does
DSP_fir_r8() documentation explicitly
say it supports this?  If that's really true, then the DSP_fir_r8() function
would be fairly complex in order to keep
track of where it is in the filter tap sequence in between calls to it.  The
typical FIR filter function is not this
complex and assumes the entire filter is applied during each call.  This
requires only keeping track of enough of NR
length data to account for coefficient overlap between blocks -- which implies
that NR > NH.

Second assuming you are doing everything correctly and still see a
"distortion" every block, a couple of guesses might
be:

  -you are somehow not feeding the next NR
   block with data exactly one sample after
   the previous block

  -static array space used by DSP_fir_r8() to
   maintain "memory" of the previous block is
   somehow not static or being overwritten or
   corrupted in between calls to DSP_fir_r8()

-Jeff

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment:
www.ti.com/dm6467

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Jonas-

>> > I´m doing a timedomain convolution using the DSP_fir_r8 function
from
>> > DSP_LIB. I´m using different blocklegth NR and filterlength NH.
>> > For errorchecking I use coefficients where h0 = 32767 and the
rest
>> > zeros, so I´m expectiing to see the delayed input signal on the
> output.
>> >
>> > Now I noticed a strange behavior of the function: if I increase
the
>> > filterlength to NH = 4096 and the blocksize to NR >= 32, I see
a short
>> > distortion every block, watching the output signal with a scope.
>> > It seems that always the last sample in a block is wrong.
>> > With NR = 24 there are no problems.
>> > There are also other configuration with the same result, like
NR>=8
>> > with NH = 16384, and NR>=92 with NH = 1024.
>> >
>> > Has anybody noticed these things before and is there a solution
> for this?
>> >
>> > Im using the DSK6416 with CCS 3.1.
>>
>> First I would ask how you can have block length less than filter
> length?  Does DSP_fir_r8() documentation explicitly
>> say it supports this?  If that's really true, then the DSP_fir_r8()
> function would be fairly complex in order to keep
>> track of where it is in the filter tap sequence in between calls to
> it.  The typical FIR filter function is not this
>> complex and assumes the entire filter is applied during each call.
> This requires only keeping track of enough of NR
>> length data to account for coefficient overlap between blocks --
> which implies that NR > NH.
>>
>> Second assuming you are doing everything correctly and still see a
> "distortion" every block, a couple of guesses might
>> be:
>>
>>   -you are somehow not feeding the next NR
>>    block with data exactly one sample after
>>    the previous block
>>
>>   -static array space used by DSP_fir_r8() to
>>    maintain "memory" of the previous block is
>>    somehow not static or being overwritten or
>>    corrupted in between calls to DSP_fir_r8()
>>
>> -Jeff
>> Ok, thank you.
> Yes, it was my fault, I used the wrong buffers, sorry.

I'm glad to hear you got it working.  It would be good if you give the specific
problem and fix that you found for
other group members implementing FIR filters.

-Jeff

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment:
www.ti.com/dm6467

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )