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
_______________________________________________
Discuss-gnuradio mailing list
address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio