On 05/07/2019 02:30 PM, Jose Ruvalcaba wrote:
Yes I do. However, I've noticed that when I reboot the radio, the
issue does not appear. However, after I switch to another flowgraph,
the issue shows up and I need to reboot the radio again. I've attached
a screenshot of the issue after trying the test tools in case it helps.
Ah, OK. So, you stop a flow-graph, which apparently leaves the USRP in
a weird state, and then when you run a "fresh" graph, it produces
this error?
Is it possible for you to try the current UHD master, rather than the
3.14 tagged release?
On Tue, May 7, 2019 at 10:41 AM Marcus D Leech
<patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>> wrote:
If you use one of the test tools like uhd_fft or any of the purely
UHD tools do you see the same issue?
Sent from my iPhone
On May 7, 2019, at 1:14 PM, Jose Ruvalcaba <joruv...@gmail.com
<mailto:joruv...@gmail.com>> wrote:
Hi Marcus,
I was using a 1 Msps sample rate in my flowgraph. As for the
Ethernet controller, I was currently using my standard 1 GigE
Ethernet port on my PC, however, this issue also shows up when
using a 10GigE connection. If it helps, the 10 GigE Ethernet card
I have is the desktop card sold by Ettus Research.
Thanks,
Jose
On Tue, May 7, 2019 at 8:07 AM Marcus D. Leech
<patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>> wrote:
On 05/07/2019 02:23 AM, Jose Ruvalcaba wrote:
Hello,
I recently installed GNU Radio 3.7.13.4 with UHD 3.14 ,using
PyBOMBS, and tried to use my X310 radio with it. It asked me
to update its FPGA image, and after updating it, I began to
see an error whenever I tried using the USRP sink and source
block In GNU Radio. The error reads:
/Executing: /usr/bin/python2 -u
/home/satrnground/Downloads/simple_xponder.py//
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.3.0;
Boost_106501; UHD_3.14.0.0-110-g6af6ac32
[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mRadio 1x clock: 200 MHz*
[31;0m[ERROR] [UHD] [39;0mException caught in safe-call.
in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
uhd::endianness_t _endianness = (uhd::endianness_t)0]
at
/home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError:
IOError: Block ctrl (CE_00_Port_30) no response packet -
AssertionError: bool(buff)
in uint64_t
ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
[with uhd::endianness_t _endianness = (uhd::endianness_t)0;
uint64_t = long unsigned int]
at
/home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155*/
/*
*/
Note that I am NOT trying to use RFNOC, which I think this
issue is related too, I am just trying to use the x310 with
regular USRP blocks in GNU radio.If it helps to know, I am
running UBuntu 18.04 and the FPGA image I downloaded on my
X310 was the default HG one. Can anyone shine some light
into how to get rid of this issue?
Thanks,
Jose R
What sample rate are you using? Do you happen to know what
type of Ethernet controller your PC has?
_______________________________________________
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
