PoorSDR4All for uSDX: a much more complete SDR experience from your PC

Documentation for PoorSDR4All 1.0.0a1 · Last updated: September 2026

Developed in the Acuántico Power lab · PoorSDR4All 1.0.0a1 · Alpha

If you have a uSDX v1, v2, or one of the many minimalist clones, you probably know this scene well:

MENU. EXIT/MODE. Encoder.

You want to go from 40 m to 20 m. You switch bands and then have to check the mode, because on 40 m you were on LSB and on 20 m you’ll normally want USB. Then a signal shows up that you want to fine-tune: you drop the tuning step from 1 kHz to 0.5 kHz. You finish and want to go back to 1 kHz. It can all be done; what wears you down is having to dig through menus for actions you repeat constantly during a normal operating session.

From a single interface you can have in front of you frequency, band, mode, tuning step, PTT, Tune, volume, mic gain, ANR, Radio/SDR audio, OpenWebRX+, waterfall, spectrum, S-meter, spots, Digi, memories, autocall macros, and quick shortcuts. Underneath, PoorSDR4All coordinates CAT, audio, network services, and external integrations.

PoorSDR4All can be used partially without OpenWebRX+ for functions like CAT, radio audio, memories, or autocall macros. However, OpenWebRX+ is a fundamental part of the project and is required to enjoy the full experience: without it you lose integrated SDR reception, the waterfall, the spectrum display, the derived S-meter, and other functions tied to that backend.

The idea is simple: a small, minimalist uSDX shouldn’t have to feel small just because you’re operating it from the PC.

PoorSDR4All doesn’t try to turn the uSDX into a different rig or give it RF capabilities it doesn’t have. Its goal is more practical: strip away most of the friction of the physical front panel and use the computer to build a more comfortable, visual, and integrated station around the radio.

It doesn’t change the radio. It changes the experience of using it.

Quick manual: from zero to operating safely

1. Connect the uSDX over CAT

Swipe horizontally to see the whole table →

2. Set up reception

Swipe horizontally to see the whole table →

3. Tune in a signal

1. Choose BAND to jump to a band.
2. Choose MODE. For HF phone, LSB is normally used on the lower bands and USB on the higher ones, but the band plan and the actual signal always take priority.
3. Select the tuning step.
4. Move the VFO with the wheel, keyboard, arrow keys, or channel controls; for an exact frequency, edit the display.
5. Confirm the uSDX has followed the change.

4. Open the SDR experience

Before continuing, connect to OpenWebRX+ an SDR receiver capable of covering HF and a suitable antenna. If the SDR shares the uSDX’s antenna, don’t transmit until you’ve installed an automatic antenna switch that isolates it during TX.

1. Start or connect to OpenWebRX+.
2. Press OWRX.
3. Select the SDR reception source if you want to listen to that stream.
4. Change band and check that the waterfall follows the matching profile.
5. Click a signal on the waterfall to tune it from the console.

5. First transmit test

1. Set up the PC’s microphone and the audio output to the radio.
2. Lower Gain / Mic before you start.
3. Key PTT briefly and check the TX state.
4. Release PTT and confirm the radio goes back to RX.
5. If PTT doesn’t switch correctly, stop the test and check the CAT connection, the profile, the speed, and firmware compatibility.

6. Save a frequency

Open Mem, save a name, frequency, and mode, and recall it whenever you want to return to that spot. Memories are local to PoorSDR4All: they tune the radio, but they don’t program the firmware’s internal memory.

↑ Back to index

What uSDX is and why there are so many variants

uSDX —also written µSDX in some projects— is a family of QRP transceivers largely defined by software. The original idea shrinks the hardware a lot and pushes functions into firmware, so the rig can be small and cheap, but its physical interface tends to be equally minimal.

Over time, follow-ups, derivative boards, and commercial units appeared under names like uSDX, (tr)uSDX, usDX, uSDR, or QCX-uSDX. You shouldn’t assume that two rigs sold as “uSDX” share the same firmware, the same USB converter, the same connectors, the same CAT speed, or the same PTT behavior.

Original uSDX and (tr)uSDX

PoorSDR4All includes a generic TS-480 profile at 38400 baud and a trusdx-115200 profile for modern (tr)uSDX firmware. In the current Alpha, the latter is implemented but still marked as pending full physical validation on more rigs.

As a rule of thumb: don’t change values at random just because your radio is called uSDX. Identify the variant, firmware, port, and speed first.

↑ Back to index

What PoorSDR4All is

PoorSDR4All is a radio operating console written in Python with a Tkinter interface. It brings together in a single desktop application what normally means having half a dozen programs open at once:

• CAT control of the radio (Kenwood protocol / TS-480 emulation, the same one QRP rigs like the µSDX also speak).
• rigctld Proxy and a network TS-480 emulation layer for integrating external software without several applications having to open the same physical serial port directly.
• Embedded SDR waterfall (via OpenWebRX+) that follows the console: you change band and the SDR profile changes on its own; you click the waterfall and the console tunes to that frequency.
• Digi viewer showing the decodes available from the backend. To make FT8 contacts with WSJT-X, it connects to PoorSDR4All’s rigctld proxy and uses its own audio chain.
• Optional remote web server for operating from another device or from your phone.
• Autocall macros with prerecorded audio, and plugins — a logbook with contest features, WiFi filter relays.

