Question about gr_ofdm_sampler.cc

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

On Wed, Feb 10, 2010 at 8:10 AM, bin zan [email protected] wrote:

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

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?
2. Why d_timeout_max=1000? Pre-defined preambles only appear
every 1000 FFT length of data?
3. Only data after state_frame will go through FFT process,
others
will be dropped (including CP)?
4. According to your powerpoint OFDM implementation in GNU
radio,
FFT happens before preamble correlation, which file actually do the
preamble
correlation?

Thanks,
Bin

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

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

On Wed, Feb 10, 2010 at 11:40 AM, bin zan [email protected] 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 8:46 PM, bin zan [email protected] 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 7:18 PM, bin zan [email protected] 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

Yes, there is one preamble defined for every packet. The preamble is
designed to be duplicated in time for correlation.

We actually don’t generally use the CP for correlation. While we have
a sync block that does use it, it poses some problems in
implementation (I think this is covered in the presentation you
referenced before). The standard sync method we use just uses the
preamble.

Tom

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 6:52 AM, bin zan [email protected] wrote:

Thank you,
Bin

Well then, yes, it is modified. The ofdm_sync blocks adjusts the
frequency to make sure the subcarriers are in the center of the
frequency bins for the FFT. If you don’t do this, you introduce major
ISI into the received symbol.

Tom

Hi Tom,
> Well then, yes, it is modified.
Since the data are changed, can I say if measure the SNR from the
data
after FFT, then they are inaccurate and bias?

Thanks,
Bin

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs