# Automatically Restart UHD/gr-uhd blocks **URL:** \ **Category:** GNU Radio\ **Created:** [February 18, 2015, 10:30pm UTC](https://www.ruby-forum.com/t/automatically-restart-uhd-gr-uhd-blocks/234250 "2015-02-18T22:30:20Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [February 18, 2015, 10:30pm UTC](https://www.ruby-forum.com/t/automatically-restart-uhd-gr-uhd-blocks/234250/1 "2015-02-18T22:30:20Z")
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 ---
**Author:** ![jmaenpaa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@jmaenpaa](https://www.ruby-forum.com/u/jmaenpaa)\ **Post date:** [February 19, 2015, 12:08am UTC](https://www.ruby-forum.com/t/automatically-restart-uhd-gr-uhd-blocks/234250/2 "2015-02-19T00:08:39Z")
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. \ **Author:** ![jmaenpaa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@jmaenpaa](https://www.ruby-forum.com/u/jmaenpaa)\ **Post date:** [February 19, 2015, 12:16am UTC](https://www.ruby-forum.com/t/automatically-restart-uhd-gr-uhd-blocks/234250/3 "2015-02-19T00:16:09Z") 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 ---
**Author:** ![jmaenpaa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@jmaenpaa](https://www.ruby-forum.com/u/jmaenpaa)\ **Post date:** [February 19, 2015, 9:27am UTC](https://www.ruby-forum.com/t/automatically-restart-uhd-gr-uhd-blocks/234250/4 "2015-02-19T09:27:22Z")
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 ---
**Author:** ![jmaenpaa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@jmaenpaa](https://www.ruby-forum.com/u/jmaenpaa)\ **Post date:** [February 19, 2015, 12:23am UTC](https://www.ruby-forum.com/t/automatically-restart-uhd-gr-uhd-blocks/234250/5 "2015-02-19T00:23:38Z")
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.