Re: [Discuss-gnuradio] Problem with output of inverse FFT

[Hans-Christian]

Hello @ all,

after reading Megabytes of Hex Code i found an error in another file...
everything with the ifft works fine.

I found an error in the ftw_ofdm_pilot_cc.cc file, line 82.

"offset" and "i" are defined outside of all defined functions.
if the block is deleted and created again to modulate another OFDM frame,
the wrong pilot tones are insert to this frame.

After defining "offset" and "i" in the header file (private class elements),
the second frame has the same pilot tones.

maybe it is possibel to change this in the SVN repository.

Hans


Hans-Christian wrote:
> 
> Hi @all,
> 
> on my long way to send multiple  802.11g frames i found another problem…
> 
> During the process the data is converted from frequency domain to time
> domain by inverse fft.  
> The fft length is 64, and the input is the OFDM symbol with carrier tones
> (vector of 64 * gr_complex) 
> The frame consists of 3 ofdm symbols and i want to convert two identical
> frames.
> So there are 6 elements with a size of  64* gr_complex.  (6*64 *8Byte =
> 3072 Byte)
> 
> When I compare the result of the first frame (Bytes 0 – 0x5FF) with the
> result of the second frame (0x600 – 0xBFF) in a hex editor the frames are
> NOT the same. 
> 
> They differ from each other, starting at Byte 0x800 to 0x200 in the fist
> frame. (0x800 = 2048dec!?)
> 
> I’m able to reproduce the problem in GRC, using a file source
> –>throttle->inverse fft(size 64) -> file sink  flowgraph., my input file
> is attached.
> 
> Is there a problem with the precession of the ifft? (gnuradio 3.2.2,
> ubuntu 10.04)
> 
> Has anybody an idea how to fix this?
> 
>  http://old.nabble.com/file/p31056403/input.dat input.dat  
> http://old.nabble.com/file/p31056403/output.dat output.dat 
> 
> -Hans
> 

-- 
View this message in context: 
http://old.nabble.com/Problem-with-output-of-inverse-FFT-tp31056403p31276933.html
Sent from the GnuRadio mailing list archive at Nabble.com.