Having read the introduction of Decodium, as being “the fastest” mode, my first take was “too good to be true”. Physical laws cannot be broken. So let’s have another look at things.
Popularity
PSKreporter has a statistics page, which shows the number of spots received.
A snapshot taken on March 10, 2026 shows that the number of FT2 spots is about 0.19% of the FT8 volume. It was higher a week ago, about 0.4%. Conclusions up to the reader.
Signal to noise ratio evaluated
Searching for data, I downloaded ADIF files from PSKreporter. A bit of searching revealed that PJ2/PD1DRE was active with FT2 from PJ2 and the logged SNR’s were evaluated. At first glance, the values were rather suspicious, because many values were below the specified threshold.
The graph below is a histogram of the reported SNR’s, which shows counts of SNR values from the PSKreporter “log” of PJ2/PD1DRE. The histogram clearly shows that something is not right.
There are way too many values below -11 and that goes against the theory. In order to verify the SNR’s, a test was done to evaluate decoding, comparing with FT8 and FT4.
Signals were routed directly from one instance of Decodium to a second instance via Virtual Audio Cable. Not a real world test, but a theoretical one. Spectrum Lab was used to add Gaussian white noise and to verify levels.
The picture shows the reported SNR’s of FT8, FT4 and FT2. All relative to 2500 Hz and we can thus compare the modes with the same power and noise levels. The table shows that FT8 and FT4 values are identical (several periods were averaged and rounded to the integer value). The orange coloured levels are those where decodes become unreliable.
FT8 obviously has the best sensitivity. FT4 performs about 3 dB less and FT2 is another 4 dB behind. The lab test shows that the Decodium threshold is about 2 dB lower than the “specified -11”. Decodes were reliable down to about -13.
FT8 and FT4 have sharp cut-offs below the threshold, whereas FT2 has a softer slope, which does not surprise, given the shorter integration time.
The test also showed that reported SNR’s near the threshold become increasingly inconsistent (or one can say that “values become noisy”). I assume that the shorter cycles are also responsible for the increasing variations.
The histogram values suggest that fading affects the accuracy of the SNR algorithm. One could even argue that FT2 can make use of short signal peaks, but that comes at the expense of lost cycles. Nevertheless, Rob PE1ITR mentioned that FT2 might be advantageous for example on VHF/UHF where short-lived aircraft reflections can occur. Rapid TR cycles could be beneficial in such a case.
From the test, we can conclude that the SNR threshold for ideal circuits is about -13 dB (applying the same criteria as with FT4/FT8). Although that value is a bit better than the “advertised” values I assumed in the earlier article, the overall picture does not change much. The earlier considerations about QSO rates and SNR performance were based on theoretical parameters, but it did not take the real world into account. Especially fading and interference have considerable impact.
Structural SNR bias
The table shows that Decodium reports about 2 dB lower values than what it should be, which could be interpreted as being more sensitive than it actually is.
Time constraints
The greatest challenge of FT2 are the stringent time constraints.
The very short cycles not only require precise time keeping, but decoding has to be completed within a very short interval.
The “specifications” according to ft.it are:
| Parameter | FT8 | FT4 | FT2 |
|---|---|---|---|
| T/R Cycle | 15 s | 7.5 s | 3.8 s |
| TX Duration | 12.64 s | 4.48 s | ~3.55 s |
Based on the “TX Duration” in the table, only 250 ms is available for decoding. A little test to time the actual transmissions and gaps in between.
With Spectrum Lab, I recorded a few transmissions whilst switching between even and odd, to time the length of transmissions during even and odd cycles, which compares to subsequent TX/RX cycles. The waterfall graph with second markers shows the transmission duration to be a bit over 3 seconds and gaps are approximately 600 ms.
If we assume perfect timing and flawless TR switching, we end up with approximately half a second. WSJT-X starts decoding before the transmission is completed and good signals can be decoded before the transmission ends. This means that strong signals leave a bit more time to decode before the response has to be determined.
After the test, I switched to audio from the Maasbree web SDR to observe real world signals, because I was not in the shack. The SDR latency is about 500 ms and I noticed that Decodium adapts the timing. An indicator at the bottom of the screen shows the time lag and after some cycles, it turned from red into yellow and green, along with decreasing DT values in the windows above. The “time tuning” also seems to depend on the activity.
Being a long time user of JTDX, which has the capability of shifting the time within the application relative to the computer time, I am, familiar with the option to synchronise the “application clock” with the received periods. It does no change the computer system clock.
Decodium has a Time Synchronisation panel, which shows the state of affairs. The decode latency varies considerably and latencies of 4 to 5 seconds are not an exception. That means that decoding finishes well into the next cycle.
Time offsets (Delta Time or DT) can degrade decoding or even make it fail if the clock is too far off.
It is obvious that the stringent time requirements for FT2 had to be addressed to have it work at all. Decodium tunes the application time to the DT’s of the decodes and slowly adjusts the application clock.
From what I have seen, many transmissions are not timed exactly and that suggests that running Decodium applications use time shifts as a result of the time tuning.This obviously degrades the decoding probability because of timing differences.
There is even a runaway risk when active applications keep adjusting time and offsets can also start to oscillate back and forth. This effect was the leading cause of the power failure in Spain last year. Because the Decodium time tuning code is not open source (thus an infringement of the GPLv3 licence), it is unclear how the mechanism operates.
Supercomputers needed?
The (too) short gaps between the cycles pose a serious problem and only very powerful computers might be capable of decoding before the next cycle starts. That is particularly true for the DXpeditions “use case” as proposed by IU8LMC, who need to decode a huge amount of calling stations in order not to be overwhelmed.
A side by side test with Decodium versus WSJTX-improved showed that Decodium missed entire periods whereas WSJT-X did not. The test was performed with live signals on 20 m (audio direct from IC7600 to both applications) and over 6000 decodes were received.
Decodium missed over 10% of the messages decoded by WSJT-X, where WSJT-X missed about 1% of the messages the Decodium decoded.