It’s an Acuántico Power project, with the source code publicly available on GitHub under a noncommercial license (details below, in License). It isn’t software as a service: it installs on your machine, keeps its configuration on your machine, and doesn’t send anything anywhere you haven’t explicitly configured.

At a glance

Swipe horizontally to see the whole table →

What PoorSDR4All does and doesn’t do

PoorSDR4All tries to bring uSDX operation together in one place, but useful documentation also has to make clear where the program ends and the radio, the auxiliary SDR, and external services begin.

Swipe horizontally to see the whole table →

This Alpha also doesn’t document, as uSDX-specific CAT control: RIT, IF filters, RF gain, the radio’s internal volume, AGC, SWR, RF power, or general telemetry.

↑ Back to index

Compatibility with uSDX, (tr)uSDX, and operating systems

Swipe horizontally to see the whole table →

Swipe horizontally to see the whole table →

Requirements

For CAT and the console only

• Python 3.11 or later.
• Tkinter, PortAudio, and PySerial, along with the project’s Python dependencies.
• A uSDX or a variant with compatible CAT.
• A USB-serial data cable/interface recognized by the system.

For physical audio

• A PC audio input to receive from the radio.
• A PC audio output to the transceiver.
• Wiring suited to your variant’s levels and connectors.

For the full SDR experience

• OpenWebRX+, local or remote.
• An SDR dongle or receiver compatible with OpenWebRX+ and capable of receiving the HF bands you want to use. This is required whether OpenWebRX+ runs locally or on another machine.
• A suitable receive antenna connected to the SDR.
• If the SDR and the transceiver share an antenna, an automatic RX/TX antenna switch that disconnects and isolates the SDR before you transmit.
• External decoders installed for whichever digital modes you want to use.
• SpeexDSP 1.2.1 if you want ANR.
• A C compiler only if you want to build the optional native accelerator.

↑ Back to index

Current status of the Alpha release

This is the first public release, 1.0.0a1 — Alpha. It works in the author’s main development environment, but it still needs community validation with more radios, audio interfaces, and operating systems. The table says exactly how far each platform gets today — no more, no less:

Swipe horizontally to see the whole table →

CI results confirm that the code installs, tests, and builds — they are not a physical test of radio, CAT, SDR, or audio. If something fails on your hardware, a report on the GitHub issue tracker is exactly the kind of help this project needs right now.

How to install PoorSDR4All

PoorSDR4All is distributed as source code and also provides a self-extracting graphical Linux installer in .run format. OpenWebRX+ and its stack (csdr, pycsdr, owrx_connector…) are not bundled as precompiled binaries: the installer downloads them from their official repositories at pinned revisions, compiles them on the user’s machine, and preserves their GPL/AGPL licenses.

Recommended graphical installation on Linux

The easiest way to install PoorSDR4All on Linux is the official graphical installer: a single executable file that handles system dependencies, OpenWebRX+, the frequency display’s LED font, and the application-menu shortcut without requiring the terminal.

Manual installation on Linux (with OpenWebRX+)

The manual installation uses scripts/install.sh. The script detects Arch or Debian, installs system dependencies, compiles the accelerator, clones the OpenWebRX+ stack at exact pinned revisions, applies the patches published in patches/, and configures its systemd services. It requires sudo and modifies packages, groups, udev, polkit, and systemd; review it before running it, as with any installer that modifies the system.

git clone https://github.com/Acuantico/poorsdr4all.git
cd poorsdr4all
scripts/install.sh

Advanced installer options

Environment variables that change its behavior:

Swipe horizontally to see the whole table →

A normal update (without RESET_OWRX_CONFIG) keeps settings.json, users, and OpenWebRX bookmarks exactly as they were.

Arch Linux

The following procedures install the console manually. They’re useful for development or custom installs; to also get the local OpenWebRX+ stack, use the recommended installer above.

sudo pacman -S --needed python tk portaudio git base-devel
git clone https://github.com/Acuantico/poorsdr4all.git
cd poorsdr4all
python -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install .
python scripts/build_native.py       # acelerador opcional
python -m poorsdr

Debian / Ubuntu / Raspberry Pi OS (64-bit)

sudo apt update
sudo apt install python3 python3-venv python3-tk portaudio19-dev git build-essential
git clone https://github.com/Acuantico/poorsdr4all.git
cd poorsdr4all
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install .
python scripts/build_native.py       # acelerador opcional
python -m poorsdr

Windows 10/11

Install Python 3.11 or later and Git. For the optional accelerator you’ll need Visual Studio Build Tools with the C++ workload, clang, or MinGW. Audio uses WASAPI via PyAudioWPatch, and CAT talks over COM ports. OpenWebRX+ doesn’t install natively on Windows: point to a remote OpenWebRX+ server or run it inside WSL2.

git clone https://github.com/Acuantico/poorsdr4all.git
Set-Location poorsdr4all
py -3.11 -m venv .venv
.venvScriptsActivate.ps1
python -m pip install --upgrade pip
python -m pip install .
python scriptsbuild_native.py       # opcional; requiere MSVC, clang o gcc
python -m poorsdr

Plugins

Plugins are independent, optional Python packages installed separately:

python -m pip install ./plugins/filter-relays

