Re: [Discuss-gnuradio] UHD recv demuxer errors with a simple Python flowgraph

[Marcus Müller]

Hi Pierre,

that looks more like a USB communication breakdown than an issue with
your software.

just as a quick test: if you set the sampling rate to something USB2 can
handle (e.g. 8 MHz or lower), does that work with a USB2-only port (ie.
pick one that's not blue)? Some USB3 port controllers just misbehave.

Best regards,

Marcus


On 05.06.2017 15:01, Pierre Baudry wrote:
> Hi,
>
> While working with gr-gsm blocks and examples I ran into some weird UHD
> errors.
>
> I tried to reduce as much as possible the flowgraph complexity, and
> ended up writing a very simple flowgraph that seems to reliably trigger
> the UHD errors.
>
> I uploaded the flowgraph here:
> https://gist.github.com/anonymous/d3c0c9f1f72ab7cdc2c3460126682bc6
>
> The point of this flowgraph is to simply tune into a frequency, acquire
> some samples and proceed with a new acquisition. This is similar to what
> grgsm-scanner does, with the sample analysis removed.
>
> On my hardware (Xeon E5-2650 with USRP B200 on USB3), this flowgraph
> will produce a lot of UHD errors every time such as:
>
>> Tuning to 1934.301035 MHz
>> Acquisition N° 13 finished
>>
>> Tuning to 1619.216092 MHz
>>
>> UHD Error:
>>     recv packet demuxer unexpected sid 0xc449c000
>>
>> UHD Error:
>>     recv packet demuxer unexpected sid 0x44208000
>>
>> UHD Error:
>>     recv packet demuxer unexpected sid 0xc4064000
>>
>> UHD Error:
>>     recv packet demuxer unexpected sid 0xc2780000
>> ---- snip ----
> Am I doing something the wrong way ?
> Is there a limitation of some kind with the way I retune the USRP ?
> I first thought that these errors were tied to the processing power
> required but the flowgraph I wrote just trashes received samples so this
> is very unlikely.
>
> Best,
> Pierre
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio