Just the status report from the work done the past couple of weeks on
OFDM. With Matt E., Bob McGwier, and Eric B., 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
Tom R. wrote:
Just the status report from the work done the past couple of weeks on
OFDM. With Matt E., Bob McGwier, and Eric B., 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
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-tf3917154.html#a11114206
Sent from the GnuRadio mailing list archive at Nabble.com.
Martin D. 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
Tom R. 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-tf3917154.html#a11130078
Sent from the GnuRadio mailing list archive at Nabble.com.
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
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