Re: [Discuss-gnuradio] A few questions about subclassing gr_block

2013-05-03 Thread Martin Braun (CEL) 
On Fri, May 03, 2013 at 11:04:40AM +1200, Mark Cottrell wrote:
> I am trying to create a block that detects sync patterns at baseband tagging
> the first sample of the pattern using stream tags, then using the tags down

That's the correct way to do it, if you ask me.

Just to clarify: Before you get a sync pattern, are you producing
anything? Or are your copying all of the input to the output, plus the
tag? If the latter is the case, you should use a sync_block.

> stream as part of demodulation.  I have made a few assumptions about how
> gnuradio works that I would like to validate:
> 
> - a sync pattern could span two blocks of samples passed to general_work

It depends on your sync pattern. If it's not too long, you can avoid
that.

> - I need to keep SYNC_PATTERN_LENGTH - 1 samples to get around this, so I
> should be able to use a general block and not output all of the items
> 
> - you can't tag historic samples (i.e. samples obtained using set_history), so
> I can't use that

You can also use 'future' samples to do signal processing. An example
are the peak_detector blocks, which find the beginning of a peak.

Simply don't consume them.

> Currently I have an implementation of the block, but I am having trouble
> understanding the relationship between ninput_items and noutput_items.  When I
> feed the block from a file source consisting of 720 samples, I get 
> ninput_items
> [0] = 720 and noutput_items = 512.  Does this value for noutput_items mean I
> can only consume and copy 512 of the input samples?  And do I need to 
> implement
> forecast if I want to output more?

That depends. Do you *really* want to output more? How many? What if
your have 1440 items at the input?

Basically, this is telling you there's space for 512 items in the output
buffer. If you can use a sync_block, you'll never run into these
problems, because there's only one value.

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpRQZT0phdvh.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A few questions about subclassing gr_block

2013-05-03 Thread Martin Braun (CEL) 
On Fri, May 03, 2013 at 09:08:34AM +0200, Martin Braun (CEL) wrote:
> > Currently I have an implementation of the block, but I am having trouble
> > understanding the relationship between ninput_items and noutput_items.  
> > When I
> > feed the block from a file source consisting of 720 samples, I get 
> > ninput_items
> > [0] = 720 and noutput_items = 512.  Does this value for noutput_items mean I
> > can only consume and copy 512 of the input samples?  And do I need to 
> > implement
> > forecast if I want to output more?
> 
> That depends. Do you *really* want to output more? How many? What if
> your have 1440 items at the input?
> 
> Basically, this is telling you there's space for 512 items in the output
> buffer. If you can use a sync_block, you'll never run into these
> problems, because there's only one value.

Also, there's lots of other functions to control the output buffer size,
e.g. set_output_multiple(), set_min_output_items()...

MB


-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpWUYSAgXfb7.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 4rx FPGA image issue

2013-05-03 Thread Nada ABDELKADER 

I'm using UHD 003.005.002-47-g4a860d74
I'm working on narrowband/tunnel.py. I changed the usrp_source call to  
create 4 channels, I added all necessary connections.
I made those changes with two channels using the default fpga image  
and it worked well.


mle...@ripnet.com a écrit :




On 02 May 2013 12:25, Nada ABDELKADER wrote:


I got the same

error!

What version of UHD are you using?

Can you forward to the list
a minimum .grc file that shows the problem?







This message was sent using IMP, the Internet Messaging Program.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build-gnuradio under Ubuntu 13.04

2013-05-03 Thread Alexandru Csete 
On Fri, May 3, 2013 at 4:37 AM, Marcus D. Leech  wrote:
>
> Has anyone experienced any build failures in UHD on Ubuntu 13.04 using
> build-gnuradio?
>
> I haven't upgraded my Ubuntu system yet, and I have had one report of a
> UHD build failure on Ubuntu 13.04
>   due to libboost1.49, but a manual upgrade to libboost1.53 cured it.

Hi Marcus,

I have installed both UHD and gnuradio on several xubuntu 13.04
computers having the default boost 1.49. No build issues and no
runtime issues, though haven't done much testing so far.

Alex

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error in Building UHD on Windows

2013-05-03 Thread Zooz Engineer 
Hi Marcus,

Please find attached the txt file with the warnings.

Cheers,

Zo



Date: Thu, 2 May 2013 11:18:59 -0700
From: ml-node+s4n41109...@n7.nabble.com
To: xtmpcvs...@hotmail.com
Subject: Re: Error in Building UHD on Windows



If everything works fine: Ignore them.

The first one seems interesting, but does not necessarily imply an

error.

(sometimes you really just want to check if a double is still

in initialized state, e.g. filled with zeros and therefore use it as a 

boolean; some compilers interpret that as cast to int)

However, could you point out the file that warning occurred, just to 

help check things for consistency?


Thanks,

Marcus Müller


Am 02.05.2013 10:42, schrieb Zooz Engineer:

> However, I have some 27 warnings in MSVC and I don't know how important

> they are:

>

> C4244: '=' : conversion from 'double' to 'uint32_t', possible loss of data

