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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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