JE1HFUの無線業務日誌

TECH系HAMになりたい

D-STAR P2P通信プロトコルを考える(3) 参加処理の詳細

先日注文した「P2Pがわかる本」、本日到着しました!P2Pの基礎知識がどっさり載っています。まさにこのような本と出会いたかったの!(表紙の絵はなんかあれですが。)

www.ohmsha.co.jp

参加処理の具体的な通信内容について考えます

前回はP2Pネットワークの参加方法について、概要を考えました。今回は、その具体的な通信方法について検討したいと思います。なお、4800bpsという限られた帯域を真の意味で有効活用するためには、通信内容をbit単位で考えるべきなのでしょうが、アプリ開発のしやすさ、他者が簡単にソースコードに手を加えられるように、キャラクタで通信内容を考えていきます。(このソフトはオープンソースにする予定です)

①ネットワーク参加時の各局に対する問合せ

トランシーバの電源を入れ、ソフトを立ち上げた状態では、まだどの局ともつながっておらず、ネットワークから孤立した状態です。

兎にも角にも、まずは近隣の局とコミュニケーションを取らなければいけません。そこで最初に行うのが問合せ。構文は次のような感じかな。

「who_(自局コールサイン)」(”_”はスペース)

②「who」に対する各局の応答

(1)具体的な返答内容

ネットワーク参加者の「who」を受信した局は、自局とつながっている局の概要を参加者に向けて返します。例えば、数のようなネットワークを既に持つJA1BBBは、参加者であるJA1AAAに対して、次のように返答します。

f:id:je1hfu:20200527223514p:plain

既にネットワークを持つJA1BBBがJA1AAAに返答する

「answho_(参加者のコールサイン)_(自局コールサイン)_(ネットワークの規模=つながっている局数)」

JA1BBBはJA1CCC〜JA1HHHまでの6局とつながっているので、以下のような返答になります。

「answho_JA1AAA_JA1BBB_6」

(2)返答にかかる時間

この返答では、22byte = 176bit の通信を必要とします。このデータ以外に、D-STARでデータを送ろうとすると、都度以下のようなヘッダーが準備され毎回送信されるようです。

f:id:je1hfu:20200527225335p:plain

D-STARの無線部ヘッダの容量

つまり、176bitのデータを送るのに、939bitかかります。通信速度は4800bpsなので、0.196≒0.2秒かかります。

(3)輻輳を抑えるための乱数

ここで問題になるのは、例えば以下のようなトポロジーを持つネットワークだった場合。

f:id:je1hfu:20200527224211p:plain

通信が輻輳し通信不可能となる

上図の場合、JA1AAAがwhoを送信した直後、JA1BBB、JA1III、JA1JJJによる返答が一斉に行われ、通信が輻輳しデータを正しく受信できなくなります。

そこで、whoを送った後は一定時間待機の時間を設け、この時間の中で任意の時間に各局が返答するスタイルをとることで、輻輳の確立を減らします。

whoに対する返答は1局あたり0.2秒でできますので、2秒待機すれば10スロット返答のための時間を確保できます。図にすると以下のような感じ。

f:id:je1hfu:20200527230055p:plain

2秒の待機で10スロットを確保できる

この10のスロットのうちのどれかを使って、whoを受信した各局が返答をするようにします。どのスロットを使うか決めるために乱数を使います。この10スロットが少ないか多いかは、ベータ版リリース後に検討します。(確率論が苦手です)

③取りこぼしの有無を確認するための通信

当然、この仕組みを作っても輻輳がなくなることはないので、2秒の待機後に取りこぼしがないか確認するための信号を参加者が送信し、取りこぼされた局がいれば再度応答し…を繰り返します。

確認は以下のように行います。

「else_(自局コールサイン)_(受信できた局①)_(受信できた局②)…」

「else_JA1AAA_JA1BBB_JA1III_JA1JJJ」

④ネットワーク詳細情報の送信要求

受信取りこぼしの局がいなくなったら、各局にネットワーク情報の詳細を送ってもらいます。

要求方法は次のように行います。

「detail_(要求する相手先コールサイン)_(自局コールサイン)」

「detail_JA1BBB_JA1AAA」

