[Top][All Lists]

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

Re: [Discuss-gnuradio] Several basic questions

From: David Scaperoth
Subject: Re: [Discuss-gnuradio] Several basic questions
Date: Mon, 11 Jun 2007 09:13:21 -0400

On Jun 11, 2007, at 3:54 AM, Teun wrote:

Hi Guys,

I tried searching the forum, but I still got some problems which I don't
fully understand.

To my knowledge, the receiving ADC Rate is 64 MSamples/second, at a
granuality of 14 bits/sample. This would make it possible to have a total system bandwith of 32 Mhz (Nyquist), which is enough for example 802.11 standards. However, samples are transfered to the PC, using the USB bus. The usual I/O handling of the USB bus is 16 bits I and 16 bits Q signals, which means that you require 4 bytes per complex sample. The raw data rate for the
USB is 480Mbit/s, but due to overhead it is possible to get only about
320Mbit/s, which is about 40Mbyte/s. Summing everything up, it is possible to transfer 40M/4 = 10Msamples/second over the USB bus, which means that you can only check a system with a bandwith of approximately 10Mhz. Am I right
about this?


If this is true, the limiting factor is the USB bus, not the
ADC's on the USRP. Is it possible to use some sort of 1Gbit ethernet
connection for the USRP?

There will be for the USRP 2 (search the discussion board with "gige" for lots of discussion)

I know this wouldn't help that much, but It would
make it possible to achieve the 802.11 standards (Channels of 20Mhz). Is
this possible or are other things like CPU speed/PC memory becoming an

If you look at the discussion board for HDTV you will find lots of discussion about processing the data off-line because current CPU speeds are not presently not sufficient. There is some work on getting these types of applications working on cell processor.

Another question (I'm pretty new to GNU Radio / USRP). Within our group we
are looking for a testbed to test MESH protocols (MAC level). We are
especially interested in congestion control and throughput measurements (Hopping between nodes). Therefor a basic, maybe stupid, question. If I'm creating some interleaving node (A node which is just receiving messages and forwarding them), what is the minimal time for the USRP to switch between receiving mode and transmitting mode? (RFX2400) Couldn't find anything about
this in documentation.

With the current GNU Radio setup, there are two ways to switch between Tx and Rx. One is manually be calling the Python function set_tx_enable() the other is using the Auto T/R switch, which is called using the set_auto_tr() function in Python. The Auto Switching basically allows the transmit samples to have priority over the receiver samples, so when its time to transmit something, the receive path is halted until the transmitter is done. as far as switching between rx and tx, its on the order of micro-seconds with the auto-switching, but the manual switching (set_tx_enable(True/ False)) is not as clean of a switch and is not coupled to the incoming / outgoing samples at all. It is worth noting that Python will soon be an optional request that will allow the user to couple the samples and configuration operations together more easily, but it is uncertain to me how much that will improve any latency in the manual switching.

With the new mblocks, the process is more manual and will be much faster/powerful than the current implementation , so if you can wait, I would. If you would like to see what other people have done with MAC layer implementations, one well-known project is the Adroit project that partnered with Click MAC level software. I have read a few paper on this and they basically express the need for the mblocks....=).

If anyone could help clearify these things, that would be great.

Please correct me if I misspoke here. Hopefully this gives you a better idea of how to proceed.




View this message in context: http://www.nabble.com/Several-basic- questions-tf3900065.html#a11056374
Sent from the GnuRadio mailing list archive at Nabble.com.

Discuss-gnuradio mailing list

reply via email to

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