> C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)

> C4305: '=' : truncation from 'double' to 'float'

>

> Can they be fixed or I can just ignore them?

>

> Best,

> Zo


___

Discuss-gnuradio mailing list

[hidden email]

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio











If you reply to this email, your message will be added to the 
discussion below:

http://gnuradio.4.n7.nabble.com/Error-in-Building-UHD-on-Windows-tp41004p41109.html


To start a new topic under GnuRadio, email 
ml-node+s4n2...@n7.nabble.com 

To unsubscribe from GnuRadio, click here.

NAML

  Warning2warning C4244: '=' : conversion from 'double' to 'uint32_t', 
possible loss of dataC:\UHD\host\lib\usrp\dboard\db_tvrx2.cpp13121  
  uhd
Warning3warning C4244: '=' : conversion from 'double' to 'uint32_t', 
possible loss of dataC:\UHD\host\lib\usrp\dboard\db_tvrx2.cpp13141  
  uhd
Warning4warning C4244: '=' : conversion from 'double' to 'uint32_t', 
possible loss of dataC:\UHD\host\lib\usrp\dboard\db_tvrx2.cpp13271  
  uhd
Warning5warning C4244: '=' : conversion from 'double' to 'uint32_t', 
possible loss of dataC:\UHD\host\lib\usrp\dboard\db_tvrx2.cpp13291  
  uhd
Warning6warning C4244: '=' : conversion from 'double' to 'uint32_t', 
possible loss of dataC:\UHD\host\lib\usrp\dboard\db_tvrx2.cpp13431  
  uhd
Warning9warning C4244: '=' : conversion from 'std::streamoff' to 'int', 
possible loss of dataC:\UHD\host\utils\usrp_n2xx_simple_net_burner.cpp
1171usrp_n2xx_simple_net_burner
Warning10warning C4244: '=' : conversion from 'std::streamoff' to 
'int', possible loss of data
C:\UHD\host\utils\usrp_n2xx_simple_net_burner.cpp1511
usrp_n2xx_simple_net_burner
Warning11warning C4244: 'argument' : conversion from 'double' to 'const 
std::complex::_Ty', possible loss of data
C:\UHD\host\examples\txrx_loopback_to_file.cpp761
txrx_loopback_to_file
Warning12warning C4244: 'argument' : conversion from 'double' to 'const 
std::complex::_Ty', possible loss of data
C:\UHD\host\examples\txrx_loopback_to_file.cpp761
txrx_loopback_to_file
Warning19warning C4244: 'argument' : conversion from 'double' to 'const 
std::complex::_Ty', possible loss of data
C:\UHD\host\examples\tx_waveforms.cpp751tx_waveforms
Warning20warning C4244: 'argument' : conversion from 'double' to 'const 
std::complex::_Ty', possible loss of data
C:\UHD\host\examples\tx_waveforms.cpp751tx_waveforms
Warning22warning C4244: 'argument' : conversion from 'double' to 
'int64_t', possible loss of data
C:\UHD\host\examples\tx_samples_from_file.cpp1891
tx_samples_from_file
Warning1warning C4244: 'argument' : conversion from 'double' to 
'uint32_t', possible loss of dataC:\UHD\host\lib\usrp\dboard\db_tvrx2.cpp   
 10951uhd
Warning26warning C4244: 'argument' : conversion from 'time_t' to 
'unsigned int', possible loss of data
C:\UHD\host\examples\transport_hammer.cpp731transport_hammer
Warning27warning C4244: 'argument' : conversion from 'time_t' to 
'unsigned int', possible loss of data
C:\UHD\host\examples\transport_hammer.cpp1231transport_hammer
Warning13warning C4244: 'initializing' : conversion from 'double' to 
'float', possible loss of data
C:\UHD\host\examples\txrx_loopback_to_file.cpp1441
txrx_loopback_to_file
Warning15warning C4244: 'initializing' : conversion from 'double' to 
'float', possible loss of data
C:\UHD\host\examples\txrx_loopback_to_file.cpp1441
txrx_loopback_to_file
Warning17warning C42

Re: [Discuss-gnuradio] build-gnuradio under Ubuntu 13.04

2013-05-03 Thread Sean Nowlan 

On 05/03/2013 08:59 AM, Sean Nowlan wrote:

On 05/02/2013 10:37 PM, Marcus D. Leech wrote:

Has anyone experienced any build failures in UHD on Ubuntu 13.04 using
build-gnuradio?

I haven't upgraded my Ubuntu system yet, and I have had one report of a
UHD build failure on Ubuntu 13.04
   due to libboost1.49, but a manual upgrade to libboost1.53 cured it.


I didn't try to build with Boost 1.49. I went straight to Boost 1.53 
and haven't had any issues yet (knock on wood!).

(Sorry - forgot to copy to list)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build-gnuradio under Ubuntu 13.04

2013-05-03 Thread mleech 
 

On 03 May 2013 09:00, Sean Nowlan wrote: 

> On 05/03/2013 08:59 AM,
Sean Nowlan wrote: 
> 
>> On 05/02/2013 10:37 PM, Marcus D. Leech wrote:

>> 
>>> Has anyone experienced any build failures in UHD on Ubuntu
13.04 using 
>>> build-gnuradio? 
>>> 
>>> I haven't upgraded my Ubuntu
system yet, and I have had one report of a 
>>> UHD build failure on
Ubuntu 13.04 
>>> due to libboost1.49, but a manual upgrade to
libboost1.53 cured it.
>> I didn't try to build with Boost 1.49. I went
straight to Boost 1.53 and haven't had any issues yet (knock on
wood!).
> (Sorry - forgot to copy to list)

OK, so the question I have
lingering in my head is whether I should special-case Ubuntu 13.04, and
have it explicitly install Boost1.53. I have one report of grief with
UHD+Ubuntu-13.04+boost-1.49, and reports of it having gone just fine
with boost-1.49 on Ubuntu 13.04. 

 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error in Building UHD on Windows

2013-05-03 Thread Marcus Müller 

Looked at those code lines, since I wasn't used to the
compiler output of msvc; everything looks fine.

Cheers,
Marcus
Am 03.05.2013 13:12, schrieb Zooz Engineer:

Hi Marcus,

Please find attached the txt file with the warnings.

Cheers,

Zo




Date: Thu, 2 May 2013 11:18:59 -0700
From: ml-node+s4n41109...@n7.nabble.com
To: xtmpcvs...@hotmail.com
Subject: Re: Error in Building UHD on Windows

If everything works fine: Ignore them.
The first one seems interesting, but does not necessarily imply an
error.
(sometimes you really just want to check if a double is still
in initialized state, e.g. filled with zeros and therefore use it as a
boolean; some compilers interpret that as cast to int)
However, could you point out the file that warning occurred, just to
help check things for consistency?

Thanks,
Marcus Müller

Am 02.05.2013 10:42, schrieb Zooz Engineer:

 > However, I have some 27 warnings in MSVC and I don't know how important
 > they are:
 >
 > C4244: '=' : conversion from 'double' to 'uint32_t', possible loss of
data
 > C4800: 'int' : forcing value to bool 'true' or 'false' (performance
warning)
 > C4305: '=' : truncation from 'double' to 'float'
 >
 > Can they be fixed or I can just ignore them?
 >
 > Best,
 > Zo


___
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



If you reply to this email, your message will be added to the discussion
below:
http://gnuradio.4.n7.nabble.com/Error-in-Building-UHD-on-Windows-tp41004p41109.html

To start a new topic under GnuRadio, email ml-node+s4n2...@n7.nabble.com
To unsubscribe from GnuRadio, click here
.
NAML




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build-gnuradio under Ubuntu 13.04

2013-05-03 Thread Ben Hilburn 
I updated the GNURadio Ubuntu install instructions for the 1.53 special
case. It's a known safe option, so it should generate less issues.

I'll update the wiki once Ubuntu updates the libboost-all-dev meta-package
to the newer version.

Cheers,
Ben


On Fri, May 3, 2013 at 7:14 AM,  wrote:

> **
>
> On 03 May 2013 09:00, Sean Nowlan wrote:
>
> On 05/03/2013 08:59 AM, Sean Nowlan wrote:
>
> On 05/02/2013 10:37 PM, Marcus D. Leech wrote:
>
> Has anyone experienced any build failures in UHD on Ubuntu 13.04 using
> build-gnuradio?
>
> I haven't upgraded my Ubuntu system yet, and I have had one report of a
> UHD build failure on Ubuntu 13.04
>due to libboost1.49, but a manual upgrade to libboost1.53 cured it.
>
>
> I didn't try to build with Boost 1.49. I went straight to Boost 1.53 and
> haven't had any issues yet (knock on wood!).
>
> (Sorry - forgot to copy to list)
>
> OK, so the question I have lingering in my head is whether I should
> special-case Ubuntu 13.04, and have it explicitly install Boost1.53.  I
> have one report of grief with UHD+Ubuntu-13.04+boost-1.49, and reports of
> it having gone just fine with boost-1.49 on Ubuntu 13.04.
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error in Building UHD on Windows

2013-05-03 Thread Josh Blum 


On 05/03/2013 06:12 AM, Zooz Engineer wrote:
> Hi Marcus,
> 
> Please find attached the txt file with the warnings.
> 

These are just implicit casts that cause default warnings in MSVC, but
not GCC. We generally fix these by just explicitly casting. There is
nothing to worry about.

I will add the explicit casts in due time. Thats for the report though.
I think that will be helpful!

Cheers,
-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP connection to python-C#

2013-05-03 Thread Ben Hilburn 
Adriana -

The GNURadio UDB source / sink blocks are just receiving / sending samples
via a UDP port.

You can use a block, or a C# application that just listens to the socket.
Look at the implementation of the UDP source if you are confused. It is
just using 'basic UDP sockets'.


http://gnuradio.org/doc/doxygen/classgr__udp__source.html


Cheers,
Ben


On Thu, May 2, 2013 at 3:44 PM, Adriana Arteaga
wrote:

> Hi!
> We need to implement a connection between usrp E110 (python) and a C#
> application in a host.
> In usrp, we use UDP Sink to send traffic from usrp to host, but we don't
> know if UDP Source can be used in C# application or if we have to use basic
> UDP sockets.
> Is there some like that in C# or what can we use?
>
> Thanks.
>
> Adriana
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP connection to python-C#

2013-05-03 Thread Marcus Müller 

Hi Adriana,

there is something wrong with the involved terminology here, so
hopefully I understand your question correctly:
You use an USRP E110, on which you run an GNU Radio flowgraph that
you created in python.
You have another computer somewhere else, that has a C# runtime on it.
You want to connect your flowgraph with a C# application on that computer.

"UDP Source" refers (on this mailing list) to the GNU Radio Block 
gr_udp_source; that block can, of course, only be used inside a GNU 
Radio flowgraph, because that is the framework it was written with.

That framework has no support for C#.

Since the GNU Radio UDP Sink simply sends out the input samples in UDP
packets, you're totally free to use whatever UDP socket implementation
fits your needs best and exists for your desired programming language/
environment.

I don't know if there is something comfortable to work with in C#;
I never worked with the .NET environment. Most people here are quite
fond of C++/python, so I guess if you want to do signal processing in C#
you're a little bit on your own here.
Personally, if you don't have to extend a already existing codebase, I'd
suggest using python instead of C#... since you'll already be using 
python when using gnuradio, thus introducing little extra learning 
effort (python is a nice language to learn, anyway).


However you may write your code:
Happy hacking!

Marcus

Am 03.05.2013 00:44, schrieb Adriana Arteaga:

Hi!
We need to implement a connection between usrp E110 (python) and a C#
application in a host.
In usrp, we use UDP Sink to send traffic from usrp to host, but we don't
know if UDP Source can be used in C# application or if we have to use
basic UDP sockets.
Is there some like that in C# or what can we use?

Thanks.

Adriana




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble posting messages to block's message port

2013-05-03 Thread Marcus Müller 

Hi Sean,
have you tried using tb.msg_connect(src, "out_port_id", dst, 
"in_port_id") instead of tb.connect?


Cheers
Marcus
Am 03.05.2013 00:35, schrieb Sean Nowlan:

I'm trying to create a block that accepts messages and prints them out.
I created a block that extends gr_block and it has no stream ports: I'm
using gr_io_signature(0,0,0) for input and output. I am following the
guidance of this page:

http://gnuradio.org/doc/doxygen/page_msg_passing.html

 From a test Python script I instantiate a top_block /tb/ and then
connect my stream-port-less block with tb.connect(block_instance). I
follow the lead of the page above to post a message, but the bound
handler function never gets called (I inserted a line to print "I'm
here!!" to stdout when the function gets called).

Am I having issues because my block doesn't have any stream inputs or
outputs?

Thanks,

Sean

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About "FPGA-ADC/DAC and RF frontend" Latency

2013-05-03 Thread Ben Hilburn 
NaceurElOuni -

I think I'm having trouble understanding your question. I'm not sure what
you want to measure, or how you intend to measure it.

For starters, there isn't really a shared concept of 'time' between the
FPGA and the analog components. The FPGA operates in terms of clocks...
which don't exist on the analog front-end. I suppose you could try to
measure it in real-world 'time', but figuring out how to do that would be
incredibly hard, and then the instrumentation you would need to do it would
be even harder (probably?).

Are you asking about measuring the group delay of the analog components? If
that's the case, the throwing everything into a simulator is your best bet.

Anyway, sorry for the confused response. I don't think I'm understanding
your question correctly.

Cheers,
Ben


On Wed, May 1, 2013 at 11:36 PM, NaceurElOuni  wrote:

> Hi,
>
> I am working on estimating the delay between a Tx and an Rx using a stream
> of packets modulated in a BPSK scheme (1 Mb/s) with a pair of N210.
> (Sampling of 8 Mbits/s)
> I want to know if the latency added by the portion(*) of [ FPGA - DAC - RF
> front end to the antenna *2 (Rx Part) ] could be determined for a giving
> set
> of parameters (transmission-reception)
>
> I am interested in estimating the range of this latency (tens? hundreds of
> microseconds?)
>
> Then, could this latency be considered as insignifiant versus the latency
> of
> the local network and the latency of Ethernet queue processing
> (Encapsulation/Decapsulation). (for eg. both Rx and tx ethernet latency are
> fluctuating between 1 to 1.5 msec.)
>
> Another point, how is the latency of the portion (*) varying.
>
> All explanation are appreciated, thank you in advance.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/About-FPGA-ADC-DAC-and-RF-frontend-Latency-tp41091.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Why other correlators(ml or pnac) can not work in ofdm example except for Schmidl and Cox correlator(default)?

2013-05-03 Thread Ben Hilburn 
Hi Yingjie Chen -

If your schedule requires that the code work, then feel free to hack on it
and make it work! That's the beauty of open source. You could then
contribute your code back to the community, thus helping everyone that has
put effort into making GNURadio what it is, today =)

Cheers,
Ben


On Thu, May 2, 2013 at 2:09 AM, Yingjie Chen  wrote:

> Thanks for you reply. Can you tell me what should I do next? Update the
> code or other things? Cause I am very urgent with my project and need to
> use other correlator(like pnac). Thanks in advance.
>
>
> 2013/5/2 Martin Braun (CEL) 
>
>>  On Thu, May 02, 2013 at 04:52:53PM +0800, Yingjie Chen wrote:
>> > I have checked the code in ofdm_receiver.py and found that gnuradio uses
>> > Schmidl and Cox as default correlator for frame detection. However,
>> when I
>> > change to other correlators like ml or pnac,the receiver cannot
>> receiver any
>> > more. Is there any problem with that? Thanks so much.
>>
>> The OFDM code is under heavy maintenance right now. The code you're
>> inspecting is a bit outdated and it's quite likely it doesn't work
>> properly.
>>
>> MB
>>
>> --
>> Karlsruhe Institute of Technology (KIT)
>> Communications Engineering Lab (CEL)
>>
>> Dipl.-Ing. Martin Braun
>> Research Associate
>>
>> Kaiserstraße 12
>> Building 05.01
>> 76131 Karlsruhe
>>
>> Phone: +49 721 608-43790
>> Fax: +49 721 608-46071
>> www.cel.kit.edu
>>
>> KIT -- University of the State of Baden-Württemberg and
>> National Laboratory of the Helmholtz Association
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble posting messages to block's message port

2013-05-03 Thread Sean Nowlan 

On 05/03/2013 01:26 PM, Marcus Müller wrote:

Hi Sean,
have you tried using tb.msg_connect(src, "out_port_id", dst, 
"in_port_id") instead of tb.connect?


Cheers
Marcus


I'm trying to post a message to a port from top_block as opposed to 
connecting the output port of one block to the input of "dst". The 
documentation indicates this can be done using 
"dst.to_basic_block()._post(port, msg)".Unfortunately this is not 
working for me.


http://gnuradio.org/doc/doxygen/page_msg_passing.html

--sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble posting messages to block's message port

2013-05-03 Thread Sean Nowlan 

On 05/03/2013 01:41 PM, Sean Nowlan wrote:

On 05/03/2013 01:26 PM, Marcus Müller wrote:

Hi Sean,
have you tried using tb.msg_connect(src, "out_port_id", dst, 
"in_port_id") instead of tb.connect?


Cheers
Marcus


I'm trying to post a message to a port from top_block as opposed to 
connecting the output port of one block to the input of "dst". The 
documentation indicates this can be done using 
"dst.to_basic_block()._post(port, msg)".Unfortunately this is not 
working for me.


http://gnuradio.org/doc/doxygen/page_msg_passing.html


More precisely, posting the message doesn't fail, so I *guess* it 
worked. However the handler function is not called. I used the 
boost::bind call to bind the message handler function following the lead 
of the example code.


--sean

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About "FPGA-ADC/DAC and RF frontend" Latency

2013-05-03 Thread mepard 
Hint 1:  If both 210s are on the same PPS and frequency reference and the FPGA 
clocks are synchronized to the PPS, you can schedule the transmit and receive 
to within one tick of the 100 MHz ADC clock.
Hint 2:  Cross correlate the transmitted and received samples. The lag will be 
independent of Ethernet and IP delays.

-Marc


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation-Problem:

2013-05-03 Thread Wolfgang Buesser 
O.k.

I managed to make it work by removing every file named  *usrp* or
*gnuradio* and reinstalling gnuradio and uhd from the repository.

Now the examples seem to work on my usrp1.

But I am quite desperate at getting my old python code to work. I have
programmed a vector-network-analyzer.
I used to call 

...

from gnuradio import usrp

...

def _instantiate_blocks (self):
self.tx = usrp.sink_s(0, self.interp)


Apparently all the system call have changed completely. Is there
anything like a 'migration guide'? I really hate the idea of having to
go through all this tedious programming again just because my old OS is
gone.

Thanks for your help

tnx de
Wolfgang

DK1BW

