Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

>
>
> The SC12 support apparently broke at some point.  I know that Michael West
> (Ettus R team) has been working to get it working again,
>   but won't be ready for a little bit.
>
> I use SC12 myself in my lab, but I don't recall which UHD version I'm
> using in the lab, and won't be there until tomorrow evening.  If possible
>   try to revert to 3.10.
>
Thanks a lot for your feedback, I'll try with older versions then. They did
say that they fixed things with 3.13.0.0 concerning sc12/8, but it seemed
it made things worse. I'll try that again also.

If someone from Ettus is following, is there any schedule on the SC12
issue? Was that supposed to be fixed in 3.13.0.0?


> Thing is, there's no way anyone can guarantee any particular sample rate
> is possible on your system, because of significant differences from
>   system to system, and significant differences from workload to
> workload.Anything that involves recording samples to disk at high input
>   rates is very tricky to make work, for example.  Anything that involves
> a lot of processing of the samples is going to have a higher compute
>   load, and be more likely to cause overruns.
>
I understand, it's just that at this point I'm only streaming, without any
processing, not even saving to disk, on what I would expect be a more than
decent computer, without much happening on the side.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/27/2018 12:02 AM, RizThon wrote:

I've tried with 3.12.0.0, on both Windows and Linux.

On Ubuntu 18.04, I can set num_recv_frames to what seems like any 
number without getting error. I tried 128, 256, even 512 and 1024.


I do get better results than on Windows, but I'm still getting lots of 
overflows.


I did try 3.13.0.0 on Windows just when it was out, but I got worst 
result (2850 overruns at 28MS/s in SC16 instead of just a few). So for 
now I reverted back to 3.12.


So you confirm SC12 is supposed to work on a B210 (and I guess also on 
any B2x0)? That may allow me to reach 56MS/s


If that's the case, what can be the problem?
The SC12 support apparently broke at some point.  I know that Michael 
West (Ettus R team) has been working to get it working again,

  but won't be ready for a little bit.

I use SC12 myself in my lab, but I don't recall which UHD version I'm 
using in the lab, and won't be there until tomorrow evening.  If possible

  try to revert to 3.10.

Thing is, there's no way anyone can guarantee any particular sample rate 
is possible on your system, because of significant differences from
  system to system, and significant differences from workload to 
workload.Anything that involves recording samples to disk at high input
  rates is very tricky to make work, for example.  Anything that 
involves a lot of processing of the samples is going to have a higher 
compute

  load, and be more likely to cause overruns.




Thanks a lot.

On Fri, Jul 27, 2018 at 12:14 AM Marcus D. Leech > wrote:


What version of UHD?  I’ve used SC12 myself without issue.

Sent from my iPhone

On Jul 26, 2018, at 1:28 AM, RizThon mailto:rizt...@gmail.com>> wrote:


SC12 actually gives me an error as soon as it starts streaming
(with or without specifying num_recv_frames=44). Using the
--continue option, I get tons of such errors:

[ERROR] [STREAMER] The receive packet handler caught a value
exception.
ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET

Is this specific to my issues with USB, meaning on Linux it works
well, or is the B210 (and B2x0 generally) not handling sc12?

(https://files.ettus.com/manual/structuhd_1_1stream__args__t.htmlmentions/Only
some devices/for SC12).

Thanks again.

On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 07/25/2018 10:18 PM, RizThon wrote:

I already tried smaller values, but not small enough. It
seems the highest I can go is num_recv_frames=44. Anything
higher gives me errors.

At 40MS/s, without that parameter, I get 160 to 180
overflows over 20 seconds, while with num_recv_frames=44 I
only get 20 to 30.

This actually allows me to stream at 55MS/s in *sc8* for 20s
without any overflow! With sc16 though, I don't seem much
difference and still get more than 5000 overflows.

Is it possible to use sc12 with the B2x0? The ADC having a
12 bits resolution, we wouldn't lose any data.

Concerning num_recv_frames, is this a problem with the
Windows USB driver, meaning I wouldn't get better results on
another Windows computer? I tried other drivers, using
Zadig. Only the "WinUSB" driver works, but it doesn't work
better than the original Ettus driver.

Do you advise people to use Linux rather than Windows for
USB performance reasons? Should using 256 or 128 fix my
streaming problems?

Thanks.



On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 07/25/2018 01:08 PM, RizThon wrote:



Use a 5-6V supply capable of 2 or 3 amps.


Thanks, it's actually working fine, the led properly
turned green after the firmware and gateware were uploaded.

Trying .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
  Num received samples: 201778444
  Num dropped samples:  2800
  Num overruns detected:2800
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0

