I tend to use more recv_frames at higher rates. Whether this is related to the device becoming catatonic is a shit in the dark.
Sent from my iPhone > On May 26, 2020, at 4:51 PM, Andre Puschmann > <[email protected]> wrote: > > On 26/5/20 22:39, Marcus D Leech wrote: >> What sample rate? > > All LTE samples rates, ranging from 1.92e6 to 30.72e6. > > I have to note that traffic is always full-duplex, we send and receive > at the same rate. Also we always send/receive in 1ms chunks, so > depending depending on the sample rate that is 1ms worth of samples. > >> >> You could try num_recv_frames=128 or higher for higher sample rates. > > We alter the send_frame_size and recv_frame_size depending on the bandwidth. > > For 11.52e6, for example, we use > 'send_frame_size=1024,recv_frame_size=1024'. > > For 23.04e6 we decrease the size and use > `num_recv_frames=64,num_send_frames=64`. > > But we don't alter the num_recv_frames. I guess this means we use > num_recv_frames=32 for all bandwidths. > > I can give your suggestion a try as soon as the device is up again. But > in general, do you reckon we should use different parameters for streaming? > > Thanks > Andre > > > >> >> Sent from my iPhone >> >>>> On May 26, 2020, at 3:52 PM, Andre Puschmann >>>> <[email protected]> wrote: >>> >>> Hey Marcus, >>> >>> thanks for the response. >>> >>>> On 25/5/20 23:44, Marcus D Leech wrote: >>>> Might seem silly >>>> But have you tried a different USB cable! >>>> >>>> Does it exhibit this behavior in a different host? >>>> >>>> Is it just this one device? >>> >>> Actually we have another setup with a different host and different B210 >>> that shows a similar behavior. >>> >>> I had the feeling that when using "otw-format=sc12" for some of the >>> configs we are running, the problem happens quicker. But it's just a >>> feeling. Is there any known unsuitability or caveat when using sc12? >>> >>> In any case, I'll try to approach the issue a bit more systematic over >>> the coming days/weeks and carefully swap cable/USRPs/hosts to see if we >>> can identify a pattern. This may take a while though due to the current >>> situation with lab access, etc. >>> >>> Anyway, if there is anything else that I could try, let me know. >>> >>> Thanks >>> Andre >>> >>> >>> >>>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>>>> On May 25, 2020, at 4:55 PM, Andre Puschmann via USRP-users >>>>>> <[email protected]> wrote: >>>>> >>>>> Hey guys, >>>>> >>>>> I am facing a weird issue with one of the B210 we use in our CI setup. >>>>> It used all day long with shorter and longer runs, with different >>>>> bandwidth configurations, number of channels, stream parameters, etc. >>>>> >>>>> That works fine in principle but after a while the device simply >>>>> wouldn't work any longer. The app is unable to init the device. >>>>> >>>>> $ uhd_usrp_probe >>>>> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; >>>>> UHD_3.15.0.HEAD-0-gaea0e2de >>>>> [INFO] [B200] Loading firmware image: >>>>> /usr/share/uhd/images/usrp_b200_fw.hex... >>>>> [ERROR] [UHD] Device discovery error: EnvironmentError: IOError: Could >>>>> not load firmware: >>>>> EnvironmentError: IOError: ihex_reader::read(): record hander returned >>>>> failure code >>>>> Error: LookupError: KeyError: No devices found for -----> >>>>> Empty Device Address >>>>> >>>>> Trying to reset gives the same error: >>>>> >>>>> $ /usr/lib/uhd/utils/b2xx_fx3_utils -D >>>>> Device opened (VID=0x2500,PID=0x0020) >>>>> B2xx detected... Control of B2xx granted... >>>>> >>>>> Loading firmware >>>>> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; >>>>> UHD_3.15.0.HEAD-0-gaea0e2de >>>>> [INFO] [B200] Loading firmware image: >>>>> /usr/share/uhd/images/usrp_b200_fw.hex... >>>>> Exception while loading firmware: EnvironmentError: IOError: Could not >>>>> load firmware: >>>>> EnvironmentError: IOError: ihex_reader::read(): record hander returned >>>>> failure code >>>>> >>>>> >>>>> After that happened the only way to recover the device is unplug the >>>>> USRP. A simple reboot doesn't help. Dmesg doesn't show any issues. >>>>> >>>>> UHD is 3.15 compiled from source on a vanilla Ubuntu 18.04 LTE (side >>>>> note: there are no pre-built packages for 3.15 in the 18.04 PPA). System >>>>> is a Intel NUC Skull Canyon. Cables are stock ones. Let me know if you >>>>> need any further information on the setup. >>>>> >>>>> Any pointers on what might be wrong here are highly appreciated. >>>>> >>>>> Cheers >>>>> Andre >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> [email protected] >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >>> -- >>> Andre Puschmann >>> >>> Software Radio Systems (SRS) >>> http://www.softwareradiosystems.com >>> >>> PGP/GnuPG key: 6C42AB31 >>> fingerprint: 137A AE49 785B A445 257C 8AD7 D877 A498 6C42 AB31 > > > -- > Andre Puschmann > > Software Radio Systems (SRS) > http://www.softwareradiosystems.com > > PGP/GnuPG key: 6C42AB31 > fingerprint: 137A AE49 785B A445 257C 8AD7 D877 A498 6C42 AB31 _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
