SoapySDRPlay support

[ghost]

I am trying to get the SDRplay to work on a mac using osmosdr and it just doesn't work. Also i don't expect too much Mac support from the SDRplay guys. They are mainly focussing on Windows.
Given that the SDRplay API is public, how much effort would it be to add native support for SDRplay in CubicSDR? I think native support for the trio RTL-SDR (done), AirSpy and SDRplay would make CubicSDR the first SDR application for the "new generation" SDR devices.

In this issue you can find (will be copied to wiki eventually):

Build instructions (OSX): #144 (comment)
Update instructions: #144 (comment)

[dc1rdb]

Fully supporting this request and willing to help with testing!

[cjcliffe]

It looks like using SoapySDR for #64 is going to future-proof us for this. It's possible to add an SDRPlay SoapySDR driver without even having to re-compile CubicSDR; they already have a separate driver available for UHD and BladeRF I'm just using the OsmoCom RTL one to start for testing as it's the only device I have here at the moment.

That said once Soapy is implemented anyone could write the SoapySDRPlay driver and add it to CubicSDR without needing my intervention; it'd be a bit more difficult for me to do without the hardware so adding it as a SoapySDR issue for them might get the driver done more quickly.

[ghost]

Cool! Since i have a SDRplay, is there anything i can do to help moving this forward?

[dc1rdb]

FYI: I've just placed an enhancement request at the SDRPlay website to provide a SoapySDR module for the SDRPlay RSP.

[cjcliffe]

@dc1rdb cool -- you might want to direct them here: https://github.com/pothosware/SoapySDRPlay as I've also partly implemented it myself last night in a fork here: https://github.com/cjcliffe/SoapySDRPlay

I'm hoping between @Toontje and I we can get it working; would love to have one to test (as I would with all the devices, hah) with but it won't be in the budget for a few months yet.

[dc1rdb]

Done - it should show up in the thread at http://sdrplay.com/community/viewtopic.php?f=5&t=230 in a couple of hours.

[ghost]

Please let me know when you checked in SoapySDRplay support si i can build
and test the SDRplay supported version of CubicSDR.

Ton.

On Wed, Sep 16, 2015 at 5:04 PM, Charles J. Cliffe <[email protected]

wrote:

@dc1rdb https://github.com/dc1rdb cool -- you might want to direct them
here: https://github.com/pothosware/SoapySDRPlay as I've also partly
implemented it myself last night in a fork here:
https://github.com/cjcliffe/SoapySDRPlay

I'm hoping between @Toontje https://github.com/Toontje and I we can get
it working; would love to have one to test (as I would with all the
devices, hah) with but it won't be in the budget for a few months yet.

—
Reply to this email directly or view it on GitHub
#144 (comment).

[cjcliffe]

@Toontje we'll need to do a bit of testing prior to CubicSDR to verify the implementation. I'll put the steps here and we'll make sure SoapySDR and SoapySDRPlay are building properly and you should be able to give me some immediate results.

First up, installing SoapySDR:

git clone https://github.com/pothosware/SoapySDR.git
cd SoapySDR
mkdir build
cd build
cmake ..
make -j4
sudo make install
sudo ldconfig #only needed on linux systems
SoapySDRUtil --info

Next get OSX mir_sdr from sdrplay (requires you fill out a form) at http://www.sdrplay.com/mac.html and install it like this:

mkdir mir_sdr
tar -xvzf ~/Downloads/mir_sdr_api_MacOSX_1.2.tar.gz

    x ./2015_03_29_mac/
    x ./2015_03_29_mac/libmir_sdr.so
    x ./2015_03_29_mac/._mir_sdr.h 
    x ./2015_03_29_mac/mir_sdr.h

sudo cp 2015_03_29_mac/libmir_sdr.so /usr/lib/
sudo cp 2015_03_29_mac/mir_sdr.h /usr/include/

Additionally I was missing /usr/local/lib/libusb-1.0.0.dylib which libmir_sdr was expecting to find; so I had to copy the MacPorts version I had installed to there:

sudo port install libusb
    .. installing ..
sudo cp /opt/local/lib/libusb-1.0.* /usr/local/lib/

Then install the SoapySDRPlay module from my fork:

git clone https://github.com/cjcliffe/SoapySDRPlay.git
cd SoapySDRPlay
mkdir build
cd build
cmake ..
make
sudo make install

If all went well, test to see if you can get a response from the SDRPlay: (this is my current status with no device connected)

cjmacbook:build ccliffe$ SoapySDRUtil --probe="driver=sdrplay"
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device driver=sdrplay
mir_sdr_Init: starting hardware initialization
mir_sdr_Init: gR=40dB fs=2.048MHz rf=222.064MHz bw=1.536MHz if=0.000MHz

mir_sdr_2500_Init(2)

mir_sdr_usb_Init()

mir_sdr_usb_USB DLL: Revision 0.1.1

mir_sdr_usb_Init: Timeout expired/failed to establish connection with the device

mir_sdr_2500_Init: mir_sdr_usb_Init() failed
mir_sdr_Init: mir_sdr_2500_Init() Error 1

----------------------------------------------------
-- Device identification
----------------------------------------------------
  driver=SDRPlay
  hardware=SDRPlay
  mir_sdr_version=1.100000

----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
  Channels: 1 Rx, 0 Tx
  Timestamps: NO

----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
  Full-duplex: YES
  Antennas: RX
  Corrections: DC removal
  Full gain range: [0, 0] dB
  Full freq range: [0.1, 2000] MHz
    RF freq range: [0.1, 2000] MHz
  Sample rates: [0.2, 8] MHz
  Filter bandwidths: [0.2, 8] MHz

[cjcliffe]

@Toontje the build that should eventually work with this is on OSX now up at: https://github.com/cjcliffe/CubicSDR/releases/tag/0.1.7-soapyexperiment1

[cjcliffe]

@Toontje @dc1rdb -- it's possible that https://github.com/cjcliffe/SoapySDRPlay now works; but I feel there may be some order-of-operations issues still to deal with. Let me know when you've had a chance to review everything 👍

[dc1rdb]

Initial test after performing above mentioned installs, SDRPlay hardware connected:

See here: https://gist.github.com/cjcliffe/6adadcbbbb1a7ba9c713

[dc1rdb]

CubicSDR 0.1.7 crashes about 1 second after painting the UI. I sent the detailed report by mail.

[cjcliffe]

Yeah I think it's implied by the example code (but not stated anywhere) that there's a specific order of operations to setting the parameters / checking flags after the stream has opened which I have not followed. I'll do some reworking so that everything is cached and only initialized when the stream starts; if that doesn't do it then we'll get into more detailed logging.

[cjcliffe]

@dc1rdb can you try running CubicSDR 0.1.7 like this?

cjmacbook:ccliffe$ /Applications/CubicSDR.app/Contents/MacOS/CubicSDR

It should produce a log to the terminal with all the startup details. Note you can post logs here easier by using three backquotes `to start` and stop a code block.

Replace /Applications/ with wherever you have v0.1.7 located.

Edit: doing some debugging with fake input, there's some obvious issues so a commit will be on the way.

https://github.com/cjcliffe/SoapySDRPlay has been updated with fixes for several errors, some pretty obvious :)

You can update existing with:

cd SoapySDRPlay
git fetch -p
git pull
cd build
make clean
make
sudo make install

[dc1rdb]

Success! Works like a charm. Here comes the log, I captured a couple of frequency changes, too.

See here: https://gist.github.com/cjcliffe/9f4ed1e2098a0bbd0a53

[dc1rdb]

I noticed that the driver seems to be performing a firmware update:

Opened device with idVendor = 0x1df7 idProduct = 0x2500 fwVersion = 0x0200

Msg: libusb_get_configuration() = 0

mir_sdr_2500 attachFn(hnd, 0x0200, 1, 0)
mir_sdr_2500_Init: revisionId = 0x0200, doing FW update
fwDownload: FW image size = 6008
mir_sdr_usb_WaitForReattach()
mir_sdr_2500 detachFn()
mir_sdr_usb_Uninit()

Releasing interface in mir_sdr_usb_Uninit()

Closing driver handle in mir_sdr_usb_Uninit()

Closed driver handle in mir_sdr_usb_Uninit()

Closed eventThread in mir_sdr_usb_Uninit()

Exited libusb in mir_sdr_usb_Uninit()

mir_sdr_usb_Uninit() completed

mir_sdr_usb_Init()

mir_sdr_usb_USB DLL: Revision 0.1.1

Opened device with idVendor = 0x1df7 idProduct = 0x2500 fwVersion = 0x0206

It does not seem to be persistent, i.e. when I disconnect the SDRPlay from USB and reconnect it, the firware version goes back to 0x0200. Any ideas?

[SDRplay]

