FCD Pro +, Airspy, BladeRF, HackRF, RFSpace, etc. via SoapySDR

[dc1rdb]

Thanks for your great work! Using it daily on Mac OS X, running very stable.
Is there a chance to support Funcube dongle Pro+ in the future, maybe through something like gr-fcdproplus library?

[kgarrels]

Or with gr-osmosdr for many SDR?
Kai

Am 20.03.2015 um 10:17 schrieb dc1rdb [email protected]:

Thanks for your great work! Using it daily on Mac OS X, running very stable.
Is there a chance to support Funcube dongle Pro+ in the future, maybe through something like gr-fcdproplus library?

—
Reply to this email directly or view it on GitHub.

[cjcliffe]

Thanks @dc1rdb glad it's working well for you -- I'm investigating using either gr-osmosdr and/or SoapySDR at the moment which should allow for a wider range of devices. I haven't decided whether to use them completely or allow for one-off builds for specific devices -- I would like to keep a lean RTL-SDR build as an option so a few other devices might be reasonable to support that way too.

[UbhaSecurity]

gr-osmosdr would be best. Then you get hackrf etc support to.

[vsboost]

yes please, hackrf support would be great.

[dc1rdb]

I'd love to see the SDRplay RSP to be included in the list of supported devices. I could be achieved either through gr-osmosdr or maybe by using the OS X API supplied by SDRplay http://sdrplay.com/api_drivers.html
Thanks again for your excellent work!

[ghost]

+1 for gr-osmocom. You are having it as a 0.1.x milestone, can you make an estimation on the x in 0.1.x? Looking to move from rtl-sdr to SDRplay.

[cjcliffe]

I'll aim for 0.1.5 -- it'll probably be awhile before I can buy some of the other hardware for testing but I'll start by implementing it for rtl-sdr via gr-osmosdr and go from there.

[dc1rdb]

Owning FCDP+, HackRF, SDRPlay and various RTL-Dongles, I'd be happy to do some testing for you. Just let me know.

[ghost]

Same here. If we can help, just shout. After all it's us that benefit from
your efforts.

On Mon, Aug 10, 2015 at 9:56 AM, dc1rdb [email protected] wrote:

Owning FCDP+, HackRF, SDRPlay and various RTL-Dongles, I'd be happy to do
some testing for you. Just let me know.

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

[ghost]

Just a heads-up. I have the SDRplay working with gr-osmosdr on a Mac.

[cjcliffe]

@Toontje great; I'll be checking it out once I wrap up the 0.1.4 issues and testing -- I'm going to try to hook into gr-osmosdr dynamically at runtime so that it's not a requirement; it'll just ask if you want to use it on startup if available.

[cjcliffe]

Just a note I've moved the releases to minor revisions, so 0.2.0 should be considered the next "release" and 0.1.5, 0.1.6, 0.1.7, etc. will be several unannounced patch/testing releases to come before then.

[cjcliffe]

Going to try this through https://github.com/pothosware/SoapySDR SoapyOsmoSDR library, tried a few things so far and it's been smoother than using the gr-osmosdr blocks directly -- plus it looks like they support the option of full remote control of any supported device.

[cjcliffe]

Initial results looking good, just need to get a data stream now..

Loading:: configuration file '/Users/ccliffe/Library/Application Support/CubicSDR/config.xml'
API Version: v0.3.0-g56754c9d
ABI Version: v0.3-0
Install root: /usr/local
Module found: /usr/local/lib/SoapySDR/modules/libairspySupport.so
Module found: /usr/local/lib/SoapySDR/modules/libbladerfSupport.so
Module found: /usr/local/lib/SoapySDR/modules/libhackrfSupport.so
Module found: /usr/local/lib/SoapySDR/modules/librfspaceSupport.so
Module found: /usr/local/lib/SoapySDR/modules/librtlSupport.so
Loading modules... done
Available factories...airspy, bladerf, hackrf, null, rfspace, rtl, 
Found device 0
  driver = rtl
  label = Realtek RTL2838UHIDIR SN: 00000003
  rtl = 0

[vsboost]

Well done, looking forward to this.

[cjcliffe]

Have it working on Mac with SoapySDR but can't get the bundled app version to work -- I've put in an issue at SoapySDR repository for it. I'll see about getting Linux and Windows SoapySDR builds going tomorrow; should be easier since they have binary releases available too

