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-tf39... Sent from the GnuRadio mailing list archive at Nabble.com.
on 2007-06-11 09:55
on 2007-06-11 15:15
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
on 2007-06-11 16:21
2007/6/11, Teun <firstname.lastname@example.org>: > 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 Danielsen