Several basic questions

GNU Radio
1

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? 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
issue?

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.

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

Thanks,

Teun

–
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.

2

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

system bandwith of 32 Mhz (Nyquist), which is enough for example
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?

Yes.

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
issue?

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.

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.

David

3

2007/6/11, Teun [email protected]:

usual I/O handling of the USB bus is 16 bits I and 16 bits Q signals, which
issue?
Correct me if I am wrong, but in the usrp_rx_cfile.py script there is
an option to transfer 8-bit samples across the USB. With this option
enable, it should be possible to increase the BW at the expense of the
resolution.

–
Trond D.