Re: [USRP-users] USRP B-Series Issue with USB LTE Adapter Connected

[Michael West via USRP-users]

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 fails to call recv() quick enough to retrieve the data and
re-queue the transfers.  You can increase the number of transfers by
setting the num_recv_frames in the device args.  I believe the default is
32, but we sometimes recommend setting it much higher (like 256 or 512).
But more buffering will not help if the application cannot keep up with the
rate.  If you can live with lower resolution, you can try using sc8
samples.  That will cut the bandwidth on the USB transport in half.
2.  The recv timeout is the maximum time to wait for the requested data to
arrive.  It is mainly a function of sample rate and the number of samples
requested in the recv() call.  I would not expect changing it to have much
of an effect for the use case you describe.  For best performance, the
number of samples requested should be aligned to the maximum number of
samples per frame and the timeout should be set to the number of samples
divided by the sample rate plus some margin.  The benchmark_rate example
included with UHD is a good reference for sizing the buffer and setting the
timeout value for optimal performance.

Regards,
Michael

On Tue, Jun 26, 2018 at 11:59 AM, GhostOp14 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> 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).  The 8 MSPS rate was probably the max that the setup could
> handle and the added LTE USB communications was just enough to disrupt the
> USRP recv transfer.  Backing the recv size down gave a little more
> bandwidth back to the bus to avoid the overrun.  I wasn't running into it
> on the other systems since they had a more capable CPU and had USB3 buses.
>
> So this brings up a couple of questions...
> 1. When a stream recv is requested is it held in a memory buffer on the
> USRP such that the recv call retrieves it in bulk blocks?  Or does it truly
> need to be processed by the recv loop within a fixed time window so the
> stream can continue to operate on the USRP (hence the overruns)?
> 2. I had adjusted the recv timeout from the default (0.1) to 0.2 to try to
> give it more time for the transfer but that hadn't helped.  Given the
> scenario above what does that timeout actually adjust?
>
> I think I have my solution but any insights would be great.
>
> Thanks!
>
>
> On Mon, Jun 25, 2018 at 12:28 AM, Ian Buckley 
> 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 

Re: [USRP-users] USRP B-Series Issue with USB LTE Adapter Connected

[GhostOp14 via USRP-users]

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).  The 8 MSPS rate was probably the max that the setup could
handle and the added LTE USB communications was just enough to disrupt the
USRP recv transfer.  Backing the recv size down gave a little more
bandwidth back to the bus to avoid the overrun.  I wasn't running into it
on the other systems since they had a more capable CPU and had USB3 buses.

So this brings up a couple of questions...
1. When a stream recv is requested is it held in a memory buffer on the
USRP such that the recv call retrieves it in bulk blocks?  Or does it truly
need to be processed by the recv loop within a fixed time window so the
stream can continue to operate on the USRP (hence the overruns)?
2. I had adjusted the recv timeout from the default (0.1) to 0.2 to try to
give it more time for the transfer but that hadn't helped.  Given the
scenario above what does that timeout actually adjust?

I think I have my solution but any insights would be great.

Thanks!


On Mon, Jun 25, 2018 at 12:28 AM, Ian Buckley  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.
>>
>>
>>
>> 

Re: [USRP-users] USRP B-Series Issue with USB LTE Adapter Connected

[GhostOp14 via USRP-users]

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  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

Re: [USRP-users] USRP B-Series Issue with USB LTE Adapter Connected

[Gilad Beeri (ApolloShield) via USRP-users]

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 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B-Series Issue with USB LTE Adapter Connected

[Marcus D. Leech via USRP-users]

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 
mailto: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] USRP B-Series Issue with USB LTE Adapter Connected

[GhostOp14 via USRP-users]

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?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com