Recently we are building an OFDM communication system based on RawOFDM( How to build and run RawOFDM?). In the simplest
point-to-point
case, we use a pair of PC and USRP as the transmitter and use another
pair
as the receiver.
To reduce the influence of CFO, we need to run our system with large
bandwidth (like 802.11 at 20MHz). However, once we set the transmitting
bandwidth larger than 2MHz, the receiver’s program will block there and
show “over-run” message later on (a screen of "O"s). For small bandwidth
(<2MHz), the receiver runs pretty well.
Do you have similar experience? How can I make the OFDM receiver work
with
20MHz bandwidth?
We use USRP N210. And the configuration of our PC is
Ubuntu release 10.10(maverick) kernel 2.6.35-22-generic GNOME 2.32.0
Memory: 15.7GiB
Processor 0~7: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
UHD version: UHD_003.004.000-c50bb91 image version 8
gnuradio version: 3.4.x
Your experience is exactly what I have tested. The data rate of OFDM
based
on the current GNURadio never exceeds 1Mbps with acceptable PER.
I guess the only way to beat more bandwidth is to use very strong
computer…
Just state, I was using the tunnel.py instead of the rawOFDM to do the
test. Seems nobody declared good bitrate within this community, although
I
have asked for many times.
Thanks for sharing your experience. Are you using RawOFDM or Benchmark
OFDM?
I agree with you that we need more powerful PCs because for large
bandwidth
we have too much samples to process. Furthermore, the bottleneck is
definitely in the receiving part because in our system the transmitter
can
support 20MHz OFDM transmitting well. And the signal processing
complexity
of OFDM receiver is much higher than transmitter.
I think our PCs are powerful enough (4 cores cpu at 2.4G) and we are
ready
to purchase some more powerful PCs (8 cores at 3.3G). But I wonder that
even 3.3G cpu still cannot support 20MHz bandwidth.
Does anyone have other solutions such as using parallel signal
processing
or multi-thread? We have 8-core cpu but we don’t know how to fully
utilize
them using gr.
Just state, I was using
the tunnel.py instead of the rawOFDM to do the test. Seems nobody
declared good bitrate within this community, although I have asked for
many times.
–
Alex, Dreams can come true - just
believe.
Nobody has answered because there is no single answer. Your
achievable performance depends on too many factors for anyone to come up
with a reasonable answer.
Different computers, with very different
performance levels, different OS distributions with different
optimizations in different parts of the kernel. And that’s ignoring any
of the path distortions that may be present between your radios.
The
fact is that general-purpose operating systems aren’t well-optimized for
real-time, high-bandwidth, digital signal processing, even on systems
where the “raw” compute power would seem to be adequate. The path
lengths (in terms of number of executed instructions) between data
sources and the calculations are much longer than they would be in a
compute environment optimized for the job.
Nobody has answered because there is no single answer. Your achievable
performance depends on too many factors for anyone to come up with a
reasonable answer.
Yes, I agree with you that there are many factors to impact the
performance. So I keep asking what is the best performance has been
achieved within the community, and then I can compare with them to find
out
the possible space to improve the bandwidth supported. What I just need
is
just an concrete number for benchmark. If any guy claims the good
result, I
will know I still can do something to beat the limit.
I use the Benchmark OFDM instead fo RawOFDM, but I think the basic
synchronization algorithm is the same.
UT austin has a project Hydra which is using the OFDM modulation, http://netlab.ece.utexas.edu/hydra/
but I did not see any record about the bitrate they achieved. Someone
else
told me that Hydra does not have big bandwidth.
24MHz is impossible to be achieved, as the maximum USRP sample rate is
25M/S for 16bit sample, except you use your own frond end.
8 Core at 3.3G PC should have improvement on the supported bandwidth.
But I
don’t know what performance it can achieve. Currently I am using the
4Core
as yours.
The GNURadio has its own automatic parallelism like VOLK to support SIMD
acceleration. So I dont think you need additional work to support
multi-core computing. But you may consider using the GPU.
However, when I use the uhd_fft.py to see the signal spectrum, the
bandwidth of the benchmark_tx’s signal is only 8MHz. I guess the
benchmark_tx does not use 20MHz to transmit.
Sorry - but I have quick question related to installing rawofdm.
I keep getting that Makefile.in is missing when I try and run configure
in rawofdm. Anything else that I need to do for it to get running?
gnuradio 3.4.2
ubuntu 11.10
Thanks.
Alex Z. wrote in post #1071465:
Hi Qing,
Your experience is exactly what I have tested. The data rate of OFDM
based
on the current GNURadio never exceeds 1Mbps with acceptable PER.
I guess the only way to beat more bandwidth is to use very strong
computer…