Nunca Más, Ni Una Más (NMN1M), the logbook that provides the “Log” button, isn’t part of the PoorSDR4All tree: it’s an independent project, with its own repository, license, and release cycle. It must be installed separately following its own instructions. With no extensions installed, the console works the same, but it doesn’t show the “Log” button or the “Relays” tab in Settings. More detail in the Plugins section.

Optional functions that depend on external software

• Remote web server: python -m pip install ".[web]".
• FT8 / FT4 / JT65 / WSPR: you need the official WSJT-X decoders installed.
• ANR (noise reduction): needs SpeexDSP 1.2.1 installed on the system.
• GTK viewers (waterfall and Digi panel as separate GTK processes): optional; if they’re not available, the waterfall falls back to its Tkinter version.

First launch and where everything lives

PoorSDR4All never stores configuration, logs, or databases inside the installed package — everything goes to the standard user directories:

Swipe horizontally to see the whole table →

PoorSDR4All runs with python -m poorsdr or the installed poorsdr command. Configuration, data, and logs are saved in the user’s directories, separate from the installed package.

The most common serial ports on Linux are /dev/ttyUSB0 and /dev/ttyACM0; on Windows they’re COM1, COM2, etc. The Settings window enumerates them automatically when it opens (along with audio devices), but the combo boxes stay editable by hand in case detection fails or the device is unplugged at that moment.

First connection: how to connect a uSDX to your PC

Take this first setup step by step. The goal is to validate each layer separately: first CAT, then reception, then SDR if you’re going to use it, and only at the end, transmission.

1. Connect the CAT cable with the radio powered off. If you’ll use physical audio, also connect the audio input and output.
2. Turn on the uSDX and open PoorSDR4All. You can run poorsdr or python -m poorsdr.
3. Open Settings → Radio / CAT. Select the real port. On Linux it’s normally /dev/ttyUSB* or /dev/ttyACM*; on Windows, a COM port.
4. Select the profile and speed. Use your firmware’s own values; don’t copy the ones from a screenshot of a different install.
5. Save and check frequency/mode. If the dial doesn’t follow the console, stop here and fix CAT first.
6. Set up Settings → Audio. Assign all four audio roles and start at low levels.
7. Choose Radio or SDR. Radio listens to the physical input; SDR uses the OpenWebRX+ stream.
8. Check reception. Tune a known signal and confirm frequency, mode, and audio.
9. Set up OWRX if you want waterfall/spectrum/Digi.
10. Test TX last. Low gain, a suitable load/antenna, and a brief key-down.

↑ Back to index

The main console: control by control

This is the part that really changes the uSDX experience. The main screen brings together the controls you use most during a radio session, so the rig’s physical menu stops being the center of operation.

Swipe horizontally to see the whole table →

↑ Back to index

PoorSDR4All Settings: complete field-by-field reference

This section documents every control the user can find in the Settings window. It doesn’t just list them: it explains what each field is for, what the user should normally put there, and which options are best left untouched.

Settings works as a field reference. The chapters that follow explain how to use each function during real operation — tuning, audio, OpenWebRX+, spots, autocall macros, the web server, and integrations — and tie the procedure back to these parameters.

Radio / CAT — connecting to the uSDX and control services

Swipe horizontally to see the whole table →

Audio — what comes in, what goes out, and what the operator hears

Swipe horizontally to see the whole table →

OWRX — OpenWebRX+ integration, waterfall, and band tracking

Swipe horizontally to see the whole table →

Spots / Cluster — source and duration of DX alerts

Swipe horizontally to see the whole table →

This tab sets the source and the retention time. Which spot types are shown is handled from the Spots button on the main console.

Web — remote control from a browser

Swipe horizontally to see the whole table →

Pressing Save applies the settings on the fly. PoorSDR4All restarts the web server when a parameter that affects its operation changes; there’s no need to restart the whole console.

Interface — language, theme, and starting mode

Swipe horizontally to see the whole table →

Autocall — the 10 profiles and the console’s 4 buttons

Swipe horizontally to see the whole table →

Shortcuts — every action assignable, no exceptions

Click an action’s field and press the key you want to assign. The × clears the assignment. An action can also be left with no key at all.

Swipe horizontally to see the whole table →

Plugins — enable or disable extensions

This tab lists the plugins it detected. Each plugin shows a checkbox: checked means active, unchecked means disabled. Changes take effect when you restart PoorSDR4All.

• Plugin name: identifies the detected extension.
• Enable checkbox: decides whether PoorSDR4All should load it on the next launch.
• Info text: shows the plugin’s identifier. The guide doesn’t depend on the specific state shown in a sample screenshot.
• With no plugins installed: PoorSDR4All still works; plugins are optional and additive.

About — project information

Swipe horizontally to see the whole table →

The About tab is informational only: it doesn’t store any operating parameters.

Optional Relays tab — only if the matching plugin is installed and active

PoorSDR4All can add tabs to Settings from plugins. The filter-relays plugin adds Relays; that’s why it doesn’t appear on every install. If it does appear, its fields are:

Swipe horizontally to see the whole table →

↑ Back to index

Tuning the uSDX from your PC: frequency, steps, bands, and modes

PoorSDR4All is built so changing frequency no longer has to depend constantly on the physical encoder. You can edit the frequency directly, move it with the keyboard/wheel, and pick a suitable step before you move.

