Raspberry Pi 5, DragonOS, HackRF, All of It

Pi in hand, not the smaller of the versions, the sixteen gigabyte one- this post will go through a wizardly tale, summoning a dragon; DragonOS that is- a tale of setting up the Pi 5 with DragonOS. There were some challenges, some unique setup and some setup to consider- hardware included- since I include an uninterruptible power supply which is advertised to supply that 5 V, 5 A which the creators of the Raspberry Pi 5 have cursed us with- why not just have made it 12 V? Ok, gripe over. What follows is the adventure I took.

Over a few days, since I'd done this between other projects- October 29th through to November 1st, 2026- but you, following along, would only be... well, easily under an hour- easily under 30 minutes... not even 15 minutes... downloading the DragonOS image and flashing it may even take up more time than the setup that follows- getting control of your dragon, DragonOS.

A unique setup- good for the knowledge bank, a mix of headless setup with other unique input device(s). Don't have any extra peripherals and need a similar OS booted onto your Pi? This will help you out. I utilized an external touchscreen and further my Mac mini to get the job done- actually, as it turned out, since I can remote into the Pi anytime I want, the Mac drove the Pi over SSH eventually the whole way.

Chapter One- The Egg Hatches

Balena Etcher was the tool which flashed the OS onto the SD card... the DragonOS Pi64 image is a hefty file, a 5.0 GB download, but a 64 GB micro worked... the creator of the OS states a minimum of a 32 GB card. You are best off with a card rated A2 and V30, the two marks that mean fast small reads and steady writes- the official Raspberry Pi 64 GB A2 V30 card was $45.95 CAD at PiShop.ca, in stock (checked 2026-11-01). Etcher itself is a free download at etcher.balena.io.

Coming back to this, revisiting, confirming the action complete- indeed it had... The microSD card already held DragonOS, flashed from DragonOS_Pi64_Beta42.img.gz kept on an external SSD. Before moving the card to the Pi I wanted proof that it was the DragonOS card and not some other one. The image's first 512 bytes hold a disk signature that shows up on the card as the start of the PARTUUID value. Don't worry, keep following and you'll catch the command.

Both checks run on the Mac, in Terminal, with the card still in the reader. Print the signature bytes from the compressed image (the four bytes at offset 440, stored little-endian). Put your own path to the image file in place of mine.

gzip -dc /Volumes/ExternalSSD/DragonOS_Pi64_Beta42.img.gz | head -c 512 | xxd -s 440 -l 72

Print the same value from the card's boot partition and compare the two.

grep -o 'PARTUUID=[^ ]*' /Volumes/bootfs/cmdline.txt

At first I thought it to be the wrong image... no, just a formatting mixup- lucky I'd paid attention... Mine read 04a9 b278 in the image and 78b2a904 on the card, the same number written backwards. The card went into the Pi, the Pi drove an AOC 24" monitor on HDMI-A-1 and a small touch monitor on HDMI-A-2, with Ethernet as its only network link. I eventually ditched the AOC 24" monitor on HDMI-A-1 for more portability- that small touch screen is much easier to place, being 7" rather than 24"- the remote connection through the Mac was the ultimate setup for mobility.

With the microSD inserted into the Pi... that initial boot- an important one, don't touch it till it is done.

"wow it booted so fast" was my first reaction. The desktop came up with a circuit-board wallpaper and a pointer in the top left corner... and I had no mouse and no keyboard to move it. The Mac found the Pi on the network as raspberrypi.local at 192.168.1.xxx (your router hands out the last number), with SSH on port 22 closed to it.

First issues- no network connectivity- even when I'd selected Wi-Fi... something was amiss- sometimes with Macs, you gotta go into Settings > General > Sharing... have to set up that Internet Sharing to Ethernet or other... mine had been already set a time ago- Ethernet- for my setup was done with the Nzyme infrastructure in place and in mind... connecting those taps and node... well, that node directly by Ethernet to the Mac, the taps reporting into the node themselves with that Ethernet connection- all of it with Tailscale running in the background.

So, who holds the keys to the stronghold?

Chapter Two- The Locked Gate

Raspberry Pi images traditionally turn SSH on if an empty file named ssh sits on the boot partition. Mounted on the Mac, the card's boot partition shows up as bootfs.

Before we adventure further, the Pi 5 has an on/off switch now, compared to its older Pi 4 and under, which had not- one click does the job, but per Raspberry Pi's documentation a double click... I used a touch screen pen tip to do that through the case it's been installed into. A quick "press, press" does the trick. The docs spell it out- on the desktop a single press opens a window with shutdown, reboot and logout, two presses in quick succession shut it down cleanly, and holding the button forces a hard shutdown. The clean one ultimately saves your microSD card.

Back on the Mac, in Terminal, with the card in the reader. Create the empty file and eject the card cleanly (disk6 was my card; check yours with diskutil list).

touch /Volumes/bootfs/ssh

sync && diskutil eject disk6

The Pi booted again and port 22 stayed closed. The file had been consumed, so the switch had flipped, but sshd could not start. This DragonOS image ships with no SSH host keys, and the service that normally generates them is disabled. A server with no keys refuses to listen at all.

With no keyboard on the Pi, the fix had to run by itself at boot. A Raspberry Pi OS card can run a one-shot script from the kernel command line. This whole stretch happens on the Mac, with the card back in the reader and bootfs mounted. Two files on that partition are involved. The first is cmdline.txt, one long line of boot options- the hook gets added to the end of that same line, after a space, never on a line of its own. The second is a new file, firstrun.sh, saved next to it. On the next boot the Pi runs the script once, the script strips the hook back out of cmdline.txt, deletes itself and reboots. The first version of the script failed to open the gate. The second version generated the keys, added the Mac's public key to authorized_keys and enabled the service. Victory! Not so fast... not there yet.

On the Mac, keep a copy of the original first.

cp /Volumes/bootfs/cmdline.txt /Volumes/bootfs/cmdline.txt.orig

Open the file in a plain text editor in Terminal (control-O saves, control-X leaves).

nano /Volumes/bootfs/cmdline.txt

Add this to the end of the existing line, with a space before it. Do not run it- it is text that goes into the file.

systemd.run=/boot/firmware/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target

Print your Mac's public key, the one the Pi will trust. Copy the whole line it prints.

cat ~/.ssh/id_ed25519.pub

Create the script on the card. Everything inside it runs on the Pi, as root, during the next boot- not on the Mac. Put your copied key in place of the placeholder on the KEY= line. This is the working version trimmed to the lines that matter.

nano /Volumes/bootfs/firstrun.sh

#!/bin/bash
FW=/boot/firmware
KEY='ssh-ed25519 AAAA...your key here... you@yourmac'
U=$(getent passwd 1000 | cut -d: -f1); H=$(getent passwd 1000 | cut -d: -f6)
install -d -m 700 -o "$U" -g "$U" "$H/.ssh"
echo "$KEY" >> "$H/.ssh/authorized_keys"
chown "$U:$U" "$H/.ssh/authorized_keys"; chmod 600 "$H/.ssh/authorized_keys"
ssh-keygen -A
systemctl enable ssh
sed -i 's| systemd.run=[^ ]*||; s| systemd.run_success_action=[^ ]*||; s| systemd.unit=kernel-command-line.target||' "$FW/cmdline.txt"
rm -f "$FW/firstrun.sh"
exit 0

Make it executable, flush the writes and eject.

chmod +x /Volumes/bootfs/firstrun.sh

sync && diskutil eject disk6

The two lines that finally cracked it, inside that script- generate the missing host keys, then turn the service on at boot.

ssh-keygen -A

systemctl enable ssh

