SDRPlay API 3.01 support

nmaster2042 commented 4 years ago

It would add dual tuner support for RSP Duo. The 3.01 API is avaliable on open beta.

SDRplay commented 4 years ago

It already exists here: https://www.sdrplay.com/community/viewtopic.php?f=9&t=4179&p=13884 needs testing

dlaw commented 4 years ago

Direct GitHub link: https://github.com/fventuri/SoapySDRPlay3

vsonnier commented 4 years ago

@SDRplay Not to mention v3.0 would likely be needed to support RSPDx also...

nmaster2042 commented 4 years ago

I built the SoapySDRPlay3 module and tried it on my ubuntu 19.04.

I built the last SoapySDR and Cubic SDR.

I connected my RSPduo, started CubicSDR, RSPDuo was detected.

I started a with Tuner 1 50 ohms, it works fine, tried HIZ, worked too, and the tuner 2 50 ohms too.

Then I started a second instance of cubicsdr at the same time, but this time it didn't detects RSPDuo to let me use the other free tuner.

Let me know if you need some more tests.

nmaster2042 commented 4 years ago

Here commands from SoapyUtil, the probe seems to have issue:

$ SoapySDRUtil --find

######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Found device 0 driver = sdrplay3 label = SDRplay3 Dev0 RSPduo 1809029D65

$ SoapySDRUtil --probe="driver=sdrplay3"

######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay3 Error probing device: map::at

SDRplay commented 4 years ago

I haven't performed a review of the SoapySDRPlay code for the API 3.01, but before the slave stream can be started, the first stream needs to be put into master mode. If it is still in single tuner mode (the default) then the API will not allow the 2nd stream to start. It will also not allow the 2nd stream to be seen as available.

@vsonnier how to handle the API 3.x here? Another branch? Once this is setup and the initial code from Franco is here, it will be easier to review and maintain.

In the next couple of weeks I'll have an updated version of the API to support the RSPdx as well as some bug fixes including the high sample rate issue that was around from some time ago.

I won't be able to make a lot of the SoapySDRPlay changes myself, but I'll be active on here and will help where I can.

Andy.

vsonnier commented 4 years ago

Thanks @SDRplay, we'll need to think of the use cases there for master/slave situation.

Instead of using manual switches the Module could auto-detect the current master/slave mode at initialization and expose settings accordingly, something like:

First Cubic instance => master mode, expose settings relevant to master (all ?), display device as "Duo Master" ot whatever.
Second Cubic instance starting => slave mode, only expose settings relevant to slave w.r.t master already started ( for instance, no antenna switch option ?) , display device as "Duo Slave" or whatever.

That's cool, but what happens when either the Cubic master or slave is closed, what are the changes to be reflected on the remaining instance ?.... If the Master remains, nothing change I suppose. If the Slave remains, would it turns silent, or continue streaming ?...etc.

Maybe the simpler way for the user is to use a manual switch procedure carefully explained in the Readme.

For developpement, it would take some time coming to the point of v3.0 could replace v2.0 completely (support of all devices on all platfoms OK) and adding a v3.0 module as a separate repository (@fventuri SoapySDRPlay3) and keeping the v2.0 alongside it (today SoapySDRPlay) would be wise.

If @fventuri and @guruofquality agree of puting SoapySDRPlay3 as a new module under the Pothosware banner, that is.

Alas I'm not as involved in the SDR hobby as before and I probably won't contribute myself, but I could take some time to test on RSP2 / Windows10 side of things when the time comes.

Of course, the main audience would be Linux / MacOS for such modules but I can't help in that regard.

SDRplay commented 4 years ago

It's not as simple as always starting the first instance as the master. In master mode, Low-IF is only possible and so therefore only 2 MHz of bandwidth. So what we do in SDRuno is to always start in single tuner mode, but have a switch to allow the changing of the first instance into master mode. Then the 2nd instance would automatically start in slave mode. Then there is dual tuner mode, where both tuners are controlled by the same instance. I guess this could all be handled by a mode option in the device selection panel.

Whichever instance is using tuner 1 will still be able to switch between the HiZ port and port A in master/slave mode.

Also, the newly announced RSPdx will only be supported in API 3.x - the aim will be to transition all library support over to API 3.x so @guruofquality does it make sense to have the API 3.x version as a branch or a new library for now? Whichever way you want to support it is fine with me.