Swipe horizontally to see the whole table →

The app exposes presets for 160, 80, 60, 40, 30, 20, 17, 15, 11, and 10 meters. Selecting a band can also coordinate the matching OpenWebRX+ profile.

Swipe horizontally to see the whole table →

PTT and Tune

PoorSDR4All’s PTT works exclusively over CAT. The app sends the TX; and RX; commands to the compatible uSDX through the same port and connection used to control frequency and mode.

If PTT over CAT doesn’t work

1. First confirm frequency and mode work over CAT.
2. Check the firmware and the compatible TX/RX commands.
3. Confirm your radio’s firmware correctly supports the CAT TX and RX commands PoorSDR4All uses.
4. If the radio gets stuck in TX, switch back to RX from the radio itself and don’t continue until you’ve found the cause.

Tune

Tune isn’t just a visual button. It generates a test tone and drives the actual transmit chain. Use it briefly, at moderate levels, and with a proper load/antenna.

uSDX audio on the computer: RX, TX, Radio/SDR, and ANR

RECEPTION FROM THE uSDX
uSDX → PC audio input → PoorSDR4All → PC speaker

RECEPTION FROM SDR
SDR/OpenWebRX+ → PoorSDR4All → PC speaker / Digi

TRANSMISSION
PC microphone or macro → PoorSDR4All → audio output to the radio → uSDX

PoorSDR4All keeps the PC’s speaker, the PC’s microphone, audio received from the radio, and audio sent to the radio separate. The RX source decides whether you hear the physical radio or the SDR.

ANR

With SpeexDSP available, ANR can be turned on and its intensity adjusted. Don’t assume more intensity is always better: start low and only raise it if it improves intelligibility.

uSDX + OpenWebRX+: waterfall, spectrum, and S-meter

OpenWebRX+ is a fundamental part of PoorSDR4All. While the console can be used partially without it, the full experience needs this backend to bring in SDR reception, the waterfall, the spectrum display, and the S-meter. PoorSDR4All takes care of integrating it into operation: a band change can select the SDR profile, the waterfall follows the console, and a click on it can send the tuning back to the radio.

OpenWebRX+ needs real receiving hardware: an SDR dongle or receiver capable of listening on HF, with a suitable antenna connected. Installing the server without an SDR that covers the bands you want doesn’t give you the reception experience it’s meant to provide.

• FFT and waterfall to see activity around the frequency.
• Zoom and panning in the viewer.
• Configurable per-band profiles.
• Markers and spots overlaid.
• Two-way tuning between the console and the waterfall.
• S-meter derived from dBFS, with auto-calibration and a configurable noise floor, plus an optional fixed scale.

How to set up auto-calibrated mode

This is the default active mode, and it isn’t meant to turn dBFS into an absolute power measurement. It’s there so the scale stays consistent with each station’s usual QRM level.

1. Leave Calibrated S-meter off.
2. Tune into a part of the band with no signals present and let PoorSDR4All track the background noise.
3. Decide which S level that QRM normally represents at your station. You can use a receiver or instrument that’s already calibrated and connected under comparable conditions as a reference. If you don’t have a reliable reference, keep S5.
4. In Settings → OWRX → Noise floor (S), enter the matching unit, between S0 and S9.
5. Press Save. Tracking is readjusted and the change applies immediately, with no need to restart the console.

This value doesn’t claim the noise has some absolute power level: it only sets where the detected floor sits on the relative scale. You may need to change it if your antenna, radio environment, or the band you’re using has a different QRM level.

How to calibrate the fixed scale with an S9 reference

Use this procedure if you need a referenced reading instead of the relative scale. The calibration only stays valid as long as the SDR receiver’s gain and the rest of the receive chain stay the same.

1. Manually fix the RTL-SDR’s gain in OpenWebRX+. Don’t use automatic gain. On a system install this is set in /var/lib/openwebrx/settings.json; the template included in the source code is at assets/owrx/settings.json. The profile field is rf_gain.
2. Feed the antenna input a signal of known power. A calibrated signal generator is the best option. For S9 on HF you can use -73 dBm as a reference; if you don’t have a generator, you need a source and an attenuation whose final level you can determine with enough precision.
3. Tune the reference signal and note the exact dBFS value OpenWebRX+ shows.
4. Open Settings → OWRX, enter that reading under S9 reference (dBFS), and turn on Calibrated S-meter.
5. Press Save. The new scale applies immediately, with no need to restart the console.

To go back to auto-calibrated mode, turn off Calibrated S-meter. The value saved in S9 reference (dBFS) is kept, but stops being used; the S-meter goes back to placing the detected noise at the unit set by Noise floor (S).

FT8 with uSDX: Digi and digital modes

Digi shows the digital activity it receives from the backend and the decoders available. With FT8 active on the backend, it lets you see the decoded frames while the console and the waterfall stay visible. This function is independent of the console’s five selectable modes: LSB, USB, CW, FM, and AM.

The availability of FT8, FT4, JT65, WSPR, or other modes depends on the decoding environment you have installed. PoorSDR4All shouldn’t be described as a self-contained universal decoder that bundles all those engines inside the main package.

To make FT8 QSOs, use WSJT-X and connect it to PoorSDR4All through the rigctld proxy. See the full WSJT-X setup.