May need to do a round number two, even three... with the above directions, again append the one-shot hook to the single line in cmdline.txt (keep a copy of the original first), fix the script and let the Pi boot once more.

Card in the Pi, Pi booted twice on its own, and from the Mac, SSH by key finally answered. Use your Pi's address.

ssh dragon@192.168.1.xxx

A dragon is captured! Once out of our control, now via the Mac, we can tame the beast.

The journey continues- it's just begun.

Chapter Three- Naming the Dragon

SSH setup- the Mac, connected, some loose ends to take care of. Connect to the Pi through that SSH connection. From here on, every command runs on the Pi, typed into that SSH window on the Mac. Once inside, the dragon needed a name, a time zone and a Wi-Fi country code.

sudo raspi-config nonint do_hostname dragon

sudo timedatectl set-timezone America/Vancouver

sudo raspi-config nonint do_wifi_country CA

On the desktop a pop-up complained that the power supply could not deliver 5 V at 5 A, and another said updates were waiting. The Pi was running fine on its 3 A supply... let us tackle the administrative work first... that 5 V, 5 A concern will be taken care of shortly after. First the all-important update, install, upgrade... this comes first, so let's do that.

Halt! Mind your needs with the setup- in my case I'm adding some peripherals, one being a HackRF One... the original DragonOS image has been compiled for just such a device. Updates, upgrades and installs may break something- in my case I left the kernel alone, along with the desktop... so that the HackRF One still plays nice. It does. No problems, so do the same and be safe. A plain upgrade keeps a new kernel back on its own- the hold that makes that permanent is the pact in Chapter Six, before the big upgrade.

sudo apt-get update

sudo apt-get -y upgrade

Tailscale gives the Pi a private address on my own network of machines. Debian 13 needs the key and the repository list from Tailscale's package server.

sudo curl -fsSL https://pkgs.tailscale.com/stable/debian/trixie.noarmor.gpg -o /usr/share/keyrings/tailscale-archive-keyring.gpg

sudo curl -fsSL https://pkgs.tailscale.com/stable/debian/trixie.tailscale-keyring.list -o /etc/apt/sources.list.d/tailscale.list

sudo apt-get update && sudo apt-get -y install tailscale

Start the daemon and ask for a login link.

sudo systemctl enable --now tailscaled

sudo tailscale up --hostname=dragon

Chromium 156 on this build never gets past "Loading..." and fails even headless, with zygote errors in the log. Firefox opens the same page without trouble. With no keyboard on the Pi, the link has to open from SSH, which means pointing the command at the Wayland desktop. Put the login link in place of $URL.

export XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-0

setsid nohup firefox "$URL" >/tmp/firefox-ts.log 2>&1 </dev/null &

A pending Tailscale login also does not survive a reboot. I restarted the Pi once mid-login. The old link was dead. Running tailscale up again prints a new one.

Firefox on the Pi was still signed in to my personal Tailscale account. I own two separate tailnets (one for personal things, one for the AI and hardware machines), so check the account name on the Connect page before tapping the button. After I picked the hardware one, the Pi joined with a 100.x.x.x address of its own.

From the Mac, confirm the Pi answers by name over the tailnet.

ssh dragon@dragon

Chapter Four- One Dragon, One Name

For a while the Pi sat on Ethernet and on the StarLink Wi-Fi at the same time. Two network connections on one subnet are the setup that made the host rename itself node-000-2.local on my earlier Nzyme sensor fleet. The cause there was avahi, the mDNS service, hearing its own announcements arrive on a second interface and deciding another machine had taken its name. It did not happen to dragon... I wanted to keep it that way. The Wi-Fi profile stays saved- it just stops joining by itself.

sudo nmcli con mod StarLink connection.autoconnect no

sudo nmcli con down StarLink

To undo it later, switch autoconnect back on.

sudo nmcli con mod StarLink connection.autoconnect yes && sudo nmcli con up StarLink

Chapter Five- The Dark Night of the Dongle

