1. Multiple USB transfers are queued by UHD and they pull the data into
host memory as quick as they can. The transfers are re-queued when the
data is retrieved by the application calling recv(). Overruns occur when
all transfers are complete, data is queued in the memory, and the
application
I think I found the fix. On the USB2 bus, backing the USRP sample rate
down from 8 MSPS to 7.4 MSPS made the issue go away. This is just
speculation on my part, but even though there was no IP-based traffic to
the LTE card, it was still communicating with the host (status, keepalive,
something).
uhd_usrp_probe seems to come back fine. It sees the 205. I'm seeing it on
another separate Pi with a different LTE adapter too so I think it rules
out the instance of both I have being the culprit.
I'll have some time tomorrow night to do some more debugging. I'll take a
look at the lsusb
Can also try exactly the same test, but with a standard PC / laptop and the
same OS, to isolate the rPi/host hardware parameter
On Mon, Jun 25, 2018 at 7:30 AM Ian Buckley via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Perhaps try 'sudo lsusb -v' with and without the LTE modem plugged in
On 06/24/2018 10:08 PM, GhostOp14 wrote:
Hi Marcus, tried that too. No luck. Powered the USRP separately,
then tried powering the LTE separately. Same result. It's as if it
can't read block data on the USB bus when the LTE is connected.
There's no data going through the LTE so I'm not
Hi folks,
I have a weird issue I've been attempting to troubleshoot for a bit and I'm
stuck.
So setup:
USRP B205 connected to a Raspberry Pi 3 (so USB 2 mode)
Huawei E3372 USB LTE adapter connected as well
Running the latest Raspbian (stretch)
Problem:
I'm using C++ code to read stream blocks
