Re: [Discuss-gnuradio] Trouble with gr-ieee802.11
Hi, On 23 Jul 2015, at 21:45, Paul Garver garv...@gatech.edu wrote: Did you install from pybombs? I've seen this error using pybombs to install on Ubuntu 15.04. It seems like a few other folks on this list have the same problem. Running gdb --args python wifi_loopback.py shows the segfault location: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff7dffb700 (LWP 11226)] 0x7fffde0db3e4 in ofdm_parse_mac_impl::parse (this=0x2de5fd0, msg=...) at /home/pwg3v/git_repos/pybombs/src/gr-ieee-80211-pwg/lib/ofdm_parse_mac.cc:61 61mylog(boost::format(length: %1%) % data_len ); My boost version is 1.55. If you disable logging in the grc block noted, (ofdm_parse_mac), the seg fault will go away. Bastian, could you elaborate on the boost version issue? Are there known incompatibilities or is this something that just needs to be fixed? To be honest, I have absolutely no idea… I cannot reproduce this error and I don’t know for sure if someone else has problems with this function. But if this causes problems I would just replace boost::format with std::cout. Best, Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable
Hi Ashraf, A single complex sine tone will only have one spectral peak. I think you will see great profit in understanding a bit of the math/signal theory involved. GNU Radio has a suggested reading page, especially made for these cases: https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading Go through Michael Ossman's tutorial (under Math). In fact, reading through that list, there's a distinct lack of free ressources that bridge the gap between why? and what are complex signals? and digital communication basics, ie. stuff like what is the spectrum/a fourier transform. If you have access to a university library or so, grab a book on basics of signals and linear systems; like in every mature scientific community, there's some healthy dispute on what students should be having access to, but if you're looking for something relative precise, yet not too mathematical and free, have a look at Lapidoth, which is available here as a PDF: http://www.afidc.ethz.ch/A_Foundation_in_Digital_Communication/Getting_The_Book.html Read chapters 2 and 6. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable
On 7/23/15 8:56 AM, Ashraf Younis wrote: Thank you for the examples and the explanation. I believe I understand. Sticking with a square wave or anything that involves a sinc envelop will always raise the spectrum. Is there something that I can transmit that won't let this occur? A pure sine wave should have a single peak on the spectrum. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Type-selectable OOT Block C++
On Thu, Jul 23, 2015 at 6:29 AM, Galiero Casay Gabriele gabriele.galieroca...@aalto.fi wrote: Hello all, I was building my own block in C++ and I have one doubt about it. Some times my block has to work with float streams and sometimes with complex streams. There is one single input and output. I have implemented separately: sync_ff_impl.cc and sync_cc_impl.cc each one with its respective xml file to use it in gnuradio-companion. Now I wanted to have only one xml so that the block is type-selectable. Is there any template or way to make it? I have been checking the code from other type-selectable blocks but it did not help much. If there is some interest about what the block does, it basically adds a predefined preamble to the incoming packets, so that in reception the receiver is able to know when the packet starts. Thanks before hand. Best regards, Gabriele Galiero Hi Gabriele, There are tons of examples in the GNU Radio source tree for how to do this. Look for any block that has a _xx or _vxx ending on it in the grc directories and you'll see it. A good example is blocks_multiply_const_vxx.xml: makeblocks.multiply_const_v$(type.fcn)($const)/make param nameIO Type/name keytype/key typeenum/type option nameComplex/name keycomplex/key optconst_type:complex_vector/opt optfcn:cc/opt /option option nameFloat/name keyfloat/key optconst_type:real_vector/opt optfcn:ff/opt /option option nameInt/name keyint/key optconst_type:int_vector/opt optfcn:ii/opt /option option nameShort/name keyshort/key optconst_type:int_vector/opt optfcn:ss/opt /option /param So the $(type.fcn) is filled in with the opt parameter of the type selected. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio and android
On Wed, Jul 22, 2015 at 4:47 PM, Volker Schroer dl1...@gmx.de wrote: Hi! I watched the development of gnuradio for android. But I'm not very familiar with java, so I searched for a way to run gnuradio python scripts without or with little modifications on android. I detected the python_for_android project and wrote some recipes to run gnuradio on android. For those who are interested , see: https://github.com/dl1ksv/python-for-android At the moment I'm able to run things like dial_tone or an fm receiver using the rtl dongle. But there are a lot of things missing, in particular a gui, support of fcd(pro+), etc. So my question: Where to go from here: Introducing kivy to gnuradio for building gui's , or migrating qt5 ( a way I'd prefer ) Or is this only a nice finger exercise and of no special interest ? Comments are welcome -- Volker Volker, This is awesome that you're working on this and sharing your progress. Two things. First, I think the QT5 way is where you'd want to go. We will be migrating there, anyways, likely for the 3.8 release. Having done some work recently on the gr_filter_design tool in QT4/5, it's not a huge amount of work to go between them. We'll likely do this work off the next branch for the next API version release. Anything you can contribute to this effort would be great. As to Python, I'm skeptical how fruitful this path really is. If it's just for your own stuff, that's one thing, but Android is Java, love it or hate it. Trying to work too far away from their structure of work is dangerous, since they can decide at any moment to just kill certain efforts -- I'm a little afraid of this myself with our reliance on the NDK, even. I'm in the boat of learning Java myself to work in this world. Easier that than trying to force other modes of operation onto this beast. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ham2mon GR based scanner
Nicely done! On Wed, Jul 22, 2015 at 9:11 PM, madengr rfeng...@me.com wrote: Throught I'd share my GR based scanner with curses GUI. Locks on and demodulates N number of NBFM channels and logs audio to disk. Uses gr-osmosdr source so should work with a variety of devices. https://github.com/madengr/ham2mon https://www.youtube.com/watch?v=BXptQFSV8E4 -- View this message in context: http://gnuradio.4.n7.nabble.com/ham2mon-GR-based-scanner-tp54975.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] Data (was: Re: Run graph/ scheduler overhead)
Was able to do better by rewriting the moving average (below). Didn't
touch the blocker class itself other than to templatize it.
dennisg@Tori-Radio:~/dc_test$ c++ -O3 -Wsign-compare -Wall
-Wno-uninitialized -fvisibility=hidden -finline -std=c++11 main_test.cc
dennisg@Tori-Radio:~/dc_test$ size a.out
textdata bss dec hex filename
28835 864 408 30107759b a.out
originalopt+c11
template: -- 0.00019348
deque: 0.000701038 0.0002474
queue: 0.00069784 0.000248843
list: 0.00194583 0.00212156
For my own amusement I ran these tests on a FreeBSD machine that is
slower than my Ubuntu machine. This machine has a different processor
(AMD 8350) at 4GHz.
Compile lines:
root@Tasha# g++49 -O3 -Wsign-compare -Wall -Wno-uninitialized
-fvisibility=hidden -finline -std=c++11 main_test.cc
root@Tasha# g++5 -O3 -Wsign-compare -Wall -Wno-uninitialized
-fvisibility=hidden -finline -std=c++11 main_test.cc
root@Tasha# clang++ -O3 -Wsign-compare -Wall -Wno-uninitialized
-fvisibility=hidden -finline -std=c++11 -I /usr/local/include
main_test.cc
root@Tasha# clang++-devel -O3 -Wsign-compare -Wall -Wno-uninitialized
-fvisibility=hidden -finline -std=c++11 -I /usr/local/include
main_test.cc
g++49 g++5clang++(3.4.1) clang++(3.7.0)
template: 0.000226272 0.00022474 0.0002870820.00023594
deque:0.000297232 0.000357486 0.0006938990.000632054
queue:0.000297098 0.000357484 0.0006908840.000627877
list: 0.00457583 0.00418757 0.00411387 0.0040383
(I also compiled against gcc6 snapshot 20150719 but it's similar in
performance to gcc5.)
It's interesting the performance for deque/queue is much worse under
clang and the templated moving average is fairly steady across all
compilers.
I think what this says is the following. First, we can improve the
performance of dc_block but against the current algorithm it's never
going to be awesome. Second, the performance of the template library
containers is fairly good and consistent and the choice of std::deque
was a fairly good one. Third, different compilers and different template
libraries at different optimization levels is going to impact
performance (duh), perhaps negatively.
One of the things GNURadio is missing is some indication of
block/library performance. For example, maybe -O2 is better than -O3 and
maybe -std=c++11 worse than the default on a given platform. However I
have little idea how we'd incorporate those metrics (seems kind of nasty
when you think about the mechanics).
templatetypename T
class moving_average_t {
private:
// Relationships of the following variables:
//
// d_len = d_delay_line.size().
// d_index = (d_index % d_len)
//
// The length of the moving average queue and the current index into
// it.
//
size_t d_len, d_index;
// The moving average delay line.
//
// The delay line is an array of type T, length d_len, and where
// d_index is the oldest entry.
//
std::vectorT d_delay_line;
T d_out, d_out_d2;
// Rather than returning a constructed sample from filter(), which
// of course can have construction/destruction overhead, store the
// sample here and return a const reference.
//
T d_temp;
public:
moving_average_t( void ) = delete;
moving_average_t( size_t len );
virtual ~moving_average_t( void );
moving_average_t( const moving_average_t t ) = delete;
moving_average_t operator=( const moving_average_t t ) = delete;
// Set the length of the delay line, reinitializing content.
//
void set_len( size_t len );
// Add a sample to the delay line and return the oldest and averaged
// sample (removed from the delay line).
//
const T filter( const T t );
// The oldest, unadjusted (i.e., averaged) signal in the delay line.
//
const T delayed_sig( void ) const;
};
templatetypename T
moving_average_tT::moving_average_t( size_t len )
: d_len( 0 ), d_index( 0 ),
d_out( 0 ), d_out_d2( 0 ),
d_temp( 0 ) {
set_len( len );
}
templatetypename T
moving_average_tT::~moving_average_t( void ) {}
templatetypename T
void
moving_average_tT::set_len( size_t len ) {
d_len = len;
d_index = 0;
d_temp = 0;
d_out = d_out_d2 = 0;
d_delay_line.clear();
for( size_t i = 0; i d_len - 1; ++i )
d_delay_line.push_back( T(0));
}
templatetypename T
inline const T
moving_average_tT::delayed_sig( void ) const {
return d_out;
}
templatetypename T
inline const T
moving_average_tT::filter( const T t ) {
T d_out_d1 ( d_out );
// Cache the oldest signal used in the average.
//
d_out = d_delay_line[d_index];
// Stuff the passed sample into the delay line and bump the index.
//
d_delay_line[d_index] = t;
d_index = (( d_index + 1 ) % ( d_len - 1 ));
// Do the math.
//
d_out_d2 = (t - d_out_d1 + d_out_d2 );
d_temp =
Re: [Discuss-gnuradio] Trouble with gr-ieee802.11
Did you install from pybombs? I've seen this error using pybombs to install on Ubuntu 15.04. It seems like a few other folks on this list have the same problem. Running gdb --args python wifi_loopback.py shows the segfault location: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff7dffb700 (LWP 11226)] 0x7fffde0db3e4 in ofdm_parse_mac_impl::parse (this=0x2de5fd0, msg=...) at /home/pwg3v/git_repos/pybombs/src/gr-ieee-80211-pwg/lib/ofdm_parse_mac.cc:61 61 mylog(boost::format(length: %1%) % data_len ); My boost version is 1.55. If you disable logging in the grc block noted, (ofdm_parse_mac), the seg fault will go away. Bastian, could you elaborate on the boost version issue? Are there known incompatibilities or is this something that just needs to be fixed? Thanks, PWG Hi, please start the flow graph in a debugger to see where it segfaults. http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB Recently, some people had problems with certain boost versions (in boost::format IIRC). Best, Bastian / On 17 Jul 2015, at 12:03, Leonardo S. Cardoso address@hidden wrote:/ / / / Hi everyone,/ / / / I’m wondering if there are any gr-ieee802.11 exports out there, who have had/ / the problem as I did... :)/ / / / I’m having some issues with a core dump whenever I try to execute any of the/ / reception codes (wifi_loopback or wifi_rx)./ / / / Specifically with the wifi_loopback I get this before the core dump:/ / / / linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.git-219-gd9656de8/ / / / Using Volk machine: avx_64_mmx_orc/ / OFDM MAPPER: encoding: 0/ / set_min_output_buffer on block 31 to 96000/ / set_min_output_buffer on block 33 to 96000/ / set_min_output_buffer on block 35 to 96000/ / set_min_output_buffer on block 36 to 96000/ / set_min_output_buffer on block 39 to 96000/ / set_min_output_buffer on block 50 to 96000/ / Segmentation fault (core dumped)/ / / / I have no idea even in which code to look for the issue, so I’m a bit stuck./ / / / Any help would be welcome./ / / / Cheers,/ / / / Leo/ / --/ / Leonardo S. Cardoso/ / Maitre de Conference/ / CITI lab, INSA-Lyon - INRIA/ / / / / / / / / / ___/ / Discuss-gnuradio mailing list/ / address@hidden/ / https://lists.gnu.org/mailman/listinfo/discuss-gnuradio/ -- Dipl.-Inform. Bastian Bloessl Distributed Embedded Systems Group University of Paderborn, Germany http://www.ccs-labs.org/~bloessl/ http://www.ccs-labs.org/%7Ebloessl/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Data (was: Re: Run graph/ scheduler overhead)
I copied out the dc_block_cc block from 3.7.8 and ran some performance
tests against it, which I've summarized in a table below.
I had to make some modifications to the original code, such as:
* I removed the make wrapper.
* I tested against different containers.
* Different containers have different access/management methods
which meant some changes to code body (I tried to be consistent).
* On input I passed a std::vector to work() rather than complex*.
Although this changes the flavor of work() I figure it's relative.
* I only used long_form and deleted the short_form code. I used
the key part of the original code.
The three containers are the original std::deque then std::queue and
std::list. The results are interesting. I probably should have looked at
other containers such as std::vector but that might require recoding.
I also compiled with and without -std=c++11 because when i looked at
container source I saw a bunch of #ifdefs for = c++0x.
These are some of the problems with the original dc_block:
* Passing by value rather than by reference.
* No inlines.
* const needed where const should be.
So in a second copy of dc_block I did those things. I found a case
(filter()) where it returns by value and I left that one alone.
The table below summarizes the results. Old means my reasonable(?)
facsimile of the original dc_block. +c11 means I added -std=c++11 to
the compile line. Opt is my optimized copy of the code where I added
references, inlines, etc. Special is opt but with different compile
options. All of the output is included at the end of this message.
The numbers you'll see for old/c++1/etc is the amount of time it took to
process /one/ sample. In old+deque for example (the first item), it
took 701us to process a sample. One of the surprising numbers is that
std::list sucks. Also, when looking at the assembly language for
filter() (copy below) I see reallocs(). That's not surprising and
probably badness. (BTW, CPLX is: typedef std::complexfloat CPLX;.)
inline const CPLX
moving_averager_c_list::filter( const CPLX x ) {
d_out_d1 = d_out;
d_delay_line.push_back(x);
d_out = d_delay_line.front();
d_delay_line.pop_front();
CPLX y = x - d_out_d1 + d_out_d2;
d_out_d2 = y;
return (y / (float)(d_length));
}
The size numbers in the table are the text segment size returned using
size a.out. The block size is simply a sizeof(d_delay_line), which
is really sizeof(std:dequeCPLX) for example.
One other note. I compiled special with -Ofast and it failed content
integrity check. Probably a bad option to use. :)
My os: Ubuntu 15.04.
My compiler: gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)
My system: AMD FX(tm)-9590 Eight-Core Processor @ 4.7GHz
I'm happy to send copies of the test code (two files) for review if
someone wants to put them on the web. The three main code blocks are
pretty simple:
{ dc_blocker_cc_deque dc( NUM_ELEM );
std::cout deque: std::endl;
t_start = gr::high_res_timer_now();
for( int i = 0; i NUM_LOOPS; ++i )
for( int j = 0; j NUM_COMPLEX; ++j )
dc.work( data, dc_deque );
timing( t_start, gr::high_res_timer_now(), NUM_LOOPS*NUM_COMPLEX );
}
#define NUM_LOOPS 5
#define NUM_COMPLEX 1
#define NUM_ELEM32
Here's the summary table:
old old+c11 opt opt+c11 special
deque: 0.000701038 0.000705963 0.000235234 0.00023607 0.000234233
queue: 0.00069784 0.000705617 0.00023619 0.00023222 0.000237184
list: 0.00194583 0.00243208 0.00191296 0.00193926 0.00194809
text
size: 265022890221712 29574 23112
text
orig: 3382126502
block size:
deque: 80
queue: 80
list: 16
Original facsimile (not c++11):
dennisg@Tori-Radio:~/dc_test$ c++ -O3 main.cc
dennisg@Tori-Radio:~/dc_test$ size a.out
textdata bss dec hex filename
28902 856 280 300387556 a.out
dennisg@Tori-Radio:~/dc_test$ ./a.out
Building complex number data...
Done.
GNURadio hi-res clock tps: 10
GNURadio sizeof(gr_complex): 8
GNURadio sizeof(CPLX): 8
dc_blocker_cc_deque: delay_line size=80
deque:
Done: total_t: 35051914970, sec_t: 35.0519, t/ea: 0.000701038
dc_blocker_cc_queue: delay_line size=80
queue:
Done: total_t: 34892023951, sec_t: 34.892, t/ea: 0.00069784
dc_blocker_cc_list: delay_line size=16
list:
Done: total_t: 97291349192, sec_t: 97.2913, t/ea: 0.00194583
Original facsimile (c++11):
dennisg@Tori-Radio:~/dc_test$ c++ -O3 -std=c++11 main.cc
dennisg@Tori-Radio:~/dc_test$ size a.out
textdata bss dec hex filename
21712 848 280 228405938 a.out
dennisg@Tori-Radio:~/dc_test$ ./a.out
Building complex number data...
Done.
GNURadio hi-res clock tps: 10
GNURadio sizeof(gr_complex): 8
GNURadio sizeof(CPLX): 8
dc_blocker_cc_deque: delay_line size=80
deque:
Done: total_t: 35298153446, sec_t: 35.2982, t/ea: 0.000705963
Re: [Discuss-gnuradio] gnuradio and android
Tom, thank you for your comments. I agree to your objection that android is java based. But I think most of the gnuradio users ( not developers ) are not willing (or not able ) to code in java. gnuradio is python based at least to glue blocks together. So my conclusion would be : either support python on android or to generate java code from grc. But I'm unsure which of the many approaches of python for android will win, if any. Nevertheless both would require gnuradio based on qt5. I just ported some other qt4 based projects to qt5 and it wasn't really a great problem. So I'd try contribute to migrate gnuradio to qt5. But some questions: Do you intend to use PyQt4 ( which should support qt5, too) or do you plan PyQt5 ? And which would be the best gnuradio repository to start from ? -- Volker Am 23.07.2015 um 15:43 schrieb Tom Rondeau: On Wed, Jul 22, 2015 at 4:47 PM, Volker Schroer dl1...@gmx.de mailto:dl1...@gmx.de wrote: Hi! I watched the development of gnuradio for android. But I'm not very familiar with java, so I searched for a way to run gnuradio python scripts without or with little modifications on android. I detected the python_for_android project and wrote some recipes to run gnuradio on android. For those who are interested , see: https://github.com/dl1ksv/python-for-android At the moment I'm able to run things like dial_tone or an fm receiver using the rtl dongle. But there are a lot of things missing, in particular a gui, support of fcd(pro+), etc. So my question: Where to go from here: Introducing kivy to gnuradio for building gui's , or migrating qt5 ( a way I'd prefer ) Or is this only a nice finger exercise and of no special interest ? Comments are welcome -- Volker Volker, This is awesome that you're working on this and sharing your progress. Two things. First, I think the QT5 way is where you'd want to go. We will be migrating there, anyways, likely for the 3.8 release. Having done some work recently on the gr_filter_design tool in QT4/5, it's not a huge amount of work to go between them. We'll likely do this work off the next branch for the next API version release. Anything you can contribute to this effort would be great. As to Python, I'm skeptical how fruitful this path really is. If it's just for your own stuff, that's one thing, but Android is Java, love it or hate it. Trying to work too far away from their structure of work is dangerous, since they can decide at any moment to just kill certain efforts -- I'm a little afraid of this myself with our reliance on the NDK, even. I'm in the boat of learning Java myself to work in this world. Easier that than trying to force other modes of operation onto this beast. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable
The FFT of any signal you take always represent that signal's whole bandwidth -- so if you have a complex signal taken at 1MS/s, you'll see 1MHz of bandwidth, and if you take one of 100MS/s, you'll see 100MHz. Hence, this is not by any means a limitation of the processing (FFT) you do to the signal -- it's simply a matter of what your signal represents physically. This question really illustrates the importance of reading up on theory! Best regards, Marcus On 23.07.2015 15:48, Ashraf Younis wrote: Thank you all so much. I am able to get the single peak with the sin wave. I go through the readings when time allows, thank you for the suggestions. In the mean time, I am curious to know if GRC is able to produce a FFT for a wide band. For example, can it produce one for the FM radio channels, show its various peaks. On Thu, Jul 23, 2015 at 9:32 AM, Mike Harpe m...@mikeharpe.com mailto:m...@mikeharpe.com wrote: Seconded. I am a reader of this list. I am working to learn DSP using Gnuradio and I can tell you firsthand that you have got to do the reading. DSP is very complex math. If you don't have that background it's very slow going. I have had to re-learn trigonometry and basic calculus just to read the introductory material. It's starting to make sense after investing months of hobby time in it. This list is an invaluable resource as well. Mike Harpe, N4PLE Sellersburg, IN On Thu, Jul 23, 2015 at 9:27 AM, Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote: Hi Ashraf, A single complex sine tone will only have one spectral peak. I think you will see great profit in understanding a bit of the math/signal theory involved. GNU Radio has a suggested reading page, especially made for these cases: https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading Go through Michael Ossman's tutorial (under Math). In fact, reading through that list, there's a distinct lack of free ressources that bridge the gap between why? and what are complex signals? and digital communication basics, ie. stuff like what is the spectrum/a fourier transform. If you have access to a university library or so, grab a book on basics of signals and linear systems; like in every mature scientific community, there's some healthy dispute on what students should be having access to, but if you're looking for something relative precise, yet not too mathematical and free, have a look at Lapidoth, which is available here as a PDF: http://www.afidc.ethz.ch/A_Foundation_in_Digital_Communication/Getting_The_Book.html Read chapters 2 and 6. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] Problem with setting up gr-ieee802-11
Hi, currently I try to setup the gr-ieee802-11 package on a debian testing installation. Compiling foo and gr-ieee802-11 works fine, but when I open the wifi_phy_hier.grc in GRC it complains about ieee802_11 not being defined. Adding an import node with import ieee802_11 does not help, a node with import foo does work for foo, so I assume installation targets are correct. I also see access to the ieee802_11 files in the python dist-packages directory when running strace gnuradio-companion. Importing the ieee802_11 module in python however works. Do you have any tips how to resolve that problem? The gnuradio package version is 3.7.5-5, the python version is 2.7.9-1. Regards Bernhard Dick -- |.-.| Dipl.-Inf. Bernhard Dick |/v\| Auf dem Anger 24 | /( )\ | DE-46485 Wesel | ^^ ^^ | www.BernhardDick.de XING: https://www.xing.com/profile/Bernhard_Dick jabber: bernh...@jabber.bdick.de Tel : +49.2812068620 Mobil : +49.1747607927 FAX : +49.2812068621 USt-IdNr.: DE274728845 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT Blocks causing BER errors?
On Wed, Jul 22, 2015 at 2:11 PM, Richard Bell richard.be...@gmail.com wrote: I've come across a really unexpected correlation this morning that I'm hoping someone has an explanation for. I have a large flow graph with many QT GUI blocks because I'm debugging a design. Mostly Time Sinks and Constellations plots with a couple of Frequency Sinks thrown in. The number of points in some of the time sinks is rather large, on the order of 30k, which allows me to see several packets of data at once. What I noticed this morning, while debugging a BPSK loopback BER tester, is by disabling a number of Constellation plots which were fed by RRC filters to make the plot pretty, errors went away. The system works as you would expect a simulation with no noise or channel effects to work, perfectly. When I enable those GUI blocks, the system looses packet synchronization within the first minute consistently. Nothing is changed in the data stream between these tests. So the question is, is there a known cap on GUI plots? Like I said, I have a lot of them and some of them are plotting a large number of points. Could this be causing buffers overruns into data spaces or something scary like that? Another thought I had, could there be an identity problem in which GNU Radio at some point can't uniquely identify blocks with the same name apart from each other and thus chooses one in some default manner? I'm imagining a plotting stream getting crossed with a data stream in some way. The bottom line is all I need to do to make this system work is disable some plotting only related blocks. Is there a known plotting cap issue that I should be aware of? Thanks, Rich Rich, That is really surprising. As sinks, those blocks shouldn't be affecting anything in the data stream at all. They might back up the flow of the system if things are running too hard on your processor, but you said you were running a loopback test, so there shouldn't be any hardware I/O causing problems. I'm not sure what to make of this right now. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio and android
So is this related to Android at all? Because you have that in your subject line... On 23.07.2015 00:04, Silverfox wrote: I am running wheezy raspberrian. I tried the osmocom source feeding the FFT. The standalone version works. Alan *From:*discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org [mailto:discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] *On Behalf Of *Marcus Müller *Sent:* Wednesday, July 22, 2015 2:46 PM *To:* discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] gnuradio and android For which blocks did that happen? Also, you say raspberry Pi2, are you running android on that? Greetings, Marcus On 22.07.2015 23:37, Silverfox wrote: I complied the latest code on a Raspberry Pi 2 and the standalone applications seem to work but I ran into strange behavior when I ran gnuradio-companion. I could not get common data types to work between processes. That is, I could not resolve type conflicts between ins and outs. Any hints on what might be wrong and how to fix it? Thanks, Alan Hill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] QT Blocks causing BER errors?
My guess, educated only in that I've seen it happen before, is that one of the blocks in your flowgraph exhibits behavior which is dependent on the number of samples per work call. Loading the machine down with GUI blocks will change the number of samples GR doles out during each work call. Timing synchronizers would be the first place I'd look. --n On Thu, Jul 23, 2015 at 7:26 AM Marcus Müller marcus.muel...@ettus.com wrote: Hi Rich, being really surprised: I think it would be nice if we knew a bit more about the signal processing part of your flow graph. What does it rely on? Pure Sample Streams? Stream Tags? Message Passing? Old-Style Message queues? Best regards, Marcus On 22.07.2015 20:11, Richard Bell wrote: I've come across a really unexpected correlation this morning that I'm hoping someone has an explanation for. I have a large flow graph with many QT GUI blocks because I'm debugging a design. Mostly Time Sinks and Constellations plots with a couple of Frequency Sinks thrown in. The number of points in some of the time sinks is rather large, on the order of 30k, which allows me to see several packets of data at once. What I noticed this morning, while debugging a BPSK loopback BER tester, is by disabling a number of Constellation plots which were fed by RRC filters to make the plot pretty, errors went away. The system works as you would expect a simulation with no noise or channel effects to work, perfectly. When I enable those GUI blocks, the system looses packet synchronization within the first minute consistently. Nothing is changed in the data stream between these tests. So the question is, is there a known cap on GUI plots? Like I said, I have a lot of them and some of them are plotting a large number of points. Could this be causing buffers overruns into data spaces or something scary like that? Another thought I had, could there be an identity problem in which GNU Radio at some point can't uniquely identify blocks with the same name apart from each other and thus chooses one in some default manner? I'm imagining a plotting stream getting crossed with a data stream in some way. The bottom line is all I need to do to make this system work is disable some plotting only related blocks. Is there a known plotting cap issue that I should be aware of? Thanks, Rich ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] gnuradio and android
No. Sorry everyone. I meant ARM not android. Alan From: Marcus Müller [mailto:marcus.muel...@ettus.com] Sent: Thursday, July 23, 2015 7:26 AM To: Silverfox; GNURadio Discussion List Subject: Re: [Discuss-gnuradio] gnuradio and android So is this related to Android at all? Because you have that in your subject line... On 23.07.2015 00:04, Silverfox wrote: I am running wheezy raspberrian. I tried the osmocom source feeding the FFT. The standalone version works. Alan From: discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org [mailto:discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] On Behalf Of Marcus Müller Sent: Wednesday, July 22, 2015 2:46 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] gnuradio and android For which blocks did that happen? Also, you say raspberry Pi2, are you running android on that? Greetings, Marcus On 22.07.2015 23:37, Silverfox wrote: I complied the latest code on a Raspberry Pi 2 and the standalone applications seem to work but I ran into strange behavior when I ran gnuradio-companion. I could not get common data types to work between processes. That is, I could not resolve type conflicts between ins and outs. Any hints on what might be wrong and how to fix it? Thanks, Alan Hill ___ 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] QT Blocks causing BER errors?
Hi Rich, being really surprised: I think it would be nice if we knew a bit more about the signal processing part of your flow graph. What does it rely on? Pure Sample Streams? Stream Tags? Message Passing? Old-Style Message queues? Best regards, Marcus On 22.07.2015 20:11, Richard Bell wrote: I've come across a really unexpected correlation this morning that I'm hoping someone has an explanation for. I have a large flow graph with many QT GUI blocks because I'm debugging a design. Mostly Time Sinks and Constellations plots with a couple of Frequency Sinks thrown in. The number of points in some of the time sinks is rather large, on the order of 30k, which allows me to see several packets of data at once. What I noticed this morning, while debugging a BPSK loopback BER tester, is by disabling a number of Constellation plots which were fed by RRC filters to make the plot pretty, errors went away. The system works as you would expect a simulation with no noise or channel effects to work, perfectly. When I enable those GUI blocks, the system looses packet synchronization within the first minute consistently. Nothing is changed in the data stream between these tests. So the question is, is there a known cap on GUI plots? Like I said, I have a lot of them and some of them are plotting a large number of points. Could this be causing buffers overruns into data spaces or something scary like that? Another thought I had, could there be an identity problem in which GNU Radio at some point can't uniquely identify blocks with the same name apart from each other and thus chooses one in some default manner? I'm imagining a plotting stream getting crossed with a data stream in some way. The bottom line is all I need to do to make this system work is disable some plotting only related blocks. Is there a known plotting cap issue that I should be aware of? Thanks, Rich ___ 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] Fwd: Creating a FFT plot like the one in this youtube variable
Thank you all so much. I am able to get the single peak with the sin wave. I go through the readings when time allows, thank you for the suggestions. In the mean time, I am curious to know if GRC is able to produce a FFT for a wide band. For example, can it produce one for the FM radio channels, show its various peaks. On Thu, Jul 23, 2015 at 9:32 AM, Mike Harpe m...@mikeharpe.com wrote: Seconded. I am a reader of this list. I am working to learn DSP using Gnuradio and I can tell you firsthand that you have got to do the reading. DSP is very complex math. If you don't have that background it's very slow going. I have had to re-learn trigonometry and basic calculus just to read the introductory material. It's starting to make sense after investing months of hobby time in it. This list is an invaluable resource as well. Mike Harpe, N4PLE Sellersburg, IN On Thu, Jul 23, 2015 at 9:27 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Ashraf, A single complex sine tone will only have one spectral peak. I think you will see great profit in understanding a bit of the math/signal theory involved. GNU Radio has a suggested reading page, especially made for these cases: https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading Go through Michael Ossman's tutorial (under Math). In fact, reading through that list, there's a distinct lack of free ressources that bridge the gap between why? and what are complex signals? and digital communication basics, ie. stuff like what is the spectrum/a fourier transform. If you have access to a university library or so, grab a book on basics of signals and linear systems; like in every mature scientific community, there's some healthy dispute on what students should be having access to, but if you're looking for something relative precise, yet not too mathematical and free, have a look at Lapidoth, which is available here as a PDF: http://www.afidc.ethz.ch/A_Foundation_in_Digital_Communication/Getting_The_Book.html Read chapters 2 and 6. Best regards, Marcus ___ 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] gnuradio and android
did this post somehow get missed? From: ikjtel Subject: [Discuss-gnuradio] patches and instructions for adding python and numpy to GNU Radio for android Date: Tue, 9 Jun 2015 23:10:36 + (UTC) http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00150.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD
On 22.07.2015 16:49, Jose Perez wrote: Thanks again Marcus. Now I am using the Head block... I don't know which number I have to put in Num Items to get out my file with no repeated information. I can understand this number to a Sin/Cosine function or a random source that I can limit how many samples I want ... but for a file I don't know and how calculate this number. Can you help me with this? Jose, I suggest you start a new thread for other, specific questions. Also, you seem to be struggling with some of the basics, may I suggest you take a look at our guided tutorials: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials Cheers, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable
Thank you for the examples and the explanation. I believe I understand. Sticking with a square wave or anything that involves a sinc envelop will always raise the spectrum. Is there something that I can transmit that won't let this occur? Perhaps something that will peak in a specific area in the FFT. Sorry if the question might seem elementary, my understanding of signals does not go very far. To be clear, I want to know if I can display a graph that will show a peak a certain region due to a detection of signal. On Wed, Jul 22, 2015 at 4:55 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Ashraf, I don't know what frequency f_squarewave your square wave has, but rectangular signals have sinc-shaped envelope, with peaks every f_squarewave. Having a sinc envelope especially means it exists over the whole nyquist band -- so that explains why you see your complete spectrum rise! I think what you should do is have a look at the spectrum of your *transmit* signal. This will make it easier to understand what you see at the receiver. Try this: http://i.imgur.com/EARpJLx.png [image: flowgraph with squarewave of f_sample/32] http://imgur.com/EARpJLx so, a squarewave with frequency of f_sample/32 (remember, there's no real frequencies in DSP -- this really just tells GNU Radio that a period is 32 samples long). Important: the QT sink is set to have an FFT length of 1024 points. You should see this: http://i.imgur.com/33xrCl6.png Now, if you have a look at this spectrum, you'll notice deep wells between the peaks, which aren't there in the receive PSD, right? There's a simple reason for that: In the simulation / the TX spectrum, your f_squarewave is probably an integer factor of f_sample. This means that the period is a whole number of samples, and that whole number of samples also happens to be an integer factor of your FFT length! Therefore, your signal is perfectly periodic (as far as the observer can tell), and hence, has line spectrum characteristics. Now, we'll play around with the frequency of the square wave: http://imgur.com/Kduv5fL set it to f_sample/32/2**0.5 ; the root of 2 is not a rational number, so no FFT window in this world could transform this without leakage. So you get this: http://imgur.com/1Fkl8f8 Looking familiar? Now, these are extremes. But the problem here is that frequency synchronization between your N210 and B200 will not be perfect -- hence, on the receiver side, the signal period might not be as exactly the integer factor that you have on the TX side, and you see the inter-peak leakage. I hope that has explained the most of this phenomenom. Best regards, Marcus On 22.07.2015 20:40, Ashraf Younis wrote: -- Forwarded message -- From: Ashraf Younis shraff...@gmail.com Date: Wed, Jul 22, 2015 at 2:39 PM Subject: Re: [Discuss-gnuradio] Creating a FFT plot like the one in this youtube variable To: Marcus Müller marcus.muel...@ettus.com I apologize for the way it seems I'm relaying information. I will attempt to give you all new information with your perspective in mind. I have two screenshots now, they have a fixed y-axis from 0 to -100 dB. The first is the graph that is displayed when there is no signal transmitted and the second is when there is one being transmitted. From the screenshots it is evident that the signal raises all of the graph's values, instead of where the signal is being transmitted. The receiving gain is set to 1. I deleted the bandwidth QT GUI Entry since my I did not know what it was doing. The receiver is is a USRP B200 The signal I am transmitting on the USRP 2921 is a simply square wave. the IQ rate is 100k, the antenna is a vert 2450 dual-band, it is set to 10 gain. It was transmitting in the same channel the B200 is receiving. I just want to make sure we're headed in the right direction. I want to use a wide band spectrum sense graph On Wed, Jul 22, 2015 at 1:55 PM, Marcus Müller marcus.muel...@ettus.commarcus.muel...@ettus.com wrote: sure :) On 22.07.2015 19:45, Ashraf Younis wrote: Excuse me, it was my mistake. I sent it as an attachment, is that okay? On Wed, Jul 22, 2015 at 1:29 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Ashraf, your mail is only 8.5kB large -- did you possibly forgot to include links to the images? Best regards, Marcus On 22.07.2015 19:28, Ashraf Younis wrote: Thank you for replying. I included some screenshots of the program. One is of the block diagram and the other is of the graph itself. I am generating a signal using a different device and program. having only one B200 has prompted me to use this method. I am using a NI USRP-2920 with lab view to generate a signal On Wed, Jul 22, 2015 at 12:01 PM, Marcus Müller marcus.muel...@ettus.commarcus.muel...@ettus.com wrote: Hi Ashraf, If you've configured the USRP source correctly, you're very likely actually displaying the spectrum your
Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable
Seconded. I am a reader of this list. I am working to learn DSP using Gnuradio and I can tell you firsthand that you have got to do the reading. DSP is very complex math. If you don't have that background it's very slow going. I have had to re-learn trigonometry and basic calculus just to read the introductory material. It's starting to make sense after investing months of hobby time in it. This list is an invaluable resource as well. Mike Harpe, N4PLE Sellersburg, IN On Thu, Jul 23, 2015 at 9:27 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Ashraf, A single complex sine tone will only have one spectral peak. I think you will see great profit in understanding a bit of the math/signal theory involved. GNU Radio has a suggested reading page, especially made for these cases: https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading Go through Michael Ossman's tutorial (under Math). In fact, reading through that list, there's a distinct lack of free ressources that bridge the gap between why? and what are complex signals? and digital communication basics, ie. stuff like what is the spectrum/a fourier transform. If you have access to a university library or so, grab a book on basics of signals and linear systems; like in every mature scientific community, there's some healthy dispute on what students should be having access to, but if you're looking for something relative precise, yet not too mathematical and free, have a look at Lapidoth, which is available here as a PDF: http://www.afidc.ethz.ch/A_Foundation_in_Digital_Communication/Getting_The_Book.html Read chapters 2 and 6. Best regards, Marcus ___ 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] Problem with setting up gr-ieee802-11
Hi, you don't need the import blocks. The rest is pretty strange. First I thought that you PYTHONPATH in GRC is different than in your console (like you just adapted it but did not restart GRC), but that does not make sense with the strace output you mention. Is a script generated? If so, did you try to execute it from the command line? Best, Bastian On 07/23/2015 04:08 PM, Bernhard Dick wrote: Hi, currently I try to setup the gr-ieee802-11 package on a debian testing installation. Compiling foo and gr-ieee802-11 works fine, but when I open the wifi_phy_hier.grc in GRC it complains about ieee802_11 not being defined. Adding an import node with import ieee802_11 does not help, a node with import foo does work for foo, so I assume installation targets are correct. I also see access to the ieee802_11 files in the python dist-packages directory when running strace gnuradio-companion. Importing the ieee802_11 module in python however works. Do you have any tips how to resolve that problem? The gnuradio package version is 3.7.5-5, the python version is 2.7.9-1. Regards Bernhard Dick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD
Jose, If you set your file source to repeat it will produce an infinite amount of samples, just like a sine would. If you know you want to produce 10,000 packets (and see how many are received), you only need to 96*10,000 samples. Hence, you'll use the head block after the file source and set it to 960,000. Best regards, Marcus On 23.07.2015 01:49, Jose Perez wrote: Thanks again Marcus. Now I am using the Head block... I don't know which number I have to put in Num Items to get out my file with no repeated information. I can understand this number to a Sin/Cosine function or a random source that I can limit how many samples I want ... but for a file I don't know and how calculate this number. Can you help me with this? My size's file: 120 bytes ; packet length: 96 Thanks so much Cheers, José On 16.07.2015 18:52, Marcus Müller-3 wrote: As I mentioned, use the head block. BR, Marcus -- View this message in context: http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54974.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] OFDM example from gr-digital with UHD
Jose, If you set your file source to repeat it will produce an infinite amount of samples, just like a sine would. If you know you want to produce 10,000 packets (and see how many are received), you only need to 96*10,000 samples. Hence, you'll use the head block after the file source and set it to 960,000. Best regards, Marcus On 23.07.2015 01:49, Jose Perez wrote: Thanks again Marcus. Now I am using the Head block... I don't know which number I have to put in Num Items to get out my file with no repeated information. I can understand this number to a Sin/Cosine function or a random source that I can limit how many samples I want ... but for a file I don't know and how calculate this number. Can you help me with this? My size's file: 120 bytes ; packet length: 96 Thanks so much Cheers, José On 16.07.2015 18:52, Marcus Müller-3 wrote: As I mentioned, use the head block. BR, Marcus -- View this message in context: http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54974.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
[Discuss-gnuradio] Type-selectable OOT Block C++
Hello all, I was building my own block in C++ and I have one doubt about it. Some times my block has to work with float streams and sometimes with complex streams. There is one single input and output. I have implemented separately: sync_ff_impl.cc and sync_cc_impl.cc each one with its respective xml file to use it in gnuradio-companion. Now I wanted to have only one xml so that the block is type-selectable. Is there any template or way to make it? I have been checking the code from other type-selectable blocks but it did not help much. If there is some interest about what the block does, it basically adds a predefined preamble to the incoming packets, so that in reception the receiver is able to know when the packet starts. Thanks before hand. Best regards, Gabriele Galiero ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