⑤ネットワーク詳細情報の送信

detailを受けた局は、自局の持つネットワーク情報の詳細を参加局に送信します。

送信方法は次のように行います。

「ansdetail_(送信先コールサイン)_(自局コールサイン)_(接続済コールサイン①)=(距離)_…」

距離とは、何局の中継局を経由しているかを示す数字です。直接波でつながっていれば1とします。また、複数の経路を持つ場合は、数字の少ない方を採用するようにします。

下図のようなトポロジにおいて、JA1BBBがJA1AAAに返す送信内容は、以下のようになります。

f:id:je1hfu:20200527223514p:plain

JA1BBBがJA1AAAに対してネットワーク詳細情報を送信する

「ansdetail_JA1AAA_JA1BBB_JA1CCC=1_JA1DDD=1_JA1EEE=2_JA1FFF=2_JA1GGG=2_JA1HHH=3」

⑥ネットワーク詳細情報の復唱

ネットワークの詳細情報を受信した参加者は、受信した情報をそのまま復唱します。これは、情報の正確性を高めるための手続きの他に、参加局を通して初めて繋がりうる他局に対する配慮でもあります。例えば下図のような場合。

f:id:je1hfu:20200527233120p:plain

Aが参加することにより、B、C、Dのネットワークが相互に接続される

上図の場合、A局が参加処理を進める過程で、例えばB局のネットワークの詳細情報を復唱すると、C局やD局は初めてB局とその下位に存在するネットワークを認知し、同時に自身の持つネットワーク情報を更新できます。

D-STAR P2P通信プロトコルを考える(2) 参加処理について

先日Hontoで注文したP2Pの本について、なんと昨日「在庫がありませんのでキャンセルさせていただきました」というメールがありました。

在庫僅少って書いてあったじゃん!ないのならないって書いてよ〜〜

Amazonに同じのが中古で出てたので注文しました。

今日は参加処理について考えます

前回は、通信プロトコルの全体像について考えたので、今日はその第1段階であるP2Pネットワークへの参加処理について考えたいと思います。

今回実現しようとしているD-STAR P2Pネットワークは、通信にD-STARを用いるネットワークで、D-STARは受信と送信が同時にできない半二重通信です。しかも厄介なのは、送信と受信が同時にできないだけでなく、同時に1局しか送信できません。このため、いかに各局がタイミングをずらしつつ、最短の時間で求める情報を共有できるかが最大のポイントになりそうです。

送信のタイミングをずらすために乱数を使う

P2Pネットワークに参加する局(新規参加局)は、はじめに近隣の電波が届く範囲にいるすべての局に向けて、ネットワークに参加したいので各局のネットワーク状況を教えてくれという趣旨の要求をします。

これを受けた近隣各局は、自局とつながっているネットワークの情報を通報しますが、一気に返すと混信して通報ができなくなります。そこで、要求を受信した局は、乱数に基づく任意のタイミングで通知させるようにします。これにより混信する確率が下がります。

とは言っても、混信する可能性がゼロになったわけではありません。そこで、通知を受けたネットワーク参加者は、通知を受けることができた局のコールサインを各局宛に送信し、その一覧に自局が含まれていない近隣局がいた場合、改めて通知を行うようにします。この作業を、近隣局の取りこぼしがなくなるまで繰り返します。

また、この最初のステップでは、各局が返す通報に、各局が持つネットワーク情報をすべて(つながっている他局コールサインをすべて)通知するのではなく、何局と繋がっているのかだけを返答させるようにします。こうすることで、最初の通報にかかる時間を節約できます。

詳細のネットワーク情報の通知

近隣局をすべて把握した新規参加者は、近隣局がどの規模のネットワークを持っているのか既に把握できているので、その情報を通知するのにかかる時間も正確に把握できます。混信を防ぐために、近隣各局に対し、どのタイミングで近隣各局のネットワーク情報を通報するのかを指定した上で、近隣各局の詳細なネットワーク情報を通報するように要求します。

要求を受けた近隣各局は、指定されたタイミングで、自局のネットワークに関する詳細を新規参加者に向けて通報します。通報する内容は、自局のネットワークに既に参加している局のコールサインと、その距離です。

