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

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 notifications@github.com 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 https://github.com/cjcliffe/CubicSDR/issues/64#issuecomment-129346992.

[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: (https://github.com/pothosware/SoapyOsmo/issues/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 Thanks; looks like I'll have to limit the PPM correction call to RTL-SDR only or add a try/catch around that statement; I didn't realize the BladeRF would throw a runtime error on that. I'll let you know when a fixed version is in.

[cjcliffe]

@pwarren I've pushed an update to the soapysdr-support branch that should only call the PPM CORR frequency option on RTL-SDR devices -- that should prevent the BladeRF from throwing a runtime_error.

[pwarren]

@cjcliffe Yep, that's done the trick! Now have CubicSDR running with the BladeRF as a source :)

My laptop is dropping samples if I set the input bandwidth much above 8MHz. I can't see a way to set the various gain settings of the thing, but it does work!

[bobobo1618]

After the changes at https://github.com/pothosware/SoapyOsmo/issues/1 I successfully ran with HackRF as a source.

Buuuuuut, I'm getting SIGBUS and SIGSEGV errors when I set the bandwidth above ~8MHz. Is that likely to be an issue here or an issue there?

[cjcliffe]

@pwarren nice! I haven't had much chance to test it past 3.2Mhz yet but have a device en-route that will help with that.

Gain settings are next on the list; SoapySDR supplies a dynamic interface to the gain settings so I'm going to implement it such that it should work for current and future devices.

[cjcliffe]

@bobobo1618 hah, good timing; two new devices confirmed working today :)

The 8Mhz barrier is probably a device-specific issue that I might need to handle; there's no limit checks on the manual bandwidth entry or SoapySDR supplied limit values so you can easily enter a value that may explode..

I'd be interested to know just how close you can edge it above 8Mhz before it dies though :)

[bobobo1618]

I don't think it's a device limitation issue, the HackRF is more than capable of handling even 20MHz bandwidth (works in Gqrx and ShinySDR). Hell, I pushed osmocom_fft past 24MHz and it was still relatively stable.

I had it sitting right on top of 8MHz with CubicSDR and it maintained that for a few seconds before it segfaulted. I'll see if the SoapyOsmo guys have any clues because it looks like it may be on their end:

Process 24928 stopped
* thread #10: tid = 0x22e75b, 0x0000000107c4a83c libhackrfSupport.so`hackrf_source_c::work(int, std::__1::vector<void const*, std::__1::allocator<void const*> >&, std::__1::vector<void*, std::__1::allocator<void*> >&) + 476, stop reason = EXC_BAD_ACCESS (code=1, address=0x1126fe000)
    frame #0: 0x0000000107c4a83c libhackrfSupport.so`hackrf_source_c::work(int, std::__1::vector<void const*, std::__1::allocator<void const*> >&, std::__1::vector<void*, std::__1::allocator<void*> >&) + 476
libhackrfSupport.so`hackrf_source_c::work:
->  0x107c4a83c <+476>: movq   %rdi, (%r13)
    0x107c4a840 <+480>: movzwl (%rsi), %edi
    0x107c4a843 <+483>: movq   0x18(%r15), %rbx
    0x107c4a847 <+487>: movq   (%rbx,%rdi,8), %rdi

[cjcliffe]

@bobobo1618 Hmm, yeah that looks like it's outside of CubicSDR; I have videos of @Toontje running it at ~8Mhz sample rate without issue on SDRPlay so I think you're right.

[UbhaSecurity]

Have to try my hackrf in time ;-)

Awsm!

Ulf

Den 26. sep. 2015 kl. 07.58 skrev Paul Warren notifications@github.com:

@cjcliffe Yep, that's done the trick! Now have CubicSDR running with the BladeRF as a source :)

My laptop is dropping samples if I set the input bandwidth much above 8MHz. I can't see a way to set the various gain settings of the thing, but it does work!

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

[cjcliffe]

Apparently while I was sleeping @jocover has already created a new standalone SoapyHackRF module!

https://github.com/pothosware/SoapySDR/issues/34#issuecomment-143422372

[bobobo1618]

Just tested and I'm getting this:

(lldb) target create "../CubicSDR/x64/CubicSDR"
Current executable set to '../CubicSDR/x64/CubicSDR' (x86_64).
(lldb) run
Process 27035 launched: '../CubicSDR/x64/CubicSDR' (x86_64)
Loading:: configuration file '/Users/lucas/Library/Application Support/CubicSDR/config.xml'
Loaded PPM for device 'HackRF HackRF One' at 0ppm
Loaded I/Q Swap for device 'HackRF HackRF One' as not swapped
Loaded Direct Sampling Mode for device 'HackRF HackRF One':  off
Loaded offset for device 'HackRF HackRF One' at 0Hz
Loaded PPM for device 'Realtek RTL2838UHIDIR SN: 00000001' at 0ppm
Loaded I/Q Swap for device 'Realtek RTL2838UHIDIR SN: 00000001' as not swapped
Loaded Direct Sampling Mode for device 'Realtek RTL2838UHIDIR SN: 00000001':  off
Loaded offset for device 'Realtek RTL2838UHIDIR SN: 00000001' at 0Hz
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
    Loading modules... done
    Available factories...hackrf, null
Found device 0
  device = HackRF One
  driver = hackrf
  part_id = a000cb3c004e474d
  serial = 000000000000000014d463dc2f3caee1
  version = 2015.07.2
Make device 0
  Buffer Size=3.750000MB

SDR thread initializing..
Using device #0
SDR post-processing thread started..
Spectrum visual data thread started.
Spectrum visual data thread started.
libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: setFrequency(CORR) unknown name
Process 27035 stopped
* thread #9: tid = 0x234d52, 0x00007fff8639c286 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
    frame #0: 0x00007fff8639c286 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff8639c286 <+10>: jae    0x7fff8639c290            ; <+20>
    0x7fff8639c288 <+12>: movq   %rax, %rdi
    0x7fff8639c28b <+15>: jmp    0x7fff86397c53            ; cerror_nocancel
    0x7fff8639c290 <+20>: retq

[bobobo1618]

Ran with debug and I got this: https://github.com/pothosware/SoapySDR/issues/34#issuecomment-143477067

The backtrace seems to show CubicSDR passing in bad args at https://github.com/cjcliffe/CubicSDR/blob/soapysdr-support/src/sdr/SoapySDRThread.cpp#L165

[cjcliffe]

@bobobo1618 you'll need the updated CubicSDR soapysdr-support branch -- I wasn't masking out the RTL-SDR CORR setting for non-RTL devices.

[bobobo1618]

Okay, the new driver works after a git pull (should've thought of that)! Can't go above 7.8MHz though, I believe this is due to the default buffer length: https://github.com/jocover/SoapyHackRF/blob/master/SoapyHackRF.hpp#L29

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