ソフトモデムを作ろう

東京消防の無線がデジタル化されたようですね

2009-03-10T23:46:00.003+09:00

150MHz帯のアナログでは、指令側の音声しか聞こえてないようです（23区内）。おそらく、運用的にはデジタルに移行しつつも、予備的にアナログも使っているといった状況ではないでしょうか。しばらくしたら、全共波以外は聞けなくなるかもしれません。

どうやら、このデジタル変調はπ/4シフトQPSKで8kbpsらしいです。これを受信して、ソフトウェアでデコードできるか否かというのを考えてみると…。

PSKを復調する方法として、SSBで復調してデコードする方法があるのですが、SSBだと普通、帯域幅が3kHzであるため、キャリアの周波数は3kHz以下になるので、π/4シフトQPSKを復調しようとした場合、数百bpsぐらいまでしょう。

別な可能性としては、DRM(Digital Radio Mondiale)をPCで復調する方法と同じ様に、受信機の中間周波を取り出して、サウンドデバイスでキャプチャー可能な周波数まで中間周波を下げて、取り込むという方法があります。

この場合、中間周波数（キャリア）をいくつまで落とすのかという考察は必要かもしれませんが、44.1kHzのサンプリング周波数だったら可能ではないでしょうか。ただし、π/4シフトQPSKの復調だけなら、単にビット列しか得られないわけですから、そこからフレームの解析やコーデックで音声化しなくてはならないので、難しいでしょうね。しかも暗号化されていたら、ほぼ無理でしょう…。

これとは別な話ですが…。彼らがＡＶＭといっているデータ通信ならデコードできそうですが、現在150MHz帯で運用されているのでしょうか？

関東私鉄空線の仕様（追記）

2009-02-11T12:28:00.003+09:00

過去記事にいわゆるNEC式空線の仕様について述べたのですが、他の私鉄のフォーマットを解析してきた結果、いくつか違ったパターンが存在するようなので、現在わかっている範囲ですが、内容をフォローすることにします。

チェックロジック

12bitのCRCでフレームをチェックしているということでしたが、フレーム長が短い場合、10bitのCRCでチェックしているようです。もちろん、生成多項式も異なります。

フレームの繰り返し

1パケット内に同じ内容のフレームを繰り返しているということでしたが、一部の私鉄では、同じ内容ではなく、シーケンス番号（1から順に増えていく数）を含んでいる場合があるようです。ただし、それ以外の内容については同じ物となっているようです（フレームのチェックビットの内容は変わる）。

空線に送られるフレーム

空線時には、各列車ごとに接続を確認するようなメッセージを送っているということでしたが、一部の私鉄では、１つのパターンを送り続けている場合があるようです。この場合、列車を識別するビットの位置には、いわゆる一斉呼び出しと同じビット配列となります。

フレームの再送

接続を確認するようなフレームを空線時に送る場合、同じ列車を識別するビット列に対して、違うコマンド列で2回続けて送信しているというとですが、これは、運転士と車掌の端末に対して送っているようです。ただし、コマンド内のビットがそのまま運転士と車掌の区別をしているというわけではなさそうです。

といったところが、現在わかってきたことになります。なお、関東私鉄空線研究会において、Windowsで動く空線デコーダーのα版テスターを募集しております。また、フォーマットの解析のために録音した空線を送っていただくといういうのでもかまいません。ご参加をお待ちしております。
あと、NEC式私鉄空線は、小田急、東急、西武、京王、東武で採用されていると認識していますが、他の私鉄でも採用されているかどうかがわかりません。情報をお持ちの方がいらっしゃったら、よろしくおねがいします。

私鉄空線のデコード（最終章？）

2008-12-30T20:53:00.007+09:00

なんとかちまちま作ってきた私鉄空線デコーダーですが、とりあえずα版ぐらいのレベルまでたどり着けました。といっても、まだ作りこんでいないところがいくつかありますが、デコード機能的には完成したという感じです。

というわけで、現在の画面ですが、基本的にはデコードした結果を表示するだけなので地味なものですｗ。あと、前の記事でも書いたとおり、空線キャンセラーの機能も入っています。ただ、気がかりなところといえば、実行時のプロセッサーの負荷率がやや高いといったところでしょうか。サンプリングレートを上げて、デュアルデコード（左右チャンネル同時にデコードする）を実行すると、ちょっと重いかな？といった感じがします。

まだ、しばらくは作りこみが必要ではありますが、テストをしたいというのもあるので、限定で公開しようかと思っています。とりあえず、LiveSpaceに「関東私鉄空線研究会」というグループを作ったので、興味がある方がいらっしゃたら、WindowsLiveのアカウントを作って、入会をリクエストしてみてください。
そういったわけで、私鉄空線デコードネタは、このブログではとりあえず、クローズしたいと思います。

テストをお願いするにこちらから注文をつけるのも忍びないですが…。テストの成果をそれなりに出したいので、とりあえずの条件としては…。

それなりにWindowsを使いこなしている人
それなりに鉄道無線に精通している人
空線がデコードできる私鉄の鉄道無線を受信できる人

要するにですね、いまのところヘルプとかの詳しいドキュメントができてないので、いきなり実行モジュールをもらってもなんとかなるとか、鉄道無線の受信の仕方とかを指南しなくてもなんとかなるとか、ＰＣと受信機をオーディオケーブルでつなげられるとか、そういったレベルなので、普通に私鉄の無線を聞いている人でＰＣを持っていればおＫといったところです。

受信電界強度が弱くて、ノイズ混じりだったり、電界強度が不安定だとデコードできないかもしれないので、必然的に特定の私鉄沿線の近くで受信できる人という条件にもなります。結局のところ関東というか首都圏の一部の地域に限定されてしまいますが…。

あと、できれば、フォーマットの解析もしたいので、いろいろな沿線の人に使ってもらいたいと思っています。このソフトは、最終的にはフリーウェアとして公開する予定なので、ボランティアで参加ということで…。そういうわけで、よろしくおねがいします。

