Re: [Discuss-gnuradio] SOC and a couple of ideas

[Marcus Müller]

Hi Greg,

:) been biting my tongue long enough, and I think there's a metric ton
of consensus to be applied here:

So, yes, everyone I've ever talked to would love GNU Radio to be more
useful in fully usable applications. And: everyone, including me, hates
the fact that setup, getting started and doing the first useful thing
are quite a hurdle. Furthermore, none of us thinks you're nuts :)

I'm not sure what you refer to when you say "production system"; I
personally do think GNU Radio's primary purpose is being a library to do
your SDR processing, and that library integrating itself greatly in a
non-obstructive way as component in bigger applications. I also think
that we're not doing a great job at that – it's really not that we see a
load of applications where GNU Radio isn't the central part, instead of
e.g. the user interface being more of a periphery to GR.

The most visible actual application that the GR project "produces" is
pretty certainly GNU Radio Companion – and I think there's good reason
to make that as polished, clean and easy to use as possible. We need
more prominent examples of well-working GRC flow graphs, too.

What I really think is missing most is a good-practice approach and a
popular example of how to design a flow graph in GRC, and use it to do
something cool – gr-air-modes' modes_gui comes to mind, but I think that
has reached a certain age and might need a facelift, and maybe a bit of
a different approach here and there on connecting GUI, logic and
GR-based processing. It's a great piece of software (kudos to Nick for
writing it!), but it was clearly written by someone who loves SDR and
understands GR very well, rather than by someone who uses one of the
popular application development frameworks (be that Qt/QtCreator, Visual
Studio, Android Studio, Node.js/Django/Ruby on Rails/…(whatever is
popular with the web these days)) and integrates a signal processing
backend into a great frontend that they designed first.

The very same goes for best-practice guides on what we've talked about
before – there's a load of data scientists, physicists, … that would
love to have a great signal processing framework that integrates easily
with R/Hadoop/paraview/SPSS, but neither does the project as is offer
any of these interfaces, nor a guide on how to write one, nor am I aware
of any more or less universal adapter.

I think it's worth promoting Tim's Theano / TensorFlow interfacing
blocks – they do exactly that: being an easy-to-use adapter between
something non-SDRy people experts of a different field (in this case:
DNNs) are proficient with and GNU Radio. To my shame, I haven't worked
with those.

What I personally, but I haven't discussed that so far, don't think is
that we should be selling GR as an application itself – to me, it's a
set of building blocks and tools to build good DSP/SDR applications.
Much like noone sells Android Studio as a user application. I do see
your point that GRC has really become that: something that people that
might not be overly DSP-experienced or even computer-savvy can use.

I'd actually like to hear what Sebastian and co would have to say about
that, since I definitely haven't worked on GRC anywhere near to
comparable as much, but it might actually be worth considering to more
clearly make a distinction between GRC and GR.

I really think this is an interesting direction – I think if we came up
with a few /concrete/ ideas on what to put on the GRC ideas page for
this, we'd help the project the most right now; mentoring org
application deadline is Thursday.

Best regards,

Marcus

On 02/05/2017 12:25 AM, Gregory Ratcliff wrote:
> Greetings all,
>
> I suspect Marcus will answer this, but a discussion might be worthwhile. 
>
> There seem to be two areas within this most fantastic system that I see some 
> evolution (and SOC might help):
>
> 1. It seems gnuradio is being used for what it is, rather than a toolset to 
> create something to use.  Hopefully, this makes sense, but I can see that 
> over the next few years gnuradio should morph into an actual production 
> system, that draws in _users_.  I’m sure many of you know what I mean.
>
> 2. Because of the above class of users joining the gnuradio community, there 
> will more and more people will expect it to work, without issues.  It seems 
> like a concerted investment less complexity to build a running system.  I’m 
> not sure what that means, but I suspect a few of you have some interesting 
> and disruptive ideas that could greatly simplify the build process but not 
> hurt performance much.
>
> Or…I’m nuts.
>
> Greg
> Nz8r
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio