search

cjcliffe / CubicSDR

Cross-Platform Software-Defined Radio Application
http://www.cubicsdr.com
GNU General Public License v2.0
2.03k stars 249 forks source link

SoapySDRPlay support #144

Closed ghost closed 8 years ago

ghost commented 8 years ago

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): https://github.com/cjcliffe/CubicSDR/issues/144#issuecomment-140906180 Update instructions: https://github.com/cjcliffe/CubicSDR/issues/144#issuecomment-141237861

dc1rdb commented 8 years ago

Fully supporting this request and willing to help with testing!

cjcliffe commented 8 years ago

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 commented 8 years ago

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

dc1rdb commented 8 years ago

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

cjcliffe commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 <notifications@github.com

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 https://github.com/cjcliffe/CubicSDR/issues/144#issuecomment-140769013.

cjcliffe commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 :+1:

dc1rdb commented 8 years ago

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

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

dc1rdb commented 8 years ago

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

cjcliffe commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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:

Cheers, -CJ

dc1rdb commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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.

SDRplay commented 8 years ago

data stream is +/- 32767

cjcliffe commented 8 years ago

@SDRplay perfect thanks; that's what I've used as the divisor for float conversion.

dc1rdb commented 8 years ago

Sorry, my mistake - accidentally cut that part out. There is one entry:

[DEBUG] stream sps: 336
[DEBUG] stream numPackets*sps: 15120
cjcliffe commented 8 years ago

Hmm, yeah that seems really low -- I use 16384*6 = 98304 samples per buffer for the RTL-SDR device. I'll make some adjustments and see if I can add an ideal numPackets size calculator.

cjcliffe commented 8 years ago

@dc1rdb I've updated my fork of SoapySDRPlay so that it should auto-adjust the IF bandwidth ceiling to fit the sample rate -- it also now sets the numPackets to match a 30 buffers / sec default based on rate.

Hopefully that will let you adjust the bandwidth beyond >2.88 without chopping; if there's still issues I may need to drop a few timers with logs in there to figure out where we're under/overflowing.

cjcliffe commented 8 years ago

@Toontje make sure you've updated to the latest SoapySDRPlay from my fork; you can find the instructions to update your copy in this comment: https://github.com/cjcliffe/CubicSDR/issues/144#issuecomment-141237861 the immediate crash should have been resolved by now.

dc1rdb commented 8 years ago

This is really looking good now, Charles! I went up to 5M bandwidth with no negative effects. I also noticed a decrease in CPU load compared to the previous version, e.g. from 45% to 35% with 2.4M decoding FM.

[DEBUG] Set numPackets to 239
[DEBUG] stream sps: 336
[DEBUG] stream numPackets*sps: 80304

One strange observation: going up from 2.56M to 2.88M results in audio tone pitch again. Continuing to 3.2M brings tone pitch back to normal. Going down from 3.2M to 2.88M does not change tone pitch.

See here: https://gist.github.com/cjcliffe/c259ce85f529c55605fc

Hope this helps. Let me know if you need more details. It's amazing how well this module is evolving without you having access to the hardware. Many thanks again!

dc1rdb commented 8 years ago

CubicSDR just terminated after a lot of bandwidth changes in rapid succession:

Set sample rate: 1500000
mir_sdr_SetFs: Sample Freq requested 1500000.000000
mir_sdr_2500_SetRegister(0x04, 0x000000)

mir_sdr_2500_SetRegister(0x03, 0x011497)

mir_sdr_SetFs: Fs->FsNomHz+dFsHz=1500000.0+0.0Hz=1500000.0Hz FsToggle->0
[DEBUG] Changed sample rate
mir_sdr_2500_SetRegister(0x09, 0x0052f3)

mir_sdr_2500_SetRegister(0x09, 0x2191d2)

mir_sdr_SetRf: f->101333324.000Hz (int=21 frac=91d afc=52f) fSynth:3242666368.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=101333324.0+0.0+0.0Hz+0.0Hz=101333324.0Hz RfToggle->1
[DEBUG] Changed center frequency
[DEBUG] Bandwidth crossed boundary and needed adjustment; resetting device..
mir_sdr_2500_StopRx()
mir_sdr_2500_StreamUninit()
mir_sdr_usb_StreamUninit(1)