私鉄空線のデコードと空線キャンセラー

2008-12-08T22:15:00.001+09:00

おまけの話でなんですが、空線がデコードできるということは、空線があるか否かがわかるという単純な発想で、作成中の空線デコーダーにいわゆる空線キャンセラーの機能を入れてみました。

空線キャンセラーといえば、空線がどのくらい除去されるのかというのが話題になるのですが…。
やる気になれば、デコード可能な信号という条件なら、ほぼ100%除去することも可能です（といっても、よっぽど電界強度が高く、安定してないと100%のデコードにはなりませんが…）。ただし、キャプチャと信号処理で必ず遅延が生じるので、それをするにはループバック（ラインインから取り込んで、Waveアウトに出力）させないとダメです。しかし、そこまでするのはかなり面倒なのでやりません（少なくともデコーダーの機能ではない）。

そういう意味では、簡易空線キャンセラーというべきかもしれませんが、信号処理でデータが抽出できたら、ミキサーコントロールを操作してミュートにするいう仕組みで、信号処理後にミュートですから、もちろんそれなりの遅延が生じます。

そもそも、キャプチャーはある程度のデータがバッファに溜まってから取り込むので、最悪バッファ長に相当する時間の遅延が発生するわけです。
さらに、そこから信号処理をするわけですが、プロセッサーの処理速度に関係なく遅延するのがフィルタです。

いわゆるデジタルフィルタは、ある程度の数の連続したサンプルを使って、出力を計算するわけですから、キャプチャしたデータの最後のほうは、次の取り込みでデータを取得しないと計算できません。あと、フィルタ長にもよりますが、フィルタによる遅延も影響してきます。

あとの信号処理は、大きく遅延するような処理はしないので、プロセッサーのパワー次第です。ただし、少なくともパソコンの場合、信号処理だけで負荷が高いと結果的にキャプチャーの取りこぼしにつながるので、ほどほどになるようにチューニングしておきます。そういった意味では、そこではそれほどの遅延にはならないはずです。

といった具合で、現在の空線デコーダーに組み込んだ簡易空線キャンセラーの場合、おそらく0.3秒ぐらいの遅延が生じているようです。これは、アップリンクの1パケットがだいたい0.5秒ぐらいなので、そこから聞いた感じで推測しているので、あまり正確な数字はないですが…。

と、いいつつも空線キャンセラーの機能は、デコーダー的にはまったくのおまけなので、これ以上どうにかしようとかは思っていません…。

私鉄空線のデコーダー

2008-12-08T21:38:00.000+09:00

私鉄空線をデコードできるということは、過去記事にていくつか述べましたが、Windows上で動くデコーダーが概ね完成しました。まだ、絵的には完成していない（アイコンとか）ので、スナップショットは、体裁が整ったらご紹介しようかと思っています。

ただ、安定して受信できるのが、西武線しかないのでフォーマットの解析は西武線のみになっています。解析はほぼ完了しておりますが、まだいくつかのなぞが残っています。詳しい人がいたら教えてほしいのですが…。

西武線の場合、無線はＬＣＸを使っているのですが、どうやら、沿線全てで指令側が１つではなくどこかに切れ目があり、場所によって指令側が変わるようです。
おそらく、どこかの駅の下り側と上り側では指令側の担当が違っているところがあるということです。

その切れ目がどこかというのが知りたいのですが…。いまのところの予想では、西武新宿線は、田無あたりに切れ目がありそうではないかと思ってます。
これとデコードとの何の関係があるかというと、このエリアによってデータが変わるのではなかろうかということです。

もちろん、それらしき場所に移動して、受信しデコードすれば判明することなのですが…。デコードをするには、それなりに電波が安定していないとダメなので、それなりの装備が必要ではないかと…。

比較的近い西武線ですらこんな感じですから、他の私鉄はほとんど手付かずです。耳で聞く限りでは受信できるところもあるのですが、デコードとなると条件は別で、電界強度が高くてもデコードできないこともありますし、聞いた感じノイズがのっていてもデコード可能という場合もあったりします。

そのへんは、デコーダーが出来上がったら、それぞれの沿線に得意な人に使ってもらって解析するというほうが無難ですかね…。

MSKをゼロクロスでデコード

2008-11-02T21:56:00.001+09:00

MSK（CPFSKも含む）をゼロクロスを使ってデコードする方法について書いてみることにします。今回作成している私鉄空線のデコーダもこの方法を使っています。

ゼロクロスは、振幅の0をまたいだ時間を測定して、信号の周波数を測定するという方法としてよく知られている方法です。基本原理は、振幅が０を基準となる周期信号は１周期で２回符号が入れ替わる（すなわち、０をまたぐ）ということから、符号をが２回変わった時間を測定すれば、１周期の時間となりその逆数が周波数になるというものです。

MSK(CPFSK)の信号は、位相が連続して周波数が移行するといったものですが、シンボルが入れ替わるところは、一般的に振幅が０となるところになります。他には最大振幅点で変わるものもあるようですが、あまり多くはないようです。
ここでは、一般的となる振幅０で移行するもの（これをsin型という）をゼロクロスを使ってデコードする方法について書くことにします。

まずは、変調速度に同期するのですが、上記の条件の通りシンボルの入れ替わりは、常に振幅０の位置で起こるわけですから、ゼロクロスの点になります。同期の開始位置は、シンボルの入れ替わる場所となりますが、もし１つシンボルが変調速度の２倍の周波数となる場合、それだけでも、変調速度との同期が可能です。

この手の処理は、ハードウェアでは変調速度と同じクロックをPLLを使って同期させるというのは一般的な方法です。しかし、ソフトウェアでのデコードの場合、多少事情が異なります。
というのは、信号はサンプリングされてデジタル化されるわけですが、変調とは無関係なクロックでサンプリングされてしまっているので、完全な同期というのはできません。しかし、変調速度よりも比較的高い周波数でサンプリングされていれば、誤差は多少あるもののデコードはは可能です。

