Sign in

username:

password:



Not a member?

Search c6x



Search tips

Subscribe to c6x



c6x by Keywords

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

Sponsor

NEW! TMS320C6474: 3x the performance. 1/3 the cost. Three 1 GHz cores on 1 chip.

Discussion Groups

Discussion Groups | TMS320C6x | Problems with DSP_fir_r8

Technical discussions about the TI C6000 DSPs (including the c62x, c64x and c67x DSPs).

  

Post a new Thread

Problems with DSP_fir_r8 - "jonas.hoeppner" - Mar 1 19:06:47 2008



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


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

Re: Problems with DSP_fir_r8 - Jeff Brower - Mar 2 1:36:32 2008

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



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

Re: Problems with DSP_fir_r8 - Jeff Brower - Mar 2 15:36:54 2008

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



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