When using GNURadio Companion, they only appear when closing the flowgraph.
On my application, which uses the same gnuradio code directly in c++
multiple times ( creates a usrp, then a flowgraph that uses it, stops the
flowgraph, then starts another after a few seconds) I see the errors at the
end of the first, then during streaming on all subsequent flowgraphs.

Occasionally I am getting a IOError: no response packet AssertionError when
I start streaming (typically after a couple of other stream instances) and
it causes my entire application to hang.

-----------------------------
Jacob Knoles



On Mon, Jul 9, 2018 at 10:53 AM Marcus D. Leech <mle...@ripnet.com> wrote:

> On 07/09/2018 01:47 PM, Jacob Knoles wrote:
>
> It seems to be sample-rate agnostic. I ran a few tests using GNURadio
> companion at 50M, 1M and 100K sample rates, they all had the same errors
> when stopping the flowgraph. For my application I need to run it at 50M.
>
> After a few runs here I now have a new error too:
> RuntimeError: RuntimeError: BIST failed!(code: 1)
>
> The usrp flowgraph would not run until power cycling the usrp.
>
> Side note: the errors do not appear if I kill the flowgraph using the stop
> button, as opposed to closing it cleanly.
> -----------------------------
> Jacob Knoles
>
> Just to clarify, the "Bad CHDR" errors occur *during* streaming?
>
>
>
>
> On Mon, Jul 9, 2018 at 10:02 AM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 07/09/2018 12:07 PM, Jacob Knoles via USRP-users wrote:
>>
>> I have a simple TX streamer that uses GNURadio in C++ which loads data
>> from a file into memory followed by a separate flowgraph of vector source
>> to usrp sink that repeats until closed.
>>
>> The problem I am having is that in my code, the log just spits out:
>>  "[ERROR] [STREAMER] Error parsing async message packet: ValueError: Bad
>> CHDR or packet fragment"
>>  many times while streaming. Then when I stop streaming I get this:
>>
>> [ERROR] [UHD] Exception caught in safe-call.
>>    in __cdecl ctrl_iface_impl::~ctrl_iface_impl(void)
>>    at
>> z:\gr-build\src-stage1-dependencies\uhd-release_003_011_000_000\host\lib\rfnoc\ctrl_iface.cpp:66
>> this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_01_Port_40)
>> no response packet - AssertionError: buff->size() > 0
>>   in unsigned __int64 __cdecl ctrl_iface_impl::wait_for_ack(const bool)
>>   at z:\
>> \gr-build\src-stage1-dependencies\uhd-release_003_011_000_000\host\lib\rfnoc\ctrl_iface.cpp:187
>>
>> For me, this is not an isolated issue, no matter what program I run, be
>> it my own, a uhd example, or a simple gnuradio-companion app I get these
>> errors. And it seems to be causing my application to crash or not transmit
>> properly.
>>
>> Is anyone else having this issue? Is there anything I can do to fix it?
>> Is this ignorable?
>>
>> Setup: Windows 10 Home
>> Intel Core i5
>> X300
>> Dual 10g ethernet using Intel X710 adapter
>>
>> Thanks for any assistance.
>> -----------------------------
>> Jacob Knoles
>>
>> Is this only at high sample rates, or is it sample-rate agnostic?
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to