discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] USRP B210 "UHD Error: recv packet demuxer unexpec


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] USRP B210 "UHD Error: recv packet demuxer unexpected sid 0xff87ffc3"
Date: Thu, 19 Mar 2015 18:05:27 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 03/19/2015 04:39 PM, Larry Van Der Jagt wrote:
Hello:

Running examples from:




With the the following changes:

1) Mb0 Clock sources in UHD:USRP source set to Default

2) Output of Polyphase decimator routed to new UHD:USRP Sink with sample rate set to 200k to match Polyphase Decimator rate and center frequency set to 93.9 MHz (source center frequency is 97.9 MHz in intended application, but problem also occurs when source and sink frequencies match)

System runs successfully for roughly 5 minutes and then errors with a series of:

UHD Error: recv packet demuxer unexpected sid 0xff87ffc3

Over and over.  Sometimes the sid listed is the same, sometimes it changes.

Running UHD 003.008.001-82-g9e6ff291 over GNURadio 3.7.6.1 utilizing USB3 on I7 running Ubuntu 12.04 LTS.  The firmware loaded is the standard usrp_b200_fw.hex that came with the build.

I note this was looked at in:


but I do not find a resolution at that time .

Once this occurs it is necessary to unplug and replug the USB cable to get the system to operate again.

There are occasional   UUU OOO Ua during operation, but these occur albeit less frequently without the addition of the USRP Sink and I have not seen the sid error when this Sink is absent.

As always any links or info is welcomed.

LVDJ


Basically, what seems to happen with B200, is that overruns tend to turn into cascades that yield dropped USB frames, which provokes "syntax errors" in the underlying (or overlying, depending on your view of the VITA-49 stack) protocol layer.

What type of USB subsystem do you have?  What CPU utilization is happening when you're running the flow-graph.  I don't have a good feel for
  how "crunchy" a PFB decimator is compared to, for example, a hierarchical filtering scheme to get you from 20Msps to a single WBFM channel.

If you really are interested in just a single WBFM channel, then bringing the samples in at a lower rate is preferable.  I usually run the radio interface at
  1Msps, and filter-and-decimate down to 250kHz.  I get good results that way.

I realize this may just be an "exploratory" thing for you, on the way to something else.

Also, I just noticed that you're running an older (very) Ubuntu.  The older kernels had poorer USB-3.0 support, so something to consider would be
  to upgrade your OS to 14.04 LTS.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]