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

[bin zan]

Hi Tom,
>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.
Here "modified", I mean the data which enter into the FFT process are different from the data if directly collected from usrp_rx_cfile.py. The value of the remaining  data (after sync and CP removed) have been changed? If that's true, How can I match the original data ( same data obtained from usrp_rx_cfile.py but without CP and unsync'd data) to the FFT bins? 

Thank you,
Bin

On Thu, Feb 11, 2010 at 12:16 AM, Tom Rondeau <address@hidden> wrote:

On Wed, Feb 10, 2010 at 8:46 PM, bin zan <address@hidden> wrote:

> 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
>>
>
>