On 08/11/2021 10:42 AM, Paul Atreides 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.
Pybombs tries to optimize things by not compiling stuff you already
have, and maybe this is the cause of the confusion?
On Wed, Aug 11, 2021 at 10:36 AM Marcus D. Leech
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 -- [email protected]
To unsubscribe send an email to [email protected]
