[Discuss-gnuradio] Combining of programs
Hi all, I'm trying to combine both sensing program (usrp_spectrum_sense.py) and transmitting program, the initialization is done using the classes usrp_options, generic_usrp, usrp_receive_path, receive_path But when i try to pass the usrp_source_c object to spectrum sensing program to set its parameter i get the following error concerning 'determince_rx_mux_value' function. This function exist in usrp_swig.py. I don't know why the compiler said that it does not exist?? keep in mind that other functions of usrp_source_c are working well like(set_decim, and usrp_rate) The ERROR: o...@vecon3:~/Documents/abbasi/programming/examples/sensing$ python test_sensing_v1.2.py -f 2.4G -m dbpsk Note: failed to enable realtime scheduling abbasi1 abbasi2 gr_fir_ccf: using SSE Requested TX Bitrate: 100k Actual Bitrate: 125k set auto True abbasi receive_path abbasi receive_path after Requested RX Bitrate: 100k Actual Bitrate: 125k modulation: dbpsk freq: 2.4G bitrate:100kb/sec samples/symbol: 2 Carrier sense threshold: 30 dB determine mux: Traceback (most recent call last): File test_sensing_v1.2.py, line 605, in module main() File test_sensing_v1.2.py, line 574, in main print determine mux: , usrp.determince_rx_mux_value(tb.rxpath.get_usrp_source(), options.s_rx_subdev_spec) AttributeError: 'module' object has no attribute 'determince_rx_mux_value' I appreciate any help thanks -- View this message in context: http://old.nabble.com/Combining-of-programs-tp28149942p28149942.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Scanning whole spectrum using TVRX
Dear All, I have a TVRX board, and am trying to do some experiments with it. My requirement is to scan the entire spectrum (50MHz - 860MHz), and dump the samples for processing using MATLAB. At a time, I am sensing 250KHz of spectrum (decimation 256), and I am collecting 10,000 samples (40 ms sensing time). My initial take was to call usrp_rx_cfile.py multiple times, each time passing in a different frequency. However, this approach takes around 15 minutes to scan the entire range (I assume it is due to the overheads). Is there any way I could make this faster? Regards, Anand ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT - Why was m-block removed - Has anyone measured latency with the USRP2 and GigE - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this - Is the scheduler the main issue in the way it handles i/o between blocks Charles On Sun, Mar 14, 2010 at 5:52 PM, George Nychis gnyc...@gmail.com wrote: Think of it this way... MAC *development* is severely limited by GNU Radio... it lacks the much-needed functionality to make information passing between the blocks rich, simple, and bi-directional. Some of the building blocks are in place (e.g., PMT), and the m-block was implemented to solve the rest of the problems, but was deprecated (maybe removed as of now?). MAC *performance* is limited by several things: 1) delay between GNU Radio and the USRP/USRP2, 2) signal processing delay (GNU Radio), and (3) jitter (e.g., unpredictable delay) ... (1) is reduced a little by USRP2 using GigE, but it's still not down to traditional MAC turnaround times (10s of us). (2) benefits from Moore's law. (3) kind of depends on whether you use realtime scheduling and how your data hits delays in queues mainly. All in all... still an open problem IMO. - George On Sun, Mar 14, 2010 at 5:06 PM, Charles Irick cir...@gmail.com wrote: I've been reading some papers related to MAC layer development on the USRP, but they seem to have tapered off with the USRP2. Does anyone have any information about MAC layer and protocol development for the USRP2. Has this been satisfied with things like timestamps and gigE? Any current papers or web links related to USRP2 protocol level development? Thanks. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick cir...@gmail.com wrote: Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT http://gnuradio.org/redmine/wiki/1/TypePMT - Why was m-block removed http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html - Has anyone measured latency with the USRP2 and GigE I'm not sure. - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this I think the latency is on hundreds of microseconds, which is greater than, say, an 802.11 ACK turnaround time (24us). - Is the scheduler the main issue in the way it handles i/o between blocks There are some details of this in the second link I gave. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] minimum number of packets usrp can receive?
i am using the RFX-2400 with usrp-1 *i would like to know what is the minimum amount of data/ minimum number of packets that the usrp can receive*. i used the benchmark_rx file and changed the default packet size to 10 bytes. by using the --from-file option and sending only 1 packet (10 bytes) of data i was unable to receive anything. only when the data was about 4 packets was i able to receive. i changed the packet size to different values but still couldn`t receive a single packet. i am transmitting at 500kb, gmsk, and the --discontinuous option enabled. is this a limitation of the usrp or am i missing something? secondly can anyone tell as to how many bits or bytes a single byte of data is converted to during transmission? i mean if i had 1 byte to transmit what would i get at the receiver say before the correlator. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Questions on DDC in gr-sounder project
Dear all, I'm trying to understand how Digital Down Conversion Implemented in gr-sounder project. The DDC needs to be implemented in FPGA, but there isn't any module in FPGA configuration implementing DDC. How does the receiver in gr-sounder implement Digital Down Conversion? Thanks a lot in advance Regards, Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on DDC in gr-sounder project
On Tue, Apr 6, 2010 at 08:19, Yan Nie yn...@uwo.ca wrote: I'm trying to understand how Digital Down Conversion Implemented in gr-sounder project. The DDC needs to be implemented in FPGA, but there isn't any module in FPGA configuration implementing DDC. How does the receiver in gr-sounder implement Digital Down Conversion? The gr-sounder component does not implement a DDC. The host code issues a tune command to set the center frequency of the analog daughterboard, then the entire baseband bandwidth of the downconverted signal is correlated with the reference PN code at successive lags to get the channel impulse response. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT http://gnuradio.org/redmine/wiki/1/TypePMT - Why was m-block removed http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html - Has anyone measured latency with the USRP2 and GigE I'm not sure. - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this I think the latency is on hundreds of microseconds, which is greater than, say, an 802.11 ACK turnaround time (24us). I would tend to blame Linux and buffering more than GbE itself (MAC + PHY). Here is an interesting doc where the researchers were asking similar questions: http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf I'm not sure yet how much buffering is done in the USRP2 firmware but we hope to know shortly as a couple of our guys are in the process of taking apart the logic, pulling out non-GbE related sections, and rebuilding. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but the delay was too long and inconsistent. I can't remember the exact figures, but definitely up to milliseconds. Veljko 2010/4/6 George Nychis gnyc...@cmu.edu: On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick cir...@gmail.com wrote: Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT http://gnuradio.org/redmine/wiki/1/TypePMT - Why was m-block removed http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html - Has anyone measured latency with the USRP2 and GigE I'm not sure. - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this I think the latency is on hundreds of microseconds, which is greater than, say, an 802.11 ACK turnaround time (24us). - Is the scheduler the main issue in the way it handles i/o between blocks There are some details of this in the second link I gave. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on DDC in gr-sounder project
Thank you so much Johnathan. Is that means the signal is converted before ADC? I'm quite confused about how the FPGA configuration connect with host code. The FPGA bitstream is loaded by usrp.source_c or usrp.source_s. Where is the FPGA bitstream loaded into? How does the usrp source class load the FPGA bitstream? Thanks, Yan - Original Message - From: Johnathan Corgan jcor...@corganenterprises.com Date: Tuesday, April 6, 2010 11:32 pm Subject: Re: [Discuss-gnuradio] Questions on DDC in gr-sounder project To: Yan Nie yn...@uwo.ca Cc: discuss-gnuradio@gnu.org On Tue, Apr 6, 2010 at 08:19, Yan Nie yn...@uwo.ca wrote: I'm trying to understand how Digital Down Conversion Implemented in gr-sounder project. The DDC needs to be implemented in FPGA, but there isn't any module in FPGA configuration implementing DDC. How does the receiver in gr-sounder implement Digital Down Conversion? The gr-sounder component does not implement a DDC. The host code issues a tune command to set the center frequency of the analog daughterboard, then the entire baseband bandwidth of the downconverted signal is correlated with the reference PN code at successive lags to get the channel impulse response. Johnathan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Veljko- I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but the delay was too long and inconsistent. I can't remember the exact figures, but definitely up to milliseconds. Do you mean two USRP2s back-to-back? Or both connected to motherboard ports? -Jeff 2010/4/6 George Nychis gnyc...@cmu.edu: On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick cir...@gmail.com wrote: Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT http://gnuradio.org/redmine/wiki/1/TypePMT - Why was m-block removed http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html - Has anyone measured latency with the USRP2 and GigE I'm not sure. - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this I think the latency is on hundreds of microseconds, which is greater than, say, an 802.11 ACK turnaround time (24us). - Is the scheduler the main issue in the way it handles i/o between blocks There are some details of this in the second link I gave. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Two independent PC+USRP nodes. All the ACK related logic was implemented at the Python layer. Another thing that I tried was to connect the two nodes via Ethernet (I have two Ethernet NICs in each of the PCs) and then use USRPs for data and Ethernet for ACKs. I still couldn't get good results, although I had some issues with the OFDM decoding latency, so I can't really say where the bottleneck was. Veljko 2010/4/6 Jeff Brower jbro...@signalogic.com: Veljko- I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but the delay was too long and inconsistent. I can't remember the exact figures, but definitely up to milliseconds. Do you mean two USRP2s back-to-back? Or both connected to motherboard ports? -Jeff 2010/4/6 George Nychis gnyc...@cmu.edu: On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick cir...@gmail.com wrote: Thanks for the reply George. I'm still looking for a little more information on this topic. - What is PMT http://gnuradio.org/redmine/wiki/1/TypePMT - Why was m-block removed http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html - Has anyone measured latency with the USRP2 and GigE I'm not sure. - Is GigE alone not capable of handling MAC turnaround times or is software to blame for this I think the latency is on hundreds of microseconds, which is greater than, say, an 802.11 ACK turnaround time (24us). - Is the scheduler the main issue in the way it handles i/o between blocks There are some details of this in the second link I gave. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
I would tend to blame Linux and buffering more than GbE itself (MAC + PHY). Here is an interesting doc where the researchers were asking similar questions: http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf I'm not sure yet how much buffering is done in the USRP2 firmware but we hope to know shortly as a couple of our guys are in the process of taking apart the logic, pulling out non-GbE related sections, and rebuilding. -Jeff I glanced over the document briefly and was wondering if your analysis of the linux issue was because of this document, or a separate source. I'm only asking because the document is 10 years old and is using RedHat 5 and Pentium 2s. I would assume the linux kernel support for GigE has improved since then. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Their whitepaper is here: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense): http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;) PS. it also has architectural latency measurements (e.g., host - kernel, kernel - USRP, USRP - kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested. This is why you have the problems you have Veljko, the turnaround time is extremely high. We came up with the approach of fast-ACKs which are generated from the USRP itself. This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
On 03/30/2010 11:48 AM, Jeff Brower wrote: Matt- We're working on a project at Signalogic to interface one of our DSP array PCIe cards to the USRP2. This would provide a way for one or more TI DSPs to insert into the data flow and run C/C++ code for low-latency and/or other high performance applications. The idea is that we would modify the current USRP2 driver (or create an alternative) so it would read/write to/from the PCIe card instead of the Linux (motherboard) GbE. A few general questions at this point: 1) We would connect the USRP2 to the GbE on our DSP array card. We would want to shift latency/delay downstream to the PCIe card Linux driver interface, and make the GbE-to-GbE interface as low latency as possible. Could you give us some guidance on which FPGA modules handle buffering for host transmit/receive? The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac which is instantiated in u2_core. Most of the buffering happens in simple_gemac_wrapper in the fifo_2clock_cascade files. Is it reasonable we can reduce buffer sizes if the array card GbE has a fast response time? You could drastically reduce this buffering if you could guarantee fast response. 2) We want to use the GNU radio GMAC as opposed to Xilinx or other off-the-shelf core, our thinking being that we can make contributions to data rate and latency-reduction discussions, as well as tech USRP2 tech support, if we become familiar with your core. Can you give us some guidance on a process to remove non-GMAC related modules from the firmware? Go to the top level and start pulling? Obviously SRAM related, CORDIC, and ADC/DAC interfaces, are not needed. I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? There were some on the wiki at one time. If they're not still there I'll post a talk I did which covers the architecture. If you really just want high speed super low latency connections to another board, I would suggest using the SERDES (MIMO) interface instead. It will have less latency than GbE. You just need an FPGA with gigabit transceivers, or a TI TLK2701 chip to talk to. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
On 04/06/2010 04:19 PM, George Nychis wrote: Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Is Sora active? The forum seems really quiet. Also they say there is a strict non-commercial use use license. Also, it seems like they are using the RF front ends from WARP, a look at the Warp site suggests the radio board is 2K. Also, they estimate the board price at several K$, so it is not quite WARP prices, but looks to be closing in on it rapidly. [1] Philip [1] http://social.microsoft.com/Forums/en-US/sora/thread/2701a49b-2ea1-4df6-a85c-d5d01b4ea77c Their whitepaper is here: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense): http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;) PS. it also has architectural latency measurements (e.g., host - kernel, kernel - USRP, USRP - kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested. This is why you have the problems you have Veljko, the turnaround time is extremely high. We came up with the approach of fast-ACKs which are generated from the USRP itself. This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Hi George, 2010/4/6 George Nychis gnyc...@cmu.edu: Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Their whitepaper is here: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense): http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;) PS. it also has architectural latency measurements (e.g., host - kernel, kernel - USRP, USRP - kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested. This is why you have the problems you have Veljko, the turnaround time is extremely high. We came up with the approach of fast-ACKs which are generated from the USRP itself. What I got from your paper is that the matched filter approach for fast packet detection would not work in an OFDM setting. What about fast ACK generation? Would it require an IFFT implementation on the USRP? Would it help much? This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P Is there anything that would prevent GNUradio developers to push the MAC layer functionality on the USRP? - George cheers, Veljko ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Did you see my previous post about the accelerator PCIe card? To some extent the Microsoft approach is what we're doing. But we want to stay compatible with USRP2 hardware so we connect GbE to the accelerator card; non MAC-related dataflow is PCIe from there. Buffering required to stay compatible with USRP2 software and high, sustained transfer rates moves right, to the accelerator card (which has a lot of memory). The real trick is software. Our approach is that MAC-related code still appears in GNU radio source, but is marked with pragmas (first something specific to our project, then OpenCL, then OpenMP) so that code actually runs on the accelerator card (the TI multicore CPUs on the acclerator card run arbitrary C/C++ code so they're not limited like an Nvidia or other GPU). We plan to use our GNU radio interface to test results of a server acceleration project we're doing for DoE. That's the long story... right now our short-term objective is the GbE-to-GbE USRP2 connection. BTW, that's a Virtex 5 on the Sora board, that's not going to be cheap. -Jeff Their whitepaper is here: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense): http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;) PS. it also has architectural latency measurements (e.g., host - kernel, kernel - USRP, USRP - kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested. This is why you have the problems you have Veljko, the turnaround time is extremely high. We came up with the approach of fast-ACKs which are generated from the USRP itself. This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Philip- On 04/06/2010 04:19 PM, George Nychis wrote: Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Is Sora active? The forum seems really quiet. Also they say there is a strict non-commercial use use license. Also, it seems like they are using the RF front ends from WARP, a look at the Warp site suggests the radio board is 2K. Also, they estimate the board price at several K$, so it is not quite WARP prices, but looks to be closing in on it rapidly. [1] I think you're touching on an underlying, basic point: Matt et. al. have spent years developing an RF + server architecture that both works and is inexpensive. Those two things are very difficult to integrate. Many tradeoffs and compromises must be made carefully, with a lot of painstaking trial and error. Matt's followers recognized this some time ago, more recently NI has recognized this. The Sora team may find it difficult -- and likely expensive -- to reliably move very high rate ADC data over some distance, external to the PC. PCIe-over-cable is one way, but again, not cheap. -Jeff [1] http://social.microsoft.com/Forums/en-US/sora/thread/2701a49b-2ea1-4df6-a85c-d5d01b4ea77c Their whitepaper is here: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense): http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;) PS. it also has architectural latency measurements (e.g., host - kernel, kernel - USRP, USRP - kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested. This is why you have the problems you have Veljko, the turnaround time is extremely high. We came up with the approach of fast-ACKs which are generated from the USRP itself. This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Charles- I would tend to blame Linux and buffering more than GbE itself (MAC + PHY). Here is an interesting doc where the researchers were asking similar questions: http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf I'm not sure yet how much buffering is done in the USRP2 firmware but we hope to know shortly as a couple of our guys are in the process of taking apart the logic, pulling out non-GbE related sections, and rebuilding. -Jeff I glanced over the document briefly and was wondering if your analysis of the linux issue was because of this document, or a separate source. I'm only asking because the document is 10 years old and is using RedHat 5 and Pentium 2s. I would assume the linux kernel support for GigE has improved since then. Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. What I found interesting in that particular document is the authors were careful not to speculate and to use a logic analyzer to make exact measurements. For me the key figures are GbE (MAC + PHY) and PCI latencies, which are likely not too reducible. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
On Tue, Apr 6, 2010 at 5:35 PM, Jeff Brower jbro...@signalogic.com wrote: Philip- On 04/06/2010 04:19 PM, George Nychis wrote: Jeff, I definitely agree that buffering also adds significant latency. How much of the MAC can you get around? I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough. We need lower latency between the hardware and the host. Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue: http://research.microsoft.com/en-us/projects/sora/ Is Sora active? The forum seems really quiet. Also they say there is a strict non-commercial use use license. Also, it seems like they are using the RF front ends from WARP, a look at the Warp site suggests the radio board is 2K. Also, they estimate the board price at several K$, so it is not quite WARP prices, but looks to be closing in on it rapidly. [1] I think you're touching on an underlying, basic point: Matt et. al. have spent years developing an RF + server architecture that both works and is inexpensive. Those two things are very difficult to integrate. Many tradeoffs and compromises must be made carefully, with a lot of painstaking trial and error. Matt's followers recognized this some time ago, more recently NI has recognized this. The Sora team may find it difficult -- and likely expensive -- to reliably move very high rate ADC data over some distance, external to the PC. PCIe-over-cable is one way, but again, not cheap. SORA is quiet right now because the boards are not public. To my understanding, they are providing dozens to research institutions for research purposes, and then after this phase pushing them public. But, I'm not sure. That's just my impression. Their original proposed price range of the SORA board was $2k. I'm not sure it will hit that price, and you're right, they're using a WARP daughterboard which is pricey. Luckily, in the academic world we can get our hands on some of these. CMU was awarded 6 of the SORA boards (which I'm assuming will come with daughterboards?) for research. Our plan is to connect them to our wireless emulator (http://www.cs.cmu.edu/~emulator/) which is accessible to *anyone*. That would allow both us, and anyone who wanted to, to use the SORA boards. But, we need to change some of the infrastructure to support the PCI-E boards. I definitely agree with you on the tradeoffs there. There is a pure tradeoff between cost and performance, and Matt and the USRP hit a great point for flexibility at the PHY and low cost radios. This to me, is sufficient for a lot of PHY-level research. As we go up the protocol stack, it's just not sufficient enough. I'm not saying it's a bad SDR solution, it's just insufficient to work our way up the protocol stack and have an effective, high throughput, radio. I'm not sure what the answer is to this... but I'm hoping there is one in the future that facilitates MAC development at a low cost :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Did you see my previous post about the accelerator PCIe card? To some extent the Microsoft approach is what we're doing. But we want to stay compatible with USRP2 hardware so we connect GbE to the accelerator card; non MAC-related dataflow is PCIe from there. Buffering required to stay compatible with USRP2 software and high, sustained transfer rates moves right, to the accelerator card (which has a lot of memory). Interesting, I didn't see this post. I tried doing some googling for it but I couldn't turn up with it. What was the subject of the post? The real trick is software. Our approach is that MAC-related code still appears in GNU radio source, but is marked with pragmas (first something specific to our project, then OpenCL, then OpenMP) so that code actually runs on the accelerator card (the TI multicore CPUs on the acclerator card run arbitrary C/C++ code so they're not limited like an Nvidia or other GPU). We plan to use our GNU radio interface to test results of a server acceleration project we're doing for DoE. That's the long story... right now our short-term objective is the GbE-to-GbE USRP2 connection. So right now you're trying to get low latency, but high throughput, between two USRP2's connected directly via GbE? So you're not using the frontend? Maybe this is explained in your previous post, if so just point me to it ;) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
PS. if you haven't seen, SORA is able to interoperate with 802.11g, which is impressive. It meets all of the timing requirements. However, it does not come with the exact ease of programming that we're familiar with. They do have to push the use of SSE and tradeoff a lot of computation for memory to do lookups. This isn't a major drawback, but it is different. For those not necessarily concerned so much with the PHY, but are looking for MAC development, it would come with a black box PHY for the standard 802.11 waveforms that can pull the processing off in time for MAC turnaround. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Hi Veljko, What I got from your paper is that the matched filter approach for fast packet detection would not work in an OFDM setting. What about fast ACK generation? Would it require an IFFT implementation on the USRP? Would it help much? It's a good question, and something I haven't explored, and I'm not much of a DSP guy. So, I'll punt the question to everyone else who has more DSP experience than me. Both are all about signal detection, both the fast-packet detection and fast ACK generation. So what you want to do is first detect the preamble in the USRP without decoding (because it's complex and takes long). So, we propose using a matched filter on the USRP to detect the packet preamble. In 802.11ab, the preamble was done with BPSK (even if the data is sent using OFDM in 802.11a). With 802.11g, it can be a full OFDM preamble. So, with a full OFDM preamble, you can still detect it with a matched filter, but I'm a little unclear about how to generate the coefficients. You essentially are detecting in the time domain with the matched filter. It might require an IFFT on the USRP... anyone? Dan? :) This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P Is there anything that would prevent GNUradio developers to push the MAC layer functionality on the USRP? The USRP and USRP2, from what I understand, are both tight for space in the FPGA. I'm pretty confident you can't fit an OFDM implementation on the USRP. There are free multipliers and space on the USRP2, but I think it would also be tight, leaving you with not much room for the MAC. Then, you'd be building the MAC in verilog which sucks. Most people who want to do MAC development have CS backgrounds, not EE backgrounds, form which Verilog is black magic ;) - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Basic questions about MIMO on USRP2
Hi all, I have several basic questions on about build a MIMO system with two USRP2s. I have my master board connect with the computer and the external clock. The slave board is connected to the master by the MIMO cable. I am working C++ and I have the SISO working now. My questions are as follows: 1 Do I need to rebuild the firmware and FPGA code for the master USRP2? 2 How I can identify which one is the master board which one is the slave in the code? 3 Do I need to call the make(interface, mac_addr_str) function twice ? 4 How can I get the mac_addr_str values for the slave and the master board ? -- Best Regards! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. I know that in the early days of Linux development, David Miller spent a lot of time making sure that the Ethernet layer could reliably send and receive more than 1 MByte/sec via TCP over 10 megabit Ethernet, and more than 10 MBytes/sec over TCP on 100 megabit Ethernet. I watched his measurements and his kernel evolve to make it happen (learning from and improving on Van Jacobson's early work making 68000-based Sun-2's move 1MByte/sec over TCP on original Ethernet). You might say, That's only 90%, surely he can do better, but that's 90% of the raw bit rate, delivered flow controlled and error-free at the TCP socket layer (all the overhead, from interframe spacing to preambles to CRCs to packet headers, goes in the 10%). As you might expect, pumping the data through required keeping all parts of both systems working in overlap. One packet being assembled to transmit, one received packet being picked apart, and one packet flying on the medium, at all times. If these two software jobs can both run in one packet time, you win (and don't need much if any buffering, keeping latency very low). These code paths were heavily scrutinized and optimized for the common cases. I haven't kept track of who's measuring Linux kernel GigE thruput recently. Here's a pointer to a 2001 study: http://www.csm.ornl.gov/~dunigan/netperf/bulk.html Most people care about TCP speed, but making fast paths for TCP usually makes even faster paths for the UDP packets that USRP2 will be using soon. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
On 04/06/2010 09:44 PM, John Gilmore wrote: Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. Simple test. Core 2 Duo system, 2.33GHz, Fedora 11. A 1500 byte ping test to localhost yields an average RTT of about 33usecs. That tests most of the network stack except for hardware interfaces, and gives you some notion of best case for latency/turn-around time. If MACs have requirements that are more aggressive than 20-50usec turnaround time, then relying purely on software in a running general-purpose operating system, even on relatively-good hardware may be optimistic. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Hi All
I am trying to understand how the optimised modified Mueller and Muller
algorithm is implemented in GNU Radio.
I had a look at the method gr_mpsk_reciever_cc::mm_error_tracking, to
see how this is done. As far as I can tell, lines 242-245 are intended
to implement equation (8) of the referenced paper, where mm_error
corresponds to mu(k) in eqn. (8). However, if I have interpreted this
correctly, what is implemented is actually:
\mu(k) = Real{[p(k) - p(k-2)] \times \hat{c}^{*}(k-1) - [\hat{c}(k) -
\hat{c}(k-2)] \times p^{*}(k-1)},
whereas eqn. (8) in the referenced omMM paper, is actually:
\mu(k) = Real{[\hat{c}(k) - \hat{c}(k-2)] \times p^{*}(k-1) +
\hat{c}^{*}(k-1) \times [p(k) - p(k-2)]}
Have I missed something here? Are these lines of code not meant to
implement eqn (8) as I suspected?
Thanks
Ian.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error meaning: not connected internally
Dear all, I try to make simulation for qam loopback. But there is an error: RuntimeError: hierarchical block 'qam8_demod' input 0 is not connected internally What is the error mean? Thank you for your help Makmur File /home/makmur/sim_qam_loopback.py, line 150, in module tb.Run(True) File /usr/lib/python2.6/dist-packages/grc_gnuradio/wxgui/top_block_gui.py, line 73, in Run if start: self.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/top_block.py, line 97, in start self._tb.start() File /usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py, line 1411, in start return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(*args, **kwargs) RuntimeError: hierarchical block 'qam8_demod' input 0 is not connected internally ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error meaning: not connected internally
On Wed, Apr 7, 2010 at 1:18 AM, Makmur Hidayat makm...@gmail.com wrote: Dear all, I try to make simulation for qam loopback. But there is an error: RuntimeError: hierarchical block 'qam8_demod' input 0 is not connected internally What is the error mean? Thank you for your help Makmur The QAM receiver code isn't really ready for use yet. In fact, if you look into the code of the block, there's nothing there and it has been disabled for use with the modulation_utils. We don't really have the synchronization capabilities written for QAM signals yet, although some of the newer code I've been working on should be almost there. Please feel free to work on this. I'd love to see it in the code, but I won't have the time to get to it for a while yet. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
