IRLP構築日記

Back to www.ji1bqw.com by JI1BQW
2007年より,IRLPノード構築日記はブログに移行します。

IRLPはThe Internet Radio Linking Projectの略で,WiRES,eQSO,EchoLinkと並ぶインターネット/VoIPを使用したアマチュア無線の一方式です。IRLPオフィシャルホームページによると,1997年にカナダはバンクーバーの地において,VE7LTD/David Cameronによって開発されました。ちなみに他を調べてみるとeQSOが1999年,EchoLinkとWiRESが2002年くらいのようですから,一番歴史があるのでしょうか。(注)

(注)各方式の発祥時期については必ずしも正確ではありません。

VoIPにもいくつかの種類がありますが,IRLPはSpeak Freelyという元はLinuxベースのVoIPを採用しています(Windows版もあり)。基本的に16bit/8KHzサンプリング,ADPCMコーデック(32Kbps)ですので音質は良好です。インターネット接続回線の速度に応じて,GSM(17Kbps)という海外携帯電話やEchoLink,eQSOで使用されている高圧縮のコーデックも選択できます。

日本では,Linuxベースのシステムである,ハードウェアを輸入する必要があるらしい,日本語のサポートが無い等々あり,あまり普及していないようです。しかし,言語を除けばそのボランタリーベースのサポートの良さは異口同音に聞くところ。ここはひとつやってみましょう。

最終的にはWiRESあるいはeQSOとのゲートウェイ構築を目指しますが,まずはIRLPノードを作り,それ自体を経験することを最初の目標とします。その後WiRES/eQSOとのゲートウェイ構築が可能かどうかを検討します。前述オフィシャルホームページでは,現状他VoIPネットワークとの単純な接続は推奨されていないようです。これは技術的な理由というよりも,セキュリティーレベルの違いや,運用ポリシーの違いのためのようです。このあたりも今後調査・検討の必要があります。

(注)その後の検討の結果,上記の理由により,他ネットワークとのゲートウェイ構築は目標とはしないことにします。

以下,構築の様子を書いていく予定です。ご質問,感想,コメントなど,内容に関するフィードバックを是非お願いします。
また,IRLPに興味はあるのだが,ボード注文の仕方や,ノード構築方法のさらに詳細を知りたいという方,私のつたない経験からのみではありますが,できる限りお役に立ちたいと思います。遠慮なく連絡ください。


2007年01月06日(土)

開設以来ベタ書きをしてきた当日記だが,いよいよブログでやってみようと思い立った。過去に一度試してみて,結局ベタに戻ったこともあるが,今度はそうならないように・・・。


2006年12月20日(水)

IRLP MLに大変面白い投稿があった。VoIPノードやレピーターへの妨害というのは東西を問わないようだ。妨害局を見分けるための,送信機識別装置(Transmitter FingerPrinter)が売られている。

FM受信機のディスクリミネーターから信号を取り出して,それをパソコンに専用インターフェースカードを経由して入力,解析する。個々の送信機は,例え同じメーカー,モデルであったとしても,送信立ち上がり時の周波数変動,安定化までの時間に個々のくせがあり,それを送信機固有の「指紋」として個体判別をするらしい。認識率など大変興味深い。録音もできるそうなので,まさに妨害局対策である。

PCインターフェースカードが,モービルトランシーバーが2〜3台買えそうな値段なので,個人では簡単には手を出せないが,ノード妨害に困っているクラブなどでは検討してみたらいかがだろうか。

「送信機識別」には,他にもいくつか方法があるらしい。


2006年12月16日(土)

今までサウンドカードはCMI8738を順調に使ってきた。今でも全く問題ないのだが,手持ちの古いサウンドブラスター2枚でも(AWE64/CT4520とPCI128/CT4700)でも試してみようと思い立った。両方ともずっと前にヤフオクで300円くらいで入手していたもの。

サウンドカードを変えた場合には,ルート権限でalsaconfを実行しサウンド系の再構成をする。さらにaumix(あるいは必要に応じて alsamixer)で再生,録音音量を調整する。

PCI128(CT4700)では,上記の手順のみで問題なく動作した。ISAのAWE64(CT4520)では,上記だけではドライバーが作成されないので,以下のようなもう一工夫必要。

(以下,ルート権限)

alsaconf実行後,/etc/modprobe.d/sound ファイル内で
alias snd-card-0 snd-sbawe
alias sound-slot-0 snd-sbawe
というエントリーがあるかを確認。snd-xxxという名前を覚えておく。これはカードによって異なる(snd-sb16など)。

/etc/rc.d/rc.local ファイル内に
modprobe snd-sbawe
という一行を追加し,リブート。

/etc/modprobe.conf ファイル内で
alias snd-card-0 snd-sbawe
というエントリーを確認,なければ編集して加える。リブート。

以上でドライバーが追加されると思う。あとはaumixで音量調整。

しばらくは,PCI128で運用してみようと思う。


2006年11月21日(火)

先日導入されたUNCOMPモードだが,やはりサウンドカードなどとの相性により一部のノードでオーディオの不具合が出ており修正が困難らしい。よって,UNCOMPモードは一度白紙に戻すらしい。今のところいつ再開できるかは未定である。音質の向上を実感してみたかったが,ノード変更したにもかかわらず実験する機会を得られなかった。大変残念である。

$CUSTOM/environmentファイル内で,変更した DEFAULTCODEC環境変数は引き続きUNCOMPのままにしておいて良いとのこと。


2006年11月18日(土)

UNCOMPモードの導入以来,オーディオに若干不具合の出ているノードがあるようだ。サウンドカードとの相性などもあるらしい。現在,imike/ispeakerの修正作業中で,数日でアップデートされるとのこと。


2006年11月14日(火)

IRLPやEchoLinkなどと同じような,しかしちょっと風変わりな,VoIPとアマチュア無線の融合システムがある。AllStar Linkと呼ばれている。技術的には,オープンソースのソフトウェアPBXであるAsteriskをベースに,その上にアマチュア無線の仕組みapp_rptを構築している。すなわち,インターネット上にプライベートなIP電話網を構築し,その末端インターフェースをアマチュア無線にしてしまおうというものである。OSはLinux,無線機用ハードウェアインターフェースが必要。他のVoIPアマチュア無線が中央サーバー形式を採っている一方,こちらはピア・トゥ・ピアのようである。同じ仕組みの,しかし別のネットワークをいくつでも作ることができる(WiRESネットワークが複数できるようなもの)。AllStar LinkはそういったAsterisk+app_rptで可能なネットワークの一つの実現例であるようだ。AllStarは,すべてアスタリスクノードでできていることから,そう名付けられたらしい。

ベースのアスタリスクでは様々なコーデックや,制御プロトコル(H323やSIPなど)が利用できるようだが(Asterisk Features),app_rptではコーデックはGSM,制御プロトコルはIAX2(Inter-Asterisk eXchange 2)を利用している。

PBXシステムがベースなので,フォーンパッチなどは大変簡単にできそうである。専用ハードウェアインターフェースがちょっと高価そうなのですぐには手を出せないが,これから調査してみようと思う。


2006年11月3日(金)

IRLPでは音声コーデックとしてADPCM(32Kbps)とGSM(17Kbps)を選択することができた。デフォルトでは,IRLP同士でADPCM,EchoIRLPでEchoLinkノードとの間ではGSMが選択される。今週Dave Cameronにより,これらにUNCOMPモードが追加された。このモードでは64Kbps,すなわち今までのADPCMの倍の帯域で音声データがやりとりされる。よって音質向上および遅延低減という効果が期待できる。ノードの自動アップデートをONにしていれば,すでにUNCOMPをサポートできるようにノード内いくつかのファイルが置き換わっているはずである。自動アップデートをしていない場合には,update files をコマンド実行すれば良い。

デフォルトのコーデックをUNCOMPにするには:

  1. root権限で $CUSTOM/environment を開く。
  2. export DEFAULTCODEC=ADPCM を export DEFAULTCODEC=UNCOMP に変更し,ファイルを閉じる。
  3. $CUSTOM/rc.irlp でirlp関連プロセスを再起動。

接続中,使用されているコーデックは $HOME/local/codec ファイルの中に記述されている。


2006年9月12日(火)

ちょっと古い2003年QST誌2月号のようであるが,ARRLによるVoIPに関する紹介記事(ARRL Article on VOIP with definitions)のPDF版がYahoo Group IRLPにアップロードされた。IRLP, EchoLink, eQSOのみならず,WiRESや(今はもうない)iLinkも紹介されている。それぞれの簡単な紹介の他に,VoIPが米国において合法であることの根拠,そして最後に,「それってアマチュア無線なの?」という問いで締めくくっている。これは今後いつまでも問われる質問かも知れない。IRLPerの一人としては,自分なりの答を用意しておこうと思う。


2006年9月10日(日)

前述のように,他ノードやリフレクター接続時にはタイムアウトが存在し,その時間は変更はできる。特にユーザー利用の多いノードや,リピーター接続ノードにおいては,これらのタイムアウト時間は必要と思われる。一方,普段はタイムアウトを設定しておきながらも,ある特定の接続については無制限にしたい場合もあると思う(イベントの場合など)。そのような時には,以下のように notimeout オプションを設定することで,その接続のみ無制限にすることができる。

$SCRIPT/call stnnnnn notimeout
$SCRIPT/connect_to_reflector refnnnn notimeout

ここで,nnnnはノード番号

notimeout用にあるDTMFプリフィックスを割当て,custom_decode からこれらを呼ぶことでDTMFから選択可能である。すなわち,普通に nnnn とDTMFを打てば,タイムアウトありでnnnnに接続し,Annnnと打てば時間無制限で接続となる(プリフィックスを'A'とした場合)ような制御が可能。ただし,EchoIRLPでEcholinkに対しては効果はない。


2006年8月22日(火)

tbd0.83では"Unable to enable core dumps"ウォーニングが直るとのことだったが,昨日7M3TJZ局よりメールをいただき,tbdcmd.cに対してもパッチを当てなければならない旨とその方法をご教示いただいた。さっそくパッチを当てたところ見事にこのウォーニングが消えた。具体的方法は7M3TJZ局がEchoIRLP MLに投稿されているので,そちらを参照していただきたい。無害とは言え,結構うるさいウォーニングが消えることで,画面上も,気持ち的にも大変すっきりした。


2006年8月8日(火)

tbdが0.83にバージョンアップされたらしい。さっそく0.81のときと全く同じ方法でバージョンアップをする。今回はソースをいじらずに,まったくそのままでコンパイルができた。しかし,このバージョンアップで"Unable to enable core dumps" という有名な(しかし無害の)ウォーニングが直るとのことだったが,いまだに発生してしまう。

