So here is my progress as of now:
It compiles on linux and works with linrad
Of course still many missing features:
No gui, every parameter is hardcoded and can not be changed except frequency:
- Sample rate is 2 Mhz, Bandwidth is 1536 kHz
- AGC is ON (altho I hate it), AGC setpoint is -25
- Zero IF mode
- LO plan auto. this closes the 380-420Mhz gap but for me it seems sdrplay is just bad on 250-420Mhz. (lot of images from broadcast FM and Tetra (Terrestrial Trunked Radio, used by the government here).
No saving/loading settings. If I do this with a config file at least it will be configurable with that.
Linrad knows about some more extio calls:
Has anybody heard about these? Are they invented by linrad?
How to buld:
then copy the libExtIO_SDRPlay.so from Linux/build/src/ to your linrad folder (where the xlinrad64 binary is).
short term TODO:
- implement setting gain with the linrad specific (?) functions
- look at SetHWSR() (also linrad specific(?))
Gain (reduction) can now be set from linrad.
Setting gain also turns AGC off and since linrad always sets the last used gain, well, AGC is now off.
In linrad gain can be set between -6 dB and 44 dB. This range is mapped to gain reduction as described below:
- below 420MHz maps to 90 .. 40 dB gain reduction (-6db gain in linrad means 90dB GR, 44dB gain in linrad means 40dB GR)
- above 420MHz maps to 85 .. 35 dB gain reduction (-6db gain in linrad means 85dB GR, 44dB gain in linrad means 35dB GR)
Small problem using the arrows around the Gain value in linrad:
It does not work unless you use some other device before sdrplay.
Solution: set up the mode you want to use, quit linrad, open par_fm_fg or par_ssb_fg or ... according to the mode you set up. Look for this line:
Change the 0 in brackets to the gain increment/decrement step you want the arrows to do. Do not change anything else!
GQRX and OsmoSDR is unusable and abandoned by me.
CubicSDR is young as functionality but with a good GUI and a good decoding library. It is missing IF and audio filters.
HDSDR with Wine is working OK but it is a Windows program in Wine
SDR Console don't run in Wine (Ubuntu 14.04) without a different version of Wine.
Linrad is too complex and I never had any feeling with it
So for now I am using CubicSDR, with problems in SSB/Digital decoding, and HDSDR.
But why work to a new GUI, with integrated SDR decoding, when there is many GUI programs already done?
The "old" dttsp was a "no GUI" program reading from radio, processing I&Q and playing radio (on Jack). All of this controlled by a TCP/IP connection. Also dspserver, from ghpsdr3, is a "server" program with interface to hardware like SDRIQ, HPSDR, Softrock, Perseus, etc.
There are also Quisk, interfaced to SDRIQ, HPSDR, "audio" SDR. Or Cutesdr.
So my question is:
why not developing a library to interface SDRPlay to an existent protocol, usable and supported from existent GUI program?
I am not a C programmer nor a programmer at all but I can do test and help to make SDRPlay a receiver interfaced to a widely range on programs.
Unfortunately similar experience and after two weeks I am considering selling the sdrplay for any price. Its pretty useless and took way to much time to get it to 20% working on linux. The hardware specs are nice but the api interface does not connect to existing programs. I did manage to get gnuradio to work somewhat but I had to change the source code to avoid usb overflows. Thats not how this is supposed to work or how it is being advertised.
Perhaps in future a good API will be available. Lets see...
Best regards, Onno de pa1ap
Reason: No reason
If you are using the gr-osmosdr from the GIT source or one of the packages with your Linux distribution, try replacing the sdrplay_source_c.cc in src/gr-osmosdr/lib/sdrplay/ with my version and I think you'll find it works much better. Turn off (uncheck) hardware AGC and IQ balance. The GQRX DC removal option can be left on, but I've found it is often necessary to boost the gain (less gain reduction) then reduce it (more gain reduction) it to activate the single shot DC removal implemented in the SDRplay library to minimize it. The API allows periodic DC removal but that isn't implemented in the current library.
I just installed SoapySDR and CubicSDR. It looks promising. Since SoapySDR provides another way to get the SDRplay into gnuradio, it might provide some features the current gr-osmosdr sdrplay library is missing. I'll report back when I've got it working. SDR-J is another option that includes several digital decoders.
I hope this helps those joining the thread late. If you follow it from the start, you'll see getting this thing working well with gnuradio wasn't easy!
... Doug AH6DL
Reason: No reason
I have read all posts in this thread from first post before ordering my SDRPlay.
And I have done all compile on my Ubuntu 14.04 without success. All compile fine but GQRX don't decode correctly.
I will redo all steps this weekend, starting from a fresh gr-osmosdr.
CubicSDR is promising but very young. No audio DSP (NR/NB/Notch) and no variable audio filter. Also some problems in correct decoding SSB.
SoapySDR + SoapySDRPlay is working wery well in CubicSDR, expecially for FM reception. So starting from SoapySDR for going to Gnuradio can be promising. I will wait your progress report on this.
SDR-J don't compile on my Ubuntu 14.04. It require Fedora or a newer Ubuntu. And is very good for FM reception and for DAB/DAB+ but SW reception is not so good.
With my old H101 I am using Quisk (simple and good) and also a self made GUI, based on Python and old Dttsp. Also Dttsp is good for SSB reception and audio DSP.
What is needed is a library for interfacing existent GUI programs to SDRPlay, simulating an existent protocol. For this SoapySDR can be a starting point.
Sorry to hear about your problems with GQRX. If you compile gr-osmsosdr with my sdrplay code, it will output the buffer status when it overflows/underflows. That can be helpful in tracking down problems. A safe starting point is sample rate at 1536000 and bandwidth at 1536000. I can send you my sdrplay config file for GQRX is that helps. When experimenting I've run into a few cases where the config file got corrupted and the only thing I could do to make it work again was to delete it and go back to an older saved config. For what it's worth, I'm using GQRX complied from GIT, v2.3.2-123-gf9a33e12. Older versions did not work nearly as well as this one.
I've been playing around with CubicSDR over the U.S. Thanksgiving holiday. I agree the FM radio performance is excellent. I can listen to one weak FM station on another island that is too distorted on any of the other programs I've tried -- including those in Windows. The bandspread window in the upper left is really nice for browsing the ham bands. It seems the I/Q output could be used to drive Quisk (which I use with my FiFiSDR) or fldigi. Maybe if I have some time today I'll see if I can get that working. My biggest complaint is I don't see a way for direct frequency entry (can't type numbers in the boxes as far as I can tell) and no option for memories. It should be easier to add that than the narrower filters and noise blankers. If I have some spare time I may look into it. More filters would be nice -- it shouldn't be too difficult to add them using existing open source code.
One thing I found made a huge difference with CubicSDR, as well as with other programs using SDRplay, is the gain setting. In my experience reception greatly improves with Automatic Gain switched off, the LNAT set to near minimum, and the TUNER gain adjusted to maximize SNR. There are threshold effects so sometimes it has to be adjusted up and down to let it settle in the sweet spot. That's the same performance I've found in GQRX with gr-osmosdr.
The closest thing to a universal interface is qr-osmosdr, at least for Linux, but some of it's parameters are not passed to the sdrplay and the SDRplay advanced features aren't supported. This prevents it from working with programs like gr-air-modes as there is no way to pass a bandwidth setting to it that I can find. Fixing that seems do-able, if device parameters from gr-osmosdr are made available to the SDRplay API. gr-osmosdr allows device strings with custom data, and it seems those could be use to set parameters like those in the Windows EXTIO. I was hoping that the soapy driver could be used in gr-osmosdr, but when I tried using it I noticed gr-osmosdr still used its own sdrplay library. From the SoapySDR web page, it looks like they haven't gotten that working yet.
The SDRplay is a great radio, and slowing the software for Linux is catching up. The situation is a lot better than it was when this thread started!
Reason: No reason
After this I have cloned GIT repo of GQRX and compiled it using qmake;make. This was my mistake, producing a "non working" GQRX
After this I have used cmake;make and this time GQRX is working.
I agree with you that gain reduction is critical in SDRPlay. In GQRX thee is only a control for gain, marked as LNA_MIX_BB gain.
In CubicSDR there is a menu option (not saved) for disabling automatic gain control. After disabled there are two slider for gain and for LNA threshold. For direct value using keyboard in frequency and bandwidth use space bar and an input field pop up for this. But this only work after a first "click" for setting an initial frequency.
For using I/Q output in Quisk there are some test to do. I suppose Quisk need to be configured for an "audio card radio" as Softrock using a band of 48000.
In Fldigi I don't know how to use an I/Q input.
SoapySDR look promising. Waiting If it become a standard.
Please post the results of your test for all of us using this great radio in Linux