近年のFT8ブームをみるに、非常通信周波数でSSBなりで声を出すよりも通常のFT8運用周波数でFT8のメッセージによって救援を求めた方が到達性が高いと考える。
同様なSN特性を持つ他のより自由文が扱えるシステムの方が適している面もあるが運用可能局の多さからあえて通常のFT8運用機材にて可能は運用手順を考えてみよう。何故ならば受信している局数が多くなければ通信は成立せず2020年現在ではFT8が圧倒的な運用局数だからである。送信側も非常通信用のソフトウェアがセットアップされている確率よりもFT8の運用環境がすでに整っている可能性が高い。
自由文13文字
各メッセージ送信元コールサインを含める事はできないため同一変調周波数であれば一連のメッセージと解釈する必要がある。
経度緯度だろうなぁ、最近のRIGにはGPS機能あるし圏外になった携帯からも緯度経度情報は得られるだろう
APRSのフォーマットが流用できれば良いのだが全く文字数が足りない。
経度緯度情報である事を示す記号は所詮受信したオペレータの判断に期待するためあまり省略すべきでは無い。LON/LATで三文字残り
QTH nnnnn/nnnn でも良いか？桁数が足りるか？
有効桁数。100m程度の精度を要求した場合何桁まで必要か？
十桁のグリッドロケータの精度は？
救助依頼：緊急度、位置情報、人数
受信した人に何かしらの公共防災機関への連絡を期待する。公的機関に連絡するには姓名が必要であろう。
通知依頼；緊急性はないが無事である事を知り合いに伝えて欲しい。
pskreporterに受信記録が残るだけで生存確認ができるとも考えられる
受信した局がどう対応するかが難しい。Google パーソンファインダーなのかなぁ。
https://google.org/personfinder/japan
個人を特定する情報としては携帯電話番号が手っ取り早いが、無線で広報してしまうのは問題か。非常時だと許容するか？
姓名をにメッセージで送るか？
相手を特定する交信の形式を取らずにビーコン的に送信する場合にはそれを受信した複数の局から公的な期間に救援要請が転送されることが予報される。重複する情報が多数寄せられる事は好ましくないが発信者のコールサインと受信時間によって重複であるかの判断は可能であろう。
想定運用例１：救助依頼
SOS JN1OLJ
LON 133.23456
LAT 45.23456
QRA
QSP JN1OLJ
世界的に数多くの受信局が稼働しているpskreporterに集まる情報は非常に強力であり。これに非常通信の通報機能を加えるアプローチ。
短縮記号の割当：状態コード、人数。
WSJT-Xに代表されるクライアントソフトウェアに非常通信モードを追加。試験モードも必要。救援要請内容やそれに伴うコードの符号をプロトコルとして定義。
自動的に公的機関に連絡が行くのはやりすぎか。何かしらのアラートが自動的に発信される機能は欲しいところ。地域によって対応は大きく異なるけど。
WSJTXはソースコードが公開されており、改変バージョンを作る事は可能。コンパイル環境を調査する必要がある。ただし、改変したバージョンを配布するかは別問題。
汎用のメッセージングを可能にしたJS8CALLにはすでにAPRSへの連携機能がある。10桁のグリッドロケータを手動で入力。