距離というのは、物理的な距離ではなく、何局の中継局を介してつながっているかという値のことで、将来ダイレクトにメッセージを送る際、経路を決定する上で重要な値です。

以上をフローにまとめると、以下のような感じになります。

f:id:je1hfu:20200524172349p:plain

P2P新規参加者のフロー

新規参加局に対する応答フローは、以下のようになります。

f:id:je1hfu:20200524172914p:plain

P2P新規参加者に対する応答フロー



D-STAR P2P 通信プロトコルを考える(1)

関連記事が何個になるか分からないので、とりあえずこの記事を(1)としてシリーズ物にしちゃう。笑

D-STAR P2Pネットを思いつき、マイルストーンをとりあえず設定したので、今日から具体的にプロトコルを考えていきます。

P2Pについて先日ざっと調べてみたところ、P2Pノードには①参加処理、②脱退処理、③冗長化、④データ転送の機能を最低限実装する必要があるみたいです。(wikipedia、当社調べ)

やはりこういう勉強は本でしょ、ということで調べたらいいのがあります。

honto.jp

もちろんポチりましたが、なんとコロナの影響で配送まで最低10日かかるとおっしゃいます。勘弁してよ。本が届くまで、ネットで頑張って勉強します。

①参加処理

P2Pネットワークに接続するための通信方法を決めないといけません。この段階のプロトコルを理解するために、IPにおけるP2Pを理解したいと思います。長くなりそうなので適当に読み飛ばしてくださいね笑

IPにおけるP2Pネットワークでは、そのネットワークに接続するとき、既にP2Pに参加している誰かに接続しないといけません。そのためには、そのノードのIPアドレスを知っている必要があります。

コンタクトノードに問い合わせてIPアドレスを知る(ピュアP2P)

コンタクトノードとは、いつも電源が入っているノードのことだそうです。コンタクトノードはいつもP2Pに参加していることがわかってるので、接続者はまずコンタクトノードにアクセスしてネットワークに参加します。

D-STARはVHF帯を使っているので、見通し距離が通信距離の限界です。この方式を採用するとコンタクトノードを全国に無数に配置しなくちゃいけないのでナンセンスです。

手当たり次第に聞く(IPでは実現できないが無線ならできる!)

IPはパケットの送信先を厳密に指定する必要があります。だから、IPにおけるP2P通信は、ネットワークに参加するために、既に参加しているノードのIPを知るための方法が複数編み出されています。(上述のコンタクトノードや、スーパーノード、インデックスサーバーなど)

そこでふと思ったのですが、無線って相手が決まっていなくても送信できますよね。CQです。つまり、D-STAR P2Pネットワークに参加したいノードは、まさにCQを出す要領で近くの通信できそうなノードを呼びかけ、それを聞いた近くのノードは自動で応答できるような仕組みを作れば、コンタクトノードやインデックスサーバーの代わりとなる物を作らなくても容易にP2Pネットワークに参加することができそうです。意外と相性がいいのかも。

②脱退処理

P2Pネットワークに参加しているノードは、今ネットワークに参加しているノードすべてが、どのような形でお互いにつながっているのかを知っている必要があります。これを把握していないと、データの伝送経路を決定することができないからです。

適当な名前がないので、マップと勝手に呼ぶことにします。網目のようにつながったP2Pネットワークの中で、特定の相手にメッセージを送るとき、このマップを見ながらどの経路で伝送しようか考えないといけません。そして、このマップは常に変化し続けます。参加者は増えたり減ったりするからです。

参加者がネットワークから脱退(=切断)するとき、もういなくなるよといってから脱退すれば、残っている参加者は彼がいなくなった後のマップを作り直すことができます。どうやって脱退の情報を伝達するのかというプロトコルも考えないといけません。

③冗長化

そうは言っても、アプリの不具合や無線機の電池切れなど、予期せぬ脱退は起こりえます。脱退宣言なしにある参加者が急に脱退したとしても、それをカバーできるようなシステムを作り上げる必要があります。

常に、「もしこの伝送経路が使えなくなっても、代わりにこの経路を使おう」と備えておけば、突然特定のノードが脱退しても通信を継続でき、ネットワークの安定性が向上します。

