New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDRplay RSP2 Does Not Show Up As A Local Device In 0.2.4 On macOS 10.12 #649

Open
PashPaw opened this Issue May 6, 2018 · 50 comments

Comments

Projects
None yet
9 participants
@PashPaw

PashPaw commented May 6, 2018

After I upgraded CubicSDR from 0.2.3 to 0.2.4 on my Mac, the RSP2 does not show up in the devices menu as a local device after refreshing the device list. SoapySDR sees the device still and I can run it as a network SDR still.

@righthalfplane

This comment has been minimized.

righthalfplane commented May 6, 2018

I have the same problem. The modules inside CubicSDR 0.2.4 are not compatible with those in /usr/local/lib. I was able to get CubicSDR 0.2.4 to work by renaming the modules folder inside of CubicSDR 0.2.4 - that way it uses the good modules in /usr/local/lib -

cd /Applications/CubicSDR.app/Contents/MacOS
sudo mv modules modulessave
CubicSDR

You need to reload the device that you want use after CubicSDR starts.

Dale.

@cjcliffe cjcliffe self-assigned this May 7, 2018

@cjcliffe

This comment has been minimized.

Owner

cjcliffe commented May 7, 2018

@PashPaw @righthalfplane I can't seem to reproduce the issue here; make sure you've got the latest RSP driver (should be 2.11.2 on 15th Nov 2017) from https://www.sdrplay.com/downloads/ since CubicSDR is compiled using that version.

@vsonnier

This comment has been minimized.

Collaborator

vsonnier commented May 9, 2018

Given @righthalfplane last try I would guess it is the same issue on #644 and #588 remaining problem: Something like incompatible versions loading, where modules are first searched in /usr/local/lib then only afterwards in CubicSDR/modules.
Problem is, CubicSDR SoapySDR may expect v0.7 API modules (for instance), but got v0.6 ones (or the contrary).
I have the same problems on Windows when the current PothosSDR distribution has different modules versions as the prepackaged modules of CubicSDR.

Indeed depending on how CubicSDR was compiled, it could serach in other places than its own modules directory, ex in SOAPY_SDR_ROOT(env)/lib/SoapySDR/modules0.6/.., maybe also the LD_LIBRARY_PATH ?

Normally building Cubic with -DBUNDLE_INSTALLER=1 -DBUNDLE_SOAPY_MODS=1 -DBUNDLED_MODS_ONLY=1 would make it load modules exclusively from its own modules dir, but maybe it was not built that way as we can see with @righthalfplane experiment.

@PashPaw

This comment has been minimized.

PashPaw commented May 9, 2018

I do have the most recent version of the SDRplay drivers installed. From what it sounds like, @vsonnier might be on the right track here. I'll see what happens when I build it from source.

@righthalfplane

This comment has been minimized.

righthalfplane commented May 9, 2018

I ,also, got CubicSDR 0.2.4 to work by making no changes in CubicSDR 0.2.4, by going to /usr/local/lib/SoapySDR and renaming the folder modules0.7

cd /usr/local/lib/SoapySDR
sudo mv modules0.7 modules0.7-save

CubicSDR 0.2.4 then worked with my SDRPlay RSP1, SDRPlay RSP2, HackerRF one and RTL2838 stick. My NetSDR stopped working because my replacement routine for discover_netsdr has not been include in CubicSDR 0.2.4.

The folder modules0.7 was still around from my local build of CubicSDR 0.2.3 that put in my discover_netsdr module - so that my RFSpace NetSDR would work.

@vsonnier

This comment has been minimized.

Collaborator

vsonnier commented May 10, 2018

Thanks @righthalfplane for your tests. So CubicSDR really tries to load from both /usr/local/lib/SoapySDR/modules0.7 and its own modules directory.
It seems the problem arises when the user has already compiled SoapySDR modules independently, which may create loading clashes if both modules don't have the strictly identical API/ABI level.

@righthalfplane For both your successful attemps (rename CubicSDR modules to hide them, or else rename /usr/local/lib.. ones to hide them) what are the CubicSDR starting console log ?

Cubic normally dumps the paths of the found modules together with their API version so it could be interesting.

@righthalfplane

This comment has been minimized.

righthalfplane commented May 10, 2018

It shows a bunch of error messages -