FT8 checklist

• The PC’s clock is correctly synced.
• The frequency and mode are correct.
• CAT is stable.
• There’s a visible signal on the waterfall.
• The matching decoder is available.
• Audio levels aren’t clipping.
• If you’re going to transmit: PTT, duty cycle, power, and cooling are under control.

Spots and DX Cluster

Spots can arrive over MQTT or a Telnet cluster. The point isn’t just reading a list: they can be plotted on the waterfall to turn DX information into part of the tuning workflow.

• Configurable duration for each spot.
• Type filters from the console.
• MQTT source with URL, topics, and credentials.
• Telnet source with host, port, callsign, and password.

Frequency memories

PoorSDR4All’s memories locally save name, frequency, and mode and let you return to that spot later without repeating all the navigation. The app can infer the band based on proximity to its reference frequencies.

Autocall: audio macros

You can define up to 10 macros with a name, an audio file, repeat count, and interval, and assign four of them to the console’s four visible buttons. The current version lets you pick WAV, MP3, OGG, or FLAC files from the file dialog.

• Test the file off-air first.
• Start with low gain.
• Check the output level going to the radio.
• Confirm PTT returns to RX when it finishes.
• Follow the identification and automatic-operation rules that apply to you.

Keyboard shortcuts

Shortcuts are designed so that once you’re used to the console, many actions can be done without taking your hand off the keyboard.

Swipe horizontally to see the whole table →

Remote control via the web server

PoorSDR4All includes an optional web server for operating from another device or from your phone. It ships turned off, and the project requires you to set the credentials and the signing secret before you can start it.

Setting up the remote web server (Settings → Web)

1. Web server: turn it on.
2. User: the default is admin; you can change it.
3. Password: enter a strong password. It’s required, and the server won’t start if it’s not set. PoorSDR4All only stores its hash and salt, never the plain-text password.
4. Host: keep 127.0.0.1 if the panel should only be available on the machine itself. To reach it from a phone or another computer on the same LAN, use 0.0.0.0, which listens on every interface.
5. Port: the default is 8080.
6. Allow WAN: not needed for normal use inside the LAN. This option allows connections from outside it, but it doesn’t open the port on your router or firewall, and it doesn’t make the service safe for the Internet. While this feature is still experimental, leave it off and use a VPN for any outside access.
7. Automatic HTTPS: turn it on so PoorSDR4All generates a self-signed certificate and serves the panel over https://. If you turn it off and don’t set ssl_cert and ssl_key manually, the panel is served over http://.

Pressing Save applies the configuration on the fly. If a parameter affecting how the server runs has changed, PoorSDR4All restarts only that service.

Accessing from another device

1. With the server running, check the console’s log for the available addresses. For example:

https://<your-lan-ip>:8080
https://<device-name>:8080
https://localhost:8080

2. From your phone or another computer on the same WiFi or LAN, open https://<device-ip>:8080. You need the LAN IP of the computer running PoorSDR4All: localhost and 127.0.0.1 only work from that same computer.
3. If you use automatic HTTPS, the browser will warn the first time that the self-signed certificate isn’t trusted. Confirm you’re going to the right address and explicitly accept to continue.
4. Sign in with the user and password configured in Settings → Web.
5. If WebRTC audio is available and working correctly on your install, press the panel’s audio button to try to set up the receive and transmit connection. Your browser will ask for microphone permission the first time. This part is also experimental and may have bugs or still-incomplete features.

Integrating other software: rigctld and TS-480 emulation

PoorSDR4All can remain the sole owner of the physical CAT port and offer radio control to other applications over the local network. This avoids the classic problem of two programs trying to open the same serial port at the same time.

Swipe horizontally to see the whole table →

Programs that support rigctld

1. First set up the uSDX in PoorSDR4All until frequency, mode, and PTT all work.
2. In Settings → Radio / CAT, leave Control mode = direct.
3. Turn on rigctld Proxy.
4. If the client is on the same computer, use 127.0.0.1 as the host.
5. Note the port; the default is 4536.
6. In the external program, select its Hamlib NET rigctl, Network rigctl, or equivalent option, and point it at PoorSDR4All’s host/port.
7. Don’t set the uSDX’s physical serial port in that program: PoorSDR4All keeps it open.

Other programs without rigctld support

1. Turn on TS-480 emulator in Settings → Radio / CAT.
2. Set its Host and Port; the default is 127.0.0.1:4532.
3. In the external program, use its Kenwood TS-480-compatible radio/network mode, as long as it supports this kind of TCP connection.
4. Remember the emulation covers the subset PoorSDR4All has implemented; it doesn’t turn the app into a full TS-480.

In both paths, PoorSDR4All receives the client’s changes, updates its own state, and applies them to the radio through its own CAT control.

Using WSJT-X with PoorSDR4All through the rigctld proxy

This is the recommended way to use WSJT-X with a uSDX controlled by PoorSDR4All. WSJT-X doesn’t compete for the serial port: PoorSDR4All keeps the physical CAT connection, and WSJT-X connects over TCP to the rigctld proxy.

1. Check PoorSDR4All first

1. Open PoorSDR4All and confirm the uSDX is connected over CAT.
2. Change frequency from the console and confirm the radio follows.
3. Switch LSB/USB and confirm the mode responds.
4. Test PTT from PoorSDR4All and confirm TX and RX both work before bringing WSJT-X into it.