It seems I still can't stream faster than around
28MS/s. I still get similar results with
.\rx_samples_to_file.exe (using --null to not store to
file).

Should I try to run some tests from
http://files.ettus.com/manual/page_rdtesting.html ?

Concerning the error "[ERROR] [USB]
libusb_session_impl::libusb_event_handler_task:
LIBUSB_ERROR_CODE -1" that I get when 

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

I've tried with 3.12.0.0, on both Windows and Linux.

On Ubuntu 18.04, I can set num_recv_frames to what seems like any number
without getting error. I tried 128, 256, even 512 and 1024.

I do get better results than on Windows, but I'm still getting lots of
overflows.

I did try 3.13.0.0 on Windows just when it was out, but I got worst result
(2850 overruns at 28MS/s in SC16 instead of just a few). So for now I
reverted back to 3.12.

So you confirm SC12 is supposed to work on a B210 (and I guess also on any
B2x0)? That may allow me to reach 56MS/s

If that's the case, what can be the problem?

Thanks a lot.

On Fri, Jul 27, 2018 at 12:14 AM Marcus D. Leech  wrote:

> What version of UHD?  I’ve used SC12 myself without issue.
>
> Sent from my iPhone
>
> On Jul 26, 2018, at 1:28 AM, RizThon  wrote:
>
> SC12 actually gives me an error as soon as it starts streaming (with or
> without specifying num_recv_frames=44). Using the --continue option, I
> get tons of such errors:
>
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: bad vrt header or packet fragment
> Error: Receiver error: ERROR_CODE_BAD_PACKET
>
> Is this specific to my issues with USB, meaning on Linux it works well, or
> is the B210 (and B2x0 generally) not handling sc12?  (
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions 
> *Only
> some devices* for SC12).
>
> Thanks again.
>
> On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech 
> wrote:
>
>> On 07/25/2018 10:18 PM, RizThon wrote:
>>
>> I already tried smaller values, but not small enough. It seems the
>> highest I can go is num_recv_frames=44. Anything higher gives me errors.
>>
>> At 40MS/s, without that parameter, I get 160 to 180 overflows over 20
>> seconds, while with  num_recv_frames=44 I only get 20 to 30.
>>
>> This actually allows me to stream at 55MS/s in *sc8* for 20s without any
>> overflow! With sc16 though, I don't seem much difference and still get more
>> than 5000 overflows.
>>
>> Is it possible to use sc12 with the B2x0? The ADC having a 12 bits
>> resolution, we wouldn't lose any data.
>>
>> Concerning num_recv_frames, is this a problem with the Windows USB
>> driver, meaning I wouldn't get better results on another Windows computer? I
>> tried other drivers, using Zadig. Only the "WinUSB" driver works, but it
>> doesn't work better than the original Ettus driver.
>>
>> Do you advise people to use Linux rather than Windows for USB performance
>> reasons? Should using 256 or 128 fix my streaming problems?
>>
>> Thanks.
>>
>>
>>
>> On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech 
>> wrote:
>>
>>> On 07/25/2018 01:08 PM, RizThon wrote:
>>>
>>> Use a 5-6V supply capable of 2 or 3 amps.

 Thanks, it's actually working fine, the led properly turned green after
>>> the firmware and gateware were uploaded.
>>>
>>> Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
>>> Benchmark rate summary:
>>>   Num received samples: 201778444
>>>   Num dropped samples:  2800
>>>   Num overruns detected:2800
>>>   Num transmitted samples:  0
>>>   Num sequence errors (Tx): 0
>>>   Num sequence errors (Rx): 0
>>>   Num underruns detected:   0
>>>   Num late commands:0
>>>   Num timeouts (Tx):0
>>>   Num timeouts (Rx):0
>>>
>>> It seems I still can't stream faster than around 28MS/s. I still get
>>> similar results with .\rx_samples_to_file.exe (using --null to not
>>> store to file).
>>>
>>> Should I try to run some tests from
>>> http://files.ettus.com/manual/page_rdtesting.html ?
>>>
>>> Concerning the error "[ERROR] [USB]
>>> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that
>>> I get when specifying num_recv_frames, what could I do? Should I try a
>>> different driver? Has anyone already experienced that error?
>>>
>>> Thanks.
>>>
>>> Try with a smaller number?The Windows LIBUSB behaves differently
>>> than the Linux version.  On Linux, I can usually ask for 256 without
>>>   any issue.  Try 64.
>>>
>>>
>>> The SC12 format should work just fine.
>>
>> The particular values available for num_recv_frames seem to be libusb
>> implementation specific, and to a certain extent controller specific as
>> well.
>>
>> Windows is known to have somewhat poorer performance (at least with
>> LibUSB type schemes) that Linux, TBH.
>>
>>
>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

What version of UHD?  I’ve used SC12 myself without issue. 

Sent from my iPhone

> On Jul 26, 2018, at 1:28 AM, RizThon  wrote:
> 
> SC12 actually gives me an error as soon as it starts streaming (with or 
> without specifying num_recv_frames=44). Using the --continue option, I get 
> tons of such errors:
> 
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: bad vrt header or packet fragment
> Error: Receiver error: ERROR_CODE_BAD_PACKET
> 
> Is this specific to my issues with USB, meaning on Linux it works well, or is 
> the B210 (and B2x0 generally) not handling sc12?  
> (https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions 
> Only some devices for SC12). 
> 
> Thanks again.
> 
>> On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech  wrote:
>>> On 07/25/2018 10:18 PM, RizThon wrote:
>>> I already tried smaller values, but not small enough. It seems the highest 
>>> I can go is num_recv_frames=44. Anything higher gives me errors.
>>> 
>>> At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 
>>> seconds, while with  num_recv_frames=44 I only get 20 to 30.
>>> 
>>> This actually allows me to stream at 55MS/s in sc8 for 20s without any 
>>> overflow! With sc16 though, I don't seem much difference and still get more 
>>> than 5000 overflows.
>>> 
>>> Is it possible to use sc12 with the B2x0? The ADC having a 12 bits 
>>> resolution, we wouldn't lose any data.
>>> 
>>> Concerning num_recv_frames, is this a problem with the Windows USB driver, 
>>> meaning I wouldn't get better results on another Windows computer? I tried 
>>> other drivers, using Zadig. Only the "WinUSB" driver works, but it doesn't 
>>> work better than the original Ettus driver.
>>> 
>>> Do you advise people to use Linux rather than Windows for USB performance 
>>> reasons? Should using 256 or 128 fix my streaming problems?
>>> 
>>> Thanks.
>>> 
>>> 
>>> 
 On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech  wrote:
> On 07/25/2018 01:08 PM, RizThon wrote:
>>> Use a 5-6V supply capable of 2 or 3 amps.
> Thanks, it's actually working fine, the led properly turned green after 
> the firmware and gateware were uploaded.
> 
> Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
> Benchmark rate summary:
>   Num received samples: 201778444
>   Num dropped samples:  2800
>   Num overruns detected:2800
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
> 
> It seems I still can't stream faster than around 28MS/s. I still get 
> similar results with .\rx_samples_to_file.exe (using --null to not store 
> to file).
> 
> Should I try to run some tests from 
> http://files.ettus.com/manual/page_rdtesting.html ?
> 
> Concerning the error "[ERROR] [USB] 
> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" 
> that I get when specifying num_recv_frames, what could I do? Should I try 
> a different driver? Has anyone already experienced that error?
> 
> Thanks.
> 
 Try with a smaller number?The Windows LIBUSB behaves differently than 
 the Linux version.  On Linux, I can usually ask for 256 without
   any issue.  Try 64.
 
 
>> The SC12 format should work just fine.
>> 
>> The particular values available for num_recv_frames seem to be libusb 
>> implementation specific, and to a certain extent controller specific as well.
>> 
>> Windows is known to have somewhat poorer performance (at least with LibUSB 
>> type schemes) that Linux, TBH.
>> 
>> 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

SC12 actually gives me an error as soon as it starts streaming (with or
without specifying num_recv_frames=44). Using the --continue option, I get
tons of such errors:

