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