The UPS went in next, a Waveshare UPS Module 3S with three 18650 cells (not included), so the Pi could ride through a power cut. Waveshare sells it for $21.99 USD and RobotShop Canada had it in stock at $31.41 CAD (both checked 2026-11-01). The warning about 5 A came straight back and the USB Wi-Fi adapter (an MT7612U) kept dropping off the bus. A small USB hub with a serial chip behind it showed up at the same time.

Counting the dongle's resets made the problem visible. It had reconnected 92 times in about half an hour, roughly every twenty seconds, each time with error -71. Half an hour of that is enough to make anyone doubt the board.

Count how often the kernel has reset the adapter since boot.

sudo dmesg -T | grep -c 'reset high-speed USB device'

A Pi 5 asks its power supply over USB-C whether it can give 5 A. A supply that does not speak USB Power Delivery, as this UPS does not, gets treated as weak. The Pi read 900 mA, showed the warning and capped every USB port at 600 mA in total.

Check the cap, the 5 V rail and the throttle flags.

sudo vcgencmd get_config usb_max_current_enable

sudo vcgencmd pmic_read_adc EXT5V_V

sudo vcgencmd get_throttled

On my Pi the voltage was fine at 5.22 V and get_throttled read 0x0, so it was not a brownout, just a failed negotiation. Raspberry Pi's bootloader documentation describes a setting, PSU_MAX_CURRENT, that tells the firmware to skip the negotiation and assume a supply of the given current. If the supply cannot really give 5 A, a heavy USB load will make the Pi throttle. The undo is to re-apply the saved copy of the old config.

Save the current bootloader config first.

sudo rpi-eeprom-config > ~/eeprom-config.bak.txt

Build a new config file that is the old one plus the new line.

{ cat ~/eeprom-config.bak.txt; echo "PSU_MAX_CURRENT=5000"; } > /tmp/eeprom-new.txt

Write it into the bootloader EEPROM. The tool reports "UPDATE SUCCESSFUL" when the flash verifies.

sudo rpi-eeprom-config --apply /tmp/eeprom-new.txt

sudo reboot

After the reboot the Pi reported a 5000 mA supply and usb_max_current_enable=1. The warning disappeared, the voltage read 5.22 V and the throttle flag stayed at 0x0. The dongle went from 92 resets to about one.

There was a question about viewing the power supply's status, the battery- the charge level... there is supposedly another data connection which provides this and can be verified on the Waveshare wiki page for the power supply unit- it isn't so straightforward- there is another cable provided which is labelled "battery"... luckily this connection doesn't fit anything on the Pi, since that socket puts out the raw voltage of the three cells in series, 9 V empty to 12.6 V full- this would fry your Pi- it's there for other applications such as robotics, or powering other devices and peripherals. I can't recall if jumper wires were included; my memory tells me they had not been (Waveshare's own contents list has none)- female to female- giggity- female to female jumper cables are necessary to complete this data connection.

To do this, power the Pi off, then run three wires from the UPS pin header to the Pi's 40-pin header: SDA to pin 3, SCL to pin 5 and GND to pin 6. The wiki's diagram adds a fourth wire, 5 V to 5 V, which feeds the Pi through the header- the Pi already drinks from the USB-C cable, so that one stays off. Then, back in the SSH window on the Pi, turn I2C on and look for the chip at address 0x41.

sudo raspi-config nonint do_i2c 0

sudo apt-get -y install i2c-tools python3-smbus

sudo i2cdetect -y 1

A 41 in that grid means the wiring is right, and the INA219.py demo linked from the wiki prints voltage, current, power and the charge percentage.

Leave that other cable which would connect into the "battery" spot to the side... Pis are too pricey to make silly mistakes like adding another 12 V into the poor thing, frying it... would be a shame. Save that cable though... never know if it'll come in handy.

Chapter Six- The Pact With the Kernel

