An Early Review
You've heard of FT8. You may be of the opinion that you wish you hadn't, but that ship has sailed, my friends.
FT8 is the daddy of modern digital modes in terms of take-up. If you're into your digital modes, you may have dabbled with FT4. Think of it as FT8 after a double espresso - it's twice as fast and you'll have to concentrate to keep up with the flow unless you're in 'do-it-for-me' mode, which in itself does take some of the fun out of it. If you run in 'manual-intervention' mode, you can play two or three QSOs at the same time and rack up the contacts - but you'll need your wits about you. No time for a slurp of coffee, or you'll fat-finger your console.
Then on Monday 16th Feb 2026, Martino Merola IU8LMC dropped his experimental (but working) prototype of Decodium 3.0. It's a fork of WSJT-X, meaning it’s a perfectly legitimate copy of an existing piece of open-source software which then diverges from that original development, introducing its own code and configuration changes.
Forks typically go one of two ways: either they flourish into glorious standalone tools, or they end up as digital moss on a forgotten GitHub branch. Martino's effort is currently somewhere in between, but while it isn't the final polished article, it's already making waves on the bands, excuse the pun.
FT2 In Decodium
Now I like my digital stuff, but I looked at this and thought it was an interesting but ultimately pointless toy. Why? Because FT4 is already blisteringly fast - in fact it's on the limit of my operating capabilities when in full chat. Add to that the fact that FT4 is already packaged into the current stable and well-supported version(s) of WSJT-X (version 2.7.0 and version 3.0.0 Release Candidate 1) - so it's a mature and usable mode. I even scoffed a little when I found out that FT2 'only' decodes down to about -12 dB, compared to FT8’s impressive -20 dB - but it's a new digital mode and other people were starting to pick up on it and were already making QSOs.
Alright, let’s dive in and see what it’s like...
So here's what it takes. Installation isn't pretty, but it's not too tricky either if you follow the instructions laid out by the developer. I did, but still encountered a few teething problems. I'll briefly share them with you, along with some quick fixes, or at least my initial thoughts and observations at the end.
First, a little background. I currently use WSJT-X v2.7.0, not v3.0.0 RC1. Here's why that matters (or not). The installation page linked below leads you down the route of installing v2.7.0 as a starting point. Yes - having WSJT-X installed is a prerequisite, but when you read some of the technical documentation, it says the new software is based on v3.0.0 RC1. OK, so Decodium is really a Beta, but I've tried it with both, and it didn't seem to make much difference. On reflection, I'd recommend going with v2.7.0 for now.
Disclaimer: Based on my very limited experience of WSJT-X v3, there are 'features' of Decodium 3.0 which I've never seen before. These may be in WSJT-X v3 or they may be brand new. I don't know, but they're not documented with Decodium v3.0 that I can find, and this is a problem. Secondly, this thing is moving so fast that I've had to re-write this article three times in the last 24 hours - so I won't be quoting too many specifics.
How To Install Decodium With FT2
To get started, head over to HamPass: https://hampass.com/ft2 (or directly to https://www.ft2.it/) and download two files. The first one contains the forked code and associated support files (the installer for which was sadly only available for Windows when I started writing this, but is now also available for Linux, and rightly so, plus something called macOS?) and the second file is one containing the new frequencies being used for FT2. Mercifully, this downloadable file also contains all the 'existing' frequencies, so unless you've customised your frequency file (for the UK 60m allocation for example) you're good to go. If you have customised it, you'll have a bit of retrofitting to do.
At this point, I'm hearing all the non-digi guys bemoaning the loss of yet more spectrum to the screeching of electronic chalk on blackboard. Yeah. On virtually every band, but within the band plan (probably...). Relax - I can't see it becoming a big thing, and if it does, it'll take the load off FT8. I'll stick my neck out right now, and predict it will remain niche.
After building a Windows machine (doh!), I installed WSJT-X v3.0.0 RC1, but after then having a few minor issues using Decodium, I reverted to v2.7.0. This may or may not have been significant, as I still see glitches.
Next, decompress/unzip/extract the main program file (referred to as a 'plugin' - but it's not - so don't try and put it in the WSJT-X 'Plugins' sub-directory) into the same directory as you installed WSJT-X. The default is C:\WSJT\wsjtx on Windows if I remember correctly. You'll end up with a folder in there called something horrible like Decodium_3_202602014 or similar. Within that sub-directory you'll find the new executable wsjtx.exe. Create a shortcut to that and drag/drop it onto your desktop and rename it Decodium, to save your future self some confusion.
Now you can run it up, and use the program itself to overwrite the frequencies file (Import QRG file in WSJT-X (File -> Settings -> Frequencies -> RIGHT click on list -> Load -> select your downloaded ft2-bands.qrg file). The last option is called 'Load', not 'Import' - some of the instructions online appear to be incorrect.
Now I suggest a reboot.
The new tool appears to have an NTP function built in. I tried installing a third party time-sync tool (Dimension 4), but I think it just fought Decodium. I suggest you use a decent external NTP service and turn off NTP in Decodium. This worked best for me - see below.
I'll let you play with it and make up your own mind, but here's what I found. It's insanely fast, as advertised. It's so fast that your time synchronisation has to be really accurate, and that QSOs often break down causing messages to be re-transmitted because they were not received correctly. This wasn't just an issue with my QSOs, I observed it time and time again with other stations, which rather defeats the point. Is it better to send once with a high success rate, or twice for total redundancy?
FT2 3.8 Second Windows
Apparently, FT2 uses the same Forward Error Correction as FT8 and FT4 (77-bit payload, LDPC(174,91), 8-GFSK modulation) but I'm not sure that bundling that payload into such a short time window is workable. Maybe it can be perfected, but I found that even the lag caused by keying my radio, running through the amplifier, tuner etc. could jinx a transmission. Interestingly, the bandwidth is three times that of FT8 at around 150Hz, but even so...
Let me know if you try it, and how it works out for you. I also found that when using the built-in NTP function, the audio to the radio was somehow inhibited by the software if it thought that the Delta Time was too great, or the NTP time signal was out by more than maybe 500ms - it 'grades' these factors using a traffic light colour indicator in the status bar at the bottom of the window. A 'tune' would always produce output power, but a data transmission would seemingly only occur if those parameters were within tolerance, even though the radio was always keyed. The official maximum time sync differential is a tiny 50ms by the way, but I had it working when far greater than that, even with Decodium's NTP turned on. Delta status was reported with a fair degree of believability, and looks to be aggregated from the last few decodes.
An interesting project, and thanks go to the developer (and support team, testers etc.) for bringing it to the community. Don't forget that it's still an early Beta version, and I for one hope that they can iron out the anomalies (particularly the timing issues) and maybe bring some new options to the party. I would personally like to see a custom filter added, much like you can list only decoded 'CQ' calls. I would like to filter/highlight any specific text string - callsigns, 'POTA', regions, grids, wildcard country names, etc.
What additions or changes would you welcome?
I currently use scripts to monitor and flag/alert specific things written to the wsjtx.log file (not the .adi file) but it would be nice to see this included in the application in some way - once the basics are fixed, of course.
Berni M0XYF
