USRP B210 "UHD Error: recv packet demuxer unexpected sid 0xff87ffc3"

Hello:

Running examples from:

http://www.trondeau.com/examples/2014/1/23/pfb-channelizers-and-synthesizers.html

https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633d9/543aee20e4b09162d086354d/1395272342027/fm_channelizer.grc

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:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/009516.html

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

On 03/19/2015 04:39 PM, Larry Van Der J. wrote:

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs