Discussion and technical support related to USRP, UHD, RFNoC
View all threadsI'm using a USRP1 w/ UHD 3.005.003 through gnuradio 3.7.3 on windows 7 x64. All software compiled from source w/ MSVC 2010.
I have encountered an issue very similar to that in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-April/001061.html.
Using the C++ api, I create a flowgraph (starting with a usrp_source block) to estimate the frequency offset of an received signal, stop the flowgraph, adjust the RX center frequency of the usrp and then restart to measure the residual offset. Upon restarting the flowgraph I get a limitless list of errors:
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 3
UHD source block got error code 0xf
Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
There was no resolution (that I could find posted) to the issue reference above. I have confirmed the issue exists with Windows 7.
I appreciate any advice on resolving or further debugging this issue.
Jared.
On 05/12/2014 02:33 PM, Jared Dulmage via USRP-users wrote:
I'm using a USRP1 w/ UHD 3.005.003 through gnuradio 3.7.3 on windows 7 x64. All software compiled from source w/ MSVC 2010.
I have encountered an issue very similar to that in
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-April/001061.html.
Using the C++ api, I create a flowgraph (starting with a usrp_source block) to estimate the frequency offset of an received signal, stop the flowgraph, adjust the RX center frequency of the usrp and then restart to measure the residual offset. Upon restarting the flowgraph I get a limitless list of errors:
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 3
UHD source block got error code 0xf
Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
There was no resolution (that I could find posted) to the issue reference above. I have confirmed the issue exists with Windows 7.
I appreciate any advice on resolving or further debugging this issue.
Jared.
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
There's no need to stop the flow-graph just to change frequency. Just
assume that the first little bit after you change frequency is rubbish
and discard it.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
On 12.05.2014 20:33, Jared Dulmage via USRP-users wrote:
Using the C++ api, I create a flowgraph (starting with a usrp_source
block) to estimate the frequency offset of an received signal, stop
the flowgraph, adjust the RX center frequency of the usrp and then
restart to measure the residual offset. Upon restarting the
flowgraph I get a limitless list of errors:
UHD Error: The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 3 UHD source block got error
code 0xf
Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
There was no resolution (that I could find posted) to the issue
reference above. I have confirmed the issue exists with Windows 7.
I appreciate any advice on resolving or further debugging this
issue.
Hi Jared,
a couple of questions:
Thanks!
Martin
Marcus,
Yes, there are work-arounds for this particular scenario, but I could envision another scenario where we would like to stop a flowgraph completely and start a new one w/o exiting the program. Perhaps the platform needs to handle multiple standards or waveforms with minimal interruption but you don't have the resources to have all of them loaded and executing simultaneously.
Martin,
We have been using the 3.5.3 branch only to minimize changes while we code up our models. It was what we originally used when we started. I could update, but that will have to wait until after an upcoming deadline.
The sequence you describe: start, stop, wait, start, is exactly what we do. We've observed the error both using the same flowgraph (i.e. restarting the same top block) and a different flowgraph with a different top block.
Thanks for the feedback.
Jared.
-----"USRP-users" <usrp-users-bounces@lists.ettus.com> wrote: -----To: usrp-users@lists.ettus.com
From: Martin Braun via USRP-users
Sent by: "USRP-users"
Date: 05/13/2014 12:57AM
Subject: Re: [USRP-users] ERROR_CODE_BAD_PACKET after resuming a flowgraph
On 12.05.2014 20:33, Jared Dulmage via USRP-users wrote:
> Using the C++ api, I create a flowgraph (starting with a usrp_source
> block) to estimate the frequency offset of an received signal, stop
> the flowgraph, adjust the RX center frequency of the usrp and then
> restart to measure the residual offset. Upon restarting the
> flowgraph I get a limitless list of errors:
>
> UHD Error: The receive packet handler caught an exception.
> RuntimeError: usb rx6 transfer status: 3 UHD source block got error
> code 0xf
>
> Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
>
> There was no resolution (that I could find posted) to the issue
> reference above. I have confirmed the issue exists with Windows 7.
>
> I appreciate any advice on resolving or further debugging this
> issue.
Hi Jared,
a couple of questions:
Thanks!
Martin
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
@lists.ettus.com>@lists.ettus.com>
On 05/13/2014 03:56 AM, Martin Braun via USRP-users wrote:
On 12.05.2014 20:33, Jared Dulmage via USRP-users wrote:
Using the C++ api, I create a flowgraph (starting with a usrp_source
block) to estimate the frequency offset of an received signal, stop
the flowgraph, adjust the RX center frequency of the usrp and then
restart to measure the residual offset. Upon restarting the
flowgraph I get a limitless list of errors:
UHD Error: The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 3 UHD source block got error
code 0xf
Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
There was no resolution (that I could find posted) to the issue
reference above. I have confirmed the issue exists with Windows 7.
I appreciate any advice on resolving or further debugging this
issue.
Hi Jared,
a couple of questions:
Thanks!
Martin
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Also, this is on a USRP1, where it doesn't actually have all the same
semantics as other UHD devices--the device-side code was frozen years
and years ago, prior to UHD being born, and so the UHD adaptation
layer isn't really able to support all the same semantics as other,
"true" UHD devices. Just wondering out loud if that has something to
do with the observed effects.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
A colleague of mine has verified that starting a flowgraph after stopping one (whether the same or a different flowgraph) yields an error even with the USRP2 (N210) attached through ethernet. This time the error is:
thread[thread-per-block[0]: < block gr uhd usrp source (0)>]: ValueError: bad vrt header or packet fragment
So perhaps the issue is not necessarily due to the USRP1 legacy code.
Jared.
-----"USRP-users" <usrp-users-bounces@lists.ettus.com> wrote: -----To: usrp-users@lists.ettus.com
From: "Marcus D. Leech via USRP-users"
Sent by: "USRP-users"
Date: 05/13/2014 04:13PM
Subject: Re: [USRP-users] ERROR_CODE_BAD_PACKET after resuming a flowgraph
On 05/13/2014 03:56 AM, Martin Braun via USRP-users wrote:
> On 12.05.2014 20:33, Jared Dulmage via USRP-users wrote:
>> Using the C++ api, I create a flowgraph (starting with a usrp_source
>> block) to estimate the frequency offset of an received signal, stop
>> the flowgraph, adjust the RX center frequency of the usrp and then
>> restart to measure the residual offset. Upon restarting the
>> flowgraph I get a limitless list of errors:
>>
>> UHD Error: The receive packet handler caught an exception.
>> RuntimeError: usb rx6 transfer status: 3 UHD source block got error
>> code 0xf
>>
>> Debugging the program, the error code is ERROR_CODE_BAD_PACKET.
>>
>> There was no resolution (that I could find posted) to the issue
>> reference above. I have confirmed the issue exists with Windows 7.
>>
>> I appreciate any advice on resolving or further debugging this
>> issue.
>
> Hi Jared,
>
> a couple of questions:
>
> - Is there are reason to use 3.5.3? If you use a more recent version,
> do things become more stable?
> - When you say you stop and restart the flow graph, do you actually do
> a start(), stop(), wait(), start() on the same flow graph object?
>
> Thanks!
>
> Martin
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Also, this is on a USRP1, where it doesn't *actually* have all the same
semantics as other UHD devices--the device-side code was frozen years
and years ago, prior to UHD being born, and so the UHD adaptation
layer isn't really able to support all the same semantics as other,
"true" UHD devices. Just wondering out loud if that has something to
do with the observed effects.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
@lists.ettus.com>@lists.ettus.com>