mir_sdr_2500_SetRegister(0x08, 0x006280)

mir_sdr_2500_Uninit()

mir_sdr_2500_SetRegister(0x09, 0x063000)

mir_sdr_2500_SetRegister(0x09, 0x00800e)

mir_sdr_2500_SetRegister(0x03, 0x091300)

mir_sdr_2500_SetRegister(0x05, 0x000004)

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_Init: starting hardware initialization
mir_sdr_Init: gR=40dB fs=1.500MHz rf=101.333MHz bw=1.536MHz if=0.000MHz

mir_sdr_Init: Fs=1500000Hz is too low for Lif=0 and Bw=1536000 - minimum required 1536000
[DEBUG] stream re-init sps: 252
[DEBUG] stream re-init numPackets*sps: 50148
libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: Error resetting mir_sdr interface for bandwidth change.
Abort
SDRplay commented 8 years ago

I would change the minimum allowed sample rate to 2MHz

ghost commented 8 years ago

Ok, All seem to be working except the fact that i don't receive anything. Maybe a dumb questions, but are you already pulling the data in from the SDRplay? It looks like the SDRplay is working fine, but CubicSDR is not receiving any data from the SDRplay.

Log here: https://www.dropbox.com/s/clca8xvrtozglms/sdrplay.log?dl=0

dc1rdb commented 8 years ago

@Toontje, I have the following configuration fully working on my Mac:

cjcliffe commented 8 years ago

@dc1rdb thanks for the help -- it does look like there's something unstable in the bandwidth updates and CubicSDR itself will need some buffer adjustments to match better too -- I'll analyze the logs and figure out what's going on later today.

@SDRplay Thanks; I'll set that as the minimum range value.

@Toontje you should be seeing something I would think according to @dc1rdb's results -- if you're seeing decibel scale lines change and a flat spectrum in the spectrum view after startup then it's receiving data; otherwise it should be stalled. Maybe try with just SDRPlay connected? Will review the log some more later today.

The pitch issues I think I just need to re-init the SDRPlay each time it changes and the weirdness should go away.

One thing I noted you may want to re-run cmake with:

cd SoapySDRPlay/build/
cmake ../ -DCMAKE_BUILD_TYPE=Release

So that optimization is enabled; otherwise it may get a bit sluggish regardless.

Cheers!

dc1rdb commented 8 years ago 
cd SoapySDRPlay/build/
cmake ../ -DCMAKE_BUILD_TYPE=Release

Thanks for the hint - this reduces my CPU load by another 5%!

ghost commented 8 years ago

Ok, updated SoapySDR and SoapySDRplay to the latest commit and built SoapySDRplay with Build-Type=Release as mentioned above and all is working.

cjcliffe commented 8 years ago

@dc1rdb @Toontje excellent, sounds like we're making progress!

If you update your SoapySDRPlay builds to the latest commit there's a couple updates:

ghost commented 8 years ago

Can the SDRplay handle 12MHz sample rate?

I will update SoapySDRplay.

On Sun, Sep 20, 2015 at 7:08 PM, Charles J. Cliffe <notifications@github.com

wrote:

@dc1rdb https://github.com/dc1rdb @Toontje https://github.com/Toontje excellent, sounds like we're making progress!

If you update your SoapySDRPlay builds to the latest commit there's a couple updates:

  • Changing sample rate will now re-init each time to hopefully prevent pitch weirdness
  • Any incoming samples that don't match the current center frequency or sample rate will now be skipped so there's no lingering samples going to CubicSDR with mismatched contents
  • The minimum sample rate is now 2Mhz (previously 200khz) and maximum is 12Mhz (previously 8Mhz)

— Reply to this email directly or view it on GitHub https://github.com/cjcliffe/CubicSDR/issues/144#issuecomment-141811368.

SDRplay commented 8 years ago

Yes, max sample rate is 12MHz

dc1rdb commented 8 years ago

Just tested latest commit 1260d3fd58 - looking really good! Pitch weirdness is completely gone. Sample rates up to 12 MHz are selectable. However, on my machine 11M is the practical limit, bringing CPU load to its maximum.

Selecting a sample rate <2M crashes CubicSDR:

Set sample rate: 1500000
mir_sdr_SetFs: Sample Freq requested 1500000.000000
mir_sdr_2500_SetRegister(0x04, 0x000000)

mir_sdr_2500_SetRegister(0x03, 0x01161f)

mir_sdr_SetFs: Fs->FsNomHz+dFsHz=1500000.0+0.0Hz=1500000.0Hz FsToggle->1
[DEBUG] Changed sample rate
mir_sdr_2500_SetRegister(0x09, 0x00f7c3)

mir_sdr_2500_SetRegister(0x09, 0x233f02)

mir_sdr_SetRf: f->106008968.000Hz (int=23 frac=3f0 afc=f7c) fSynth:3392286976.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=106008968.0+0.0+0.0Hz+0.0Hz=106008968.0Hz RfToggle->1
[DEBUG] Changed center frequency
mir_sdr_2500_StopRx()
mir_sdr_2500_StreamUninit()
mir_sdr_usb_StreamUninit(1)

mir_sdr_2500_SetRegister(0x08, 0x006280)

mir_sdr_2500_Uninit()

mir_sdr_2500_SetRegister(0x09, 0x063000)

mir_sdr_2500_SetRegister(0x09, 0x00800e)

mir_sdr_2500_SetRegister(0x03, 0x091300)

mir_sdr_2500_SetRegister(0x05, 0x000004)

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_Init: starting hardware initialization
mir_sdr_Init: gR=40dB fs=1.500MHz rf=106.009MHz bw=1.536MHz if=0.000MHz

mir_sdr_Init: Fs=1500000Hz is too low for Lif=0 and Bw=1536000 - minimum required 1536000
[DEBUG] stream re-init sps: 252
[DEBUG] stream re-init numPackets*sps: 50148
libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: Error resetting mir_sdr interface for bandwidth change.
Abort
ghost commented 8 years ago

CubicSDR crashes when "playing around" with filter width using the GUI. I admit, i push it to the limit, but that's what testing is for, no? Set sample width to 12MHz. Use the GUI to move up and down the band a few times. Use the upper left windows and change filter width. Eventually CubicSDR will close with no debug window.

Last messages i got were:

mir_sdr_2500_SetRegister(0x09, 0x15ade2)

mir_sdr_SetRf: f->131564865.000Hz (int=15 frac=ade afc=6eb) fSynth:2105037840.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=11564865.0+0.0+0.0Hz+120000000.0Hz=131564865.0Hz RfToggle->0
[DEBUG] Changed center frequency
mir_sdr_ReadPacket: Rf update confirmed: Rf=131564865.0Hz RfToggle=0
[DEBUG] Center frequency change acknowledged from device. packet: 754
mir_sdr_ResetUpdateFlags: resetGainUpdate=0 resetRfUpdate=1 resetFsUpdate=0
mir_sdr_2500_SetRegister(0x09, 0x00f5c3)

mir_sdr_2500_SetRegister(0x09, 0x15aec2)

mir_sdr_SetRf: f->131593920.000Hz (int=15 frac=aec afc=f5c) fSynth:2105502720.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=11593920.0+0.0+0.0Hz+120000000.0Hz=131593920.0Hz RfToggle->0
[DEBUG] Changed center frequency
mir_sdr_ReadPacket: Rf update confirmed: Rf=131593920.0Hz RfToggle=0
[DEBUG] Center frequency change acknowledged from device. packet: 0
mir_sdr_ResetUpdateFlags: resetGainUpdate=0 resetRfUpdate=1 resetFsUpdate=0
mir_sdr_2500_SetRegister(0x09, 0x009783)

mir_sdr_2500_SetRegister(0x09, 0x15af02)

mir_sdr_SetRf: f->131601184.000Hz (int=15 frac=af0 afc=978) fSynth:2105618944.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=11601184.0+0.0+0.0Hz+120000000.0Hz=131601184.0Hz RfToggle->0
[DEBUG] Changed center frequency
mir_sdr_ReadPacket: Rf update confirmed: Rf=131601184.0Hz RfToggle=0
[DEBUG] Center frequency change acknowledged from device. packet: 672
mir_sdr_ResetUpdateFlags: resetGainUpdate=0 resetRfUpdate=1 resetFsUpdate=0
error: msresamp2_crcf_create(), number of stages should not exceed 10
dc1rdb commented 8 years ago

