SDRPlays work well with 3.8, 3.9 and 3.10 using multiple methods mentioned by various people here. The proprietary drivers can make things a little bit of a challenge. Sure, documentation can always use improvement, and there's a big effort to work on that, all by volunteers. More volunteers who use GR in different ways could always help.
BTW, I'm sure you could find a more productive way to work on this than responding to our release announcement with a complaint. I did offer to help you figure some stuff out months ago and you never took us up on it. On Fri, Oct 1, 2021 at 10:51 AM Glen Langston <glen.i.langs...@gmail.com> wrote: > Hi Marcus and Franco and everyone, > > Thanks again for your help. > > I have to say, the online documentation is such a mess. I continue > to wander into documentation that is obsolete but appears to be current. > I thought > I’d found the perfect way, using pybombs, which suggested > the latest version, 3.9, would be installed. > > But sadly, now I’m have way backwards to installing 3.7 gnuradio, but am > afraid to stop the > build for fear of leaving a big mess behind. So I’ll try again after this > finishes. > > Concerning 3.9, there is, in my opinion, no excuse for killing SWIG for > the benefit of the future > use of pybind. These should have both been enabled in gnuradio for a > transition period. > Us who are actually trying to use gnuradio, not develop in it, do not have > the time or inclination > to play around with confusing instructions that are only half correct. > > I’ve purchased too many SDRPlays, which work fine in 3.7 and are not > supported > in 3.8, which we’ve finally struggled to get working. I continually > discover that bar is > too high for _other_ experts to support the confusing gnuradio whims of > the re-organizers. > > Because gnuradio is a collaboration, changes that break the OLD should > strongly be avoided. > Please strive to make changes that improve the code along new branches so > that are compatible > with the old code. > > Thanks! > > Sorry for the continued rant, but we’ve been struggling to upgrade to the > latest branch > for over a year now… By the time we get to 3.9 we expect that 3.10 will > be out. > > From what I heard from GRcon 21, many will leave gnuradio when everything > is broken in 4.0. > > Cheers > > Glen > > > On Oct 1, 2021, at 9:58 AM, Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > > > > On 2021-10-01 7:34 a.m., Franco VENTURI wrote: > >> If you are running GNU Radio >= 3.9, there's also the native SDRplay > module I wrote a big ago (https://github.com/fventuri/gr-sdrplay3) - you > can find the announcement to this mailing list here: > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-08/msg00001.html > >> > >> Unfortunately it won't build on GNU Radio 3.8 because of SWIG. > >> > >> Since it interfaces to the native SDRplay API (version 3.X), it doesn't > require SoapySDR or gr-osmocom; I haven't done any comparison with the > other approaches of interfacing with the SDRplay RSP devices (SoapySDR and > gr-osmocom), but if someone does, I would be really interested in hearing > their results. > >> > >> Franco > >> > >> > > My personal preference when writing applications is to make them > hardware-agnostic whenever possible, which is why I and am sure lots of > others > > prefer the gr-osmosdr or gr-soapysdr approach of abstracting the > hardware interface. This is particularly important when the flow-graphs > you've > > developed are going to be used by non-GR people, or even people who > have no particular expertise in modifying software. > > > > > > > > >