On Do, 2013-05-02 at 13:26 -0700, Nicholas Corgan wrote:
> This error is saying that GR-UHD was built against an older version of
> UHD than you're using now, a 3.4.* version from the looks of it. To
> fix this, rebuild GR-UHD against your current UHD.
> 
> cd (GNU Radio build directory)/gr-uhd
> make clean
> 
> sudo make install
> 
> 
> 
> On Thu, May 2, 2013 at 1:01 PM, Wolfgang Buesser
>  wrote:
> Hi Erik,
> 
> thanks - I managed to install gnuradio that way. When trying
> to run a
> usrp example I get the following error-message:
> 
> examples/uhd# ./usrp_wfm_rcv_nogui.py
> linux; GNU C++ version 4.7.2 20130108 [gcc-4_7-branch revision
> 195012]; Boost_104900; UHD_003.005.002-61-g08624153
> 
> Traceback (most recent call last):
>   File "./usrp_wfm_rcv_nogui.py", line 172, in 
> tb = wfm_rx_block()
>   File "./usrp_wfm_rcv_nogui.py", line 67, in __init__
> self.u = uhd.usrp_source(device_addr=options.args,
> stream_args=uhd.stream_args('fc32'))
>   File
> "/usr/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
> line 116, in constructor_interceptor
> return old_constructor(*args)
>   File
> "/usr/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
> line 2454, in usrp_source
> return _uhd_swig.usrp_source(*args)
> RuntimeError:
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.4.0-3,
> but UHD library reports ABI: 3.6.0-0
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version.
> 
> Maybe there is a previous version of some lib left over?
> Any hint on what I should do/try?
> 
> 73 de
> Wolfgang
> DK1BW
> 
> On Mi, 2013-05-01 at 12:51 +0200, Erik Jakobsen wrote:
> > Wolfgang.
> >
> > For opensuse 12.3 the repos are here:
> >
> > http://download.opensuse.org/repositories/home:/dl8fcl/
> >
> > GL
> >
> > 73s
> > Erik OZ4KK
> >
> >
> > > I am trying to install gnuradio on a new
> > > computer running suse 12.3 to use it with my
> > > usrp.
> > >
> > > upon cmake I keep getting the message:
> > > "Could Not find PythonLibs".
> > >
> > > Any hint what rpm or sources I need to install
> > > on Suse 12.3 would be great. Or maybe what
> > > libraries cmake is looking for.
> > >
> > > python is installed of course.
> > >
> > > Thanks
> > >
> > > wolfgang
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> --
> Wolfgang Buesser
> Am Ziegelberg 1a
> 55595 Mandel
> 
> +49 174/585 2995
> wolfgang.bues...@web.de
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> -- 
> Nicholas Corgan
> 

-- 
Wolfgang Buesser
Am Ziegelberg 1a
55595 Mandel

+49 174/585 2995
wolfgang.bues...@web.de



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation-Problem:

2013-05-03 Thread Erik Jakobsen 

Nice to hear, that you have made progress Wolfgang.

GL with the rest

73s
Erik OZ4KK

O.k.

I managed to make it work by removing every file named  *usrp* or
*gnuradio* and reinstalling gnuradio and uhd from the repository.

Now the examples seem to work on my usrp1.

But I am quite desperate at getting my old python code to work. I have
programmed a vector-network-analyzer.
I used to call

...

from gnuradio import usrp

...

 def _instantiate_blocks (self):
 self.tx = usrp.sink_s(0, self.interp)


Apparently all the system call have changed completely. Is there
anything like a 'migration guide'? I really hate the idea of having to
go through all this tedious programming again just because my old OS is
gone.

Thanks for your help

tnx de
Wolfgang

DK1BW

On Do, 2013-05-02 at 13:26 -0700, Nicholas Corgan wrote:

This error is saying that GR-UHD was built against an older version of
UHD than you're using now, a 3.4.* version from the looks of it. To
fix this, rebuild GR-UHD against your current UHD.

cd (GNU Radio build directory)/gr-uhd
make clean

sudo make install



On Thu, May 2, 2013 at 1:01 PM, Wolfgang Buesser
 wrote:
 Hi Erik,
 
 thanks - I managed to install gnuradio that way. When trying

 to run a
 usrp example I get the following error-message:
 
 examples/uhd# ./usrp_wfm_rcv_nogui.py

 linux; GNU C++ version 4.7.2 20130108 [gcc-4_7-branch revision
 195012]; Boost_104900; UHD_003.005.002-61-g08624153
 
 Traceback (most recent call last):

   File "./usrp_wfm_rcv_nogui.py", line 172, in 
 tb = wfm_rx_block()
   File "./usrp_wfm_rcv_nogui.py", line 67, in __init__
 self.u = uhd.usrp_source(device_addr=options.args,
 stream_args=uhd.stream_args('fc32'))
   File
 "/usr/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
 line 116, in constructor_interceptor
 return old_constructor(*args)
   File
 "/usr/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
 line 2454, in usrp_source
 return _uhd_swig.usrp_source(*args)
 RuntimeError:
 GR-UHD detected ABI compatibility mismatch with UHD library.
 GR-UHD was build against ABI: 3.4.0-3,
 but UHD library reports ABI: 3.6.0-0
 Suggestion: install an ABI compatible version of UHD,
 or rebuild GR-UHD component against this ABI version.
 
 Maybe there is a previous version of some lib left over?

 Any hint on what I should do/try?
 
 73 de

 Wolfgang
 DK1BW
 
 On Mi, 2013-05-01 at 12:51 +0200, Erik Jakobsen wrote:

 > Wolfgang.
 >
 > For opensuse 12.3 the repos are here:
 >
 > http://download.opensuse.org/repositories/home:/dl8fcl/
 >
 > GL
 >
 > 73s
 > Erik OZ4KK
 >
 >
 > > I am trying to install gnuradio on a new
 > > computer running suse 12.3 to use it with my
 > > usrp.
 > >
 > > upon cmake I keep getting the message:
 > > "Could Not find PythonLibs".
 > >
 > > Any hint what rpm or sources I need to install
 > > on Suse 12.3 would be great. Or maybe what
 > > libraries cmake is looking for.
 > >
 > > python is installed of course.
 > >
 > > Thanks
 > >
 > > wolfgang
 > >
 > >
 > >
 > >
 > >
 > > ___
 > > Discuss-gnuradio mailing list
 > > Discuss-gnuradio@gnu.org
 > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 >
 
 
 --

 Wolfgang Buesser
 Am Ziegelberg 1a
 55595 Mandel
 
 +49 174/585 2995

 wolfgang.bues...@web.de
 
 
 
 ___

 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 