It's a soft update - it will perform the update every time the device is reconnected. It happens on Windows as well you just don't see all the debug information. If you need any help from us on the API usage please let us know.

SDRplay Support

[cjcliffe]

@dc1rdb -- that's great news! Now all I need you to do is try increasing bandwidths incrementally and see what does/doesn't work and paste some activity of it from the logs -- the manual bandwidth entry option in 0.1.7 should now let you take it beyond 3.2M :)

[cjcliffe]

@SDRplay thanks for joining the issue! I'm sure I'll have more questions for you as I start to finish up the details but a few come to mind right away:

• Is there a way to make the IF bandwidth setting automatic? (It looks like I have to adjust it along with the sample rate -- or no?)
• Is there an automatic gain control option? The example code seems to be using an undefined function doAgc() and managing it itself.
• The API docs say "The data is returned as 16bit left justified integers" but the ADC is 12 bits -- is the data stream normalized to 16 bits as +/-32767 or 12 bit range of +/-2048 like BladeRF?

Cheers,
-CJ

[dc1rdb]

Here you go:

Demodulator worker thread started..
Set sample rate: 2560000
[DEBUG] Set sample rate
mir_sdr_SetFs: Sample Freq requested 2559999.942780
mir_sdr_2500_SetRegister(0x04, 0x07ae14)

mir_sdr_2500_SetRegister(0x03, 0x010a1f)

mir_sdr_SetFs: Fs->FsNomHz+dFsHz=2560000.0+0.0Hz=2559999.9Hz FsToggle->1
[DEBUG] Changed center frequency
mir_sdr_2500_SetRegister(0x09, 0x000003)

mir_sdr_2500_SetRegister(0x09, 0x217d02)

mir_sdr_SetRf: f->101000000.000Hz (int=21 frac=7d0 afc=0) fSynth:3232000000.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=101000000.0+0.0+0.0Hz+0.0Hz=101000000.0Hz RfToggle->0
mir_sdr_ReadPacket: Fs update confirmed: Fs=2559999.9Hz FsToggle=1
mir_sdr_ReadPacket: Rf update confirmed: Rf=101000000.0Hz RfToggle=0
Set sample rate: 2880000
[DEBUG] Set sample rate
mir_sdr_SetFs: Sample Freq requested 2879999.995232
mir_sdr_2500_SetRegister(0x04, 0x00a3d7)

mir_sdr_2500_SetRegister(0x03, 0x010b9f)

mir_sdr_SetFs: Fs->FsNomHz+dFsHz=2880000.0+0.0Hz=2880000.0Hz FsToggle->0
[DEBUG] Changed center frequency
mir_sdr_2500_SetRegister(0x09, 0x000003)

mir_sdr_2500_SetRegister(0x09, 0x217d02)

mir_sdr_SetRf: f->101000000.000Hz (int=21 frac=7d0 afc=0) fSynth:3232000000.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=101000000.0+0.0+0.0Hz+0.0Hz=101000000.0Hz RfToggle->1
mir_sdr_ReadPacket: Fs update confirmed: Fs=2880000.0Hz FsToggle=0
mir_sdr_ReadPacket: Rf update confirmed: Rf=101000000.0Hz RfToggle=1
[DEBUG] Changed center frequency
mir_sdr_2500_SetRegister(0x09, 0x006cc3)

mir_sdr_2500_SetRegister(0x09, 0x217cb2)

mir_sdr_SetRf: f->100995425.000Hz (int=21 frac=7cb afc=6cc) fSynth:3231853600.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=100995425.0+0.0+0.0Hz+0.0Hz=100995425.0Hz RfToggle->0
[DEBUG] Changed center frequency
mir_sdr_SetRf: ERROR: previous Rf update not recieved (or timed out)
mir_sdr_ReadPacket: Rf update confirmed: Rf=100995425.0Hz RfToggle=0
[DEBUG] Changed center frequency
mir_sdr_2500_SetRegister(0x09, 0x006cc3)

mir_sdr_2500_SetRegister(0x09, 0x217cb2)

mir_sdr_SetRf: f->100995425.000Hz (int=21 frac=7cb afc=6cc) fSynth:3231853600.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=100995425.0+0.0+0.0Hz+0.0Hz=100995425.0Hz RfToggle->1
mir_sdr_ReadPacket: Rf update confirmed: Rf=100995425.0Hz RfToggle=1
Set sample rate: 3200000
[DEBUG] Set sample rate
mir_sdr_SetFs: Sample Freq requested 3200000.047684
mir_sdr_2500_SetRegister(0x04, 0x09999a)