[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET

Is this specific to my issues with USB, meaning on Linux it works well, or
is the B210 (and B2x0 generally) not handling sc12?  (
https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions *Only
some devices* for SC12).

Thanks again.

On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech  wrote:

> On 07/25/2018 10:18 PM, RizThon wrote:
>
> I already tried smaller values, but not small enough. It seems the highest
> I can go is num_recv_frames=44. Anything higher gives me errors.
>
> At 40MS/s, without that parameter, I get 160 to 180 overflows over 20
> seconds, while with  num_recv_frames=44 I only get 20 to 30.
>
> This actually allows me to stream at 55MS/s in *sc8* for 20s without any
> overflow! With sc16 though, I don't seem much difference and still get more
> than 5000 overflows.
>
> Is it possible to use sc12 with the B2x0? The ADC having a 12 bits
> resolution, we wouldn't lose any data.
>
> Concerning num_recv_frames, is this a problem with the Windows USB driver,
> meaning I wouldn't get better results on another Windows computer? I
> tried other drivers, using Zadig. Only the "WinUSB" driver works, but it
> doesn't work better than the original Ettus driver.
>
> Do you advise people to use Linux rather than Windows for USB performance
> reasons? Should using 256 or 128 fix my streaming problems?
>
> Thanks.
>
>
>
> On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech  wrote:
>
>> On 07/25/2018 01:08 PM, RizThon wrote:
>>
>> Use a 5-6V supply capable of 2 or 3 amps.
>>>
>>> Thanks, it's actually working fine, the led properly turned green after
>> the firmware and gateware were uploaded.
>>
>> Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
>> Benchmark rate summary:
>>   Num received samples: 201778444
>>   Num dropped samples:  2800
>>   Num overruns detected:2800
>>   Num transmitted samples:  0
>>   Num sequence errors (Tx): 0
>>   Num sequence errors (Rx): 0
>>   Num underruns detected:   0
>>   Num late commands:0
>>   Num timeouts (Tx):0
>>   Num timeouts (Rx):0
>>
>> It seems I still can't stream faster than around 28MS/s. I still get
>> similar results with .\rx_samples_to_file.exe (using --null to not store
>> to file).
>>
>> Should I try to run some tests from
>> http://files.ettus.com/manual/page_rdtesting.html ?
>>
>> Concerning the error "[ERROR] [USB]
>> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that
>> I get when specifying num_recv_frames, what could I do? Should I try a
>> different driver? Has anyone already experienced that error?
>>
>> Thanks.
>>
>> Try with a smaller number?The Windows LIBUSB behaves differently than
>> the Linux version.  On Linux, I can usually ask for 256 without
>>   any issue.  Try 64.
>>
>>
>> The SC12 format should work just fine.
>
> The particular values available for num_recv_frames seem to be libusb
> implementation specific, and to a certain extent controller specific as
> well.
>
> Windows is known to have somewhat poorer performance (at least with LibUSB
> type schemes) that Linux, TBH.
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 10:18 PM, RizThon wrote:
I already tried smaller values, but not small enough. It seems the 
highest I can go is num_recv_frames=44. Anything higher gives me errors.


At 40MS/s, without that parameter, I get 160 to 180 overflows over 20 
seconds, while with num_recv_frames=44 I only get 20 to 30.


This actually allows me to stream at 55MS/s in *sc8* for 20s without 
any overflow! With sc16 though, I don't seem much difference and still 
get more than 5000 overflows.


Is it possible to use sc12 with the B2x0? The ADC having a 12 bits 
resolution, we wouldn't lose any data.


Concerning num_recv_frames, is this a problem with the Windows USB 
driver, meaning I wouldn't get better results on another Windows 
computer? I tried other drivers, using Zadig. Only the "WinUSB" driver 
works, but it doesn't work better than the original Ettus driver.


Do you advise people to use Linux rather than Windows for USB 
performance reasons? Should using 256 or 128 fix my streaming problems?


Thanks.



On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech > wrote:


On 07/25/2018 01:08 PM, RizThon wrote:



Use a 5-6V supply capable of 2 or 3 amps.


Thanks, it's actually working fine, the led properly turned green
after the firmware and gateware were uploaded.

Trying .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
  Num received samples: 201778444
  Num dropped samples:  2800
  Num overruns detected:2800
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0

It seems I still can't stream faster than around 28MS/s. I still
get similar results with .\rx_samples_to_file.exe (using --null
to not store to file).

Should I try to run some tests from
http://files.ettus.com/manual/page_rdtesting.html ?

Concerning the error "[ERROR] [USB]
libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE
-1" that I get when specifying num_recv_frames, what could I do?
Should I try a different driver? Has anyone already experienced
that error?

Thanks.


Try with a smaller number?The Windows LIBUSB behaves
differently than the Linux version.  On Linux, I can usually ask
for 256 without
  any issue.  Try 64.



The SC12 format should work just fine.

The particular values available for num_recv_frames seem to be libusb 
implementation specific, and to a certain extent controller specific as 
well.


Windows is known to have somewhat poorer performance (at least with 
LibUSB type schemes) that Linux, TBH.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

I already tried smaller values, but not small enough. It seems the highest
I can go is num_recv_frames=44. Anything higher gives me errors.

At 40MS/s, without that parameter, I get 160 to 180 overflows over 20
seconds, while with  num_recv_frames=44 I only get 20 to 30.

This actually allows me to stream at 55MS/s in *sc8* for 20s without any
overflow! With sc16 though, I don't seem much difference and still get more
than 5000 overflows.

Is it possible to use sc12 with the B2x0? The ADC having a 12 bits
resolution, we wouldn't lose any data.

Concerning num_recv_frames, is this a problem with the Windows USB driver,
meaning I wouldn't get better results on another Windows computer? I tried
other drivers, using Zadig. Only the "WinUSB" driver works, but it doesn't
work better than the original Ettus driver.

Do you advise people to use Linux rather than Windows for USB performance
reasons? Should using 256 or 128 fix my streaming problems?

Thanks.



On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech  wrote:

> On 07/25/2018 01:08 PM, RizThon wrote:
>
> Use a 5-6V supply capable of 2 or 3 amps.
>>
>> Thanks, it's actually working fine, the led properly turned green after
> the firmware and gateware were uploaded.
>
> Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
> Benchmark rate summary:
>   Num received samples: 201778444
>   Num dropped samples:  2800
>   Num overruns detected:2800
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
> It seems I still can't stream faster than around 28MS/s. I still get
> similar results with .\rx_samples_to_file.exe (using --null to not store
> to file).
>
> Should I try to run some tests from
> http://files.ettus.com/manual/page_rdtesting.html ?
>
> Concerning the error "[ERROR] [USB]
> libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that
> I get when specifying num_recv_frames, what could I do? Should I try a
> different driver? Has anyone already experienced that error?
>
> Thanks.
>
> Try with a smaller number?The Windows LIBUSB behaves differently than
> the Linux version.  On Linux, I can usually ask for 256 without
>   any issue.  Try 64.
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 01:08 PM, RizThon wrote:



Use a 5-6V supply capable of 2 or 3 amps.


Thanks, it's actually working fine, the led properly turned green 
after the firmware and gateware were uploaded.


Trying .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
  Num received samples: 201778444
  Num dropped samples:  2800
  Num overruns detected:2800
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:   0
  Num timeouts (Tx):   0
  Num timeouts (Rx):   0

It seems I still can't stream faster than around 28MS/s. I still get 
similar results with .\rx_samples_to_file.exe (using --null to not 
store to file).


Should I try to run some tests from 
http://files.ettus.com/manual/page_rdtesting.html ?


Concerning the error "[ERROR] [USB] 
libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE 
-1" that I get when specifying num_recv_frames, what could I do? 
Should I try a different driver? Has anyone already experienced that 
error?


Thanks.

Try with a smaller number?The Windows LIBUSB behaves differently 
than the Linux version.  On Linux, I can usually ask for 256 without

  any issue.  Try 64.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

>
> Use a 5-6V supply capable of 2 or 3 amps.
>
> Thanks, it's actually working fine, the led properly turned green after
the firmware and gateware were uploaded.

Trying  .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
  Num received samples: 201778444
  Num dropped samples:  2800
  Num overruns detected:2800
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:0
  Num timeouts (Tx):0
  Num timeouts (Rx):0

It seems I still can't stream faster than around 28MS/s. I still get
similar results with .\rx_samples_to_file.exe (using --null to not store to
file).

Should I try to run some tests from
http://files.ettus.com/manual/page_rdtesting.html ?

Concerning the error "[ERROR] [USB]
libusb_session_impl::libusb_event_handler_task: LIBUSB_ERROR_CODE -1" that
I get when specifying num_recv_frames, what could I do? Should I try a
different driver? Has anyone already experienced that error?

Thanks.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Anon Lister via USRP-users]