--
Nicholas Corgan




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-osmosdr in MacPorts

2013-05-03 Thread alanwoodward 
Michael, 

the update seems to work, I have built (using macports) the whole of
gnuradio and the osmosdr module.  All seems to work with the osmo and rtl
sources and sink appearing in companion and being able to hook them
together.

I am having a problem getting a graph to execute however, (probably a path
but I can't see the error).

Error reads:

Executing: "/Users/alanwoodward/Desktop/Radio Graphs/top_block.py"

Traceback (most recent call last):
  File "/Users/alanwoodward/Desktop/Radio Graphs/top_block.py", line 16, in

import osmosdr
  File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/__init__.py",
line 45, in 
from osmosdr_swig import *
ImportError: No module named osmosdr_swig

$ echo $PATH
/opt/local/bin:/usr/local/share/python:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

$ echo $PYTHONPATH
/opt/local/Library/Frameworks/Python.framework/Versions/2.7

I appreciate any help, Alan




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-osmosdr-in-MacPorts-tp40539p41146.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP2 + WBX for DVB-T replaying

2013-05-03 Thread Dinos Pastos 
Hi there,

I have a USRP2 with WBX board which has been sitting around doing nothing.
I was wondering if it is possible to use this hardware to get a live DVB-T
signal and replay it back.

What I want to do is to intercept entitlement management messages and
modify/remove them on the fly.

Please let me know if there is such support with this hardware or even a
previous project that tackles this request.

Regards

Dino
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSoC Students: Application deadline

2013-05-03 Thread Martin Braun (CEL) 
Hi all GSoC applicants,

thanks for submitting so many fantastic GSoC proposals!

Just a quick status update: We have received 28 applications; we will
know about the number of slots next week Wednesday.
Realistically, I am expecting 2-4 slots for GNU Radio. Selecting
students will be hard, and I hope we can find a good way to do that.

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpIAErBbjsKF.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About "FPGA-ADC/DAC and RF frontend" Latency

2013-05-03 Thread NaceurElOuni 
Thank you Marc,

* Ok I will try using a common clock ref and input PPS

* Scheduling the transmit and receive  to within one tick of the 100 MHz
ADC clock: Can that be done into the host GNU radio code or am supposed to
move the code to the FPGA.

* Is that the samples count method to get accurate time-stamping ?

* Can you please explain to me more about the concept of cross
correlating transmitted
and received samples.



2013/5/3 mepard [via GnuRadio] 

> Hint 1:  If both 210s are on the same PPS and frequency reference and the
> FPGA clocks are synchronized to the PPS, you can schedule the transmit and
> receive to within one tick of the 100 MHz ADC clock.
> Hint 2:  Cross correlate the transmitted and received samples. The lag
> will be independent of Ethernet and IP delays.
>
> -Marc
>
>
> ___
> Discuss-gnuradio mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://gnuradio.4.n7.nabble.com/About-FPGA-ADC-DAC-and-RF-frontend-Latency-tp41091p41143.html
>  To unsubscribe from About "FPGA-ADC/DAC and RF frontend" Latency, click
> here
> .
> NAML
>



-- 
Naceur Amine El Ouni, B. Ing
Laboratoire LaCIME.


École de technologie supérieure 

naceur.el-o...@lacime.etsmtl.ca

1100, rue Notre-Dame Ouest Montréal (Québec) H3C 1K3 Canada
Tel : 514 396-8800, ext. 7608
Cell : 438-868-2240




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/About-FPGA-ADC-DAC-and-RF-frontend-Latency-tp41091p41149.html
Sent from the GnuRadio mailing list archive at Nabble.com.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About "FPGA-ADC/DAC and RF frontend" Latency

2013-05-03 Thread NaceurElOuni 
Hi Ben,

Thanks for explanations,

I've been doing some theoretical calculations on the group delay estimation
and found that this part is giving negligible latency compared to the
Ethernet portion between USRP and host.

cheers.





2013/5/3 Naceur Amine El Ouni 

> Thank you Marc,
>
> * Ok I will try using a common clock ref and input PPS
>
> * Scheduling the transmit and receive  to within one tick of the 100 MHz
> ADC clock: Can that be done into the host GNU radio code or am supposed to
> move the code to the FPGA.
>
> * Is that the samples count method to get accurate time-stamping ?
>
> * Can you please explain to me more about the concept of cross correlating 
> transmitted
> and received samples.
>
>
>
> 2013/5/3 mepard [via GnuRadio] 
>
>  Hint 1:  If both 210s are on the same PPS and frequency reference and the
>> FPGA clocks are synchronized to the PPS, you can schedule the transmit and
>> receive to within one tick of the 100 MHz ADC clock.
>> Hint 2:  Cross correlate the transmitted and received samples. The lag
>> will be independent of Ethernet and IP delays.
>>
>> -Marc
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> [hidden email] 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> --
>>  If you reply to this email, your message will be added to the
>> discussion below:
>>
>> http://gnuradio.4.n7.nabble.com/About-FPGA-ADC-DAC-and-RF-frontend-Latency-tp41091p41143.html
>>  To unsubscribe from About "FPGA-ADC/DAC and RF frontend" Latency, click
>> here
>> .
>> NAML
>>
>
>
>
> --
> Naceur Amine El Ouni, B. Ing
> Laboratoire LaCIME.
>
>
> École de technologie supérieure 
>
> naceur.el-o...@lacime.etsmtl.ca
>
> 1100, rue Notre-Dame Ouest Montréal (Québec) H3C 1K3 Canada
> Tel : 514 396-8800, ext. 7608
> Cell : 438-868-2240
>



-- 
Naceur Amine El Ouni, B. Ing
Laboratoire LaCIME.


École de technologie supérieure 

naceur.el-o...@lacime.etsmtl.ca

1100, rue Notre-Dame Ouest Montréal (Québec) H3C 1K3 Canada
Tel : 514 396-8800, ext. 7608
Cell : 438-868-2240




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/About-FPGA-ADC-DAC-and-RF-frontend-Latency-tp41091p41150.html
Sent from the GnuRadio mailing list archive at Nabble.com.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble posting messages to block's message port

2013-05-03 Thread Martin Lülf 
I had this issue once and if I remember correctly, connecting the block 
to the flowgraph (i.e. connect any block to your message port, even if 
that port will never send messages) will make your message handler react 
to messages from your python code.


Hope this helps
Martin


Am 03.05.2013 19:46, schrieb Sean Nowlan:

On 05/03/2013 01:41 PM, Sean Nowlan wrote:

On 05/03/2013 01:26 PM, Marcus Müller wrote:

Hi Sean,
have you tried using tb.msg_connect(src, "out_port_id", dst,
"in_port_id") instead of tb.connect?

Cheers
Marcus


I'm trying to post a message to a port from top_block as opposed to
connecting the output port of one block to the input of "dst". The
documentation indicates this can be done using
"dst.to_basic_block()._post(port, msg)".Unfortunately this is not
working for me.

http://gnuradio.org/doc/doxygen/page_msg_passing.html


More precisely, posting the message doesn't fail, so I *guess* it
worked. However the handler function is not called. I used the
boost::bind call to bind the message handler function following the lead
of the example code.

--sean



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trouble posting messages to block's message port

2013-05-03 Thread Nowlan, Sean 


From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of 
Martin Lülf [m...@mluelf.de]
Sent: Friday, May 03, 2013 7:59 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Trouble posting messages to block's message port

I had this issue once and if I remember correctly, connecting the block
to the flowgraph (i.e. connect any block to your message port, even if
that port will never send messages) will make your message handler react
to messages from your python code.

Hope this helps
Martin

---
Thanks! I'll give that a shot.

--sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem in Accessing GNU Radio.org web link -reg

2013-05-03 Thread Mr. R. Gandhiraj 
Sir,
This is Gandhiraj R, from Amrita Vishwa Vidyapeetham, Coimbatore, Tamil Nadu, 
India.

Currently many of our students  working in GNURadio based projects.
Recently we can not access the GNURADIO.ORG web link.

Error message:
---
Access Denied
The owner of this website (gnuradio.org) has banned your IP address 
(14.139.187.130). (Ref. 1006)

Timestamp: Fri, 03 May 2013 06:14:13 -0700

Your IP address: 14.139.187.130

Requested URL: gnuradio.org/redmine/projects/gnuradio/wiki

Error reference number: 1006

Server ID: FL_23F5

Process ID: PID_68d368ba8fd022c

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like 
Gecko) Chrome/24.0.1312.70 Safari/537.17
--
kindly give the solution for the same.

with regards,

-- 
R.Gandhiraj, M.Tech.,(Ph.D) 
Assistant Professor (Sr.Gr.), 
Department of ECE, Amrita School of Engineering, Coimbatore Campus, 
Amrita Vishwa Vidyapeetham (University), 
Coimbatore-641105 

Mobile: +91 99422 23982 
Office : +91(422) 2656422 (Ext. 5726) 
Fax : +91(422) 2656274 

Official Web : http://engineering.amrita.edu/cb/depts/ece/faculty.php 
Personal Web: http://sites.google.com/site/gsrgandhiraj/ 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio