A cross-platform GUI application that acts as a UDP splitter/bridge for WSJT-X, allowing you to forward WSJT-X UDP traffic to multiple ham radio applications simultaneously (HAMRS, GridTracker, JTAlert, Log4OM, etc.).

WSJT-X only allows you to configure a single UDP output destination. If you want multiple applications to receive WSJT-X data (e.g., HAMRS for logging and GridTracker for monitoring), you need something in the middle to split that traffic.

Some applications like HAMRS are also particular about which port they listen on, making direct connections difficult when multiple apps are involved.

This bridge sits between WSJT-X and your other applications:

                          ┌──→ HAMRS (port 2237)
WSJT-X ──→ UDP Bridge ──├──→ GridTracker (port 2333)
           (port 2238)   ├──→ GridTracker ADIF (port 9876)
                          └──→ JTAlert (port 2442)

• One-to-many UDP forwarding — Send WSJT-X data to as many apps as you need
• Per-destination bidirectional mode — Apps like GridTracker can send commands back to WSJT-X (e.g., clicking a callsign in the Call Roster)
• Automatic heartbeat generation — Keeps destination apps connected even if WSJT-X heartbeats are delayed
• WSJT-X protocol awareness — Parses and displays message types (Heartbeat, Status, Decode, QSO Logged, etc.)
• Live packet log — See all traffic flowing through the bridge in real time
• Persistent configuration — Your settings are saved between sessions
• No dependencies — Uses only Python standard library (no pip installs needed)
• Cross-platform — Works on Windows, macOS, and Linux

• Python 3.7 or later
• Tkinter (included with most Python installations)

python3 --version      # Should be 3.7+
python3 -c "import tkinter; print('Tkinter OK')"

On some Linux distributions, you may need to install Tkinter separately:

# Debian/Ubuntu
sudo apt install python3-tk

# Fedora
sudo dnf install python3-tkinter

git clone https://github.com/vincois/wsjtx-udp-bridge.git
cd wsjtx-udp-bridge

python3 wsjtx_udp_bridge.py

In WSJT-X, go to File → Settings → Reporting and set:

• UDP Server: 127.0.0.1
• UDP Server port number: 2238 (or whatever port the bridge is listening on)
• Accept UDP requests: ✓ (checked, if you want bidirectional support)

Click Add in the bridge to add your applications:

Click ▶ Start and you should see packets flowing in the log.

Some applications need to send commands back to WSJT-X. For example, clicking a callsign in GridTracker's Call Roster tells WSJT-X to reply to that station.

Enable bidirectional mode per-destination:

• Check the Bidirectional checkbox when adding/editing a destination, or
• Select a destination and click Toggle Bidir

One-way (→) is fine for passive logging apps like HAMRS. Use bidirectional (↔) for interactive apps like GridTracker or JTAlert.

Note: Bidirectional changes require a Stop/Start of the bridge to take effect.

Two test scripts are included for verifying the bridge works without needing WSJT-X or a radio:

# Terminal 1: Start the bridge
python3 wsjtx_udp_bridge.py

# Terminal 2: Simulate a destination app receiving packets
python3 test_receiver.py

# Terminal 3: Simulate WSJT-X sending packets
python3 test_sender.py

Settings are saved to ~/.wsjtx_bridge_config.json and persist between sessions. You can edit this file directly if needed:

{
  "listen_ip": "127.0.0.1",
  "listen_port": 2238,
  "destinations": [
    {
      "name": "HAMRS",
      "ip": "127.0.0.1",
      "port": 2237,
      "enabled": true,
      "bidirectional": false
    }
  ]
}

App shows "connecting..." or doesn't see data:

• Make sure the bridge is started (green status)
• Verify the destination port matches what the app expects
• The bridge sends heartbeats every 15 seconds — wait a moment for the app to connect

Port already in use error:

• Another application is already listening on that port
• Make sure WSJT-X and the bridge aren't trying to use the same port

GridTracker callsign clicks don't work:

• Enable bidirectional mode on the GridTracker destination
• Stop and restart the bridge after changing bidirectional settings
• Check that "Accept UDP requests" is enabled in WSJT-X settings

Return traffic isn't reaching WSJT-X:

• The bridge learns WSJT-X's address from its first incoming packet
• Make sure WSJT-X is sending data before trying to send commands back

MIT License — see LICENSE for details.

Contributions are welcome! Feel free to open issues or submit pull requests.

• WSJT-X by Joe Taylor, K1JT and the WSJT Development Group
• WSJT-X UDP Protocol Documentation

73 de the ham radio community!