SDRplay commented 4 years ago

I've had a look at the SoapySDRPlay3 library and can see why it's not working. Low-IF mode in particular doesn't work like it did in API 2.x, it's easier now. I'll try to find some time to make some changes if @guruofquality can give some guidance on where the library should be maintained.

Andy.

fventuri commented 4 years ago

Vincent, no problem with me with putting SoapySDRPlay3 under the Pothosware banner (I think the could should already have the correct license).

Feel free to contact me if you any questions about the code itself.

Franco

On November 6, 2019 at 3:02 PM Vincent Sonnier notifications@github.com wrote:

Thanks @SDRplay https://github.com/SDRplay , we'll need to think of the use cases there for master/slave situation.

Instead of using manual switches the Module could auto-detect the current master/slave mode at initialization and expose settings accordingly, something like:

    * First Cubic instance => master mode, expose settings relevant to master (all ?), display device as "Duo Master" ot whatever.
    * Second Cubic instance starting => slave mode, only expose settings relevant to slave w.r.t master already started ( for instance, no antenna switch option ?) , display device as "Duo Slave" or whatever.

That's cool, but what happens when either the Cubic master or slave is closed, what are the changes to be reflected on the remaining instance ?.... If the Master remains, nothing change I suppose.
If the Slave remains, would it turns silent, or continue streaming ?...etc.

Maybe the simpler way for the user is to use a manual switch procedure carefully explained in the Readme.

