discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] ctrlport_probe2_x with gr-ctrlport-monitor in the


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] ctrlport_probe2_x with gr-ctrlport-monitor in the absence of samples
Date: Wed, 9 Sep 2015 12:41:19 -0400

On Thu, Sep 3, 2015 at 7:17 AM, Eric Statzer <address@hidden> wrote:
I'm attempting to use ctrlport_probe2_x and gr-ctrlport-monitor to probe points in a bursty flowgraph.  When I place a ctrlport_probe2_x probe somewhere in the part of my flowgraph that process samples only upon reception of a burst, gr-ctrlport-monitor doesn't fully initialize (populate its list of controlport "knobs") until after all ctrlport_probe2_x blocks have performed at least one call to work().  Furthermore, the gr-ctrlport-monitor GUI is only responsive to user input if all ctrlport_probe2_x blocks in the flowgraph are regularly making calls to work() (i.e. gr-ctrlport-monitor query latency becomes equal to the time that elapses between processing individual bursts), so if for some reason bursts ever stop trickling to one of the probes, gr-ctrlport-monitor becomes unresponsive to user input.

The gr-ctrlport-monitor behavior can be recreated with any simple flowgraph that contains a ctrlport_probe2_x that will never (or infrequently) make a call to work, such as: random_pdu -> pdu_to_tagged_stream -> ctrlport_probe2_b, where the "generate" port of the random_pdu block is left unconnected.  Attempting to connect gr-ctrlport-monitor to this flowgraph will cause gr-ctrlport-monitor to be unresponsive (have to kill it) almost immediately after the GUI is displayed.

I wasn't sure if this is a limitation of ctrlport_probe2_x or gr-ctrlport-monitor, but I wanted to see if t was was possible to make the combination play nicely together when applied to a bursty flowgraph.

Relevant system info:
  GNU Radio 3.7.8
  Thrift 0.9.2
  Ubuntu 15.04
  
Thanks in advance,
Eric

Eric,

Have you tried increasing the number of threads in the thrift server? Try making/modifying ~/.gnuradio/thrift.conf with:

[thrift]
nthreads = 10 (or some number greater than the number of probe blocks you have)

(and make sure you have set "[ControlPort] config=~/.gnuradio/thrift.conf" so it gets picked up.)

I'm wondering if it's just blocking on all endpoints in a single thread right now before allowing any of them to return.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]