2. Set up the proxy in PoorSDR4All

Swipe horizontally to see the whole table →

3. Set up WSJT-X

In WSJT-X open File → Settings → Radio and set up the control like this:

Swipe horizontally to see the whole table →

4. Use Test CAT and Test PTT

1. Press Test CAT in WSJT-X. If it works, the TCP connection to the proxy is up.
2. Press Test PTT for the shortest time needed, with the station ready. PoorSDR4All should reflect the state, and the uSDX should switch to TX over CAT.
3. If Test CAT fails, check rigctld Proxy, the host, the port, your local firewall, and that PoorSDR4All is running.
4. If Test CAT works but Test PTT fails, check again that PTT works directly from PoorSDR4All, and check the firmware’s CAT TX/RX compatibility.

5. Set up audio in WSJT-X

In WSJT-X’s Settings → Audio, select the input that receives audio from the uSDX and the output that feeds the transmit audio. If your station uses virtual interfaces, select those. The rigctld proxy doesn’t carry audio.

Swipe horizontally to see the whole table →

6. To work FT8

1. Precisely sync your computer’s clock.
2. Check the band and the working frequency.
3. Verify WSJT-X is receiving audio and that signals show up in its waterfall.
4. Adjust levels to avoid clipping.
5. Before transmitting, verify CAT and PTT with the tests above.
6. Make the contact from WSJT-X. PoorSDR4All’s Digi panel can serve as an extra viewer, but it doesn’t replace WSJT-X’s own operating interface.

WSJT-X on another computer on the same network

You can also run WSJT-X on another machine on the LAN. In that case PoorSDR4All’s proxy must listen on an address reachable from that network, and WSJT-X must use IP_OF_THE_POORSDR_PC:PORT as its Network Server. Only do this inside a network you control, and apply a firewall; don’t publish rigctld directly to the Internet.

Common WSJT-X + PoorSDR4All problems

Swipe horizontally to see the whole table →

↑ Back to index

PoorSDR4All CAT reference for uSDX

CAT transport uses ASCII text ending in ;, 8N1 serial, no flow control, with timeout/reconnect logic.

Swipe horizontally to see the whole table →

38400 or 115200

38400 is the reference speed for the project’s generic TS-480 profile. 115200 is reserved for the modern (tr)uSDX profile when its firmware requires it. The name “uSDX” alone isn’t enough to pick the speed.

↑ Back to index

Plugins

PoorSDR4All discovers installed extensions at startup as independent Python packages. They’re enabled or disabled one by one from Settings → Plugins tab; the change takes effect when you restart the console. The distributed tree includes Filter Relays. Other integrations, like NMN1M, are published and installed separately.

Nunca Más, Ni Una Más (NMN1M)

This is the logbook and QSO log that can add the “Log” button to the console. It isn’t distributed inside the PoorSDR4All repository: it has its own repository, license, documentation, and release cycle. Install it separately in the same environment following NMN1M’s official wiki so PoorSDR4All can discover it.

Filter Relays

Selects a remote filter bank per band via WiFi-controlled relays. Adds the “Relays” tab to Settings only if it’s installed and active.

Writing your own plugin

A plugin exposes an object with id, name, and a register(ctx) method that can add a background service, a button on the console, and/or an entire tab in Settings:

class MyPlugin:
    id = "my_plugin"
    name = "My plugin"

    def register(self, ctx):
        ctx.add_service(MyService(ctx.bus, ctx.config))
        ctx.add_console_button("my_button", "Label", self._abrir)
        ctx.add_settings_tab("My tab", (
            Field("my_section", "setting", "Field label", "bool"),
        ))

    def shutdown(self):  # opcional
        ...

PLUGIN = MyPlugin()

And in the plugin’s pyproject.toml, the entry point that makes it discoverable:

[project.entry-points."poorsdr.plugins"]
my_plugin = "my_package.plugin:PLUGIN"

With no plugin installed, the console works exactly the same — the plugin system is purely additive.

Where PoorSDR4All stores its configuration, and how to back it up

Swipe horizontally to see the whole table →

Swipe horizontally to see the whole table →

For a clean backup, stop PoorSDR4All and OpenWebRX+, copy the configuration and data directories, and protect those copies: they can contain hashes, local paths, or keys for services you’ve configured.

Recommended workflows

Operating SSB

1. Connect CAT.
2. Select a band.
3. Choose LSB or USB.
4. Select Radio or SDR.
5. Adjust volume.
6. Turn on ANR only if it helps.
7. Tune in.
8. Adjust TX gain.
9. PTT.
10. Return to RX and check.

Receiving with SDR and transmitting with uSDX

1. Start OpenWebRX+.
2. Press OWRX.
3. Select RX = SDR.
4. Choose a band.
5. Look for activity on the waterfall.
6. Click/tune in.
7. Transmit with the uSDX when needed.

Working FT8 with WSJT-X

The correct flow is: PoorSDR4All keeps the uSDX’s CAT port, and WSJT-X connects to the rigctld proxy. Don’t connect WSJT-X directly to the same serial port.

