[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Struggling with gr-perf-monitorx
From: |
Dennis Glatting |
Subject: |
Re: [Discuss-gnuradio] Struggling with gr-perf-monitorx |
Date: |
Tue, 16 Jun 2015 21:27:14 -0700 |
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.