AlexandreRouma / SDRPlusPlus

Cross-Platform SDR Software
GNU General Public License v3.0
3.94k stars 544 forks source link

SDRPlay RSP1a issues #762

Closed bubbaearle closed 2 years ago

bubbaearle commented 2 years ago

I have new installs of the 64 bit Pi OS bullseye on a 4GB Pi 4 as well as a Pi 400. I also have a Lenovo laptop loaded with Linux Mint LMDE 5.0 Elsie - Debian bullseye I used this website for install instructions: http://radiosrs.net/tech.html
SDR++ and CubicSDR istalled on each machine.

On each machine I was initially able to start the RSP1a, but stopped it to make adjustments to settings, but after a few minutes it froze up and crashed.

On each machine SDR++ will recognize my RSP1a but will not start it. SDRPlay selected as source, RSP1A with serial# as device. No Device Available in red below IF mode.

Used the following commands to start / stop SDRPlay to troubleshoot: sudo systemctl stop sdrplay sudo systemctl start sdrplay

I can select RTL SDR or another device and it will start.

I can run SDR++ with my RTL SDR - no issues.

RSP1a works fine with CubicSDR on each machine - no issues.

Reboot after app crash and still same results. I have reinstalled the SDRPlay API as well as SDR++, I am at a loss at this point.

AlexandreRouma commented 2 years ago

the SDRplay API on linux is quite broken.

I suspect there is a conflict between SoapySDR and the native source module, Go to the module manager menu, remove the SoapySDR source, confirm that there is no longer a "SoapySDR" option in the source menu and reboot your Pi.

Cubic uses SoapySDR only so there is no chance of conflict.

By the way, make sure to never have two SDR software running at the same time because the SDRplay API doesn't handle it well.

(It showing "device not available" is proof that there's a usage conflict)

bubbaearle commented 2 years ago

I never have two apps open at the same time or else the Pi's will overheat, the laptop could probably handle the CPU load, but I never have two apps trying to use the same device at the same time.

I reboot after every crash & restart SDR++ only.

Aren't the SDRPlay API & SoapySDR co-dependent?

I will try deleting the SoapySDR module as a source and report back. I'll try this on the laptop first as it is the machine that will be my primary RSP1a host, then on the Pi4.

Will post my results.....

AlexandreRouma commented 2 years ago

The SDRplay API and SoapySDR are two completely different things and are completely independant.

bubbaearle commented 2 years ago

10-4

I thought the API was dependent on SoapySDR. I reckon it's needed by CubicSDR, so that's why they (SDRPlay) have a script for it.

I'm new at Linux , but I'm learning.

AlexandreRouma commented 2 years ago

Cubic needs it because Cubic doesn't have specialized code for each SDR vendor, it uses SoapySDR as an abstraction layer.

SDR++ talks to the SDRplay API directly.

bubbaearle commented 2 years ago

Your suggestion seems to have resolved the issue - on both the laptop & the Pi4

I deleted the SoapySDR module

Rebooted machine

Selected SDRPlay & clicked REFRESH button

Clicked start button and device started. Started / stopped several times tweaking/learning settings and so far so good.

bubbaearle commented 2 years ago

I ran the software some over the weekend. It seemed to be pretty good, except on a few occasions it did not see the device. A reboot solved the issue.

I did notice the longer the app runs - several hours of use, the slower the response of the app gets. Button clicks are slower, display gets slower, at which point the audio gets choppy. Starting & stopping the device locks the app up forcing you to reboot.

AlexandreRouma commented 2 years ago

either your computer is overheating or there's an issue with your graphics drivers. Then UI runs completely separate of the DSP and I know of many users who have let it run for weeks with no issues.

srs4511351 commented 2 years ago

I also use SDR++ on a Raspberry Pi. I do have occasional problems with SDR++ loading the SDRplay device. It is necessary to restart the device to get it working again. Once it works, it is reliable. I still have the SoapySDR devices enabled. HackRF crashes if I run any other device first.

If there is a problem with the SDRplay API, I hope you will contact SDRplay to resolve the issue. I can run the SDRplay device directly with gqrx or use the SoapySDR device. Either one will work. The same is true for QRadioLink and SDRangel. I have no problems with SdrGlut. I have run the SDRplay and HackRF at the same time in SDRangel with no problems. I have also run both devices simultaneously it 2 different applications.

Somehow, these other applications have managed to get the SDRplay device to work well with their program. Could you discuss it with them?

----Steve

Lesprilibre commented 2 years ago

Hi ! I've you ever try some commands like systemctl restart sdrplay ? This can avoid rebooting you system by restarting just the service

srs4511351 commented 2 years ago

Sometimes this will help: sudo systemctl stop sdrplay sudo systemctl start sdrplay

It it is too messed up, you may need to restart. I rarely have to power off or unplug and replug it.

——Steve

AlexandreRouma commented 2 years ago

I'll close as the original issue seems to be resolved. For anyone else who joined, please open your own issue if you still have problems.