mir_sdr_2500_SetRegister(0x03, 0x010c9f)

mir_sdr_SetFs: Fs->FsNomHz+dFsHz=3200000.0+0.0Hz=3200000.0Hz FsToggle->1
[DEBUG] Changed center frequency
mir_sdr_2500_SetRegister(0x09, 0x006cc3)

mir_sdr_2500_SetRegister(0x09, 0x217cb2)

mir_sdr_SetRf: f->100995425.000Hz (int=21 frac=7cb afc=6cc) fSynth:3231853600.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=100995425.0+0.0+0.0Hz+0.0Hz=100995425.0Hz RfToggle->0
mir_sdr_ReadPacket: Fs update confirmed: Fs=3200000.0Hz FsToggle=1
mir_sdr_ReadPacket: Rf update confirmed: Rf=100995425.0Hz RfToggle=0
Set sample rate: 2400000
[DEBUG] Set sample rate
mir_sdr_SetFs: Sample Freq requested 2399999.976158
mir_sdr_2500_SetRegister(0x04, 0x033333)

mir_sdr_2500_SetRegister(0x03, 0x01099f)

mir_sdr_SetFs: Fs->FsNomHz+dFsHz=2400000.0+0.0Hz=2400000.0Hz FsToggle->0
[DEBUG] Changed center frequency
mir_sdr_2500_SetRegister(0x09, 0x006cc3)

mir_sdr_2500_SetRegister(0x09, 0x217cb2)

mir_sdr_SetRf: f->100995425.000Hz (int=21 frac=7cb afc=6cc) fSynth:3231853600.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=100995425.0+0.0+0.0Hz+0.0Hz=100995425.0Hz RfToggle->1
mir_sdr_ReadPacket: Fs update confirmed: Fs=2400000.0Hz FsToggle=0
mir_sdr_ReadPacket: Rf update confirmed: Rf=100995425.0Hz RfToggle=1

I noticed that at 2.88M and 3.2M the audio signal becomes increasingly choppy even though the CPU load remaines pretty much the same. Beyond 3.2M, it becomes pretty much unusable.

[dc1rdb]

Changing the input bandwidth also seems to change the tone pitch of the audio signal, i.e. higher input bandwidth results in higher pitch and vice versa.

[cjcliffe]

Hmm, sounds like it's possible that it's not actually changing rate or propagating the rate change to CubicSDR; I'll investigate this evening here and see if I can spot the issue.

[cjcliffe]

@dc1rdb I've made some updates to my SoapySDRPlay fork that re-locates the center and rate updates into the stream process and does some flag checking to log if the updates succeeded. Please update and give it another try.

[ghost]

I have the same issue as @dc1rdb where CubicSDR starts and closes after less then 1 second.
Starting it from the command line makes the icon bounce in the dock but no interface shows up.
After starting a second time the interface shows up and closes again after one second. Here is the console log:

See here: https://gist.github.com/cjcliffe/50551d25f65b73e2d7db

[SDRplay]