ここのところIRLP JA局が集まっていたリフレクター 9004 だが,この数日ダウンしている。オーナーに連絡したところ,サーバーが遠隔地にあり,実際に管理している担当者が休みに入っているとのこと。回復にはもう少しかかるかも知れない。


2006年7月9日(土)

Dave Cameron より,IRLP Embedded Computer が発表された。Mini-ITXベース,HDDなし(代わりにFlashドライブを使用),OSはslackware10.2とのこと。IRLP,EchoIRLP,その他一般的なRemote Adminなどスクリプトがプレインストールされているらしい。山頂のレピーターなど,無人遠隔地での運用を想定して開発されたようだ。

Yahoo Group: irlp-embedded もオープンされた。


2006年7月2日(日)

今朝は早起きして,リフレクター#9356でのスペースシャトルNASA音声フィードを聞いていた。残念ながら20マイル先に雷雲が留まっているということで,ローンチは明日へ延期されたが,その延期決定の場を生で聞けたというのも臨場感があってよかった。NASAからの音声の中で,"T-9 holding" という言葉が繰り返し使われたので調べてみた。Space Shuttle Launch Sequence によると打ち上げ9分前の最終判断のためのカウントダウン停止点らしい。

打ち上げ時間には,リフレクター#9356には70ノード以上がコネクトしていた。


2006年06月23日(金)

EchoIRLPで使用されているthebridge(tbd)を現在のバージョン0.77から0.81にアップデートした(thebridge-0.81 release note)。tbdはソースコードしか公開されていないので,ビルドが必要。その手順は以下のとおり:

  1. root権限で,service tbd stop を実行しtbdサービス(デーモン)を止める。以下root権限。
  2. SourceForge.net より,thebridge-0.81パッケージ(thebridge-0.81.tgz)をダウンロード。/rootなどに置く。
  3. tar -xzvf thebridge-0.81.tgz で解凍。
  4. cd thebridge-0.81
  5. EchoIRLPメーリングリストにおいてJK1ZRW(7M3TJZ)局が提示している修正を src/conference.c に加える。(これをしないとコンパイル時にエラーが起きる)
  6. ./configure
  7. make
  8. make install
  9. make clean
  10. cp /usr/local/libexec/tbd /home/EchoIRLP/tbd (シンボリックリンクでも良い)(注)
    あるいは
    mv /usr/local/libexec/tbd /home/EchoIRLP/tbd
    ln -s /home/EchoIRLP/tbd/tbd /usr/local/libexec/tbd
  11. cp /usr/local/bin/tbdcmd /home/EchoIRLP/tbd (シンボリックリンクでも良い)(注)
    あるいは
    mv /usr/local/bin/tbdcmd /home/EchoIRLP/tbd
    ln -s /home/EchoIRLP/tbd/tbdcmd /usr/local/bin/tbdcmd
  12. /home/irlp/custom/rc.irlp を実行する。tbdが正しくスタートするかを確認。
  13. 接続テストがOKなら,ここで3.で解凍時にできたディレクトリ(thebridge-0.81)は消去して良い。
(注)/usr/local/libexec/tbdから/home/EchoIRLP/tbd/tbdへのシンボリックリンクではなく,逆に実体を/home/EchoIRLP/tbdにおいた方が良い。echo-installスクリプトでは,後者のように一度 /home/EchoIRLP/tbd に mv してから,/usr/local/libexec/tbdにシンボリックリンクを張るような処理をしている。 tbdcmdも同様。

以上は,すでにEchoIRLPがインストールされている状態でのtbdバージョンアップ方法である。新規のFC5 for IRLPで,EchoIRLP(tbd 0.81)を新規にインストールする場合には,EchoIRLP Yahoo Groupから入手する echo-install スクリプトに手を加えることと,上記5.のソースコードへの修正が必要だろう。


2006年06月22日(木)

IRLPノード構築においては,IRLPボードの装着,無線機との配線,OS,IRLPソフトウェアのインストールといった作業を行わなければならないが,これらのインストール作業の後にもいくつかすべきことが待っている。オフィシャルページでは,"What do you do after the install?"というマニュアルとして公開されている。その中でも特に以下の項目は大変重要。これらの設定を忘れてはいけない。

2005年9月29日の記述を参照)

"What do you do after the install?"を翻訳したので,一度目を通してみて欲しい。


2006年06月19日(月)

米時間7月1日にスペースシャトル Discovery のローンチがあるようだ。NASAからのオーディオがIRLP(WALA Reflector #9356)およびEchoLink(*ORLANDO* conference server)で配信される予定。

STS-121 Discovery/ 18th International Space Station Flight
Launch Pad: 39B
Launch Date: July 1, 2006
Launch Time: 3:48 p.m. EDT
Landing: July 13, 2006
Duration: 12 days
Orbital Insertion Altitude: 122 nautical miles
Orbit Inclination: 51.60°
Countdown begins: T-43 hours

3:48pm EDT は,日本時間で言うと7月2日午前4:48。日曜だし,早起きが得意な方は試してみてはいかがだろうか。


2006年06月18日(日)

IRLPは,ノードのIPアドレスがグローバルであれば,それが動的IPアドレスでも動作する。これは,各ノードがcronによって15分毎に自分のIPアドレスをチェックし,変更があればそれをIRLPサーバーに通知しているからである。IRLPサーバーは各ノードのIPアドレスを一括管理していると同時に,IPアドレスリスト($HOME/local/hostsファイル)の各ノードへの配信,インターネット上でのip.irlp.netゾーンファイルの管理を行っている(注)。よって,あまり頻繁にノードのIPアドレスが変わるようだと,これらの動作も頻繁に行われ負荷が増大する。また,各ノードへのアドレスリスト配信とのタイミングにより,そのノードと接続できないという可能性もあるので,注意が必要。自ノードのIPアドレスが変わったかどうかは,$HOME/log/messages内の "ipupdate:" で始まるエントリーを探せばわかる。

(注)各ノードはインターネット上で,stnxxxx.ip.irlp.net (xxxxはノード番号)で名前解決ができる。

特にインターネットアクセス環境としてPPPoEを利用している場合は,できれば自ノードのIPアドレスが頻繁に変わらないような工夫をしておくと良い。例えば,ルーターのTimeoutを長くする,keep aliveを設定する,定期的にIP通信を行うような(pingなど)自動プログラムを流しておく,などが考えられる。


2006年06月15日(木)

IRLP MLにおいて設計者VE7LTDより,オーディオファイルに関する若干の設計変更予定が発表された。IRLPでは,相手ノードあるいはリフレクターに接続/切断した際,接続局側には被接続局が作成したアナウンスが流れる。これは各局が自由に作成できる.wavファイルで,サーバーに登録しておくと,接続局に(そのファイルがなければ)ダウンロードされ,その局で再生される仕組みになっている。

一方,.wavファイルを置くディレクトリ($HOME/audio)が大きくなる,接続のたびに同期を取る,サーバーへ登録しなければならない,などの欠点もある。よって今後は,接続/切断時のメッセージは被接続局からネットワーク経由で流れてくるように設計変更しているらしい。これは,現在より小さなシステム(HDDではなくフラッシュディスクを利用したターンキー型ワンボックスIRLP)を作るアイデアもあるようで,それに向けたステップでもあろう。

ここで,現在のオーディオファイルの作成方法についてまとめておく。

本件に限らず,IRLPの機能に関しては,各局が様々な意見,要望,提案をML上で行っている。新しい機能の仕様が最終的に決まるまで,このような議論が続くのであろう。このようにオープンに,皆が参加できるプロセスは大変アマチュア的ですばらしいと思う。


2006年06月12日(月)

デバイスファイルのパーミッションだが,FC4より/etc/udev/permissions.d/50-udev.permissionsではなく,/etc/security/console.perms.d/50-default.perms というファイルで設定するようになったらしい。よって,クリーンなFC4以降のシステムでは50-udev.permissionsは存在しない。当局のシステムはFC3からのアップグレードであったため,このファイルが残っていたようだ。本問題の解決には /etc/security/console.perms.d/50-default.perms ファイルの中の:

<console> 0600 <sound> 0600 root

というエントリーを以下のように書き換える:

<console> 0600 <sound> 0660 root.sys

リブートで,本来欲しい属性(0660/root.sys)に変更された。リブート時鳴らなかった "IRLP node enabled"のアナウンスも流れるようになった。したがって,問題回避のため記述していた rc.irlpファイル内のchmod/chgrpコマンドの羅列はすべて不要となった。とりあえず一件落着。


2006年06月11日(日)

最近,IRLPノードの再インストールについてお問い合わせをいただいたので,その概略を書く。

まず,IRLPの再インストールには,$HOME/scripts/backup_for_reinstall スクリプトを実行することで作成されたバックアップファイル($HOME/backup/irlp_backup.tgz)が必要。すなわち,日頃からこのスクリプトでバックアップをとり,irlp_backup.tgzを別のメディアやPCにコピーしておくこと。これは重要。また,/rootディレクトリーに get-irlp-files スクリプトがある場合には,これもバックアップファイルと共にコピーしておくと良い。再インストールの時には,これを実行し,2) Re-install from backup を選択すれば良い。

IRLP再インストールは,上記のようにget-irlp-filesがあればそれを実行する。無い場合には, オフィシャルサーバーより irlp_reinstall スクリプトをダウンロードし,実行する(詳細は IRLP_Upgrade_to_FC3 内の記述を参照のこと)。

EchoIRLPがある場合には,IRLP再インストール終了後,新規インストールと同様の手順を踏む。

もし,万が一バックアップが無い状況でIRLPを再インストールしなければならない場合は,FC3/5 for IRLPのインストールおよびネットワーク構成を行った上で,それ以上は何もせず, installs@irlp.net に再インストールを依頼する。その際,インストールチームが遠隔ログインして作業する場合もあるので,sshがrootでログインできることを確認しておく。(遠隔ログインで作業する必要がある場合には,先方からIPアドレス,sshポート番号,rootパスワードを尋ねられる。)


2006年06月10日(土)

