One weak-signal mode, half a dozen decoders, and about four completely different ways to run it β desktop, laptop, phone, or a scrap of kit in a rucksack on a hilltop. This is the map.
FT8 (FrankeβTaylor, 8-FSK) came out of Joe Taylor K1JT's WSJT project as a weak-signal digital mode. Structured 15-second transmit windows, a fixed message format, and decoding that works well below the noise floor β that's the whole trick. It's turned HF and VHF into something you can work with a handful of watts and a compromise antenna, which is exactly why it's taken over the bottom of most digital sub-bands.
Every piece of software below does the same fundamental job β timed audio in, decoded callsigns and grid squares out, timed audio back β but they differ in decoder sensitivity, platform support, and how much extra plumbing (logging, mapping, contest support) is bolted around the core.
Pick your platform and how you mainly operate. This won't cover every edge case, but it'll get you to a sensible starting stack rather than fifteen tabs of forum arguments.
These are the programs doing the real work: audio in, waterfall, decode, message construction, audio out.
| Software | Platforms | Cost | Known for | Notes |
|---|---|---|---|---|
| WSJT-Xreference | Win / Mac / Linux | Free, open source | The original. Everything else is measured against it. | Solid, conservative decoder philosophy β fewer false decodes rather than the absolute highest count. Best documentation of any of them (read the user guide, genuinely). |
| JTDX | Win / Mac / Linux | Free | Contesters, weak-signal and aurora/polar-flutter chasers | Forked from WSJT-X. Tends to log more repeat decodes of marginal stations and has deeper AP (a-priori) decoding options. "JTDX Improved" community build is the actively updated variant. |
| MSHV | Win / Linux (official) β Mac only via unofficial builds | Free | EME, very weak signals, lightweight/portable rigs, Super Fox | Written by Christo LZ2HV. Different UI paradigm to the other two β worth ten minutes of getting used to. Recent versions added Super Fox/Super Hound DXpedition-style operation. |
| iDigi | macOS only | Paid (free 30-min trial sessions) | Mac users wanting one app for everything | Built exclusively for macOS β not a Windows port. Covers FT8/FT4 plus CW, PSK, RTTY, SSTV and WEFAX in one native app. Actively developed β worth trialling before buying. |
| FT8CN | Android | Free, open source | Running FT8 straight from a phone | The original Android-native decoder (BG7YOZ). VOX via phone mic/speaker, or CAT over USB-OTG/Bluetooth/Wi-Fi to a radio with a sound card. Development has slowed lately. |
| FT8AF | Android | Free, open source | Actively maintained Android alternative to FT8CN | Newer project (K1AF) built specifically because FT8CN's development stalled. Worth checking if you want ongoing updates. |
| iFTx | iOS / iPadOS | Paid (one-off, ~$2) | The go-to iPhone/iPad option | Works well with USB sound-card radios (e.g. IC-7300, Xiegu X6100) for audio. Apple blocks serial/CAT access on iOS entirely, so PTT needs either a radio with VOX or an interface with its own VOX circuitry β there's no true CAT-triggered PTT on this platform. |
The decoder is only half the stack. These listen to its UDP output and turn raw decodes into a logbook, a map, or an alert that someone you need has just shown up.
Live world-map plot of every decode, award tracking (grids, DXCC, states), weather and solar overlays. Reads WSJT-X or JTDX UDP output directly and can forward to a logger.
UDP in: matches decoder's port (default 2237)Audible/visual alerts for wanted callsigns, grids or DXCC entities, plus logging integration. Grabs the UDP port exclusively, so ordering matters if you're also running GridTracker.
UDP in: fixed to decoder's portFull logging suite with QSL/award tracking. Commonly chained: decoder β GridTracker β Log4OM, since Log4OM's multicast support is limited and proxy-forwarding avoids UDP port fights.
Inbound: proxy-forward from GridTrackerThe default choice once contesting is the goal. Talks to WSJT-X/JTDX over UDP for FT8 contest exchanges and handles multiplier tracking properly.
UDP broadcast, contest-specificNot software you run β a web service the decoders upload spots to automatically. Handy for checking your own propagation without a second radio.
pskreporter.infoHamlib (built into WSJT-X/JTDX), OmniRig, or a dedicated app like wfview for IC-7300-class radios β sits between the decoder and the radio's CAT port.
rigctld default: 4532Same rough sequence regardless of which decoder you pick.
FT8's 15-second windows mean your PC clock needs to be accurate to within about a second. If it's out, you'll see plenty of activity and get almost no replies.
Either a dedicated USB interface (SignaLink, DigiRig, RigBlaster) or a radio with a built-in USB sound card (IC-7300, FT-991A and most current rigs). Set the decoder's audio input/output to that device, not your PC mic/speakers.
Pick the right rig model and serial/USB port in the decoder's radio settings, test with the "Test CAT" button, then test PTT separately β they're configured independently.
Set the radio to the data mode your interface expects (commonly USB-D or a DATA mode, not plain USB β some rigs will silently switch to RTTY-USB if the CAT "Mode" setting in the decoder is wrong). Keep power modest; FT8's strength is decoding weak signals, and running high power mostly just causes splatter.
Once decodes are flowing, add GridTracker or JTAlert for visibility, then a logger. Start the chain in a consistent order each time β logger first, then decoder, then whatever's listening to its UDP feed β it avoids most of the "nothing's showing up" headaches.
WSJT-X/JTDX send UDP to a single port, and the first app to grab it "owns" it β a second listener gets nothing. Use GridTracker's UDP forwarding, or a logger's proxy-forward feature, to fan the data out rather than running two apps against the same port directly.
If you're driving the rig through something like Ham Radio Deluxe or another CAT-control layer, set the decoder's own "Mode" setting to None and switch modes from the radio's front panel instead β otherwise the two fight over which data mode is active.
Almost always the clock. Recheck NTP sync before touching anything else in the audio or RF chain.
Different decoders trade off differently between raw decode count and confirmed unique callsigns β more decodes often just means more repeat hits on the same marginal station, not more stations worked. Don't chase the biggest number for its own sake.