Automatically Restart UHD/gr-uhd blocks

GNU Radio
1

I’ve recently received a request to have GNU Radio flowgraphs recover
gracefully in the event of power glitches, or transient Ethernet
anomalies
that are severe enough to break the dataflow. ie. the event should be
noted, but there should be a way to re-init the USRP for continued
operation with restart the .py.

I haven’t really been keeping up.

  • Has there been any discussion on how we might modify gr-uhd, and
    maybe
    UHD, to allow automatic re-initialization of the USRP?
  • If not, is this a reasonable place to brainstorm on the problem?
  • Has anyone already solved this?

It doesn’t seem that complex, but I’d like to pick the most
straight-forward path.
-John

2

I worked around a problem like this by installing an in-line power relay
in
my remote nodes. Not ideal, but in some rare situations, even forcing
the
FPGA to reload was not successful. Sometimes a power cycle was the only
hope.

That said, I’ve heard some lovely things about reset commands available
for
the newer boards, but it’s not clear to me if they are integrated into
the
driver. Seems likely, though.

Very Respectfully,

Dan CaJacob

On Wed, Feb 18, 2015 at 4:29 PM, John M.
<[email protected]

3

Dan,

I think you were working a different, USB-related issues.

My task is a bit different. The goal is not to power cycle the USRPs -
its
to re-initialize and resume after and power cycle, without intervention
from an external executive or operator. (ie. by some task that monitors
for a stop in dataflow and then perhaps calls a re-init function in
gr-uhd,
or rebuilds a flowgraph entirely)

-John

4

On 02/19/2015 12:14 AM, John M. wrote:

Dan,

I think you were working a different, USB-related issues.

My task is a bit different. The goal is not to power cycle the USRPs -
its to re-initialize and resume after and power cycle, without
intervention from an external executive or operator. (ie. by some task
that monitors for a stop in dataflow and then perhaps calls a re-init
function in gr-uhd, or rebuilds a flowgraph entirely)

This has been mentioned before, but we’ve never made a plan to fix this.
One issue is that if the USRP conks out, this usually means the block
breaks down – so the issue is not so much recovering the multi_usrp,
but rather making sure the usrp_{sink,source} blocks keep running when
the USRP has some issues.

M

5

On 02/18/2015 06:14 PM, John M. wrote:

-John

Attach a custom block that watches for samples arriving at the desired
rate, and makes note of time. When there’s a too-big gap, it can
send a terminate signal to the process,and have things shut-down.
Then a script (Python, bash, whatever) can simply restart
the flow-graph.