Hi Dennis,
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]
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L66
[3]
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#aa5581727d057bdd8113f8b2a3fc5bd66
[4] http://libvolk.org
