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