[ERROR] SoapySDR::ConverterRegistry(F32, F32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S32, S32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S16, S16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S8, S8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(F32, S16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S16, F32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(F32, U16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(U16, F32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(F32, S8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S8, F32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(F32, U8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(U8, F32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S16, U16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(U16, S16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S16, S8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S8, S16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S16, U8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(U8, S16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(U16, S8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S8, U16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S8, U8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(U8, S8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CF32, CF32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS32, CS32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS16, CS16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS8, CS8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CF32, CS16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS16, CF32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CF32, CU16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CU16, CF32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CF32, CS8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS8, CF32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CF32, CU8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CU8, CF32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS16, CU16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CU16, CS16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS16, CS8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS8, CS16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS16, CU8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CU8, CS16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CU16, CS8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS8, CU16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CS8, CU8, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(CU8, CS8, 0) duplicate registration
Loading bundled SoapySDR module /Applications/CubicSDR.app/Contents/MacOS/modules//libuhdSupport.so..
Available factories...airspy, audio, bladerf, hackrf, lime, redpitaya, remote, rfspace, rtlsdr, sdrplay, uhd
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.7/libHackRFSupport.so)
duplicate entry for hackrf (/Applications/CubicSDR.app/Contents/MacOS/modules//libHackRFSupport.so)
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.7/librfspaceSupport.so)
duplicate entry for rfspace (/Applications/CubicSDR.app/Contents/MacOS/modules//librfspaceSupport.so)
Loaded font 'Bitstream Vera Sans Mono' from '/Applications/CubicSDR.app/Contents/Resources/fonts/vera_sans_mono12_0.png', parsed 255 characters.
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.7/librtlsdrSupport.so)
duplicate entry for rtlsdr (/Applications/CubicSDR.app/Contents/MacOS/modules//librtlsdrSupport.so)
Loaded font 'Bitstream Vera Sans Mono' from '/Applications/CubicSDR.app/Contents/Resources/fonts/vera_sans_mono16_0.png', parsed 255 characters.
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.7/libsdrPlaySupport.so)
duplicate entry for sdrplay (/Applications/CubicSDR.app/Contents/MacOS/modules//libsdrPlaySupport.so)
Loaded font 'Bitstream Vera Sans Mono' from '/Applications/CubicSDR.app/Contents/Resources/fonts/vera_sans_mono18_0.png', parsed 255 characters.
Loaded font 'Bitstream Vera Sans Mono' from '/Applications/CubicSDR.app/Contents/Resources/fonts/vera_sans_mono24_0.png', parsed 255 characters.
Loaded font 'Bitstream Vera Sans Mono' from '/Applications/CubicSDR.app/Contents/Resources/fonts/vera_sans_mono27_0.png', parsed 255 characters.
Found Rafael Micro R820T tuner
[INFO] [UHD] Mac OS; Clang version 8.0.0 (clang-800.0.42.1); Boost_105900; UHD_3.11.0.0-0-unknown

@PashPaw

This comment has been minimized.

PashPaw commented May 10, 2018

@vsonnier I think you may be right. So, when I ran SoapySDRUtil --info, this was what it said it was:

SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.6.1-g285e72aa
API Version: v0.6.0
ABI Version: v0.6
Install root: /usr/local
Search path: /usr/local/lib/SoapySDR/modules0.6
Module found: /usr/local/lib/SoapySDR/modules0.6/libremoteSupport.so
Module found: /usr/local/lib/SoapySDR/modules0.6/libsdrPlaySupport.so
Loading modules... done
Available factories...null, remote, sdrplay,

When I built 0.2.4 from source yesterday, I had no problems with it seeing the RSP2. And unlike @righthalfplane, I don't see those errors after recompiling it.

@righthalfplane

This comment has been minimized.

righthalfplane commented May 10, 2018

When you do a local build, you need to be sure to install the SDRplay package before the build. I had the install of SDRplay_RSP_API-MacOSX-2.11.2.pkg switch from modules0.6 to modules0.7 - so I had to do the build all over again.

@guruofquality

This comment has been minimized.

guruofquality commented May 11, 2018

Few comments here:

Theres a guide, though not completed. It has a section about the multiple installs: https://github.com/pothosware/SoapySDR/wiki/ConfigGuide#avoid-simultaneous-installs

Its something that happens every so often, but basically

  • SoapySDR from an official package, some modules from an official package, and other modules from source in /usr/local should generally work. You definitely want to make sure that you dont install modules from source that are also installed in the package manager

  • Otherwise, if SoapySDR is installed from source, basically everything also needs to be module wise and application wise (think of the dependency tree) or there is going to be issues.

That said, cubicsdr providing bundled soapysdr and modules while also searching standard install paths may be an issue. Thats another situation where you could have duplicates. And I'm not sure whats right, loading more carefully preferring only one of the modules of the same name, or expending the /usr/local or /usr module to be removed, or to not search outside of the bundle at all. Where does this bundled version of CubicSDR search by default?

For anyone running into this multiple modules thing, it would be good to get a complete list of all of the libSoapySDR.so.* files on the system, all full paths to the bin/SoapySDRUtils on the system, a list of all of the installed modules, and SoapySDRUtil --info outputs from each individual SoapySDRUtil found on the system to understand better whats going on.

@cjcliffe

This comment has been minimized.

Owner

cjcliffe commented May 11, 2018

@guruofquality I've made a PR to SoapySDR that fixes the issue; the enumerate() call was forcing a call to loadModules() that was out of my control -- the bundled version wasn't supposed to be looking around in the system folders :)

@cjcliffe

This comment has been minimized.

Owner

cjcliffe commented May 11, 2018

@PashPaw @righthalfplane @8xk40367 I've made a bundle of CubicSDR using the patch I've submitted to SoapySDR -- please let me know if this build works any better for detecting SDRPlay as it should only attempt to load the included 0.7 module:

CubicSDR-0.2.4-Darwin.dmg-patch1.zip

@PashPaw

This comment has been minimized.

PashPaw commented May 11, 2018

@cjcliffe @righthalfplan Thanks for your hard work so far, but...

It doesn't see the RSP2 still with a prebuilt binary. I even copied the library over from /usr/include/SoapySDR/ into the app bundle. Nothing. It did see my RTL-SDR though, so there's that.

@righthalfplane

This comment has been minimized.

righthalfplane commented May 11, 2018

Everything seems to work Ok on 10.13.4 except I get ERROR messages if the 'libSoapySDR.0.7*' files are in /usr/local/lib

[ERROR] SoapySDR::ConverterRegistry(F32, F32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S32, S32, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S16, S16, 0) duplicate registration
[ERROR] SoapySDR::ConverterRegistry(S8, S8, 0) duplicate registration
...

If I move the 'libSoapySDR.0.7*' files out of /usr/local/lib everything still works on 10.13.4 and the ERROR messages go away.

On 10.12.6, I get the ERROR messages if the 'libSoapySDR.0.7*' files are in /usr/local/lib, but everything seems to work Ok. If I move the 'libSoapySDR.0.7*' files from /usr/local/lib, the ERROR messages go away, but CubicSDR no longer finds the SDRplay RSP2 device.

Very Strange ?

The modules in /usr/local/lib/SoapySDR/modules0.7 are no longer generating warning messages.

@guruofquality

This comment has been minimized.

guruofquality commented May 11, 2018

The duplicate registration comes from when the libSoapySDR in the cubic bundle loads modules build outside of the bundle, which in turn load the /usr/local/lib/libSoapySDR.so.* which is yet another copy of the library, and then his static symbols get loaded and loads another copy of the converters. That actually used to happen with the null module, but I moved it out of static initialization, I probably need to do the same with the converters. Anyway, i guess you can see how loading stuff build outside of the bundle could be an issue. If its all the same ABI, its probably OK though.

@SDRplay

This comment has been minimized.

SDRplay commented May 11, 2018

No, just rebuild SoapySDRPlay - we just bundle it in with the API to help people who don't want to (or know how to) build it.

@guruofquality

This comment has been minimized.

guruofquality commented May 11, 2018

@cjcliffe A pull for that issue we discussed: pothosware/SoapySDR#163 Letting the CI take care of it and I think that lets cubic do everything manually and removes the automatic load when doing manual loads. You can still call loadModules() manually if desired.

I have the same problems on Windows when the current PothosSDR distribution has different modules versions as the prepackaged modules of CubicSDR.

@vsonnier on that topic, the PothosSDR installer sets an environment variable SOAPY_SDR_ROOT so it can find its resources. The problem is any other copy of SoapySDR on the system picks this up. The funny thing is, I dont think we need the environment variable, SoapySDR can search relative to its dll. So I think I can remove SOAPY_SDR_ROOT from the installer. In the meantime if you remove it, I think it will also fix the problem.

@vsonnier

This comment has been minimized.

Collaborator

vsonnier commented May 13, 2018

@guruofquality Thanks, that was simple enough. :)

@cjcliffe

This comment has been minimized.

Owner

cjcliffe commented May 14, 2018

@guruofquality PR looks good thanks; that should take care of the bundle vs. local module issues for us.

@mpvano

This comment has been minimized.

mpvano commented May 21, 2018

So...

How exactly does someone experiencing this fix it without rebuilding everything from source?

M

@PashPaw

This comment has been minimized.

PashPaw commented May 21, 2018

@SDRplay

This comment has been minimized.

SDRplay commented May 21, 2018

We do the best we can, when we can. It won't be good enough for everyone, but then it's hard to please everyone all the time (if not impossible). If I need to rebuild SoapySDR/SoapySDRPlay and upissue the API install, I can do that. Please remember there is a known issue that the refresh button in the CubicSDR device selection window will need to be used if the RSP has just been connected - that's a known API issue, not a CubicSDR or SoapySDR issue before I get pounced on again :-)

@PashPaw

This comment has been minimized.

PashPaw commented May 22, 2018

@vsonnier

This comment has been minimized.

Collaborator

vsonnier commented May 22, 2018

For now, there are several workarounds:
@righthalfplane has found one:

,also, got CubicSDR 0.2.4 to work by making no changes in CubicSDR 0.2.4, by going to /usr/local/lib/SoapySDR and renaming the folder modules0.7
cd /usr/local/lib/SoapySDR
sudo mv modules0.7 modules0.7-save
CubicSDR 0.2.4 then worked with my SDRPlay RSP1, SDRPlay RSP2, HackerRF one and RTL2838 stick.

In addition, @cjcliffe has generated a patched version, see comments above.

@mpvano

This comment has been minimized.

mpvano commented May 22, 2018

I had no luck with the patched version and breaking all my other SDR software by disabling the existing SoapySDR modules is a clumsy option.

I was actually hoping to try to understand the problem enough to find a better fix.

Is there a way to patch CubicSDR's Info.plist to affect the search enough to make it fail?

when Gqrx had a slightly similar problem, I was able to fix it by controlling the environment this way:


  <key>LSEnvironment</key>
  <dict>
        <key>SOAPY_SDR_ROOT</key>
        <string>/usr/local</string>
  </dict>


I wonder if setting that to a key that would deliberately fail is an option? The trouble is, I don't fully understand what the fixes are trying to do...

thanks,

M

@SDRplay

This comment has been minimized.

SDRplay commented May 23, 2018

I've just got back, with a day of flight delays :-( , from the Dayton Hamvention, so I can rebuild the API installer with the latest SoapySDR/SoapySDRPlay if that helps? I guess I should also make sure the CubicSDR link is also pointing to the latest. I'll get those done and tested. I'll let you know when it's pushed to our website.

@mpvano

This comment has been minimized.

mpvano commented May 23, 2018

thanks...

@SDRplay

This comment has been minimized.

SDRplay commented May 24, 2018

https://www.sdrplay.com/software/SDRplay_RSP_API-MacOSX-2.11.3.pkg

I've been testing this with the CubicSDR 0.2.4 dmg and it's working well. Please test and let me know. If it's ok, I'll release it.

Thanks for your patience.

@righthalfplane

This comment has been minimized.

righthalfplane commented May 27, 2018

SDRplay_RSP_API-MacOSX-2.11.3.pkg works well on MacOS sierra with CubicSDR 0.2.3 and CubicSDR 0.2.4 with my RSP1 and RSP2

@SDRplay

This comment has been minimized.

SDRplay commented May 27, 2018

ok, let's close this down and I'll release it. I'll update the CubicSDR link to point to 0.2.4 as well.

@glennatpnl

This comment has been minimized.

glennatpnl commented May 27, 2018

I've also tested and confirm it's working OK:
RSP2 on MAC OS X 10.11.6 | API 2.11.3 | CubicSDR 0.2.4

@SDRplay

This comment has been minimized.

SDRplay commented May 27, 2018

Links all updated on the website - thanks for everyone's patience and testing.

@PashPaw

This comment has been minimized.

PashPaw commented May 29, 2018

@PashPaw

This comment has been minimized.

PashPaw commented May 29, 2018

@mpvano

This comment has been minimized.

mpvano commented May 29, 2018

Sorry it's too late to help, but it works fine here as well...

thanks to everyone for all their (sometimes unappreciated) hard work...

M

@mpvano

This comment has been minimized.

mpvano commented May 29, 2018

One additional note, however...

It breaks all the other software I need to use that uses the SDRPlay hardware including GQRX and soapy_power (used by qspectrum).

When I looked this up last week, I'm sure that this version of soapy is not yet actually released. The latest production version seems to be 6.1.

Why is CubicSDR requiring an unreleased and incompatible version to operate?

Sorry, I've reverted everything until this mess gets untangled.

M

@SDRplay

This comment has been minimized.

SDRplay commented May 29, 2018

Release numbers is a whole topic by itself!

Where are you looking to see production or stable versions, etc.?

I'm not pointing to a specific version, I'm just building whatever the master branch is.

@mpvano

This comment has been minimized.

mpvano commented May 29, 2018

@mpvano

This comment has been minimized.

mpvano commented May 29, 2018

@SDRplay

This comment has been minimized.

SDRplay commented May 29, 2018

Well every man and his dog is going to build from master, so if 0.7 isn't released then maybe it should be in a separate branch and then merged back to master when released?

I'm not really an expert on github, I know enough to use it, so I don't know what the protocol on releases is. Is there one?

@mpvano

This comment has been minimized.

mpvano commented May 29, 2018

@SDRplay

This comment has been minimized.

SDRplay commented May 29, 2018

you still have to install the API though right? brew doesn't do that - the API installs these versions of SoapySDR - or have I misunderstood the flow?

@mpvano

This comment has been minimized.

mpvano commented May 29, 2018

@mpvano

This comment has been minimized.

mpvano commented May 29, 2018

@guruofquality

This comment has been minimized.

guruofquality commented May 30, 2018

I know its unreleased. Truthfully I wanted to update the cmake stuff before tagging. In the meantime brew install --head soapysdr should take care of things.

@dStruct

This comment has been minimized.

dStruct commented Aug 3, 2018

I can confirm this is still an issue, on both Ubuntu 17.10 and 18.04 LTS. Both installs are for the most part unmodified and using apt packages. I did the same process on both, by downloading the latest SDRplay driver v2.13 from sdrplay.com and then downloading the 0.2.4 AppImage bundle. When this failed to show my device which I plugged in after installing the driver, I then attempted the apt repo package on 18.04 to no avail. Considering repo's usually lag behind that was not a shock though.

Is there a dep I'm unaware of? In an effort to get things working I apt installed/removed a number of packages that seemed related including soapysdr0.6-module-mirisdr which didn't do a thing.

Does anyone know for a fact if 0.2.3 also has this issue?

@dStruct

This comment has been minimized.

dStruct commented Aug 3, 2018

Ok finally got it resolved, and I found a few issues. First SoapySDRUtil --info was not able to find the v2.10 driver, since I have v2.13 (latest) installed, so I triaged this with a simple symlink

ln -s /usr/local/lib/libmirsdrapi-rsp.so.2.13 /usr/local/lib/libmirsdrapi-rsp.so.2.10

This fixed PothosUtil and PothosFlow, and I finally had a usable device available, but did not resolve the Cubic issues.

Then I tried my best to fix the AppImage however no matter what I tried I could not seem to mount the AppImage file read write and add the v2.13 driver directly. So running the AppImage ./CubicSDR-0.2.4-x86_64.AppImage I would get the following in red.

Loading modules... [ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.6/libsdrPlaySupport.so) dlopen() failed: libmirsdrapi-rsp.so.2.11: cannot open shared object file: No such file or directory done Available factories...null,

So I gave up on the AppImage and did an sudo apt install CubicSDR and ran that and it found the driver and everything is now working perfectly.

Another thing I should point out is I also blacklisted the msi2500 kernel module by creating /etc/modprobe.d/msi2500.conf and adding the line "blacklist msi2500", followed by unplugging the usb cable, doing a sudo rmmod msi2500, and plugging my SDRplay cable back in.

cjcliffe, I appreciate the software, thank you!

@cjcliffe

This comment has been minimized.

Owner

cjcliffe commented Aug 3, 2018

@guruofquality Looking back I see that I'd updated my build scripts and dropped the maint tag for reasons I can't remember -- I think it was loadModule related; so everything was built against 0.7 master at the moment.

I'm guessing I should still be using the maint branch for proper compatibility? Can switch that back for 0.2.5 build unless there's a reason to keep it at master branch.

@mpvano

This comment has been minimized.

mpvano commented Aug 4, 2018

I'd like to see that, but people using the latest driver package that SDRPlay just put together so people can use 0.2.4 will have to downgrade their drivers to use 0.2.5.

Of course the new SDRPlay driver breaks all other SDR software EXCEPT CubicSDR 0.2.4 anyway, so I had to uninstall it to continue using GQRX's binaries and my existing SoapyPower builds - which meant I couldn't use 0.2.4 at all.

M

@cjcliffe

This comment has been minimized.

Owner

cjcliffe commented Aug 18, 2018

@mpvano aye I agree -- going to go with what's out already possibly switch it over to maint again once 0.7 is current.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment