Re: [Discuss-gnuradio] Struggling with gr-perf-monitorx

[Dennis Glatting]

On Tue, 2015-06-16 at 23:43 -0400, Tom Rondeau wrote:
> On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting <address@hidden>
> wrote:
>         
>         I have this "nearly" working. MX brings up a window, connects
>         to GRC,
>         briefly displays a graph, then blanks out. Displayed in the
>         command line
>         window:
>         
>         gr-perf-monitorx: radio.getKnobs threw exception (math domain
>         error).
>         ...
>         (repeats)
>         
>         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:
>         
>         address@hidden:~/thrift# gnuradio-companion  --version
>         GNU Radio Companion v3.7.7.1-131-g71ab508d
>         
>         
>         address@hidden:~/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.
> 

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. 

SDR is HackRF. I wasn't seeing Os with bladeRF.