1. Sync the computer’s clock.
2. Confirm PoorSDR4All controls the uSDX’s frequency, mode, and PTT.
3. Turn on rigctld Proxy; for the same PC, normally use 127.0.0.1:4536.
4. In WSJT-X select Hamlib NET rigctl and use that host/port as the Network Server.
5. Set PTT Method = CAT and run Test CAT / Test PTT.
6. Set up WSJT-X’s audio input and output separately.
7. Operate FT8 from WSJT-X. Digi and OpenWebRX+ can stay open as visual support.

See the full procedure in Using WSJT-X with PoorSDR4All through the rigctld proxy.

Creating a memory

1. Go to the frequency/mode you want.
2. Open Mem.
3. Enter a name.
4. Save.
5. Recall it later to tune back in.

Troubleshooting uSDX + PoorSDR4All

Swipe horizontally to see the whole table →

Quick diagnostic commands on Linux

python --version
python -c "import tkinter"
ls -l /dev/serial/by-id/
ls -l /dev/ttyUSB* /dev/ttyACM* 2>/dev/null

Frequently asked questions about uSDX and PoorSDR4All

What is PoorSDR4All?

The operating console developed by Acuántico Power to work with radios in the uSDX family from your PC, bringing together CAT, audio, SDR reception, waterfall, digital modes, spots, memories, macros, and external interfaces.

Is PoorSDR4All official uSDX project software?

No. It’s an independent Acuántico Power project, designed specifically around operating with the uSDX and compatible variants.

What software can I use to control a uSDX from the PC?

Any program that understands the compatible CAT subset can control certain functions. PoorSDR4All is designed as a full console built around the uSDX, not just as a CAT client.

Does it work with (tr)uSDX?

There’s a dedicated 115200 profile for modern (tr)uSDX firmware. In the current Alpha, broad physical validation of that profile is still pending.

Which CAT speed should I use: 38400 or 115200?

It depends on your firmware. The project’s generic TS-480 profile uses 38400; the modern (tr)uSDX profile uses 115200 when that applies.

Do I need Hamlib?

Not for direct mode. Hamlib/rigctld is an advanced integration for station setups using external software.

Can I use WSJT-X?

Yes. The recommended setup is for PoorSDR4All to keep the physical CAT port and for WSJT-X to select Hamlib NET rigctl, pointing at PoorSDR4All’s proxy, normally 127.0.0.1:4536. Audio is set up separately in WSJT-X. See the step-by-step guide.

Does PoorSDR4All decode FT8?

Digi shows the decodes available from the installed backend. With the FT8 decoder active, it shows its frames while you actually work the contact from WSJT-X.

Do I need OpenWebRX+?

You can use PoorSDR4All partially without OpenWebRX+ for basic CAT control, radio audio, memories, and other console functions. That said, OpenWebRX+ is fundamental to what the project is about and is required for the full SDR reception, waterfall, spectrum, S-meter, and backend-related experience.

Do I need a second SDR?

For the full experience you need an SDR receiver compatible with OpenWebRX+ that can receive HF and has a suitable antenna connected. It can be on the same computer or connected to a remote OpenWebRX+ server; the uSDX’s basic CAT alone doesn’t produce the waterfall.

Can I connect the SDR and the uSDX to the same antenna?

Yes, and it’s the ideal setup, but only through an automatic RX/TX antenna switch that isolates the SDR before you transmit. Don’t connect both inputs directly to the same antenna, and don’t trust that protection to a common passive splitter: the transmitted energy can damage the SDR receiver’s front end.

Can I listen to the uSDX’s own receiver?

Yes. Select the Radio RX source and set up the audio endpoint that receives audio from the transceiver.

Can I receive with SDR and transmit with the uSDX?

Yes; it’s one of PoorSDR4All’s main workflows: visual reception with OpenWebRX+/SDR and transmit/control with the uSDX.

Is the S-meter the uSDX’s own?

No. It’s derived from the OpenWebRX+ stream’s dBFS level, not from the uSDX’s CAT. By default it’s relative and auto-calibrates against the background noise; each user can choose which S unit their ambient QRM is displayed at. You can also use a fixed scale referenced to S9 if you calibrate it with a known signal and keep the SDR’s gain fixed.

Can it read SWR or power from the uSDX?

Not through the CAT subset implemented in this Alpha release.

Does it program the uSDX’s internal memories?

No. It keeps local memories and tunes the radio when you recall them.

Does it work on Windows?

There’s Python support for Windows 10/11, considered experimental. OpenWebRX+ must be remote or run inside WSL2.

Does it work on Raspberry Pi?

There’s a planned install for Raspberry Pi OS 64-bit/arm64, but broad physical validation is still pending.

Does it work on macOS?

It isn’t announced as a supported or verified platform in this Alpha.

Where does it store its configuration?

In user directories: XDG on Linux and APPDATA/LOCALAPPDATA on Windows.

What license does it use?

Acuántico Power’s original code is source-available under the PolyForm Noncommercial License 1.0.0. Third-party components keep their own licenses.

uSDX / PoorSDR4All glossary

Swipe horizontally to see the whole table →

Security

• The remote web server is off by default and refuses to start without a configured password and signing secret.
• Don’t expose the CAT, rigctld, spiderd, or OpenWebRX ports directly to the Internet.
• Only the latest version gets security fixes. OpenWebRX+, csdr, pycsdr, owrx_connector, SpeexDSP, and the other external projects maintain their own channels.
• Found a vulnerability? Don’t post exploitable details in a public issue: use the GitHub repository’s private Security advisories channel, or Acuántico Power’s contact form, noting “PoorSDR4All security”. Include the affected version, platform, impact, and minimal steps to reproduce it.

