Dc offset register access and improved debug output

[Peter3579]

• I amended the interface to provide access to the dc-offset correction control register.
• The debug output (level 1) has become more user friendly.
• The lower LNA gain at the high bands is considered.
• And finally I started to improve the README.md to include an interface description. This is far from complete and hopefully correct so far.

The updated gain distribution algorithm from the Jul 25, 2024 commit has been removed. That needs further discussion on what might be optimal. There is a tradeoff to be made between intermodulation and low noise figure. I'd assume that a low noise figure is less important in the "AM"-modes below 50 MHz. Therefore the algorithm could depend on RX frequency.

[ericek111]

I have no idea why I'm not getting notifications for PRs on my own projects, that's ridiculous.

Peter, I'd be happy to make you a maintainer, as I'm quite busy these days and some of these changes look sound. One needs to be quite careful not to make the algorithm even worse. There are multiple separate (and quite extensive) changes in this PR. I mostly care about compatibility with SDRPlusPlus and SoapyMiri.

[Peter3579]

Erik,

Thanks for your trust. I do not want to force any changes on your repository. And I acknowledge that you depend on this repository for using it with SDRPlusPlus and SoapyMiri for your purposes (on probably multiple platforms). So I'm going to break my PR into smaller pieces and separate out the update of the gain reading, so we can both review that change. The other modifications should not change the original behavior (besides the in my view better human readable debug messages) and the addition of a new interface function to get raw control on the DC-offset register settings on the MSi001. But maybe that new interface is not ideal - I had hoped for a discussion.

As I currently don't use SDRPlusPlus and typically don't use the radio via Soapy, it would be hard for me to spot any regressions. Even if I would use both regularly, your use-case and my use-case are probably quite different. So that would not guarantee anything. Furthermore I'm very ignorant to Windows, Mac, and Android since I'm only using Linux.

Another issue is the naming and version numbering of the library. I don't see a clear strategy.

As indicated in the Debian related PR, the major version number might be 5 to avoid conflicts with f4exb/libmirisdr-4. The underlying issue is, that both libraries (yours and Edouard's) finally install as /usr/lib/libmirisdr.so on a Linux system (actually as /usr/lib/libmirisdr.so.4.0git IIRC) and use the same inlcude file "path/names". (To make things worse, there is also the original Osmocom libmiri around.)

On the other hand, you started already with version tags, latest is v1.1.2, which (ideally?) should install the library as
/usr/lib/libmirisdr5.so.1.1.2 (note the 5 appended to libmirisdr). But that would require changes to the SDRPlusPlus and the SoapyMiri build scripts. Or at least a change to your build script invocation is necessary to specify the to be used libmirisdr5 and the associated include files /usr/include/mirisdr5/mirisdr.h, /usr/include/mirisdr5/mirisdr_export.h.

I don't know how the library naming and versioning issue is handled on the other platforms.

TL;DR
I'm very happy to support. But there are a few fundamental decisions to be made (or communicated if already taken) which are yours in the first place.

Best regards,
Peter