そのメソッドの一つに、フラッディング方式と呼ばれる方法があり、これは自分の知っているノード全てにメッセージを送り、どこかで通信エラーが起きても他の経路でカバーできるようにした仕組みのことです。

このフラッディング方式は一見良さそうですが、D-STAR P2Pに採用するのは微妙です。一度に複数のノードに送信できるのが無線のいいところですが、2つのノードから同時に受信はできないからです。このあたりのプロトコルは、頭を使わないといけないかも。

④データ転送

上記の冗長化にも通じる話ですが、無線の欠点は同時に1つのノードしか送信できないことです。1つから複数はOKなのですが、D-STARはGMSK変調であり、GMSKはFSKの一種なので、複数の同時送信は混信してどちらのデータも使えなくなります。ネットワーク参加者が多くなると、ここの問題が顕著に出てきそうです。

 

今日はこれくらいにしておきます。。

D-STAR P2Pネットワーク構築までのマイルストーン

なんちゃってプロジェクトマネジャーです。D-STAR P2Pネットワークの実現のためのマイルストーン、すなわち工程表を考えようと思います。

 

思い立った経緯はこちらです。

je1hfu.hatenablog.com

 

f:id:je1hfu:20200520203439p:plain

D-STAR P2Pネットワーク構築のマイルストーン

正式版(ver.1.0)を配布して終了ではなく、そこからがスタートですが、とにかく世に送り出すところまで持っていかないと。

正式版配布までの道のりを、とりあえず思いつく限りに書き出してみました。プロトコルをしっかり考えて方針を固めた上で、アルゴリズムやアプリのユーザインタフェースなど考えていきたいと思っています。

1. 通信プロトコルの考案

P2Pと一口に言っても、様々な方式があることを調べていて知りました。

各ノードの問い合わせ方法をどうするのか(ピュアP2P or スーパーノード型P2P)、伝達方法をどうするのか(非構造化オーバレイ or 構造化オーバレイ)、ネットワーク接続から切断までのプロセスをどうするのか、などなど。後々頓挫することのないよう、実際の運用を見越して慎重にプロトコルを考えていきたいです。

2. アルゴリズムの作成

通信プロトコルを達成するための時間が最速になるように考えるのがこの段階の目的。D-STARのデータ通信速度に制約がある以上、どれだけ有効にそのリソースを使えるかどうかは、アルゴリズムのセンスにかかってると思います。しかし、Hello worldくらいしかプログラムを組んだことがない自分、ここ一番ヘビーな気がしてなりません。勉強勉強。

3. アプリケーションの開発

P2Pネットワークは参加者の数が物を言うネットワークです。特に電波、wi-fiと違ってピア同士が直接波で繋がるネットワークなので、なるべくたくさんのピア=ハムが参加してほしいと願います。

そこで大事なのはユーザインタフェースです。PCを使ったアプリを開発する方がまだいいかもしれませんが、ユーザーにとって使いやすいのはやはりPCよりスマホと言えそうです。そしてこの使いやすさこそが、ユーザーを増やすために一番大事なところで、手軽に使えるからこそ利用者が増え、利用者が増えるからこそネットワークがより強くなって安定性が向上し、その結果また利用者が増えると思われます。好循環。

4. BETA版リリースと改善

とりあえず動くところまで行ったら、あとはとにかく動かしながらエラーを洗い出し、それを潰していくことでアプリケーションとしてのレベルを上げていく魂胆です。まずはたたき台を作らないと。

6. 正式版(ver.1.0)の配布

過酷なフィードバックにより鍛え上げられたムキムキアプリはようやく正式版となって世に送り出されます。るはずです。ここからがスタートで、より使いやすいユーザインタフェースや、面白い機能を実装していって、常にアップデートし続けながら、面白いネットワークを作っていけたらなぁと思います。

D-STARでP2Pネットワーク

D-STARにはDD(デジタルデータ)モードとDV(デジタルボイス)モードが実装されていますが、DVモードにもデータ通信機能が備わっています。このDVモードを使って、P2Pネットワークを作り上げたら面白いと思っています。そのアイデアのメモ。

DVモード

