Hello, can someone point me to correct wiki or documentation how to install/setup HackRF with the Docker SatNOGS installation? I have search the forum but do not know where to start.
Thanks!
1 Like
What installation scheme are you using ?
Support info:
{
“versions”: {
“satnogs-client”: “unknown”,
“satnogs-ansible”: “unknown”,
“satnogs-flowgraphs”: “unknown”,
“gr-satnogs”: “unknown”,
“gr-soapy”: “unknown”,
“gnuradio”: “unknown”,
“satnogs-config”: “1.0”
},
“state”: {
“is-applied”: false,
“pending-tags”: null
},
“system”: {
“date”: “2025-10-15T07:57:27.479754+00:00”,
“platform”: {
“system”: “Linux”,
“node”: “satnogs-config”,
“release”: “6.12.47+rpt-rpi-v8”,
“version”: “#1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16)”,
“machine”: “aarch64”,
“processor”: “”
},
“memory”: {
“total”: 3981299712,
“available”: 3606179840,
“percent”: 9.4,
“used”: 273731584,
“free”: 1822244864,
“active”: 623136768,
“inactive”: 1316392960,
“buffers”: 103825408,
“cached”: 1781497856,
“shared”: 10031104,
“slab”: 157863936
},
“disk”: {
“total”: 30631604224,
“used”: 6516207616,
“free”: 22539911168,
“percent”: 22.4
}
},
“configuration”: {
“satnogs_antenna”: “TX/RX”,
“satnogs_api_token”: “[redacted]”,
“satnogs_artifacts_api_post_interval”: “60”,
“satnogs_artifacts_enabled”: true,
“satnogs_dc_removal”: false,
“satnogs_dev_args”: “bias_tx=true”,
“satnogs_gain_mode”: “Settings Field”,
“satnogs_log_level”: “DEBUG”,
“satnogs_network_api_post_interval”: “60”,
“satnogs_network_api_query_interval”: “120”,
“satnogs_other_settings”: “AMP=0,LNA=40,VGA=48”,
“satnogs_ppm_error”: “0”,
“satnogs_rx_samp_rate”: “8e6”,
“satnogs_soapy_rx_device”: “driver=hackrf”,
“satnogs_station_elev”: “7”,
“satnogs_station_id”: “2830”,
“satnogs_station_lat”: “59.453”,
“satnogs_station_lon”: “17.890”,
“satnogs_waterfall_min_value”: “-90”
}
}
I can add that I followed the installation guide including RPi installation from start.
Then I read this thread: Satnogs-client docker can't see any hardware devices - #3 by thebouleoffools
“With the docker stack, we don’t need gnuradio, soapy, or the sdr packages on the host.”
So I’m not sure if I should do any more installations for HackRF to make it work in Docker.
If you’re using the official docker stack and not installing a bunch of sdr packages on the host, the ansible part of that stack will take care of the udev rules and everything necessary on the host.
And yes, it is accurate that you do not need to install hackrf stuff on the host. First it cannot be used in the container, second it might instead interfere with conflicting udev rules.
The images are packed with everything we have supported in the past.
If it is the official stack and it is up and running, you can issue this to list all the soapy packages installed: docker exec -it satnogs_satnogs-client dpkg -l 'soapysdr*'
For me it is:
ii soapysdr-module-airspyhf:arm64 0.2.0-2 arm64 Soapy AirspyHF - AirspyHF device support for Soapy SDR.
ii soapysdr-module-plutosdr:arm64 0.2.1-4 arm64 Soapy PlutoSDR - PlutoSDR device support for Soapy SDR.
ii soapysdr-tools 0.8.1-3 arm64 software defined radio interface library tools
un soapysdr0.8-module <none> <none> (no description available)
ii soapysdr0.8-module-airspy:arm64 0.2.0-3+b1 arm64 Airspy device support for SoapySDR
ii soapysdr0.8-module-airspyhf:arm64 0.2.0-2 arm64 Soapy AirspyHF - AirspyHF device support for Soapy SDR.
ii soapysdr0.8-module-all:arm64 0.8.1-3 arm64 All device support for SoapySDR (metapackage)
ii soapysdr0.8-module-audio:arm64 0.1.1-4+b1 arm64 Audio device support for SoapySDR
ii soapysdr0.8-module-bladerf:arm64 0.4.1-4+b1 arm64 bladeRF device support for SoapySDR
ii soapysdr0.8-module-hackrf:arm64 0.3.3-5+b1 arm64 HackRF device support for SoapySDR
ii soapysdr0.8-module-lms7:arm64 22.09.1+dfsg-1+b2 arm64 Lime Microsystems LMS7 device support for SoapySDR
ii soapysdr0.8-module-mirisdr:arm64 0.2.5-8 arm64 Mirics SDR device support for SoapySDR
ii soapysdr0.8-module-osmosdr:arm64 0.2.5-8 arm64 OsmoSDR device support for SoapySDR
ii soapysdr0.8-module-plutosdr:arm64 0.2.1-4 arm64 Soapy PlutoSDR - PlutoSDR device support for Soapy SDR.
ii soapysdr0.8-module-redpitaya:arm64 0.1.1-4+b1 arm64 RedPitaya device support for SoapySDR
ii soapysdr0.8-module-remote:arm64 0.5.2-3+b2 arm64 Use SoapySDR devices over network (client module)
ii soapysdr0.8-module-rfspace:arm64 0.2.5-8 arm64 RFSpace device support for SoapySDR
ii soapysdr0.8-module-rtlsdr:arm64 0.3.3-1 arm64 RTL-SDR device support for SoapySDR
ii soapysdr0.8-module-uhd:arm64 0.4.1-3+b3 arm64 UHD device support for SoapySDR
First of all, thank you very much @SA2KNG for your support!
Yes, I used the official stack, I just run the installation command according to the Wiki after a fresh install of RPi OS:
curl -sfL https://satno.gs/install | sh -s --
The soapy packages list gives me this (note that I have soapysdr0.7, not 0.8 as you have):
ii soapysdr-module-airspyhf:arm64 0.2.0-1 arm64 Soapy AirspyHF - AirspyHF device support for So>
ii soapysdr-module-plutosdr:arm64 0.2.1-2 arm64 Soapy PlutoSDR - PlutoSDR device support for So>
ii soapysdr-tools 0.7.2-2 arm64 software defined radio interface library tools
un soapysdr0.7-module <none> <none> (no description available)
ii soapysdr0.7-module-airspy:arm64 0.1.2-2 arm64 Airspy device support for SoapySDR
ii soapysdr0.7-module-airspyhf:arm64 0.2.0-1 arm64 Soapy AirspyHF - AirspyHF device support for So>
ii soapysdr0.7-module-all:arm64 0.7.2-2 arm64 All device support for SoapySDR (metapackage)
ii soapysdr0.7-module-audio:arm64 0.1.1-2+b1 arm64 Audio device support for SoapySDR
ii soapysdr0.7-module-bladerf:arm64 0.4.1-2 arm64 bladeRF device support for SoapySDR
ii soapysdr0.7-module-hackrf:arm64 0.3.4-1~bpo11+1 arm64 HackRF device support for SoapySDR
ii soapysdr0.7-module-lms7:arm64 20.10.0+dfsg-2 arm64 Lime Microsystems LMS7 device support for Soapy>
ii soapysdr0.7-module-mirisdr:arm64 0.2.5-4 arm64 Mirics SDR device support for SoapySDR
ii soapysdr0.7-module-osmosdr:arm64 0.2.5-4 arm64 OsmoSDR device support for SoapySDR
ii soapysdr0.7-module-plutosdr:arm64 0.2.1-2 arm64 Soapy PlutoSDR - PlutoSDR device support for So>
ii soapysdr0.7-module-redpitaya:arm64 0.1.1-2 arm64 RedPitaya device support for SoapySDR
ii soapysdr0.7-module-remote:arm64 0.5.2-1 arm64 Use SoapySDR devices over network (client modul>
ii soapysdr0.7-module-rfspace:arm64 0.2.5-4 arm64 RFSpace device support for SoapySDR
ii soapysdr0.7-module-rtlsdr:arm64 0.3.2-1satnogs1 arm64 RTL-SDR device support for SoapySDR
ii soapysdr0.7-module-uhd:arm64 0.4.1-1 arm64 UHD device support for SoapySDR
Then I probe when the HackRF is connected to the RPI:
sudo docker exec -ti satnogs_satnogs-client SoapySDRUtil --probe
And I get this:
Probe device
[ERROR] avahi_client_new() failed: Daemon not running
[ERROR] avahi_client_new() failed: Daemon not running
[INFO] [UHD] linux; GNU C++ version 10.2.1 20210110; Boost_107400; UHD_3.15.0.0-4+b1satnogs1
ERROR: Unable to create Avahi DNS-SD client :Daemon not running
[WARNING] Unable to scan ip: -26
So, I remove the HackRF and connect a RTL-SDR instead to the same USB port and re-run the probe, then I get this (note the “Found Micro R820T tuner”)
Probe device
[ERROR] avahi_client_new() failed: Daemon not running
[ERROR] avahi_client_new() failed: Daemon not running
[INFO] [UHD] linux; GNU C++ version 10.2.1 20210110; Boost_107400; UHD_3.15.0.0-4+b1satnogs1
ERROR: Unable to create Avahi DNS-SD client :Daemon not running
[WARNING] Unable to scan ip: -26
Found Rafael Micro R820T tuner```Did you start with a blank newly installed Raspberry Pi install image ?
Did you start with a blank newly installed Raspberry Pi install image ?
Hi Jan,
yes I did.
1 Like
You should still specify the actual SDR, else it will just pick one (audio) and give you something.
Use for example: --probe="driver=hackrf"
Do note that the container isn’t guaranteed to handle re-plugging of usb devices gracefully, sometimes you need to restart it.
sudo docker restart satnogs_satnogs-client
I actually don’t remember if the gnuradio-3.8 or gnuradio-3.10 images are default, I’m pretty sure it’s the older and I have specified latest master (experimental). So that is the explanation of soapy 0.7 vs 0.8
Sorry - no luck. Tried several USB ports and restarted the docker several times. Probing with --probe=“driver=hackrf” and just get:
Error probing device: no hackrf device matches
Note! I used the HackRF with Windows and it works without any problem. It also worked without any problem with the RPi 4 and the legacy SatNOGS installation
What about lsusb on the host?
Jan | PE0SAT
lsusb on host gives:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1d50:6089 OpenMoko, Inc. Great Scott Gadgets HackRF One SDR
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
1 Like
Looking good, now lets check if there is a /etc/udev/rules.d/*hackrf*.rules file.
Please also share what is in the file. cat *hackrf*.rules I am not sure how the file is called that is the reason I use * maybe there are even more then one.
Jan | PE0SAT
2 Likes
- There is no hackrf .rules files present at /etc/udev/rules.d/ on the host
- There is no .rules file present at all on the docker container
They should be installed in /etc/udev/rules.d/53-hackrf.rules by satnogs-setup (ansible).
OK, then I guess something did not work during installation. What should I do, re-install everything from start or?
I don’t know if this is an error in this specific installation or a installation bug ?
You can create the file manually to solve it for now.
This should be in the file /etc/udev/rules.d/53-hackrf.rules
# HackRF Jawbreaker
ATTR{idVendor}=="1d50", ATTR{idProduct}=="604b", SYMLINK+="hackrf-jawbreaker-%k", MODE="660", GROUP="plugdev"
# HackRF One
ATTR{idVendor}=="1d50", ATTR{idProduct}=="6089", SYMLINK+="hackrf-one-%k", MODE="660", GROUP="plugdev"
# rad1o
ATTR{idVendor}=="1d50", ATTR{idProduct}=="cc15", SYMLINK+="rad1o-%k", MODE="660", GROUP="plugdev"
# NXP Semiconductors DFU mode (HackRF and rad1o)
ATTR{idVendor}=="1fc9", ATTR{idProduct}=="000c", SYMLINK+="nxp-dfu-%k", MODE="660", GROUP="plugdev"
# rad1o "full flash" mode
KERNEL=="sd?", SUBSYSTEM=="block", ENV{ID_VENDOR_ID}=="1fc9", ENV{ID_MODEL_ID}=="0042", SYMLINK+="rad1o-flash-%k", MODE="660", GROUP="plugdev"
# rad1o flash disk
KERNEL=="sd?", SUBSYSTEM=="block", ENV{ID_VENDOR_ID}=="1fc9", ENV{ID_MODEL_ID}=="0082", SYMLINK+="rad1o-msc-%k", MODE="660", GROUP="plugdev"
#
This file also depends on a group membership, the user running the docker container needs to be a member of group plugdev
After you installed this file and made sure the group membership is in place, you can trigger udev or reboot the system.
The you should be able to probe the hackrf successfully.
Jan | PE0SAT
Thanks, I have done this now but it is still not possible to probe the HackRF in the docker container.
sudo docker exec -ti satnogs_satnogs-client SoapySDRUtil --probe="driver=hackrf"
Gives:
######################################################
## Soapy SDR -- the SDR abstraction library ##
######################################################
Probe device driver=hackrf
Error probing device: no hackrf device matches
Then my guess is, that the user running the satnogs container isn’t part of the plugdev group.
The a quick and dirty change the MODE="660" statement in the hackrf ules file to MODE="666" then everyone can read write to this device. (reboot after the change and try again)
Jan | PE0SAT
Checking a docker install to see if this possible an image bug?
Looking at and docker install I had lying around:
There are only two rules files and no hackrf version
Jan | PE0SAT