4.0: soapy: initial port incl. rtlsdr, hackrf

[mormj]

Description

Initial port of the soapy module to GR 4.0 This includes wrappers for rtlsdr and hackrf, which are done as hier blocks rather than grc differences

There is still missing functionality, namely in the message ports. Still need to figure out whether to inherit parameters from the base block, or have a separate cmd port as in GR 3.x

Checklist

• [x] I have read the CONTRIBUTING document.
• [x] I have squashed my commits to have one significant change per commit.
• [x] I have signed my commits before making this PR
• [x] My code follows the code style of this project. See GREP1.md.
• [ ] I have updated the documentation where necessary.
• [ ] I have added tests to cover my changes, and all previous tests pass.

[willcode]

We've got to find a way that there are no hardware-specific compile-time files. That defeats the runtime modularity.

[mormj]

I'm torn on this

1. Yes, the compiled files include hardware specific info (ranges, parameters)
2. They are not hard linking to any hardware specific drivers

For instance, here is the wrapping done of rtlsdr similar to what was done in the GRC files for 3.9

{
    // Ports defined in yml

    d_soapy_source_block = soapy::source<T>::make({ "driver=rtlsdr", 1, { "" }, { "" } });

    d_soapy_source_block->set_sample_rate(0, args.samp_rate);
    d_soapy_source_block->set_gain_mode(0, args.agc);
    d_soapy_source_block->set_frequency(0, args.center_freq);
    d_soapy_source_block->set_frequency_correction(0, args.freq_correction);
    d_soapy_source_block->set_gain(0, "TUNER", args.gain);

    this->connect(d_soapy_source_block, 0, this->base(), 0);
}

All we provide is a wrapping from the top level yaml parameters (e.g. center_freq) to the channel that will be used. I think it is super helpful to have an rtlsdr block as opposed to inputting a bunch of strings somewhere. But can the above bit of code be mapped some other way that is not compiled? I don't have a good way atm without creating a new config file

[willcode]

In the 3.10 architecture, new hardware can be added by dropping a grc yml somewhere. Everything else is handled symbolically via the soapysdr API. There is admittedly a little Python logic in the yml, but that file can be maintained by the soapy driver author pretty easily and dropped in at runtime. Also, I'm hoping that we get a soapy Qt block that can discover hardware attributes at runtime, allowing us to get rid of even the hardware-specific yml files. If there's C++ involved, then there's a build process, versioning, etc. involved in installing or updating a new soapy driver.

[mormj]

Gotcha - from a module developer's point of view, that makes perfect sense.

I had started with the grc files approach, but there's more I want to capture -like the ability to do the parameter setting

x = soapy.rtlsdr(...)
x.set_freq()

In this workflow at a minimum is the new yaml file that would need to be maintained, but perhaps that yaml file could have a soapy section to map things and do the logic that is currently done in the grc yaml

will need some thought though, because there is an overlay of multiple higher level blocks to 1 base block, and things just aren't set up that way as of now

[willcode]

Would it be equivalent to have

x = soapy.source("rtlsdr", ....)
x.set("freq", ...)

or is there a reason to have the hard-coded setter?

[mormj]

No reason in particular other than habit/consistency with other blocks

[mormj]

I think to get there with the current codegen setup will require a bit of thought. Converting to draft, will revisit this later unless @willcode or someone else has a good solution.

[mormj]

Closing in favor of #6136