D-STARの音声通信モードであるDV(Digital Voice)モードには、標準でデータ通信機能が備わっています。これは、音声通信をしながらデータ送信を同時に実行できるもので、データ送信速度はおよそ1,200bpsです。ファストデータモードという機能も備わっていて、これは音声通信分もデータ送信に充てたもので、音声とデータの同時送出はできませんが、およそ3,961bpsの速度でデータを送出できます。

icomのID-51では、USBのアダプタを使うことでPC側ではCOMポートと認識され、このポートにデータを送ることで簡単にデータを無線で飛ばすことができます。かつてのパケット通信では、TNCと呼ばれる、データを音声に変換する装置が必要でしたが、D-STARではこれが不要で、データ通信の敷居が下がったと言えそうです。

P2Pネットワーク

ネットワークの概念の話。馴染みのネットワーク方式はP2Pではなくサーバー・クライアント方式と呼ばれるもので、サーバーと無数のクライアントが繋がってデータをやり取りします。クライアント同士はサーバーを介して接続され、サーバーが動かなくなるとクライアントは孤立します。

f:id:je1hfu:20200519210619p:plain

サーバ・クライアント方式。サーバーがダウンするとクライアントは孤立する。

対してP2P(Peer to Peer)方式ですが、これはピアすなわちクライアントがそれぞれ個別に繋がり合うネットワークの方式です。サーバーがそもそもないので、サーバーの稼働状況はピアにとって無関係です。面白いのは、各ピア同士は複数の経路で繋がっているので、あるピアがいなくなったとしても、別経路で情報を伝達できるところにあります。ネットワーク全体として、サーバ・クライアント方式より信頼性が高いのです。

f:id:je1hfu:20200519211105p:plain

P2P方式。ピアからピアまでの経路が複数あるので、強靭なネットワーク。

レピータはサーバーと同じ

アマチュア無線でいえば、レピータはちょうどサーバ・クライアント方式と言えます。レピータと通信できる範囲にいれば、レピータサイト内にいるハムと通信が可能ですが、レピータがダウンすれば通信が途絶します。

そこで、D-STARのデータ通信機能を使ったP2Pネットワークを構築できたら面白いだろうなぁと思うのです。

インターネットにおけるP2P通信というと、ピア同士はIPアドレスによりつながりますので、ネットワークがダウンすると通信できなくなります。この点、D-STARで繋がったネットワークは本当の意味でのP2Pネットワークだと言えます。

D-STARを使った強靭なP2Pネットワークを構築するには、参加者が多ければ多いほどシステムの信頼性が上がります。信頼性の高いネットワークが構築されれば、災害時にも有益だと考えられます。

どんな機能を実装するか

D-STARのDVモードのファストデータ通信を使ったとしても、せいぜい4kbps程度の速度しか出せません。なので、データ通信といっても、このネットワークでファイルの交換をするといった使い方はナンセンスです。

まず目指すは、D-STARによる物理的なP2Pネットワークに参加している参加者の情報(①コールサイン、②オンライン情報の最終タイムスタンプ(最新のオンライン情報がいつ送られたのか)、③コメント)を、ちょうどSkypeのように一覧で表示させ、ネットワークの繋がりを感じられるところまで行けたらいいなぁと思っています。

問題点

まあなんと言っても無線局運用規則259条(禁止する通報)です。

アマチュア局の送信する通報は、他人の依頼によるものであってはならない。 

(無線局運用規則第259条)

P2Pネットワークとはデータの送信に自分以外のピアをあてにする方式なので、他人の依頼で成り立ってるネットワークです。この条文はアマチュア無線を商用利用させないための条文だと思うので、各局が自発的に通信しているということにすれば大丈夫な気もしますが、まあグレーゾーン?

 

 アプリリリースまでの道のり…

je1hfu.hatenablog.com

 

RN-270のコンフィグについて

RN-270Fを購入しました。説明書全部英語です。どうやって使うのーーー

RN-270Fのデータシート

RN-270Fの取扱説明書

導入編

まずはBluetoothのペアリング。単四電池2本をセットしたら、ペアリング始めるよ。

