SDRplay RSP1A Does Not Show Up As A Local Device In 0.2.5 Windows 10

[MarcKaufman]

I just built CubicSDR on Windows 10 using source + 0.2.5 release binaries, and built the sdrPlaySupport.dll. The dll loads on launch, as does the mir_sdr_api.dll. However, I don't see the RSP1A as an available device. SDRUno runs properly. (Apologies if this isn't the correct forum for this)

[vsonnier]

Hi @MarcKaufman, please run CubicSDR in the command line that way: CubicSDR.exe > output.log and attach the output.log here.

[MarcKaufman]

Log file attached. output.log

[vsonnier]

Thank you. Although the sdrPlaySupport.dll is there, the loading of modules itself Available factories...airspy, airspyhf, audio, bladerf, hackrf, lime, null, redpitaya, remote, rtlsdr, uhd shows that the plugin is not loaded. From that, no suprise that the device itself is not loaded.

Did you follow the guide: https://github.com/cjcliffe/CubicSDR/wiki/Build-Windows to build and deploy the SoapySDRPlay module. In particular, the module must be compiled against v2.13 API, and the API driver C:\Program Files\SDRplay\API\x64\mir_sdr_api.dll must be copied in the CubicSDR directory.

[MarcKaufman]

Yes to both. If I run CubicSDR from MSVC I can see tlog)hat the mir_sdr_api dll is loaded. CubicSDR_output.log

[vsonnier]

Hello @MarcKaufman, well it is not any clearer, really. I own a RSP2 and runs Windows 10 x64 but indeed I've not tried the latest changes of master, maybe a bug was introduced. Wild guess: the Hw/Ids of the device are no longer recognized properly with the recent changes on Windows maybe because of this: https://github.com/pothosware/SoapySDRPlay/pull/47 and later commits.

You should add traces to https://github.com/pothosware/SoapySDRPlay/blob/master/Registration.cpp in the SoapySDRPlay module to see if or how your device is actually recognized.

[vsonnier]

I've recompiled the module from the master, linking to the latest SoapySDR API v0.80, and it works for me on RSP2 but I had to copy the SaopySDR.dll into CubicSDR dir to make it work. Indeed the APIs versions of both Saopy and modules must be aligned, else they won't load.

So you have to recompile SoapySDR according to the guide, but don't forget to copy the generated SoapySDR.dll into the CubicSDR directory also.

Edit : I updated the Windows guide to add this missing step.

[vsonnier]

@MarcKaufman Any news ?

[MarcKaufman]

No news. I've temporarily moved on. I was trying to load a Debug version of CubicSDR, but I'm told that is not supported. Since I'm using MSVC 2019 I had to recompile everything to use the current toolkit. I'll try to get back to this next week.

[MarcKaufman]

In progress. First: sdr/SDREnumerator.cpp line 113 needs to be Windows aware: std::vector localMods = SoapySDR::listModules(exePath.GetPath().ToStdString() +

ifdef _MSC_VER

            "\\\\modules"

else

            "/modules"

endif

-note no trailing delimiter. SoapySDR has similar problems in Module.cpp listSearchPaths() and listModules(path)

[MarcKaufman]

It appears that this was a false bug. All is working now with no code changes (ignore suggested change). The problem seemed to be finding the right place to put the modules directory.

[vsonnier]

Great ! Hva fun with CubicSDR, @MarcKaufman !