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 <trondeau1...@gmail.com>wrote: > On Wed, Feb 10, 2010 at 8:46 PM, bin zan <zanbin2...@gmail.com> wrote: > > > > > > On Wed, Feb 10, 2010 at 10:18 PM, bin zan <zanbin2...@gmail.com> 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 <trondeau1...@gmail.com> > >> wrote: > >>> > >>> On Wed, Feb 10, 2010 at 11:40 AM, bin zan <zanbin2...@gmail.com> > 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 < > trondeau1...@gmail.com> > >>> > wrote: > >>> >> > >>> >> On Wed, Feb 10, 2010 at 8:10 AM, bin zan <zanbin2...@gmail.com> > 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 > >> > > > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
