New Airspy R2/Mini driver development

Good day all,

I have been an early adapter when it comes to the Airspy SDR receivers, the R2 was my first buy and soon after there was also the Mini. The challenge with the Airspy is its high sample rate and USB communication, they will perform at there best if they have a dedicated USB interface with a good quality USB cable, if you don’t give this any attention you will be disappointed. That being said, I was really surprised about recent “bad” performance when using it with my SatNOGS client. This brought me to the following:

Maybe others already have seen my query via this community to get some idea on how other Airspy R2/Mini SDR users are experiencing it performance when using it with a SatNOGS ground-station.

There where not many responses, but looking at the ones that where there I saw similar issues in there reception.

As you know the SatNOGS client uses the Soapy framework in combination with gr-soapy to communicate with the SDR, this opens the possibility to have a generic way to build the software, you only need a Soapy 0.7 SDR module and you can use it your ground-station.

So if there is some SDR related issue, we need to look at the Soapy 0.7 Airspy driver. I already ran into issues before where I wanted to combine two Airspy receivers on the same computer and discovered that the serial= function wasn’t available. Gain, as can be read on this wiki page is also an issue.

Then I saw a twitter posting that Albin Stigo was working on Soapy AirspyHF improvements and I asked if this was also possible with the R2 and Mini. So I shared some recent waterfall data, that was created when using the PothosWare SoapyAirspy master branch, his first response was, yes, this looks like buffer overruns and his AirspyHF upgrades could also be used with the R2 and Mini. The next couple of days he created a new git repository and came pretty soon with the initial release. Have a look at the repository and don’t forget the issue page.

After a couple of version I am now running with the latest v2 branch and after more then 48 hours I can see a clear difference in performance on both the R2 and the Mini.

So I am looking for others that will also try this new version.

There are a couple of steps that you need to take:

  • Build the source
  • Alter your satnogs-client configuration.

Build from source:

First make sure you have the latest Airspy library installed, this can be done by following the steps on this airspyone_host github page.

Then build the v2 SoapyAirspy library from Albin, this can be done in the following way.
Make sure the following dependencies are in place. sudo apt-get install libsoapysdr-dev and maybe there are other for your specific environment.

mkdir source
cd source 
git clone https://github.com/ast/SoapyAirspy.git
mkdir build
cmake -Wno-dev ../
make

This will produce a libairspySupport.so to easily test this version and go back to to former release I just made a copy of the current one and after that copied the new version to the system location.

For x86 systems, this is done in the following way, arm users will have a different directory (/usr/lib/arm-linux-gnueabihf)

sudo cp /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libairspySupport.so /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libairspySupport.so.deb

sudo cp libairspySupport.so /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libairspySupport.so

Now we also need to change the /etc/default/satnogs-client file, I will first do this manually, so not with the help of sudo satnogs-setup

I guess it will currently look similar to the following example (serial and biastee are optional)

SATNOGS_SOAPY_RX_DEVICE="driver=airspy,serial=4a464c836701234,biastee=true"
SATNOGS_GAIN_MODE="Settings Field"
SATNOGS_OTHER_SETTINGS="LNA=9,MIX=6,VGA=11"

This is a so called manual gainmode when using the new driver and if you want to use it in this way, you need to device string in the following way:

Manual (gainmode=2) LNA, MIX and VGA values between 0 and 15 can be used

SATNOGS_SOAPY_RX_DEVICE="driver=airspy,serial=4a464c836701234,biastee=true,gainmode=2"
SATNOGS_GAIN_MODE="Settings Field"
SATNOGS_OTHER_SETTINGS="LNA=9,MIX=6,VGA=11"

Now with this release the Airspy native gain modes like linear and sensitive are also supported and these can be configured in the following way:

Linear (gainmode=0) LIN values between 0 and 21 can be used

SATNOGS_SOAPY_RX_DEVICE="driver=airspy,serial=4a464c836701234,biastee=true,gainmode=0"
SATNOGS_GAIN_MODE="Settings Field"
SATNOGS_OTHER_SETTINGS="LIN=14

Sensitive (gainmode=1) SENS values between 0 and 21 can be used

