For completion here: This is topic now a public UHD issue : https://github.com/EttusResearch/uhd/issues/475
R&D's Michael West replied there "We are aware of the issue and already have a fix in progress. It should be available within 2-4 weeks." On Wed, Aug 11, 2021 at 2:31 PM Ron Economos <w...@comcast.net> wrote: > Here's what's working for me. > > 1) git clone https://github.com/EttusResearch/uhd.git > > 2) git checkout v4.0.0.0 -b tmp > > 3) edit the file host/lib/usrp/cores/rx_vita_core_3000.cpp and apply the > one line patch in the correct place (before the comment "// issue the > stream command"). > > _continuous_streaming = stream_cmd.stream_mode > == > stream_cmd_t::STREAM_MODE_START_CONTINUOUS; > > 4) git diff > > If you edited the file correctly, you should see: > > diff --git a/host/lib/usrp/cores/rx_vita_core_3000.cpp > b/host/lib/usrp/cores/rx_vita_core_3000.cpp > index 4b09f75fd..368ae8e0a 100644 > --- a/host/lib/usrp/cores/rx_vita_core_3000.cpp > +++ b/host/lib/usrp/cores/rx_vita_core_3000.cpp > @@ -117,6 +117,9 @@ struct rx_vita_core_3000_impl : rx_vita_core_3000 > cmd_word |= uint32_t((inst_stop) ? 1 : 0) << 28; > cmd_word |= (inst_samps) ? stream_cmd.num_samps : ((inst_stop) ? > 0 : 1); > > + _continuous_streaming = stream_cmd.stream_mode > + == > stream_cmd_t::STREAM_MODE_START_CONTINUOUS; > + > // issue the stream command > _iface->poke32(REG_CTRL_CMD, cmd_word); > const uint64_t ticks = > > 5) build as usual > > Just because the patch is in 4.1.0.0 and 4.1.0.1, doesn't mean they are > fixed. Something else could be broken that causes the same issue. > > Ron > On 8/11/21 9:39 AM, Paul Atreides wrote: > > just uninstalled and changed to origin/UHD4.1 and i have the same issue. > On branch UHD-4.1 > Your branch is up to date with 'origin/UHD-4.1'. > > On Wed, Aug 11, 2021 at 12:23 PM Paul Atreides <maud.dib1...@gmail.com> > wrote: > >> just built uhd systemwide from source. no pybombs environment. same issue >> rx_benchmark terminates after the first dropped sample. >> maybe the patch didn't make it? or i'm on the wrong branch? >> i ran git checkout v4.1.0.1 then the regular dance >> >> ~/uhd$ git status >> HEAD detached at v4.1.0.1 >> nothing to commit, working tree clean >> >> cd uhd/host >> mkdir build >> cd build >> cmake ../ (no errors or exclusions other than DPDK) >> make -j($nproc) >> sudo make install >> sudo ldconfig >> >> >> >> uhd/host/build/examples/./rx_samples_to_file --rate 40e6 --gain 40.0 >> --freq 915e6 --bw 36e6 --progress --file testfile.bin --continue --duration >> 20 >> >> Creating the usrp device with: ... >> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; >> UHD_4.1.0.HEAD-0-gf633b497 >> [INFO] [B200] Detected Device: B210 >> [INFO] [B200] Operating over USB 3. >> [INFO] [B200] Detecting internal GPSDO.... >> [INFO] [GPS] Found an internal GPSDO: GPSTCXO, Firmware Rev 0.929b >> [INFO] [B200] Initialize CODEC control... >> [INFO] [B200] Initialize Radio control... >> [INFO] [B200] Performing register loopback test... >> [INFO] [B200] Register loopback test passed >> [INFO] [B200] Performing register loopback test... >> [INFO] [B200] Register loopback test passed >> [INFO] [B200] Setting master clock rate selection to 'automatic'. >> [INFO] [B200] Asking for clock rate 16.000000 MHz... >> [INFO] [B200] Actually got clock rate 16.000000 MHz. >> Using Device: Single USRP: >> Device: B-Series Device >> Mboard 0: B210 >> RX Channel: 0 >> RX DSP: 0 >> RX Dboard: A >> RX Subdev: FE-RX2 >> RX Channel: 1 >> RX DSP: 1 >> RX Dboard: A >> RX Subdev: FE-RX1 >> TX Channel: 0 >> TX DSP: 0 >> TX Dboard: A >> TX Subdev: FE-TX2 >> TX Channel: 1 >> TX DSP: 1 >> TX Dboard: A >> TX Subdev: FE-TX1 >> >> Setting RX Rate: 40.000000 Msps... >> [INFO] [B200] Asking for clock rate 40.000000 MHz... >> [INFO] [B200] Actually got clock rate 40.000000 MHz. >> Actual RX Rate: 40.000000 Msps... >> >> Setting RX Freq: 915.000000 MHz... >> Setting RX LO Offset: 0.000000 MHz... >> Actual RX Freq: 915.000000 MHz... >> >> Setting RX Gain: 40.000000 dB... >> Actual RX Gain: 40.000000 dB... >> >> Setting RX Bandwidth: 36.000000 MHz... >> Actual RX Bandwidth: 36.000000 MHz... >> >> Waiting for "lo_locked": ++++++++++ locked. >> >> Press Ctrl + C to stop streaming... >> 40.0125 Msps >> 39.9994 Msps >> 39.9995 Msps >> OGot an overflow indication. Please consider the following: >> Your write medium must sustain a rate of 160.000000MB/s. >> Dropped samples will not be written to the file. >> Please modify this example for your purposes. >> This message will not appear again. >> Timeout while streaming >> >> Done! >> >> On Wed, Aug 11, 2021 at 10:42 AM Paul Atreides <maud.dib1...@gmail.com> >> wrote: >> >>> right on. thanks marcus. >>> i'm going to try a regular source build instead of pybombs and see if >>> that fixes it (he said for the 200th time in his career). >>> i just wanted 2 dev environments for gnuradio and that worked really >>> well for 3.7/3.8. if you have any suggestions i'm open to that. >>> >>> i'll keep you guys posted and thanks again for helping. >>> >>> >>> On Wed, Aug 11, 2021 at 10:36 AM Marcus D. Leech < >>> patchvonbr...@gmail.com> wrote: >>> >>>> On 08/11/2021 10:20 AM, Paul Atreides wrote: >>>> >>>> right. i tried 4.1 first, then master then rolled back to 4.0. they all >>>> did the same thing. >>>> according to micheal's post above the patch is applied to 4.0 master. >>>> the latest UHD-4.0 rev is here >>>> <https://github.com/EttusResearch/uhd/commit/0d184ff412c2710c15c0237711ab57c5033692a2> >>>> (0d184ff) >>>> this is my output >>>> UHD_4.0.0.0-193-g0d184ff4 >>>> >>>> >>>> The patch is definitely in 4.1.0.0 and 4.1.0.1 >>>> >>>> >>>> >>>> On Wed, Aug 11, 2021 at 10:07 AM Marcus D. Leech < >>>> patchvonbr...@gmail.com> wrote: >>>> >>>>> On 08/11/2021 10:03 AM, Paul Atreides wrote: >>>>> >>>>> Ok, then what else could it be? it's the identical behavior to the >>>>> report ed bug. >>>>> >>>>> I have a b210 and b205mini and both produce this issue >>>>> Both have worked fine at higher sample rates in the past. >>>>> >>>>> My setup is >>>>> ubuntu20.04 >>>>> UHD 4.0 (via pybombs) >>>>> GNURadio 3.9 (via pybombs) >>>>> >>>>> This is what Michael Dickens said: >>>>> >>>>> It was not part of the UHD 4.0.0.0 release, and has not been >>>>> backported to the UHD-3.15-LTS (or prior) branch. - MLD >>>>> >>>>> You're still running 4.0.0.0 as shown in the UHD startup header here: >>>>> >>>>> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; >>>>> UHD_4.0.0.0-193-g0d184ff4 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
