最近、なかなか興味深いJTDXのForkを見つけました。

JTDX_CONTEST by CE3TSK

JTDX_CONTEST公式サイト GitHub

名前だけを見ると「JTDXにコンテスト機能を追加した版かな？」と思うのですが、実際に調べ、動かしてみると、それだけではありませんでした。

JTDXユーザーにはかなり気になるFork

私はJTDXのベータテスターとして、一般公開版の2.2.159だけでなく、2.2.160 RC版も使用しています。

今回は、次のソフトを同じWAVファイルで比較してみました。

• WSJT-X 3.0.2
• JP1LRT Edition（WSJT-X 3.1 Improvedベース）
• JTDX 2.2.159
• JTDX 2.2.160 RC版
• JTDX_CONTEST v3.0.0-rc05

ところが、そのBenchmark WAVに見覚えが……

JTDX_CONTESTのサイトには、作者CE3TSKが性能評価に使用しているBenchmark WAVが公開されています。

FT8 / FT4それぞれ1時間分、240 periodの実受信データに加え、信号数が既知のcrowded-band用WAVも公開されており、Pythonのbenchmark scriptまで用意されています。

そのcrowded-band用FT8 WAVのファイル名を見て、

となりました（笑）。

元のファイル名は、

210615_071015.wav

2021年6月15日 07:10:15 UTC。

これは、このBlogでも以前公開したWAVです。

録音したのは、6m仲間のJR1LZK 田崎さん。茨城県水戸市で50MHzを受信した際の、非常に混雑したFT8の1 periodです。

当時、田崎さんの了解をいただいて、このBlogでBenchmark用として公開しました。

2021年の記事「FT8 decoding benchmark」

今回、JTDX_CONTEST側の ft8_full_band_16.wav と、元の 210615_071015.wav を実際に比較したところ、バイト単位で完全一致していました。

CE3TSK側では、このWAVについて104信号のtruth setを作成しており、そのうち101局がJA局だったと説明しています。6mの大オープンらしい、かなり過酷なデコーダー試験素材です。

同じWAVで比較してみた

今回の手元での比較結果は次の通りでした。

73 → 75 → 83 → 93。

このWAVのような、極端に多くの信号が重なった状況では、かなり大きな差です。

まず、WSJT-X 3.0.2とJP1LRT Editionはともに73 decodeでした。

JP1LRT Editionではデコーダー部分に手を加えていないため、この結果はある意味当然ですが、少なくとも今回の試験では、JP1LRT Edition独自改造によってデコード性能が低下しているわけではないことも確認できました。

JTDX 2.2.159では75、2.2.160 RC版では83、そしてJTDX_CONTESTでは93でした。

JTDX_CONTESTは何をしているのか

JTDX_CONTESTの面白いところは、単純にデコード閾値を下げただけではないところです。

Ensemble decoding

同じ音声にわずかなdelay、dither、frequency shiftなどを与え、複数の条件でdecodeし、その結果を統合します。

Alternate pass

通常のdecode後に残ったresidual audioに対して、別のdecode recipeでもう一度探索します。

Hint memory

一度decodeした局やメッセージの情報を複数periodにわたって保持し、次のdecodeに利用します。

Background decoding / Pipeline

そして個人的に最も面白いと思ったのが、Background decoding / Pipelineです。

「送信中にもdecodeする」

通常のFT8ソフトでは、受信periodが終わるとdecodeを実行し、その結果で次の送信内容を決めます。

JTDX_CONTESTは、ここを二段階に分けています。

まず短時間のRX phaseで、次の送信を決めるために必要なdecodeを済ませます。

その後、こちらが送信を開始してからも、直前に受信した音声を保持したままBackground decodingを続けます。Alternate pass、Ensemble、Residual decodeなどを、従来ならCPUが遊んでいた時間に実行します。

例えば、Background decodingで次のようなものを見つけたとします。

• 自局宛てのメッセージ
• New DXCC
• New Call on Band
• 強力な局の下に埋もれていたDX

現在の送信には間に合わなくても、その情報をHint memoryなどへ引き継いでおけば、次の受信periodでは既知候補として扱える。

つまり送信中の追加decodeは「今の送信を変えるため」ではなく、次の送信判断に使う情報を先に掘っておくための処理と考えると分かりやすいと思います。

6m DXでは、これはかなり価値があると思います。

一瞬のオープンでNew DXCCが出てくる6mでは、これが一番悔しいパターンです（笑）。

送受信に使うも良し、受信専用でも良し

JTDX_CONTESTは、普通に送受信ソフトとして使うこともできます。

一方で、

という使い方も面白いと思います。

JTDXユーザーの中には、取りこぼしを嫌って複数のdecoderを同時に動かしている方も少なくないでしょう。

そういう人にとっては、かなり興味深い選択肢になるはずです。

Contest機能も搭載

名前の通り、JTDX_CONTESTにはコンテスト機能も組み込まれています。

現在は特にWW Digi DX Contestを意識した実装となっており、exchange、points、multipliers、contest logなどが統合されています。

単なる「JTDXのdecoder実験版」ではなく、実戦運用までかなり意識して作られている印象です。

Benchmark環境も公開されている

もう一つ評価したいのは、作者が性能を主張するだけでなく、検証用のWAVとscriptを公開していることです。

• FT8：実受信1時間、240 period
• FT4：実受信1時間、240 period
• crowded-band WAV
• truth set
• benchmark script

crowded-band用WAVにはtruth setがあるため、単に「何局decodeしたか」だけでなく、false decodeまで評価できます。

JTDX_CONTESTを見てみる

JTDXユーザーなら一度試してみる価値あり

JTDX_CONTESTは現在、v3.0.0-rc05です。

したがって、完成したGA版として評価する段階ではありません。

しかし、長年JTDXを使っていて、

という人には、一度試してみる価値がかなりあると思います。

特にFT8 / FT4でDXを追いかけている人、6mのような一瞬のオープンを狙っている人には面白いでしょう。

実際の送受信に使うも良し。受信専用のサブdecoderとして使うも良し。

Webサイトは日本語表示にも対応しています。

JTDX_CONTEST公式サイト

最後にちょっとだけ

今回、

WSJT-X 3.0.2 = 73
JP1LRT Edition = 73
JTDX 2.2.160 RC版 = 83
JTDX_CONTEST = 93

という結果を目の前で見てしまいました。

でも、JP1LRT Editionではデコーダーには手を付けていません。

これはむしろ、次に何を研究すべきかが見えてきた、と考えることにします。

73, Yoshi / JP1LRT