Hi All,

So I updated my UHD driver and it still gave me the same error. However, I
did try it with a different computer that had UHD 3.12 and my radio worked
fine. I am assuming its something with the most recent UHD drivers? Until
then I may need to downgrade my UHD drivers. By any chance does anyone know
how to downgrade UHD using PyBombs?

On Tue, May 7, 2019 at 11:36 AM Marcus D. Leech <[email protected]>
wrote:

> 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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
>> 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
>>> [email protected]
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to