A quote from the website (ft2.it):
“Complete QSO in 7-11 seconds. Theoretical rate of ~240 QSO/hour, ideal for contests and DXpeditions.”
OK, game on. Let’s check.
What about FT8 Superfox?
The user manual states:
(…) Standard messages include up to 9 Hound callsigns: as many as four may receive numerical signal reports to start a QSO, and the remainder receive RR73 to acknowledge that a QSO has been logged. (…)”
If you assume that everything runs smoothly and that each message always contains four reports (start QSO), then the stations that received a report will receive RR73 in the following period and four new ones will receive a report. So a maximum of eight reports per minute can be reached, which I believe determines the maximum throughput. I would then arrive at 480.
There is a small advantage such that 5 RR73s can be sent simultaneously, allowing ‘pending’ RR73s from previous periods to be ‘caught up’. This happens, for example, when a hound’s R-NN report is missed due to fading or QRM. The number of reports of 4 remains the same, of course, but the ‘damage’ caused by missed periods is somewhat limited. After all, 5 RR73s can go together with 4 reports.
The practical rate is obviously less. I watched the Jarvis DXpedition via a web SDR to get an impression of the real world performance. Just as with FT8, a fair number of repeats was seen and the actual rate was about 2.5 to 3 Q’s Q per minute, which is about 150 to 180 per hour.
Initial Superfox tests as reported by K1JT
Joe reported initial superfox tests via groups.io and rates between about 250 and 350 per hour were attained.
The SNR was in the + range for the test and I think that the Jarvis number is closer to reality. It has to be noted that the Jarvis team used the RIB concept with only 100 Watts output. Because I could see both sides, it was observed that the hounds regularly failed to decode the fox and, conversely, the fox did not always respond to the reports of the hounds.
In case expeditions use more power, the rate will become higher. I consider rates between 150 and 250 a fair reference.
Decodium versus FT8 Superfox
K1JT and K9AN documented sensitivity comparisons between Superfox and “normal” FT8, see [1].
The signal to noise ratio threshold for Decodium is stated to be -10.8 dB. I assume that this it the theoretical limit. This is worse than the Superfox threshold, which is about -16, so 5 dB sensitivity is lost relative to Superfox.
Then we have the hounds. With Superfox, they transmit normal FT8, which means that the FT8 threshold of approximately -20 applies. Decodium hounds call with Decodium *FT2). About 9 dB difference.
It is obvious that FT8 Superfox is far superior.
Attainable QSO rates
The claimed rate of 240 Q’s per hour is the theoretical limit. In real life, speed will be substantially lower. The theoretical limit for Superfox is 480 Q’s per hour, but the real world rates were around 250 to 350 or 52 to 73% of the maximum. If we assume that Decodium can attain similar percentages, the QSO rate would be between about 125 and 175 Q’s per hour.
But I doubt that these percentages can be reached. Because the required bandwidth for Decodium is three times the FT8 bandwidth. If we assume that the same amount of hounds would call in the same passband, there will be a lot more mutual interference between the Decodium hounds which implies that decoding will be a lot more difficult.
It is easy to understand that QSO rates further drop considerably in a busy band and at the end of the day, I estimate the real rate near about 120 Q’s per hour.
We should not forget that the theoretical limit for a single stream FT8 Fox/Hound is 120 Q’s per hour and a dual stream has a limit of 240 per hour. If we assume a 50% real world rate, the two stream FT8 is roughly equal. The power per stream is about 6 dB lower (if set correctly) and the loss of sensitivity is about equal to the above mentioned 5 dB. The SNR’s at the Fox are still normal FT8 values and thus about 9 dB better. The narrower bandwidth of FT8 is also an advantage (for F/H, the hounds should call above 1000 Hz and if we assume 3 kHz bandwidth, FT8 channel capacity is still twice as much).
Other performance considerations
The shorter transmission durations will render the protocol more vulnerable for interference and (impulsive) noise. Longer integration enhances resilience and I expect Decodium decoding probability to be relatively lower.
Computer clocks need to be very wel synchonised which can be an additional hurdle. Because of the shorter transmissions and the inherently shorter decoding interval, computer requirements are a lot more stringent. Computers that perform well with FT8, can be too slow for Decodium. Good for computer vendors, but bad for the environment.
Conclusion
SuperFox demonstrably outperforms Decodium (FT2) in sensitivity, decoding robustness, and achievable throughput—making FT2’s main advantage (shorter exchange time) effectively irrelevant for real-world DX conditions.
In plain terms: FT2 runs faster—but only downhill with a tailwind.
Reference s and notes:
[1] SuperFox and FT8: Weak-Signal Performance, Joe Taylor and Steve Franke, September 6, 2024
https://wsjt.sourceforge.io/SuperFox_Performance.pdf
[2] My estimate of -20 is based on many hours of practical experience with FT8. This value is for non a priori decodes.
Appendix
Artificial Intelligence software “development”
The “developers” state that the code was based on FT8/FT4 code and AI was used to change the protocol for the higher speed. The amount of “development” is probably minor, since I expect that after changing some parameters, much of the code can be used “as is”.
The software is announced with a lot of fanfare, as if it is a revolutionary invention, which it is simply not. My analysis refutes the performance claims made and my impression is that the initiators failed to address fundamental considerations. Because otherwise, they would draw the above conclusions and abandon the idea.