discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receivi


From: Alex Zhang
Subject: Re: [Discuss-gnuradio] Support wideband(20MHz) OFDM transmitting/receiving using RawOFMD and USRP N210
Date: Mon, 6 Aug 2012 22:04:45 -0500

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.

Here the paper has some literature review on the USRP usage.
http://iweb.tntech.edu/rqiu/publications/JCMQiu_2012.pdf

On Mon, Aug 6, 2012 at 9:33 PM, Qing Yang <address@hidden> wrote:
Hi Alex,

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.

Sincerely,
--
Yang, Qing
Information Engineering, CUHK



2012/8/7 Alex Zhang <address@hidden>
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.


On Mon, Aug 6, 2012 at 3:06 PM, Alex Zhang <address@hidden> wrote:
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...

On Mon, Aug 6, 2012 at 10:12 AM, Qing Yang <address@hidden> wrote:
Dear all,

Recently we are building an OFDM communication system based on RawOFDM(http://people.csail.mit.edu/szym/rawofdm/README.html). 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


Sincerely,
--
Yang, Qing
Information Engineering, CUHK


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




--

Alex,
Dreams can come true – just believe.




--

Alex,
Dreams can come true – just believe.





--

Alex,
Dreams can come true – just believe.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]