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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to