CubicSDR 0.2.5 performs much poor than CubicSDR 0.2.3 with the LimeSDR Mini

[righthalfplane]

On Ubuntu 18.04, CubicSDR 0.2.5 could only do 4 MSPS with a LimeSDR Mini where CubicSDR 0.2.3 was able to run the LimeSDR Mini at its maximum 40 MSPS. I made a video showing the problem -

https://youtu.be/85RKiUUFYm0

[righthalfplane]

The problem effects CubicSDR 0.2.4 also. It has the problem on every system that I have - MacOS, Windows 7, Windows 10, Ubuntu 18.04, and Raspbian (PI 4). The problem is not in the SoapySDR as SdrGlut uses the SoapySDR and does not have the problem.

[Dantali0n]

I remember we changed some things around starting and stopping device streams when changing sample rate which were specific to Lime devices, could be related.

[vsonnier]

I remember we changed some things around starting and stopping device streams when changing sample rate which were specific to Lime devices, could be related.

Indeed, please have a look at this: #718

Hi @righthalfplane, I hope by "0.25" you indeed means the current master because there is no way someone should consider such an old version (me in particular, who has close to zero time nowaydays...), especially here because #718 brought enhancements after 0.25 release on the Lime side.

[righthalfplane]

I was using the pre-build and system supplied versions of Cubic0.2.5. I build CubicSDR 0.2.6a from the git source (I also had to build a special version of wxWidgets to use with it - that is why I did not immediately use the git source) and it works at the 40 MSPS. It, however, does seem to have any way to set the bandwidth - it seems to be set to a bandwidth to 5 MHZ, which only shows the center of the 40 MHZ range. It runs on Ubuntu 18.04 but it has problems on MacOS Sierra.

[vsonnier]

and it works at the 40 MSPS. It, however, does seem to have any way to set the bandwidth - it seems to be set to a bandwidth to 5 MHZ,

Which means that the device is not obeying the 40Msps Sample rate request in Cubic... If you compiled a master version of SoapySDR and everything else is up-to-date, ...etc. then an issue should be opened there: https://github.com/myriadrf/LimeSuite because Cubic is definitly capable of more than 5Msps.

Edit: or maybe you should NOT upgrade: pothosware/PothosSDR#70. Either way, please open an issue at LimeSuite.

[righthalfplane]

Most of the SDRs have internal filters that you can set the bandwidth for independent of the sample rate. With my limeSDR mini using SDR# or SdrGlut, I can run a 40 MSPS and set the bandwidth of the internal filters to 5 MHZ, 10 MHZ, ... With CubicSDR the internal filters are stuck at 5MHZ with no way to change them. So the full 40 MHZ range appears and it is running at 40 MSPS, but all signals more than 5 MHZ from the center frequency are greatly muted by the internal filters. The SoapySDR routine "SoapySDRDevice_setBandwidth" permits you to adjust the internal filters - I can find no call to SoapySDRDevice_setBandwidth in CubicSDR.

[vsonnier]

Indeed, CubicSDR only usesetSampleRate to be the the only setting that controls the number of I/Q samples/s, as it should be. The setBandwidth is an implementation detail that most SDR devices don't need (it works on RTL-SDR, RSP, AdamPLUTO...etc... an probably all) and Cubic have no use of setBandwidth at all.

If the Lime Soapy module applies a band filter by default instead of giving a full requested sample rate unfiltered , this is the problem of the module or driver not Cubic.

Even if Cubic start using setBandwidth all over the place, there is no garantee that most Soapy modules implement it correctly, so the Lime Soapy should rather behave like the crowd here.

In any case, that deserves a question here: https://github.com/myriadrf/LimeSuite.

[righthalfplane]

On MacOS High Sierra with the LimeSDR mini, CubicSDR 0.2.6a comes up at a very small sample rate and you can tune one station at a time, but when you try to set the sample rate to some reasonable value it hangs. CubicSDR works OK with a RTL stick and SDRPlay. SdrGlut, which also uses SoapySDR, works just fine with the LimeSDR mini on High Sierra.

I looked with the debugger - after the reset of the sample rate CubicSDR hangs on the call to readStream - it never returns. If you just stop and start the device - it also hangs.

[Dantali0n]

Naturally we want to use Soapy as a transparent layer that exposes SDR devices in such a way that the necessary function calls we make to the devices are universal. And as of such any behavior that is not consistent across devices should be reported to the maintainer of the Soapy device library. In this case https://github.com/myriadrf/LimeSuite.

However, it has become clear to me that this transparency is less transparent than we would like it to be(currently 7 device specific issues open). I propose that we write a small wrapping interface that can perform some device specifics upon events such as; starting, stopping. changing sample rate and changing gain. Subsequently, we can track these specifics with the maintainers upstream and refer to the specific issue in our code.

This is less than ideal but it would at least prevent users from not being able to use some specific devices until the problems are resolved upstream.

[vsonnier]

Time to close this way too old issue.