SoapyAirspy::getNativeStreamFormat returns 65536 as fullScale. But the native format is signed short, so it shall in fact be 32767, right?

65536 (or rather 65535) would be more appropriate for unsigned short.

Thanks for this very interesting project!

I have been playing with Soapy and an Airspy when I noticed that the FFTs on my first samples did not always came out as expected. Looking closer I noticed that the 1st few complex samples always contained some 0s and from thereon on never again. This seems a bit strange and almost like either the first buffer has some wrong data in it or I am reading it wrong. Hopefully this is something I am doing wrong.

I allocate the buffers as such:

	vector<vector<char>> buffMem(1, vector<char>(SoapySDR::formatToSize("CF32") * mtu));
	vector<void *> buffs(1);
	for (size_t i = 0; i < 1; i++) buffs[i] = buffMem[i].data();
	int flags(0);
	long long timeNs(0);
	vector<vector<float>> sampleBuff(5 * 2048, vector<float>(2));		// Holds the IQ samples

then read a couple of sample with:

	for (int l = 0; l < 4; l++)
	{
		// Read stream
		int elementsRead = device->readStream(st, buffs.data(), mtu, flags, timeNs);

		cout << elementsRead * SoapySDR::formatToSize("CF32") << " bytes have been read. Flags = " << flags << endl;

		for (int i = 0; i < buffMem[0].capacity(); i += SoapySDR::formatToSize("CF32"))
		{
			deciCnt++;

			if (((i + 8) <= buffMem[0].capacity()) && deciCnt == 1)
			{
				// Bytes packed back into floats
				float ival;
				float qval;
				unsigned char ci[] = { buffMem[0][i + 0], buffMem[0][i + 1], buffMem[0][i + 2], buffMem[0][i + 3] };
				unsigned char cq[] = { buffMem[0][i + 4], buffMem[0][i + 5], buffMem[0][i + 6], buffMem[0][i + 7] };
				memcpy(&qval, &cq, sizeof(qval));
				memcpy(&ival, &ci, sizeof(ival));

				// Store the IQ values
				sampleBuff[sampleCount][0] = ival;
				sampleBuff[sampleCount][1] = qval;
				sampleCount++;

				deciCnt = 0;

			}
		}
	}

I am reading 2048 (MTU) elements at a time.

Output of the first few samples

