Problems with gqrx 2.5.3 and SDRPlay

[wofritzyt]

Hi,

I have got gqrx 2.5.3 running on Kubuntu 14.04 with an SDRPlay. It is basically working but I have some problems.

Sometimes the SDRPlay appears in the device list, sometimes it does not. What can be the reason?

If the SDRPlay is in the list and I select it, I get device string "sdrplay=0". If the SDRPlay ist not in the list, I can select it with device "Other" and device string sdrplay=0.

I can also activate the SDRplay with "Other" and device string soapy=sdrplay.

Both devices give slightly different settings in the "Input controls" tab.

Problems:

Device "sdrplay=0":
1. I can not select input rate in "I/O devices" the pull down menu is empty. I can enter an input rate manually, but this is not stored in the settings.
2. Changing frequency does not work. I see the hardware frequency changing and the frequency marks moving, but no effect. I see in the terminal that the RF frequency in the driver is not changed. I can change demodulator frequency correctly.
3. When I start gqrx, I get a message that something is wrong with my device and I must reconfigure it.

Device "soapy=sdrplay"
1.I can not select input rate. Same as above.

I have installed gqrx following the procedure in http://gqrx.dk/download/install-ubuntu.
I compiled osmosdr manually for SDRPlay and SoapySDR support.

What would be the best way to attack these problems? I am experienced with Linux and C++, but have no experience so far with SDR and SDR software. I am not afraid to set up a development environment and do some testing.

I'll read through the gqrx web site, but some start points would be helpful.

Regards,
Wolfgang, DK7OB

[David Ranch]

Hello Wolfgang,

I have similar issues with my AirSpy v2 and the following thread answers some of your questions:

   https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!searchin/gqrx/David$20Ranch/gqrx/L62IQW3hs0U/B-6DFPpnAQAJ

--David
KI6ZHD

[Alexandru Csete]

Hi Wolfgang,

I think the gr-osmosdr driver wrapper needs to be updated for the
recent sdrplay API. There may have been a patch on the sdrplay forum
some time ago.

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/790e8a95-ff03-408c-8821-d3e11fb1ba49%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[wofritzyt]

Thanks David, could well be the same issue.

The thread confirms what I suspected: The device string is important, and if it works with "Other" and the correct device string it's OK with me.

I have observed the problem at startup only with device string sdrplay=0, not with soapy=sdrplay.

[wofritzyt]

On Friday, March 25, 2016 at 1:51:43 AM UTC+1, Alexandru Csete wrote:

Hi Wolfgang,

I think the gr-osmosdr driver wrapper needs to be updated for the
recent sdrplay API. There may have been a patch on the sdrplay forum
some time ago.

Alex

Thank you Alexandru.

I searched the sdrplay forum but no luck so far.

I built gr-osmodr and soapysdr from git master.

I'm going to update my Eclipse environment today and import the gr-osmosdr and soapysdr sources so I can navigate in the code better.

Some question regarding my current "major" issue regarding the empty sample rate list:
- Should the driver provide a list of the supported sample rates?
- If I enter the frquency manually, shouldn't it be stored in the settings anyway? I just checked with a "RFSPACE SDR-IQ Receiver". I can select a sample rate and this sample rate is restored correctly after gqrx restart. Even if I change this value manually, the modified value is restored correctly.

Wolfgang, DK7OB
 

[Alexandru Csete]

On Fri, Mar 25, 2016 at 8:07 AM, wofritzyt <wolfgan...@gmx.net> wrote:
>
> I searched the sdrplay forum but no luck so far.

I'm pretty sure I have seen a patch a month or two ago, or perhaps
there is a modified version of gr-osmosdr maintained by sdrplay on
github.

>
> I built gr-osmodr and soapysdr from git master.
>
> I'm going to update my Eclipse environment today and import the gr-osmosdr
> and soapysdr sources so I can navigate in the code better.
>
> Some question regarding my current "major" issue regarding the empty sample
> rate list:
> - Should the driver provide a list of the supported sample rates?
> - If I enter the frquency manually, shouldn't it be stored in the settings
> anyway? I just checked with a "RFSPACE SDR-IQ Receiver". I can select a
> sample rate and this sample rate is restored correctly after gqrx restart.
> Even if I change this value manually, the modified value is restored
> correctly.

