Hi Andreas,
> If i stop the drawing of all the graphs in the compiled GNU Radio
application, i could change parameters like the volume or gain with the
sliders/text boxes now.
That was to be expected :) Calculating a 512-point FFT is somewhat
ressource-consuming, but drawing and updating a graph o
Hi Marcus,
Hi Andreas,
GRC is already as multithreaded as GTK applications can generally be --
I think the bottleneck here is really your Bananapi's CPU, its RAM and
its graphics card driver.
If i stop the drawing of all the graphs in the compiled GNU Radio
application, i could change parameter
Hi Andreas,
GRC is already as multithreaded as GTK applications can generally be --
I think the bottleneck here is really your Bananapi's CPU, its RAM and
its graphics card driver.
To be honest, I generally consider the Raspberry Pi and similar devices
to be embedded ones with hardware that underw
That would require wholesale reworking of GRC.
You *really, really, really* shouldn't think of a lowly banana-pi as
your *development* environment. The .py files that are generated by GRC
can be generated on a "real" machine, and executed on the banana-pi,
provided that you have identical GR i
Hi,
iam testing gnuradio-companion editor on the Bananapi LUbuntu. When i am
editing a block or drawing a block i recognize in top that the python
process has a 100% CPU (i have 2 CPUs) load. The gnuradio-companion
editor reacts very slow.
Is it possible to tell the editor or python to use 2
