Re: [Discuss-gnuradio] question about gr_ofdm_sampler.cc

[Tom Rondeau]

On Wed, Feb 10, 2010 at 8:46 PM, bin zan <address@hidden> wrote:
> Hi Tom,
>       Please help me to understand another question. Are the data stream
> goes into FFT process the original data stream or they have been modified
> somehow? If they are modified, how to make original data stream enter into
> the FFT process with the sync information on hand.
>
> Thanks,
> Bin

I'm not sure what you mean by "modified." They have been adjusted by
the sync block to fit in the middle of the FFT bins and the CP has
been removed. Other than that, it's just the data stream.

Tom


> On Wed, Feb 10, 2010 at 10:18 PM, bin zan <address@hidden> wrote:
>>
>> Hi Tom,
>> Thanks a lot for all your information.
>> Can I say that the predefined preambles are used both for symbol sync and
>> then later correlation, and the CP is only used for symbol sync?
>> One preamble is inserted at transmitter every full packet?
>>
>> Thanks,
>> Bin
>>
>> On Wed, Feb 10, 2010 at 5:45 PM, Tom Rondeau <address@hidden>
>> wrote:
>>>
>>> On Wed, Feb 10, 2010 at 11:40 AM, bin zan <address@hidden> wrote:
>>> > Hi Tom,
>>> >           Can you help me answer the following questions?
>>> >           1. Does that mean, the data has not be divided into sync'd
>>> > segments until ofdm_sampler.cc?
>>>
>>> I'm not sure what "that" is you are talking about (please reply inline
>>> and don't top post when responding), but I think I get what you are
>>> asking. Yes, the sampler separates the stream into vectors that are
>>> fft_length in size.
>>>
>>> >           2. Why d_timeout_max=1000? Pre-defined preambles only  appear
>>> > every 1000 FFT length of data?
>>>
>>> 1000 was just an arbitrary number. We wanted to make sure that it
>>> would stop sampling after a while if no new packets are seen. It just
>>> has to be long enough to make sure the timeout/reset doesn't happen
>>> during the reception of one full packet.
>>>
>>>
>>> >           3. Only data after state_frame will go through FFT process,
>>> > others
>>> > will be dropped (including CP)?
>>>
>>> Yes, the sampler removes the CP. It's purpose is served so it is no
>>> longer necessary.
>>>
>>>
>>> >           4. According to your powerpoint OFDM implementation in GNU
>>> > radio,
>>> > FFT happens before preamble correlation, which file actually do the
>>> > preamble
>>> > correlation?
>>>
>>> This correlation is done in the ofdm_frame_acq (part of
>>> ofdm_receiver). We use the preamble in the frequency domain to figure
>>> out the subcarrier offset (how many bins away from DC the signal is)
>>> and then create the equalizer from it. The output of this block is
>>> just the occupied tones post equalizer.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>> > On Wed, Feb 10, 2010 at 12:36 PM, Tom Rondeau <address@hidden>
>>> > wrote:
>>> >>
>>> >> On Wed, Feb 10, 2010 at 8:10 AM, bin zan <address@hidden> wrote:
>>> >> > Hi,
>>> >> >       I just wonder why in gr_ofdm_sampler.cc, the  consume_each for
>>> >> > STATE_NO_SIG and STATE_PREAMBLE are different.
>>> >> > consume_each(index - d_fft_length + 1);
>>> >> > consume_each(index-d_fft_length);
>>> >> >
>>> >> > Both suppose to  leave one  fft length, right?
>>> >> > Can any one explain it?
>>> >> >
>>> >> > Thanks,
>>> >> > Bi
>>> >>
>>> >> It's just like the comments say, in STATE_NO_SIG, we consume 1 less
>>> >> because we need to leave behind a full fft_length of items to test for
>>> >> the preamble. When we have the preamble in STATE_PREAMBLE, we consume
>>> >> everything including that one so that the next input block is the
>>> >> start of the packets.
>>> >>
>>> >> FYI: Matt and I are working on the OFDM stuff this week. We're seeing
>>> >> some issues that we need to work out, so things we thought were right
>>> >> could be wrong and will hopefully be fixed.
>>> >>
>>> >> Tom
>>
>
>