Another issue (don't know if it was present on previous versions of SoapySDRPlay):

-> SDRPlay becomes "deaf", no reception anymore.

Same thing happens vice versa, i.e. switching from 6 MHz to 100 MHz.

Quitting and restarting CubicSDR does not solve the problem. Issue can only be resolved by physically unplugging and replugging SDRPlay.

cjcliffe commented 8 years ago

@dc1rdb / @Toontje wow, considering the lack of high-bandwidth limit testing and proper buffer tweaks that CubicSDR still needs to handle 11-12M I'm surprised it made it anywhere near there :)
I'll do some tweaking to the buffer management in CubicSDR so that it's not overloading the pipes with tiny fractional-time packets at high bandwidth.

<2M bandwidth should have prevented you from setting it; that's the new minimum for SoapySDRPlay module unless we add some decimation to it. I'll look into the best way to handle that at the CubicSDR and SoapySDR levels

@Toontje when the incoming sample rate vs. demodulator rate is at a factor of less than 0.0005 (i.e. 3.2M to 1.5Khz) liquid-dsp blows a sanity fuse on the decimation factor -- basically try to keep it above 5-6khz at > 2.88M bandwidth until I can either uncap it, force the minimum ratio or find a workaround.

@dc1rdb Not sure about the "deaf" problem -- most likely I've overlooked something that gets reset on the device during a session load. Does it happen when:

Also is there anything strange in the log after it happens?

ghost commented 8 years ago

I have the same issue as @dc1rdb when starting CubicSDR. No reception. I usually change the center frequency and filter bandwidth by click, hold and moving the spectrum display. Log here: https://www.dropbox.com/s/clca8xvrtozglms/sdrplay.log?dl=0 And yes, unplugging and re-plugging the device solves the problem.

EDIT: Unplugging and re-plugging the device solves the problem SOMETIMES. EDIT2: In fact, i cannot get my SDRplay to receive anymore unless i connect it to a Windows SDR program first. I guess these programs initialise or reset the device.

dc1rdb commented 8 years ago

To answer your questions:

Manually changing the frequency between 100MHz and 6MHz (hover demod and spacebar) --> deaf Going to 6Mhz then using the "Reset Session" option --> "Reset Session" has no effect Holding shift and pressing left/right arrow to move frequencies quickly --> deaf

Nothing strange in the log, either:

mir_sdr_SetRf: f->100000000.000Hz (int=21 frac=3e8 afc=0) fSynth:3200000000.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=100000000.0+0.0+0.0Hz+0.0Hz=100000000.0Hz RfToggle->1
mir_sdr_2500_SetRegister(0x09, 0x032101)

mir_sdr_SetGr: GR->40[16,24,0,0] gRset->0x210 DCCALmode=4 DCCALspd=1 GrToggle->1
setToggleStates: initialising sampNum=0x00020596, gainSetting=0x210, FsToggle=0, RfToggle=0, GrToggle=0
setToggleStates: initialising Fs=2399999.976, Rf=100000000.000, Gr=40
[DEBUG] Set numPackets to 239
[DEBUG] stream sps: 336
[DEBUG] stream numPackets*sps: 80304
 Stereo Disabled
Audio thread initializing..
Demodulator thread started..
Initialized demodulator stack size of 2048000
Audio thread started.
Audio thread initializing..
Demodulator preprocessor thread started..
Demodulator worker thread started..
Audio thread started.
mir_sdr_2500_SetRegister(0x09, 0x000003)

mir_sdr_2500_SetRegister(0x09, 0x020002)

mir_sdr_SetRf: f->6000000.000Hz (int=2 frac=0 afc=0) fSynth:192000000.000
mir_sdr_SetRf: Rf->RfNomHz+dRfHz+LifHz+Lif1Hz=6000000.0+0.0+0.0Hz+0.0Hz=6000000.0Hz RfToggle->1
[DEBUG] Changed center frequency
mir_sdr_ReadPacket: Rf update confirmed: Rf=6000000.0Hz RfToggle=1
[DEBUG] Center frequency change acknowledged from device. packet: 105
mir_sdr_ResetUpdateFlags: resetGainUpdate=0 resetRfUpdate=1 resetFsUpdate=0

EDIT: There seems to be a boundary at 30 MHz. When going below, the unit becomes deaf and can only be brought back to life by unplugging/replugging.