The sample rate is stored in the settings, you can check in the config
file stored in ~/.config/gqrx/
It may not work properly with the sdrplay or soapysdr backend,
however, as I wrote above, I have seen reports that it works with a
patched gr-osmosdr.

One last thing to keep in mind. You wrote that you installed gqrx from
the PPA, then went on installing gr-osmosdr from source. Unless you
have taken special precautions, you now have two versions of
gr-osmosdr installed and gqrx still uses the "old" from the PPA.

Alex

[Wolfgang Fritz]

Am 25.03.2016 um 11:03 schrieb Alexandru Csete:
> On Fri, Mar 25, 2016 at 8:07 AM, wofritzyt <wolfgan...@gmx.net> wrote:
>>
>> I searched the sdrplay forum but no luck so far.
>
> I'm pretty sure I have seen a patch a month or two ago, or perhaps
> there is a modified version of gr-osmosdr maintained by sdrplay on
> github.
>

OK. I'll check this. The "Getting Started" procedure on the sdrplay
website guided me to a gr-osmosdr git repo, maybe this is the modified
version already.

>>
>> I built gr-osmodr and soapysdr from git master.
>>
>> I'm going to update my Eclipse environment today and import the gr-osmosdr
>> and soapysdr sources so I can navigate in the code better.
>>

This is done. I have gqrx from git and gr_osmosdr etc. now in eclipse
and can build everything from source.


>> <snip>

>
> The sample rate is stored in the settings, you can check in the config
> file stored in ~/.config/gqrx/
> It may not work properly with the sdrplay or soapysdr backend,
> however, as I wrote above, I have seen reports that it works with a
> patched gr-osmosdr.
>

I have found out why the sample rate drop down list is empty:

The drop down list content is hard coded in
CIoConfig::updateInputSampleRates() and there is no code for sdrplay yet
and no "catch all" default. I have added code now for the sdrplay and
the drop down list is working. A "last resort" which simply copies the
stored rate to the drop down list would still be nice.

I found an issue though: If the has been stored before, that value is
not displayed, but always the first entry. The stored entry is attached
to the end of the list for some devices and at the beginning of the list
for other devices.

> One last thing to keep in mind. You wrote that you installed gqrx from
> the PPA, then went on installing gr-osmosdr from source. Unless you
> have taken special precautions, you now have two versions of
> gr-osmosdr installed and gqrx still uses the "old" from the PPA.
>

Yes, I have that in mind. The gqrx from the binary package indeed tries
to load the libraries from the binary packages (which are under
/usr/lib) but I forced it to use my libraries with
LD_PRELOAD=/usr/local/lib/libgnuradio-osmosdr-0.1.5git.so

But the home built gqrx uses the libs in /usr/local/lib by default.

BTW: If I get the sdrplay working properly, are you interested in patches?

Wolfgang

> Alex
>

[Alexandru Csete]

On Fri, Mar 25, 2016 at 11:35 AM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
>
> BTW: If I get the sdrplay working properly, are you interested in patches?
>

Yes, but the only device specific code in gqrx is the list of
predefined sample rates and I'd be happy to get a patch with that.

Alex

[Wolfgang Fritz]

Am 24.03.2016 um 20:31 schrieb wofritzyt:
> Hi,

> Problems:
>
> Device "sdrplay=0":

> 2. Changing frequency does not work. I see the hardware frequency
> changing and the frequency marks moving, but no effect. I see in the
> terminal that the RF frequency in the driver is not changed. I can
> change demodulator frequency correctly.

I found out that this does only happen if the frequency step is < 10kHz.

Reason is the gr_osmodsr and a possible bug in the sdrplay API.

For delta < 10 kHz, osmodsr calls mir_sdr_SetRf() in relative mode with
the delta. This has no effect. I changed that to use the frequency in
absolute mode and now it is working properly.

For delta >= 10 kHz, the osmosdr performs a full device reinitialization
which also sets the frequency.

I have to ask on the sdrplay forum why this is done.

And I double check if the osmosdr I am using is the one
supported/modified by sdrplay.

Wolf, DK7OB

[Wolfgang Fritz]

Please check attached patch.

