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 output. I also have a B210 I can try and see if I get the same results. Do you know if the USB on the USRP uses bulk transfers and is there anything you're aware of in the USB spec that can interfere with them? I'll post my results after I give it a shot tomorrow. On Mon, Jun 25, 2018 at 12:28 AM, Ian Buckley <i...@ionconcepts.com> wrote: > Perhaps try 'sudo lsusb -v' with and without the LTE modem plugged in and > see if that reveals any more clues? > Does uhd_usrp_probe work when the LTE modem is plugged in? > > > On Jun 24, 2018, at 7:14 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > > 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 sure how that's possible. Especially since it > works fine as soon as I pull the LTE adapter out. > > Well, I'm going to go with "it's the LTE adapter". > > > > 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 > > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