サンプリングされたデータからゼロクロスを検出するには、振幅が０以上か未満かで２つに分けて、１つ前のサンプルと比較して違っていれば、１つ前のサンプルとそのサンプルの間のどこかにゼロクロス点があるということになります。
そして、次のゼロクロスを見つけてその間のサンプル数を数えていけばよいわけです。ただし、サンプリングのクロックとの関係上１サンプル分の誤差が生じる可能性があるため、その分を考慮して同期をとるようにしていきます。

あとは、変調速度に相当するサンプル数（サンプリング周波数÷変調速度）毎にゼロクロスが存在することを確認しながら、その間に含まれるゼロクロスの数を数えていけばよいです。もし、変調速度と同じ周波数で変調されていれば、ゼロクロスは中間に１つ存在するわけですし、1/2の周波数ならば、ゼロクロスは０個といった具合になります。

といった方法でデコードは可能ですが、現実にはゼロクロスの位置が信号の歪みにより前後することがあります。なので、その分を考慮し多少前後しても許容するような作りのほうがデコード能力は高くなります。ただし、あまり甘くしすぎると誤検出することもあるので、その辺のさじ加減はチューニングのひとつとなるでしょう。

あと、ゼロクロスに限った話ではないですが、前処理としてフィルタをかけておくと、比較的簡単にデコード能力が向上します。もちろん、フィルタの選び方次第で良くも悪くもなるので、それなりに適切なフィルタを選ぶ必要はあります。
正直言って、ベストなフィルタというのはわかりません。基本的にはBPFをかけるのですが、通過域が広いとノイズの除去になりづらいですし、狭くしすぎると歪みが起きてゼロクロスがずれます。

ゼロクロスの処理は、アルゴリズムも比較的簡単でプロセッサの処理的には軽く実現することができるので、まずはMSKなどのデコーダを作ってみようという人にはおすすめです。
実際に作った空線のデコーダですが、上記の処理方法をベースに作成していますが、十分なデコード能力を持っていると思います。

関東私鉄空線の仕様

2008-10-31T21:45:00.005+09:00

私鉄の空線のデコードですが、大まかな仕様がわかってきたので、まとめてみます。ただ、独自に解析した結果であって、正式な仕様とは違っている可能性は十分あります。あくまでも参考ということでお願いします。

前回の記事でチェック方式は、CRC12ではなかろうかということでしたが、予告通りを総当りしたところ、生成多項式が見つかったので、CRC12で確定とします。なお、パリティはありませんでした。
あと、変調方式ですがMSKといってましたが、おそらく正しくはCPFSK（位相連続のFSK）ではなかろうかと思ったので、そう書いておきます。

変調仕様
変調方式	変調速度	マーク周波数	スペース周波数
CPFSK	1200ボー	1800Hz	1200Hz

初期信号、いわゆる空線時の信号は「マーク・スペース」の連続となります。空線間に送出される信号（アップリンクで一回に送られるものも同様）をとりあえずパケットということにします。

パケット仕様
初期信号	フレーム	初期信号	フレーム	…	初期信号	フレーム	初期信号

要するにパケットは、同じ内容のフレームが複数個存在しているということです。含まれるフレームの数は、可変で鉄道会社によって変わるようですし、フレームの内容によって数が増えることもあるようです。
フレーム間の信号は、基本的には8個のマーク・スペースの連続（16シンボル）となります。

フレーム仕様
同期パターン	データ	終了文字	CRC
16ビット	可変長	8ビット	12ビット

データは、鉄道会社によって長さが異なるようですが、会社毎に長さは一定で4の倍数ビットとなるようです。終了文字も鉄道会社毎に異なりますが、データの長さによって決まっているかもしれません。いまのところ、異なる鉄道会社において同じデータ長を使用しているところがあるかはわかりません。
予想としては、データ長と終了文字で鉄道会社を識別できるのではないかと思っています。そういった意味では、終了文字というよりは会社識別用ビット列なのかもしれません。

データ内の仕様ですが、２つに分けられると思われます。そのうち前半は、おそらく識別符号として使われていて、この部分が全て「1」のパターンが存在しており、これは一斉呼び出しなどの相手を特定しない場合に送られると考えられます。そのため、ダウンリンクのみに存在するのではないかと思います。

データの後半は、なんだかの制御用に使用されているものだと思われます。少なくともダウンリンクとアップリンクでは、この部分のビットの立ち方が異なります。また、同じ識別符号を持つパケットが２回連続で送られているようですが、そのときに２回目には１つだけビットが増えていて、再送フラグではないかと思われます。

私鉄の空線のデコード(7)

2008-10-28T20:56:00.001+09:00

相変わらず、私鉄の空線のデコードを続けています。その後、デコード精度を上げてみたところ、西武線以外の空線もデコードできるようになり、フレームのフォーマット（プロトコル）がなんとなく見えてきました。
ただ、まだデータの収集は十分ではないので、正しいかはわかりません。

かつては、フレームは可変長ではないかということをいっていたのですが、どうやら基本的には固定長であるようです。ただし、解釈によっては１ビット増えたり減ったりしているとも思えます。
フレームの後にいわゆる空線パターンの「10」の連続があるのですが、それが固定長なのかどうかはよくわからないといった感じです。

現段階で想像されるフォーマットは以下のような感じになっています。

同期パターン	データ	データ終了	チェック
16bit	Xbit	16bit	13bit

このうち、「データ｣の長さは鉄道会社によって違うようですが、もしかしたら複数の長さのパターンがあるかもしれません。あと、いずれの場合も長さは4の倍数になっているようです。
「データ終了」のパターンも会社によって異なるように思えます。

