usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

ERROR_CODE_BAD_PACKET after resuming a flowgraph

JD
Jared Dulmage via USRP-users
Mon, May 12, 2014 6:33 PM

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.

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.
MD
Marcus D. Leech via USRP-users
Mon, May 12, 2014 6:55 PM

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 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
MB
Martin Braun via USRP-users
Tue, May 13, 2014 7:56 AM

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

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
JD
Jared Dulmage via USRP-users
Tue, May 13, 2014 11:02 PM

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:

  • 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

@lists.ettus.com>@lists.ettus.com>

MD
Marcus D. Leech via USRP-users
Tue, May 13, 2014 11:12 PM

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

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
JD
Jared Dulmage via USRP-users
Fri, May 16, 2014 12:46 AM

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>