On Tue, 2015-06-16 at 23:43 -0400, Tom Rondeau wrote: > On Tue, Jun 16, 2015 at 11:11 PM, Dennis Glatting <gnura...@pki2.com> > 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: > > 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 > > > > > 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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