あと、チェックだと思われるビット列ですが12bitかもしれません。よくはわからないのですが、パリティで1bit付加されるような仕様なのかもしれません。ここだけ奇数なのはやはりあやしいので、パリティではないかという予想も含まれていますが。
12bitが何かのチェックではないかというのは、以前も書いたのですがここだけがかなりランダムのようなビット配列になります。ただ、12bitのチェックアルゴリズムというと、CRCぐらしか思いつかないのですが、生成多項式がわからないので確認はしていません。
ちなみにネットで調べたところによると12bitのCRCというがあるらしいです。ただし、どこが規定したものかはわかりませんでした。12bitなら、総当りで計算してもたいしたことはないので、最悪それで見つけてみようかとは思っています。

私鉄の空線のデコード(6)

2008-10-12T22:06:00.001+09:00

関東私鉄の空線のデコードの続きですが、フレームのサイズが変わるのが気になったので、ビットの同期を少し精度を上げてみたのですが、やはり違ったサイズのフレームが送られているように思われます。
１ビット違うというのであれば、デコードを失敗しているのではないかとも思うのですが、サイズが３分の２ぐらいのものがあるので、さすがにそこまでは失敗はしないはずなので、やはり可変長なフレームになっているのではないでしょうか。

といったわけで、これから先の解析はデータの収集が必要ではなかろうかと思いつつ、面倒なので、とりあえずこのへんでいったん中断しようかと思います。ただ、作ったソフトが中途半端だと再開したときに訳がわからなくなるので、デコードしたデータを表示するだけという、かなり寂しげなソフトですが、いちおうそれなりにデコードはできるので、形だけということで現状版としてFIXしてしまおうかと思っています。

あえてスナップショットを見せるほどのものではありませんが、折角なので画像をアップしておきます。画像をそのままアップすると例の電波法に引っかかると叩かれそうなので、一部モザイクをかけました。一部でいいのか？という気もしますが…。

デコードしたのは、西武線のアップリンクです。データの中身の意味はわかりませんが、フレームの前半は比較的規則性のありそうな数字の並びになってますが、後半の16ビットぐらいはどちらかというとランダムな感じのする数字になってます（モザイクで見えないですが）。
そういう意味から推測すると、後半は何かエラーチェック用のデータであると思います。16ビットで間違えがなければCRC16かもしれませんが、そうでなければBCHかもしれません。前半のデータが何も加工されずに送られているのであれば、エラーチェックは無視しても問題はないとは思うので、ある程度の解析はできるのかもしれません。

私鉄の空線のデコード(5)

2008-09-28T23:27:00.001+09:00

私鉄の空線のデコード（アップリンクも含む）の解析として西武線をデコードしていますが、データのパターンがいろいろあるようなので、手間取っています。

まず、フレームの長さが一定ではないということがわかりました。ダウンリンクはほとんどが56ビットですが、アップリンクは57ビットになります。ただし、両者ともビット長が短いフレームやまれに長いものも存在するようです（長いほうはデコードエラーかもしれないが…）。
特にダウンリンクのほうは、短いフレームを送っている頻度が高いように思えます。

あと、フレームの長さとデータとの間になんだかの相関関係があるようで、先頭の数ビットにパターンで長さが変わる傾向があります。ただし、そこにデータの長さを示す数値があるようには見えません。おそらく、データの種類を識別する情報が先頭に存在するのではないかと推測されます。

あとは、データの中に共通するビットパターンが存在するようです。ただし、それほど多くのデータを見たわけではないので、フレームに含まれる情報が同一のものであるかもしれません。頻度の低いデータの場合、このパターンが含まれない可能性もあります。

と、いった具合で、思ったよりも複雑なため、これから先は解析が難しそうです。もっと大量のデータを収集してパターンを整理しなければならないかもしれません。

私鉄の空線のデコード(4)

2008-09-23T15:29:00.003+09:00

私鉄空線のデコードですが、その後プログラム的にデータを分割してみたところ、前回の記事の内容と違っているところがあったので、一部訂正します。
といっても、まだ解析が十分とはいえないので、この先また違ったことになっているかもしれません…。

まずは、複数送信されるデータ（これをフレームとする）は、基本的には102ビット（13バイト）になっているようです。ただし、たまに100ビットになっているときもあるようなので、フレームは可変長かもしれません。

あと、一度に送信されるフレームの回数ですが、基本的には7回送信しているようです。ただし、たまに聞いた感じでも通常より長い時間送っている場合があるので、なんだかの情報を送ろうとしているときには、１回に送る回数を増やしているようです。
ただ、これはアップリンクを受信して確認したものなので、ダウンリンク側の空線ではこのようなパターンがないかもしれません。確認はしてませんが、ダウンリンクで通話が始まる前に送出されているデータがこの回数の多いパターンかもしれません。
ということを仮定すると、アップリンク側の回数の多いデータは、通話を要求しているときに送られるものとか、重要な情報を送るときのパターンかもしれません。

私鉄の空線のデコード(3)

2008-09-22T21:08:00.001+09:00

私鉄の空線のデコードですが、とりあえずアップリンクをいくつかデコードしてみたところ、１回の送信で同じ内容のデータを複数回送っているもよう。今回も西武線を受信しているが、他の私鉄も同じような感じに聞こえるため、おそらく同様なことをしていると思われる（ちゃんとデコードできてないので未確認）。

ちなみに具体的には、80ビットの同じ内容のデータを複数回（回数はちゃんと確認してないが、８回ぐらいと思われる）を送信しているようにみえる。さらに最初の16ビットと最後の16ビットは内容が固定されているようなので、実質48ビット（6バイト）のデータになる。

同じ内容のデータを続けて送っているということを考えると、何かエラー訂正をしているようではなさそうだと思われる。実際に8ビットごとにパリティをチェックしても同じにならない。エラー訂正的には、べたな方法だがエラーチェックは単純にデータの比較だけで済むので、処理は楽かもしれない。

