[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    Re: Peaks when increasing the FFT lenght ofdm example
From:       pv () koalatech ! pt
Date:       2021-12-21 15:08:00
Message-ID: 20211221150800.Horde.ESHbTq0qfDqj26bzW8I5ltq () b64 ! wv ! pt
[Download RAW message or body]

This message is in MIME format.


Hi Johannes,

First of all thanks for the quick response and time with my problem.

I've made a text file with all specifications of my OFDM example that  
can be found in the attachments of this mail.

Thanks again with your help and anything more just let me know.

Best regards,
Pedro Viegas






Citando Johannes Demel <demel@ant.uni-bremen.de>:

> Hi Pedro,
>
> we'd need more info to tell why you observe these peaks. How large  
> are your input packets? Do they span multiple OFDM symbols? How many  
> subcarriers are active?
>
> Your peaks hint at some kind of repetition or lot's of zeros.
>
> Cheers
> Johannes
>
>
> On 14.12.21 13:07, Pedro Viegas wrote:
>> Hi everyone,
>>
>> I'm having a problem when I increase the number of carriers from 64  
>> to 512 in the gnuradio OFDM example. When the number of carriers is  
>> 512, the complex envelope of the signal in the time domain has some  
>> peaks, which I can not have for the test I'm trying to make. Can  
>> anyone tell why there are those peaks and how I get rid of them?
>> A possible cause for the peaks, in my opinion, can be the fixed  
>> frame len of the header, that is filled with zeros when the FFT  
>> size increases, resulting in a peak in the beginning of each frame  
>> because of the ifft block. If this is the problem, how can I change  
>> that frame len?
>> To better show what I'm saying, there is an image on the  
>> attachments of the complex envelope with the peaks.
>>
>> Thanks in advance,
>> Pedro Viegas


-- 
Pedro Viegas
DSP Engineer
Koala Tech
phone: +351 917 354 070
e-mail: pv@koalatech.pt


["512 carriers GRC" (application/octet-stream)]

[prev in list] [next in list] [prev in thread] [next in thread]