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. > > >