SATNOGS_SOAPY_RX_DEVICE="driver=airspy,serial=4a464c83670830b,biastee=true,gainmode=1"
SATNOGS_GAIN_MODE="Settings Field"
SATNOGS_OTHER_SETTINGS="SENS=14

When you copied the library and changed the values you can restart your satnogs-client sudo systemctl restart satnogs-client and with the following command you can look at the logs created by the next observation that you created and that will be using the new installed library. sudo journalctl -f -u satnogs-client -n 512 When the observation starts you will see a information similar to this:

Nov 09 13:30:55 exomars satnogs-client[67448]: [DEBUG] Found AirSpy device: serial =         306b65c7
Nov 09 13:30:55 exomars satnogs-client[67448]: [DEBUG] SoapyAirspy::SoapyAirspy(biastee) = true
Nov 09 13:30:55 exomars satnogs-client[67448]: [INFO] airspy_set_rf_bias(1)
Nov 09 13:30:55 exomars satnogs-client[67448]: [DEBUG] SoapyAirspy::SoapyAirspy(gainmode) = 0
Nov 09 13:30:55 exomars satnogs-client[67448]: [INFO] gainMode_ = 0
Nov 09 13:30:55 exomars satnogs-client[67448]: [DEBUG] setGainMode(0)
Nov 09 13:30:55 exomars satnogs-client[67448]: [INFO] airspy_set_rf_bias(1)
Nov 09 13:30:55 exomars satnogs-client[67448]: [INFO] gainMode_ = 0
Nov 09 13:30:55 exomars satnogs-client[67448]: [INFO] Using format CF32.
Nov 09 13:30:55 exomars satnogs-client[67448]: [DEBUG] sample type: 0, sample size 8
Nov 09 13:30:55 exomars satnogs-client[67448]: [DEBUG] setGainMode(0)
Nov 09 13:30:55 exomars satnogs-client[67448]: [DEBUG] SoapyAirspy::setAntenna(RX)
Nov 09 13:30:56 exomars satnogs-client[67448]: [DEBUG] SoapyAirspy::activateStream() flags=0 timeNs=0 numElems=0

I hope this information is enough so that others will give this development a try and see if they also have a better experience when using the Airspy R2 and or Mini SDR.

Source:

4 Likes

Currently the following stations are running with this new driver.

A R2 SatNOGS Network - Observations in gainmode=0 and LIN=14 configured (this system also has a LNA and therefor the LIN gain only 14)

A Mini SatNOGS Network - Observations in gainmode=2 and LNA=9,MIX=6,VGA=11 configured (this system also has a LNA)

@PE0SAT Thanks for this. I had compiled the new lib a couple weeks ago and installed it on my station 2134 that uses an R2.

When I walked through your installation method above, I realized that I had two instance of the lib in different locations.

/usr/local/lib/SoapySDR/modules0.7/libairspySupport.so
/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libairspySupport.so

Since I had only replaced the one in /usr/lib/x86_64-linux-gnu/ and not knowing which was/is getting called when the satnogs-client starts – I just replaced both just now. The result was a good observation so it didn’t break anything :upside_down_face: with these settings:

satnogs_other_settings: LNA=10,MIX=8,VGA=13
satnogs_rx_samp_rate: 2.5e6
satnogs_soapy_rx_device: driver=airspy,biastee=true

Good day, thanks for trying and please keep providing information and updates.

Some remarks:

If you want to know what driver is used, SoapySDRUtil --info should give you some information.

When you are going to use this new driver, satnogs_soapy_rx_device: driver=airspy,biastee=true needs an extra option. To see all options you can use SoapySDRUtil --probe="driver=airspy". In this case we are looking for gainmode.

Based on your example satnogs_soapy_rx_device: driver=airspy,biastee=true this needs to be:

satnogs_soapy_rx_device: driver=airspy,biastee=true,gainmode=2 gainmode=2 enables manual LNA,MIX and VGA options.

Please also test gainmode 0 and 1, 0 is linearity and 1 is sensitivity.

Currently I am testing with the following settings:

satnogs_gain_mode: Settings Field
satnogs_soapy_rx_device: driver=airspy,biastee=true,gainmode=0
satnogs_other_settings: LIN=14

The next test will be:

satnogs_gain_mode: Settings Field
satnogs_soapy_rx_device: driver=airspy,biastee=true,gainmode=1
satnogs_other_settings: SENS=14

In the meantime the github code is updated by the developer to fix some bugs, so maybe you can rebuild the driver.

3 Likes

Hello!
I have been running an Airspy Mini on my Satnogs station for a long time and I’m very interesting if an improved driver could be implemented in Satnogs.
At the moment I do not have the free time to build and test this new Soapy driver but will follow this subject with interest.

Thanks for your work!
//Lars SM0TGU

Hi Lars,

Currently we are, maybe in an alpha phase, the developer is also in contact with the PothosWare person that is responsible for the Airspy driver. When the driver is working and all bugs and issues are resolved it will go to the main package.

Currently the gainmode 0 (linear) and 2 (manual) are working find, but there seems to be an issue with gainmode 1 (sensitive).

When my extra R2 arrives I will do some further testing.

In the meantime I would love to see more people give this SoapyAirspy driver a try and share the experiences.

Thanks info.

I built Albin’s new driver and tried gainmode=1.

My result was this.
I found following messages but this looks OK.

[INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
1 Like

Thanks, that is very useful. I will share this with the developer.

Are you using a Airspy R2 or a Mini?

Oh, I forgot an important information. My Airspy is Mini (Firmware version v1.0.0-rc10-6).

1 Like

A question from the developer:

That log indicates Satnog did not consume data fast enough and there were an overrun. Sometimes it happens once or twice when you start receiving. It would be useful to know what hardware and if it happened only once or multiple times (multiple logs).

Source: Twitter

1 Like

Please forward to developer.

My hardware is Raspberry Pi 4B. Airspy Mini is connected to USB2.

Overrun occurs 1 - 17 times in one observation, but the timestamp is the same.
There were NO error passes, it was 9 out of 17 passes.

Log1:

Nov 15 06:04:22 gs2107 satnogs-client[4599]: [INFO] Using format CF32.
Nov 15 06:05:22 gs2107 satnogs-client[4599]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 15 06:05:23 gs2107 satnogs-client[4599]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 15 06:05:23 gs2107 satnogs-client[4599]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 15 06:05:23 gs2107 satnogs-client[4599]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 15 06:08:04 gs2107 satnogs-client[4599]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 15 06:08:04 gs2107 satnogs-client[4599]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 15 06:09:53 gs2107 satnogs-client[3100]: netrigctl_close: done status=Command completed successfully
Nov 15 06:09:54 gs2107 satnogs-client[4674]: POST OBSERVATION SCRIPT RUNNING

Log2:

Nov 16 09:52:10 gs2107 satnogs-client[11271]: [INFO] Using format CF32.
Nov 16 09:55:49 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:55:53 gs2107 satnogs-client[11271]: [INFO] SoapyAirspy::rx_callback: ringbuffer write timeout
Nov 16 09:56:12 gs2107 satnogs-client[6107]: netrigctl_close: done status=Command completed successfully
Nov 16 09:56:15 gs2107 satnogs-client[11334]: POST OBSERVATION SCRIPT RUNNING

Maybe it is easier to create and issue on GitHub and place a pointer to the issue on the community.

I would expect that we also want to know the exact satnogs configuration when you are testing gainmode=1

And what happens when you use for example GQRX with this Soapy driver and if it is responding in the same way.

Before I open issue on GitHub, I will share my test setting.

satnogs_api_token: ...
satnogs_soapy_rx_device: driver=airspy,gainmode=1
satnogs_antenna: RX
satnogs_rx_samp_rate: 3e6
satnogs_gain_mode: Settings Field
satnogs_other_settings: SENS=14
satnogs_complete_output_path: /tmp/.satnogs/data/complete
satnogs_station_id: '2107'
satnogs_station_lat: ...
satnogs_station_lon: ...
satnogs_station_elev: ...
enable_iq_dump: true
satnogs_artifacts_api_token: ...
satnogs_artifacts_enabled: true
udp_dump_host: 127.0.0.1
udp_dump_port: '57356'
satnogs_post_observation_script: /home/jh4xsy/postob.sh --id {{ID}} --tle {{TLE}}

But I not sure how to place a pointer to the issue on the community.

And GQRX test will be on this weekend.

1 Like

Hi, I have now upgraded my client to the latest RPi image so I can be a part of this testing.
I have an Airspy Mini.
What is the current status, should I wait for the fix for the overrun?

Hi Lars,

First get familiar with your new install, let me know if you are up for a new challenge.
We need to build the new driver, replace the current one and change some satnogs client Soapy driver settings.

The steps are in the top of this posting.

1 Like

Try new drivers.
My mini is working fine after I stopped saving the IQ dump file to USB storage. No timeout and overrun.

Drivers built and installed now, today at 18:30 UTC.
Results can be seen at my station:
https://network.satnogs.org/observations/?station=858

2 Likes

What gain mode are you using Lars?

I’m using mode 2. But, I’m not seeing the same log as described earlier in this thread. Do I need to set some DEBUG-info for Soapy? This is what I see.

Nov 29 21:07:38 SATNOGSSM0TGU satnogs-client[6957]: gr-satellites: Observation: 6811834, Norad: 43132, Name: 0_PICSAT, Script: satnogs_bpsk.py
Nov 29 21:07:38 SATNOGSSM0TGU satnogs-client[6957]: gr-satellites: Starting observation 6811834
Nov 29 21:07:40 SATNOGSSM0TGU satnogs-client[6957]: gr-satellites: running at 48000 sps
Nov 29 21:07:40 SATNOGSSM0TGU satnogs-client[6493]: satnogsclient.observer.observer - INFO - Start rotctrl thread.
Nov 29 21:07:40 SATNOGSSM0TGU satnogs-client[6493]: satnogsclient.observer.worker - INFO - Tracking initiated
Nov 29 21:07:40 SATNOGSSM0TGU satnogs-client[6493]: satnogsclient.observer.observer - INFO - Start rigctrl thread.
Nov 29 21:07:40 SATNOGSSM0TGU satnogs-client[6493]: satnogsclient.observer.worker - INFO - Tracking initiated
Nov 29 21:07:40 SATNOGSSM0TGU satnogs-client[6493]: rig_init: rig does not have rx_range!!
Nov 29 21:07:40 SATNOGSSM0TGU satnogs-client[6493]: network_open: hoststr=127.0.0.1, portstr=4532
Nov 29 21:07:41 SATNOGSSM0TGU satnogs-client[6493]: satnogsclient.observer.observer - INFO - Start gnuradio thread.
Nov 29 21:07:43 SATNOGSSM0TGU satnogs-client[6996]: [INFO] Using format CF32.

Just to be sure, this is the module in use. Correct? (0.2.0-a9695d7)

Lib Version: v0.7.2-2
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr
Search path:  /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7
Search path:  /usr/local/lib/arm-linux-gnueabihf/SoapySDR/modules0.7                (missing)
Search path:  /usr/local/lib/SoapySDR/modules0.7                                    (missing)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libHackRFSupport.so  (0.3.3)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libLMS7Support.so    (20.10.0)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libRedPitaya.so      (0.1.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libairspySupport.so  (0.2.0-a9695d7)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libaudioSupport.so   (0.1.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libbladeRFSupport.so (0.4.1)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libmiriSupport.so    (0.2.5)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libosmosdrSupport.so (0.2.5)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libremoteSupport.so  (0.5.2)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/librfspaceSupport.so (0.2.5)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/librtlsdrSupport.so  (0.3.2)
Module found: /usr/lib/arm-linux-gnueabihf/SoapySDR/modules0.7/libuhdSupport.so     (0.4.1)

The debug log is removed from the driver by the developer, therefor no details in the log output.

Could you also try gain mode 0 and 1, I am currently running in 0 with LIN=14, gain mode 1 seems to have an issue with the R2 but with the Mini it should be fine.

My values are maybe lower because I also use a LNA.