With the power sorted I asked for everything to be updated, except whatever could damage the radio and Wi-Fi drivers. DragonOS on this Pi runs kernel 6.12.47. The pending update jumped to 6.18. A jump like that could upset the Wi-Fi and SDR drivers this Pi relies on. Reflashing the card is the only clean undo for a Pi with no keyboard that fails to boot. The bootloader package rpi-eeprom got the same protection, since my power fix lives in it.

A kernel is the core of the operating system, the part that talks to hardware. Holding it means the package manager skips it on purpose.

Save the list of installed packages as a rollback reference.

dpkg --get-selections > ~/pkg-selections.bak.txt

Hold the kernel packages and the bootloader package.

sudo apt-mark hold linux-image-rpi-2712 linux-image-rpi-v8 linux-headers-rpi-2712 linux-headers-rpi-v8 rpi-eeprom

Do a dry run first, then the real upgrade.

sudo apt-get full-upgrade -s

sudo apt-get -y full-upgrade

Afterwards the package manager still lists five "upgradable" packages. Those five are the held ones, kept that way until a kernel jump is a decision I make on purpose.

Chapter Seven- The Scrying Pool

Next I wanted the Pi's desktop on the Mac's screen. The Mac's built-in Screen Sharing connected to the Pi's wayvnc server, but the log said "Client handshake timed out" and the Mac asked for a password that did not exist. Apple's client cannot complete the handshake with wayvnc- typing a password changes nothing.

A browser works instead, with a private wayvnc listening only on the Pi itself with no password, a small bridge called websockify turning that into something a web page can read, and an SSH tunnel carrying it to the Mac. Security comes from binding to localhost and the encrypted tunnel, so never expose this port to the network.

The wayvnc config file, ~/wayvnc-dragon.conf on the Pi, holds two lines.

address=127.0.0.1
enable_auth=false

Install noVNC and websockify on the Pi.

sudo apt-get install -y novnc websockify

Start the private wayvnc on port 5901 (run this inside the desktop session).

wayvnc -C ~/wayvnc-dragon.conf 127.0.0.1 5901

Start the bridge from port 6080 to 5901 and serve the noVNC page.

websockify --web=/usr/share/novnc 127.0.0.1:6080 127.0.0.1:5901

On the Mac, open the tunnel.

ssh -f -N -L 6080:127.0.0.1:6080 dragon@dragon

Then visit this address in a browser.

http://localhost:6080/vnc.html?autoconnect=true&resize=remote

The dragon's whole desktop appeared in the browser, clickable. A launcher script on the Pi now brings it all up at every boot from ~/.config/labwc/autostart. A user autostart file replaces the system one, so the four default lines (pcmanfm-pi, wf-panel-pi, kanshi and lxsession-xdg-autostart) must be copied in first. Otherwise the panel and desktop never start.

DragonOS also ships its own wayvnc on port 5900 for every network interface, protected by a Pi login. That separate server is not part of this private route.

Chapter Eight- The Roar

On October 31 I asked whether a HackRF was connected to the Pi. The answer was no... the only radio on the bus was the Wi-Fi dongle. The HackRF One and its PortaPack (running Mayhem firmware) went onto the Pi in the early hours of November 1. I do not know yet which PortaPack model this is... H1, H2 or H4M... and the model decides how it gets charged.

The Pi's kernel log kept the story.

sudo dmesg -T | tail -40

First the device refused to take an address from the Pi, twice, with the same error -71 the Wi-Fi dongle had been throwing. About four minutes later it enumerated as "PortaPack Mayhem" on /dev/ttyACM0 with the USB ID 1d50:6018. Ten seconds after that, it re-enumerated as "HackRF One" with the USB ID 1d50:6089.

List the USB devices and look for the ID.

lsusb

Ask the HackRF tools to find it.

hackrf_info

It answered with the board and its serial number. When SDR++ already had the radio open, the same command printed "Resource busy". That only means another program has the device.