赤いボタンが一つ付いてるので、これを1秒以上押す。ボタンの下に4つDIPスイッチが付いてるけど、まずはすべてOFF=赤いボタン側になってればOK。

f:id:je1hfu:20200510204612j:plain

中央の赤いボタンを1秒以上押す。

ボタンを押すと、クリアケース内部の3つのLEDのうち、青色と緑色のLEDが3秒ほど交互に点滅し、その後緑色のLEDだけが1秒間に2回のペースで点滅を始めます。

これは起動中の意味らしく、1分続きますのでがまんがまん。

1分後、緑LEDの点滅が1秒に1回のペースになります。これがBluetoothで検出可能になったサイン。この状態で、WindowsやMacでペアリングをします。ペアリングコードはデフォルトで1234です(後で変えられるみたい)

ちなみに、この検出可能時間はデフォルトで3分なので、ゆっくりしてるとオートパワーオフになります笑(これも後で変えれる。僕はソッコーで変えました)

説明書では、接続すると緑LEDが点滅から点灯になると書いてありますが、ペアリングするとすぐ消灯するので焦ります。ここで僕は1時間くらいつまずきました。。

結論から言うと、COMポートをオープンにしないと(つまり、TeratermやScreenコマンドにより通信を確立しないと)緑LEDは点灯しません。

ペアリングがうまくいったら、RN-270が自動でペアリングしたマスター(ここではPCのこと)と接続できるように設定します。赤ボタン横のDIPスイッチをいじることで、自動接続可能の設定をします。2番のDIPスイッチのみON=赤ボタンと反対側にしてください。

f:id:je1hfu:20200510205923j:plain

2番のDIPスイッチだけ、赤色ボタンと反対側にする

これで自動接続可能になります。

設定編

Tera Termで設定します。他でもできると思いますが、試していません。

まず、デバイスマネジャーから「ポート(COMとLPT)」を開いて、RN-270にアサインされたCOM番号を控えます。なぜか2つアサインされます。僕の場合はCOM4でした。

月に、RN-270の赤ボタンを1秒以上押して起動させます。緑LEDが1秒に2回点滅するようになったら、TeraTermで、RN-270にアサインされたCOMに、ボーレート115,200bps、データ8bit、パリティなし、ストップビット1、フロー制御なしで接続します。

注意したいのは、コンフィグモードが有効になるのは起動してから60秒以内の、緑LEDが1秒に2回点滅している間に接続できた場合だけです。

接続できたらすかさず、「$$$」を入力。すると、「CMD」と表示されコンフィグモードになります。

「h」と入力しエンターで、help参照できます。入力はechoかかっていないので、文字を打っても画面に何も表示されませんが、ちゃんとRN-270に届いているのでご安心を。

さて、検出可能時間だけ長めに設定しておきましょう。

コンフィグモードで、「S+,600」と打ってエンターすると、自動接続時間を600秒にできます。これで、無接続で3分経ったらオートスリープを回避できます。

あと、コマンドはShift-JISで送らないといけないので注意です。多分TeraTermはUTFがデフォルトになっています。

Bluetooth-RS232インタフェースRN-270Fが届いた!

無線機の無線化を計画中の僕。FT-450のCAT用端子であるRS232をbluetoothによりワイヤレスで接続し、無線機をワイヤレスでスマートに操作できるようにしちゃおうと考え、Bluetooth-RS232ユニットであるMicrochip社のRN-270Fを購入しました。

本日、無事アメリカからはるばる我が家にやってきましたのでご紹介します。

f:id:je1hfu:20200510200820j:plain

RN-270F。FはFemale(メス)のF。

5月6日に注文してすぐに発注処理され、アメリカのテキサス州からケンタッキー州、アラスカ州を経由して4日後の本日午前、無事到着です。長旅お疲れさま!

f:id:je1hfu:20200510201351j:plain

iCOMのID-51より少し低い丈。なんか昔のガラケーみたい。

Mouser Japanを使って買いました。スピーディにお取引できたので申し分なし。お値段11,484円なり。

しかしアバウトなアメリカ、説明書ついてないし、秋葉原でHDDのバルク品買ったときみたいな袋に裸で入ってました笑

納品書の受注者の会社名、「Mouser Japan Gogo Kaisha」となってて可愛いです。Godo kaisha(合同会社)だと思うよ。