この私鉄無線のデータ通信をどのようなことに使っているかはわからないが、単純にセルコールとして利用しているのであれば、発信元か呼び出し先があれば十分なはずなので、6バイトというデータ量でも用は足りているのかもしれない。基本的に全２重な通信なので、アップリンクでは発信元、ダウンリンクは呼び出し先（一斉コールも含めて）でよいとすれば、4バイトでも十分かもしれない。あとは何かの制御用の情報とも考えられる。

私鉄の空線のデコード(2)

2008-09-20T13:49:00.002+09:00

前回、私鉄空線のデコーダを試しに作ってみたということを書いたが、やはりアルゴリズム的にやっつけだったためビットを拾えなかったので、ZeroCrossベースでMSKデコーダを新たに作ってみた。
空線は入力電界が不安定なためエラーが多かったが、アップリンクを受信してみたところ、比較的強力で安定していたためこちらをデコードしてみることにした。

アップリンクのほうは、連続した信号ではなく単発でパケットのような信号をおおよそ0.5秒ぐらいの長さで送信しているもよう。この信号を今回作ったデコーダで、MSK1200ボー1200/1800Hzでデコードしてみたところ、600ビット以上連続でデコードできているようなので、ビットシンクはうまくいっていると思われる。もちろん、入力電界が弱い信号は途中でエラーとなってしまうが…。

ダウンリンク（空線があるほう）は、一定な音との合間に定期的に送っている信号や通話の前や通話中に送られている信号もアップリンクの信号に似ているので、おそらくこのデコーダで解読できるかもしれない。
といっても、この先の仕様はまったくわからないので、試行錯誤するしかないだろう。とりあえず、１フレームを８ビットとかで仮定して、先頭のビットパターンを見つけ出すとかしかないかもしれない。無信号のときのビットパターンが01の繰り返しなので、NRZIになっているかもしれないし、調べることはいっぱいありそう…。

私鉄の空線のデコード

2008-08-27T22:40:00.001+09:00

私鉄といっても関東とからしいが、鉄道無線に使われている通話以外のときの音（いわゆる空線信号）は、MSKらしいのでデコードしてみようと試みた。
仕様的には、1200ボーで1200/1800Hzの信号ということらしいので、やっつけでMSKデコーダをつくってみた。

うちで聞こえる私鉄の無線だと西武線だったので、デコードしてみたらビットシンクに失敗してデコード不能ｗ。やはり、FM変調で入力電界が低いとノイズにやられてデコードが難しいっぽい。振幅の変動と周波数の高いノイズの対策をしなくてはならないのであろうか…。

とりあえず、3kHzぐらいのLPFでも入れてみて再度試してみる予定。あと、できれば制御用のデータの仕様も知りたいけど、当然公開はされてないだろうから地道に探るしかないのかもしれない。せめて、フレーム長とパリティとかCRCとかがわかっていると楽なんだけどね。

CRC-CCITTの計算の高速化

2008-05-22T23:24:00.008+09:00

ずいぶん前の話だが、CRC-CCITTの計算という記事を書いて、とてつもなくシンプルなソースを出していたのだが、もう少し使えそうな方法として、テーブルを使って計算を高速化する方法を書いてみる。

そのときの記事のソースコードを見てもらえればおわかりになると思うが、計算されるCRCの値は、入力されたデーターのビットとXORして、その結果から多項式のビットとXORをしているというものである。
CRCの値は、XORの計算のみであるため、結合則（(A xor B) xor C = A xor (B xor C)）が成り立つので事前に計算しておくことができる。実際には、初期値0で8ビット分(0～0xFF)の多項式の計算しておき、その結果をテーブルに入れておいて、データーと現在のCRC値の下位8ビットからテーブルのインデックスを割り出し、その結果とCRC値の上位8bitを下位にシフトしたものとXORすればよい。

といった、説明をされても、ピンと来るとは到底思えないので、実際のコードをあげてみる。今回はJavaのクラスにしてみたが、Javaのjava.util.zipというパッケージの中にCRC32というクラスがある。ZIPの仕様はよく知らないのでわからないが、なんだかの初期値と多項式で32ビットのCRCを計算していると思われる。
このパッケージには、checksumというインターフェースがあるので、これを実装することにする。

import java.util.zip.Checksum;

/**
 * Compute CRC16(CRC-CCITT) for a data stream.
 * 
 * @author finky
 * @version 1.0
 * @see java.util.zip.Checksum
 */
public class CRC16 implements Checksum {
 static final int INITIAL_VALUE = 0xffff;
 static final int POLYNOMIAL = 0x8408;
 static final int table[] = new int[256];
 static {
  for (int i=0; i < 256; i++) {
   table[i] = calculate(i, 0);
  }
 }
 private int value;
 /**
  * Creates a new CRC16 object.
  */
 public CRC16() {
  value = INITIAL_VALUE;
 }
 /**
  * Calculate CRC16 for simple algorithm.
  * @param data effective 8bits.
  * @param value CRC value.
  * @return updated CRC16 value.
  */
 private static int calculate(int data, int value) {
  for (int i = 0; i < 8; i++) {
   boolean flag = ((value ^ data) & 0x0001) != 0;
   value >>= 1;
   if (flag) value ^= POLYNOMIAL;
   data >>= 1;
  }
  return value;
 }
 /**
  * Returns CRC16 value.
  * @see java.util.zip.Checksum#getValue()
  */
 public long getValue() {
  // TODO Auto-generated method stub
  return value;
 }

 /**
  * Resets CRC16 to initial value.
  * @see java.util.zip.Checksum#reset()
  */
 public void reset() {
  // TODO Auto-generated method stub
  value = INITIAL_VALUE;
 }