Used to have to compile the driver for the lime in debug mode to get
underrun reporting. Though I believe they may have changed some of that
recently.

On Tue, Jul 24, 2018, 23:57 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 07/24/2018 11:42 PM, RizThon via USRP-users wrote:
>
> I have used the b2x0 radios for some applications myself, we have had no
>> luck sampling much higher than 30MS/s. I think real-world USB3 speeds max
>> out around 100MB/s.
>>
>> Will
>
>
> Thanks Will, that matches my experience. At 28MS/s it tells me I need to
> stream at 112MB/s.
>
> You cannot stream faster than about 30Msps from the B210 when in
>> dual-channel mode.  This is a limitation of the data bus architecture on  the
>> AD9371 chip, and not strictly a limitation of the B2xx FPGA.
>
>
> Sorry for the misunderstanding. On the B210, I'm in *single channel*, RX
> only, and I start having overruns at 28MS/s.
>
> You can try using the "num_recv_frames" option in the device argument--I'd
> suggest trying 128 and 256.
>
> I'll also note that, near as I can tell, LimeSDR drivers dont' reliably
> report overruns, so you may be getting them without knowing about it.
>
>
>
> I was just giving my experience with a Lime where I can stream in dual
> channel, RX only, at 56MS/s. In that case though the Lime sends its data
> back as SC12, meaning it can pack a bit more samples.
>
> FYI, we fixed a couple of sc12/8 related issues on our latest master
>> branch. As Marcus says, if you're doing dual channel on the B210, you
>> can only go to 30.72 Msps though.
>>
>
> Should I play with the OTW format? Does the B210 handle SC12 (
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions 
> *Only
> some devices* for SC12).
>
> I tried rx_samples_to_file.exe from
> http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe
> . If I choose SC8, then I can stream faster. It seems I can go up to 49MS/s
> without error, over 20 seconds.
>
> At 50MS/s and up I get an error
> rx_samples_to_file.exe --null --time 20 --freq 2450e6 --gain 50 --spb
> 1 --rate 50e6 --wirefmt sc8
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: bad vrt header or packet fragment
> Error: Receiver error: ERROR_CODE_BAD_PACKET
>
> I modified the code to allow --wirefmt sc12, I also get an error, even at
> 28MS/s
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: bad vrt header or packet fragment
> but again I'm not sure if the B210 handles that format .
>
> UHD 3.13 is just out, so I tried
> http://files.ettus.com/binaries/uhd/uhd_003.013.000.000-release/Windows-7-x86_64/uhd_3.13.0.0-release_Win32_VS2014.exe
> . I now get 2850 overruns at 28MS/s in SC16, while I'd get up to 5 with the
> previous version. In SC8 I can go up to 40MS/s only, instead of 49. With
> the x64 version I get similar results. So for now I reverted back to 3.12.
>
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 12:18 PM, RizThon wrote:



On Wed, Jul 25, 2018 at 10:57 PM Marcus D. Leech > wrote:


Presuming you followed the instructions here for UHD installation:

https://files.ettus.com/manual/page_install.html

Everything should be fine.

Yes I installed 
http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe 
as well as the driver 
http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
In the device manager, I see it under /USRPs / Ettus Research LLC 
B200/B210/


I can't remember if we covered this or not.  Are you
externally-powering the B210?   Some USB ports don't quite provide
enough power.

I only tried it bus-powered.

Unfortunately it seems my power supply doesn't work well. When I plug 
it, the power led turns on then off. If I then connect the USB, it's 
still off.


What's the min/max voltage I can use? Maybe I can use a different 
power supply.


Thanks.

Use a 5-6V supply capable of 2 or 3 amps.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

On Wed, Jul 25, 2018 at 10:57 PM Marcus D. Leech  wrote:

> Presuming you followed the instructions here for UHD installation:
>
> https://files.ettus.com/manual/page_install.html
>
> Everything should be fine.
>
Yes I installed
http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe
as well as the driver
http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip
In the device manager, I see it under *USRPs / Ettus Research LLC B200/B210*



> I can't remember if we covered this or not.  Are you externally-powering
> the B210?   Some USB ports don't quite provide enough power.
>
I only tried it bus-powered.

Unfortunately it seems my power supply doesn't work well. When I plug it,
the power led turns on then off. If I then connect the USB, it's still off.

What's the min/max voltage I can use? Maybe I can use a different power
supply.

Thanks.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/25/2018 01:56 AM, RizThon wrote:


You can try using the "num_recv_frames" option in the device
argument--I'd suggest trying 128 and 256.


I get tons of errors right after seeing [INFO] [B200] Operating over 
USB 3. Would this explain why I can't seem to stream fast?


Here's what I get for 128
Creating the usrp device with: num_recv_frames=128...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900; 
UHD_3.12.0.0-release

