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] <mailto:[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] <mailto:[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]
<mailto:[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
<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