 /**
  * Updates checksum with specified array of bytes.
  * @see java.util.zip.Checksum#update(int)
  */
 public void update(int b) {
  // TODO Auto-generated method stub
  int index = (value ^ b) & 0x00ff;
  value = table[index] ^ (value >> 8);
 }

 /**
  * Updates CRC16 with specified array of bytes.
  * @see java.util.zip.Checksum#update(byte[], int, int)
  */
 public void update(byte[] b, int off, int len) {
  // TODO Auto-generated method stub
  for (int i = 0; i < len; i++) {
   update(b[off + i]);
  }
 }
}

javadoc用のコメントの一部が、JDKのドキュメントのパクリっぽくなっていますが、そのへんはご愛嬌ということでお願いしますw。サンプルソースのつもりなので、適当に使いまわしてもらってかまいませんが、確実に動作するか否かは保障できません（自分的にはちゃんと動いていると思うけど）。

すみません…

2007-04-18T14:02:00.000+09:00

完全に放置状態でした。言い訳ですが、Googleアカウントを作成してたら、旧BloggerのIDを忘れてしまいました(^^;)。やっと思い出して、Googleアカウントに変更しましたので、これで投稿ができます。

ファイル読み込みが出来上がる

2006-07-19T19:44:00.000+09:00

とりあえず、ファイルから読み込んでデータを取り出すところが完成しました。具体的に何をしていたのかは、こちらの記事をご覧ください(かなり見づらいですが^^;)。で、やっと本題に取りかかる訳ですが、SELCALはデュアルトーンなので、FFTで処理をしてみようかと思っています。実際にやってみてだめぽなら、別な方法でいきます。信号の長さが１秒もあるので、FFTでざっくり解析して比較してもそれほどCPUに負担はないのではないかと思っています。アクセラレータを使うので問題ないでしょう。詳細な仕様はまだなんにも考えていませんw。44.1kHzでもってくるので、最低でも2048のFFTが必要なことはわかっています。精度を考えるとその倍の4096かもしれません。あとは、HFなので振幅の変動を考慮したほうがよさそうだと思っています。どうするかというと、位相で比較するのはどうかと思ってはいるのですが、そうするとCPUに負荷がかかりそうなので、その辺は実験していくしかないのかと思っています。今日はとりあえず、進捗報告ということでこの辺で…

航空用のSELCALデコーダーを作ろうと思う

2006-07-08T08:27:00.000+09:00

前にちょっとだけ書いた航空用のSELCAL(ANNEX SELCAL)のデコーダーを作ってみようと思う。デコーダを作る時間がいっぱいあればいいのだが、そうもいかないくて、ここの書き込みもごぶさたしてしまっているのである。ANNEX SELCALは仕様が大体わかっているため、調査する時間がなくても作れそうなので、これにすることにした。

A:312.6 B:346.7 C:384.6 D:426.6 E:473.2 F:524.8 G:582.1 H:645.7

J:716.1 K:794.3 L:881 M:977.2 P:1083.9 Q:1202.3 R:1333.5 S:1479.1

出どこがどこだか、忘れてしまったが、前に調べた仕様では、次のような周波数がデュアルで、信号が送られる時間は１秒間となっている。まずはこの仕様で作ってみようかと思っていたのだが、ACARSと違って頻繁に受信できるものでもなさそうなので、いくつか実際に受信してサンプルを録音している。録音してそれをデコードするのはいいのだが、ファイルから読み込んでデコードするのをやったことがなかっため、そこから作らなくてはならないことになる。フォーマット変換があるので、ちょっと面倒ではまりモードになってきそうな感じになってきた。それができれば、一気にいきそうなのだが…。

余談だのだが、TOKYO RADIO（洋上管制）でなんか、やたらに声がかわいく聞こえるオペレーターがいるのだが、「OK♡」みないな話し方するひと… SSBだとそう聞こえるのか、マイクコンプレッサーのおかげなのか、地声がかわいいのかはわかりませんけど。ACCのほうも出てきているのかな？いかん、完全にヲタ化しておるorz

NRZIとソフトデコード

2006-05-16T13:36:00.000+09:00

