search

cjcliffe / CubicSDR

Cross-Platform Software-Defined Radio Application
http://www.cubicsdr.com
GNU General Public License v2.0
2.06k stars 253 forks source link

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

Open PashPaw opened 6 years ago

PashPaw commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@cjcliffe A pull for that issue we discussed: https://github.com/pothosware/SoapySDR/pull/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 commented 6 years ago

@guruofquality Thanks, that was simple enough. :)

cjcliffe commented 6 years ago

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

mpvano commented 6 years ago

So...

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

M

PashPaw commented 6 years ago

They do support the Mac the best they can. They did respond to this thread and did help.

The solution might be just have someone to build 0.2.4 against the SoapySDR 0.6 libraries and have then distribute the binary for now.

I’ll see what I can do when I get home from a trip.

Sent from my iPhone

On May 21, 2018, at 3:06 PM, Thorby notifications@github.com wrote:

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

I think the short answer is "you don't". i.e.: use 0.2.3 and like it.

The elephant in the room seems to be that the SDRplay folks clearly don't care about the Mac: read the (totally un-addressed) screaming on their forums. They seem to think running their Windows 3.1 software in a virtual machine is the state of the art, and they are trying hard to drive their users in that direction.

The long-term answer seems to be: 'buy something else".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

SDRplay commented 6 years ago

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 commented 6 years ago

@Thorby Maybe I am being too generous but we aren’t dealing with production software for either SoapySDR or CubicSDR either.

@SDRplay Thank you for input so far. It has helped me solve my issue but it still is a problem for others.

Sent from my iPhone

On May 21, 2018, at 4:11 PM, SDRplay notifications@github.com wrote:

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 an 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 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 :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

vsonnier commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

thanks...

SDRplay commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.

g1ennp commented 6 years ago

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 commented 6 years ago

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

PashPaw commented 6 years ago

Thanks.

On Sat, May 26, 2018 at 10:27 PM, SDRplay notifications@github.com wrote:

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/649#issuecomment-392306319, or mute the thread https://github.com/notifications/unsubscribe-auth/AZOZcq6_lvnByl4kRl9QoJN1hlcxGSl0ks5t2jk6gaJpZM4Tz3JE .

PashPaw commented 6 years ago

And yes, that fixed my problem. The version of CubicSDR and the API works with my RSP2 now. Thanks so much for everyone's help--especially @cjcliffe and @SDRplay for their support.

On Mon, May 28, 2018 at 7:56 PM, Paula Ash paula.ash@gmail.com wrote:

Thanks.

On Sat, May 26, 2018 at 10:27 PM, SDRplay notifications@github.com wrote:

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

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/649#issuecomment-392306319, or mute the thread https://github.com/notifications/unsubscribe-auth/AZOZcq6_lvnByl4kRl9QoJN1hlcxGSl0ks5t2jk6gaJpZM4Tz3JE .

mpvano commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

https://github.com/pothosware/SoapySDR/blob/master/Changelog.txt

This shows 7.0 as pending, not released.

On May 29, 2018, at 10:56 AM, SDRplay notifications@github.com wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

mpvano commented 6 years ago

Also, I'm looking to see everyone in agreement about api's not everyone using mutually exclusive ones.

Version 7 is not available under the popular brew package system and hence nothing that requires it can be built using brew. I suspect the same is true for the other macOS package systems as well.

M

On May 29, 2018, at 10:56 AM, SDRplay notifications@github.com wrote:

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

SDRplay commented 6 years ago

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 commented 6 years ago

I have no idea, I'm not an expert either, but I rely on a package manager to supply dependencies to build things from source. If version 7 is not supported by brew or other package managers, I have to manually adapt and rebuild all dependencies for everything, something that's just not humanly possible.

I'm not blaming you, just reporting that the current situation is not viable here.

M

On May 29, 2018, at 11:13 AM, SDRplay notifications@github.com wrote:

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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

SDRplay commented 6 years ago

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 commented 6 years ago

Yes, but the new api is not compatible with other soapy dependencies and builds, the old one was the same version.

On May 29, 2018, at 11:26 AM, SDRplay notifications@github.com wrote:

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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

mpvano commented 6 years ago

That is to say, the old Sdrplay installer installed a version of soapy that was identical to what brew could install allowing other builds and binaries to work. The new package that he just put together is not.

M

On May 29, 2018, at 11:26 AM, SDRplay notifications@github.com wrote:

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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

guruofquality commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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