(Copyright)Mr.Mike Hasselbeck / WB2FKO
このコスタス配列のベースライン周波数がtime step =4 に来ているところは、同期処理が最も速く開始できるように、音0 (baseline freq.)がtime step = 1 に持ってきたほうが良い感じ。time step = 1 の音3と、time step = 4の音0を交換したほうが良いかも。
物理プロトコルは8値のFSKなので、計算式でこんなに簡単に書けます。😃
復調処理は、サイン関数の逆関数arcsinを使って、未知の k を求めたいわけですよね。
FFT処理でも、160mS毎に、k=0〜7の数値 が求まるのと合わせ、
上記式だけでも、復調方式の演算法がはっきりクリアに見えます。
逆に式を使わないかぎり、解読の数値演算処理はプログラミングは、やりようがないので、「数式不要!」というようなネット講座では、いかがなものか？と。😓
＼(^o^)／(約6BPS程度の超低速データ転送速度では、隣り合う8個の周波数キャリアは、周波数は常に一つの値でFFT積分処理で、値kを突出させる。それにより、ノイズ成分とキャリア信号を浮き出させる。という着想のように思います。:D
最初は、処理のフローチャートに見えたものの、そうではなく、プログラムの処理を曖昧に列挙した感じ。
FT-8のプログラム処理で、重要なキモは、先のコスタス配列の受信信号に同期させサンプリングされた16Bit/ワードの音の15 秒データの全てをFFT変換後に、時間同期と、周波数同期の二次元行列の補正計算を行うこと。
(受信したコスタス同期信号を基準に、時間と周波数について、サンプリングデータのFFT積分値のズレ分を補正計算する。)
(Copyright)Mr.Mike Hasselbeck / WB2FKO
1フレーム15秒は時間がかかりすぎるので、同期信号は、最初と最後の２個がいいかなぁ。1音/160mSは、AD変換器のサンプリング周波数が、192KHzにも上がっているので、16mSくらい、1/10にしたい。1フレーム 1.5秒ですむし。
無線機には、あらかじめ「コールサイン」と位置情報「グリッドロケータ６文字」の情報しか送受信しないので、パソコンで信号処理するよりも、無線機側に、下図のようなオーディオ用のADC/DACを実装し、ハードはこれだけの制御で十分で、あとの信号処理を無線機内のプログラムROMに実装すれば、パソコン使わなくても、送受信スイッチ操作で、ほぼ自動通信できちゃいますよね。😄
(Copyright nabe様)
WSJTアプリの更新があるので、現状PC上のアプリ実装ですが。プロトコル仕様が落ち着けば、という条件でですが・・・。
callは、ボタンを一回押すだけ・マウスをクリックするだけ・・・て、面白さとしては、どうなのかな？
IC-7300には、先のTI社ADC/DACがしっかり入ってました。
受信音のFFT処理等によるノイズ分離は、パソコンのWSJTが処理。
電信の場合は、スイッチ操作だけで、コールサインと、RS送受信できるので、それと同様の簡単な操作性が、FT-8等でも、もっと安く実現できる構成ができそうですね。
CWではコールサインは3〜4秒で送れるのと、流星エコーの短い時間の電離空気の反射を考えると、FT-8の15秒/ 送信フレームは、やはりできるだけ短くしたいところ。
S/N比を上げるのにFFTは最高の手段だけど、簡単にプログラムするには、移動平均でも音の解読は可能なので、もっと楽にプログラムする手もありかも。
動画編集で解説するほど難しくなく、仕組みを理解すれば、実装の考え方だけなら、
とても優しく、そんなに難しくないかんじ。😄・・・と思うんですが・・・。
たし、何より、FT-8等Weak Signalの変調モードを使う人々が、大勢で束になって呼ぶ状態では、受信側ではどうにも解読できなくなるので、使う側も、FT8通信のしくみを考えないと、昔式 おばか "じゃぱ〜ん" の人らと同じレベルになっちゃうよねぇ・・・😒 😓
ローカル局とは仲良くという記事みっけました。
15秒も連続送信してたら、相手の信号受信がむつかしそう。
やっぱり送信時間は短くしたいところでしょうか・・・。
----
以上、FT-8デジタル通信方式について、ほぼ全体を網羅できたと思います。
どんな聞こえ方かは、こちらのyoutubeサイトにも上げては見ましたが、見に来る人がほぼいまぜんので、これ以上の情報は不要というところか・・・？と思います。
多分、より詳しく方式や設計法を説明しても、わかってもらいない、という限界点みたいなものがある感じがしています。2022/06/25
