On 02/18/2015 06:14 PM, John Malsbury 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)
-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.
On Wed, Feb 18, 2015 at 3:06 PM, Dan CaJacob <dan.caja...@gmail.com
<mailto:dan.caja...@gmail.com>> wrote:
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 Malsbury
<jmalsbury.perso...@gmail.com
<mailto:jmalsbury.perso...@gmail.com>> wrote:
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