[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: 
LIBUSB_ERROR_CODE -1

[...]
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: 
LIBUSB_ERROR_CODE -1

[INFO] [B200] Initialize CODEC control...
[...]

With 256 the program crashes and I only see
Creating the usrp device with: num_recv_frames=256...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900; 
UHD_3.12.0.0-release

[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: 
LIBUSB_ERROR_CODE -1

[ERROR] [USB] libusb_sessi

Can this be a USB driver problem? I'm using the one from 
http://files.ettus.com/binaries/misc/ dated 29-Mar-2016 19:52.


Can I run any test to make sure everything is fine (B210, drivers, 
software)?


I'll also note that, near as I can tell, LimeSDR drivers dont'
reliably report overruns, so you may be getting them without
knowing about it.


I always check the timestamps returned, so I'm pretty sure I only get 
very few overruns with the Lime.

Presuming you followed the instructions here for UHD installation:

https://files.ettus.com/manual/page_install.html

Everything should be fine.

I can't remember if we covered this or not.  Are you externally-powering 
the B210?   Some USB ports don't quite provide enough power.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[RizThon via USRP-users]

>
> You can try using the "num_recv_frames" option in the device argument--I'd
> suggest trying 128 and 256.
>

I get tons of errors right after seeing [INFO] [B200] Operating over
USB 3. Would
this explain why I can't seem to stream fast?

Here's what I get for 128
Creating the usrp device with: num_recv_frames=128...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900;
UHD_3.12.0.0-release
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task:
LIBUSB_ERROR_CODE -1
[...]
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task:
LIBUSB_ERROR_CODE -1
[INFO] [B200] Initialize CODEC control...
[...]

With 256 the program crashes and I only see
Creating the usrp device with: num_recv_frames=256...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900;
UHD_3.12.0.0-release
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task:
LIBUSB_ERROR_CODE -1
[ERROR] [USB] libusb_sessi

Can this be a USB driver problem? I'm using the one from
http://files.ettus.com/binaries/misc/ dated 29-Mar-2016 19:52.

Can I run any test to make sure everything is fine (B210, drivers,
software)?

I'll also note that, near as I can tell, LimeSDR drivers dont' reliably
> report overruns, so you may be getting them without knowing about it.
>

I always check the timestamps returned, so I'm pretty sure I only get very
few overruns with the Lime.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/24/2018 11:42 PM, RizThon via USRP-users wrote:


I have used the b2x0 radios for some applications myself, we have
had no luck sampling much higher than 30MS/s. I think real-world
USB3 speeds max out around 100MB/s.

Will

Thanks Will, that matches my experience. At 28MS/s it tells me I need 
to stream at 112MB/s.


You cannot stream faster than about 30Msps from the B210 when in
dual-channel mode.  This is a limitation of the data bus
architecture on  the AD9371 chip, and not strictly a limitation of
the B2xx FPGA.


Sorry for the misunderstanding. On the B210, I'm in *single channel*, 
RX only, and I start having overruns at 28MS/s.
You can try using the "num_recv_frames" option in the device 
argument--I'd suggest trying 128 and 256.


I'll also note that, near as I can tell, LimeSDR drivers dont' reliably 
report overruns, so you may be getting them without knowing about it.





I was just giving my experience with a Lime where I can stream in dual 
channel, RX only, at 56MS/s. In that case though the Lime sends its 
data back as SC12, meaning it can pack a bit more samples.


FYI, we fixed a couple of sc12/8 related issues on our latest master
branch. As Marcus says, if you're doing dual channel on the B210, you
can only go to 30.72 Msps though.


Should I play with the OTW format? Does the B210 handle SC12 
(https://files.ettus.com/manual/structuhd_1_1stream__args__t.html 
mentions/Only some devices/for SC12).


I tried rx_samples_to_file.exe from 
http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe 
. If I choose SC8, then I can stream faster. It seems I can go up to 
49MS/s without error, over 20 seconds.


At 50MS/s and up I get an error
rx_samples_to_file.exe --null --time 20 --freq 2450e6 --gain 50 --spb 
1 --rate 50e6 --wirefmt sc8

[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET

I modified the code to allow --wirefmt sc12, I also get an error, even 
at 28MS/s

[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
but again I'm not sure if the B210 handles that format .

UHD 3.13 is just out, so I tried 
http://files.ettus.com/binaries/uhd/uhd_003.013.000.000-release/Windows-7-x86_64/uhd_3.13.0.0-release_Win32_VS2014.exe 
. I now get 2850 overruns at 28MS/s in SC16, while I'd get up to 5 
with the previous version. In SC8 I can go up to 40MS/s only, instead 
of 49. With the x64 version I get similar results. So for now I 
reverted back to 3.12.






___
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] B210 sampling rate

[RizThon via USRP-users]

>
> I have used the b2x0 radios for some applications myself, we have had no
> luck sampling much higher than 30MS/s. I think real-world USB3 speeds max
> out around 100MB/s.
>
> Will



Thanks Will, that matches my experience. At 28MS/s it tells me I need to
stream at 112MB/s.

You cannot stream faster than about 30Msps from the B210 when in
> dual-channel mode.  This is a limitation of the data bus architecture on  the
> AD9371 chip, and not strictly a limitation of the B2xx FPGA.


Sorry for the misunderstanding. On the B210, I'm in *single channel*, RX
only, and I start having overruns at 28MS/s.

I was just giving my experience with a Lime where I can stream in dual
channel, RX only, at 56MS/s. In that case though the Lime sends its data
back as SC12, meaning it can pack a bit more samples.

FYI, we fixed a couple of sc12/8 related issues on our latest master
> branch. As Marcus says, if you're doing dual channel on the B210, you
> can only go to 30.72 Msps though.
>

Should I play with the OTW format? Does the B210 handle SC12 (
https://files.ettus.com/manual/structuhd_1_1stream__args__t.html mentions *Only
some devices* for SC12).

I tried rx_samples_to_file.exe from
http://files.ettus.com/binaries/uhd/latest_release/Windows7/uhd_3.12.0.0-release_Win32_VS2014.exe
. If I choose SC8, then I can stream faster. It seems I can go up to 49MS/s
without error, over 20 seconds.

At 50MS/s and up I get an error
rx_samples_to_file.exe --null --time 20 --freq 2450e6 --gain 50 --spb 1
--rate 50e6 --wirefmt sc8
[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET

I modified the code to allow --wirefmt sc12, I also get an error, even at
28MS/s
[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
but again I'm not sure if the B210 handles that format .

UHD 3.13 is just out, so I tried
http://files.ettus.com/binaries/uhd/uhd_003.013.000.000-release/Windows-7-x86_64/uhd_3.13.0.0-release_Win32_VS2014.exe
. I now get 2850 overruns at 28MS/s in SC16, while I'd get up to 5 with the
previous version. In SC8 I can go up to 40MS/s only, instead of 49. With
the x64 version I get similar results. So for now I reverted back to 3.12.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 sampling rate

[Martin Braun via USRP-users]

FYI, we fixed a couple of sc12/8 related issues on our latest master
branch. As Marcus says, if you're doing dual channel on the B210, you
can only go to 30.72 Msps though.

-- M


On 07/24/2018 12:06 PM, Marcus D. Leech via USRP-users wrote:
> On 07/24/2018 03:18 AM, RizThon via USRP-users wrote:
>> Hi all,
>>
>> I'm still having issues with a B210 with sample rates greater than
>> 28MS/s. At 28 I get a few overruns out of a million blocks of 1024
>> samples, but as I sample faster, the number of overruns grow fast.
>>
>> I have an AMD Ryzen 7 2700 (8 physical cores @ 3.2GHz), 16GB
>> RAM, Gigabyte GA-AB350N, Windows 10. The USB driver is
>> from http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip .
>>
>> I've tried adding "num_recv_frames=256" but I get an error:
>>
>> Creating the usrp device with: num_recv_frames=256...
>> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106300;
>> UHD_3.11.0.1-37-g2c9087d1
>> [INFO] [B200] Detected Device: B210
>> [INFO] [B200] Operating over USB 3.
>> [ERROR] [USB] libusb_session_impl::libusb_event_handler_task:
>> LIBUSB_ERROR_CODE -1
>>
>> I would have expected to be able to stream with barely any overrun at
>> 56MS/s on that computer. I stream at that speed in dual channel on a
>> LimeSDR (in SC12 format).
>>
>> Any advice on how to get better results?
>>
>> Thanks.
>>
> You cannot stream faster than about 30Msps from the B210 when in
> dual-channel mode.  This is a limitation of the data bus architecture on
>   the AD9371 chip, and not strictly a limitation of the B2xx FPGA.
> 
> 
> 
> 
> ___
> 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] B210 sampling rate

[Marcus D. Leech via USRP-users]

On 07/24/2018 03:18 AM, RizThon via USRP-users wrote:

Hi all,

I'm still having issues with a B210 with sample rates greater than 
28MS/s. At 28 I get a few overruns out of a million blocks of 1024 
samples, but as I sample faster, the number of overruns grow fast.


I have an AMD Ryzen 7 2700 (8 physical cores @ 3.2GHz), 16GB 
RAM, Gigabyte GA-AB350N, Windows 10. The USB driver is from 
http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip .


I've tried adding "num_recv_frames=256" but I get an error:

Creating the usrp device with: num_recv_frames=256...
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106300; 
UHD_3.11.0.1-37-g2c9087d1

[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 3.
[ERROR] [USB] libusb_session_impl::libusb_event_handler_task: 
LIBUSB_ERROR_CODE -1


I would have expected to be able to stream with barely any overrun at 
56MS/s on that computer. I stream at that speed in dual channel on a 
LimeSDR (in SC12 format).


Any advice on how to get better results?

Thanks.

You cannot stream faster than about 30Msps from the B210 when in 
dual-channel mode.  This is a limitation of the data bus architecture on

  the AD9371 chip, and not strictly a limitation of the B2xx FPGA.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com