RE: [Discuss-gnuradio] Considerations for new hardware in gnuradio
The ability to drop bits off in hardware would be a great feature, at the moment I have three high end digitizers and could double my bandwidth/ or quadruple if they had this feature. Most astronomy applications can get away with 2 bits, 4 nice, and 8 is a waist, I have several applications that our USRP2 would be perfect for if we could get rid of bits in the FPGA, with out being FPGA programmers. From: discuss-gnuradio-bounces+bruce.stansby=postgrad.curtin.edu...@gnu.org [discuss-gnuradio-bounces+bruce.stansby=postgrad.curtin.edu...@gnu.org] on behalf of Marcus D. Leech [mle...@ripnet.com] Sent: Tuesday, 30 March 2010 1:10 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Considerations for new hardware in gnuradio On 03/29/2010 11:13 PM, George Nychis wrote: Short but sweet response. It would be great to have a SDR hardware board that works with GNU Radio that has a very, very, low latency connection to the host, like PCI express. Similar to the Microsoft Research SDR (previously named SORA). That would be great and open up possibilities of low latency MAC protocol implementations. Just sayin'! - George More bandwidth == definitely_better But IM(PNS)HO you don't want receiver cards living inside a PC cabinet. Which is why I like the USRP remote philosophy. I'm thinking about doing some hardware myself, for the specific purpose of radio astronomy: o integrated LNA/downconverter/sampler o common LO/sample-clock for all antenna o 1GiGE, probably using a compact (4-bit) coding to improve channel bandwidth This would appeal to only a small fraction of all Gnu Radio users, to be sure. But there are some themes that are common to other applications: o robust phase coherence (any kind of aperture synthesis requires this) o high bandwidth (sometimes at the expense of code bits) Fit in a tighter cost envelope. :-) -- Marcus Leech 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Making new block
Dear all, I learn about Writing A Signal Processing Block for GNU Radio. Then I run qa_howto.py. The result like this: Traceback (most recent call last): File ./qa_howto.py, line 24, in module import howto ImportError: No module named howto Therefore, does it mean that there is error during making new block? Thank you for your help Regards Makmur ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 firmware build error
On Tue, Mar 30, 2010 at 08:38:08AM +0200, Stefan Fehrle wrote: I wanted to build the USRP2 firmware to enable the testclk at J503, but I have some errors. I download the source with the command git clone git://gnuradio.org/gnuradio and the mb-gcc from http://gnuradio.org/tools/ Then I execute the commands ./bootstrap and ./configure.gnu MB_GCC=/usr/local/bin/microblaze/bin/mb-gcc. I have no errors or warnings. Then I execute the command make and I have the following errors: If you're building from the firmware directory you must use: # If in firmware directory ./boostrap ./configure.gnu This will get you the correct compiler. If you build the host code and the firmware from the top of the build, you only need to do # If at top of build tree ./bootstrap ./configure r...@thinkpad-kubuntu:/usr/local/src/gnuradio/usrp2/firmware# make make all-recursive make[1]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware' Making all in config make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/config' Making all in include make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/include' Making all in lib make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/lib' gcc -DHAVE_CONFIG_H -I. -I.. -DHAL_IO_USES_UART -I../include -I../lib --std=gnu99 -Wall -Werror-implicit-function-declaration -mxl-soft-div -msoft-float -mxl-soft-mul -mxl-barrel-shift -O2 -MT abort.o -MD -MP -MF .deps/abort.Tpo -c -o abort.o abort.c cc1: error: unrecognized command line option -mxl-soft-div cc1: error: unrecognized command line option -mxl-soft-mul cc1: error: unrecognized command line option -mxl-barrel-shift make[2]: *** [abort.o] Error 1 make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware' make: *** [all] Error 2 r...@thinkpad-kubuntu:/usr/local/src/gnuradio/usrp2/firmware# I use Kubuntu 9.04 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Making new block
On Tue, Mar 30, 2010 at 05:27:28PM +1030, Makmur Hidayat wrote: Dear all, I learn about Writing A Signal Processing Block for GNU Radio. Then I run qa_howto.py. The result like this: Traceback (most recent call last): File ./qa_howto.py, line 24, in module import howto ImportError: No module named howto Therefore, does it mean that there is error during making new block? Thank you for your help Regards Makmur The QA code only works if you use $ make check Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 250MHz signal generation using Basic TX
Thank you Josh, Appreciate if you through a light on the instructions for using the external clock for the usrp board Thanks Regds, Sudhir. On Tue, Mar 30, 2010 at 9:38 AM, Josh Blum j...@joshknows.com wrote: On 03/29/2010 08:11 PM, S'dir wrote: Hi, Greetings. I have an USRP Rev-4.5 board, which contains two daughter boards, Basic TX and BasicRX. According to the TX and RX Daughterboards data sheet, the TX daughter board is capable of generating up to 1 MHz to 250 MHz signal. I am unable to generate transmit signal more than 44MHz using the usrp_siggen.py program which comes with the Gnu Radio software development kit to generate the Transmit signal. The DAC rate is 128 Msps. Technically, you cannot have frequencies above the nyquist rate of 64 MHz. The basic tx relies on aliasing to get anything above that rate. Take a look on a spectrum analyzer when transmitting, you should see the signal and its aliases. -Josh ___ 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] can't open usrp
Hi, Are you working with Linux ? If so, try to run sudo wbfm_receive or sudo usrp_probe to test the presence of usrp. sumol wrote: Hi all, I am doing my project work in SDR for sensor data collection. I have installed gnu radio 3.2 version.While running wbfm_receive in examples im meeting one run time error as follows: usrp: failed to find usrp[0] Traceback (most recent call last): File /home/susane/gnuradio-3.2/grc/examples/usrp/usrp_wbfm_receive.py, line 180, in module tb = usrp_wbfm_receive(options) File /home/susane/gnuradio-3.2/grc/examples/usrp/usrp_wbfm_receive.py, line 129, in __init__ self.usrp_simple_source_x = grc_usrp.simple_source_c(which=0, side=B, rx_ant=RXA) File /usr/lib/python2.6/dist-packages/grc_gnuradio/usrp/simple_usrp.py, line 47, in __init__ else: self._make_usrp(which=which, nchan=1) File /usr/lib/python2.6/dist-packages/grc_gnuradio/usrp/common.py, line 28, in _make_usrp def _make_usrp(self, *args, **kwargs): self._u = self._usrp_args[0](*args, **kwargs) File /usr/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py, line 1646, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp please help me to solve this -- View this message in context: http://old.nabble.com/can%27t-open-usrp-tp28077947p28078493.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
Re: [Discuss-gnuradio] USRP2 firmware build error
Eric Blossom schrieb: On Tue, Mar 30, 2010 at 08:38:08AM +0200, Stefan Fehrle wrote: I wanted to build the USRP2 firmware to enable the testclk at J503, but I have some errors. I download the source with the command git clone git://gnuradio.org/gnuradio and the mb-gcc from http://gnuradio.org/tools/ Then I execute the commands ./bootstrap and ./configure.gnu MB_GCC=/usr/local/bin/microblaze/bin/mb-gcc. I have no errors or warnings. Then I execute the command make and I have the following errors: If you're building from the firmware directory you must use: # If in firmware directory ./boostrap ./configure.gnu This will get you the correct compiler. If you build the host code and the firmware from the top of the build, you only need to do # If at top of build tree ./bootstrap ./configure r...@thinkpad-kubuntu:/usr/local/src/gnuradio/usrp2/firmware# make make all-recursive make[1]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware' Making all in config make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/config' Making all in include make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/include' Making all in lib make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/lib' gcc -DHAVE_CONFIG_H -I. -I.. -DHAL_IO_USES_UART -I../include -I../lib --std=gnu99 -Wall -Werror-implicit-function-declaration -mxl-soft-div -msoft-float -mxl-soft-mul -mxl-barrel-shift -O2 -MT abort.o -MD -MP -MF .deps/abort.Tpo -c -o abort.o abort.c cc1: error: unrecognized command line option -mxl-soft-div cc1: error: unrecognized command line option -mxl-soft-mul cc1: error: unrecognized command line option -mxl-barrel-shift make[2]: *** [abort.o] Error 1 make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware' make: *** [all] Error 2 r...@thinkpad-kubuntu:/usr/local/src/gnuradio/usrp2/firmware# I use Kubuntu 9.04 I did this but it dosen't solve the problem of executing the command make -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 firmware build error
On Tue, Mar 30, 2010 at 12:05:25PM +0200, Stefan Fehrle wrote: Eric Blossom schrieb: On Tue, Mar 30, 2010 at 08:38:08AM +0200, Stefan Fehrle wrote: I wanted to build the USRP2 firmware to enable the testclk at J503, but I have some errors. I download the source with the command git clone git://gnuradio.org/gnuradio and the mb-gcc from http://gnuradio.org/tools/ Then I execute the commands ./bootstrap and ./configure.gnu MB_GCC=/usr/local/bin/microblaze/bin/mb-gcc. I have no errors or warnings. Then I execute the command make and I have the following errors: If you're building from the firmware directory you must use: # If in firmware directory ./boostrap ./configure.gnu This will get you the correct compiler. If you build the host code and the firmware from the top of the build, you only need to do # If at top of build tree ./bootstrap ./configure r...@thinkpad-kubuntu:/usr/local/src/gnuradio/usrp2/firmware# make make all-recursive make[1]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware' Making all in config make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/config' Making all in include make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/include' Making all in lib make[2]: Entering directory `/usr/local/src/gnuradio/usrp2/firmware/lib' gcc -DHAVE_CONFIG_H -I. -I.. -DHAL_IO_USES_UART -I../include -I../lib --std=gnu99 -Wall -Werror-implicit-function-declaration -mxl-soft-div -msoft-float -mxl-soft-mul -mxl-barrel-shift -O2 -MT abort.o -MD -MP -MF .deps/abort.Tpo -c -o abort.o abort.c cc1: error: unrecognized command line option -mxl-soft-div cc1: error: unrecognized command line option -mxl-soft-mul cc1: error: unrecognized command line option -mxl-barrel-shift make[2]: *** [abort.o] Error 1 make[2]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/gnuradio/usrp2/firmware' make: *** [all] Error 2 r...@thinkpad-kubuntu:/usr/local/src/gnuradio/usrp2/firmware# I use Kubuntu 9.04 I did this but it dosen't solve the problem of executing the command make Sorry, try this: $ export PATH=/usr/local/bin/microblaze/bin:$PATH $ ./bootstrap ./configure.gnu $ make Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Considerations for new hardware in gnuradio
Per- If we had an fpga image that allowed us to store samples on the USRP2 that would be very benefitial, at least for me. Then one could test algorithms with 100MHz sample-rate. Yes, it would not be possible to use the channel continously. Receiving 1ms of samples would take 4ms to upload. However, using the time-stamp functionality one can synchronize nodes to transmit and receive at the same time and thereby enable testing e.g. interference rejection algorithms. How many samples? I think the USRP2 has a 512k x 16 (1 Mbyte) SRAM that's not used in the default FPGA image. -Jeff Quoting George Nychis gnyc...@cmu.edu: Short but sweet response. It would be great to have a SDR hardware board that works with GNU Radio that has a very, very, low latency connection to the host, like PCI express. Similar to the Microsoft Research SDR (previously named SORA). That would be great and open up possibilities of low latency MAC protocol implementations. Just sayin'! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 250MHz signal generation using Basic TX
http://gnuradio.org/redmine/wiki/gnuradio/USRPClockingNotes On 03/30/2010 01:09 AM, S'dir wrote: instructions for using the external clock for the usrp board ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Firmware Changes nt working properely ???
Hi i am trying to synchronize two USRP2's to the reference clock 10MHz. as per the discussions i found in the internet i have added clocks_mimo_config(MC_WE_LOCK_TO_SMA); just before the while(1) loop in txrx.c and then i have compiled the code to create txrx.bin But when i burn this txrx.bin with the downloaded u2_rev3.bin from the trunk(gnuradio website). The USRP2 is booting up all fine(6 LED's flash once and 2 LED's remain). but when connected to PC , it shows USRP2 not found. to cross verify i also downloaded txrx.bin from the trunk in gnuradio website and burnt the SD card with u2_rev3.bin. USRP2 again boots up properely , and the USRP2 is detectable in the PC (./find_usrps) But when i compile the firmware code and burn, the USRP2 boots properly , but does not connect to the PCI don't know why ??? Can somebody help me out here ? am i missing anything ? I compiling the firmware directory in the gnuradio3.2.2/usrp2/firmware the compiled txrx.bin is 28KB and the downloaded txrx.bin is 25.6KB Thanks KRISHNA S The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] questions on DDC in FGPA configuration
Dear all, I'm reading the receiver part of gr-sounder project. As my undering, in the FPGA configuration of this project, the received signal directly goes to the sounder module, after being demuxed into I and Q signals by adc_interface module. I didn't see any module of the FPGA configuration of this project implments DDC. In python program, however, it has been set the tunning frequency for sounder receiver. Which part of the receiver tunning frequency will set to in the FPGA configuration? Which part of the FPGA configuration implements DDC? Thank you so much in advance. Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] interfacing a DSP array card to USRP2
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? Is it reasonable we can reduce buffer sizes if the array card GbE has a fast response time? 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. 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? Thanks. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Feedback between Blocks
Johnathan Corgan-2 wrote:
Shyamnath wrote:
I am trying to incorporate a few modifications to the DBPSK
implementation in gnuradio for which I need to implement feedback
between the different signal. So my question, is there a clean way to
implement feedback between the different signal processing blocks.
More specifically if my flow graph is BLOCK1 -- BLOCK2 - BLOCK3 and
I want to have a feedback from block3 to block1 is it possible? I am
interested in feedback of a flag bit.
There are a few ways you can do this, depending on how frequently you
need to update the value of this flag.
As you mentioned, you can create a shared variable and pass a reference
to this to your blocks. You'll need to write your own blocks, however,
in order to add the code in the 'work' function that acts on the flag
value.
You'll need to protect your shared data with a mutex or other
synchronization primitive, as there is no guarantee that the work
functions of your blocks will run in the same thread. (Currently they
do; this will definitely change in the future.)
But there is still no guarantee how frequently the work functions will
get called by the flow graph scheduler, so there could be an arbitrary
delay between setting the flag in one block and the opportunity for
another block to act upon the changed value.
If you only need to update the value infrequently, you can instead do it
from a custom thread from within Python. For example, from a custom
thread, you can wake up once a second, call a read method on one block
to get the flag value, then call a method on the other block to set it.
There are variations of the above but we'd need to know more about what
you're trying to accomplish.
--
Johnathan Corgan
I am also interested in an answer to this question. I do not fully
understand the flow graph thread/process dispatching/scheduling process in
gnuradio for streams of data. From Jonathan's statements, It seems as
though 'chunks' of data are processed using the user-defined-in-python chain
of software routines.
There is little/no user-code control of the chunk size or frequency with
which those chunks get passed between routines. Is this correct? Also, it
seems like flow graph scheduling is only done in Python, not C++, right?
I want to do what Shyamnath is trying to do, at a fairly high refresh rate
(e.g. the feedback flag is asserted for *each* received packet; with ~1ms
granularity???). Perhaps the 'custom thread' approach suggested by Jonathan
would work this fast - I'll try it out - although it seems a bit inefficient
(e.g. polling instead of interrupting). Are there 'tags'/timestamps on data
samples that I can use? Has someone else implemented something similar
already?
I have seen discussions in the forum about timestamping/tagging of data
samples for the USB interface. However, I need these tags to make it right
through 'Block 1' and on through 'Block 2' to 'Block 3'. The objective is
to be able to use the feedback signal to 'note' the specific upstream raw
samples that are associated with a particular detected downstream valid
packet. I searched but didn't see anything like this in the gnuradio source
code, but maybe someone can point me towards something similar that I might
have overlooked.
System time in Block 1 and Block 3 could be used for time-stamping, but it
sounds as though this won't really help me ('no guarantee' on the execution
times for the different blocks by the flow graph scheduler). I could also
implement a parallel tagging path too. Based on the comments above, it
seems like the flow graph scheduler will not 'guarantee' that this parallel
path is handled consistently/synchronously with the data samples path
either. Which is the better approach?
I don't care about absolute real-time delay or jitter in the processing of
samples, but I don't want to incorrectly map a set of raw samples to the
wrong decoded packet-level data. I also need to be able to handle sequences
of received packets that occur 'close together' in time. Not detecting a
packet is preferred to losing track of this 'identity' correspondence
because of gnuradio flow-graph scheduler-related asynchronous operation.
Unfortunately, I *am* definitely interested in data that occurs at or near
the same time; this is so I can try and dial out some of the RF channel
time-variant fading effects in my analysis. Therefore, losing packets in
this way should be a rare event. Given this, what is the best approach?
In other news, I'd also really like to know the correspondence between ADC
samples and the exact time that they occurred (this is pretty well
timestamping, straight up). Maybe there is a Rx-clock based counter in the
FPGA that can be read... synchronously with data Does anyone know of an
FPGA load which has this functionality?
Any suggestions/guidance would be appreciated.
/ David Knox
--
View this message in context:
RE: [Discuss-gnuradio] running OFDM on USRP2
I have been inactive on this for some time due to other issues with my USRP2s. However, I have been able to look into this again now, with Veljko's modified code. I run as root, and also had the realtime scheduling enabled, however on the receive side I see nothing until the transmitter stops transmitting, at which time I see timeout. This seems to be the same problem that Bin had (except without the realtime scheduling issue). Bin, did you end up resolving this issue? Cheers Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Tom Rondeau Sent: Thursday, 4 February 2010 11:56 PM To: bin zan Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 On Wed, Feb 3, 2010 at 1:55 PM, bin zan zanbin2...@gmail.com wrote: Hi Tom, In our case, even with script from Veljko, the OFDM receiver doesn't show any thing. And we always see usrp2: failed to enable realtime scheduling. Do you think that will cause problem? Thanks, Bin No, that message is just telling you that you don't have permissions to run it at the highest priority. It means you won't be able to run as fast, but that shouldn't be the cause of your problems. Tom ___ 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
