In airspy_set_linearity_gain (and airspy_set_sensitivity_gain), if an out of bound value is given (ex : 30) the minimum gain will bet set . Man could expect to get the maximum gain in this case ..

It's because the variable value is an unsigned int and so the computation :
value = GAIN_COUNT - 1 - value; will not give a negative number and the following
if (value < 0) is meaningless with an uint

Plus, the maximum allowed value (GAIN_COUNT) is not in airspy.h and so application could not know it.

When compiling the Airspu host libraries and tools on Centos6.7, running the "cmake ../ -DINSTALL_UDEV_RULES=ON" command gives the following error:

-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - not found
-- Looking for stdint.h
-- Looking for stdint.h - not found
-- Looking for stddef.h
-- Looking for stddef.h - not found
-- Check size of unsigned short
-- Check size of unsigned short - failed
-- Check size of unsigned int
-- Check size of unsigned int - failed
-- Check size of unsigned long
-- Check size of unsigned long - failed
CMake Error at /usr/share/cmake/Modules/TestBigEndian.cmake:44 (message):
no suitable type found
Call Stack (most recent call first):
libairspy/CMakeLists.txt:73 (TEST_BIG_ENDIAN)

Per this HackRF thread ( https://pairlist9.pair.net/pipermail/hackrf-dev/2013-July/000120.html ), the libairspy/CMakeLists.txt and airspy-tools/CMakeLists.txt files improperly specify the gnu90 ANSI standard but GCC v4.4 only supports GNU89. Simply deleting these two lines fixes the issue and things compile fine.

--David

Hello. It is possible to use width of a strip of 10 MHz? Thanks in advance.

Would be nice to know under which license the code is published.

I had builded this in my raspberry , but when I run airspy_info, it seem no found my HF+? but the pi os has found the device.

airspy_get_lna_gain
airspy_get_mixer_gain
airspy_get_vga_gain
ref: pothosware/SoapyAirspy#14 (comment)

libairspy/src/airspy.c is using CRLF as line ending on seven rows. The rest of the file uses LF.

Not all editors play nicely with this mix making it cumbersome working on the file and keep track of changes. Is it possible to make the line endings consistent?

Warning during make, not sure if significant:

[ 7%] Building C object libairspy/src/CMakeFiles/airspy.dir/airspy.c.o
/home/ubuntu/airspy/libairspy/src/airspy.c: In function ‘conversion_threadproc’:
/home/ubuntu/airspy/libairspy/src/airspy.c:306:3: warning: enumeration value ‘AIRSPY_SAMPLE_END’ not handled in switch [-Wswitch]
switch (device->sample_type)
^
[ 14%] Building C object libairspy/src/CMakeFiles/airspy.dir/iqconverter_float.c.o
[ 21%] Building C object libairspy/src/CMakeFiles/airspy.dir/iqconverter_int16.c.o
Linking C shared library libairspy.so
[ 21%] Built target airspy
Scanning dependencies of target airspy-static
[ 28%] Building C object libairspy/src/CMakeFiles/airspy-static.dir/airspy.c.o
/home/ubuntu/airspy/libairspy/src/airspy.c: In function ‘conversion_threadproc’:
/home/ubuntu/airspy/libairspy/src/airspy.c:306:3: warning: enumeration value ‘AIRSPY_SAMPLE_END’ not handled in switch [-Wswitch]
switch (device->sample_type)
^

Starting point for this build was using the following image:
http://www.kd0cq.com/2014/08/packed-full-beaglebone-black-img-file-rtl-sdr-gnuradio-gqrx-lots-more-on-ubuntu-14-04/

If the device is unplugged while streaming, the while-loop in transfer_threadproc exits and the calls to libusb_handle_events_timeout_completed stops. This will in most cases lead to non-completed and/or failed transfers to be left hanging around inside the libusb.

When the libusb context is then closed, these hanging transfers cause memory leaks.

As far as I understand libusb, if you have submitted a transfer with libusb_submit_transfer, you must continue to make calls to a libusb_handle_events_* function until a event callback takes place for the transfer in question.

Canceling a transfer does not change this, you still need to make calls to libusb_handle_events_* after canceling the transfer and wait for the callback to fire before the transfer is considered complete.

Actually, even during a normal stop of libairspy (a call to libairspy_stop_rx), transfers are hanging around unhandled but are "released" due to the call to airspy_set_receiver_mode to turn off the receiver. This call will issue a libusb_control_transfer that most likely call a libusb_handle_events_* function under the hood making a proper cleanup. This seem more like a unintended behavior then by design though.

A simple fix might be to make a call to libusb_handle_events_timeout inside kill_io_threads just after the join of the two threads. This will fire event callbacks for the remaining transfers and free internal libusb memory.

The calls to the callback is safe here since device->stop_requested is set to true and the callback will just be a no-op.

Another way (perhaps even more robust?) is to introduce a reference counter that keep track of transfers in flight. Increase the counter for every call to libusb_submit_transfer and decrease it in the callback. And then in kill_io_threads you just loop over calls to libusb_handle_events_timeout until the reference counter reaches zero.

All this is observed on Fedora 33 x86_64 with libairspy master and libusb 1.0.24 and using a Airspy R2.

Simple program to show the memory leak:

#include <stdio.h>
#include <unistd.h>
#include <inttypes.h>

#include <airspy.h>

struct ctx {
    unsigned counter;
};

static int data_cb(airspy_transfer *transfer) {
    struct ctx *ctx = (struct ctx*)transfer->ctx;

    if (++ctx->counter == 20) {
        printf("Consumer thread: Data received...\n");
        ctx->counter = 0;
    }

    return 0;
}

int main(int argc, char **argv) {
    uint64_t              serial = 0;
    struct airspy_device *dev = NULL;
    int                   ret;
    struct ctx            ctx = { 0 };

    // Get serial if provided
    if (argc > 1) {
        ret = sscanf(argv[1], "%" SCNx64, &serial);
        if (ret != 1) serial = 0;
    }

    printf("Main thread: Running memleak test using device %.16" PRIx64 "....\n", serial);

    ret = airspy_open_sn(&dev, serial);
    if (ret != AIRSPY_SUCCESS) {
        printf("Error: Unable to open device.\n");
        return 1;
    }

    airspy_start_rx(dev, data_cb, &ctx);

    printf("Main tread: Waiting for device to be unplugged...\n");
    while (airspy_is_streaming(dev) == AIRSPY_TRUE) {
        sleep(1);
    }

    airspy_stop_rx(dev);
    airspy_close(dev);

    return 0;
}

Compile and run with valgrind:

  $ gcc -Wall -I/usr/include/libairspy -o memleak memleak.c -lairspy -lusb-1.0 -lpthread
  $ valgrind --leak-check=full --show-leak-kinds=all --show-error-list=yes ./memleak

Unplugg the device and valgrind will most of the time indicate memory leaks in like three out of six tries.

airspy_si5351c -n 0 -r -s0x0123456789ABCDEF 2>&1 | grep Usage | wc -l

It repeats the usage message once for each digit of the serial number, once for each character in 0x and one because there is some type of problem. which adds up to 19 times in total.

It does return the correct result, though.
Board serial number to open: 0x0123456789ABCDEF
[ 0] -> 0x11

But it only works if -s(with no space)serial_number is the very last argument.

Hi,

When compiling for Windows 10 using MSVC (2019) and CMake, the compiler prints warnings
that it is ignoring an unrecognized option "-O3" for libairspy and "-O2" for airspy-tools.
But more importantly CMake is not passing the correct optimization options to MSVC (/O2 /Ob2),
so the resulting binaries are not optimized.

This issue can be solved by removing line:
set(CMAKE_C_FLAGS_RELEASE "-O3")
from libairspy/CMakeLists.txt and
set(CMAKE_C_FLAGS_RELEASE "-O2")
from airspy-tools/CMakeLists.txt

CMAKE_BUILD_TYPE=Release already sets "-O3" for gcc/clang and sets "/O2 /Ob2" for msvc.
This implies, though, that airspy-tools will also be compiled with -O3 for gcc/clang.

Regards.

Open fails due to the kernel driver having claimed the interface already, we should probably tell the user about this instead of exiting with a generic open error.

When the airspy mini is disconnected from USB unconditionally then the function airspy_stop_rx() reports AIRSPY_ERROR_LIBUSB(-1000) which is as expected. But the function airspy_close() blocks for ever.

I use both functions during the shutdown of my application. Because of airspy_close() the program is not quit correctly.

https://github.com/AlbrechtL/welle.io/blob/56504bcd40544e32987ceb3832715e3cc0f1c821/src/input/airspy_sdr.cpp#L84

CAirspy::~CAirspy(void)
{
    if (device) {
        int result = airspy_stop_rx(device);
        if (result != AIRSPY_SUCCESS) {
            std::clog  << "Airspy: airspy_stop_rx () failed:" << airspy_error_name((airspy_error)result) << "(" << result << ")" << std::endl;
        }

        result = airspy_close(device);
        if (result != AIRSPY_SUCCESS) {
            std::clog  << "Airspy: airspy_close () failed:" << airspy_error_name((airspy_error)result) << "(" << result << ")" << std::endl;
        }
    }

    airspy_exit();
}

What can I do to close the airspy driver correctly even if the airspy in disconnected?

I've done some experiment to make airspy works on FreeBSD (rasperry).
Seems to be as simple as this patch but cmakes

diff --git a/libairspy/src/iqconverter_float.c b/libairspy/src/iqconverter_float.c
index 844e846..111007e 100644
--- a/libairspy/src/iqconverter_float.c
+++ b/libairspy/src/iqconverter_float.c
@@ -38,6 +38,12 @@ THE SOFTWARE.
   #define _aligned_free(mem) free(mem)
   #define _inline inline
   #define FIR_STANDARD
+#elif defined(__FreeBSD__)
+  #include <stdlib.h>
+  #define _aligned_malloc(size, alignment) malloc(size)
+  #define _aligned_free(mem) free(mem)
+  #define _inline inline
+  #define FIR_STANDARD
 #elif defined(__GNUC__) && !defined(__MINGW64_VERSION_MAJOR)
   #include <malloc.h>
   #define _aligned_malloc(size, alignment) memalign(alignment, size)
diff --git a/libairspy/src/iqconverter_int16.c b/libairspy/src/iqconverter_int16.c
index d38df68..50798db 100644
--- a/libairspy/src/iqconverter_int16.c
+++ b/libairspy/src/iqconverter_int16.c
@@ -34,6 +34,11 @@ THE SOFTWARE.
   #define _aligned_malloc(size, alignment) malloc(size)
   #define _aligned_free(mem) free(mem)
   #define _inline inline
+#elif defined(__FreeBSD__)
+  #include <stdlib.h>
+  #define _aligned_malloc(size, alignment) malloc(size)
+  #define _aligned_free(mem) free(mem)
+  #define _inline inline
 #elif defined(__GNUC__) && !defined(__MINGW64_VERSION_MAJOR)
   #include <malloc.h>
   #define _aligned_malloc(size, alignment) memalign(alignment, size)

Using cmake 3.4.1 (the one available in FreeBSD ports) it seems you need to add set(THREADS_PREFER_PTHREAD_FLAG ON) to correctly detect the right libpthread (without s) but still cmake is running its tests with -lpthreads, I don't know cmake enough to fix this.

The manually compiled binaries seems to work but airpsy_info detects the same board 32 times:

Found AirSpy board 32
Board ID Number: 0 (AIRSPY)
Firmware Version: AirSpy NOS v1.0.0-rc3-0-g4d9e874 2015-01-09
Part ID Number: 0x6906002B 0x00000030
Serial Number: 0x16C46XXXXX
Supported sample rates:
        10.000000 MSPS
        2.500000 MSPS
Close board 32

Any ideas? Thanks.

I would like to use an Airspy-mini for the Open-Glider-Network at 3 MHz sampling and decimate by 3 for 1 MHz bandwidth and specify an appropriate filter with:

extern ADDAPI int ADDCALL airspy_set_conversion_filter_float32(struct airspy_device* device, const float *kernel, const uint32_t len);

I have tried various filter designs, but they all end up with aliasing. Can you provide details for the design of the required filter taps ?

I have several PCs where I could install the host under Ubuntu. But on my RPI3 I get an error:

pi@raspberrypi:~/apps/airspy/airspyone_host-master/libairspy/build $ cmake ../ -DINSTALL_UDEV_RULES=ON
CMake Error at CMakeLists.txt:77 (find_package):
By not providing "FindUSB1.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "USB1", but
CMake did not find one.

Could not find a package configuration file provided by "USB1" with any of
the following names:

USB1Config.cmake
usb1-config.cmake

Add the installation prefix of "USB1" to CMAKE_PREFIX_PATH or set
"USB1_DIR" to a directory containing one of the above files. If "USB1"
provides a separate development package or SDK, be sure it has been
installed.

-- Configuring incomplete, errors occurred!
See also "/home/pi/apps/airspy/airspyone_host-master/libairspy/build/CMakeFiles/CMakeOutput.log".

What can I do?

pi@raspberrypi:~ $ dpkg -l | grep usb
ii libusb-0.1-4:armhf 2:0.1.12-25 armhf userspace USB programming library
ii libusb-1.0-0:armhf 2:1.0.19-1 armhf userspace USB programming library
ii libusb-1.0-0-dbg:armhf 2:1.0.19-1 armhf userspace USB programming library development files
ii libusb-1.0-0-dev:armhf 2:1.0.19-1 armhf userspace USB programming library development files
ii libusb-1.0-doc 2:1.0.19-1 all documentation for userspace USB programming
ii libusbmuxd2:armhf 1.0.9-1 armhf USB multiplexor daemon for iPhone and iPod Touch devices - library
ii usb-modeswitch 2.2.0+repack0-2 armhf mode switching tool for controlling "flip flop" USB devices
ii usb-modeswitch-data 20150115-1 all mode switching data for usb-modeswitch
ii usbutils 1:007-2 armhf Linux USB utilities

I suggest a little enhancement: add an airspy_list_devices() api function similar to the one in airspyhf.

An improvement upon the one from airspyhf would even be that given a NULL pointer in place of the serials pointer, it would just return the number of devices, thus allowing to correctly allocate the serials buffer.

Please, consider submitting the udev rules to upstream (systemd). Here is an example how to do it: systemd/systemd#20561

Without this, it is not possible to use Airspy SDR devices in Flatpak and other special configurations where it is not possible to install the Airspy libs/udev rules system-wide.

When writing a firmware image using "airspy_spiflash -w" and re-reading it afterwards using "airspy_spiflash -l 0x1000 -r" the file contents differ. If this isn't a bug, it's not the behavior one would expect after reading the help text of airspy_spiflash.

Using the current v1.0.0-rc3 image (v1.0.0-rc3-0-g4d9e874 2015-01-09) for example, it looks like the read image starts at offset 0x12F0 of the released image.

Another strange thing is that it seems to be impossible to read more than 0x10000 bytes even though the SPI flash chip seems to be a 0x100000 device. When trying to read beyond 0x1000 the AirSpy seems to crash and needs to be replugged to be accessible again.

When I close the program, I get this error.

Consultez la fin de ce message pour plus de détails sur l'appel du débogage
juste-à-temps (JIT) à la place de cette boîte de dialogue.

************** Texte de l'exception **************
System.NullReferenceException: La référence d'objet n'est pas définie à une instance d'un objet.
à SDRSharp.MainForm.MainForm_Closing(Object sender, CancelEventArgs e)
à System.Windows.Forms.Form.OnClosing(CancelEventArgs e)
à System.Windows.Forms.Form.WmClose(Message& m)
à System.Windows.Forms.Form.WndProc(Message& m)
à System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
à System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
à System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Assemblys chargés **************
mscorlib
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.34209 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll

SDRSharp
Version de l'assembly : 1.0.0.1423
Version Win32 : 1.0.0.1423
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.exe

System
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.34238 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

SDRSharp.Radio
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.Radio.DLL

System.Windows.Forms
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.34251 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System.Drawing
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.34270 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

SDRSharp.Common
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.Common.DLL

SDRSharp.PanView
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.PanView.DLL

System.Configuration
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.34209 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Xml
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.34234 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

SDRSharp.CollapsiblePanel
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.CollapsiblePanel.DLL

SDRSharp.FrequencyEdit
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.FrequencyEdit.DLL

SDRSharp.AIRSPY
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.AIRSPY.DLL

SDRSharp.HackRF
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.HackRF.DLL

SDRSharp.RTLSDR
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.RTLSDR.DLL

SDRSharp.RTLTCP
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.RTLTCP.DLL

SDRSharp.FUNcube
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.FUNcube.DLL

SDRSharp.FUNcubeProPlus
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.FUNcubeProPlus.DLL

SDRSharp.SoftRock
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.SoftRock.DLL

SDRSharp.SDRIQ
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.SDRIQ.DLL

SDRSharp.SDRIP
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.SDRIP.DLL

SDRSharp.AfedriSDRNet
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.AfedriSDRNet.DLL

SDRSharp.IQCorrection
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.IQCorrection.DLL

SDRSharp.NoiseBlanker
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.NoiseBlanker.DLL

SDRSharp.AuxVFO
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.AuxVFO.DLL

SDRSharp.BasebandRecorder
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.BasebandRecorder.DLL

SDRSharp.TimeShift
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.TimeShift.DLL

SDRSharp.DNR
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.DNR.DLL

mscorlib.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.18408 built by: FX451RTMGREL
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/mscorlib.resources.dll

SDRSharp.DigitalIfProcessor
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.DigitalIfProcessor.DLL

SDRSharp.DigitalAudioProcessor
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.DigitalAudioProcessor.DLL

SDRSharp.AudioRecorder
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.AudioRecorder.DLL

Microsoft.GeneratedCode
Version de l'assembly : 1.0.0.0
Version Win32 : 4.0.30319.34234 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

SDRSharp.DCSDecoder
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.DCSDecoder.DLL

SDRSharp.CTCSSDecoder
Version de l'assembly : 1.0.0.0
Version Win32 : 1.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.CTCSSDecoder.DLL

SDRSharp.FrequencyScanner
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.FrequencyScanner.DLL

System.Windows.Forms.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.18408 built by: FX451RTMGREL
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/System.Windows.Forms.resources.dll

Microsoft.GeneratedCode
Version de l'assembly : 1.0.0.0
Version Win32 : 4.0.30319.34234 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

Microsoft.GeneratedCode
Version de l'assembly : 1.0.0.0
Version Win32 : 4.0.30319.34234 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

SDRSharp.FreqMan
Version de l'assembly : 0.0.0.0
Version Win32 : 0.0.0.0
CodeBase : file:///C:/Users/Administrateur/Desktop/SDR/sdr-install/sdrsharp/SDRSharp.FreqMan.DLL

Microsoft.GeneratedCode
Version de l'assembly : 1.0.0.0
Version Win32 : 4.0.30319.34234 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

Accessibility
Version de l'assembly : 4.0.0.0
Version Win32 : 4.0.30319.34209 built by: FX452RTMGDR
CodeBase : file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll

************** Débogage JIT **************
Pour activer le débogage juste-à-temps (JIT), le fichier de configuration pour cette
application ou cet ordinateur (machine.config) doit avoir la valeur
jitDebugging définie dans la section system.windows.forms.
L'application doit également être compilée avec le débogage
activé.

Par exemple :

Lorsque le débogage juste-à-temps est activé, les exceptions non gérées
seront envoyées au débogueur JIT inscrit sur l'ordinateur
plutôt que d'être gérées par cette boîte de dialogue.

Im running on ubuntu vivid with a fresh clone & install of the airspy repo (including PR #19 which I understand should make things work out of the box with newer kernels).

However I am unable to connect and unsure how to debug further. See output below.

dgorissen@minion:~$ uname -a
Linux minion 3.19.0-30-generic #34-Ubuntu SMP Fri Oct 2 22:08:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

dmesg output:
[ 2000.375749] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 2000.610160] usb 1-2: New USB device found, idVendor=1d50, idProduct=60a1
[ 2000.610164] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2000.610165] usb 1-2: Product: AIRSPY
[ 2000.610167] usb 1-2: Manufacturer: www.airspy.com
[ 2000.610168] usb 1-2: SerialNumber: AIRSPY SN:466C64C82C1073C7
[ 2000.641372] airspy 1-2:1.0: usb_control_msg() failed -32 request 0a
[ 2000.641375] airspy 1-2:1.0: Could not detect board
[ 2000.641380] airspy: probe of 1-2:1.0 failed with error -32

dgorissen@minion:~$ airspy_info
airspy_lib_version: 1.0.6

Found AirSpy board 1
Board ID Number: 0 (AIRSPY)
Firmware Version: AirSpy NOS v1.0.0-rc5-0-g648c14f 2015-05-20
Part ID Number: 0x6906002B 0x00000030
Serial Number: 0x466C64C82C1073C7
Supported sample rates:
10.000000 MSPS
2.500000 MSPS
Close board 1
airspy_close() board 1 failed: AIRSPY_ERROR_LIBUSB (-1000)

I've tried to use airspy_rx with "-r -" to be used on the cli (for example pipe to multimon).

Do you plan to support it ?

The user should be able to select a bandwidth (and sample rate) for a recording of I/Q samples.
If using WAV container, the recording should seamlessly continue in a new WAV file when the maximum length of the WAV file is reached.

If a device that is streaming is unplugged, libairspy sometimes deadlock when airspy_close is called to close the open, but now absent, device. As far as I can see, what is happening is that the conditional:

Simple program to reproduce, deadlock.c:

#include <stdio.h>
#include <unistd.h>
#include <inttypes.h>

#include <airspy.h>

struct ctx {
    unsigned counter;
};

static int data_cb(airspy_transfer *transfer) {
    struct ctx *ctx = (struct ctx*)transfer->ctx;

    if (++ctx->counter == 20) {
        printf("Consumer thread: Data received...\n");
        ctx->counter = 0;
    }

    return 0;
}

int main(int argc, char **argv) {
    uint64_t              serial = 0;
    struct airspy_device *dev = NULL;
    int                   ret;
    struct ctx            ctx = { 0 };

    // Get serial if provided
    if (argc > 1) {
        ret = sscanf(argv[1], "%" SCNx64, &serial);
        if (ret != 1) serial = 0;
    }

    printf("Main thread: Running deadlock test using device %.16" PRIx64 "....\n", serial);

    ret = airspy_open_sn(&dev, serial);
    if (ret != AIRSPY_SUCCESS) {
        printf("Error: Unable to open device.\n");
        return 1;
    }

    airspy_start_rx(dev, data_cb, &ctx);

    printf("Main tread: Waiting for device to be unplugged...\n");
    while (airspy_is_streaming(dev) == AIRSPY_TRUE) {
        sleep(1);
    }

    airspy_stop_rx(dev);
    airspy_close(dev);

    return 0;
}

Build and run with:

$ gcc -Wall -I/usr/include/libairspy -o deadlock deadlock.c -lairspy -lusb-1.0 -lpthread
$ ./deadlock

and then unplug the device. Sometimes the program exits correctly, but sometimes it hangs in airspy_close.

/ libairspy / src / airspy.c
Line 890:
version[result] = '\0';
Possible segfault if result is greater than length, for some reason.

if (result < 0 || result > length)
in line 886 should fix it.

I'm using a Winbook TW100 tablet running Windows 8.1. I'm trying to use Airspy with Unitrunker but am not able to get any signal. Airspy is recognized in UT and I have a working control channel set but when I hit run, there's just a flat line. My R280T works fine. Airspy also works fine in SDR#. Are there any settings in Win8.1 that I should be aware of?

Problem description see title (or read this for more details https://uk.groups.yahoo.com/neo/groups/airspy/conversations/messages/2013 )

libusb may possibly be the root cause of problem, by returning the same device two times (under Win 8.1) - libusb/libusb#56

Can the airspy_open_device function be modified somehow to workaround this Windows 8.1 libusb bug, at least until libusb put a fix in place for the Windows 8.1 security feature :)
https://github.com/airspy/host/blob/master/libairspy/src/airspy.c#L504

Guys,

As you can see in https://groups.google.com/forum/#!topic/gqrx/Y1uUZSJ5hJ0, Michael Dickens helped me with an issue in libairspy, whilst trying to install gqrx through macports.

He suggested:
Before building libairspy, modify host/libairspy/CMakeLists.txt and add the following near the beginning:

if(APPLE)

    set(GR_LIBRARY_DIR "lib") 

    if(NOT CMAKE_INSTALL_NAME_DIR) 

        set(CMAKE_INSTALL_NAME_DIR 

            ${CMAKE_INSTALL_PREFIX}/${GR_LIBRARY_DIR} CACHE 

            PATH "Library Install Name Destination Directory" FORCE) 

    endif(NOT CMAKE_INSTALL_NAME_DIR) 

    if(NOT CMAKE_INSTALL_RPATH) 

        set(CMAKE_INSTALL_RPATH 

            ${CMAKE_INSTALL_PREFIX}/${GR_LIBRARY_DIR} CACHE 

            PATH "Library Install RPath" FORCE) 

    endif(NOT CMAKE_INSTALL_RPATH) 

    if(NOT CMAKE_BUILD_WITH_INSTALL_RPATH) 

        set(CMAKE_BUILD_WITH_INSTALL_RPATH ON CACHE 

            BOOL "Do Build Using Library Install RPath" FORCE) 

    endif(NOT CMAKE_BUILD_WITH_INSTALL_RPATH)

endif(APPLE)

Works for me...

Kind regards and thanks for the good work.