↑ Back to index

Architecture, for anyone who wants to contribute

PoorSDR4All is organized in layers to keep the interface, the radio logic, the configuration, and the external services separate. This structure lets you work on one part of the program without mixing it up with all the others.

poorsdr/
  infra/      user paths, logging, and EventBus
  config/     configuration model and persistence
  core/       CAT logic, bands, tuning, memory, waterfall, and S-meter
  services/   radio, audio, OpenWebRX+, web, memories, and integrations
  ui/         main console and Settings window
  viewers/    waterfall and Digi panel
  i18n/       language resources
  runtime.py  app composition and startup

Services are coordinated through an EventBus. That way, a change in frequency, mode, PTT, memory, or OpenWebRX+ status can propagate to the parts that need it without the interface having to directly control every component.

When you save Settings, the configuration is persisted and the affected services are reconfigured. When a change requires internally restarting an audio device, a socket, or a connection, the corresponding service can do it without forcing the user to close the whole application.

The repository includes automated tests and static checks to cut down on regressions. Even so, software tests are no substitute for validation with real radios, audio interfaces, and SDR receivers.

How to contribute

Bug reports and proposals are welcome without any formalities on the GitHub issue tracker. For code, documentation, or resources to be merged into the project:

1. Open an issue describing large changes before implementing them.
2. Keep each contribution focused, with tests where appropriate.
3. Confirm in the pull request that you’ve read and accept the current version of the CLA (contributor license agreement) — the maintainer needs to be able to show that acceptance before merging anything.
4. Explicitly declare any third-party code, data, or resources: origin, version, and license.
5. Don’t include keys, private certificates, credentials, logs, or real user data.

The CLA lets Acuántico Power include your contribution in both the noncommercial and the commercial edition — but you keep the copyright to your own contribution. Changes to GPL or AGPL components are submitted separately and keep that component’s license: PoorSDR4All’s CLA doesn’t relicense third-party code. Contributions made on behalf of a company require that company’s authorization; the maintainer may ask for an additional corporate agreement.

Development environment

python -m pip install -e ".[dev,web]"
ruff check src tests
mypy src
pytest -q

License

PoorSDR4All’s original code is offered under the PolyForm Noncommercial License 1.0.0. It’s source-available, not OSI-approved open source software: you can use, modify, and distribute it for noncommercial purposes, but commercial use requires a separate agreement.

Some components and data keep their own licenses — AGPL, GPL, BSD, MIT, CC-BY, or public domain (OpenWebRX+, csdr, pycsdr, owrx_connector, owrx-spider, SpeexDSP, GeoNames, Natural Earth, flag-icons…). The exact revisions, changes, attributions, and full texts are in THIRD_PARTY_NOTICES.md and in the LICENSES/ directory of the repository.

For commercial use, contact Acuántico Power through the contact form. A commercial license for PoorSDR4All can only grant rights over code that Acuántico Power actually controls: it doesn’t turn the GPL or AGPL components into proprietary software, and it doesn’t remove the obligation to provide their source code where that applies.

Changelog

1.0.0a1 — Initial Alpha

First public release of PoorSDR4All.

• Operating console for uSDX with CAT control of frequency, mode, and PTT.
• RX/TX audio management and choosing reception from Radio or SDR.
• Integration with OpenWebRX+ for waterfall, spectrum, an auto-calibrated S-meter with a configurable noise floor or an S9 reference, band profiles, and coordinated tuning.
• Digi panel for the decoders available in the installed environment.
• Spots / DX Cluster over MQTT or Telnet.
• Local memories, autocall macros, and configurable shortcuts.
• Optional web server and integration layers for external software.
• A plugin system independent of the core.
• Visual themes and centralized configuration.
• Install on Linux, with experimental support on Windows 10/11.
• Automated tests, static analysis, and a reproducible build process.

The full version history is kept in CHANGELOG.md inside the repository.

Other tools from the lab

PoorSDR4All is part of a practical route through the Acuántico Power radio laboratory: start with Your first amateur radio rig, use NMN1M to log contacts, or see IRCB if you need an audio-and-PTT interface for another transceiver. Other projects include aprStar and Hamlib Launcher.

The uSDX is still small; your station no longer has to feel small

The uSDX’s appeal lies exactly in its philosophy: a lot of result from very little hardware. But that simplicity comes at a cost when every band change, mode, step, or setting sends you back to the same menu and the same encoder.

PoorSDR4All was born to fix that part of the experience. It doesn’t add watts, it doesn’t magically improve the RF filters, and it doesn’t turn the transceiver into a different rig. It uses the computer to put around the radio what the front panel can’t comfortably offer: instant CAT control, managed audio, an SDR view of the band, waterfall, spots, digital modes, memories, autocall macros, shortcuts, and integrations.

Let the uSDX keep the simplicity that makes it interesting, while using it from the PC feels much closer to working with a full SDR station.

PoorSDR4All is a project of Acuántico Power‘s own. This Alpha is being released so it can be used, tested against more uSDX variants, and improved with reproducible reports from the community.

↑ Back to index