その後,/usr/bin/play コマンドで,エラーが発生することがわかった。昨日の3つのデバイスファイルだけではなく,さらに /dev/sequencer, /dev/snd/*, /dev/adsp も同様にパーミッションおよびgrpを変更することで修正。よって,少々みっともないが,私の $CUSTOM/rc.irlp には以下が追加されている。本質的な解決(注)をしたい。

chmod 660 /dev/audio
chmod 660 /dev/dsp
chmod 660 /dev/mixer
chmod 660 /dev/sequencer
chmod 660 /dev/snd/*
chmod 660 /dev/adsp
chgrp sys /dev/audio
chgrp sys /dev/dsp
chgrp sys /dev/mixer
chgrp sys /dev/sequencer
chgrp sys /dev/snd/*
chgrp sys /dev/adsp

(注)その後本質的解決が判明した。

2006年06月09日(金)

FC5へのアップグレードをやってみた(新規インストールではなくFC3の上へのアップグレード)。はまった結果,丸一日かかってしまった。

オフィシャルページ内のISOイメージから焼いたCDで,現行PCをブート。いくつかメニューが表示されるうち,Upgrade を選択する。そのままOSのアップグレードは問題なく進み,15分くらいで終了。

さて,リブートするがIRLPが起動しない。原因を見てみるとオーディオ関係のデバイスファイルの属性が変わってしまっている。少なくとも /dev/audio, /dev/dsp, /dev/mixer の3つのファイルは,それぞれ

crw-rw---- 1 root sys 14, 4 Jun 9 17:59 /dev/audio
crw-rw---- 1 root sys 14, 3 Jun 9 17:59 /dev/dsp
crw-rw---- 1 root sys 14, 0 Jun 9 17:59 /dev/mixer

でなくてはならない。しかし,FC5アップグレード後はそれぞれ 600/root.root になってしまっていた。これらの属性は,/etc/udev/permissions.d/50-udev.permissions ファイル内で指定されているので,このファイルを変更すれば直るはずなのだが,それを変えても直らない。原因不明なので,仕方なく $HOME/custom/rc.irlp 内で chmod, chown コマンドでOSリブートの度に変更することでごまかした。どうして50-udev.permissionsファイルの変更で直らないのだろうか。

本質的解決ではないが,なんとかIRLPは再開できた。(但し,ブート時の"IRLP node enabled"のアナウンスが,rc.irlpの前に実行されるらしく,鳴らなくなった。)

次は,EchoIRLPだが,これは何もせず動いた。再コンパイルが必要かと思っていたが,その必要はなかった。

次の問題は,httpd (注1)が動かないこと。これではリモート管理コンソールが動かないのと,それよりも何よりもこのホームページが動かなくなってしまった。/sbin/service httpd start とやると,libssl.so.4/libcrypto.so.4 がないと言って起動失敗する。さらに調べてみると httpd 本体ではなく,php の一つのコンポーネントが,これら2つのシェアードライブラリーを使っているようだ。依存関係がずれているのだろうか。他のコンポーネントは,OpenSSLとして libssl.so.6/libcrypto.so.6を使っており,それらはそれぞれ/lib/libssl.so.0.9.8a, /lib/libcrypto.so.0.9.8a からのシンボリックリンクとして存在している。これ以上考えてもわからないので,えぃやで,これらのファイルから libssl.so.4/libcrypto.so.4 にシンボリックリンクを張ってみる(すなわち libssl.so.4 = libssl.so.6, libcrypto.so.4 = libcrypto.6にしてしまう)。これで何とか動き出した。

(注1)httpd/phpは,FC3/5 for IRLP には含まれていない。アドオンの遠隔コンソールをインストールすることで導入される。

最後の問題は,samba(注2)が動かないこと。これも何かのライブラリーが無いというメッセージだったが,yum update sambaをすることで動き出した。バージョンの整合性の問題だったのであろう。

(注2)sambaは,FC3/5 for IRLPには含まれていない。当局が別途インストールした。

以上なんとか復活したが,アップグレードどころか逆にノードPCを汚してしまったような気がする。特に,デバイスファイルのパーミッションの件と,libssl.so.6 の件は,どなたか正しい解決方法をご存知であれば,ぜひご教示いただきたい。

今回は既存FC3の上にFC5アップグレードをかけたためいくつか問題が生じたが,FC5の新規インストール+IRLP再インストールであれば,多分1時間もかからずに,かつきれいにできると思う。


2006年05月20日(土)

VE7LTD/David Cameron より配布されるFedoraCore for IRLPが正式にFC5になったようだ。JF9LGL局によると,IRLPボード購入時についてくるCDもすでにFC5とのこと。IRLPオフィシャルページにも,FC5インストール用ドキュメントと,CDのisoイメージがアップロードされたので,早速CDを焼いてみた。このCDでブートしてみると,New Installの他に,Upgradeオプションもある。近々,アップグレードに挑戦してみようと思う。


2006年05月13日(土)

EchoIRLPというのは,一体なんなのだろう。IRLPとEchoLinkとの間のゲートウェイなのだろうか。もう一度,使ってみた経験から学んだことを整理してみたい。

(概念図参照)

これらから言えることは,EchoIRLPは必ずしも異なるVoIPシステム間のゲートウェイとか,相互接続機能ということではなく,あくまでローカルユーザーがIRLPとEchoLinkの両方を(しかし,一時にはどちらか一つを)利用できるように利便性を高めたVoIPノードであるということであろう。このように考えれば,基本的には他VoIPとの相互接続を許していないIRLPにおいてEchoIRLPが存在している理由がわかる(注)

(注)もちろん,EchoLink側がライセンス認証を行っており,ゆえにアマチュア局のみが利用しているということが明らかであるということがその前提として存在すると思う。

2006年04月02日(日)

ブロードバンドによるインターネットアクセスの普及に伴って,宅内LANを構築されている局が大半だと思う。その場合,宅内PCのIPアドレス割当ては,ブロードバンドルーターをDHCPサーバーにした,動的IPアドレス割当てになっているだろう。

一方,VoIPアマチュア無線を利用する場合は,ルーターにポート転送をさせる関係で,VoIPソフトの入っているPCの宅内IPアドレスを固定させる必要がある。そのやり方には二通りある。

  1. 宅内の各PC側の設定において,IPアドレスの自動取得ではなく,手動による固定設定にする。
    最近のOSはDHCPがデフォルトになっているので,こちらを選択するなら変更が必要。また複数のPCがあるときには,それぞれにおいて設定を行う必要があるし,OSの種類が異なる場合,設定方法が異なるというデメリットがある。
  2. DHCPサーバー(ルーター)の設定において,各PC(MACアドレス)に割り当てるIPアドレスを固定する。
    ルーター一箇所で管理できるメリットはあるが,各PCのMACアドレスを知る必要がある。一方,PC側はさほどいじる必要がない(デフォルトのDHCP設定で良い)。

上記のような理由で,Windows/Linux混在環境である当局の場合には,2.を選択している。

1.の方法は,Windowsの場合には「ネットワークの設定」で簡単にできるが,Linux(Fedora Core3)でもさほど難しくはない。FC3での固定IPアドレスへの設定は以下のとおり。

  1. /etc/resolv.conf ファイル内に記述されている,nameserver のアドレスを確認。
  2. root で,netconfig コマンドを実行。キャラクターベースのGUIが実行される。
  3. Use dynamic IP configuration のところのチェックをはずし,その下の IP Address, Netmask, Default Gateway, Primary Nameserver のそれぞれを設定する。
  4. ifdown eth0
    ifup eth0
    コマンドをそれぞれ実行。

ifdownコマンドでネットワークが切断される。SSHで作業しているとコンソールに行かなければならないので,始めからコンソールで作業した方が良い。


2006年03月25日(土)

IRLPではFull Duplex運用が考慮された設計がなされている。しかし,その目的は電話やスカイプのような同時双方向会話を実現することではなく,IRLP接続のレピーター管理である。すなわち,レピーター送信中でもDTMFコマンドを受け付けられるようにすることを目的としている。例えば,IRLPリモートノードからの信号をレピーターが送信している時でも,そのIRLPレピーターを強制的に切断できる。また,天気予報やニュースなど,比較的長い内容の送信を途中で中断することができる。

Full Duplexにするには,IRLPボード上のジャンパー(PTT LCKOUT)をはずすだけで良い(注)

(注: このジャンパーをはずすことで,PTT On (送信中)でも,COSを検知できるようになる。旧Ver. 2ボードでは,唯一のダイオードをカットするだけで良いようだ。

元々,リンクの両端が無線によるHalf Duplex交信を前提としているIRLPでは,シンプレックス運用しているのであれば,実験目的以外にあえてFull Duplexにする必要はない。


2006年03月23日(木)

IRLPのDTMFデコーダーは,ハードウェアデコードなのでWiRESと同様にそのデコード能力は充分。送信側のトーン送信速度や長さの違いに柔軟に対応できる。

一点注意すべきは,"D"のみデコードできないこと。これは,IRLPがPCとのインターフェースにパラレルポートを使用していることから来る制限である。 (bi-directionalではない)標準パラレルポートではPCへの入力は5ライン(ビット)のみである。その内1ビットはCOSに割当てられているので,残り4ビット。一方,表現したい状態は,アイドル状態と0〜9,#,*,A,B,C,Dの16文字の計17状態で,4ビットでは足りない。

パラレルポートをbi-directionalに構成すれば8ビットのデータラインも入力として利用できるが,ユーザーにポート再構成させることによる混乱と,"D"デコードをあきらめることによる不便さの両方を考慮した上で,現在は後者を選択している(注)。実際には"D"がデコードできないことによる不便はほとんど無い。

VE7LTD/D. Cameron も,将来のIRLPボードでの"D"デコードについて言及しているので,この問題は近いうちに解決すると思われる。

一方,DTMF regeneration における"D"エンコードは問題なくできる。

(注) よって,IRLPノードPCのパラレル(プリンター)ポートは,BIOS設定においてbi-directionalではなく,「標準」モードにセットしておかなければならない。

2006年03月22日(水)

以前のIRLPリフレクターは,1チャネルしかなかったそうだ。それでは,せっかくのネットワークやPCの能力を生かしきれないということで,2002年に登場したのが super-reflector と呼ばれる現在のリフレクターの形である。リフレクター用PC1台につき,1IPアドレスで,ポートを送受10組,計20個使っている。これで各リフレクターにつき10チャネル可能となった。

各リフレクターには一般ノード局と同様に4桁のリフレクター番号が割当てられている(最上位桁は9)。その最下位桁はチャネル番号であり,チャネル0がそのリフレクターのメインチャネルである。すなわち,Crossroads Reflector のリフレクター番号は9200であると同時に,9200はそのメインチャネルでもある。そして,9201-9209がそれぞれサブチャネル1〜9となる。チャネルにアクセスするには,単にその番号をアクセスノードに対してDTMFで送出すればよい。例えば,Crossroads Reflectorの日本語サブチャネル9202にコネクトするには,DTMF 9202を送出すればよい(注)

(注)海外の会員制をとっているノードでは,事前アクセスコードや,プレフィックスを設定している場合もあるらしいが,日本のノードではそういうことは無いと思われる。

それぞれのリフレクターで,サブチャネルの用途が決まっているので,アクセスする前にはそのリフレクターのガイドライン(上記Crossroads Reflector の例)に目を通しておくと良い。また,多くの場合,サブチャネル8と9はGSM音声コーデック用になっており,(低速アクセスの)ダイアルアップノード用,同じGSMであるEchoLinkゲートウェイ用,あるいは緊急アクセス用などとして使われている(Western Reflectorの例)。


2006年03月18日(土)

Fedora Core 5のリリースを控え(本日現在3月20日予定),FC3がlegacy projectに移行されメンテナンスモードに入った。よって,FC3 for IRLPに対する標準yum updateも働かなくなるため,以下を行うことが推奨されている:

(as root)

rpm -Uvh http://download.fedoralegacy.org/fedora/3/legacy-utils/i386/legacy-yumconf-3-4.fc3.noarch.rpm
yum update
shutdown -r now

ただし,上記のアップデートによって,大半のノード(注)はサウンドデバイスのパーミッションが変更され,オーディオが動作しなくなるらしい。その場合,以下を行う:

(as root)

cd /etc/udev/permissions.d
mv 50-udev.permissions.rpmsave 50-udev.permissions
shutdown -r now
(注)以前,オーディオ関連の別問題があった際,その問題解決のために rc.irlp ファイルを変更している一部のノードは,それが効いているためサウンドデバイスパーミッションの変更は不要のようだ。しかし,当局を含む日本の多くのノードはそれには当てはまらず,上記パーミッション変更の手続きが必要となると思われる。

2006年03月14日(火)

VE7LTD/David Cameronは現在FC5 for IRLPの作業を行っているようだ。4月21日,22日にラスベガスでIRLPコンファレンスが開催されるが,それに前後してリリースが予定されている。


2006年02月28日(火)

IRLPリフレクターは現在#9000から飛び石で19個存在しており,それぞれが0〜9のサブチャネルを持っている。よって190のルームやコンファレンスに相当する場があり,それぞれに目的や用途がある。さらに,それぞれの使い方のガイドラインも設定されている(StatusページのReflector Summaryからリンクされている)。

その中から,9010 Discovery Reflector を紹介したい。このリフレクターは,ARISSスクールコンタクトで知られるスペースシャトルのミッション時に,宇宙飛行士と世界中の子供達の間のアマチュア無線を通じた交信を中継しているリフレクターである。スケジュールに合わせてワッチするなら,チャネル0(#9010)ではスクールコンタクトが,またチャネル7(#9017)では,スペースシャトルミッション交信がライブで聞けるようだ。

またこのホームページのAudio Library では,スクールコンタクトの交信録音が聞ける。カナダの幼稚園児の「スペースステーションではどんな本を読んでいるんですか」とか,小学1年生の「スペースステーションではどうやって着替えるのですか」という質問はとてもかわいいし,中学生の「無重力は人の骨にどのような影響がありますか」という質問などに,きちんと応える宇宙飛行士の応答は聞いていて気持ちが良い。「スペースステーションで病気になったらどうするのですか」・・・どうするのか録音を聞いてみよう。


2006年02月19日(日)

EchoIRLPのオペレーティングモードについて。

EchoIRLPには新旧2種類のオペレーティングモードがある。

  1. Shared Conference Mode (共有コンファレンスモード)
    結論からいうと,このモードは現在ほとんど使われていない。このモードはIRLP,EchoLink共通の場(コンファレンス)を設けて,そこでお互い話をしよう,というもの。場はEchoLinkが提供する。IRLPノード側からは,自ノードのecho_confファイルにリストされているEchoLinkコンファレンスにのみ接続できる。echo_confファイルには,IRLPから接続可能なコンファレンスの名前,IPアドレス,ノード番号,接続パスワードが定義されている。一方,これらのコンファレンスではIRLPからの接続を想定した設定がなされている。EchoLink側から当該IRLPノードには接続できない。IRLP側から,EchoLink側ノードのIPアドレス解決方法としては,自ノードにインストールされており適宜自動アップデートされるecho_hostsファイルを参照する方法,あるいは動的にEchoLinkサーバーへの問い合わせする,という二つの方法も提供されている。EchoLink側のIPアドレスが解決できれば,IRLPソフトが直接,コンファレンス側のゲートウェイポートにアクセスする。
  2. tbd Mode (tbdモード)
    現在はこのモードが大半である。すなわち,IRLPノード内ローカルにTheBridge(tbd)をデーモンとして常駐させ,これを経由してEchoLinkに接続する。すなわち,IRLPノード内にEchoLink機能を入れてしまおうという考え。EchoLinkからは完全にEchoLinkノードに見える。IRLPソフトからは,tbdcmdというtbd管理ツールを使ってtbdに対しconnect,disconnectを始めとしたコマンドを発行する。一方,tbdの発生するイベントは,echoirlp-statusというスクリプトがキャッチし,さらにイベントの種類に応じてそれぞれのハンドラーを呼び出す。

    Shared Conference Modeとの違いは,
    1. EchoLink側ノードのIPアドレス解決は,tbdが5分おきに作成する host ファイルを利用する。
    2. 接続は,IRLP<->tbd<->EchoLinkという2段階接続となる。
    3. EchoLinkコンファレンスだけではなく,すべてのEchoLinkノードにアクセス可能。(アクセス先が拒否していなければ)
    4. EchoLinkとして(-L)あるいは(-R)のノード登録が必要。

IRLP側の音声コーデックは両システムで互換性のあるGSMが選択され,途中D-A変換が入るようなことは無い。


2006年02月12日(日)

以前書いたように,IRLP Version 3 のボードには,外部コントロール端子 AUX1〜3があり,DTMFや遠隔管理コンソールから簡単にON/OFFができる。IRLPメーリングリストで紹介された実際の利用例。

応用例はまだまだ,他にもありそうだ。


2006年02月11日(土)

IRLPには,ノードの設定をチェックする問題発見用スクリプトが用意されている。$SCRIPT/troubleshoot-irlpがそれで,これを repeater で実行すると以下をチェックする:

#1 DNSサーバーテスト hostコマンドで,irlp.netのIPアドレスを正しくlookupできるかをチェック。
#2~3 ポート転送テスト 必要なTCP/UDPのポートをチェック。
#4 ホスト名解決テスト hostnameコマンドで返ってくるホスト名にpingし,このホスト名が解決できるか,そしてpingできるかをチェック。
#5~8 PGPキーテスト 正しい自ノード認証用公開PGPキーが存在するかをチェック。
#9 日付(date)テスト システム日付チェック。PGPキー生成日より,ノードのシステム時計の日付が古いとノードは正しく動作しない。
#10 Environmentファイルテスト $CUSTOM/environmentファイルが壊れていないかをチェック。
#11 /tmpディレクトリー書込みテスト /tmpディレクトリーが書き込み可かをチェック。
#12 custom_decodeファイルテスト $CUSTOM/custom_decodeファイルが,正しく実行可能かをチェック。

これはノード設定の際,陥りやすいエラーを確認するためのものだろう。よって,すべての機能をチェックする訳ではない。また,何かしらエラーが見つかった場合でも,このスクリプト自身が解決方法までを提示してくれる訳ではない。エラーの場合は,単にドキュメントを見ろと言ってくるだけである。

troubleshoot-irlpスクリプトは,実行前にノードを disable にする。実行終了後 enable に戻すが,何らかの理由で(例えば,途中でctrl-cで止めた場合など)スクリプトが最後まで実行されないと disable のままになるので注意。ノードをenableにするには,$SCRIPT/enableを実行する。

最近,自ノードが一見正しく動作しているにもかかわらず, IRLP status pageにおいて "Down"と表示されるケースがあるらしい。メーリングリストにも原因と対策が流れたが,これはそのノードのDNS設定がうまく行っていない場合に起きる。その場合,上記 troubleshoot-irlp のテスト#1でエラーが出ると思う。解決策は,/etc/resolv.conf ファイル内に,正しいネームサーバーのアドレスを記述すること。自宅ルーター経由の場合にはそのルーターがネームサーバーになっている場合が多いので,その場合にはルーターのアドレス,あるいは自分のプロバイダーから指定されているアドレス,あるいはまた公開ネームサーバーのアドレスを記述しておく。


2006年01月31日(火)

IRLPのタイムアウト・タイマーについて。

IRLPには種々のタイマーが存在するが,運用上認識しておくと良いタイマーは以下のとおり:

  1. 4分COSタイマー
    IRLPノードは,ローカルユーザーから4分以上連続してCOS ON(RF受信)を検知した場合,リンクを切断する。ログには"Node Disconnect coslock from xxxx" と表示される。
  2. 5分PTTタイマー
    IRLPノードは,5分以上連続してPTT ON(RF送信)した場合,リンクを切断する。ログには"Node Disconnect pttlock from xxxx"と表示されるとともに,pttlockエラーのアナウンスが流れる。
  3. リフレクター接続時間制限タイマー
    リフレクターへの連続接続時間を制限する。$HOME/custom/environmentファイル内のREFLECT_TIMEOUT_VALUEに秒で設定する。デフォルトは1200(=20分)。0 (ゼロ)にすると無制限。
  4. ダイレクト接続時間制限タイマー
    Node-to-Nodeでの連続接続時間を制限する。$HOME/custom/timeoutvalueファイル内の数字(秒)を変更。デフォルトでは1200(=20分)。上のREFLECT_TIMEOUT_VALUEとは異なり無制限にはできない。0(ゼロ)を指定すると0秒でdisconnectになる。よって何かしら有限値を指定する。

1.および2.は,誤動作やいたずらによるリフレクターや他ノードの占有防止,ノード無線機の過剰送信を抑えるためのタイマーであり,IRLP同士の場合には通常4分COSタイマーが先に働きリンクは切断される。これらのタイムアウト値は,全てのIRLPノードが同じ値を持つべきで,IRLPシステム内でハードコードされており変更は不可能。さらにノードオーナーとしては,これらのソフトウェアタイマーだけに頼らず,ノード無線機のTOTもできる限り設定すべきであろう。その場合は5分が適切であろう。

1.〜4.のタイマーのいずれかが働くと単に送信ができなくなるだけではなく,リンク自体が切断(disconnect)されることに注意。


2006年01月21日(土)

自局のEchoIRLPから他EchoLink局にコネクトできない場合があるが,それは相手局がリンク局(-L)からのコネクトを許可していないからかもしれない。自分のEchoLink Windows クライアントにおいて(-L)を許可しないようなセキュリティー設定にしコネクトすると,全く同じエラーメッセージが流れた。


2006年01月18日(水)

IRLPノード遠隔管理コンソールのインストールに伴い,このLinux PCにはApache Webサーバーが導入されている。これを有効活用して,今まで外部無料Webサーバーに構築していた当ホームページもこちらの自宅サーバーで運用することにした。広告がなくなったので少しすっきりしたと思う。

IRLPオフィシャルページにある,IRLP FAQ Page を翻訳,掲載した。オフィシャルページからもこちらにリンクされた。


2006年01月14日(土)

今までIRLPノード用LinuxPCには,別のWindows PCよりSSHでログインしていた。公開鍵暗号を利用したセキュアな通信であると思っていたが,何とSSHの設定を正しく行っておらず,単なるID/パスワード認証になっていることに気がついた。暗号系を正しく使えば,本来ログイン時にIDとパスワードを入力する必要はないのである。Linux側の /etc/ssh/sshd_conf という設定ファイルにおいて以下を設定しなければいけなかった。

PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication no

さらに,rootでのログインを避けるために以下を設定した。

PermitRootLogin no

もうひとつ陥りやすい部分は ssh 関連のファイルパーミッション。特に$HOME/.sshと,その中の公開鍵ファイルは以下のようなパーミッションにしておかないとログインできない。

drwx------ 2 repeater repeater 4096 Oct 8 13:04 .ssh
-rw------- 1 repeater repeater 225 Oct 8 09:24 authorized_keys

ただSSHを使えば安全,という訳ではなかったようだ。

上記のように設定することで,秘密鍵を持たない他からのアクセスはできなくなる。例えば,IRLPノードに問題が生じた時,IRLPサポートチームがリモートでログインしての問題解決を申し出ることがあるが,その場合にはこの設定をはずし,rootのpassword authenticationによるアクセスを許可するような設定に戻す必要がある。

さて,ずいぶんと昔に使っていたUNIXのシェルがkshだった。Linuxには無いのかと探していたら,それに近い pdksh (public domain ksh) というものがあるらしい。さっそく入れてみよう。インストールパッケージはhttp://web.cs.mun.ca/~michael/pdksh にある。pdksh-5.2.14.tar.gzをダウンロード,解凍。READMEにあるように,configure, make, make installコマンドをそれぞれ順番に実行していく。実行ファイルは/usr/local/bin/ksh としてインストールされるので,最後に /etc/shells にそのパスを追加。ログインシェルを変更するにはどうするのだったろうか。明日の宿題。

ところで,EchoIRLPだが,コンファレンスやユーザー局の多くには問題なく接続できるのだが,リンク局(-L)の半数くらいには Timeout でつながらなかった。もちろん,EchoLink Windows クライアントからは問題なくつながるので,EchoIRLPの問題だと思われる。なぜリンク局での接続失敗が多いのだろう。


2006年01月13日(金)

定期ID送出スクリプトを変更した。毎時00,20,40分の20分毎にIDを出すようにした。最近はLinuxエキスパートの方にもこの日記をご覧いただいているようなので,このようなプログラムを掲載するのは全く恥ずかしい限りだが,たったこれだけのシェルを書くにも時間がかかる。Linux標準らしいbashというシェルは,以前UNIXで使っていたbshやkshとは異なるようだ。しかし,少しずつIRLP式シェルプログラミング法がわかってきた。使える環境変数や,ノード状況の判断方法,シェル冒頭に入れるべき「おまじない」,keyup/unkeyの仕方,WAVファイルの送信の仕方など。


2005年12月28日(水)

今日ふと見たらIRLPオフィシャルホームページのIRLP Operating Guidelineのところに,"In Japanese"として,ここのガイドライン翻訳ページにリンクが張られていた。原文オーナーに翻訳完成を報告したので,そのようにしてくれたのであろう。責任重大だ。


2005年12月24日(土)

昨日のEchoIRLP導入後,EchoLink2局と交信していただいた。何とか使えるようだ。

資料を読んだだけでは分からないものも,実際にやってみると色々見えてくる。EchoIRLPは,単純にIRLPとEchoLinkを「音声ミックス」レベルで接続している訳ではないようだ。EchoLinkのコンファレンス構築で使用される TheBridge (tbd) をIRLPノードにローカルに導入し,それを経由してEchoLinkと接続している。緩衝になっていると思われるので,今後その役割等を理解していきたい。

また,EchoIRLPの資料には,すべてのEchoLinkノードと接続できる訳ではなく,あらかじめ認証設定をおこなったコンファレンス,EchoLink局とのみ接続できる旨の記述があった。しかし,昨日からの当局での実験では,特に制限なく多くのEchoLinkノードには接続できているようだ。どうしてだろう。一方,WX_TALKというEchoLinkコンファレンスに接続した際,EchoIRLPからの接続は許可していない旨のアナウンスが流れた。こちらがEchoIRLPだとわかった上で判断しているようだ。どうやっているのだろう。


2005年12月23日(金)

IRLPソフトウェアは基本的に,IRLP操作用ユーザーであるrepeaterの$HOMEディレクトリー(/home/irlp)以下にインストールされる。PCクラッシュなどの万が一の場合に備えてバックアップ用のスクリプトが用意されている。$SCRIPT/backup_for_reinstall というスクリプトを実行することで,$HOME以下のファイルを(一部wavファイル除き)tarアーカイブをかけて$HOME/backup/irlp_backup.tgzとして置いてくれる。その後,このtarボールを別メディアに置いておけばOK。

IRLPと他VoIPのリンクについては,まずはEchoLinkとの相互接続の仕組みとして実績あるEchoIRLPを経験してみたいと思う。EchoIRLPのインストールについて調査しているが,まずはその基本的な前提条件として:

前者はOKだが,残念ながらEchoLinkの運用経験はPCクライアントのみで,リンク局は立ち上げたことがない。まずはそれから始めなければならない。年末・年始の楽しみができた。

(参考:Interconnecting EchoLink and IRLP

---

午前中に上記を書いた後,昼過ぎよりEchoLink PCクライアントからリンク局設定とEchoIRLPのインストールを行った。前者は新たな認証に1時間ほどかかったが問題なくリンク局として登録完了。後者については,定番であるYahoo Groupの EchoIRLP Groupからインストールパッケージをダウンロードし,IRLPノードPCへインストールする。インストール自体は相変わらず簡単。インストールパッケージが実行ファイルなので,それを実行し,いくつかの質問に答える手順でインストールできる。質問のうちいくつかは悩んだが,基本的にデフォルト値のままで良いようだ。また,動作開始前にはルーターのEchoLinkポートを,今までのPCクライアントではなく,IRLPノードPCに向け直さなければならない。

また,インストール中プログラムのビルドが行われる。よって,ノードPC上には gcc を始めとした標準C開発環境が必要。しかし,当局は何もせずに問題なくビルドされたので,これらはFC3 for IRLPに始めから入っているか,あるいはインストールの途中で自動ダウンロードしたのだと思う(注1。FC3 for IRLPを使うなら気にする必要はないだろう。なお,EchoIRLPコンポーネントはrepeaterユーザーの$EchoIRLPディレクトリー(/home/EchoIRLP)にインストールされるとともに,$HOME下のIRLP側コンポーネントの多くも変更される(例:rc.irlp が変更されて,自動起動されるデーモンが追加される)(注2。よって,EchoIRLPインストール前にIRLPをバックアップしておくことは重要。

(注1)その後,EchoIRLPインストール時にC開発環境もインストールされるとの確認情報あり。
(注2) EchoIRLPのインストールによってIRLPコンポーネントが変更されてしまう。よって,今後IRLPサポートチームからの,オフィシャルなサポート(installs@irlp.netなどへの質問)は得られなくなる。しかし,大部分はYahoo Groupメーリングリストによって,世界中の仲間が手伝ってくれる。

EchoLink側から見た場合,JI1BQW-L (#84377) がEchoIRLP リンク局である。EchoLinkからここにコネクトすると,IRLP #8437 に接続される。EchoLink側からIRLPノードにDTMFコマンドを出すことはできない。

IRLP側からは,#nnnn (nnnnはEchoLinkノード番号)というDTMFコマンドでnnnnに接続できる。ディスコネクトは73。この接頭文字'#'は,当局で定義したもの。'#'で始まるDTMFコマンドはEchoLinkコマンドと見なすようにcustom_decodeファイルに定義している。ただし,EchoLinkの標準DTMFコマンドが全て使えるわけではない。また,接続先のEchoLinkノードに対してDTMFコマンドを出すこともできない。

EchoLink PCクライアントをSingle Userモードに戻し,かつProxy接続設定にして(注3,お互いにコネクト,ループバックを確認した。

(注3)グローバルIP一つの環境では,PCクライアントはProxy経由にしないと同じ宅内LANからは接続できない。なぜなら,すでにルーターのEchoLink用ポートがIRLPノードPCに向けられているため。

2005年12月19日(月)

YahooのIRLPメーリングリストにおいて,遠隔管理コンソールの話題が出ていたので,早速試してみる。あるFTPサイトからインストールパッケージをダウンロードし,それを実行すれば,そのままyumが実行され,必要な前提コンポーネントを全て自動ダウンロードした上でインストールしてくれる。実質作業時間20分。やっていることは,IRLPノードPCに対するApache Webサーバーのインストールと,IRLP用phpその他を自動で設定。(画面イメージ

この遠隔コンソールからノードに対し,以下の操作が可能:

万が一の場合は,職場からはsshでアクセスしようと思っていたが,これで十分。

i-modeからもできるかと思い試してみたら問題なく動いた。Good!  管理コンソールがi-modeでも動くということは,IRLPボードのAUX端子コントロールをi-modeでできるということ。工夫次第で,i-modeで日本中どこにいても家の中をコントロールできますね(アマチュア無線からは離れますが)。

管理コンソールのインストール方法はオフィシャルページにもアップロードされた。

インストール時にユーザーIDおよびパスワードの設定を求められる。後の変更は,スーパーユーザー権限で以下のコマンドで行う:

htpasswd /etc/htpasswd.irlp userid

もし,ユーザーIDを忘れてしまったら,/var/www/html/control/.htaccess ファイル内を確認する。


2005年12月17日(土)

定期ID送出スクリプトを少しアップデートし,運用を始めて見た。他IRLP局で多く使われているスクリプトもあるのだが,SoundBlasterカード用APIを利用しているため,他チップ使用の当局では使えない。他のスクリプトを参照しながら素人ながら作ってみたが,他に推奨できるまでには至っていないので,前回と同様にあくまで参考として見て欲しい。改善点などアドバイスいただければ幸いである。


2005年12月13日(火)

IRLPでも「どこでもWiRES」のような無線機無しでのアクセスメソッドが作れるのだろうと思っていた矢先に,同じようなトピックがIRLP MLに流れた。全体的コンセンサスがある訳ではなさそうだが(注),IRLPコミュニティーではPCからの直アクセスは否定的なようである。よく考えてみると,IRLPの略は Internet Radio Linking Project。すなわち無線同士をインターネットでリンクするもの,となっている。また,オフィシャルページを見ると,IRLPのサブタイトルとして,"IRLP - Keeping the Radio in Amateur Radio" とある。やはり "the Radio"=「無線」があることを前提にしたシステムのようだ。

これもIRLPの運用ポリシーに近いものなのだろう。他VoIPネットワークを接続する際には考慮すべき項目の一つになろう。

(注)その後数ヶ月MLを見ておりその論調からは,本件ほぼ全体的コンセンサスを得ていると言って良いと思う。

2005年12月05日(月)

timestampというスクリプトをYahoo Groupよりダウンロードした。様々なコマンドからの出力をパイプで喰わせてやると,それにタイムスタンプをつけて返してくれる。特に readinput コマンド(COS/PTT状況をモニターするコマンド)で下記のように使用すると重宝する。

[repeater@dell ~]$ readinput | $CUSTOM/timestamp
2005-12-05 22:24:44.630 Starting /home/irlp/custom/timestamp, enter ^c to exit..
2005-12-05 22:24:48.722 COS ACTIVE                <--- SQL信号ON:  ハンディからの信号受信
2005-12-05 22:24:48.878 DTMF S                   <--- DTMF * 受信
2005-12-05 22:24:49.294 DTMF 6                   <--- DTMF 6 受信
2005-12-05 22:24:49.606 DTMF 6                   <--- DTMF 6 受信
2005-12-05 22:24:50.082 COS INACTIVE              <--- SQL信号OFF:  ハンディからの信号OFF
2005-12-05 22:24:50.336 FORCE KEY BIT SET          <--- Key up
2005-12-05 22:24:50.336 PTT ACTIVE                <--- PTT ON:  この直後DTMFコマンド *66 の結果としてノード状況が音声送信されます。
2005-12-05 22:24:52.675 FORCE KEY BIT RESET         <--- Unkey
2005-12-05 22:24:52.676 PTT INACTIVE               <--- PTT OFF

このreadinputと,$HOME/log/messages (ログ)を常時監視しておくと,自局ノードの利用状況が把握できる。

[repeater@dell ~]$ tail -f ./log/messages
Dec 04 2005 13:55:40 +0900 decode: DTMF = S73
Dec 04 2005 13:55:40 +0900 Node Disconnect from ref9990
Dec 04 2005 13:58:28 +0900 decode: DTMF = S66
Dec 04 2005 14:01:06 +0900 decode: DTMF = S66
Dec 05 2005 14:36:11 +0900 stn3425 connect ADPCM      <--- ノード#3425からのコネクトあり
Dec 05 2005 14:38:25 +0900 stn3425 disconnect          <--- ノード#3425ディスコネクト
Dec 05 2005 14:55:17 +0900 stn3425 connect ADPCM      <--- 再度#3425からのコネクトあり
Dec 05 2005 14:55:35 +0900 stn3425 disconnect          <--- ディスコネクト
Dec 05 2005 21:15:03 +0900 decode: DTMF = S66
Dec 05 2005 22:24:50 +0900 decode: DTMF = S66         <--- 上の readinput例で送信したDTMF*66のデコード


2005年12月04日(日)

娘に「なんでベタ書きで日記かいてるの。ブログにすれば。」と指摘され,いろいろ教えてもらいながらブログを試してみた。しかし,やはり書き勝手はこっちの方が良い。引き続きここで書いていきます。でも,ブログのトラックバックやコメントの機能は良いな。

1200MHz移行して1ヶ月たったが,トーンSQLの必要性は見当たらない。必要以上に敷居をあげることもないし,IRLPメーリングリストではトーンがネットワークを流れることを避けるため,できればフィルターアウトすべき,という論調もある。トーンSQLはオフにすることにした。(注)

(注)実際には,トーンスケルチの使用は,多くのリフレクターで推奨されている。トーンスケルチは使うべきだが,それが受信機のオーディオアウトを通って,さらにリフレクターまで流れ込んでくると別の問題を引き起こすので,ネットワークに流す前にフィルターアウトすべきであるというのが論点。

EchoIRLPのスタディーが進んでいない。EchoIRLPメーリングリスト以外の情報源が少ない。

そろそろ,この日記のエッセンスだけを取り出して,IRLPノード構築法としてまとめたいと思っている。


2005年11月12日(土)

eQSOの利用率が低いこと,そしてeQSO自体の安定性に不満があるため eQSO RF ゲートウェイは停止することにした。代わりに,430.02MHzではWiRES-IIノードを運用する。海外QSOに興味があるので,とりあえず#0100に常駐させてみる。

eQSOの安定性への不満とは,VOXによるネットワーク側への送信コントロール,DTMFソフトデコードの2点。調整がシビアであることと,その割にはアクセスリグの違いでうまく動かないことがある。やはりこの2点はハードウェアコントロールが良い。(試していないが,前者はWiRESやIRLPと同様にSQLラインを使ってハードウェアコントロールにできるはず。)

IRLPオフィシャルホームページにある運用ガイドラインを日本語に翻訳した。原文自体が内容的に十分整理されていないような印象も受けるが,一読の価値はあるだろう。基本的にはWiRESで言われている事柄と同様。


2005年11月01日(火)

オークションで購入したTM-833に免許が降りた。十数年前に比べると変更申請も簡単かつ迅速になったものだ。何より申請書をわざわざ買いに行かなくてもダウンロード入手できるのは良い。さらに,同じオークションでトーンスケルチユニットTSU-8を入手。中古とは言え玉数の少ない1200MHz,本体もトーンスケルチユニットも結構な買い物だったが,常時Sメーターが動いている430MHzに比べると精神衛生上ずっと良い。

したがって今までの2PC/1RIG構成から,IRLPとeQSOを分離。IRLPを今後のVoIP周波数帯を考慮し1294.62MHz/88.5Hz,eQSOは引き続き438.02MHz/123Hzとする。

IRLP PCとRIG間のケーブルを整理した。今までRIG SPK OUT から PC MIC-IN は別オーディオケーブルを使っていたが,RIGのデータ端子からのAF-OUTを使うことにした。小さいDB9コネクタ内でのハンダ付けには難儀したが,ケーブル1本減ってすっきりした。

写真右半分の白いケーブルがメスコネ部分を切ったPS/2延長ケーブル。コネクタはMiniDIN6pinでRIGのデータ端子につなげる。左のDB9はPCのIRLPボードへ,2本の3.5φプラグはそれぞれPC MIC-IN,PC SPK-OUT へつながる。

2005年10月22日(土)

海外にはアマチュア無線関連のニュースをMP3で聞けるWebサイトがいくつかあるようだ。そこから定期的にMP3をダウンロードして,ノードから送信できる仕組みを導入。DTMFコマンドでそれらのニュースを聞ける。ただし,英語。

430MHzの違法・不法モービル局にいい加減嫌気が差したため1200MHzへのQSYを決心。特にIRLP ReflectorやeQSO room,EchoLink conferenceの場合,当たり前だが海外局との同居が基本となる。日本の違法・不法局の音声が少しでも流れてしまうのは大変まずい。QSY完了後,あらためてトップページを変更予定。しかし,これから430MHzはどうなってしまうのだろうか。

430MHz,1200MHz,2PC の設備に対して,どのように IRLP, eQSO, WiRES を組み合わせようか。今回のIRLP導入最終目的はゲートウェイ構築であるが,どのような問題があるか引き続き検討要。問題としては,技術的要素だけではなく,セキュリティーや,それぞれの運用ポリシー等も考慮する必要あり。例えば,IRLPはPGPを使ってノード認証をしている。単純に他ネットワークをリンクした場合,どのようにこの認証セキュリティーを担保できるのか。一方,すでにEchoIRLPプロジェクトにおいてEchoLinkとのリンクは可能となっているので,それを学ぶ必要あり。


2005年10月16日(日)

午前中 Western Reflector (#9250)をワッチしていたら,子供の声がよく聴こえる。よく聞いてみると米国内のジャンボリー(ボーイスカウトやガールスカウトの大会?)らしい。世界中からコールしてきた色々な局に様々な質問をしている。おもしろかったのはオーストラリアの局に対する「カンガルーは見たことあるか」というとても純粋な質問。日本の無線ではめっきり子供の声を聞くことがなくなった。もっと増えて欲しいと思う反面,V/UHF違法・不法局どうしの交信などは,とても子供に聞かせられない。違法・不法局の悪影響というのは実はこのようなところにもある。

今日はランダムアクセス用コマンドを導入した。世界中のIRLPノードに対してランダムに接続する。ダウンロードしてきたスクリプトに若干の手を加えて,ランダム選局の対象地域を指定できるようにした。

ところで,IRLP Ver.3 ボードにはAUX1〜3という外部コントロール用端子がでており,プログラムからON/OFFが可能。前述のcustom_decodeスクリプトを使えば,DTMFを使って面白いことができそうである。例えば,custom_decodeのどこかに以下のような1文を入れておけば,DTMF "#13"で,IRLPボードのAUX3端子をONにできる。

if [ "$1" = "P13" ] ; then "$BIN"/aux3on ; exit 1 ; fi 
(注)ちなみに,'#'は英語でパウンドと呼ばれるため'P'。'*'はスターで'S'。プログラム上はこのように置き換えられている

2005年10月9日(日)

昨日WinSCPの導入でWindows<-->Fedora間でファイルを転送できるようになったが,やはり共有ファイルシステムが欲しくなった。噂には聞いていた samba を入れてみよう。Fedora Core3 for IRLP では samba はインストールされていないのでインストールから始めなければならない。しかし,Fedoraについてのとても良い日本語ホームページを見つけたので,それを参考に構築をした。ステップバイステップで書いてあるので,その通りに実行することであっという間に構築できた。実質時間30分以内。Linuxでは,入っていないインストールパッケージは,その依存パッケージも含めてインターネットから自動的にダウンロードしてくれる(yumコマンド)。

これで,Fedora上のsambaで設定したディレクトリが,Windowsからワークグループ上の共有フォルダとして見えるようになった。快適。ただし,日本語のフォルダ名やファイル名はFedoraで化ける。今後の検討課題。


2005年10月8日(土)

Windows PCとFedoraのPC 2セットをかわるがわる使うのも面倒になってきた。Windows からFedoraへtelnetでアクセスしようと思ったが,Fedora側にtelnetデーモンが入っていない。いろいろ調べた結果,最近ではセキュリティの関係で telnet ではなく ssh が使われているようだ(telnetではユーザーIDとパスワードが平文で流れる)。たしかに Fedora ではデフォルトで sshデーモンが動いている。Windows での ssh クライアントを調べると,いくつかフリーソフトがあるようだ。とりあえず PuTTY をダウンロード。sshではユーザー認証時データが暗号化されるようで,公開鍵と秘密鍵のペアを作る必要がある。PuTTYには鍵作成ツールもついてくるので簡単にできる。公開鍵の方をFedoraの $HOME/.ssh/authorized_keys ファイルに入れればOK。

これで,FedoraをWindowsからいじることができるようになったので,Fedora PCのキーボードとマウスは隅に追いやることができ,机上がすっきりした。ディスプレイは1台をSWで切り替えていたが,その必要もなくなった。FB。

同じようにFTPもやりたくなったので調べてみると,やはり同様のセキュリティの理由でFTPはあまり使われていないようだ。代わりに WinSCP というのも見つけて使ってみる。これは前述の PuTTYの鍵生成ツールがそのまま使えるのでFB。これで,いちいちフロッピー経由でファイルを移動する必要がなくなった。


2005年10月6日(木)

職場でそっと Google Earth を覗いてみる。ドンピシャ自宅の真上,それどころか家の中のノードが置いてある辺り。ここまで正確にわかってしまうと逆に怖いな。

Google Earth は,クライアントプログラム上でマウスポインターが示す地点の lat/long 情報を正確に表示する。よって,ポインターを家の上においてその数字を IRLP登録すればかなり正確に場所を示すことができる。

インターネットより speaktime スクリプトを入手,遊び半分で入れてみる。*66(ノード状況通知)の時と同様に$CUSTOM/custom_decodeスクリプトを変更し,DTMF *77 でspeaktimeを呼ぶようにする。これで*77で現在時刻を英語でアナウンスしてくれる。


2005年10月5日(水)

IRLPメーリングリストで,さかんに Google Earth の話題がやりとりされているので試してみると,やはり想像どおり各ノードの位置が Google Earth上で表示される。見た目なかなか良い。すでに各ノード登録時に lat/long(緯度・経度)情報は入力しているので,それをもとに衛星写真上に印をつけてくれる。それだけでなく,各ノードの状況によって色分け,接続中のノードは相手と線で結んでくれる。しかし,自局登録時の情報が十分な精度ではなかったためか(小数点以下5桁でもかなりずれる),自分の家とは若干違うところに表示されてしまった。

帰宅後,Database Update Page からもう少し高い精度で自分の登録情報をアップデート(ちなみにノードPCと同じIPアドレスからしか変更できない)。実際の家近くになったかどうか確認しようと思ったら,自宅のPC性能が低いからか Google Earth client が動かない。明日また職場でそっと見てみよう。

ノードのログを見てみると,日中 #66666 のDTMFアクセスが多い。WiRESと思われているのだろう。音声定期アナウンスで「IRLPノード」と言っているのだが,それでもこの間までWiRESだったため間違えてアクセスしてくるのだろう。勝手に変えてしまって申し訳ない。


2005年10月4日(火)

頭を悩ませていたwavファイル再生音質問題であるが,なんとか解決した。
とは言え,サウンドカードを同じCMI8738チップだが別製品と変えただけ。同じ「玄人志向」社製の同チップ製品だが,CMI8738-4CHPCIではダメで,CMI8738-6CHLPではOK。同じチップなので変えてもダメだろうと諦めていたが,ダメもとでやってみて動きだした。サウンドでは結構苦労した。これからトライされる方は,Tested SoundBlaster Cards を参考に,できればやや古いタイプの SoundBlaster を早い段階で入手されておくことをお勧めします。

私の場合はサウンドのみならず,何か動かない場合Linux構成をいじったり,カーネルをリビルドして直すほどのスキルはなく,H/W交換という一番安易な方法で対応せざるを得なかった。やはりLinuxはこういうところがマニア向きといわれる所以であろう。

ということでconnect/disconnectの際のアナウンスがきれいに流れるようになった。今まで酷い音で空を汚しており申し訳ありませんでした。

これで何とかIRLPノードの体をなしてきたと思う。お近くの方は是非アクセスしてみてください。

今日はReflector#9254において,IRLPメーリングリストで開局の知らせがあったばかりのサイパンKH6FV/KH0とQSO,そのままハワイ・ホノルルのKH6DQにも呼ばれ海外QSOを楽しんだ。


2005年10月3日(月)

あいかわらず connect/disconnect の際のアナウンスの音質が悪い。これはRIGを経由せずPCだけで再生しても同じ。使われているwavファイル形式は 8bit/8KHzサンプル/Mono/PCM。このファイルをWindowsに持っていくときれいに再生される。Windows側で22.05KHzや44.1KHzで作成したファイルをFedoraに持っていくときれいに再生される。よって,ほぼ間違いなく Fedora PC での 8bit/8KHz/PCM 再生の問題。別のサウンドカードを入手しようか。しかし,どれなら確実に動くのかが不明。オフィシャルホームページには tested sound card のリストがあるが,すべて古いSoundBlasterなので,入手できるのだろうか。

今日は自分のノードのannounceファイルを作る。これは自局にコネクトした相手局側に流れる音声IDである。このファイルをセンターサーバーにロードすると,そのファイルが自動的に各IRLPノードに配信される。Windowsのsndrec32を使って8KHz/8bit/mono/PCM で自分で録音。connect時とdisconnect時の2つのファイルを作り(例:"This is JI1BQW. Link on.","This is JI1BQW. Link off"),それぞれのファイル名を"stn8437on.wav","stn8437off.wav"とする。これをフロッピーに入れて(注)Fedora から root で $HOME/scripts/send_wave_files を実行すると,サーバーにロードされ,数分で(?)各ノードに配布されるらしい。

(注)オンラインマニュアル"What do you do after the install"ではフロッピーに入れるよう指示があるが,必ずしもフロッピーに入れる必要がないことがその後わかっている。これら2つのファイルを /tmp ディレクトリーにコピーしておき,root で $HOME/scripts/send_wave_files実行するだけで良い。詳細は当スクリプトの中を参照のこと。

また,ローカル局がノードの接続状況を知るためのDTMFコマンド(WiRESの#6666Dコマンドに相当)を作る。check_irlpというシェルスクリプトをインターネット検索で見つけたので,それをダウンロードした。これを $CUSTOMディレクトリーに置く。さらに$CUSTOM/custom_decode スクリプトを変更し,DTMF "*66"でcheck_irlpを実行するようにした。custom_decodeは,デコードしたDTMFを解釈し,指定されたプログラムを実行する簡単なシェル。IRLPソフトは,解読されたDTMFコードを入力としてこのスクリプトをコールするようだ。すなわち,デコードされたDTMFは,まずこちらを通って処理されてから,IRLPソフトに処理が戻される。custom_decodeの詳細は Owner's FAQ にある。custom_decodeは簡単ではあるが,一方前処理でもあるのでエラーさせないように注意。

このように自分でコマンドを作れるような自由度は IRLP の大きな魅力の一つ。海外の他ノードでは,現在時刻や天気予報をアナウンスするような例もあるようだ。


2005年10月2日(日)

あちこち Reflector をモニターしている時に,JA3VQW局よりコネクトをいただいた。日本のIRLP局は数が少ないので,新たな開局はすぐ伝わるらしい。まだ完全ではないので,お恥ずかしい限り。VQW局ありがとうございました。


2005年10月1日(土)

今日は記念すべき IRLP first QSO。相手は東京目黒区の JR1NNV 局でした。Node-to-Nodeでこちらから突然コネクトしたにもかかわらず,快くご応答くださいました。NNV局にはあらためてお礼申し上げます。ありがとうございました。

ボードが届いたのが今週の月曜日ですから,今日まで平日がほとんどとは言えほぼ1週間かかってしまいました。まだ細かいところでやり残しがたくさんあります。WiRESとeQSOでそれぞれノードを立ち上げましたが,どちらも数時間でできたのに比べると,IRLPはやらなければならない事,解決しなければならない事,調べなければならない事がたくさんあります。しかし,久しぶりに「何かを作った」という達成感はあります。Linuxも久しぶりにいじって,指が vi をまだ覚えていることに我ながら感心したりもしました。

これからしばらくはIRLPを勉強します。学んだことは引き続きここに書いていきます。


2005年9月30日(金)

昨日からなんとか動作を続けているようだ。やり残しを少しずつ片付けよう。

今日まで持ち越している問題の検討:

IRLPデフォルト設定から以下を変更:

IRLPには,RIGからの定期ID送出の機能が見つからない。よって簡単なシェルを組むことにする。下のようなシェルを裏で動かしておけば良いはず。ただし,keyコマンドの実行後何かしらの原因でunkeyコマンドが実行されない場合,RIGが送信状態のままになるので,別の対策は必要。私はRIG自体の連続送信制限時間を設定している。

#!/bin/bash
while [1]; do
  key                     # PTT ON
  sleep 1                 #(必要に応じて)私の場合これがないと,下のメッセージの頭が落ちる
  play id_message.wav     # IDメッセージ送出
  unkey          # PTT OFF
  sleep $PERIOD           # $PERIOD=ID送出間隔(秒)
done
(注)ノードが接続状態にあるときには,keyコマンド,playコマンドが利かず,このシェルは動きません。リソースを取れないからかも知れません。いずれにしろ参考程度に。
(注2)その後の調査で,このシェルはIRLPプログラミングの基本ができていないことがわかっています。実際には使わないで下さい。

2005年9月29日(木)

今日は外出先から直帰,少し早く帰宅できた。

今の大きな問題は,PCから音が出ないこと。音が出ないので録音(MIC-IN)が動いているのかもわからない。残念ながらFedora (というかLinux系の)サウンド関係は全く経験無いためググリまくるが,複雑すぎてやっぱりよくわからない。もうオンボードのサウンドチップ(CS4236Bなのだが)との相性が悪いと勝手に決めつけ,手持ちのPCIサウンドボード(CMI8738)を挿し,alsaconfコマンドで再構成。さらにBIOS設定でオンボードサウンドをオフにして起動。いきなり音が鳴り出した。よくわからないが,とにかく動いたので良しとする。録音もOK。

オンラインマニュアル"What do you do after the install"に従い,aumix(サウンドミキサー)を使って以下の音量調整をおこなう。

まず,root権限で aumix を実行。さらに別の virtual terminal において su - repeater を実行しておく。

さらに,pulseback(いわゆる bouncing とか「おつり」とか言われている現象)の調整をおこなう。この一つの原因は,RIGの送信から受信への遷移の際,一瞬SQLが開くこと。

ちなみに,pulseback があるかどうかは,readinput コマンドで PTT と COS の状況を観察するとある程度判断が可能。例えば,IRLPネットワークから信号を受信すると,readinput は以下のような遷移を示す。
PTT ACTIVE (RIGを送信状態にする)
PTT INACTIVE (RIGを受信に戻す)
pulseback が無い場合はこれだけだが,もし PTT INACTIVE の直後に(時間差なく)以下のようなCOSのon/offが観察されるような場合には,pulseback を疑う。
PTT ACTIVE (RIG送信)
PTT INACTIVE (RIG受信に戻る)
COS ACTIVE (SQL開き,その結果パケット送信される)
COS INACTIVE (SQL閉じる)
後日気付いたのだが,この設定によりトーンSQLが一瞬開くことによるノイズパケット送出も抑えられているようだ。トーンSQLでQRMをブロックしていても,時々音声周波数の一部が反応するのかトーンSQLが一瞬開いてQRMになることがある。この現象がある程度抑えられているように思う。

これで,一応すべて完了のはず。では,いよいよ使ってみますか・・・

あちこちの reflector に接続,モニター開始。DTMFも問題なく,快適にコントロールできる。しかし,まだどのreflectorのどのchannelが,どのように使われているのかがよくわからない。これからは,こういう運用上の慣習も調べて行かないと。


2005年9月28日(水)

今日も帰宅後9時から作業開始。まず,昨日書いたような自分のノード情報をデータベース管理者にメールで送る。すぐに返事あり,リストに掲載された。Good!

さて,ハードの工作開始。別途用意したものは:

(注)これはminiDIN6pinのオス・メスが両端についていてRIGデータ端子用にFB(600円くらいするが,工作嫌いな私には重宝)。私は1本はいつもこれをRIGから出している。おかげでRIG背面での細かい作業が不要になる。例えばWiRESの時は,HRI-100 付属ケーブルをこのPS/2延長ケーブルのメス側につないで使っている。HRI-100付属ケーブルは貴重なので切ってはいけない。切るならこちらのPS/2延長ケーブル。

ちなみに,HRI-100のminiDIN8ピン用には Macintosh のプリンターケーブルがminiDIN8ピン両方オスでこれもFB。

まずはIRLPボードのパラレルコネクタ部分と,ボードから出ているDB9シリアルコネクタをPCのペリフェラルスロットに固定。バススロットに接続する訳ではなく,単にペリフェラルの長四角の窓にねじ止めするだけ。ボード付属のパラレルケーブルを使ってボードとPCを接続する。

いよいよRIG(ICOM IC-207)との接続。まずRIGのデータ端子とIRLPボードから出ているDB9コネクタを接続する。PS/2延長ケーブルのオスはRIGデータ端子に接続,さらに反対側メスコネクタ近くでケーブルを切断,DB9メスコネクタに付け替える。使う信号はPTT,SQL,AF-IN,AF-OUT,GNDの5本。RIG側のPTTはボード側のPTTに,SQLはCOSに,AF-OUTはDTMFデコーダ端子にそれぞれ接続。ピン配置はオンラインマニュアルにあるとおり。IC-207の場合,PTTとSQLの極性はデフォルト(PTT active low,SQL active high)のままでOK。

DB9コネクタ内でRIG側のAF-INに20cm程度のシールド線を接続(DB9のどのピンにも接続しない),もう一端には3.5φオーディオミニジャックプラグをハンダ付けし,それをPCのSPK(LINE OUT)に接続する。これはIRLPネット側からの受信AF信号をデータ端子経由でRIGに送るため。

RIGの外部SPK端子から,オーディオケーブルでPC MIC(LINE-IN)へ接続。上記同様,RIGデータ端子AF-OUT(1200bps)経由でPC MIC-INに入れればRIG<->PC間の長いケーブルが減ってすっきりするが,半田付けをやりたくないのでこうした。

さて,これで良いはず。Fedoraにrootでログイン,virtual terminal を一つ作り(ALT-F2),su - repeater でユーザーを切り替える。ちなみにIRLP関連コマンドは,この repeater というユーザーで実行する。まず readinputコマンドで,PTTとCOS(SQL)が正しく動くかを確認する。しかし,うまく行かない。PTTは認識せず,COSは別のハンディから送信しようがしまいがActiveのまま。なぜだろう・・・としばし考えた末,大きな間違いに気が付いた。IRLPボードに電源を接続していない!前述のようにバススロットには挿さないので別電源の供給が必要なのである。PC内の余っている4ピン電源コネクタをボードに挿さなければならない。そのためのコネクタがボートにあるし,オンラインマニュアルの一番最後に書いてある。見落としたようだ。

さぁ,これでOK。別ハンディから送信すると, readinput コマンドからの出力でCOSがINACTIVEからACTIVEへ,またvirtual terminalを切り替えてそこから key コマンドを入れればPTTがACTIVEになりノードRIGが送信。(同時にIRLPボード上のCOS/PTT LEDもそれぞれ点灯します)

Windows PCからIRLPステータスを確認すると,無事自分のコールサインが表示され,IDLEになっている。DTMFテストがてら,ハンディからあるreflector番号を入力すると,無事接続された。(ここでもDTMF送信と同時に,IRLPボード上のDTMF Decode LEDが点灯します)。

IRLPのDTMFデコーダーはWiRES同様ハードウェアなので,何の調整もなく,エンコーダーも選ばず,送出速度に関係なくほぼ完璧に動作します。やはりこれは良い。eQSOゲートウェイはソフトデコーダーだったので,DTMFを構成する各トーン周波数毎に音量調整する必要あり,かつエンコーダーが変わると認識しないことや,送出速度が速いと追いつかないことがありました(私のVX-2ではDTMF送出速度が変えられないので使えなかった)。

今日はここまで。まだPCのオーディオ(サウンド)あたりがうまく行っていなさそうなので,明日に持ち越す。RIGのデータ端子をWiRES HRI-100に再接続してWiRESノードに戻す。


2005年9月27日(火)

IBM NetvistaのCD-ROMドライブを交換することで,anacondaが走り出した。一歩進んだが,今度はVideo廻りでストップ。もうあきらめて,WiRES/eQSOで使っているDell Optiplex (PIII 500MHz 256MB mem)と交換することにする。古い機械だが,IRLP最低スペックは十分に満たしている。

あとで知ったのだがHCL/FC3をちゃんと調べてからPCを購入すれば良かったと思う。RedHatが動いたので大丈夫と高を括ったが,考えてみればRedHatが動くのは当たり前。根の同じRedHatが動いたからといってFedoraが動くとは限らない。

さて,本題のFedoraだが,こちらのDell機にはあっけなくインストール終了。ネットワークにつなげたままインストールすることで何もせずにネットワーク系も構成してくれる。ただ,こちらもサウンドがうまく動いているかどうかまだわからないのと,キーボードが日本語KBD設定になっていないので,この辺は明日以降確認することにする。UNIXのようなlocaleというのはあるのだろうか。昨日はインストーラーがKBDの種類を聞いてきたのだが・・・。

引き続き,IRLPソフトのオンラインインストールに移る。オンラインマニュアル"IRLP Node Software Installation Manual"で流れを確認し,install script を実行。あとは画面の指示に従って操作するだけ。これは簡単!あっという間にインストール終了。無事ノード番号 stn8437 が割り当てられた。

そして,オンラインマニュアルに従い,WiRESやEchoLinkでおなじみのファイアウォールの穴あけ。問題なし。

さらにオンラインマニュアルの"What do you do after the install"によると,この後は以下の情報をデータベース管理者に送ればIRLP仲間入りができるらしい。

しかし,当然のことながらその前にハードウェアの接続が待っている。昨日送られてきたボードだけで良いのか,あるいは他に作る必要あるのか,明日以降調べて行きます。


2005年9月26日(月)

オーダーしていた IRLP board他一式到着。内容は次の通り:

1週間早くオーダーしていれば先週の連休で遊べたのに,と後悔するが,実は根を詰めてしまう性格のためこのくらいが良い,と別の自分が言う。

早速 Fedora をインストール。早くもここで躓く。送られてきたCDでブートはするが,途中からCDが認識されなくなり先に進まない。インターネットで調べると,どうもこのIBM Netvistaではそういうことが起きるらしい。解決策は見つからない。RedHatは問題なく動いたのに・・・と,あきらめて評判の良いIRLPサポートにメールを出しました。ただIRLPの問題ではないので解決できるかどうかは疑問。

---

今日はFedoraの方はさっさとあきらめたので,もう一台のPCでeQSOとWiRESのゲートウェイ構築を試みる。Windows2000,サウンドカード2枚で,両者の音をMIXさせようとするが音声レベルがなかなか合わない。何とか聞ける程度でまだ使い物にはならない。引き続きチューニングが必要。あと,eQSO受信時にWiRES送信するための回路を作る必要あり。


2005年9月22日(木)

連休を挿んでいたので若干遅れて,Linux用PC到着(相手は企業だったのでとりあえずOK)。早速検証兼ねて手持ちの RedHad 7.2 をインストールし,無事動作確認。大した根拠もなくこれなら Fedora も行けるだろうと高を括る。


2005年9月17日(土)

WiRESノード,eQSOゲートウェイ/サーバとやったので,次はIRLPだ〜,と一念発起。昨夜(9月16日金曜夜)boardをオーダーしました。 送料がわからないので,とりあえずUS$150をPayPalで送って,(ボード+CD)のパッケージと日本向け送料を引いた残りをdonationにしてね,とメールを 送ったら,今朝(土曜)には早速返事が返ってきて,向こうの月曜日には発送してくれるとのこと。

またLinux用に別PCが必要なので,本当にFedora Core 3が動くのかがちょっと心配ながら,オークションでIBM Netvista(Cel1GHz/128MB/20GB)を安く落札。

これからどうなるか,ここに記録します。


Back to www.ji1bqw.com