[Discuss-gnuradio] The GSoC project on LDPC codes.
Hello Everyone, I'm Manu, one of the GSoC student under GNU Radio this year. I worked on LDPC Codes, mentored by Jens. Another GSoC student Tracie also worked on LDPC Codes this summer. We both worked such that there is minimum duplicates and both our work complemented each other. As the final output I have an Out Of Tree module gr-ldpc which implements a generic decoder and a generic encoder for LDPC codes. The encoder block expects an LDPC code specified in alist[1] format. There are two decoder blocks, one for Binary Symmetric Channel model and another for AWGN Channel model. The decoder implements the sum product algorithm[2]. Also two algorithms for construction of LDPC codes have been implemented. I prepared a video presentation of my work to be presented at GR Con 2013, and the presentation is available at http://home.iitb.ac.in/~manu.ts/presentation.pdf (presentation) and http://home.iitb.ac.in/~manu.ts/presentation.ogv (video). The gr-ldpc OOT module is available at https://github.com/manuts/gr-ldpc. During the project we also worked on porting the codes to fecapi, which is a wonderful framework for developing FEC blocks. I'm yet to finish porting gr-ldpc to FECAPI framework. Overall, GSoC 2013 was a great experience. Frankly, I was not able to meet all the goals set in my proposal. I hope to fulfill all that I promised in the future. The encoder/decoder blocks have to be optimized. And in future I intend to bring more of Coding techniques into fecapi framework. There is lot many people to whom I'm thankful for this wonderful experience. I don't pick any name just so that the mail is concise as possible. I also thank the entire GNU Radio community for this opportunity. Hoping for the feedbacks on the module, -- Manu T S [1] http://www.inference.phy.cam.ac.uk/mackay/codes/alist.html [2] http://www.cs.toronto.edu/~radford/ftp/LDPC-2012-02-11/decoding.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Lock/Unlock segfaulting
The temporary fix suggested elsewhere with substituting lock() with stop() followed by wait() and unlock() with start() was tested and works fine!!! For now this is sufficient for what I want to do, although the stop/wait/start method works only on the entire top_block and not on individual (hier2) blocks as the lock/unlock (is supposed to) work thanks everyone for the help, Achilleas On Fri, Oct 4, 2013 at 6:45 PM, Achilleas Anastasopoulos wrote: > I have uploaded a bare minimum example that still has this problem: > > sinusoid--> throtle --> (ON or OFF block) --> null sink > > http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test1.py > > And here is all the output of gdb (it segfaults in unlock() ): > > > > (gdb) backtrace > #0 0x700b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 () >from /usr/local/lib64/libvolk.so.0.0.0 > #1 0x7083910a in gr::blocks::multiply_const_cc_impl::work(int, > std::vector >&, std::vector std::allocator >&) () >from /usr/local/lib64/libgnuradio-blocks-3.7.2git.so.0.0.0 > #2 0x70401fc7 in gr::sync_block::general_work(int, > std::vector >&, std::vector std::allocator >&, std::vector > >&) () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 > #3 0x703caca8 in gr::block_executor::run_one_iteration() () >from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 > #4 0x70410ee6 in > gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) () > from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 > #5 0x703ff38e in gr::tpb_container::operator()() () >from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 > #6 0x703ff58e in > gr::thread::thread_body_wrapper::operator()() > () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 > #7 0x703b320f in > boost::detail::thread_data >::run() () >from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 > #8 0x003349a11629 in thread_proxy () from > /lib64/libboost_thread-mt.so.1.50.0 > #9 0x003340a07d15 in start_thread () from /lib64/libpthread.so.0 > #10 0x00333fef253d in clone () from /lib64/libc.so.6 > > > > > > > > > On Fri, Oct 4, 2013 at 6:00 PM, Marcus Müller wrote: > >> Hi Achilleas, >> >> after skimming through your code, I found no obvious mistakes so far. >> My guess was that under some circumstances, you connect or disconnect a >> connection twice or something similarly wicked happens, but I can't see >> why that should happen. >> Can you supply us with a backtrace, generated by GDB? >> (gdb --args python onoff_flat_test.py; then type "run" as soon >> as gdb is ready, then type "backtrace" after the program >> segfaulted) >> >> Greetings >> Marcus >> On Fri, 2013-10-04 at 17:46 -0400, Achilleas Anastasopoulos wrote: >> > >> > >> > I have a pyhton program (see >> > http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py) >> > that based on a button chooser (on/off) rearranges itself. >> > I use lock/unlock to do the disconnection/reconnection. >> > However, I always get segfaults after a couple of changes. >> > >> > >> > The graph is pretty simple: >> > >> > >> > A complex sinusodial source + noise (throttled) goes to either: >> > >> > >> > ON) multiplication by 2 and complex to mag squared >> > >> > or >> > >> > OFF) multiplication by 0 and complex to mag squared >> > >> > >> > and then to a null sink. >> > >> > >> > >> > I would really appreciate some input because I am kind of lost as to >> > what >> > >> > is going wrong. >> > >> > thanks in advance, >> > Achilleas >> > >> > >> > ___ >> > 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] gr_firdes.cc/firdes.cc - window functions - flawe
On Mon, Oct 7, 2013 at 12:02 AM, bob wole wrote:
> We installed gnuradio 3.6.3 using gnruadio build script. We can't change the
> gnuradio version currently. How can we apply this patch to our installation.
> What commands should we run? We don't use git.
>
> --
> Bob
Hi Bob,
You'll use the 'patch' command for this.
1. Download the gnuradio-window-patch.diff from Chris' post (into
directory: ~/Downloads).
2. cd into the GNU Radio source directory (I'll assume the directory:
~/gnuradio-3.6.3)
3. Run: 'patch -p1 < ~/Downloads/gnuradio-window-patch.diff'
If it works, it will say:
patching file gnuradio-core/src/lib/general/gr_firdes.cc
patching file gr-filter/lib/firdes.cc
I just tried these steps on my own system using the 3.6.3 tarball from
our website.
However, I noticed that there is a problem with the patch in the
Kaiser window when the number of taps in the filter is odd. The patch
that I applied to maint/master/next (all 3.7) takes account of this
and works with both even and odd number of taps.
Also, many QA failures will occur with the patch because the Hilbert
transform assumed the use of a rectangular window. The results were
actually calculated using a Hamming window because of the bug, so
using the actual rectangular window will make the results different.
These are the QA failures I get with 3.6.3:
The following tests FAILED:
41 - qa_filter_delay_fc (Failed)
78 - qa_hilbert (Failed)
82 - qa_firdes (Failed)
92 - qa_filter_delay_fc (Failed)
101 - qa_hilbert (Failed)
Errors while running CTest
Again, the patch that I applied last week for 3.7 accounts for this
and fixes the QA code. I think it does so in a more elegant way, too,
and reduces many of our QA tests to comparing against a set of 'gold'
results to actually properly calculating the results.
To summarize. The patch from Chris will be ok (though watch for a
Kaiser window with an odd number of taps) but will cause the QA to
fail. You can safely ignore that as it's expected.
Tom
> On Sun, Oct 6, 2013 at 12:39 PM, KB3CS - Chris wrote:
>> (If you just want to cut to the chase, the diff against 3.6.5.1 is
>> attached)
>>
>> How i got here: Contemplating some filters using gnuradio-companion with
>> a
>> simple flowgraph (simple enough to describe in words alone). Noticed the
>> frequency response with a Rectangular filter was exactly the same as with
>> a
>> Hamming filter and also the response with a Kaiser filter (while varying
>> Beta) seemed quite wrong.
>>
>> The flowgraph: noise source -> throttle -> filter -> FFT
>> really basic. used the "convenience" blocks which are wrappers for
>> firdes.
>>
>> After quite a while of scratching my head at the odd results observed,
>> then
>> checking (and double-checking) Oppenheim[1999] and others, I wrote a
>> little
>> python to have a direct look at the window function coefficients:
>>
>> #!/usr/bin/env python
>> from gnuradio import gr, audio
>> from math import pi
>>
>> sample_rate = 192000
>> ntaps = 16
>>
>> #channel_coeffs =
>> gr.firdes.low_pass(1.0,sample_rate,50e3,4e3,gr.firdes.WIN_HAMMING,beta)
>>
>> #print channel_coeffs
>>
>> #channel_coeffs =
>> gr.firdes.low_pass(1.0,10,1,1,gr.firdes.WIN_HAMMING,beta)
>>
>> #print channel_coeffs
>>
>> print "\n\nRectangular window function for {} samples\n".format(ntaps)
>>
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_RECTANGULAR,ntaps,0)
>>
>> print win_coeffs
>>
>> print "\n\nHamming window function for {} samples\n".format(ntaps)
>>
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_HAMMING,ntaps,0)
>>
>> print win_coeffs
>>
>> print "\n\nKaiser window function for {} samples\n".format(ntaps)
>>
>> alpha = 1.0
>> print "Alpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> alpha = 2.5
>> print "\nAlpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> alpha = 8.0
>> print "\nAlpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> alpha = 20.0
>> print "\nAlpha = {}\n".format(alpha)
>> win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)
>>
>> print win_coeffs
>>
>> print "\nDone\n"
>>
>> .. and here's the essential extract of output from unmodified v3.6.5.1
>> source:
>>
>> Rectangular window function for 16 samples
>>
>> (0.0799821186066, 0.11976908892393112, 0.23219992220401764,
>> 0.39785218238830566, 0.5880830883979797, 0.769809265137,
>> 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,
>> 0.9121478199958801, 0.769809265137, 0.5880830883979797,
>> 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,
>> 0.0799821186066)
>>
>>
>> Hamming window function for 16 samples
>>
>> (0.0799821186066, 0.11976908892393112, 0.23219992220401764,
>> 0.39785218238830566, 0.5880830883979797, 0.769809265137,
>> 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,
>>
Re: [Discuss-gnuradio] Lock/Unlock segfaulting
On Mon, Oct 7, 2013 at 11:55 AM, Achilleas Anastasopoulos wrote: > The temporary fix suggested elsewhere with > substituting lock() with stop() followed by wait() > and unlock() with start() was tested and works fine!!! > > For now this is sufficient for what I want to do, > although the stop/wait/start method > works only on the entire top_block and not on individual (hier2) blocks > as the lock/unlock (is supposed to) work > > thanks everyone for the help, > Achilleas Achilleas, Can you open an Issues ticket for this on gnuradio.org with your example script? I think that I might know the cause of this problem. Just want to make sure it's documented and doesn't get lost. Tom > On Fri, Oct 4, 2013 at 6:45 PM, Achilleas Anastasopoulos > wrote: >> >> I have uploaded a bare minimum example that still has this problem: >> >> sinusoid--> throtle --> (ON or OFF block) --> null sink >> >> http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test1.py >> >> And here is all the output of gdb (it segfaults in unlock() ): >> >> >> >> (gdb) backtrace >> #0 0x700b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 () >>from /usr/local/lib64/libvolk.so.0.0.0 >> #1 0x7083910a in gr::blocks::multiply_const_cc_impl::work(int, >> std::vector >&, std::vector> std::allocator >&) () >>from /usr/local/lib64/libgnuradio-blocks-3.7.2git.so.0.0.0 >> #2 0x70401fc7 in gr::sync_block::general_work(int, >> std::vector >&, std::vector> std::allocator >&, std::vector >&) >> () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >> #3 0x703caca8 in gr::block_executor::run_one_iteration() () >>from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >> #4 0x70410ee6 in >> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) () >> from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >> #5 0x703ff38e in gr::tpb_container::operator()() () >>from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >> #6 0x703ff58e in >> gr::thread::thread_body_wrapper::operator()() >> () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >> #7 0x703b320f in >> boost::detail::thread_data >::run() () >>from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >> #8 0x003349a11629 in thread_proxy () from >> /lib64/libboost_thread-mt.so.1.50.0 >> #9 0x003340a07d15 in start_thread () from /lib64/libpthread.so.0 >> #10 0x00333fef253d in clone () from /lib64/libc.so.6 >> >> >> >> >> >> >> >> >> On Fri, Oct 4, 2013 at 6:00 PM, Marcus Müller wrote: >>> >>> Hi Achilleas, >>> >>> after skimming through your code, I found no obvious mistakes so far. >>> My guess was that under some circumstances, you connect or disconnect a >>> connection twice or something similarly wicked happens, but I can't see >>> why that should happen. >>> Can you supply us with a backtrace, generated by GDB? >>> (gdb --args python onoff_flat_test.py; then type "run" as soon >>> as gdb is ready, then type "backtrace" after the program >>> segfaulted) >>> >>> Greetings >>> Marcus >>> On Fri, 2013-10-04 at 17:46 -0400, Achilleas Anastasopoulos wrote: >>> > >>> > >>> > I have a pyhton program (see >>> > http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py) >>> > that based on a button chooser (on/off) rearranges itself. >>> > I use lock/unlock to do the disconnection/reconnection. >>> > However, I always get segfaults after a couple of changes. >>> > >>> > >>> > The graph is pretty simple: >>> > >>> > >>> > A complex sinusodial source + noise (throttled) goes to either: >>> > >>> > >>> > ON) multiplication by 2 and complex to mag squared >>> > >>> > or >>> > >>> > OFF) multiplication by 0 and complex to mag squared >>> > >>> > >>> > and then to a null sink. >>> > >>> > >>> > >>> > I would really appreciate some input because I am kind of lost as to >>> > what >>> > >>> > is going wrong. >>> > >>> > thanks in advance, >>> > Achilleas >>> > >>> > >>> > ___ >>> > 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] Lock/Unlock segfaulting
On Mon, Oct 7, 2013 at 12:10 PM, Tom Rondeau wrote: > On Mon, Oct 7, 2013 at 11:55 AM, Achilleas Anastasopoulos > wrote: >> The temporary fix suggested elsewhere with >> substituting lock() with stop() followed by wait() >> and unlock() with start() was tested and works fine!!! >> >> For now this is sufficient for what I want to do, >> although the stop/wait/start method >> works only on the entire top_block and not on individual (hier2) blocks >> as the lock/unlock (is supposed to) work >> >> thanks everyone for the help, >> Achilleas > > Achilleas, > > Can you open an Issues ticket for this on gnuradio.org with your > example script? I think that I might know the cause of this problem. > Just want to make sure it's documented and doesn't get lost. > > Tom Also, make sure to record what version you're running. I feel like I fixed this already. Tom >> On Fri, Oct 4, 2013 at 6:45 PM, Achilleas Anastasopoulos >> wrote: >>> >>> I have uploaded a bare minimum example that still has this problem: >>> >>> sinusoid--> throtle --> (ON or OFF block) --> null sink >>> >>> http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test1.py >>> >>> And here is all the output of gdb (it segfaults in unlock() ): >>> >>> >>> >>> (gdb) backtrace >>> #0 0x700b80a0 in volk_32fc_s32fc_multiply_32fc_a_sse3 () >>>from /usr/local/lib64/libvolk.so.0.0.0 >>> #1 0x7083910a in gr::blocks::multiply_const_cc_impl::work(int, >>> std::vector >&, std::vector>> std::allocator >&) () >>>from /usr/local/lib64/libgnuradio-blocks-3.7.2git.so.0.0.0 >>> #2 0x70401fc7 in gr::sync_block::general_work(int, >>> std::vector >&, std::vector>> std::allocator >&, std::vector >&) >>> () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >>> #3 0x703caca8 in gr::block_executor::run_one_iteration() () >>>from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >>> #4 0x70410ee6 in >>> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) () >>> from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >>> #5 0x703ff38e in gr::tpb_container::operator()() () >>>from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >>> #6 0x703ff58e in >>> gr::thread::thread_body_wrapper::operator()() >>> () from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >>> #7 0x703b320f in >>> boost::detail::thread_data >::run() () >>>from /usr/local/lib64/libgnuradio-runtime-3.7.2git.so.0.0.0 >>> #8 0x003349a11629 in thread_proxy () from >>> /lib64/libboost_thread-mt.so.1.50.0 >>> #9 0x003340a07d15 in start_thread () from /lib64/libpthread.so.0 >>> #10 0x00333fef253d in clone () from /lib64/libc.so.6 >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Oct 4, 2013 at 6:00 PM, Marcus Müller wrote: Hi Achilleas, after skimming through your code, I found no obvious mistakes so far. My guess was that under some circumstances, you connect or disconnect a connection twice or something similarly wicked happens, but I can't see why that should happen. Can you supply us with a backtrace, generated by GDB? (gdb --args python onoff_flat_test.py; then type "run" as soon as gdb is ready, then type "backtrace" after the program segfaulted) Greetings Marcus On Fri, 2013-10-04 at 17:46 -0400, Achilleas Anastasopoulos wrote: > > > I have a pyhton program (see > http://web.eecs.umich.edu/~anastas/docs/onoff_flat_test.py) > that based on a button chooser (on/off) rearranges itself. > I use lock/unlock to do the disconnection/reconnection. > However, I always get segfaults after a couple of changes. > > > The graph is pretty simple: > > > A complex sinusodial source + noise (throttled) goes to either: > > > ON) multiplication by 2 and complex to mag squared > > or > > OFF) multiplication by 0 and complex to mag squared > > > and then to a null sink. > > > > I would really appreciate some input because I am kind of lost as to > what > > is going wrong. > > thanks in advance, > Achilleas > > > ___ > 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] conversion from long integer to byte/char
On Sun, Oct 6, 2013 at 6:45 PM, Arturo Rinaldi wrote: > Hi folks, > > i was wondering if it's possible to operate a type conversion from long > integer (green color in GRC) to byte/char (purple color in GRC) with the > existing gnuradio blocks. > > I'm running the 3.6.5.1 tarball, any suggestions ? Thanks in advance. > > Kind Regards, > > Arturo Right now, there is no direct conversion from int to char. To do it with current blocks, you'd have to do int_to_float followed by float_to_char. It should be easy for your to take these and create a single block out of them for your purposes. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_firdes.cc/firdes.cc - window functions - flawe
$ git diff v3.6.3 HEAD gr-filter/lib/firdes.cc (but modified since you
remain @ v3.6.3)
diff --git a/gr-filter/lib/firdes.cc b/gr-filter/lib/firdes.cc
index 5c3320d..d55a4ba 100644
--- a/gr-filter/lib/firdes.cc
+++ b/gr-filter/lib/firdes.cc
@@ -746,6 +746,7 @@ namespace gr {
case WIN_RECTANGULAR:
for(int n = 0; n < ntaps; n++)
taps[n] = 1;
+break;
case WIN_HAMMING:
for(int n = 0; n < ntaps; n++)
@@ -774,16 +775,13 @@ namespace gr {
double IBeta = 1.0/Izero(beta);
double inm1 = 1.0/((double)(ntaps));
double temp;
- //fprintf(stderr, "IBeta = %g; inm1 = %g\n", IBeta, inm1);
- for(int i=0; i
0");
+ throw std::out_of_range("gr_firdes check failed: transition_width >
0");
}
void
.. but don't make the #include file changes in your v3.6.3 and you should
change the version number (VERSION_INFO_MAINT_VERSION) in CMakeLists.txt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] conversion from long integer to byte/char
thank you very much tom..piece of cake ! ! ! ^_^ 2013/10/7 Tom Rondeau > On Sun, Oct 6, 2013 at 6:45 PM, Arturo Rinaldi > wrote: > > Hi folks, > > > > i was wondering if it's possible to operate a type conversion from long > > integer (green color in GRC) to byte/char (purple color in GRC) with the > > existing gnuradio blocks. > > > > I'm running the 3.6.5.1 tarball, any suggestions ? Thanks in advance. > > > > Kind Regards, > > > > Arturo > > Right now, there is no direct conversion from int to char. To do it > with current blocks, you'd have to do int_to_float followed by > float_to_char. It should be easy for your to take these and create a > single block out of them for your purposes. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GR Community Development / User Experience Working Group
Dear community, at the last GRCon we discussed the user experience regarding GNU Radio. A pretty huge group of people came together for a very productive discussion on how the user experience can be improved. Our method of choice was to go through the "life cycle" of a GNU Radio developer, starting at the first time they enter gnuradio.org, through installation issues and the first time they start using GNU Radio. We clearly did not have enough time, which is why I would like to invite the mailing list to continue the discussion in this thread. But first, let me recap the results from the GRCon working group. I will give an overview here; for the details, head over to the new wiki page at http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCon13Community Web Site Clearly, the web site is extremely important. We need to make sure we make a good first impression, but then also provide a useful page for everyone. Even within our group, we had nearly as many opinions as there were people. A lot of us agreed the start page has too much content, but as to what is relevant and what can go to sub-pages, there was no consensus. Installation In the future, we want to steer novice users clear from source installs, and recommend using binary installs where sensible. As soon as 3.7 releases hit the major distros, this will be very easy for most users. Since for a long time, source installs were really the only viable option (which gave cause for tools such as build_gnuradio), people have been getting used to this even though for many cases, source installs are really not a requirement. Of course, at some stage, they are necessary, but we want to make sure people only do source installs when they actually hit this stage. We definitely need to harden pybombs and get the word out to use that. However, pybombs needs to be installed through a git checkout, which is not much more difficult than doing a GR source install. We're not quite sure how to fix this. Something we never considered is that people might actually be after one of the many great OOT-modules (e.g. gr-ais), and simply consider GNU Radio a dependency. This should be reflected in the install page. Examples As with most projects, examples are one of the most important elements when learning GNU Radio. Unfortunately, we sometimes don't treat our examples very well. Sometimes, they don't even work, but in any case, there could be more examples available. This is something new users can do: Create good examples, and test the old ones. We currently don't have automated QA mechanisms for our examples, so we need real humans to have a look at them for us. There was an idea to integrate the examples into GRC, such that we add a drop down menu which accesses all the installed examples. GRC has received a very long wishlist though, so don't expect to see this any time soon (or perhaps add it yourself :). Beginners who are trying to learn GNU Radio through examples should not be shy to complain about non-working examples, but rather treat them like any other bug. This is actually a very nice way to become a contributor, by filing tickets against broken examples, fixing them or adding new ones. Tutorials = Of course, tutorials are also a major component when learning a tool such as GNU Radio. It was agreed that there are not enough entry-level tutorials, which also should be accompanied with GRC files. Luckily, we found some volunteers to work on this. GNU Radio Companion === An entire sub-working group was created to discuss development on GRC. There are a lot of expectations towards GRC; fortunately, there are also a lot of volunteers to help improve it. A separate wiki page was created to coordinate dev on the companion: http://gnuradio.org/redmine/projects/gnuradio/wiki/GRCroadmap News A surprisingly easy wish was to have more output on the newsletter than release notes. We'll try our best! OK, those were the topics discussed at GRCon13. As I said, feel free to comment or discuss! Martin -- 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 pgprNYl1PF4e3.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