Two Doors Into HackRF Mode

I remember this as "DFU mode". The log says otherwise... the two paths do different jobs.

HackRF mode on a PortaPack. Mayhem is its own firmware running on the PortaPack's processor. The main menu has a "HackRF" entry that switches the unit into normal HackRF mode for a USB host, with a confirmation dialog. The unit disconnects as "PortaPack Mayhem" and comes back as "HackRF One" a few seconds later. That is what the Pi's log shows. Mayhem also offers a serial console on /dev/ttyACM0 with a hackrf command that does the same switch. I can't tell from the log which of the two I used.

The serial console route, for anyone who prefers a terminal (tio is a small serial terminal program).

tio /dev/ttyACM0

hackrf

DFU mode. This is the NXP chip's built-in bootloader, with the USB ID 1fc9:000c. It exists for flashing and recovery, so a radio that works never needs it. The HackRF docs say to hold the DFU button while powering on, or while pressing and releasing RESET, and then to release the DFU button, after which the 3V3 LED should light. I did not do this one. The Pi has the tool ready for it now.

sudo apt-get install -y dfu-util

From the HackRF documentation, load the DFU image into RAM and then write the firmware to flash (use the files that match your board).

dfu-util --device 1fc9:000c --alt 0 --download hackrf_one_usb.dfu

hackrf_spiflash -w hackrf_one_usb.bin

The Pi also had the udev rules for both the HackRF One (1d50:6089) and the NXP DFU device (1fc9:000c), and my user is in the plugdev group. That is what lets a normal user open the radio without sudo.

A HackRF needs 500 mA at 5 V. My own field result is that it fails on most USB 3 hubs and works on USB 2 hubs, and that a Pi 5's USB budget of 600 mA, or 1.6 A with a real 5 A supply, is the number to watch. The power fix had to land before the radio did.

Closing Up the Lair

A final audit found two repairs worth making right away. The first is that DragonOS keeps its system journal in memory, so every reboot erased the USB-reset evidence from the night before. The setting below keeps it on disk with a cap of 200 MB.

sudo mkdir -p /etc/systemd/journald.conf.d

printf '[Journal]\nStorage=persistent\nSystemMaxUse=200M\n' | sudo tee /etc/systemd/journald.conf.d/10-persistent.conf

sudo systemctl restart systemd-journald

The second repair was installing dfu-util, since the udev rule already existed but the tool did not.

Quests Remaining

The default password is still in place, so SSH accepts password logins from the local network and so does the stock wayvnc on port 5900. A new password typed on the Pi covers both... the other option is turning off SSH password logins, since key login already works from the Mac.

There is no active cooler on this Pi. It sat at 74.7 °C while idling with SDR++ open, a Pi 5 starts throttling at 80 °C. Decoding signals will push it higher. Check yours with vcgencmd measure_temp.

The UPS monitor sees nothing yet. Its battery chip (an INA219 at I2C address 0x41) needs three jumper wires, SDA to pin 3, SCL to pin 5 and GND to pin 6. Until then the monitor service writes one line saying it found no UPS.

One small FTDI FT231X serial chip on the hub disappeared when the PortaPack took its port. What it belongs to is still a question.

Bill of Materials

Part	Role in the build
Raspberry Pi 5, 16 GB	The dragon (hostname dragon)
64 GB microSD card (32 GB is the stated minimum)	Boot drive, about 28% used on November 1
DragonOS Pi64 Beta42	SDR distro, Debian 13, kernel 6.12.47
Waveshare UPS Module 3S plus three 18650 cells	Battery backup, 9.0 V empty to 12.6 V full ($21.99 USD maker, $31.41 CAD RobotShop.ca, 2026-11-01)
MT7612U USB Wi-Fi adapter	Second radio on the Pi, the one that kept resetting
AOC 24" monitor on HDMI-A-1	Main display
Small touch monitor on HDMI-A-2	Second display, doubles as the pointer
HackRF One with PortaPack running Mayhem	The radio (PortaPack model not confirmed)
USB cables	Radio and hub connections
Mac mini M4 Pro	Control machine for SSH, the tunnel and the card

What I'd Buy Next

Prices were checked on the dates shown, in Canadian dollars. Maker prices are in brackets after each one.

• Active cooler- the Raspberry Pi Active Cooler at PiShop.ca was $7.15 before tax (checked 2026-11-01). The maker's page is raspberrypi.com/products/active-cooler, which lists no price. It clips on, runs from the Pi 5's four-pin fan header and has a temperature-controlled fan.
• Short USB 2.0 cable for the Pi's black ports- StarTech UUSBHAUB1, 1 ft USB 2.0 A to Micro-B, shielded, $9.26 [$12.29] (checked 2026-10-31). Maker: startech.com.
• USB-C to Micro-B cable for plugging the radio into the Mac mini- StarTech USB2CUB1M, 3 ft, $14.89 [$17.41] (checked 2026-10-31). Maker: startech.com.
• Powered USB 2.0 hub- StarTech ST4202USB, four ports, adapter included, $30.32 [$38.94] (checked 2026-10-31). Listings say 5 V at 2 A- the per-port limit is not published. Maker: startech.com.
• Female to female jumper wires for the UPS battery chip- the ELEGOO 120-piece kit was quoted at $12.99 on October 31 (price not rechecked today). Three wires is all the job takes.

The Next Campaign

SDR++ is already open on the dragon. The next adventures are the ones this board was bought for... listening in on bands, decoding what flies by and finding out how hot the Pi runs once it does. Which SDR quest should the dragon take on first, and has anyone fought the same Pi 5 power battle with a different UPS? Leave a comment with what worked for you.

Links- https://hackrf.readthedocs.io
https://github.com/portapack-mayhem/mayhem-firmware/wiki
https://dragonos.org

For the true Wizards- those who've adventured to the far distant lands which are the end of this post- a spell worthy of the most skilled, talented, knowledgeable Wizards. You know better than troubling yourself with such mini battles- use your ultimate powers! Copy and paste the URL of this post into your LLM and tell it "Do this for me"... sit back and watch the magic happen!

Glossary

• SDR - software defined radio, where a computer does the tuning and decoding that older radios did in hardware
• DragonOS - a Linux distribution packed with SDR software, here the Raspberry Pi 64-bit build
• HackRF One - a USB software defined radio that transmits and receives
• PortaPack - a small screen, buttons and processor board that turns a HackRF into a handheld unit
• Mayhem - community firmware for the PortaPack
• DFU - device firmware upgrade, a built-in bootloader mode used to flash or recover a device
• udev rule - a Linux file that sets who may open a USB device when it is plugged in
• EEPROM - small rewritable memory on the Pi that holds the bootloader and its settings
• USB Power Delivery - the USB-C protocol where a charger and a device agree on how much power to send
• UPS - uninterruptible power supply, a battery between the wall and the computer
• avahi - the Linux service that announces a machine's .local name on the network
• Tailnet - a private network of your own machines made by Tailscale
• wayvnc - a remote desktop server for Wayland desktops
• noVNC - a remote desktop viewer that runs in a web browser
• Kernel - the core of the operating system that talks to the hardware

Sources

• Raspberry Pi documentation- bootloader configuration, including PSU_MAX_CURRENT
• HackRF documentation, updating firmware- DFU mode, dfu-util and hackrf_spiflash
• PortaPack Mayhem wiki, Main Menu- the HackRF entry that switches to HackRF mode
• PiShop.ca, Raspberry Pi Active Cooler- Canadian price
• Raspberry Pi Active Cooler- maker page and specifications
• Tailscale package server- the Debian trixie key and list files
• wayvnc- the Wayland VNC server
• noVNC- the browser viewer