On 02/19/2015 12:14 AM, 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
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 operato
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
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 availa
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 r