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.

128, 256, 512 point FFT (rfft and rifft ) problem ?

I realize that I could be making some mistakes in my code, or missing something fundamental in map file.

I ve focused on 128-point,256-point  and 512-point real FFT results(using dsplib ffts). I am using  8000 Hz sine wave  for input signal(PCM format) .

i obtain good results for  64-point and  128-point  FFTs,  but  bad results for 256-point and  512-point FFTs . I see echoes at some frequencies.

 

my CODE :

#define

 

NX               FFT_SIZE

 

 

 

 

#pragma

 

 

DATA_SECTION (x,".input")

DATA x[NX];

FILE *fin = au_open2read(

"D:\\FFT\\timeSamples.au");

FILE *fout = au_open2write(

"D:\\FFT\\DSP_FFTInverseSamples[c55].au");

 

 

 

while

(!feof(fin))

{

au_read(x, 2, NX, fin);  // read 16 pcm data in au file

 

 

//fowrard FFT

rfft(x,NX,SCALE);

 

 

 

//inverse FFT 

rifft(x,NX,NOSCALE);

__lShiftSignal(x,2,NX,0);   // multiply 4 for ampitude 

au_write(x,2, NX, fout);   // write 16 pcm data in au file

 

}

printf(

"FINISHED ...\n");

 

 

 

---------- sub function----------

void

 

 

 

     int i;

 

 

     if (isLong)

    {

 

 

              long * p = (long*)s;

 

 

              for (i=0; i<len; i++)

                      p[i] <<= shift ;

    }

 

else

   {

 

 

             int * p = (int*)s;

 

 

             for (i=0; i<len; i++)

 __lShiftSignal (void * s, int shift, int len,int isLong)

{

 

                       p[i] <<= shift ;

    }

}

-----------------------------------------------------------------------------

 My MAP FILE :

 

MEMORY

{

PAGE 0: /* ---- Unified Program/Data Address Space ---- */

 

MMR (RWIX): origin = 0x000000, length = 0x0000c0 /* MMRs */

SPRAM : origin = 00000c0h, length = 0000040

DARAM0 (RWIX): origin = 0x000100, length = 0x00ff00 /* 64KB - MMRs - SPRAM */

SARAM0 (RWIX): origin = 0x010000, length = 0x010000 /* 64KB */

SARAM1 (RWIX): origin = 0x020000, length = 0x020000 /* 128KB */

SARAM2 (RWIX): origin = 0x040000, length = 0x00FE00 /* 64KB */

VECS (WRIX): origin = 0x04FE00, length = 0x000200 /* 512B */

PDROM (RIX): origin = 0xff8000, length = 0x008000 /* 32KB */

 

PAGE 2: /* -------- 64K-word I/O Address Space -------- */ 

IOPORT (RWI) : origin = 0x000000, length = 0x020000

}

 

/* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY */

 

SECTIONS

{

.text >> SARAM1|SARAM2 /* Code */

 

/* Both stacks must be on same physical memory page */

.stack > DARAM0 /* Primary system stack */

.sysstack > DARAM0 /* Secondary system stack */

 

.data >> DARAM0|SARAM1 /* Initialized vars */

.bss >> DARAM0|SARAM1 /* Global & static vars */

.const >> DARAM0|SARAM1 /* Constant data */

.sysmem > DARAM0|SARAM1 /* Dynamic memory (malloc) */

.switch > SARAM2 /* Switch statement tables */

.cinit > SARAM2 /* Auto-initialization tables */

.pinit > SARAM2 /* Initialization fn tables */

.cio > SARAM2 /* C I/O buffers */

.args > SARAM2 /* Arguments to main() */

 

vectors > VECS /* Interrupt vectors */

.ioport > IOPORT PAGE 2 /* Global & static ioport vars */

.myheap > SARAM0

 

.fftcode : {} > SARAM1 PAGE 0 /* FFT-specific sections */

.twiddle : {} > SARAM1 PAGE 0, align(2048)

.input : {} > DARAM0 PAGE 0, align(4) /* this is due to long-word data memory access */

}

 

 

  • It's pretty hard to read that partial code, because I don't know if you have cut some important part or not. To be exact - what happens to signal between FFT and IFFT? If really nothing, then that's the reason. When you do rfft() , you use Nx real input samples, but output vector is Nx Complex samples, then only Nx/2 real samples. For rifft() you need real vector, but after previous operation you have only complex vector. You can find more precise information in DSPLIB Reference. I'm not sure why it works for lower Nx, but can't see anything else.
  •  

    Thanks Michal...

    i try this code with different map file. i obtain good results with 256-point and 512-point FFTs ,too .  I do not understand with diffirence between these map files. When i changed map file in my project, i obtained good results.  What is diffirence between these map files ???

    This map File :

    /*********************************************************

     

     

     

    LINKER command file for LEAD3 memory map.

     

     

     

    **********************************************************/

     

    MEMORY

     

    {

     

    PAGE 0:

     

    MMR : origin = 0000000h, length = 00000c0h

     

    SPRAM : origin = 00000c0h, length = 0000040

     

    DARAM0 : origin = 0000100h, length = 000FF00h

     

    SARAM0 : origin = 0010000h, length = 0040000h

     

    CE0 : origin = 0050000h, length = 03b0000h

     

    CE1 : origin = 0400000h, length = 0400000h

     

    CE2 : origin = 0800000h, length = 0400000h

     

    CE3 : origin = 0c00000h, length = 03f8000h

     

    PDROM : origin = 0ff8000h, length = 07f00h

     

    VECS : origin = 0ffff00h, length = 00100h /* reset vector */

     

    }

     

    SECTIONS

     

    {

     

    vectors : {} > VECS PAGE 0 /* interrupt vector table */

     

    .cinit : {} > SARAM0 PAGE 0

     

    .text : {} >> SARAM0 PAGE 0

     

    /* Both stacks must be on same physical memory page */

    .stack > DARAM0 /* Primary system stack */

    .sysstack > DARAM0 /* Secondary system stack */

     

     

    .stack : {} > DARAM0 PAGE 0

     

    .sysstack: {} > DARAM0 PAGE 0

     

    .sysmem : {} > DARAM0 PAGE 0

     

    .data : {} > DARAM0 PAGE 0

     

    .bss : {} > DARAM0 PAGE 0

     

    .const : {} > DARAM0 PAGE 0

     

    .cio : {} > DARAM0 PAGE 0 /* added for debug */

     

     

    files : {} > DARAM0 PAGE 0 /* User-defined sections */

     

    statvar : {} > DARAM0 PAGE 0

     

    statarry : {} > DARAM0 PAGE 0

     

    tempvar : {} > DARAM0 PAGE 0

     

    temparry : {} > DARAM0 PAGE 0

     

     

    .fftcode : {} > SARAM0 PAGE 0 /* FFT-specific sections */

     

    .test : {} > DARAM0 PAGE 0

     

    .twiddle : {} > SARAM0 PAGE 0, align(2048)

     

    .input : {} > SARAM0 PAGE 0, align(4) /* this is due to long-word data memory access */

     

    }

     

  • sorry , i wrote map file wrong...

    This is rigth :

    /*********************************************************

    LINKER command file for LEAD3 memory map.

     

     

     

    **********************************************************/

     

    MEMORY

     

    {

     

    PAGE 0:

     

    MMR : origin = 0000000h, length = 00000c0h

     

    SPRAM : origin = 00000c0h, length = 0000040

     

    DARAM0 : origin = 0000100h, length = 0003F00h

     

    DARAM1 : origin = 0004000h, length = 0004000h

     

    DARAM2 : origin = 0008000h, length = 0004000h

     

    DARAM3 : origin = 000c000h, length = 0004000h

     

     

    SARAM0 : origin = 0010000h, length = 0004000h

     

    SARAM1 : origin = 0014000h, length = 0004000h

     

    SARAM2 : origin = 0018000h, length = 0004000h

     

    SARAM3 : origin = 001c000h, length = 0004000h

     

    SARAM4 : origin = 0020000h, length = 0004000h

     

    SARAM5 : origin = 0024000h, length = 0004000h

     

    SARAM6 : origin = 0028000h, length = 0004000h

     

    SARAM7 : origin = 002c000h, length = 0004000h

     

    SARAM8 : origin = 0030000h, length = 0004000h

     

    SARAM9 : origin = 0034000h, length = 0004000h

     

    SARAM10 : origin = 0038000h, length = 0004000h

     

    SARAM11 : origin = 003c000h, length = 0004000h

     

    SARAM12 : origin = 0040000h, length = 0004000h

     

    SARAM13 : origin = 0044000h, length = 0004000h

     

    SARAM14 : origin = 0048000h, length = 0004000h

     

    SARAM15 : origin = 004c000h, length = 0004000h

     

     

    CE0 : origin = 0050000h, length = 03b0000h

     

    CE1 : origin = 0400000h, length = 0400000h

     

    CE2 : origin = 0800000h, length = 0400000h

     

    CE3 : origin = 0c00000h, length = 03f8000h

     

     

    PDROM : origin = 0ff8000h, length = 07f00h

     

    VECS : origin = 0ffff00h, length = 00100h /* reset vector */

     

    }

     

     

     

     

     

    SECTIONS

     

    {

     

    vectors : {} > VECS PAGE 0 /* interrupt vector table */

     

    .cinit : {} > SARAM0 PAGE 0

     

    .text : {} >> SARAM1 | SARAM2 PAGE 0

     

    .stack : {} > DARAM0 PAGE 0

     

    .sysstack: {} > DARAM0 PAGE 0

     

    .sysmem : {} > DARAM0 | DARAM1 | DARAM2 PAGE 0

     

    .data : {} > DARAM1 PAGE 0

     

    .bss : {} > DARAM0 | DARAM1 | DARAM2 PAGE 0

     

    .const : {} > DARAM0 | DARAM1 | DARAM2 PAGE 0

     

    .cio : {} > DARAM2 PAGE 0 /* added for debug */

     

     

    files : {} > DARAM2 PAGE 0 /* User-defined sections */

     

    statvar : {} > DARAM2 PAGE 0

     

    statarry : {} > DARAM2 PAGE 0

     

    tempvar : {} > DARAM2 PAGE 0

     

    temparry : {} > DARAM2 PAGE 0

     

     

    .fftcode : {} > SARAM2 PAGE 0 /* FFT-specific sections */

     

    .test : {} > DARAM2 PAGE 0

     

    .twiddle : {} > SARAM3 PAGE 0, align(2048)

     

    .input : {} > DARAM3 PAGE 0, align(4) /* this is due to long-word data memory access */

     

    }

  • Do you still have the problem of echoed frequencies in the FFT bins?  I had this problem until I carefully aligned the data buffer according to the FFT requirements.  I'm not sure how the buffer could ever have been misaligned, but perhaps my linker files and C sources did not all match up.  In any event, the final fix was to align the buffer.  If you search this forum, you will find my complete discussion of the aliased frequency issues that I was experiencing, along with source code that reproduces the problem.

  •  

    Thanks Brian,

    Yes i have... But  i have not the problem  when i changed my map file.  Maybe you are right....   If i carefully aligned data buffer according to the FFT requirements, i can fix the problem. Could you write web address that you complete discussion of the aliased frequency issues ?

  • Certainly. I'm not sure how to link to other threads in the forum, but I will try...

    aliased bins in rfft() results?

  • Thanks

    I will focus on your topic...