Hi,
I tested on a different machine of mine (Fedora 32, GNU Radio 3.8.2) and
the problem does not occur there.
This suggests that the problem is somehow specific to this Ubuntu
system, but not to a specific build of GNU Radio (nor Python, it occurs
with both 3.8 and 3.9). Since this looks more like a GUI problem than
signal processing itself, I'm wondering if it may be related to the Qt
version there - 5.12.8. The machine it works correctly on has 5.14.2
installed.
Attached the test file. It works fine on my Fedora but very slow (in
terms of GUI responsiveness) on my Ubuntu. Would be great if somebody
could point me in a right direction of what else I can check.
Mit freundlichen Grüßen
Mariusz Plucinski
Am So., 10. Jan. 2021 um 18:41 Uhr schrieb Jeff Long
<willcode4@gmail.com <mailto:willcode4@gmail.com>>:
I was using 2MS/s, tested with 3.8 and master (which should be close
enough to 3.9). Nothing comes to mind. You could post a GRC file,
just in case there's a misunderstanding of how something works.
On Sun, Jan 10, 2021 at 10:00 AM Mariusz Pluciński
<plucinski.mariusz@gmail.com <mailto:plucinski.mariusz@gmail.com>>
wrote:
Thank you for trying this. It assures me that it's something
wrong either in my project or in my configuration.
I also tried to build GNU Radio from source (3.9.0 RC2 from
git), but the problem also occurs there.
What do you mean by "reasonable sample rate"? I'm trying with
very low values like 300 (in both throttler and time sink) and
the problem still occurs.
In the new build, there seems to be a small delay before the
data appear on the chart. Up to this moment, the window is
reponsive, but as soon as the green lines appear, it becomes not
responsive again - best visible when trying to resize the window.
Is there anything else I can check?
Mit freundlichen Grüßen
Mariusz Plucinski
Am So., 10. Jan. 2021 um 02:55 Uhr schrieb Jeff Long
<willcode4@gmail.com <mailto:willcode4@gmail.com>>:
I gave this a try, adding Vector Source -> Throttle -> QT
GUI Time Sink to a flowgraph. Performance is fine at 2MS/s
on an older laptop. Make sure that the Throttle is being set
to a reasonable sample rate.
On Sat, Jan 9, 2021 at 6:35 PM Mariusz Pluciński
<plucinski.mariusz@gmail.com
<mailto:plucinski.mariusz@gmail.com>> wrote:
Hi,
Thanks for the answers. Unfortunately, I already tried
this before (forgot to mention) and it doesn't change
anything in this weird behavior of the GUI window.
It also doesn't help to have a hardware source and/or
sink in the flow (tried with Audio Sink and osmocom
Sink/Source); as soon as I enable both Vector Source and
QT GUI Time Sink at the same time (anywhere in the
flow), everything becomes unusably slow.
I also tried to add a separate path Null Source ->
Throttle -> Null Sink (as seen somewhere in the Wiki),
but this also didn't help. Changing sample rate of the
throttle also doesn't seem to change anything.
Is there any way I can diagnose this issue?
Regards,
Mariusz
Am Sa., 9. Jan. 2021 um 23:47 Uhr schrieb Derek Kozel
<derek@bitstovolts.com <mailto:derek@bitstovolts.com>>:
Hi Mariusz,
The main issue here is that you're missing a
Throttle block in your flowgraph. You have no
Hardware block in the flowgraph, it is pure
simulation. GNU Radio will try to run the processing
as fast as possible, using 100% of available CPU. A
Throttle block limits the simulation speed to
approximately realtime (to the set sample rate per
second).
A hardware source or sink will have a real, physical
clock and will restrict the number of samples
produced (Source) or consumed (Sink) and the other
blocks will not be able to run at infinite speed
(using all the CPU).
I'm curious why that would work better with a
different non-hardware source rather than the Vector
Source, but the recommended fix is straightforward.
Regards,
Derek
Am Sa., 9. Jan. 2021 um 23:49 Uhr schrieb Ron Economos
<w6rz@comcast.net <mailto:w6rz@comcast.net>>:
It's telling you what's wrong.
>>> Warning: This flow graph may not have flow
control: no audio or RF hardware blocks found. Add a
Misc->Throttle block to your flow graph to avoid CPU
congestion.
Add a Throttle block between the Vector Source and
QT GUI Time Sink blocks.
Ron
On 1/9/21 14:32, Mariusz Pluciński wrote:
Hello everybody,
I'm quite new to GNU Radio (and to signal
processing as well), but I did a few successful
experimens. But now, I encountered a weird
behavior, namely:
Every flowgraph including Vector Source and QT GUI
Time Sink conencted (regardless if directly or
with intermediate steps) causes huge performance
degradation. CPU usage jumps to 100% of a core,
window takes a few seconds to refresh, GUI becomes
almost unusable.
Everything works well if I use any different
source, .e.g. Signal Source or osmocom Source.
Everything works well if I use any different sink,
e.g. Audio Sink or QT GUI Frequency Sink.
It's just this specific combination that causes
the issue. Drastically reducing the number of
points in the Time Sink helps, but at the cost of
the output becoming useless.
To reproduce the problem, it's enough to do the
following in GNU Radio Companion:
1. Create an empty flow graph
2. Add "Vector Source"
3. Change "Vector" parameter to "(0, 0, 0, 1)"
4. Add "QT GUI Time Sink"
5. Connect both blocks
6. Run
Am I doing something wrong here?
(in case it's necessary, my ultimate goal here is
to use the vector source as a source of bits to
modulate a square wave; the output will later be
transmitted out, but first, I'd like to see it in
the Time Sink)
I'm using GNU Radio 3.8.1.0 on Ubuntu 20.04.
Best Regards,
Mariusz Plucinski