I should be clearer on which "generic" blocks are which. When we brought in gr-soapy, it had two ymls (for source/sink blocks) that contained logic to handle a variety of different SDRs, with gains and other features being enabled/hidden based on the selected sdr type. When I added one more SDR to the source yml, it became apparent that this wasn't maintainable. Every new SDR required a bunch of mods to lines throughout the yml for special cases. GRC yml is just not a good way to program complicated stuff.
So, I put those ymls in a "deprecated" category in GRC two new kinds blocks. There are new "generic" blocks that are really generic, i.e., there is no hardware knowledge in the yml, the gains are auto-distributed by Soapy, and some of the most common parameters are available (e.g., bandwidth, gain, agc, dc offset, iq balance, freq correction). There is a "driver" field that gets "lime" or whatever, and there are device and stream arg fields, as well as tune args and "other settings". So, users may set up a single block in a flowgraph and then go back and change the type if they want. The parameters, as in gr-osmosdr, will tend to do what is expected, but can't capture some of the nuances of the hardware. Params set for one SDR may not make sense or work right when the SDR type is changed. There are also new hardware-specific yml blocks. I didn't really want hardware-specific stuff in GR, but it seemed that (1) many users would want the simple case of a single SDR and would want to see only the most important parameters for that hardware, (2) more control could be provided where available so HackRF shows its gains broken out correctly, others show a single gain, and the actual hardware gain ranges are shown and range checked. So, the one place there is some hardware specific logic is in the SDR-specific yml files, and we can live with that. People can contribute more of them, or write their own. One thing that is admittedly going to confuse people is that the meaning of gain is not standardized, and sometimes for good reason. On a HackRF, it matters how you distribute the gain, some hardware has a separate RF amp that gives part of the gain, etc. One goal was to make sure that flowgraphs could be built/edited with no hardware or drivers present. So there is no "discovery" in the template code in the yml files. The hardware specific yml files helped with this. A future goal is to have a Soapy source widget that allows you to discover and interact with hardware at runtime, as in GQRX. The yml blocks implemented so far are what I figured were enough to get people going and get some feedback, so thanks for starting to look at this. After you try out the generic (non-deprecated) and hardware-specific blocks, let me know what you think. On Wed, Oct 13, 2021 at 9:08 PM Marcus D. Leech <[email protected]> wrote: > On 2021-10-13 8:22 p.m., Jeff Long wrote: > > Don't understand that last sentence - that doesn't sound like anything > we're doing. How do you think it should work, taking into account that > different hardware has different features, sets of gains, etc? > > I have used gr-osmosdr for many years, and my apps work just fine with a > variety of hardware without the app really "knowing" much about that > hardware, other > than that it has some basic parameters, like: > > o sample rate > o RF gain > o Optionally other gains (labelled as "IF" and "BB" in gr-osmosdr, but > they may either be a NOP or do slightly-different things on various > hardware) > o center frequency > > The user supplies a 'device string', and gr-osmosdr figures out which > driver to call. > > The end user never needs to go into GRC to enable their particular > hardware. It "just works". Now, granted there are *other* features that > gr-osmosdr exposes, > like clock-synch and other things, but on hardware that doesn't support > those things, it's just a nice quiet "NOP". That's a very useful model > that facilitates a huge > swath of applications for which the relatively "generic" model is > appropriate. > > Now, back to gr-soapy. It sounds from comments both here and on the chat > channels that there's a feeling that the "generic" source/sink blocks for > soapy should > just go away. If that's the case, then I must emphatically protest in > the strongest possible terms. If that's *NOT* the case, then I've simply > mis-understood something > either here or on the chat channel, and I apologize for the waste of > bandwidth. > > > > > > On Wed, Oct 13, 2021 at 7:43 PM Marcus D. Leech <[email protected]> > wrote: > >> On 2021-10-13 7:31 p.m., Jeff Long wrote: >> >> No, the underlying C++ is not hardware specific and there is no Soapy >> driver code in GR. We added some hardware-specific YAML files to make life >> easier. Users can add their own, too, easily enough. There are generic ones >> too at the moment, but to do things right, they have to know the >> characteristics of every possible device (e.g, gains) and they're a >> maintenance nightmare. It's pretty easy to throw one block for each sdr >> you're likely to use on the screen and disable the ones you're not using, >> if you switch between them frequently. >> >> I'm not keen on making my *users* pull .grc files into GRC to make >> changes necessitated by the hardware model.... >> >> >> >> On Wed, Oct 13, 2021 at 5:47 PM Marcus D. Leech <[email protected]> >> wrote: >> >>> On 2021-10-13 4:20 p.m., Jeff Long wrote: >>> >>> This is a LimeSDR Mini. >>> >>> I think the complaint is about the fact that auto-discovery of Lime >>> doesn't work? Not sure. >>> To me, auto-discovery is fraught with issues, and I have *NEVER* in >>> the 17 years I've been >>> using Gnu Radio relied on it. >>> >>> But more disturbing to ME is that the attached screen-cap seems to >>> indicate that the Soapy blocks >>> are all *device* specific. This seems wayyyy broken to me. It means >>> you cannot have an application that >>> is device agnostic. We have had device-agnostic apps for a LONG >>> time--ever since gr-osmosdr came onto the >>> scene and then again when SoapySDR showed up. We're going back to >>> device-specific source blocks? WHY???? >>> >>> >>> >>> On Sun, Oct 10, 2021 at 8:03 PM Aardric <[email protected]> wrote: >>> >>>> Hail, >>>> My rtl-sdr soapy source block runs with attached hardware but >>>> running the flow graph with the lime source block throws out the >>>> unpleasant response: >>>> >>>> File "./test39_lime-sdr.py", line 88, in __init__ >>>> stream_args, tune_args, settings) >>>> RuntimeError: SoapySDR::Device::make() no match >>>> >>>> > SoapySDRUtil --find="driver=lime" >>>> ###################################################### >>>> ## Soapy SDR -- the SDR abstraction library ## >>>> ###################################################### >>>> >>>> Found device 0 >>>> addr = 1d50:6108 >>>> driver = lime >>>> label = LimeSDR-USB [USB 3.0] 9081C05C4212E >>>> media = USB 3.0 >>>> module = FX3 >>>> name = LimeSDR-USB >>>> serial = 0009081C05C4212E >>>> >>>> >>>> --init-- >>>> self.soapy_limesdr_source_0 = None >>>> dev = 'driver=lime' >>>> stream_args = '' >>>> tune_args = [''] >>>> settings = [''] >>>> >>>> self.soapy_limesdr_source_0 = soapy.source(dev, "fc32", 1, >>>> "driver='lime'",stream_args, tune_args, settings) >>>> >>>> I don't know why the dev_args input of "driver='lime'" is required. >>>> >>>> git branch gnuradio 3.9-maint >>>> built with PyBOMBS (on 2021-10-09) >>>> opensuse Leap 15.2. >>>> >>>> The web page https://wiki.gnuradio.org/index.php/Soapy was informative >>>> but didn't tell me where to go next with this. Before I begin the >>>> daunting (for a non-developer) task of exploring more deeply, I thought >>>> to query this forum for obvious suggestions or known solution (or bug >>>> status). >>>> >>>> Rick >>>> >>>> >>>> >>> >> >
