Forum: GNU Radio GRC vs python flow-graph by hand

739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-04-12 13:27
(Received via mailing list)
Dear Sir,

As an amateur I use GRC to create flow-graphs, but I see many other
users
create their flow-graphs in python by hand.

In what kind of cases the flow graphs must be coded by hand ?
(where GRC couldn't accomplish the task)
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2014-04-12 15:12
(Received via mailing list)
Interactivity, controlling flowgraph timing (start/stop), dynamic
reconfiguration (lock/unlock), integration with Python libraries and so
on.
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-04-13 07:12
(Received via mailing list)
It seems that in normal usage the GRC is able to accomplish most of the
tasks without modifying the python flow-graph by hand...
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2014-04-14 16:05
(Received via mailing list)
On Sun, Apr 13, 2014 at 1:10 AM, Activecat <activecat@gmail.com> wrote:

> It seems that in normal usage the GRC is able to accomplish most of the
> tasks without modifying the python flow-graph by hand...
>

Generally, we move away from GRC when we require a lot of logic and
control
to set up the flowgraph. You might have a lot of branches to enable one
type of block over another automatically based on some user input. Other
reasons are for better UI and packaging. While we can do a lot of that
inside GRC, there's still plenty of limitations that you can do directly
in
Python.

I tell people to work as far as you can in GRC until you hit these kinds
of
boundaries where you are then bending over backwards to make it work
inside
GRC. At that point, save the Python file somewhere and start
architecting
your program around that core.

Tom
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2014-04-15 01:44
(Received via mailing list)
I would also suggest to use hier blocks, as you can continue designing
the
DSP in GRC while integrating it in a Python application
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-04-15 06:17
(Received via mailing list)
Brilliant idea.
739a038d5a03d5448114b3615e2caedc?d=identicon&s=25 Activecat K. (activecat_k)
on 2014-04-15 06:21
(Received via mailing list)
On Mon, Apr 14, 2014 at 10:04 PM, Tom Rondeau <tom@trondeau.com> wrote:

> Other reasons are for better UI and packaging. While we can do a lot of
> that inside GRC, there's still plenty of limitations that you can do
> directly in Python.
>
> I tell people to work as far as you can in GRC until you hit these kinds
> of boundaries where you are then bending over backwards to make it work
> inside GRC. At that point, save the Python file somewhere and start
> architecting your program around that core.
>

Very thorough explanation, thanks!
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.