Derk

Hi all,

I would like to implement in my ExtIO dll two new sliders, in order to use the new functions.

So, I created two slider with 0-21 range, one acting on airspy_set_linearity_gain, the other one on airspy_set_sensitivity_gain.

However it is not clear to me the logic of those functions: looking to the source in airspy.c , it seems that one overwrite the parameters of other.
So, changing the slider for sensitivity make the position of linearity slider inconsistent and viceversa.

Can you suggest an alternative possible working arrangement for the two sliders ?

The Airspy team has posted a “Use at your own risk” regarding the use of USB 3.0 due to errors in the rtl-sdr library that can cause out of sequence reception of data.

Despite this warning, I've been reading about a lot of people using USB 3.0 ports on their computers and using their ears to verify that the data coming in from the Airspy is:

1. Received at the correct rate

2. The data is not corrupted in anyway.

It seems that some out of sequence data would not be discovered this way.

A better approach would be to add a test mode to the Airspy firmware so it can be commanded to output a known data pattern at a rate the host computer requests it at (320 Mbits / second for 10 Mhz I&Q ...).

I would be willing to write airspy_usb_check if the Airspy team could update the firmware. Or if you like, I would be willing to update the firmware as well.

I’m an experienced software engineer and I can mimic other people’s coding style (I’m doing it with airspy_tcp right now).

Adding this test capability to SDRSharp (far in the future – I know you are super busy) may be worthwhile contemplating as well.

Blort

Hi,

Just reading source code for my knowledge.In file airspy.c, function airspy_set_samplerate(), line 882, I believe there is a bug : LIBUSB_ENDPOINT_IN should in fact be LIBUSB_ENDPOINT_OUT.
Right ?

Nicolas

When connecting the airspy to a virtual machine, the OS cannot enumerate the manufacturer, product, and serial # preventing device from being recognized. I've tested the hackrf on hardware with Windows, on a kali laptop and it works fine, however connecting it to a kali vm (same versions as the hardware version), those parameters come up with an error preventing the OS from recognizing it. It is recognized in an lsusb and lsb -v.

I know folks are going to go on about not running these in VMs but the mix of hardware and OS's I have (the kali laptop doesn't have the horsepower for gnuradio but the Windows laptop is very capable). I've run the hackrf and rtl dongles plugged into a virtual USB 3.0 VM interface and it works fine.

Any help would be appreciated!

Could you please add a LICENSE file in the repository root directory as you did with libairspyhf?

license reference list, https://spdx.org/licenses/

Good afternoon!

I think I found a bug in the code in LibAirSpy Packing mode on.

When allocating memory:
static int allocate_transfers (airspy_device_t * const device)
{
...
if (device-> packing_enabled)
{
//Error! Invalid considered the number of unpacked samples
// sample_count = ((device-> buffer_size / 2) * 4) / 3; // packed_sample_count = 98304
sample_count = (((device-> buffer_size / 2) * 4) / 3)/0.75; // unpacked_sample_count = 131072
}
else
{
sample_count = device-> buffer_size / 2;
}
...
}

Also in
static void * consumer_threadproc (void * arg)
{
....

if (device-> packing_enabled)
{
sample_count = ((device-> buffer_size / 2) * 4) / 3; // packed_sample_count = 98304

if (device-> sample_type! = AIRSPY_SAMPLE_RAW)
{
unpack_samples ((uint32_t *) input_samples, device-> unpacked_samples, sample_count);

input_samples = device-> unpacked_samples;
// Here you need to add a new SampleCount
sample_count = sample_count / 0,75; // unpacked_sample_count = 131072
}
}
else
{
sample_count = device-> buffer_size / 2;
}
....

This is mistake? Or am I wrong understand unpacking operation 12 to 16 bit.

/ libairspy / src / airspy.c
Line 283:
dest[2] = ((packed_data[0] >> 24) | (packed_data[1] << 8)) & 0xFF0;
should be:
dest[2] = (packed_data[0] >> 24) | ((packed_data[1] << 8) & 0xF00);
Line 286:
dest[5] = ((packed_data[1] >> 28) | (packed_data[2] << 4)) & 0xFF0;
should be:
dest[5] = (packed_data[1] >> 28) | ((packed_data[2] << 4) & 0xFF0);

Hi all,

I'm building airspy latest release (v1.0.7) for the PothosSDR windows installer. We include airspy support for SoapySDR and GrOsmoSDR: More info here: https://github.com/pothosware/PothosSDR/wiki

I had to make few changes to get the build working on MSVC 2012 and 2013. This is the patch to get everything building, and I will break it down below: https://github.com/pothosware/PothosSDR/blob/master/patches/airspy_build_msvc.diff

custom pthread and libusb library paths

I provide a libusb and pthread library for the environment. And I pass in pthread and libusb to many of the libraries, not just airspy. I needed a way to disable the following code when custom pthread and libusb library paths are specified. I would be happy for an alternative mechanism though. Also, I could not set CMAKE_CROSSCOMPILING=ON as a work-around hack. CMake will override that setting.

 if(WIN32 AND NOT CMAKE_CROSSCOMPILING)
+ if (NOT DEFINED LIBUSB_LIBRARIES)
  configure_file(
      ${CMAKE_CURRENT_BINARY_DIR}/../libs_win32/libusb-1.0.dll
      ${CMAKE_CURRENT_BINARY_DIR}/airspy-tools/src/libusb-1.0.dll
  COPYONLY)
+ endif()

+ if (NOT DEFINED THREADS_PTHREADS_WIN32_LIBRARY)
  configure_file(
      ${CMAKE_CURRENT_BINARY_DIR}/../libs_win32/pthreadGC2.dll
      ${CMAKE_CURRENT_BINARY_DIR}/airspy-tools/src/pthreadGC2.dll
  COPYONLY)
+ endif()
 endif()

building with vc11 (msvc 2012)

I build for both msvc 2012 and 2013 targets (eventually 2015). I discovered some minor build issues for 2012 that were easy to remedy. Here are the patches.

The strtoull() function was missing in both the library and tools. The simplest work around for me was to define in the top level with a macro, since _strtoui64() provides the same functionality:

+#provide missing strtoull() for VC11
+if(MSVC11)
+    add_definitions(-Dstrtoull=_strtoui64)
+endif(MSVC11)

The IQ converter float code actually had a version check in it, but the code must have changed around it. Since I was able to build for vc12 but not vc11, I updated the check for _MSC_VER >= 1800 which corresponds to vc12 and up. The converter code now builds for both compiers with this new ifdef. I assume that this change means that the implementation uses a non-accelerated converter for vc11:

   //#define FIR_AUTO_VECTOR
 #else
-   #if (_MSC_VER >= 1300)
+   #if (_MSC_VER >= 1800)
        #define USE_SSE2
        #include <immintrin.h>
    #else

Thanks for your consideration!

Here is exactly what I did to get the above error.
root@bananapi ~/src/airspy/host (git)-[master] # git clean -dfx
Removing build/
Removing libairspy/build/
root@bananapi ~/src/airspy/host (git)-[master] # git pull
Already up-to-date.
root@bananapi ~/src/airspy/host (git)-[master] # mkdir build
root@bananapi ~/src/airspy/host (git)-[master] # cd build
root@bananapi ~/src/airspy/host/build (git)-[master] # cmake ../ -DINSTALL_UDEV_RULES=ON
-- The C compiler identification is GNU 4.9.1
-- The CXX compiler identification is GNU 4.9.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
-- checking for module 'libusb-1.0'
-- found libusb-1.0, version 1.0.19
-- Found LIBUSB: /usr/lib/arm-linux-gnueabihf/libusb-1.0.so
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /root/src/airspy/host/build
cmake ../ -DINSTALL_UDEV_RULES=ON 5.94s user 2.51s system 74% cpu 11.401 total
root@bananapi ~/src/airspy/host/build (git)-[master] # make
Scanning dependencies of target airspy
[ 7%] Building C object libairspy/src/CMakeFiles/airspy.dir/airspy.c.o
[ 14%] Building C object libairspy/src/CMakeFiles/airspy.dir/iqconverter_float.c.o
[ 21%] Building C object libairspy/src/CMakeFiles/airspy.dir/iqconverter_int16.c.o
Linking C shared library libairspy.so
[ 21%] Built target airspy
Scanning dependencies of target airspy-static
[ 28%] Building C object libairspy/src/CMakeFiles/airspy-static.dir/airspy.c.o
[ 35%] Building C object libairspy/src/CMakeFiles/airspy-static.dir/iqconverter_float.c.o
[ 42%] Building C object libairspy/src/CMakeFiles/airspy-static.dir/iqconverter_int16.c.o
Linking C static library libairspy.a
[ 42%] Built target airspy-static
Scanning dependencies of target airspy_gpio
[ 50%] Building C object airspy-tools/src/CMakeFiles/airspy_gpio.dir/airspy_gpio.c.o
Linking C executable airspy_gpio
[ 50%] Built target airspy_gpio
Scanning dependencies of target airspy_gpiodir
[ 57%] Building C object airspy-tools/src/CMakeFiles/airspy_gpiodir.dir/airspy_gpiodir.c.o
Linking C executable airspy_gpiodir
[ 57%] Built target airspy_gpiodir
Scanning dependencies of target airspy_info
[ 64%] Building C object airspy-tools/src/CMakeFiles/airspy_info.dir/airspy_info.c.o
Linking C executable airspy_info
[ 64%] Built target airspy_info
Scanning dependencies of target airspy_lib_version
[ 71%] Building C object airspy-tools/src/CMakeFiles/airspy_lib_version.dir/airspy_lib_version.c.o
Linking C executable airspy_lib_version
[ 71%] Built target airspy_lib_version
Scanning dependencies of target airspy_r820t
[ 78%] Building C object airspy-tools/src/CMakeFiles/airspy_r820t.dir/airspy_r820t.c.o
Linking C executable airspy_r820t
[ 78%] Built target airspy_r820t
Scanning dependencies of target airspy_rx
[ 85%] Building C object airspy-tools/src/CMakeFiles/airspy_rx.dir/airspy_rx.c.o
Linking C executable airspy_rx
[ 85%] Built target airspy_rx
Scanning dependencies of target airspy_si5351c
[ 92%] Building C object airspy-tools/src/CMakeFiles/airspy_si5351c.dir/airspy_si5351c.c.o
Linking C executable airspy_si5351c
[ 92%] Built target airspy_si5351c
Scanning dependencies of target airspy_spiflash
[100%] Building C object airspy-tools/src/CMakeFiles/airspy_spiflash.dir/airspy_spiflash.c.o
Linking C executable airspy_spiflash
[100%] Built target airspy_spiflash
make 15.53s user 2.83s system 90% cpu 20.262 total
root@bananapi ~/src/airspy/host/build (git)-[master] # make install
[ 21%] Built target airspy
[ 42%] Built target airspy-static
[ 50%] Built target airspy_gpio
[ 57%] Built target airspy_gpiodir
[ 64%] Built target airspy_info
[ 71%] Built target airspy_lib_version
[ 78%] Built target airspy_r820t
[ 85%] Built target airspy_rx
[ 92%] Built target airspy_si5351c
[100%] Built target airspy_spiflash
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/pkgconfig/libairspy.pc
-- Installing: /usr/local/lib/libairspy.so.1.0.3
-- Up-to-date: /usr/local/lib/libairspy.so.0
-- Up-to-date: /usr/local/lib/libairspy.so
-- Installing: /usr/local/lib/libairspy.a
-- Up-to-date: /usr/local/include/libairspy/airspy.h
-- Up-to-date: /usr/local/include/libairspy/airspy_commands.h
-- Up-to-date: /usr/local/include/libairspy/iqconverter_float.h
-- Up-to-date: /usr/local/include/libairspy/iqconverter_int16.h
-- Up-to-date: /usr/local/include/libairspy/filters.h
-- Up-to-date: /etc/udev/rules.d/52-airspy.rules
-- Installing: /usr/local/bin/airspy_gpio
-- Removed runtime path from "/usr/local/bin/airspy_gpio"
-- Installing: /usr/local/bin/airspy_gpiodir
-- Removed runtime path from "/usr/local/bin/airspy_gpiodir"
-- Installing: /usr/local/bin/airspy_lib_version
-- Removed runtime path from "/usr/local/bin/airspy_lib_version"
-- Installing: /usr/local/bin/airspy_si5351c
-- Removed runtime path from "/usr/local/bin/airspy_si5351c"
-- Installing: /usr/local/bin/airspy_r820t
-- Removed runtime path from "/usr/local/bin/airspy_r820t"
-- Installing: /usr/local/bin/airspy_spiflash
-- Removed runtime path from "/usr/local/bin/airspy_spiflash"
-- Installing: /usr/local/bin/airspy_info
-- Removed runtime path from "/usr/local/bin/airspy_info"
-- Installing: /usr/local/bin/airspy_rx
-- Removed runtime path from "/usr/local/bin/airspy_rx"
root@bananapi ~/src/airspy/host/build (git)-[master] # airspy_lib_version
airspy_lib_version: symbol lookup error: airspy_lib_version: undefined symbol: airspy_lib_version
root@bananapi ~/src/airspy/host/build (git)-[master] # which airspy_lib_version
/usr/local/bin/airspy_lib_version
root@bananapi ~/src/airspy/host/build (git)-[master] # ldd /usr/local/bin/airspy_lib_version
libairspy.so.0 => /usr/lib/arm-linux-gnueabihf/libairspy.so.0 (0xb6ee7000)
libusb-1.0.so.0 => /lib/arm-linux-gnueabihf/libusb-1.0.so.0 (0xb6ece000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6eab000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6dbc000)
/lib/ld-linux-armhf.so.3 (0xb6f18000)
libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xb6da2000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6d8c000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6d78000)

Hi AirSpy team,

I am trying to manage more than one device connected on the same computer. Assuming I do not know the serial numbers (hence cannot call airspy_open_sn() ) is there a way to retrieve the list of struct airspy_device* attached ?

Merci
best from F4GKR Sylvain

airspy tool airspy_rx does not seem to work (data is all zeros) when type 4 (unsigned int 16-bit Real) samples are selected. Type 3 (signed int 16-bit Real) seems to work (data varies and is non-zero).

root@odroidXU:/dev/shm# airspy_rx -r myrawfile -f 104 -t 4 -a 1 -v 3 -m 5 -l 10 -d
airspy_rx v1.0.0 27 Nov 2014
frequency_MHz -f 104.000000MHz (104000000Hz)
sample_rate -a 1
sample_type -t 4
biast -b 0
vga_gain -v 3
mixer_gain -m 5
lna_gain -l 10
Device Serial Number: 0x16C463C8335CA9C7
Stop with Ctrl-C
Streaming at 5.00 MSPS
Streaming at 5.00 MSPS
Streaming at 5.00 MSPS
Streaming at 5.00 MSPS
Streaming at 5.00 MSPS
Streaming at 5.00 MSPS
^CCaught signal 2

User cancel, exiting…
Total time: 6.6347 s
Average speed 5.0000 MSPS Real
done
root@odroidXU:/dev/shm# od -x myrawfile
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
376000000
root@odroidXU:/dev/shm# ls -al myrawfile
-rw-r–r– 1 root root 66584576 Dec 3 08:43 myrawfile
root@odroidXU:/dev/shm# rm myrawfile
root@odroidXU:/dev/shm# airspy_rx -r myrawfile -f 104 -t 3 -a 1 -v 3 -m 5 -l 10 -d
airspy_rx v1.0.0 27 Nov 2014
frequency_MHz -f 104.000000MHz (104000000Hz)
sample_rate -a 1
sample_type -t 3
biast -b 0
vga_gain -v 3
mixer_gain -m 5
lna_gain -l 10
Device Serial Number: 0x16C463C8335CA9C7
Stop with Ctrl-C
Streaming at 5.00 MSPS
Streaming at 5.00 MSPS
Streaming at 5.00 MSPS
^CCaught signal 2

User cancel, exiting…
Total time: 3.6306 s
Average speed 4.9982 MSPS Real
done
root@odroidXU:/dev/shm# od -x myrawfile | more
0000000 ffb0 ff50 ff70 ffb0 ff60 ffd0 ff40 fef0
0000020 00c0 ff80 ff90 fee0 ff30 ffe0 ffa0 ffb0
0000040 ff80 ffb0 ffb0 ff30 ff90 ffa0 ff70 ffa0
0000060 ff90 ff80 ffb0 ff20 ffb0 ff80 ffa0 ff60
…

root@odroidXU:/dev/shm# airspy_info

Found AirSpy board 1
Board ID Number: 0 (AIRSPY)
Firmware Version: AirSpy NOS v0.9.9 Beta
Part ID Number: 0x6906002B 0x00000030
Serial Number: 0x16C463C8335CA9C7
Close board 1
root@odroidXU:/dev/shm#

The Odroid XU is a quad 1.6 Ghz Arm A15. Maximum processor load on one processor was 9%.

I got the same result on a radxa.

Using the USB 3.0 on the Odroid XU I recorded a perfectly good wav file using sample type 0 at 10 Mhz

root@odroidXU:/dev/shm# airspy_rx -w -f 104 -v 3 -m 5 -l 10 -d
Receive wav file: AirSpy_20141203_093020Z_104000kHz_IQ.wav
airspy_rx v1.0.0 27 Nov 2014
frequency_MHz -f 104.000000MHz (104000000Hz)
sample_rate -a 0
sample_type -t 2
biast -b 0
vga_gain -v 3
mixer_gain -m 5
lna_gain -l 10
Device Serial Number: 0x16C463C8335CA9C7
Stop with Ctrl-C
Streaming at 10.00 MSPS
Streaming at 10.02 MSPS
Streaming at 9.99 MSPS
Streaming at 10.01 MSPS
Streaming at 10.00 MSPS
Streaming at 9.90 MSPS
Streaming at 10.02 MSPS
Streaming at 10.01 MSPS
Streaming at 10.01 MSPS
Streaming at 10.00 MSPS
Streaming at 10.00 MSPS
^CCaught signal 2

User cancel, exiting…
Total time: 11.1642 s
Average speed 10.0032 MSPS IQ
done

I’m not sure I’m reading the MSPS “Streaming at 5.00 MSPS” correctly, but when the frequency is set to 10 Mhz, I thought the number of samples per second would remain at 10 Mhz – not decrease to 5 Mhz. Is this an error?

I think it would be useful to have airspy_rx report the number of bytes per second. For sample types 3 & 4 at 10 Mhz sampling rate, I would expect it to be 20 MBytes / second – anything less and I would suspect a performance issue. It might be nice to have airspy_rx tell the user when the actual sampling rate is less than the expected sampling rate. I’m sure you could figure that out without being told by the program, but newbies might benefit from that kind of helpful message. When the sample rate is messed up, what you hear sounds like the chipmonks! (https://www.youtube.com/watch?v=DbYYwGmi3_8)

Something to consider is enhancing airspy_rx or adding airspy_tcp to run over a gigabit ethernet interface to SDRsharp.

If you would like some help modifying airspy_rx.c I would be glad to volunteer. blort.blort AT yahoo.com

If you are taking votes for additional sampling rates, I vote for 8 Mhz and 4 Mhz. I have some Linux computers that top out at 8.2 Mhz and others at 5.5 Mhz when using sampling type 0 at 10 Mhz. So 8 and 4 Mhz would be a nice (Christmas??? (Dec 25) / new years??? (Jan 1) / ground hog day??? (Feb 2)) present.

I’m sure that you are as excited about this device as we are. This device has an amazing potential that we are all eager to make full use of.

Blort

Benjamin,

Would you like some help with airspy_rx or airspy_tcp?

Please contact me at blort.blort AT yahoo.com if you are interested.

Blort

Problem running any of the airspy tools under https://github.com/airspy/host/releases/ on Windows XP

I would like to know how can I modify the make file on the directory airspyone_host-master/build/airspy-tools to add te compilation of other functions that I have to use in the airspy_rx.c file. I mean that when you have to compile the airspy_rx.c you only have to type make in this directory but I need to compile some other files of other directories.

In file airspy.c, function airspy_version_string_read() :
The following two lines are inconsistent :
memcpy(version, version_local, length-1);
version[length] = 0;
Either the memory copy must be of "length" size, either "version[length-1]" must be set to 0.
There is no documentation in comments so I guess "length" is the size of the "version" buffer so "version[length-1]" must be used.

After building and installing libairspy, 'pkg-config --cflags libairspy' shows -I/usr/local/include/ as the header file path, but the headers are actually installed in /usr/local/include/libairspy/ (at least on my system... Ubuntu 14.04.5). Consequently, I can't rely on using pkg-config in Makefiles.

The libs query (pkg-config --libs) is fine. Thanks...

Not sure if this repository is related to this issue, but how could I get an Airspy Mini device to work with GNU Radio on a Windows machine? I've installed GR 3.9 with osmo and soapy but neither one recognizes the device, whereas SDR# detects it fine. Do I need to install any package with conda, or is there zero support for GR Windows?

Error occured onDebian 7.0.4 when installing gr-osmosdr via pybombs:

airspy.h is installed in /usr/local/include/libairspy/ and called when making gr-omsosdr. This fails due to the fact that "airspy_commands.h", as specified in l. 29 of airspy.h is not present.

Please tell me if you need more details or error logs.

On some systems clang-based buld fails:

/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:470:23: error: always_inline function '_mm_set_ps' requires target feature 'mmx', but would be inlined into function 'translate_fs_4' that is compiled without support for 'mmx'
        ALIGNED __m128 rot = _mm_set_ps(hbc, 1.0f, -hbc, -1.0f);
                             ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:474:9: error: always_inline function '_mm_loadu_ps' requires target feature 'mmx', but would be inlined into function 'translate_fs_4' that is compiled without support for 'mmx'
                vec = _mm_loadu_ps(buf);
                      ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:475:9: error: always_inline function '_mm_mul_ps' requires target feature 'mmx', but would be inlined into function 'translate_fs_4' that is compiled without support for 'mmx'
                vec = _mm_mul_ps(vec, rot);
                      ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:476:3: error: always_inline function '_mm_storeu_ps' requires target feature 'mmx', but would be inlined into function 'translate_fs_4' that is compiled without support for 'mmx'
                _mm_storeu_ps(buf, vec);
                ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:123:15: error: always_inline function '_mm_set_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
        __m128 acc = _mm_set_ps(0, 0, 0, 0);
                     ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:139:19: error: always_inline function '_mm_loadu_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        __m128 head1 = _mm_loadu_ps(queue);
                                       ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:140:19: error: always_inline function '_mm_load_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        __m128 kern1 = _mm_load_ps(kernel);
                                       ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:141:19: error: always_inline function '_mm_loadu_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        __m128 head2 = _mm_loadu_ps(queue + 4);
                                       ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:142:19: error: always_inline function '_mm_load_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        __m128 kern2 = _mm_load_ps(kernel + 4);
                                       ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:144:18: error: always_inline function '_mm_mul_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        __m128 mul1 = _mm_mul_ps(kern1, head1);
                                      ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:145:18: error: always_inline function '_mm_mul_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        __m128 mul2 = _mm_mul_ps(kern2, head2);
                                      ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:147:11: error: always_inline function '_mm_add_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        mul1 = _mm_add_ps(mul1, mul2);
                               ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:149:10: error: always_inline function '_mm_add_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                        acc = _mm_add_ps(acc, mul1);
                              ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:181:17: error: always_inline function '_mm_loadu_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                __m128 head = _mm_loadu_ps(queue);
                              ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:182:17: error: always_inline function '_mm_load_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                __m128 kern = _mm_load_ps(kernel);
                              ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:183:16: error: always_inline function '_mm_mul_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                __m128 mul = _mm_mul_ps(kern, head);
                             ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:184:9: error: always_inline function '_mm_add_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
                acc = _mm_add_ps(acc, mul);
                      ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:202:13: error: always_inline function '_mm_add_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
        __m128 t = _mm_add_ps(acc, _mm_movehl_ps(acc, acc));
                   ^
/wrkdirs/usr/ports/comms/airspy/work/airspyone_host-1.0.9-18-gbfb6670/libairspy/src/iqconverter_float.c:202:29: error: always_inline function '_mm_movehl_ps' requires target feature 'mmx', but would be inlined into function 'process_fir_taps' that is compiled without support for 'mmx'
        __m128 t = _mm_add_ps(acc, _mm_movehl_ps(acc, acc));
                                   ^

I have a new airspy HF+ and plugged it in to my raspi 3 b+ running raspbian stretch

[ 1265.386636] usb 1-1.2: USB disconnect, device number 6
[ 2857.950265] usb 1-1.1.2: USB disconnect, device number 4
[ 2859.785473] usb 1-1.1.2: new high-speed USB device number 7 using dwc_otg
[ 2859.916146] usb 1-1.1.2: New USB device found, idVendor=03eb, idProduct=800c
[ 2859.916160] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2859.916168] usb 1-1.1.2: Product: AIRSPY HF+
[ 2859.916176] usb 1-1.1.2: Manufacturer: www.airspy.com
[ 2859.916186] usb 1-1.1.2: SerialNumber: AIRSPYHF SN:C852948094343FFC

You can see the kernel sees it, but running airspy_info can't find it.

root@airspy:~/openwebrx# airspy_info 
airspy_lib_version: 1.0.9
airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)

This bug steve-m/librtlsdr#13 will apply to this airspy_rx when running on a 32-bit OS (ARM).

host/airspy-tools/src/airspy_rx.c

I can't test it yet, as I don't have Airspy hardware, but it will have exactly the same problem on a 32 bit OS.