What version of UHD? I’ve used SC12 myself without issue. Sent from my iPhone
> On Jul 26, 2018, at 1:28 AM, RizThon <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.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
