On Mon, May 06, 2019 at 09:36:34AM +0200, Matthias Br??ndli wrote:
> > Pure theory: What if this intermittent issue would be an issue with a
> > certain sequence of packetlengths, some of them on the boundary of the
> > maximum size for that endpoint and endpointtype, that are not handled
> > pr
Hi Mark-Jan,
Thanks for your response.
On 03/05/2019 00:02, Mark-Jan Bastian wrote:
> For more in-depth USB debugging, there are external USB 2.0 and 3.x
> hardware bus analysers available, for example from the swiss company
> ellisys.com.
I have experience in USB protocol analysis from a previ
Hi Mathhias,
On Thu, May 02, 2019 at 02:18:38PM +0200, Matthias Br??ndli via USRP-users
wrote:
> On some systems, we observe sporadic underruns. They occur in irregular
> intervals, something like once a minute, sometimes rarer. Seen with both
> USB2 and USB3 hosts, over several UHD versions. Unt
I've had similar issues on the e310 with similar sample rates. On the e310
no usb is involved. Unfortunately I have not been able to fully get rid of
the underrun issues as well.
So far I have tried:
- separate threads with ping-pong buffers: this helped
- linux real-time scheduling
- increasing t
Setting a large number of UHD buffers can help quite a bit. In the GRC
UHD Sink block device address:
"num_send_frames=256"
In Python:
self.uhd_usrp_sink_0_0 = uhd.usrp_sink(
",".join(("num_send_frames=256", "")),
uhd.stream_args(
cpu_format="fc3
Dear all,
I'm maintaining ODR-DabMod[1], a Digital Audio Broadcasting modulator
which uses UHD to drive a USRP at 2048ksps, in most applications a B200.
ODR-DabMod runs the modulator and the UHD output in separate threads, to
ensure that a few modulated frames are always ready when the USRP needs