0	9.75201e-007	0
1	-1.63161e-006	0
2	2.91294e-006	0
3	-5.7514e-006	0
4	1.00109e-005	0
5	-1.65721e-005	0
6	2.5934e-005	0
7	-4.02493e-005	0
8	6.21305e-005	0
9	-9.65394e-005	0
10	0.000161523	0
11	-0.000401581	0
12	-0.000173937	-0.000727539
13	-0.000135679	0.000232104
14	0.000481409	-0.000474067
15	-0.00017729	0.000708774`
...

Any idea what could be the cause of this?

As a side question is there some builtin byte packing function or is this pretty much the way everyone else also do it?

I am lucky to have both Airspy Mini and Airspy HF+ I have just installed all required packages, all utility packages except the ones for Python3 and relevant hardware packages (airspy) from PothosCore github for Ubuntu.

Executing
SoapySDRUtil --probe
when Airspy Mini is connected returns various info about the hardware and I can connect to it remotely and it works. When the same is tried with Airspy HF+ the below happens:

SoapySDRUtil --probe 
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device 
Error probing device: device_id missing.

The device itself seems to be undamaged tried with GQRX on another computer and it works. Is it just unsupported yet or is this unexpected behavior?

Other info that might be useful:

dmesg | tail
[ 1181.654312] usb 3-2: new high-speed USB device number 3 using xhci_hcd
[ 1181.787154] usb 3-2: New USB device found, idVendor=03eb, idProduct=800c
[ 1181.787171] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1181.787180] usb 3-2: Product: AIRSPY HF+
[ 1181.787188] usb 3-2: Manufacturer: www.airspy.com
[ 1181.787195] usb 3-2: SerialNumber: AIRSPYHF SN:<serial-no-redacted>

lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 03eb:800c Atmel Corp. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

SoapySDRUtil --info
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Lib Version: v0.6.1-myriadrf~xenial
API Version: v0.6.0
ABI Version: v0.6
Install root: /usr
Search path: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6
Search path: /usr/local/lib/x86_64-linux-gnu/SoapySDR/modules0.6
Search path: /usr/local/lib/SoapySDR/modules0.6
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libairspySupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libosmosdrSupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libremoteSupport.so
Loading modules... done
Available factories...airspy, null, osmosdr, remote, 

PothosUtil --system-info
Lib Version: 0.6.0-ppa1~xenial
API Version: 0.6.0
ABI Version: 0.6
Root Path: /usr
Data Path: /usr/share/Pothos
User Data: /home/<user>/.local/share/Pothos
User Config: /home/<user>/.config/Pothos
Runtime Library: /usr/lib/x86_64-linux-gnu/libPothos.so.0.6.0
Util Executable: /usr/bin/PothosUtil
Dev Include Path: /usr/include
Dev Library Path: /usr/lib/x86_64-linux-gnu

sh -c "uname -a;lsb_release -a"
Linux <hostname> 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

CPU is: AMD G-T56N (2) @ 1.650GHz

After some interesting discussions with the Airspy developer on Twitter, he pointed at some source code from LinRad which provides information on what registers to set (using airspy_r820t_write) to adjust the R820T2's IF bandwidth.

See here for the register values (and corresponding bandwidths): https://sourceforge.net/p/linrad/code/HEAD/tree/trunk/airspy.c#l383
and here for the register addresses: https://sourceforge.net/p/linrad/code/HEAD/tree/trunk/airspy.c#l968

Allowing adjustment of IF bandwidth gives another lever to adjust in optimising receive performance. It would be nice if all the R820T2 registers were documented somewhere, but I suspect the full documentation is only available under NDA, so making use of what information is available from other open source projects will have to do!

I guess the SoapySDR set/listBandwidth functions would be the correct place to expose these settings?

First of all thanks for the effort on this, its been very useful for me so far. I have run into a performance issue I didn't think would be a problem.

Im using this through the Soapy python bindings. I have a specific use cases where I need to capture ~2.5 seconds of samples at a time in a continuous loop at a fixed centre frequency. Im running an airspy R2 operating at 2.5 msps.

I found out quickly that capturing ~2.5 seconds in one go causes errors or hangs, even on a relatively recent core i5. So I redid the code so I read the ~2.5 seconds in chunks.

That then makes the computer happy but occasionally it still prints out a 'O' to standard output which, from looking at the SoapyAirspy code means the client can not keep up. Im not sure what exactly happens internally at that point but its occasional enough not to bother me too much (can I avoid it though?).

However, I am now running the same code on a less powerful machine. Now very frequently it will fail to read a chunk with return error code -4. It should, however, be able to keep up. I have done similar tests with (py)rtlsdr.

So hence this issue. Am I approaching this in the correct way (see code below)? Is there an optimal buffer/chunk size I should be using? Should I activate/deactivate the stream on every 2.5s instead of only once at the beginning/end?

Code (stripped to its essentials) below. It runs in its own dedicated process.

rx_stream = sdr.setupStream(SOAPY_SDR_RX, SOAPY_SDR_CF32)
sdr.activateStream(_rx_stream)

nb = 65536
buff = numpy.zeros(nb, dtype=numpy.complex64)
niter = int(math.ceil(samples_per_scan / nb))

while True:
    samples = numpy.zeros(niter*nb, dtype=numpy.complex64)
    for i in range(niter):
         sr = sdr.readStream(rx_stream, [buff], nb)
         samples[i*nb:i*nb+nb] = buff

sdr.deactivateStream(rx_stream)
sdr.closeStream(rx_stream)

If you request a sample rate that is not supported by the hardware, then no error is reported but the sample rate is not used.

There's no error checking or validation done at either the point of calling setSampleRate() or when airspy_set_samplerate is called here: https://github.com/pothosware/SoapyAirspy/blob/master/Streaming.cpp#L197

Callers can verify the sample rate against the values returned by listSampleRates() / getSampleRateRange() before deciding to use a sample rate, but the problem is then that other drivers don't support that API well (notably, rtlsdr doesn't implement getSampleRateRange() so working around the airspy problem then limits what you can do with rtlsdr unless you special-case one or the other based on the driver in use)

https://github.com/pothosware/SoapyAirspy/blob/master/Streaming.cpp#L147

I was expecting airspy_set_sample_type(dev, asFormat);

Everything appears to go well with the connection between the SoapySDR Remote server and my client until I try to run soapy_power. Please look at the attached screenshots. Other devices work fine with soapy_power, but not Airspy.

Apologies as I was offered hardware to complete this module last year but they've not responded to me since.

If anyone would like to have a go at the Airspy module be my guest as I don't know when I'll have a chance to look at this.

Hi,

I'm using rx_fm, which uses the SoapySDR, with an Airspy Mini.
The problem is that it won't terminate, the process stays there, using 100% of a processor.
I never get the prompt back, it just sits at Signal caught, exiting.

pi@rpi-rtl-sdr:~ $ /usr/bin/timeout 10 /home/pi/sdr/rx_tools/rx_fm -d driver=airspy -f 137.1M -s 60k -g 30 -p -2 -E deemp -F 9 - | /usr/bin/sox -t raw -e signed-integer -b 16 -r 60k -c 1 - rx_fm.wav rate 11025
Using device Airspy: serial=b5ac67dc2b128913
Found 1 channel(s) :
Channel 0 :
  Found 1 antenna(s): RX
  Found 3 gain(s): LNA MIX VGA
  Found 1 frequencies: RF
  Found 2 sample rates: 6000000 3000000
  Found 0 bandwidths:
[INFO] Using format CS16.
Tuner gain set to 30.00 dB.
Tuner error set to -2 ppm.
Bandwidth set to automatic resulted in 0 Hz.
Tuned to 137580000 Hz.
Oversampling input by: 32x.
Oversampling output by: 1x.
Buffer size: 4.27ms
Sampling at 1920000 S/s.
Output at 60000 Hz.
Signal caught, exiting!

I eventually have to sigkill the process.

I should add that while the above example uses timeout to terminate after 10 seconds, the same happens if I just stop it with ctrl+c.

This doesn't happen with rx_fm (SoapySDR) and an RTL-SDR, and looking at the rx_fm source, it doesn't make a distinction between SDRs, so it must be the SoapySDR Airspy module causing this.

This is on a Raspberry Pi 3B, completely up to date.
Fresh install from source code of SoapySDR, its Airspy module and rx_tools.

Hello friends:
Is anybody using rx_tools (https://github.com/rxseger/rx_tools) with Airspy?
Is possible activate bias-t?
rx_tools uses SoapyAirspy.
A lot of thank's 4 your help.

using rtl_airband or CubicSDR mostly when i startup my Airspy R2 i see a really poor noise floor, have to stop /start a few times to get it where it should be.
i don't see this on my SDRPlay rsp2 or rsp1a or my rtl-sdr dongles so i think this is airspy specific.

lee@probook:~$ SoapySDRUtil --info
## Soapy SDR -- the SDR abstraction library
ABI Version: v0.7
Install root: /usr
Search path: /usr/lib/SoapySDR/modules0.7
Search path: /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/lib/SoapySDR/modules0.7/libairspySupport.so  (0.1.2-e69ba77)
Module found: /usr/lib/SoapySDR/modules0.7/libremoteSupport.so  (0.4.3-b6819ea)
Module found: /usr/lib/SoapySDR/modules0.7/librtlsdrSupport.so  (0.2.4-5d49f03)
Module found: /usr/lib/SoapySDR/modules0.7/libsdrPlaySupport.so (0.1.0-3745fea)
Available factories... airspy, remote, rtlsdr, sdrplay
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

Hello,

I'm working on an application where I need to connect multiple SDRs of the same type (AirSpy R2). Each one has a different antenna so I need to be able to distinguish between them.

We can display connected devices with:

device_list = SoapySDR.Device.enumerate()
for device in device_list:
    print(device)

With two AirSpys connected this gives:

{device_id=0, driver=airspy, label=AIRSPY [260868c8:2673939b], serial=260868c8:2673939b}
{device_id=1, driver=airspy, label=AIRSPY [260868c8:266b479b], serial=260868c8:266b479b}

As in the C++ API, I want to be able to connect to a specific device i with:

sdr = SoapySDR.Device(device_list[i])
This works for the first SDR with device_id=0. However, the next device crashes! As per:

Traceback (most recent call last):
  File "./multi_connect_test.py", line 36, in <module>
    sdr2 = SoapySDR.Device(args)
  File "/home/bill/miniforge3/envs/cusignal-dev/lib/python3.6/site-packages/SoapySDR.py", line 1926, in __new__
    return cls.make(*args, **kwargs)
RuntimeError: Airspy device_id out of range [0 .. 1].

I believe this is a bug in the Python binding. Something to do with the device_id being a string, but somewhere it is being checked again an int range?

Any advice on workarounds would be appreciated, or I'm happy to work together to fix the bug.

Thanks,
Bill

(For more info, I've had a brief discussion on the forum: https://groups.google.com/g/pothos-users/c/-l1P1NFdfgQ)

ref: pothosware/SoapyOsmo#7

What bit packing is, summed up in one image: https://i.imgur.com/qXnWoEK.png?1
(data is only packed while travelling across the USB bus normally, but the packed data can be accessed if needed?!?, and packing is enabled, via sample_type RAW])
http://git.osmocom.org/gr-osmosdr/commit/?id=164a09fc11cec2d8b15b38e8b512fa542d6cecc7

Hello,

I'm using this command on a raspberry with an airspy mini:
./rx_fm -E wav -d driver=airspy -f 137.9125M -g LNA=14 - | /usr/bin/sox -t wav -e signed-integer -b 16 -c 1 - rx_test.wav

but this outputs a wav-file with silence.

Why is this? I'm expecting to hear static noise.

• VGA, MIXER, LNA
• LINEARITY, SENSITIVITY?

• - Basic instructions wiki: https://github.com/pothosware/SoapyAirspy/wiki
• - Add to list of supported modules in the sidebar
• - Add to homebrew package soapyairspy.rb
• - Add to PothosSDR windows installer
• - Debian packaging for drivers PPA
• - Deprecate SoapyOsmo[AirSpy]/disable by default
• - update SoapyOsmo wiki: https://github.com/pothosware/SoapyOsmo/wiki

I'm messing around with the pack option and noticed this post (also told by the developer) that 12Msps is supported by the Airspy R2 firmware with pack on. This also opens it up to 10M wide bandwidth, so I've been told.

https://twitter.com/airspy_com/status/726100205435805698

The problem is, or maybe it's just designed this way, neither OsmoSDR nor Soapy allow selection of this sample rate. So I went into osmosdr and removed the sample rate restriction, recompiled, and selected 12msps while using GR-Iridium. The performance dive bombed, at least visually by what I saw in the terminal when compared to a setting of 10msps. But what's interesting is using Airspy_RX and the 12msps setting in terminal maintained the full 12msps without hiccups it seemed.

Would it be possible to allow such a sample rate with Soapy Airspy? I'd be curious to see if anyone else has went down this path.

Hi,
I am running openwebrx with Airspy mini.

At 403 MHz the Airspy is about 1.5 kHz off. I tried to set the ppm value in the openwebrx config, but that does not affect anything. I tried even values -2000 to + 2000 but no change at all.

The developer of the openwebrx.de version of the software writes the problem would be in the API ?

I have checked the source code of the SoapyAirspy module, and it seems like it doesn't implement the necessary API, which basically makes the setting useless and also makes it impossible for OpenWebRX to correct the frequency offset. This is the second SoapySDR module that is lacking in that regard, the other seems to be the HackRF (see here). You are of course free to try and let me know if it does work, I'd be surprised if it does though.

Since this is beyond the scope of OpenWebRX, I can only advise you contact the developers of the SoapyAirspy module to implement the setFrequencyCorrection() API.

So here I am, can this be fixed pleae ?

Thanks,

Ben