Soapy support about satdump HOT 6 CLOSED

To put it simply, SoapySDR is really, really not great. I do not want users in general using it as this always results in more bugs. Most Soapy sources have major problems that don't get fixed, Soapy itself does, and let's not talk about performance. I've supported Soapy in previous projects and used it more than once and it's been more trouble than it was worth.

Therefore, I do not want to have SoapySDR available by default and rather implement native sources per-device myself.

However, if you can build from source there is a SoapySDR source available in the code. it's just not included in official builds, and NOT recommended unless you have such as your usecase (I do not have a CaribouLite to implement support, but I'll gladly support it natively if I do at some point).

Add -DPLUGIN_SOAPY_SDR_SUPPORT=ON in the cmake command while building SatDump. As far as I'm aware it works quite well, and if it doesn't I'll gladly fix any bugs. Just not recommend, and nor will I make it easy for a random user to use it instead of the native source and complain :-)

from satdump.

SoapySDR support is being sunset in SDR++/SDR++ Server as well for the same reason.
Soapy is just a broken mess and crashes are almost never the fault of the software.

from satdump.

And worse @AlexandreRouma, as we discussed even back at FOSDEM at the GR stand, having it loaded at all will make some other APIs unstable... So it's not even an option to have it dormant without a potential downside. And that's when one driver doesn't load massive libraries eating up RAM like crazy.

from satdump.

Thanks for the response I had no idea it was buggy as hell. The few things I use it for it worked flawlessly but I'm a small use case. I will try the cmake command to enable it and test it out. I will gladly help you test it if any issues arise. Oh and unless you get a CaibouLite for free dont bother. The dev has delivered a half assed soapy driver and from what we have all gathered transmitting is broke in the firmware or driver somewhere. Somewhere it was mentioned that he was from the Ukraine which has all hell breaking loose currently. We have gotten lucky that a few talented people who backed the project have helped fixing a ton of things and you can use it to receive at least.

from satdump.

That's not exactly what's going on with the cariboulite.

The issue is it uses SMI to interface with the raspberry pi. This not only restricts it to only working on the pi4, but since it's basically never been used for anything, support in the linux kernel is horribly buggy and we're not sure at this point if it'll ever work correctly.

As for the designer/dev of the cariboulite, afaik he's in Israel and not Ukraine, but the issues are the same at the moment I guess...

I can forward his contact info to @Aang23 if he wants to ask for a dev sample. In my case I got one extremely early (basically a year before it shipped to backers) so my hardware revision is apparently more or less unusable with the production version of the code.

from satdump.

I'll close this, as in theory it's good. If there's any problem @ImDroided please comment and I'll re-open.

from satdump.