f:id:je1hfu:20200510202003j:plain

Gogo Kaisha

製造元のMicrochip社は、PICでおなじみの電子部品の老舗なので安心。Bluetooth-RS232シリーズはコネクタの形状(オスメス)と、電池タイプor外部電源タイプの計4種の中から選べるようになっています。電池タイプでも外部電源端子がついてるので、外部電源で動くそうです(外部電源を使う場合でも、ニッケル水素電池を入れないといけないらしい)

RN-270Fは電池タイプです。AAA=単4を2本使います。家に在庫がなかったので、近所の100均に買いに行くのでした…

リグの遠隔操作計画(アパマン)

10年前に購入したFT-450(まだDモデルではない)を押し入れから引っ張り出し、話題のFT8をデコードしてみたら、こんなにアクティブなんですね!高校生の頃から興味を持っていたデジタルモード、やってみたいなぁと思っています。

でも、うちはマンションなので不用意に穴を開けたりもできず。どうすれば家を傷つけることなくハムを楽しめるのか…一番いいのは、ベランダからエアコンダクトを使って同軸ケーブルを引き込み、そこに無線機を設置し、無線機を自室のPCで遠隔操作する作戦です。

f:id:je1hfu:20200504103003p:plain

無線機遠隔操作の概要図
  1. リグの操作はBluetooth-RS232により遠隔操作
  2. オーディオはBluetoothを使用
  3. CWはモジュラーを使って自室から遠隔操作

上記3つを実装する計画です。

Bluetooth-RS232デバイスで無線機を遠隔操作

FT-450はCAT(Conputer Aided Transceiver: 無線機のコンピュータ操作)端子が実装されおり、これを使うことで無線機をPCから操作できますが、RS232という奥ゆかしいケーブルを使用します。(USBが普及する前の時代のケーブル)

ただ、これを使うだけでは、別室あるPCから無線機を操作するために、ケーブルを敷設しないといけません。これではナンセンス。

RS232を無線で使えないかな、と調べてみたら、いいのがありますよ。いい時代です。

www.mouser.jp

Bluetoothには、SPP: Serial Port Protocolというプロトコルが実装されています。これは、RS232のようなシリアルポートをbluetoothで実現できるように企画されたもので、まさに今回のような用途を想定して作られたと言っても良さそう。これを活用しない手はありません。下記リンクはSPPに関する説明。

www.kddi.com

Bluetoothを用いたRS232によるシリアル通信を使うことで、無線機をワイヤレスで操作できるようになります。遠隔操作の無線化はこれでクリア。

オーディオはBluetoothトランスミッタを使用して無線化

次はオーディオの問題。つまり受信した音声を別室にあるPCに送り、別室から発せられる音声を、無線機へ転送しなければいけません。これも、Bluetoothが解決してくれそうです。Bluetooth最強説。

Bluetoothを使って音声を飛ばしたり受けたりする装置をトランスミッタというそうです。気をつけるべきはコーデック 。

使用するコーデックによっては無視できない遅延が生じ、後述しますがCWを遠隔操作する際に最悪モールスを打てなくなってしまうのでは?と懸念しています。

Bluetoothのオーディオコーデックには音質も遅延も良くないSBC、音はいいが多少の遅延があるAAC、遅延をなるべく抑える目的のaptLLといった様々なコーデックが存在します。

(2020.5.6追記)MacOSXではAptX LLをサポートしていないという噂を耳にしました…

どのくらいの可聴周波数帯域を送受信できるのかという問題もあると思います。(帯域があまりに狭いとFT8等のデジタルモードやるときに制限がかかりそうな気もする)

また、圧縮率があまりに高いと、デジタルモードの音声をきちんとデコードできるのか、相手局がきちんとデコードできるのか?と言った問題も生じてきそうですが、それこそアマチュアの真骨頂!まさに実験により明らかにしていきたい問題であります。

ともかく、これらのコーデックのうちどれを採用するかは、これから考えたいと思います。長くなりそうなので、別に記事を起こそうかな。

CWはモジュラージャックを使用して、自室から操作

