Just the status report from the work done the past couple of weeks on OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I have merged the code into the trunk so others can use it, though I currently restricted the subcarrier modulations to use only BPSK or QPSK (M-QAM will be coming soon I hope). It's not complete; specificially, it lacks an adaptive equalizer over the entire packet and channel coding. Other features should be coming over time, too. If you're interested, and for the good of the community, I have posted the presentation I gave last week to the Wireless@VT Symposium about the implementation details of the system. This includes the block-diagram representations of the flow graphs for the transmitter, receiver, and, most importantly, the synchronizers used in the system. I have made it available in both PPT and PDF format (the PPT opens just fine in the latest version of Open Office for those without MS Office). You can find it under the Presentations link on the front page of Trac (Johnathan, Eric, if you have a better place to put this kind of information, let me know; this seemed like a good place to start). Tom
on 2007-06-13 21:16
on 2007-06-13 22:11
Tom Rondeau wrote: > Just the status report from the work done the past couple of weeks on > OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully > transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. > I have merged the code into the trunk so others can use it, though I > currently restricted the subcarrier modulations to use only BPSK or QPSK > (M-QAM will be coming soon I hope). Is the not-completed QAM code in one of the developer branches (which one) Maybe I can do some work at it as soon as I get to work on OFDM. (I am now working on optimizing the wfm_rcv_pll code, my goal is a factor 4 improvement) > If you're interested, and for the good of the community, I have posted > the presentation I gave last week to the Wireless@VT Symposium about the > implementation details of the system. ......You can find > it under the Presentations link on the front page of Trac Thanks for this. Martin
on 2007-06-14 07:41
I've checked out the latest version (5772) and tried running the benchmark_ofdm files. The benchmark_ofdm.py and ofdm_benchmark_tx.py seem to be working. But when I use the benchmark_ofdm_rx.py I get the following error: python: gr_ofdm_correlator.cc:105: gr_complex gr_ofdm_correlator::coarse_freq_comp(int, int): Assertion `symbol_count <= 1000' failed. Aborted (core dumped) Currently I'm using two USRPs on one PC and tried transmitting across the air. (I modified the benchmark_rx with 'which=1'). I ran the scripts as follows: ./benchmark_ofdm_rx.py -f2.45e9 -d100 ./benchmark_ofdm_tx.py -f2.45e9 -i200 --tx-ampl=200 I hope you can give me some pointers to solve this. -Ismail -- View this message in context: http://www.nabble.com/OFDM-implementation-tf391715... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2007-06-14 16:13
Martin Dvh wrote: > Is the not-completed QAM code in one of the developer branches (which one) > Maybe I can do some work at it as soon as I get to work on OFDM. > (I am now working on optimizing the wfm_rcv_pll code, my goal is a factor 4 improvement) It's actually in the trunk, it's just hidden from the benchmark code. For the modulator, we have built a few different versions called "gr_ofdm_bpsk_mapper" and "gr_ofdm_qpsk_mapper." There is also "gr_ofdm_qam_mapper" that's kind of in shambles to force QAM16. I'd much rather get rid of these and make one "gr_ofdm_mapper" or "gr_ofdm_vector_mapper" function that receives a vector of constellation points as an argument. Then we can just use qam.py and psk.py to generate the constellation in Python and pass it to the mapper function that simply takes log2(len(constellation)) number of bits in at a time and maps them to constellation points. The only real trick is to handle residual bits on byte boundary (8PSK, 8QAM, etc.). We'll then have to have a corresponding demapper on the receiver. Just a heads-up, I'm moving to Ireland over the next week and leaving my computer behind, so I'll be pretty much unavailable for about a week and a half to two weeks as I settle in over there (and get my new computer). The work on this is pretty trivial, but I won't be able to touch it for a while, so if you feel like working on it, great! Tom
on 2007-06-15 00:33
Tom Rondeau wrote: > If you're interested, and for the good of the community, I have posted > Tom > > I seem to be having trouble- I've tried the usual suspects for arguments but get [root@evo ofdm]# ./benchmark_ofdm_tx.py -f 13M -s 300 -i 200 -M 1 Traceback (most recent call last): File "./benchmark_ofdm_tx.py", line 217, in ? main() File "./benchmark_ofdm_tx.py", line 190, in main fg = usrp_graph(options) File "./benchmark_ofdm_tx.py", line 56, in __init__ self.txpath = transmit_path(self, options) File "/root/gnuradio-normal/gnuradio-examples/python/ofdm/transmit_path.py", line 44, in __init__ self.ofdm_tx = \ File "/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm.py", line 88, in __init__ self._pkt_input = gr.ofdm_bpsk_mapper(msgq_limit, options.occupied_tones, options.fft_length) File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_general.py", line 7060, in ofdm_bpsk_mapper return _gnuradio_swig_py_general.ofdm_bpsk_mapper(*args) TypeError: ofdm_bpsk_mapper expected 5 arguments, got 3 What options does it really need? even if i go nuts and specify nearly everything with defaults ./benchmark_ofdm_tx.py -f 13M -s 300 -i 200 -M 1 --tx-amplitude=12000 -m bpsk --fft-length=512 --occupied-tones=200 --cp-length=128 I still get the same 'got 3' What'd I miss? -- View this message in context: http://www.nabble.com/OFDM-implementation-tf391715... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2007-06-15 17:23
Brett Trotter wrote: >> >> > fg = usrp_graph(options) > File > > I still get the same 'got 3' > > What'd I miss? > It's a SWIG problem. You'll probably need to clean out your gnuradio-core/src/lib/swig directory (make distclean inside it works and prevents you from having to build the whole thing again). We switched the interface by handling the insertion of known symbols in another block, so we went from 5 inputs to 3. Try again after cleaning up the SWIG files and reinstalling. Tom
on 2007-09-25 23:03
Hi: Why I run the benchmark_ofdm and there is a warning like below? gr_buffer::allocate_buffer: warning: tried to allocate 20 items of size 1600. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. And, the program stops! Does anyone knows what do I miss? Thanks!! KC