Re: [Discuss-gnuradio] Several basic questions

[David Scaperoth]

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?

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.

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

David

> 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.
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio