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 sure how that's possible. Especially since it works fine as soon as I pull the LTE adapter out.
On Sun, Jun 24, 2018 at 5:24 PM, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 06/24/2018 04:25 PM, GhostOp14 via USRP-users wrote: > >> 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 from the device (800,000 samples >> with the USRP set to 8 MSPS, so basically 1 ms of data). Without the LTE >> it works fine, I get only infrequent overruns and the rest of the logic >> works fine. As soon as the LTE is plugged in and the corresponding >> ethernet interface is up, the recv call can't get a whole block of data >> (recv returns 0 bytes). If I ifconfig down the interface or unplug the LTE >> it goes back to working just fine. Plug it back in or ifconfig up the >> interface, problem returns. Of note, there is another network connection >> up on the wifi so the LTE is getting a lower priority in the routing table >> and there isn't any data going across it (I confirmed it with the >> statistics in ifconfig for that interface). >> >> So troubleshooting so far: >> I'm running the latest UHD code (3.11.1 - Just git pulled the latest >> today and rebuilt it). >> Works fine on Ubuntu 16.04. No issues with both connected (so it's not >> my code :)) >> There doesn't appear to be any firmware updates to apply to the Huawei >> (always worth a shot) >> The huawei_cdc_ncm linux driver doesn't appear to have had any updates in >> the past couple years (so doesn't look like a linux driver update) >> Nothing showing up from dmesg or in /var/log/syslog or /var/log/messages >> related to failed recv's. >> Made sure there wasn't any data going over the LTE to rule out it's doing >> large data transfers >> I tested with other USB devices in place of the LTE. Works fine. So not >> the port or a general USB issue. >> I tried opening the device with num_recv_frames=1024 to see if that would >> help, no luck. >> I also tried increasing the timeout from the default 0.1 to 0.2 on the >> recv call with no luck there either. >> >> Any suggestions? >> >> So, two thoughts: > > The rPi USB power supply isn't really up to the task of supply > spec-maximum power to each power. Perhaps your LTE device (combined with > B205) is drawing too much power. > > The USB bus bandwidth is *per controller*, and perhaps there just isn't > enough aggregate bandwidth left to service both devices. > > The B205 has no external-power input, as I recall, but it's mostly > designed for USB3.0, where the per-port power is higher. > You might try one of those "power booster" USB2.0 "Y" cables, and plug > the "power only" plug into a 5.0V USB power supply. > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
