[Discuss-gnuradio] Lost a byte of data
Hi all, I have been using gnuradio to receive the data from the front end hardware. I have made a file sink to see the data. And the data pattern seems to lose a byte , and this occurs every 1024 bytes. I think the software reads 16KB of data but the error comes ever 1KB. I am using a SSRP module to interface with the hardware, in Ubuntu Gutsy. I have attached the portion of the file where the change occurs. The unexpected byte error comes at 5113444. 5113360 f887 fd25 f80b fd26 f8ad fdaf f819 fcd0 5113400 f83b fd29 f858 fd3f f80b fd7b f8d2 fe23 5113420 f92a fd6d f7a8 fd83 f89f fd2e f800 fd2c 5113440 f8a3 fd7f d700 41f7 0bfd aff8 85fd adf8 5113460 9afd 96f8 35fc aaf8 7cfcbff8 effd f5f7 5113500 5afc 93f8 6cfd 5ff8 c9fd 1ef8 4ffd 21f8 Any suggestion is of great help. Fasika - Looking for last minute shopping deals? Find them fast with Yahoo! Search.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bus widths and data rates
Hello, I have been trying to understand the tx and rx data paths through the AD9862 and the FPGA (standard configuration). RX side: - The two ADCs of the AD9862 push data onto two 12 bit buses - After the FPGA MUX the 16 bit I/Q signals pass into the assigned DDC - Are four extra bits assigned to the received I/Q when they arrive onto the FPGA? TX side: - The 16 bit I/Q signals pass into the FPGA demux and arrive at the appropriate AD9862 chip - I/Q signals arrive interleaved on a 14 bit bus into the AD9862 - Are the I/Q signals truncated by 2 bits before they are sent onto the 14 bit bus? Thanks, Tomas -- View this message in context: http://www.nabble.com/Bus-widths-and-data-rates-tp15145586p15145586.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] Bus widths and data rates
On Jan 30, 2008 9:35 AM, TomasOMaille [EMAIL PROTECTED] wrote:
Hello,
I have been trying to understand the tx and rx data paths through the AD9862
and the FPGA (standard configuration).
RX side:
- The two ADCs of the AD9862 push data onto two 12 bit buses
- After the FPGA MUX the 16 bit I/Q signals pass into the assigned DDC
- Are four extra bits assigned to the received I/Q when they arrive onto
the FPGA?
Pretty much. In the DC offset removal process, they are assigned on
input. Here is where it happens:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/adc_interface.v#L34
You can see that the input of the rx_dcoffset module is assigned:
.adc_in({adc0[11],adc0,3'b0})
Which is a 1 bit sign extension, the 12 original bits, then 3 bits of 0's.
TX side:
- The 16 bit I/Q signals pass into the FPGA demux and arrive at the
appropriate AD9862 chip
- I/Q signals arrive interleaved on a 14 bit bus into the AD9862
- Are the I/Q signals truncated by 2 bits before they are sent onto the 14
bit bus?
Yes, as can be seen here:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/toplevel/usrp_std/usrp_std.v#L179
Whatever 16-bits are coming from the tx_chain module is truncated by
2-bits and sent out the DACs.
Brian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question: using gr_float_to_complex
Should Rx1 be a vector_source_f rather than a vector_sink_f? -Steven On Jan 29, 2008 10:17 PM, Jonas [EMAIL PROTECTED] wrote: Hi everyone! I have this problem with using gr_float_to_complex. I wanted to connect two sptr types wherein one contains floats while the other is an sptr type of gr_float_to_complex. Unfortunately, I always get an error message saying 'port number out of range.' What should I do? Sample Code: Rx1 (class 'gnuradio.gr.gnuradio_swig_py_gengen.gr_vector_sink_f_sptr') # contains the float data Rx1_comp = gr.float_to_complex() fg_Rx1_comp = gr.flow_graph() fg_Rx1_comp.connect(Rx1,Rx1_comp) # I get error messages here saying that 'port number out of range' Thanks! :) ___ 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] Bus widths and data rates
Thanks Brian, That clears up a lot in my head. My Verilog knowledge is pretty primitive at this point. Tomas O'Maille ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-sounder tx and rx results
On 1/30/08, Dev Ramudit [EMAIL PROTECTED] wrote: Not sure if you've had a chance to take a look at this yet. I've been trying to figure out what's going on, but even with Martin's advice I still havent had much luck. Could you tell me what the slip rate is on the sliding correlator? Whenever you have some free time. Martin's description of the issue is very accurate. Due to frequency offset, the impulse response peaks do not come at the proper intervals. What is worse, is that the algorithm in the FPGA is using an n-squared algorithm to calculate the impulse response, so it is extremely sensitive to frequency offset. You can adjust the frequency manually on either side to accomodate, but simple drift will soon cause the clocks to diverge. You may also be able to post-process the impulse response records by estimating the frequency offset using an FFT and then resampling/interpolating them to the proper time base. Unfortunately, the only true way to correct this is with a PLL on the receive side, inside the FPGA, after the despreading occurs. Fortunately, I am developing one of these as part of another project. This is a direct sequence spread spectrum transceiver, and is really a superset of and replacement for gr-sounder. With the proper frequency and PN-code phase locked loops, you will be able to get channel impulse responses with much greater accuracy than the open-loop gr-sounder code does today. I normally wouldn't have announced this until there was working code people could try out. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Interest in beamforming and GNSS receivers
Hi everybody, I discovered GNU Radio few months ago, in a before-go-to-bed surfing. I found it very interesting, but complicated because of my poor skills in programming Python or C++. I'm doing research on Global Navigation Satellite Systems (GNSS) receivers, and I'm used to code everything in Matlab. Night after night, I've been browsing the documentation and making humble steps: I installed Ubuntu on my laptop, followed the -excellent, also for dummies like me- guide for installing all the software, read diagonally the documentation and played with sample codes. Some Hello Worlds, some problems with the audio module, getting used to read the mailing list, feeling astonished by the intense activity of this community... nothing new, I guess. Now I want to take it more seriously. I've seen that both python and c++ have very well done matrix algebra libraries, and that's exactly what I need for my research (you can call me naive). I would like to implement a GNSS receiver (in the wide sense) based on an antenna array and play with beamforming algorithms and weird RF front-end architectures (direct RF, IF sampling, etc). My main concern is synchronization, concretely I want to implement some signal processing algorithms in a real receiver in order to assess their impact in the whole system, testing them with real data. I've been working in the development of some algorithms that -theoretically- performs better in multipath environments, but I want to see if this is true beyond classical academic benchmarks. What is the state of GNSS receivers development in GNU Radio? I have found some expressions of interest in the Internet, but nothing concrete. I'm willing to start it from the scratch, but it is nonsense to reinvent the wheel. I would like to put in contact with other people interested on these topics. Taking advantage of your patience, I have some other questions (and you will see my newbie approach): - I've seen some statements about beamforming is possible. To what extend? I'm trying to understand the multi-antenna code example, but it is possible to use the four ADC at the same time? How well are they synchronized? it is possible to compute the weight values in software and perform the multiplication in the FPGA at real time? There is any other major bottleneck than algebraic weight computation time? - My first target is a traditional L1 C/A code GPS receiver. I guess that I can choose between RFX1200 and a BasicRx with an external front-end. Have someone worked in the connection of GNU Radio with gpstk? - It is 32 MHz the maximum bandwidth available? Will the USRP 2.0 increase this bandwidth? It is possible to decrease the resolution of the ADCs and/or increase their sampling frequency? - I also would like to work on the Galileo signal structure and the new L2CS GPS signal, mostly on the correlators. I have a background on signal processing, but I'm strongly matlab-shaped in what about programming is concerned. I'm willing to learn, but am I pointing to the right direction? If someone could enlighten me in some of this questions, it would be greatly appreciated. Sorry for the long text. Best regards, Carles Fernandez ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP underruns when attempting simultaneous receive and transmit
Hi All, summary: If I try and receive and transmit data from and to the USRP simultaneously at the same data rate (no matter what it is, even as low as 2MB/s each way) I always get usrp underruns. Background * I have a simple cross band repeater type example running under Gnuradio 3.1.1. Basically I have configured an RFX400 to receive an FM type modulated signal on one frequency (452.75MHz) and retransmit that same signal either as complex baseband to an LFTX daughterboard, or an RF signal at another frequency (440MHz) by the RFX400. Currently this involves simultaneous reception and transmission of data across the USB2.0 interface. I've typically been using usrp_decim values of 128 (i.e500Ks/s, complex = 2MB/s), and usrp_inter of 256, again giving a nominal data rate to the usrp of 2MB/s. I have verified the USB2.0 simplex performance of my PC (Pentium D 2.8GHz, 1GB RAM) by running standard gnuradio scripts such as usrp_fft.py for testing the data throughput to the PC. I was able to set the decimation rate of the fft scope to 8 (giving 8MS/s, complex, I assume = 32MB/s) without any usrp over runs reported.Decimation value below 8 start giving usrp over runs, as expected. On the PC to USRP side: I've used usrp_siggen.py to generate a sine wave on the PC and output it from the LFTX daughterboard. I kep reducing the usrp interpolation rate until I started to see under runs reported. This happened at an a value of 12, at 14 it was OK. I was expecting 16 would be my lower limit (128MS/s / 16 = 8MS/s = 32MB/s over usb2.0) but it would appear my PC USB controller is slightly better at sending data than receiving. Anyway, to get to the point. If I try and receive and transmit data simultaneously at the same data rate (no matter what it is, even 2MB/s) I always get usrp underruns. Questions *** 1) Do others see the same thing? 2) Is this because any buffering that's going at the PC end is insufficient to smooth out any slight differences in actual receive and transmit data rates, leading to the occasional starving of the USRP's usb receive buffers? 3) If I configure my application to receive samples from the usrp at a lower rate than I retransmit them (using the rational resampler to interpolate) this significantly reduces any under run's reported. Is this the generally used method to get around this particular issue? 4) Is it possible to configure the USRP to directly pass samples from the receive to the transmit, bypassing the PC altogether? Could be useful to me as a basic RF passband to complex baseband, cutting out PC latencies. Thanks in advance for your responses. Cheers Richard === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interest in beamforming and GNSS receivers
Carles Fernandez wrote: Hi everybody, I discovered GNU Radio few months ago, in a before-go-to-bed surfing. I found it very interesting, but complicated because of my poor skills in programming Python or C++. I'm doing research on Global Navigation Satellite Systems (GNSS) receivers, and I'm used to code everything in Matlab. Night after night, I've been browsing the documentation and making humble steps: I installed Ubuntu on my laptop, followed the -excellent, also for dummies like me- guide for installing all the software, read diagonally the documentation and played with sample codes. Some Hello Worlds, some problems with the audio module, getting used to read the mailing list, feeling astonished by the intense activity of this community... nothing new, I guess. Now I want to take it more seriously. I've seen that both python and c++ have very well done matrix algebra libraries, and that's exactly what I need for my research (you can call me naive). I would like to implement a GNSS receiver (in the wide sense) based on an antenna array and play with beamforming algorithms and weird RF front-end architectures (direct RF, IF sampling, etc). My main concern is synchronization, concretely I want to implement some signal processing algorithms in a real receiver in order to assess their impact in the whole system, testing them with real data. I've been working in the development of some algorithms that -theoretically- performs better in multipath environments, but I want to see if this is true beyond classical academic benchmarks. What is the state of GNSS receivers development in GNU Radio? I have found some expressions of interest in the Internet, but nothing concrete. I'm willing to start it from the scratch, but it is nonsense to reinvent the wheel. I would like to put in contact with other people interested on these topics. Taking advantage of your patience, I have some other questions (and you will see my newbie approach): - I've seen some statements about beamforming is possible. To what extend? I'm trying to understand the multi-antenna code example, but it is possible to use the four ADC at the same time? Yes. How well are they synchronized? They run off the same 64 MHz clock, so are synchronised. I have even used two connected USRPs running of the same clock (one is master and exports its clock to the slave USRP) (You use an additional flatcable between the USRPS and an align software block in gnuradio which aligns the samples) This gives you 8 ADCs. This means 8 real channels or 4 complex channels. I used this setup for a phase array with 4 DBSRX daughterboards. (DBSX daughterboards use complex sampling so they need two ADCs) DBSRX boards also support the GPS frequencies and are a lot cheaper, so you might want to consider them. But they are receive only. You can even go higher and connect 4, 8 or 16 USRPS. it is possible to compute the weight values in software and perform the multiplication in the FPGA at real time? You could do that, but that means extra multipliers in the FPGA, which take up resources. You could also do the multiplication in software, but then you have several datastreams from the USRP (which could saturate the USB connection when using a high datarate). (You can do maximal 4 receive streams from the USRP) There is any other major bottleneck than algebraic weight computation time? You have to make sure the LO's from the frontends are synchronised. This is the case with the RFX1200. It uses the USRP clock as reference. You also might need a more stable and/or precise (external) clock. the current clock is 15 ppm (from the top of my head). I don't know the exact phase-noise figures. You also might need to put good low-noise LNAs in front of the RFX1200 or the DBSRX. - My first target is a traditional L1 C/A code GPS receiver. I guess that I can choose between RFX1200 and a BasicRx with an external front-end. Have someone worked in the connection of GNU Radio with gpstk? - It is 32 MHz the maximum bandwidth available? In theory you could have 64 Mhz bandwidth when using complex sampling (the RFX1200 does this). This uses two ADCs for one frontend (one for the I and one for the Q channel) Your frontend must support this analog bandwidth of course. The RFX1200 has filtering which limits the bandwidth to about 25 MHz. You could change the filtering to widen it. This is a bit dangerous however because any remaining signals outside the 64 MHz band will fold around the niquist freq. This 64 MHz bandwidth is not transportable to the host PC with the current supported resolutions (8 bit and 16 bit) You have a maximum USB throughput of 32 MByte/sec. Which means 8 Mhz bandwidth with 16 bit resolution and 16 MHz bandwidth with 8 bit resolution. When you implement verilog code to reduce the resolution to 4 or 2 bit you would have 32 or 64 MHz bandwidth, but only for a single channel. When you implement the despreading in
Re: [Discuss-gnuradio] Shielding on 2.4GHz
DiX wrote: Hi everyone, I am using FLEX2400 d'boards to transmit and receive 802.11b packets with codes from bbn and gnuradio_example/python/digital. The problem is the d'board is always interferenced by some CISCO access points and other wireless cards located right outside of my lab. I connect the usrp to my pc with a cable (-30db attenuator applied). I hope it receives nothing but packets from my pc. But the d'board can still get packets from other wireless card. Then I put the m'b and d'b into the black enclosure. Packets still come in. And finally, I put everything (m'b, d'b, black box, attenuator) in my metal drower. Most packets are shielded out. Some still can be caputured and demodulated.%-| why is the d'b able to hear others even when I connect attenuators and cable to its antenna? -DX It might pick it up on the 6V power cable. You could try putting ferrite beads around the power cable to reduce this. greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio C++ engineer wanted
I hope no one minds me putting this up here: Path Intelligence Ltd is a multiple award winning start-up company, whose most recent achievement is winning the UK SEEDA Enterprise Hub Showcase event, ahead of more than fifty other innovative start-ups from Oxford and the broader South East region. Although our operations have been historically based in the UK we are looking to broaden into other territories (particularly the US as we have recently closed a round of funding with a Silicon Valley based VC). As a Principal Engineer, you will: o Re-architect the system to prepare for upcoming enhancements o Optimize the existing C++ code base o Assist the existing management team to continue to build the technical team both in the UK and the US o Work closely with the CEO to complete product development and implement new research initiatives o Help shape the future of Path Intelligence Ltd o Work with a young, energetic and ambitious team o Receive an attractive remuneration package The following skills are essential: o Expert C++ skills o Solid understanding of RF o Ability to formally communicate architectural designs and plans o Proven team working experience, within teams consisting of both technical developers and non-technical project/business owners (experience in working with remote teams a bonus) o Experience integrating open source technologies in application development o Proven problem solving skills o Self Starter Desired skills: o Proficiency in Python o Knowledge of RF location techniques o Experience in working on software defined radio projects and/or Gnuradio o Knowledge and experience with RF and FPGA hardware development About Path Intelligence: Path Intelligence has developed an innovative product using software defined radio, that is able to locate mobile phones highly accurately within a confined area. In the first instance Path Intelligence is using this technology to provide shopping centres and mass transit stations with information on people flow through their space. However, this is just the tip of the iceberg of what is possible with this technology and Path Intelligence has plans to move into many different industries, applications and geographies. Path Intelligence has recently concluded a funding round with a Silicon Valley venture capital firm that focuses on leading edge technologies and plans to aggressively expand into the US and Europe in the near future. At Path Intelligence, our goal is to provide the most timely and accurate location information available.To that end, we strive very hard to hire the smartest people. We’re an environment where great ideas shape our vision and true passion drives us to the best solutions to the most challenging problems. Salary: Competitive + Benefits, with the potential for equity Location: UK/US Contact: Sharon Biggar ([EMAIL PROTECTED]) Reference: GNUPATHCP ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP underruns when attempting simultaneous receive and transmit
On Thu, Jan 31, 2008 at 01:50:32PM +1300, Richard Clarke wrote: Hi All, summary: If I try and receive and transmit data from and to the USRP simultaneously at the same data rate (no matter what it is, even as low as 2MB/s each way) I always get usrp underruns. Which operating system and distribution are you using? Questions *** 1) Do others see the same thing? Haven't tried. 2) Is this because any buffering that's going at the PC end is insufficient to smooth out any slight differences in actual receive and transmit data rates, leading to the occasional starving of the USRP's usb receive buffers? You're running the two daughterboards (the rx and tx) on a single USRP, right? In that case, the input and output rates will be locked to the same clock. If you're running under Linux, I'd try specifying the fusb buffering parameters in the usrp.source_c and usrp.sink_c constructors. Use identical values on the source and sink. E.g., fusb_block_size = 4096# must be a multiple of 512 fusb_nblocks = 4 src = usrp.source_c(0, decim, fusb_block_size=fusb_block_size, fusb_nblocks=fusb_nblocks) ... dst = usrp.sink_c(0, interp, fusb_block_size=fsub_block_size, fusb_nblocks=fusb_nblocks) and I'd enable realtime scheduling (you'll need to be root or holding CAP_SYS_NICE): # Attempt to enable realtime scheduling r = gr.enable_realtime_scheduling() if r == gr.RT_OK: realtime = True else: realtime = False print Note: failed to enable realtime scheduling for the simplest test case, just connect the sink and source together and see how that works. No mod or demod, cat IF-in IF-out fg.connect(src, dst) 3) If I configure my application to receive samples from the usrp at a lower rate than I retransmit them (using the rational resampler to interpolate) this significantly reduces any under run's reported. Is this the generally used method to get around this particular issue? No. You want the input and output rates exactly the same. 4) Is it possible to configure the USRP to directly pass samples from the receive to the transmit, bypassing the PC altogether? Could be useful to me as a basic RF passband to complex baseband, cutting out PC latencies. This is possible, but to my knowledge no one has written the verilog to do it. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP underruns when attemptingsimultaneousreceive and transmit
OK thanks Eric. I should have mentioned I was using Ubuntu 7.10. My application was effectively just passing the samples from the USRP Rx to the USRP Tx via the PC, no actual demod/remod going on. I'll try your suggestions regarding fusb buffering parameters and see if that makes a difference. Thanks again. Cheers Richard === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP underruns when attemptingsimultaneousreceive and transmit
Hi, I wrote a USRP based RF Repeater code http://www.nabble.com/file/p15199195/repeater.py.tar.gz repeater.py.tar.gz before may be 8 months which is connecting source-Destination in IF level. Although the input parameters should be entered by hand and not from the command line, the code was working at that time perfectly on ubuntu 7.04 and I think it will work on 7.10. It frequency translates any 4MHZ RF bandwidth from any frequency to any frequency (tunable by the connected USRP daughter baords) using two USRP daughter boards. Dear Eric , Jonhathan : Is it possible to add this code to gnuradio-examples ? Regards, Firas -- View this message in context: http://www.nabble.com/USRP-underruns-when-attempting-simultaneous-receive-and-transmit-tp15195921p15199195.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] Interest in beamforming and GNSS receivers
Hi all, I have an interest in radioastronomy. I plan to make simple beamforming phase array (primary with 4 and later with 8 antennas) with USRP (later with 2) and GNU Radio. I am inspired by LOFAR radiotelescope. Now I collect all available information about using GNU Radio and USRP for it. Martin, could you send more information about your solution, project (url etc.) ? Thanks, Pavol PS: I haven't USRP yet. However, I am buying my first USRP, right now :) Martin Dvh wrote: Carles Fernandez wrote: How well are they synchronized? They run off the same 64 MHz clock, so are synchronised. I have even used two connected USRPs running of the same clock (one is master and exports its clock to the slave USRP) (You use an additional flatcable between the USRPS and an align software block in gnuradio which aligns the samples) This gives you 8 ADCs. This means 8 real channels or 4 complex channels. I used this setup for a phase array with 4 DBSRX daughterboards. (DBSX daughterboards use complex sampling so they need two ADCs) DBSRX boards also support the GPS frequencies and are a lot cheaper, so you might want to consider them. But they are receive only. You can even go higher and connect 4, 8 or 16 USRPS. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
