Re: Releases v3.8.4.0 and v3.9.3.0

[Glen Langston]

Hi Jeff,

Thanks again for everyone’s continued efforts.

We did get 3.8 working for several dongles, particularly the Airspy, air spy
mini, rtlsdr and limesdrs.   So that is great.

Unfortunately the SDRPlay folks did not have time to get the SDRplay
included in the 3.8 revision we got running and I’ve been struggling with that.

I’d been able to use apt-get and various build steps working before.
What I find difficult is that each revision has a new preferred build method.
I’d not needed PyBombs before now.

I’m trying to follow the PyBombs instructions but it is
failing at the UHD step, which I don’t want anyway. So at the moment
I’m googling how to not install UHD on a raspberry pi, so that I can go
to the next step.

A fairly simple question.   Is PyBombs required for 3.9 and 3.10
or could I go back to git clone and the build steps?

Thanks

Glen


, except that we could not get 
> On Oct 1, 2021, at 11:35 AM, Jeff Long <willcode4@gmail.com> wrote:
> 
> 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.langston@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 <patchvonbraun@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.
> > 
> > 
> > 
> 
>