過去記事「 VHF ACARSのデコード」で、ACARSのプロトコルがNRZI(Non Return to Zero Inverse)と書きました。よくよく考えてみるとNRZIというは、電線に電気が通るようなときに使う用語なような気がして、ソフトデコードでNRZIというのはおかしいのかな？という気もしましたが、ACARSはNRZIと同じように符号化されるということなのです。 NRZIは別に難しいものではないのですが、ACARSを例に書いてみようかと思います。 NRZIは、「I」がInverseを意味するように、信号が「１」のときに符号が反転し、「０」のときは符号が変わらないということです。これをFSKのデコードで話をすると、まず、周波数の高いほうをスペースといいここでは「B」、低いほうをマークといい、「Y」という記号とします。マークの信号の場合を「１」として、マークの信号が来たら符号が反転するとします。仮に「BBYYBYBB」という信号がきたとすると、そのままだと「00110100」ということになります。NRZIの場合は、「同同反反同反同同」（同＝変わらない、反＝反転）という意味になります。初期値が「０」であれば、「00100111」という結果になります。 ACARSを例にとるとACARSは最初のビットシンクをとるところは、ASCIIコードで「+」(2BH)「*」(2AH)が送られてきます。ビットは下位ビットから送出されるので、「1101010」「0101010」となりますが、パリティが「1」で固定なので、続けると「1101010101010101」となります。これをNRZIにすると「？同反反反反反反反反反反反反反反」（初期値を意識して最初は？とした）となります。実際には「BBYYYYYYYYYYYYYY」となります。さらにビットシンクよりの前の信号はスペース(「B」)なので、デコーダーとしては、「YYYYYYYYYYYYYY」(14個の「Y」）を待つことでビットシンクをするということになります。

HF ACARS(HFDL)のデコーダーを作ってみようかと考え中

2006-04-23T12:10:00.000+09:00

VHF ACARSのデコーダーすらまともに完成させていないのに他のものを作ってみるのもどうかと思うのではあるが、かなり気になっているので調査ぐらいはしてみようかと。 HFDLやHF ACARSでグーグルって見ると、ARINC 635と753というのがプロトコルで使われているようだ。これらの仕様書はARINCで販売されているがやたらに高い。

ACARS

山本無線ＣＱ秋葉原にあるアマチュア無線ショップアペックスラジオ AOR受信機、航空、気象受信関連商品販売

下位のレイヤーでは、SSB(USB)で1440HzでPSKで変調している。2PSK,4PSK,8PSKのモードがあり、1800、1200、600、300bpsの転送速度のモードがある。変調速度は1800ボーで固定である。ということらしい。変調速度とモードと転送速度が違っているように思えるかもしれないが、おそらくFEC(Forward Error Correction)をつかっているのであろう。FECはSITORでも使われている方法。これだけの情報だとどうにもなりそうにない。PSKのデコーダまでか、遅延のシンボル数がわかればFECまでぐらいかもしれない。あとは、PC-HFDLとかをなめるように使ってみて何をやっているか探るとかしかないのか？やるとすれば、まず1440Hzで8PSKのデコードをするモジュールから作るしかない。ビットまで拾えればなんとかなるかもしれないが、いずれにしろ試行錯誤になるのは間違えなさそうだ。

ACARS HFDL

ソフトデコーダーでいろいろ受信してみる（２）

2006-04-21T13:55:00.001+09:00

前回は船舶系で終わってしまったので、今回は航空系です。

ACARS

Kinetic Avionic SBS-1 SSR(二次監視レーダー)の受信アペックスラジオ AOR受信機、航空、気象受信関連商品販売

航空系だと最もメジャーなのがVHF ACARSではないでしょうか。デコーダーもWACARSをはじめ、有償なものまでいろいろあります。日本国内では周波数は、131.45MHzがメインで、他に131.25MHzと131.95MHzがあります。131.95MHzは最近運用が始まったのですが、東京や大阪などの過密地帯向けに運用されているようです。東京では比較的よく受信できますが、通信頻度は高くありません。あとは、HF ACARSといわれているHFDLというのがあります。名称通りHF（短波）で通信されているもので、現状ではデコードできるのは、PC-HFDLというソフトぐらいはないでしょうか。HFという電波の性格上、近くでも受信できなかったり、遠くの飛行機のデータが受信できたりということがあります。

SELCAL

SELCALというと、航空系と船舶系と両方あります。航空系は、プロトコルからANNEX SELCALといわれることもあります。このSELCALは、航空機側から管制へ自機の識別のため送信されるもので、通常はHFの管制（洋上管制）の音声通信で使われているものです。AirNavという有償のソフトウエアでデコードできます。その他にもあるようですが、特に有名なものはないようです。

SELCALはいわゆるデュアルトーン（２つの音を同時に出す、DTMLともいえる）で２回送るだけで、データー通信とはいえるかどうかはわかりません（しかし、作成は試みたことはないですが、デコードは意外に難しいかもしれません）。

こんなところでしょうか、航空系は船舶系よりもあまりデータ通信が多くないと思えるのですが、航空機からの電波は陸でよく受信できるということもあり、趣味とされている方も多いようです。

デコーダー航空無線

ソフトデコーダーでいろいろ受信してみる

2006-04-19T10:10:00.001+09:00

ソフトモデムを使って通信するのはアマチュア無線ではかなりあります。CWに始まり、RTTYやパケットなどのFSKやPSK31などのPSK、SSTVもあります。最近ではデジタル通信として、PSKの多重（直交なのか？）を使ったものもあります。アマチュア無線は開局してないと楽しめませんし、HFだとアンテナもそれなりのものが必要でしょう。

とりあえず、お手軽なところで受信だけで楽しめるのは何があるかというと、船舶か航空系になってしまうと思います。VHFやUHFのデジタル系の受信はソフトデコーダーでは、おそらく無理ですから。

船舶系FSK

山本無線ＣＱアマチュア無線、ハンディGPS製品などの販売パソコンGPSショップ GPS関連商品専門店

船舶でいわゆるRTTYでの通信はあまり多くないと思います。おそらくSITOR-Aといわれる形式(100ボー180Hzシフト）が多いのではないでしょうか。通報であるNAVTEXはSITOR-Bで同じく100ボー180Hzシフトです。これらはRTTYとエンコードの形式が違うため、RTTYのデコーダーではデコードできません。NAVTEXはデコードできるソフトがいくつかありますが、SITOR-Aの場合、ビットで同期するので、NAVTEXのデコーダーではデコードできないかもしれません。 NAVTEXは、基本的に518kHzか424kHzでSSBで受信するので、それなりの受信機とアンテナが必要です。アメリカではHFでも送信されていますので、ハワイかグアムからの通報は受信できます。

気象FAX

HFでのFAXの受信は、気象FAXが最も受信しやすいと思います。日本では気象庁が船舶向けにFAXを送っています。詳しくは、同サイトのトップの下のほうに「気象資料の閲覧・入手方法」というリンクがありますので参照してください。日本以外には、韓国、中国、台湾などが受信しやすいと思います。

気象FAXという意味では、NOAAの衛星からの画像受信があります。こちらはVHFですが、FMでIFのバンド幅が広いものが必要となり、ちょっと特殊な受信機が必要になります。あとこれらの衛星は、地上からみて静止しているのではなく、１日に２回ぐらい上空を横切ります（南北方向なので縦切り？w）。そのため高い所からの受信となるため、GPやディスコーンなどのアンテナだとうまく受信できない場合があります（この手の垂直なアンテナは真上からの電波は得意でない）。気象衛星用のデコーダもフリーなものも含めていくつかあります。受信機やアンテナなどいろいろ条件が厳しいのではまり度が高いのではないでしょうか。

今日のところは...続きはまた書きます。

CRC-CCITTの計算

2006-04-16T15:20:00.003+09:00

モデム等の通信で多く使われているエラーチェックアルゴリズムとしてCRC(巡回冗長検査)があります。このアルゴリズムは、ハード的に比較的簡単なロジックで実現できて、検出能力も比較的高いためよく使われているようです。 CRCの原理については、面倒なのでここでは書きませんw。グーグルってもらえれば、詳しく解説されています。
CRC-CCITTは、CCITTで規格化されたCRCということになります。CCITTは現在ではITUという団体に変わっています。CRCのアルゴリズムを使って何を規格化したかというと、CRCの計算のパラメタとなる、「ビット長」「多項式(polynominal)」「初期値」「ビットを送る方向」ということになります。
CRC-CCITTでは、ビット長は16bit、多項式は1+X^5+X^12+X^16、初期値はFFFF、送りはLSB First（右送り）となります(LSB Firstはプロトコルに依存するかも)。ただし、プロトコルによっては初期値が違う場合もあるようです。
実装コードは、テーブルを使って高速化したもの等が検索するといくつかあるようですが、すなおに簡単なコードで書くと、以下のようになります。

static unsigned short _crcValue=0xFFFF;
static unsigned short _polynomial=0x8408;

unsigned short crcCalc(unsigned char data)
{
 for(unsigned i=0;i<8;i++){
  bool flag=((_crcValue^data)&0x0001)!=0;
  _crcValue>>=1;
  if(flag) _crcValue^=_polynomial;
  data>>=1;
 }
 return _crcValue;
}

１回計算すると_crcValueが変わるかもしれないので、0xFFFFで初期化してから計算するようにします。チェックするデータを順にパラメタにいれて関数を呼び出します。戻り値にCRCの値を返してますが必要なのは最後だけです(0xFFFFになっている）。
実装するときにはもっと賢いコードに書き換えてくださいねw。

WACARSのデコード

2006-04-12T10:25:00.001+09:00

WACARSと自前デコーダーとでデコード能力を比較しているので、WACARSの「くせ」がある程度わかってきたので書いてみます。

IFのバンド幅による影響

Kinetic Avionic SBS-1 SSR(二次監視レーダー)の受信鳳文書林出版販売航空図、航空関連書籍販売

通常のAMの場合、6kHzのバンド幅になっている受信機がほとんどですが、6kHzの場合2400Hzの信号がやや減衰されます。どのくらい落ちるかは受信機によって異なりますが、一般的に考えると減衰するほうがよい受信機であるともいえます。WACARSでデコードする場合、1200Hzとの振幅の差が大きいと失敗しやすくなりますが、極端に悪くなることはなさそうです。おそらく、他の条件（S/Nの悪化）などが重なると影響が大きくなる傾向があるようです。

振幅の変動

ACARSはVHFなのでHFの様に信号が強弱することは基本的にはなく、ましては信号を送る時間が長くても２秒ぐらいなので、受信信号の強さが変動することは、ほぼないと思われます。

受信機によってはAGCが効くため、復調された信号の最初のほうに振幅が安定しないところが現れます。WACARSの場合、どうやらFrame Syncまでの間に振幅が変動すると失敗しやすくなる傾向があるようです。AGCの効きかたが（時間軸に対して）緩やかなだと、このような状態になるものだと思われます。

ノイズ

あえて悪い環境として、ハンディ機でPCから１mぐらい離して、付属のアンテナで受信してみると、WACARSもかなりデコードできません。波形レベルでみると弱い信号はかなり歪んで、デコードできる感じがしません。耳で聞いた感じでは信号がきているのはわかるのではあるのですが。

おそらく、ノイズが多いとIFのバンド幅などの影響が大きくなるようです。これはWACARSというよりもデコーダーでは一般的なことになります。

振幅の大きさ

要はボリューム調整のことです。受信する信号によって復調した信号の大きさ（音の大きさ）が変わりますが、特にハンディ機などでAGCが効いてない場合、その差が大きくなります。

上記の悪条件をなるべく除いてWACARSでデコードした場合、レベルインジケーターが右のほうに（大きめに）しても左にほうにしても違いはありませんでした。おそらく、条件が悪い信号をデコードするときにボリュームがあのインジケーターの真ん中にくるほうがよいという意図なのかもしれません。

終わりに

WACARSは、受信側の条件が整えば、デコード能力は低くありません。波形が多少歪んでいてもちゃんとデコードします。そういう意味ではWACARSと同等な能力を持つデコーダーを作るは簡単ではないようです。

ビットシンク

2006-04-10T21:03:00.000+09:00

ビットシンク（正しくはBit Frame SyncかSymbol Frame Syncかも）は、変調された信号を変調速度に合わせて（同期）１か０（多値の場合には１以外もあるが）を検出することである。これをソフトウエアで実装するのはどうすればいいのかということが書いてある文章がほとんど見つからなかったのだが、ハードウエア的にはだいたい次のようになるらしい。まずは、信号処理で比較をして、結果が１か０になる（デジタル的になる）。０→１もしくは１→０のタイミングを検出して、そこから変調速度に合わせたクロックと同期をさせる。場合によっては、０→１と１→０の両方（順番はどちらでもよい）を検出してから同期を取る場合もあるらしい。同期が開始されると、クロックが上がるときもしくは下がるときに１か０かどちらかであるかをチェックする。ただし、信号処理でどちらかともつかない信号が来た場合には、同期を中断して最初の状態になり１か０から状態が変わるのを待つようにする。といった感じになるようだ、ソフトウエアでもおおかた同じようにすればよさそうである。ただ、このままだと最初の信号が不安定な時は同期に失敗するので、パケットのように最初のピットパターンだけで同期を取るような場合には、もうちょっと工夫しないと、デコードの能力はあまり高くならないかもしれない。

デコーダー/同期