SoapyAirspy install in Debian fails now that apt-key is depreciated

Hi,

First time posting. I have had a station 3276 up and testing for a few weeks with moderate success. After continuous tweaking I decided to upgrade from my raspberry pi to a linux server to remove local RFI. From there I upgraded from a nooelec RTL-SDR to an Airspy R2. Multiple folks suggested in other posts that I could get better performance with a better quality SDR.

I made the changes in the config in RX_DEVICE, GAIN_MODE, etc… but the receiver isn’t found so I following the advice on the wiki to install SoapyAirspy
https://github.com/pothosware/SoapyAirspy/wiki

The first step in dependencies is to run sudo add-apt-repository -y ppa:myriadrf/drivers
to add the RF drivers needed to support the Airspy

Debian 11 has depreciated apt-key so that repository wont be used because debian wont pull ubuntu keys

Attempting to force the issue i added the [ trusted=yes] to the repositories in /etc/apt/sources.list.d
deb [trusted=yes] Index of /myriadrf/drivers/ubuntu focal main

I also modified “sudo apt-get update” to “sudo apt-get update --allow-insecure-repositories”

I have been round and round trying to get this to work, to get a clean install of SoapyAirspy to use the new SDR with no luck. I get bogged down in NO_PUBKEY and apt-secure(8) but all of the instructions on how to do this are outdated before apt-key was depreciated and this install was straight forward and easy.

The instructions on how to use an airspy are all for Ubuntu and the SatNOGS wiki states " Other distributions are not supported by SatNOGS Client Ansible, as the pre-built packages won’t be compatible. Thus, while derived from Debian, SatNOGS Client Ansible is known to break for Ubuntu and Linux Mint."

Any recommendation on how to get SoapyAirspy drivers installed would be hugely helpful.

-Cheers

Hi,
A lot here to unpack (:
These are my recommendations from my personal experience over the years.

Naked boards tends to do this, for RF work I use metal RPi cases. Also RFI chokes on usb, power and network.

Yes, but there are a lot of good rtl’s out there as well. However, tweaking the sdr pales in comparison what can be accomplished with a LNA at the antenna feedpoint. If there’s close by interference it can still be a problem thou, so getting the antenna away from electronics is next up up the list.

Generally I would suggest staying away from external sw when starting up a station, the ones included in the SatNOGS repo has been tried and tested over a long time. Some SDR’s do need external sw thou, and that leads to the conclusion to not start off with a SDR that is not supported out of the SatNOGS box.

IIRC Debian and Ubuntu use the same signing key system, so it’s only a matter of getting the keys installed and that can differ a small bit. I would be careful when mixing and matching deb/ubuntu because the many package versions does not track perfectly.

This usually means that some dependency is named a little bit different, but will probably build on a Debian dist that is closely matched on the relevant packages. Debian -- Packages search on oldstable (debian 11) for the package name, if not found, remove numbers and dashes from the end of the package name.

I have not been working with Aispy, but perhaps @PE0SAT or someone else can chime in on those specifically.

Hi,

I have recently gone through the exercise of rebuilding my RPi/RTL-SDR SatNOGS stations and ran into the encryption key problem. These are part of my notes from the install…in particular the fix for the encryption key problem. It is simply just that the original version has expired and you need a new key.

Fix Expired SatNOGS Repository Encryption Key

In the RPi the repository info is stored in the ‘/etc/apt/’ directory/subdirectories and consists of ‘.list’ files with links to the repositories and matching ‘.gpg’ files (sometimes ‘.asc’ or ‘.key’) that contain the encrypted keys to secure those files. The encrypted key files have an expiry date.

The SatNOGS repository key in the Ansible 20220910 image has expired and will give a EXPKEYSIG error if accessed. Because of this the update in a subsequent step will fail. To avoid this it is necessary to download the latest key file for the associated SatNOGS repository link from the master OpenSUSE SatNOGS repository.

The link pointing to the master OpenSUSE SatNOGS repository is stored in the file ‘/etc/apt/sources.list.d/satnogs.list’ and the corresponding encryption key file is stored in the file ‘/etc/apt/trusted.gpg.d/satnogs.gpg’.

The default version of the SatNOGS repository in the Ansible 20220910 image currently points to a Raspbian 11 (Bullseye) repository, so the updated encryption key file should correspond to that version. It is worth quickly checking because some info on the internet suggests an older Raspbian 10 version is used. I suspect this info is old because the Raspbian 11 repository works fine. To check use the cat command to look at the contents.

The relevant line should look like this:

$ cat /etc/apt/sources.list.d/satnogs.list

deb http://download.opensuse.org/repositories/home:/librespace:/satnogs/Raspbian_11 ./

If this is correct they you can simply proceed to downloading the Raspbian 11 encryption key. If not you can simply update the ‘satnogs.list’ file using an editor to match the line above.

The command to load the encryption key into the ‘satnogs.gpg’ file is as follows. Note that because it pipes the output of one command into another command using stdout it needs to be done as a single command:

$ wget -q -O - http://download.opensuse.org/repositories/home:/librespace:/satnogs-unstable/Raspbian_1 1 /Release.key | sudo gpg --dearmor - o /etc/apt/trusted.gpg.d/satnogs.gpg

What does this do? The ‘wget -q -O - ’ downloads the file ‘Release.key’ (the encryption key) from the repository in quite mode (‘-q’) and outputs it to stdout ( ‘-O -’). Because the file is in an OpenGPG ASCII armor format we need the ‘sudo gpg --dearmor’ command (note the two dashes) to unpack the file to a binary data format. The gpg option ‘-o /etc/apt/trusted.gpg.d/satnogs.gpg’ writes the data directly to the ‘satnogs.gpg’ file. It will prompt you to overwrite the existing version.

Note that some older documentation uses the ‘sudo apt-key --keyring’ command to convert from OpenGPG ASCII armor format but this is now depricated and will give error messages. Using gpg avoids these error messages.

After making these changes do a system reboot to refresh everything and make sure you are using the correct versions of software.

$ sudo reboot

Log back in to continue.

I know you are not using a RPi but I assume the process would be quite similar…I think you just get the right key. I can see a Debian_11 key file in /repositories/home:/librespace:/satnogs - openSUSE Download so I would be trying that.

I hope this helps you understand and resolve your encryption key error. Good luck with the rest.

Regards,
John – VK4JBE

1 Like

As @SA2KNG mentioned there is a lot that needs response and also up front some updates.

Let me reply to the Airspy part, yes it is a far better SDR then the RTL-SDR but also need some TLC :wink:

For now running a SatNOGS station on a x86 computer you need to use Debian old-stable code name BULLSEYE (Debian 11)

The default install is mainly configured around the use of a RTL-SDR and all the dependencies and configurations are in place.

When you want to use another SDR a couple of dependencies and configuration needs to be in place and sorry to say, one needs some Unix experience.

Up front, you don’t need to add any repositories and I will try and explain the steps needed:

  • First we need to make sure the Airspy kernel module isn’t loaded when the SDR is connected, this is done by make sure the following file is present in /etc/modprobe.d/airspy-blacklist.conf

cat /etc/modprobe.d/airspy-blacklist.conf

#
# Block AirSpy kernel module from loading
#
blacklist airspy
#

There are ways to make sure the module isn’t already loaded and remove it, but for now after creating this file, reboot the system.

  • Now we need to make sure udev - Dynamic device management has the right configuration to recognize the SDR when it is connected. This is done with the help of configuration files in /etc/udev/rules.d for the Airspy Min and R2 is something like 52-airspy.rules

cat /etc/udev/rules.d.52-airspy.rules

ATTR{idVendor}=="1d50", ATTR{idProduct}=="60a1", SYMLINK+="airspy-%k", MODE="660", GROUP="plugdev"

This description is telling us a couple of things and the most important one is, that only the device owner and members of the group plugdev can read and write from this device.

With the command id one can see if he or she is member of this group, below an example:

lab@hostname:~$ id
uid=1002(lab) gid=1002(lab) groups=1002(lab),4(adm),27(sudo),46(plugdev),112(usrp),998(satnogs)

Both the main user of the system and satnogs need to be member of the group plugdev this can be done with the following command: usermod -a -G plugdev satnogs and maybe also for others.

To make sure the group is applied and active, logout and login and check with id if it is now showing. If you are using a graphical user interface, reboot the system.

  • The last step to make sure it is working, check if the airspy packages are installed.

To make it possible to do some manual checks, we will install the airspy package and for the SatNOGS Soapy support we will add the airspy soapy driver.

sudo apt-get install airspy

sudo apt-get soapysdr0.7-module-airspy

When this is all done, we can do some basic checks:

After you connected the airspy you would see the following message if you run sudo dmesg -wT

[    1.874692] usb 2-4: Product: AIRSPY
[    1.874693] usb 2-4: Manufacturer: www.airspy.com
[    1.874694] usb 2-4: SerialNumber: AIRSPY SN:466C64C8306B65C7

When this is the case, execute airspy_info and that will show you:

Found AirSpy board 1
Board ID Number: 0 (AIRSPY)
Firmware Version: AirSpy NOS v1.0.0-rc10-6-g4008185 2020-05-08
Part ID Number: 0x6906002B 0x00000030
Serial Number: 0x466C64C8306B65C7
Supported sample rates:
	10.000000 MSPS
	2.500000 MSPS
Close board 1

Then the final check before changing the SatNOGS config is to see if the hardware is able to support the high airspy sample rates:

This is done with the following command:

airspy_rx -r /dev/null -t 2

Device Serial Number: 0x466C64C8306B65C7
Stop with Ctrl-C
Streaming at 9.999 MSPS
Streaming at 9.999 MSPS
Streaming at 10.000 MSPS
Streaming at 10.000 MSPS
Streaming at 10.000 MSPS
Streaming at 10.000 MSPS
Streaming at 10.000 MSPS

Lets see if this will help you to get it up and running.

Jan - PE0SAT

SatNOGS Debian install

1 Like

THANK YOU!

I was so happy to get several responses and I learned something great from all three of you. I couldn’t believe that multiple people took the time and effort to get back to me so quickly.

BLUF: I was mostly successful getting my linux based station online with the Airspy R2 receiver. Ultimately the Debian 11 VM that I am running on a VMware EXI host only allowed me to connect a USB 2.0 hardware driver as the OS didn’t support a 3.0. So I busted the read/write limits with the high-speed SDR which I could see when i ran “sudo dmesg -wT”.

I reverted my virtualized station back to using the the rtl-sdr because the lower data-rate was tolerated by my hardware. That said I took your advice and successfully used the airspy R2 on my raspberry pi 4B and tried a day’s worth of NOAA-15/18/19 passes to test the quality. My raspberry pi is POE with unshielded cables in an outdoor enclosure with other POE devices, so I have a lot of front end RFI mitigation work to do before sticking with that as a more permanent installation. I agree with SA2KNG, shielded cases, ferrite chokes and better cabling is on my horizon to knock down the noise.


Specific thoughts from your comments:
@vk4jbe that was the best explanation of the relationship between sources.list.d elements and trusted.gpg.d elements and how to successfully map and load keys. I was successful in updating my satnogs keys and I used the same advice on another project immediately. Thank you

@PE0SAT Thank you for making that so clear and concise. While ultimately I hit the I/O wall on my server using these instructions, they were 100% successful on my raspberry pi setup. Your instructions also gave me a better idea about the packages that come with the satnogs build and the deltas required to use an additional SDR. This blog post is a great record for how to pull this off. Thank you

Cheers!

2 Likes