これも大問題であります。とにかくすべての通信系ケーブルをワイヤレス化しようと考えているので、どんな細いケーブルも床をつたわえることはNGなのです!

この問題については、結論を言うとモジュラーを採用するのですが、同じように試行錯誤されている方がいらっしゃいまして、とても参考にさせていただきました。

minkara.carview.co.jp

この記事を見るまで、モジュラーを使うというアイデアは考えもしませんでした。ナイスアイデア!ありがとうございます!

アパマンでも素敵なハムライフを

施工はまだ先になりそうですが、仕様と採用する製品等を検討して、随時UPして行こうと思います。楽しみだなぁ!

GL(グリットロケータ)から当該範囲を地図上に表示する便利なサイト

www.levinecentral.com

 

昨日からワッチを初めてみたFT8ですが、噂通り活況でびっくりしました。PC上に次から次へと交信内容が出てくるのは見ていて楽しいです。

RTTYやPSKと違い、ONAIRの周波数が決まっているのも面白いですね。トランシーバをいじらずにPC操作に集中できます。

交信はラバースタンプそのもの、GL(グリットロケータ)で運用場所をやり取りし、信号強度を交換して終了。僕の耳では聞き取れない音でも、PCがしっかりデコードしてくれるので、びっくりします。

さて、FT8では、運用場所をGLを使ってやりとりしてますが、まだ駆け出しの僕はこの記号を見てもどこの国なのか、東から飛んできた電波なのか西から飛んできた電波なのかさっぱりわかりません。

いいツールはないかなと思ってたら、ありました。さすがワールドワイドウェブ。

Amateur Radio Ham Radio Maidenhead Grid Square Locator Map

グリットロケータ(4文字ないし6文字)を入力すると、範囲を地図上に表示してくれます。

僕は地理が苦手でしたが、学生のころにHFの魅力に憑かれてれば、もしかしてもっと点数が良かったのかな。

QSLダイレクト送付の連絡先をどう交換するか

f:id:je1hfu:20200323105204p:plain

どのように安全に個人情報のやり取りをするか

D-STARのメッセージ機能を活用する

D-STARのDVモードを使って、シンプレックスで交信することにめちゃめちゃ興味を持っています。

僕はJARLに入会していないので、QSLカードをビューロ経由で送ることができません。

よって、QSLカードの交換は必然的にダイレクトになるのですが、QSLをダイレクトで送るのって、人によっては少し敷居が高いのかなと思ったりもします。個人情報をどうやってやりとりするか、住所氏名等の漢字をどう伝えるかなどなど。

D-STARには音声にメッセージを重畳する機能があります。僕はこの機能を活用すれば、QSLカードのダイレクト交換をよりスムーズに確実に、かつ安全にできるのではないかと考えています。その方法は?

メッセージ機能を使って電話番号を交換し、SMSで住所を交換

デジタルにしてはだいぶアナログな方法だと思いますが…

でも、これが一番確実で安全だと思いませんか。

どうやるかというと、QSLカードのダイレクト交換をお願いした上で、住所氏名等のやり取りはSMSでするのです。SMSは電話番号さえわかれば送ることができます。そして、この電話番号のやりとりに、メッセージ機能を活用できると思うんですよね。

D-STARのメッセージ機能を使って、お互いの電話番号を交換できれば、もし仮に無線を傍受していた第三者がいたずらのSMSを送ったとしても(そんな人はいないと信じたい)、QSLを交換しようとしている2局は互いの電話番号を把握しているので、第三者からのSMSがいたずらだとすぐにわかります。交換した番号ではない番号からのSMSだとわかるからです。

また、非通知SMSによるいたずらを懸念するかもしれません。この点については問題ありません。いたずら防止のため、非通知でSMSを送ることはできなくなっているからです。

SMSはキャリアの垣根が一切ない最強のシステム。これを活用しない手はない

SMSは2011年から、事業者(docomoやauやsoftbankなど)をまたいでやり取りができるようになりました。それまでは同一の事業者間でしかやりとりができなかったんです。

11桁の番号をお互いに交換するだけで、安全にメッセージのやり取りができるようになるSMSを活用しない手はないと思います。

(c)2020 Daichi Yamada | プライバシーポリシー