I’m not sure what that message is telling me in the operation/debug
domain. Clue please.
The paper “Inspecting GNU Radio Applications with ControlPort and
Performance Counters” shows various blocks in Figures 2 and 5 named
“Ctrlport…”. Are those necessary for MX? I haven’t found anything that
indicates yes or no. Clue please.
Operationally:
root@Tori-Radio:~/thrift# gnuradio-companion --version
GNU Radio Companion v3.7.7.1-131-g71ab508d
root@Tori-Radio:~/thrift# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
On Tue, Jun 16, 2015 at 11:11 PM, Dennis G. [email protected]
wrote:
domain. Clue please.
root@Tori-Radio:~/thrift# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.04
Release: 15.04
Codename: vivid
I’m not sure what MX is? Are you using that as shorthand for
gr-perf-monitorx?
If that’s the case, then no, the Ctrlport Probes are there for other
purposes and not necessary for Performance Monitor.
I’m seen that Math Domain error before, but I’ve never been able to
replicate it reliably. I think it’s something related to a divide by
zero
and I think happens when one block’s performance measure of work time
comes
back with 0 – which doesn’t often happen. Are you using any of your own
blocks in the flowgraph? What if you run the Controlport Monitor tool
instead of Performance Monitor? That will just show you a list of all
available parameters exposed by the application over ControlPort.
error).
named
root@Tori-Radio:~/thrift# lsb_release -a
gr-perf-monitorx?
any of your own blocks in the flowgraph? What if you run the
Controlport Monitor tool instead of Performance Monitor? That will
just show you a list of all available parameters exposed by the
application over ControlPort.
That’s an interesting tool. Thanks for pointing it out.
I’m looking for why I am getting "O"s on the console but I don’t see
full buffers (worst is 9%). I assume I’m doing something pragmatically
stupid or graph stupid, which is the usual case.
What does “nproduced -2.0” mean? Is there a paper somewhere?
While I’m asking stupid questions, :), it would be handy for this tool
to spit out something textual so I can post-process, such as graphing a
parameter. Is that possible? I don’t see anything obvious in the
immediate Python code.
Perhaps I should also mention two things. First, I’ve only been working
with GRC for a few months and I’m not signals literate. Second, I’m
processing samples using OpenMP (in some cases nested) plus some data
structures background maintenance threads, and written in C++11. Seems
to all work fine. Not sure that matters.
I’m looking for why I am getting "O"s on the console but I don’t see
full buffers (worst is 9%). I assume I’m doing something pragmatically
stupid or graph stupid, which is the usual case.
SDR is HackRF. I wasn’t seeing Os with bladeRF.
I can really only tell from the USRP side of life [1], but since we’re
talking about hardware:
This could happen because if, after the source block has produced a
number of samples that it took from the hardware, it needs to be called
again to be able to get more samples. If that “calling again” doesn’t
happen, at some points, the receive buffers flow over.
The calling again, however, will only happen if GNU Radio sees reason
for it, which would typically mean that something in the output buffer
reader changed.
If, for example, the block that you connect to the source, just sits
there and blocks in its (general_)work(), there’s no chance that it
could yet take more input data – and hence, GNU Radio doesn’t ask for
more samples from the source. If that’s the case, try to connect a null
sink in parallel to the first block after the source. Does that change
things.
What does “nproduced -2.0” mean? Is there a paper somewhere?
I’d rather point you to the right source directly [2]. I don’t really
know why that appears; it’s a “magic value” that your block’s
(general_)work can return to tell the scheduler that the return value is
not the number of items that were produced, and that the significant
number is the sum of items that were specified using produce()[3] calls.
While I’m asking stupid questions, :),
still waiting for your first
it would be handy for this tool
to spit out something textual so I can post-process, such as graphing a
parameter. Is that possible? I don’t see anything obvious in the
immediate Python code.
Well, the idea is that controlport allows you to more or less easily
write your own clients that just directly ask. Now, there’s two things:
if you need something specific, it might be easier to just write a
client of your own.
If you want to be awesome, and think your visualization or output
facility is helpful for anyone but you, too, you might want to work with
gr-perf-monitorx’s source code itself and make upstream pull requests –
it’s very seldom that GNU Radio can’t use a GUI developer
Perhaps I should also mention two things. First, I’ve only been working
with GRC for a few months and I’m not signals literate.
Well, I think you’re becoming more and more literate
Second, I’m processing samples using OpenMP (in some cases nested) plus some
data
structures background maintenance threads, and written in C++11. Seems
to all work fine. Not sure that matters.
It’s generally cool to see someone do additional acceleration! OpenMP
sounds exiting, as it covers a field that differs from the “raw”
data-parallelism that VOLK[4] tries to achieve using SIMD on different
platforms. What’s your application’s purpose?
Greetings,
Marcus
[1] Idle, Eric: Why to permanently consider the less strenuous side of
existence, in: Proceedings of the Life of Brian, final notes, 1978.
Editors: Chapman, Cleese, Gilliam, Idle, Jones, Palin.
[2]
I ran into this “math domain error” with CtrlPort recently. Based on
your
suggestion that it might be related to zero work blocks causing a divide
by
zero, I started hacking away anything that might be being
short-circuited
in the relatively complex flowgraph. First, an shorted branch of a
select
tree - no dice. Then a copy block. BAM! That was it. I guess copy
must
be super efficient and not really do any work.
Anyhow, I figure that using a copy block in a fg should reliably
reproduce
this problem an perhaps serve as a model for working around it.
In my fg, the copy block was serving as a valve that would prevent
downstream blocks from executing if it was shut. In my case, the
“valve”
was open, and data was flowing through the copy block.