This works for the osmosdr and the soapy backend.

Looking at the code, the soapy backend seems to be more advanced than
the osmosdr. It "behaves" better, for example a series of larger
frequency steps (10 kHz and more) with the scroll wheel gives errors
with osmosdr because they are executed too slowly but work without
problems with the soapy backend.

Sometimes I get a bus error when I quit gqrx. This seems to be relatred
to sdrplay, but since I have no other SDR hardware, I can't verifiy this.

sdrplay seems to need quite some work until "production ready" :-)

Regards,
Wolf DK7OB

PS: Forgot to say: gqrx is a very nice program!

[Alexandru Csete]

On Fri, Mar 25, 2016 at 7:31 PM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
>
> Please check attached patch.

Thanks for the patch, I have applied it.

>
> sdrplay seems to need quite some work until "production ready" :-)
>

The SDR hardware market is increasingly overloaded. Basically, a new
SDR device comes out every month. On the other hand, there are very
few people capable and/or willing to write SDR software and even fewer
who go all the way to provide end user applications.

At the same time the number of users has also exploded during the last
2 years, so the balance between hardware availability, user base and
software providers is very unbalanced. I tried running gqrx as a
serious project but had to say stop when it was growing to an unpaid
full time project. So, now it is back to the "what I have and when it
suits me" spare time project type.

On the positive side, I have got a significant amount of free hardware
out of doing work like gqrx and this helps a lot towards providing
good support for the hardware. I have stopped worrying about
supporting hardware that I do now have sitting on my desk or otherwise
have unconditional access to.

I do not have an SDRPlay and to make it worse, it comes with a closed
source driver that can not be integrated into our binary packages.
Blind coding using a closed source driver is not very appealing to me.
The company may go out of business and then nobody will be able to
update the drivers.

How many times do we see people worried like "Should I upgrade from
windows X to Y? Will my drivers work?" and it is the same on linux
with binary only drivers.

I hope this rant can shed some light on why I am not putting any
significant effort into sdrplay support.

Alex

[Wolfgang Fritz]

Am 26.03.2016 um 13:39 schrieb Alexandru Csete:
> On Fri, Mar 25, 2016 at 7:31 PM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
>>
>> Please check attached patch.
>
> Thanks for the patch, I have applied it.
>
>>
>> sdrplay seems to need quite some work until "production ready" :-)
>>
>
> The SDR hardware market is increasingly overloaded. Basically, a new
> SDR device comes out every month. On the other hand, there are very
> few people capable and/or willing to write SDR software and even fewer
> who go all the way to provide end user applications.
>

I was talking about the sdrplay drivers, not gqrx ;-)

> At the same time the number of users has also exploded during the last
> 2 years, so the balance between hardware availability, user base and
> software providers is very unbalanced. I tried running gqrx as a
> serious project but had to say stop when it was growing to an unpaid
> full time project. So, now it is back to the "what I have and when it
> suits me" spare time project type.
>
> On the positive side, I have got a significant amount of free hardware
> out of doing work like gqrx and this helps a lot towards providing
> good support for the hardware. I have stopped worrying about
> supporting hardware that I do now have sitting on my desk or otherwise
> have unconditional access to.
>
> I do not have an SDRPlay and to make it worse, it comes with a closed
> source driver that can not be integrated into our binary packages.
> Blind coding using a closed source driver is not very appealing to me.
> The company may go out of business and then nobody will be able to
> update the drivers.
>

Yes, that's a problem I was not aware of when I purchased the sdrplay. I
usually avoid hardware that is not supported by open drivers.

> How many times do we see people worried like "Should I upgrade from
> windows X to Y? Will my drivers work?" and it is the same on linux
> with binary only drivers.
>
> I hope this rant can shed some light on why I am not putting any
> significant effort into sdrplay support.
>

Yes, and I fully accept it.

Maybe I find the time to look into it a bit deeper, but I am on a full
time job and don't have the time I would like to have.

Also I'm not familiar with SDR or GUI programming.

What I like to have is the soapy support for sdrplay in gqrx, because
the soapy driver seems to be much better. I'll look into this.

But I have to find out how actively these drivers are developed. Maybe
osmosdr is catching up.

Wolfgang

> Alex
>