For developpement, it would take some time coming to the point of v3.0 could replace v2.0 completely (support of all devices on all platfoms OK) and adding a v3.0 module as a separate repository (@fventuri https://github.com/fventuri SoapySDRPlay3) and keeping the v2.0 alongside it (today SoapySDRPlay) would be wise.

If @fventuri https://github.com/fventuri and @guruofquality https://github.com/guruofquality agree of puting SoapySDRPlay3 as a new module under the Pothosware banner, that is.

Alas I'm not as involved in the SDR hobby as before and I probably won't contribute myself, but I could take some time to test on RSP2 / Windows10 side of things when the time comes.

Of course, the main audience would be Linux / MacOS for such modules but I can't help in that regard.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/pothosware/SoapySDRPlay/issues/58?email_source=notifications&email_token=AAKTH64QSHQUTSGT4G7O3OLQSMPFRA5CNFSM4JADTU62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDHZ5DA#issuecomment-550477452 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKTH6ZI4URACFDRX2Y2I5DQSMPFRANCNFSM4JADTU6Q .

guruofquality commented 4 years ago

If the v3 api can support everything, then we really dont need a new project like SoapySDRPlay3 right? I would just tag the current SoapySDRPlay and tell anyone if they need to use the v2 api to check out the tag. And make the v3 support the master branch. The goal is to switch over to the v3 api entirely, right?

SDRplay commented 4 years ago

Yes @guruofquality, API 3.x can support all RSPs and is necessary for full RSPduo support and also to support the RSPdx - for now though, the default build that people find should be API 2.x - in the next few weeks I'll get the API 3.x builds for Linux/x86, MacOS and ARM released and will also look at the SoapySDRPlay code to support it. When the API 3.x version of SoapySDRPlay has been tested and proven to work well, then it should become the master.

SDRplay commented 4 years ago

I've setup api3 branch, based on @fventuri repo - I've fixed the RSPduo probe and added basic RSPdx functionality.

There is still work to do - I will try to do more when I can, but if anyone can help that would be appreciated. The RSPduo master/slave and dual tuner functionality needs more work. Also, adding RSPdx HDR mode.

nmaster2042 commented 4 years ago

Issue remains the same with the new api3 branch + last api 3.06.

I connect my RSPduo, started CubicSDR, RSPDuo was detected.

$ SoapySDRUtil --find driver=sdrplay give this output:

######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Found device 0 driver = sdrPlay label = SDRplay Dev0 RSPduo 1809XXXXXX

Here is the probe command: $ SoapySDRUtil --probe driver=sdrplay ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device [INFO] devIdx: 0 [INFO] hwVer: 3 [INFO] mode: 1

-- Device identification

driver=SDRplay hardware=1809XXXXXX sdrplay_api_api_version=3.060000 sdrplay_api_hw_version=3

-- Peripheral summary

Channels: 1 Rx, 0 Tx Timestamps: NO Other Settings:

RSP Duo Mode - RSP Duo Mode [key=rspduo_mode, default=Tuner A (Single Tuner), type=string, options=(Tuner A (Single Tuner), Tuner A (Master/Slave), Tuner B (Single Tuner), Tuner B (Master/Slave), Dual Tuner)]
RF Gain Select - RF Gain Select [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)]
IF Mode - IF frequency in kHz [key=if_mode, default=1620kHz, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)]
IQ Correction - IQ Correction Control [key=iqcorr_ctrl, default=true, type=bool]
AGC Setpoint - AGC Setpoint (dBfs) [key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
ExtRef Enable - External Reference Control [key=extref_ctrl, default=true, type=bool]
BiasT Enable - BiasT Control [key=biasT_ctrl, default=true, type=bool]
RfNotch Enable - RF Notch Filter Control [key=rfnotch_ctrl, default=true, type=bool]
DabNotch Enable - DAB Notch Filter Control [key=dabnotch_ctrl, default=true, type=bool]

-- RX Channel 0

Full-duplex: NO Supports AGC: YES Stream formats: CS16, CF32 Native format: CS16 [full-scale=32767] Antennas: Tuner 1 50 ohm, Tuner 2 50 ohm, Tuner 1 Hi-Z Corrections: DC removal Full gain range: [0, 48] dB IFGR gain range: [20, 59] dB RFGR gain range: [0, 9] dB Full freq range: [0.001, 2000] MHz RF freq range: [0.001, 2000] MHz CORR freq range: MHz Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

Then I start with Tuner 1 50 ohms. Everything is ok. Last I start a second instance of cubicsdr at the same time, but this time it didn't detects RSPDuo.

on command line wile first cubicsdr instance is running I can make

$ SoapySDRUtil --probe="driver=sdrplay" ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay Error probing device: SoapySDR::Device::make() no match

The service API is running too: $ ps ax | grep sdr 1468 ? Sl 0:47 /usr/local/bin/sdrplay_apiService 13509 pts/1 S+ 0:00 grep --color=auto sdr

How can I change tuner mode in order to use the dual tuner mode ?

SDRplay commented 4 years ago

This is not an "issue" as such - this branch is a work in progress. As I said above...

There is still work to do - I will try to do more when I can, but if anyone can help that would be appreciated. The RSPduo master/slave and dual tuner functionality needs more work. Also, adding RSPdx HDR mode.

The master/slave functionality isn't working - I will try to get to it when I can, but if anyone else is able to make the changes that would be great.

Master mode requires either 6 or 8 MHz sample rate, IF = 1.620 MHz and BW = 1.536 MHz. 6 MHz is the standard mode, 8 MHz is really only to be used to be compatible with dump1090 which also can be run in master/slave mode.

Dual tuner mode hasn't been implemented - I'm not sure whether the SoapySDR framework or SoapySDR compatible applications can support two IQ streams? Maybe one for @guruofquality

nmaster2042 commented 4 years ago

Sorry I red too fast. I was too excited to try it ;-)

On the SoapyUtil --probe command we see 1 RX channel whereas there is actually 2 tuners. It would perhaps do it for 2 iq streams to add a 2nd RX channel ?

it's just a reflection, i don't know if it can work that way.

SDRplay commented 4 years ago

Yes this why it needs some work. Currently it is set up in single tuner mode so that's why it reports 1. However the device can be queried and 2 can be reported IF the master tuner hasn't already been started.

If no one gets to this then I will do it, it's just a matter of when I'll be able to.

fventuri commented 4 years ago

I made a fork under my account and created a branch called 'RSPduo_fixes' (https://github.com/fventuri/SoapySDRPlay/tree/RSPduo_fixes). I cleaned up a couple of warnings during compile and I also straightened up the code for the RSPduo mode/tunes and antennas (hopefully). I tested my changes this afternoon using 'SoapySDRUtil' with the following commands:

SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner A (Single Tuner)" SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner B (Single Tuner)" SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner A (Master/Slave)" SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner B (Master/Slave)" SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Dual Tuner"

and in each case 'SoapySDRUtil' returned what I expected (including 2 RX channels in the last case with 'Dual Tuner').

Please give it a try and if it looks OK to you, I'll go ahead and send a pull request.

Franco

pothosware / SoapySDRPlay2