[ghost]

Is your code ready for check in so i can build and test it? I'm really looking forward to this.

[bobobo1618]

Code is in the soapysdr-support branch and I just gave it a quick test with an RTL SDR and found that it works fine.

The HackRF driver is broken for me though: (pothosware/SoapyOsmo#1).

[cjcliffe]

@bobobo1618 Glad the RTLSDR is working; I've been able to test that one pretty thoroughly here -- unfortunate to hear the HackRF isn't right yet..

I think we might need to liberate a few more devices from OsmoSDR into SoapySDR modules to prevent the Osmo/Soapy disconnect in the future :)

[pwarren]

Have had a crack with my BladeRF, and get an error, here's the output of CubicSDR:

pwarren@hollis:~/Projects/CubicSDR/build(soapysdr-support)$ LD_LIBRARY_PATH=/home/pwarren/Projects/target/lib ./x64/CubicSDR -c tmp 
Gtk-Message: Failed to load module "canberra-gtk-module"
SoapySDR init..
    API Version: v0.3.0-g603da6be
    ABI Version: v0.3-0
    Install root: /usr/local
    Module found: /usr/local/lib/SoapySDR/modules/libairspySupport.so
    Module found: /usr/local/lib/SoapySDR/modules/libbladeRFSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/libhackrfSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/librfspaceSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/librtlSupport.so
    Loading modules... done
    Available factories...airspy, bladerf, hackrf, null, rfspace, rtl
Found device 0
  backend = libusb
  device = 0x02:0x02
  driver = bladerf
  instance = 0
  serial = aeac0204f1b6cb5e5ee83a2da689e185
Make device 0
[INFO] bladerf_open_with_devinfo()
[INFO] bladerf_get_serial() = aeac0204f1b6cb5e5ee83a2da689e185
[INFO] setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz
[INFO] setSampleRate(0, 1.000000 MHz), actual = 1.000000 MHz
  fpga_size=40
  fpga_version=0.3.4
  fw_version=1.8.0
  serial=aeac0204f1b6cb5e5ee83a2da689e185
[INFO] bladerf_close()


SDR thread initializing..
Using device #0
SDR post-processing thread started..
Spectrum visual data thread started.
Spectrum visual data thread started.
[INFO] bladerf_open_with_devinfo()
FFT visual data thread started.

Audio Device #0 PulseAudio
    Default Output? Yes
    Default Input? Yes
    Input channels: 2
    Output channels: 2
    Duplex channels: 2
    Native formats:
        16-bit signed integer.
        32-bit signed integer.
        32-bit float normalized between plus/minus 1.0.
    Supported sample rates:
        8000hz
        16000hz
        22050hz
        32000hz
        44100hz
        48000hz
        96000hz

Available vertical sync SwapInterval functions: 
    glxSwapIntervalEXT: No
    DRI2SwapInterval: No
    glxSwapIntervalMESA: No
    glxSwapIntervalSGI: No
No vertical sync swap interval functions available.
Loaded font 'Bitstream Vera Sans Mono' from '/home/pwarren/Projects/CubicSDR/build/x64/vera_sans_mono16.fnt', parsed 167 characters.
Loaded font 'Bitstream Vera Sans Mono' from '/home/pwarren/Projects/CubicSDR/build/x64/vera_sans_mono12.fnt', parsed 167 characters.
[INFO] bladerf_get_serial() = aeac0204f1b6cb5e5ee83a2da689e185
[INFO] setSampleRate(1, 1.000000 MHz), actual = 1.000000 MHz
[INFO] setSampleRate(0, 1.000000 MHz), actual = 1.000000 MHz
[INFO] setSampleRate(1, 2.400000 MHz), actual = 2.400000 MHz
[INFO @ lms.c:2226] Clamping frequency to 237500000Hz
terminate called after throwing an instance of 'std::runtime_error'
  what():  setFrequency(CORR) unknown name
Aborted

[cjcliffe]

@pwarren give the latest commit to soapysdr-support a go when you can and let me know if you're still having issues above 8Mhz -- it handles the buffer a bit differently now to try and fill it completely to match the framerate to the sample rate; it may have still been pushing too many small buffers before.

[bobobo1618]

After your patch to the HackRF driver and git pulling the latest commits, CubicSDR works at higher bandwidths but it shows a lot of weird 'buzzing' when getting it to demodulate. Also shows an insane amount of CPU utilization. Anything I can do to give you more useful info?

[cjcliffe]

@bobobo1618 hmm, does the buzzing only occur at > 8mhz bandwidths?

[bobobo1618]

Yep, it works fine at lower bandwidths (like the defaults).

[cjcliffe]

@bobobo1618 May just be high CPU usage then; there's a bunch of work to do as I've never used it past 3.2M here myself -- test hardware is on it's way though.

One thing to reduce CPU right away if you haven't tried is to make sure you run cmake for everything involved like this:

build$ cmake ../ -DCMAKE_BUILD_TYPE=Release

without "-DCMAKE_BUILD_TYPE=Release" it'll be building debug binaries which are significantly less optimized.

[bobobo1618]

I'm already running release binaries.

I can give you profiles to figure out CPU usage if you can point me to a tool that makes them in a format that's useful to you.

[cjcliffe]

@bobobo1618 I'd be grateful for some more information -- use whatever you're comfortable with; I typically use XCode for basic profiling but I've used valgrind as well.

If you just want to point out what you find (screenshots work too) instead of sending profile dumps I can work with that too.

[UbhaSecurity]

Late for the show, but.

I tried 2 different boxes and same.

ulf@hack:/src/CubicSDR/build$ cd x64/
ulf@hack:/src/CubicSDR/build/x64$ ./CubicSDR
Loading:: configuration file '/home/ulf/.CubicSDR/config.xml'
Loaded PPM for device 'Generic RTL2832U OEM :: 00000001' at 0ppm
SoapySDR init..
API Version: v0.3.0-g9671ca26
ABI Version: v0.3-0
Install root: /usr/local
Module found: /usr/local/lib/SoapySDR/modules/libhackrfSupport.so
Module found: /usr/local/lib/SoapySDR/modules/librfspaceSupport.so
Module found: /usr/local/lib/SoapySDR/modules/librtlSupport.so
Loading modules... done
Available factories...hackrf, null, rfspace, rtl
Found device 0
driver = hackrf
hackrf = 0
label = HackRF HackRF One
Make device 0
Using HackRF One with firmware git-4e98bc6
Error making device: Failed to open HackRF device (-1000) HACKRF_ERROR_LIBUSB

SDR thread initializing..
Using device #0
Spectrum visual data thread started.
Spectrum visual data thread started.
SDR post-processing thread started..
terminate called after throwing an instance of 'std::runtime_error'
what(): Failed to open HackRF device (-1000) HACKRF_ERROR_LIBUSB
Aborted

I keep on RTFM :-)

[UbhaSecurity]

I got it working with latest git off:

• Soapyapi
• Soapyhackrf module
• Cubicsdr

Seems stable at 20mhz bandwith :-D

~/src/CubicSDR/build/x64$ ./CubicSDR
Loading:: configuration file '/home/ulf/.CubicSDR/config.xml'
Loaded PPM for device 'Generic RTL2832U OEM :: 00000001' at 0ppm
SoapySDR init..
API Version: v0.3.0-g9671ca26
ABI Version: v0.3-0
Install root: /usr/local
Module found: /usr/local/lib/SoapySDR/modules/libHackRFSupport.so
Module found: /usr/local/lib/SoapySDR/modules/librtlSupport.so
Loading modules... done
Available factories...hackrf, null, rtl
Found device 0
device = HackRF One
driver = hackrf
part_id = a000cb3c005e4f54
serial = 0000000000000000457863c82f21441f
version = 2015.07.2
Make device 0
buffer size=3.750000MB
clock source=internal
part id=a000cb3c005e4f54
serial=0000000000000000457863c82f21441f
version=2015.07.2

[cjcliffe]

@UbhaSecurity that's excellent; would love to see some more high bandwidth screenshots if you could post a few :)

[bobobo1618]

Just updated my HackRF driver and the issues I was having appear to be mostly gone!

There's a lot of falloff at the ends though, this doesn't occur in Gqrx or other applications. Driver issue or Cubic issue you think?

[bobobo1618]

Actually I just started it again and the falloff at the edges wasn't there:

But I wasn't able to set the bandwidth/sample rate above 16MHz (putting in 20MHz for example resulted in CubicSDR setting it to 16MHz anyway).

[bobobo1618]

Oh and by the way, I got the bundled Mac app working (compiling, running). That may be because I have the Soapy drivers installed though. The bundle doesn't appear to have included them or anything.

[bobobo1618]

And I started it again and the falloff is back...

I figured it out though.

Steps to reproduce:

• Plug in HackRF
• Start CubicSDR
• Set bandwidth to 20MHz
• See falloff
• Close CubicSDR
• Open Gqrx
• Set bandwidth to 20MHz
• Open CubicSDR
• Set bandwidth to 20MHz
• Don't see falloff

My guess is that Gqrx is setting something on the HackRF (sample rate?) that CubicSDR isn't touching that leads to displaying this falloff.

[bobobo1618]

Have another couple of high bandwidth screenshots though:

[cjcliffe]

@bobobo1618 interesting; it's likely changing the default gain settings or something like that; I'll have the gain support in sometime this week; for now it should be switching on the AGC -- perhaps the SoapyHackRF isn't accepting that command? Either that or there's a bandwidth filter I'm not adjusting.

Thanks for the screen caps; looks like it's doing better than I had expected so far.

[bobobo1618]

Yeah, that could be it. Gqrx has the gain set a lot higher I think.

What's going on with the 16Mhz thing though? Cubic doesn't appear to be letting me set it any higher.

[cjcliffe]

@bobobo1618 I totally overlooked that it seems; was just checking the source to figure it out -- luckily I had just set the upper limit on the actual manual input dialog to 16M -- I've switched the cap to 25M now if you pull the latest update.

[bobobo1618]

Yep, that worked!

[cjcliffe]

I see @jocover has just pushed a fix that appears to address the falloff issue to SoapyHackRF: pothosware/SoapyHackRF@20228c0

[bobobo1618]

Yep, no longer need the Gqrx hack/workaround now. HackRF support seems to be working as well as RTL-SDR now :)

[UbhaSecurity]

Awsm.

Will git pull and rebuild tonight :-)

I had the same issue with max 16mhz, and gqrx to enable gain.

Wonderful work people :-)

Ulf

Den 28. sep. 2015 kl. 03.41 skrev bobobo1618 [email protected]:

Yep, no longer need the Gqrx hack/workaround now. HackRF support seems to be working as well as RTL-SDR now :)

—
Reply to this email directly or view it on GitHub.

[antigraviton]

added: #151, tried with the Airspy, at first with no joy...
reverted to firmware v1.0.0-rc5-0-g648c14f 2015-05-20, and it works, although the absence of gain controls make it unusable.
@2.5MSPS: ok (except for gain)
@10MSPS: seems ok (old hardware gives clipped sound) (except for gain issues)

Edit:
changed DEFAULT_SAMPLE_RATE to 2.5e6 (src/CubicSDRDefs.h), make
changed gain defaults in SoapyOsmo (gr-osmosdr/lib/airspy/airspy_source_c.cc), set_gain, set_mix_gain and set_if_gain. make && make install

[cjcliffe]

There's a windows build up now that includes bundled SoapySDR modules for a few devices; I'd be interested to see how it works out:

https://github.com/cjcliffe/CubicSDR/releases/tag/v0.1.15-alpha

Cheers!

[cjcliffe]

Just a note that there's new bundled SoapySDR alpha builds available for Windows and OSX:
https://github.com/cjcliffe/CubicSDR/releases/tag/0.1.16-soapysdr

Windows version currently lacks SoapyOsmo support so it won't work with AirSpy and RFSpace.

[vsboost]

Thanks Charles,

Ill test it with the HackRF tonight.

[cjcliffe]

SoapySDR support is now merged down to master so supporting any device is now technically possible; so I'm going to close this general issue for now.

Updated SoapySDR build instructions have been added to the CubicSDR Wiki for OSX, Windows and Linux plus some basic SoapySDR support module build examples/instructions.

If you have specific issues for a SoapySDR module you can find the issue tracker for them at: https://github.com/pothosware/

If you'd like to request a new Soapy[Device] module you can place an issue at https://github.com/pothosware/SoapySDR and we'll try our best to get it started.

Thanks for your support everyone!

[ghost]

Great work, well done, man!