There is no built-in AGC - our website has a technical note to explain the gain control system (http://www.sdrplay.com/docs/SDRplay_AGC_technote_r2p2.pdf)
There is also no automatic IF bandwidth setting.
I will get clarification on the data stream for you.

[dc1rdb]

Ok, just updated to the current SoapySDRPlay. Gone are the mentioned tone pitch changes, but the choppy audio at 2.88M and higher is still present. Here are the respective parts of the log:

See here: https://gist.github.com/cjcliffe/4dfc7105ef70a44c5f0c

[cjcliffe]

@dc1rdb hmm, I should have seen some:

[DEBUG] stream numPackets*sps:

entries in there; can you see if you can locate? I'm pretty sure the remaining issue is just the buffer size which I may need to handle better on the CubicSDR side of things. I'm going to have CubicSDR dynamically adjust the buffer size so that the processing rate stays constant -- it's most likely just trying to jam too many requests into the pipe that could be done in much larger pieces.

I think I can figure out the last bits of the AGC now from the flowchart in the link provided by @SDRplay -- and the IF bandwidth adjustment shouldn't be too hard to implement with some range checks.

[ghost]

I installed the latest API to get Pothos working and for the sake of it re-built SoapySDR, SoapySDRplay and CubicSDR again and i now get OpenGL errors.

mir_sdr_ReadPacket: Gain update confirmed: Gr=37dB GrToggle=0 gset=0x20d
[DEBUG] Gain change acknowledged from device. packet: 104
mir_sdr_ResetUpdateFlags: resetGainUpdate=1 resetRfUpdate=0 resetFsUpdate=0
[DEBUG] AGC: Gain reduction changed from 37 to 38
mir_sdr_SetGr: GR->38[14,24,0,0] gRset->0x20E DCCALmode=1 DCCALspd=1 GrToggle->0
mir_sdr_ReadPacket: Gain update confirmed: Gr=38dB GrToggle=0 gset=0x20d
[DEBUG] Gain change acknowledged from device. packet: 0
mir_sdr_ResetUpdateFlags: resetGainUpdate=1 resetRfUpdate=0 resetFsUpdate=0
OpenGL Error 1281
[DEBUG] AGC: Gain reduction changed from 38 to 37
mir_sdr_SetGr: GR->37[13,24,0,0] gRset->0x20D DCCALmode=1 DCCALspd=1 GrToggle->0
OpenGL Error 1281
mir_sdr_ReadPacket: Gain update confirmed: Gr=37dB GrToggle=0 gset=0x20d
[DEBUG] Gain change acknowledged from device. packet: 137
mir_sdr_ResetUpdateFlags: resetGainUpdate=1 resetRfUpdate=0 resetFsUpdate=0
OpenGL Error 1281
[DEBUG] AGC: Gain reduction changed from 37 to 38
mir_sdr_SetGr: GR->38[14,24,0,0] gRset->0x20E DCCALmode=1 DCCALspd=1 GrToggle->0
mir_sdr_ReadPacket: Gain update confirmed: Gr=38dB GrToggle=0 gset=0x20d
[DEBUG] Gain change acknowledged from device. packet: 0
mir_sdr_ResetUpdateFlags: resetGainUpdate=1 resetRfUpdate=0 resetFsUpdate=0
OpenGL Error 1281
[DEBUG] AGC: Gain reduction changed from 38 to 37
mir_sdr_SetGr: GR->37[13,24,0,0] gRset->0x20D DCCALmode=1 DCCALspd=1 GrToggle->0
OpenGL Error 1281
mir_sdr_ReadPacket: Gain update confirmed: Gr=37dB GrToggle=0 gset=0x20d
[DEBUG] Gain change acknowledged from device. packet: 189
mir_sdr_ResetUpdateFlags: resetGainUpdate=1 resetRfUpdate=0 resetFsUpdate=0
OpenGL Error 1281
OpenGL Error 1281
OpenGL Error 1281

[cjcliffe]

@dc1rdb @SDRplay If you're running from the latest .DMG it packages it's own libSoapySDR via cpack automatically from my local 0.3.0 build. Do you need an 0.4.0 build? I've been using the 0.3 "release" version with bundles.

Edit: I see on Facebook now that people are having success; I'll leave it as is for the moment :)

@Toontje I don't see the OpenGL errors here; but I'll try it in my Ubuntu VM -- that's where they usually show for me if it's a problem.

[cjcliffe]

@Toontje I think I see what's going on from the log you e-mailed me.. the Waterfall update routine has changed.. I'll make an adjustment to fortify the thread access and have you pull an update to confirm.

[cjcliffe]

@Toontje pushed an update for the waterfall changes; should be more thread-safe now; let me know if that clears up any of the OpenGL errors and waterfall 'OnPaint' crashes.

[dc1rdb]

@SDRplay Your hosted version of CubicSDR http://sdrplay.com/software/CubicSDR-0.1.11-Darwin.dmg is different to the original version https://github.com/cjcliffe/CubicSDR/releases/download/v0.1.11/CubicSDR-0.1.11-Darwin.dmg
Maybe that is on of the reasons for the experienced problems.

I just followed the installation instructions on https://github.com/cjcliffe/CubicSDR/releases/tag/v0.1.11 which resulted in a perfectly working configuration on Mac OS 10.9.5 Mavericks.

[dc1rdb]

@SDRplay Some additional observations: I just wiped my entire /usr/local/ folder and reinstalled SDRplay_RSP_API_Installer_1.9.2.pkg together with CubicSDR hosted at SDRPLay.com (http://www.sdrplay.com/software/CubicSDR-0.1.11-Darwin.dmg).
The resulting combination works fine on Mac OS 10.9.5.
There seems to be an incompatibility between SDRplay_RSP_API_Installer_1.9.2 and the "original" CubicSDR hosted at github (https://github.com/cjcliffe/CubicSDR/releases/download/v0.1.11/CubicSDR-0.1.11-Darwin.dmg).
Hope this helps clarifying the situation.

[cjcliffe]

@dc1rdb pretty sure this is just a Soapy version mismatch; I've been building with 0.3.0 since that's what the pothos windows binaries were at.

[ghost]

Just built CubicSDR from source and i don't get the OpenGL errors anymore, but also i don't get a waterfall.

[cjcliffe]

@Toontje That's kinda strange considering the one in the top left is still working.. I may have to make a special debug branch for you -- can you give me the specs for your graphics card in "About This Mac"?

Edit: Have you restarted recently? it's possible the GPU driver tanked and doesn't have enough resources for the waterfall texture..

Also while tinkering with Qt installations did it have you install anything OpenGL related? It's possible a library is conflicting with wxWidgets.. Try building the static wxWidgets from the Wiki and use that during CMake as the wxWidgets path: https://github.com/cjcliffe/CubicSDR/wiki/Build-OSX---MacPorts-.App

[cjcliffe]

@Toontje on second thought I pushed a quick revert of my removal of the DEFAULT_SAMPLE_RATE in some places -- that initially caused an immediate waterfall failure for me before and you might just be racing a bit faster or slower than my system and hitting the issue on another one I changed.

Those should all be back to defaults now and hopefully just something in the waterfall chain was getting badly initialized because of the zerod value.

[ghost]

Graphics card: Intel HD Graphics 3000 512 MB
Warnings during building (don't know if they are related):

See: https://gist.github.com/cjcliffe/9b45d9e7aa460fc0103f

[cjcliffe]

@Toontje going to tweak it so that only the waterfall thread can update the waterfall texture; I think this is still a graphics driver issue with the recent waterfall changes at the moment.

[cjcliffe]

@Toontje -- I pushed an update to sopaysdr-support that should fix any conflicts in OnPaint() and processInput() in the waterfall which I keep seeing in the crash traces.

[ghost]

I just built the latest SoapySDR, SoapySDRplay and CubicSDR 0.1.12 and apart from the occasional seg fault all is working again.

[ghost]

Seg fault: https://www.dropbox.com/s/ofx85t93eez7ht0/segfault.mov?dl=0
It usually happens either directly after launching or on device detection. Once the SDRplay is detected all runs fine.

[cjcliffe]

@Toontje that's still failing on the new waterfall memcpy code.. I must still be doing something funky there I'm going to have to take another look!

[cjcliffe]

@Toontje I've committed some more fixes to keep the gl context happy on waterfall panel init; let me know if that stabilizes anything.

[ghost]

First impression is good. No segfaults, all interface elements preset and working. Won't have a lot of time to test today. Travelling and all. I will keep you informed how it's going, but all is looking good so far.

[cjcliffe]

@Toontje sounds good; I think we've got it -- it does sort of a funky mutex walk between the waterfall data and waterfall render now and I can't theorize how the texture could end up badly initialized any more.

Thanks for your help! You're doing wonders for the Facebook crew as you have the perfect configuration for maximum GPU driver havoc 👍

[ghost]

And i thought i was just a pain in the b*tt for you. ;-)

[ghost]

Scope display gone.

[cjcliffe]

@Toontje Hmm, yeah that thing acts up in windows all the time -- I think I have an uninitialized variable somewhere.. Going to take a look at it now.

[cjcliffe]

@Toontje spectrum/scope and some additional crash fixes are now committed; let me know how you make out.

[ghost]

All looking good so far.
Don't know what you did, but i hardly get any segfault anymore.

[cjcliffe]

Good news that @jazzkutya has implemented Low-IF modes for SoapySDRPlay -- pull the latest updates and you'll now get 222KHz, 333KHz, 428KHz, 500KHz, 571KHz, 750KHz, 875Khz and 1MHz input rates in CubicSDR!

[jazzkutya]

actually only 500khz, 1Mhz and 2Mhz are Low IF modes, all others are zero-IF modes.

[cjcliffe]

Thanks for your help on this issue everyone; going to wrap it up as it's getting slow to load ;)

Feel free to create new issues related to SDRPlay and CubicSDR here or use https://github.com/pothosware/SoapySDRPlay/issues for SoapySDRPlay specific issues.

I'm going to shift on-going SoapySDR implementation related discussion over to #64

Cheers!