【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。
コテハン推奨。
前スレ
【C4FM】デジタル信号復調【π/4DQPSK】
http://mint.2ch.net/test/read.cgi/radio/1434951910/ >>920
MPU側の解析は進んでいません...特に録音再生部分のことだと思いますが、記録しているメモリ領域が分かっていません...
DSP側のメモリ空間で記録しているのかもしれません
手作業無しで自動化となると、今のところの最短ルートはJTAG-ICE経由になろうかと思います
>>923
メリット5とのことなので、当面テーブルと順序はいじらずに固定したいと思います
ありがとうございます >>925
普段は閑古鳥なのに、突然ワザとらしくそれも頻繁にスレへ書き込み始めたからじゃないの??
知らんけど 大変おつかれさまです
>>926
^です
メールしました(121)、よろしくお願いします >>929
了解しました
内容に関してはちょっと時間をかけて検討させて下さい... うおお!ついに音声デコード!おめでとうございます。 >>931
聞けてもあんま役に立たない通話だろうけどな つまりは800MHz帯デジタルMCAのコーデックはM-CELPで正解だったのか! アナログ時代でもAVMシステムで出動、現場着、帰署の連絡はナビの
タッチパネルをタッチするだけで音声通話はいらない
消防、救急波のデジタル化は無線の中でも遅かった。だけど携帯電話
のデジタル化は早かったので傍受対策や個人情報取り扱いの関係も
あって「携帯電話を開局せよ!」といった通話をアナログ消防無線で聞く
ことが2000年頃から増えた。
現在の消防無線はデジタルで傍受できないけどデジタル消防無線機が
ハンディ機でも重く大きく、現場で使いにくいからスマホで本部と連絡する
光景を火災現場で見かける。
携帯電話が使えない大災害になれば無線通話は増えそう。 音声がデコード出来た事によって、動態は判明しずらくとも団体コード・出場種別等々は色々判明するんじゃないかな?と思うので、通話量が少なくなっても音声がデコード出来た事は相当大きいと思うぞ RLが団体コードを一覧にしてまとめてくれると良いのだがね。 ちょっと複雑になってきたので、ここまでのTCH(voice)のデータ処理の手順を整理して教えていただけますか?gnuradioから生データを取得した時点から音声デコードへ至る過程の処理を詳しく教えて欲しいです。 いくらなんでもその言い方は酷くないですか?
技術的興味を持っちゃいけないんですか? 変なレスはnullですよ、フィルタ処理しましょうw
ともあれ今は生データ取得から誤り訂正等々の信号処理→TCHからvoice部分を切り出し→MCA機のビットフォーマットにあわせたビット位置変更→コーデックへ入力→μ-law出力(音声化)という一連の流れを手作業でやっているみたいだからなかなか大変だと思います。
特に数秒の音声でもバイナリ化されたデータを収集・編集して纏めるのは結構な苦労だったんではないでしょうか。お疲れ様でした。
是非>>921さんがデコードした音声聞いてみたいです。
なかなか難しいと思いますが、いつかリアルタイムでデコード出来るようになるといいですね。 >>929
CCSのユーザーズマニュアル(jaju020.pdf)を見ているだけなのですが、次の手順で入出力がある程度自動化できそうな気がします
(『4.4 プローブポイント』と『5.1ファイル入出力(I/O)』を参照)
まず、メインファンクションとして以下のものを作ります
(1) 初期化ファンクションを呼ぶ
(2) (ここにプローブポイント1を設定)
(3) デコードファンクションを呼ぶ
(4) (ここにプローブポイント2を設定)
(5) (2)へジャンプ(無限ループ)
プローブポイント1では、入力バッファに対して読み出したファイル内容を指定ワード数分ずつ書き込みます
プローブポイント2では、出力バッファから指定ワード数を出力ファイルに追記します
入力ファイルの終わりで実行を止めるように設定すればOKに思えます
あと、まだ入出力ファイルの加工が必要ですが、これは調査中です... >>939
手順として洗練されるまでもうしばらくお待ちください... お疲れさまです
>>882
>>945
併用でとても楽になりそうです。
入力側の応用は思いつきませんでした
鼻づまり感の雑感で毎回初期化すべきか
悩んでいました >>949
独り言ですが破声音や鼻濁音(連続パルス)の
mca実機はどんな感じ?と思ってます >>947
ええ、すでにデジタルMCAの実機持ってますよ >>949
音質の問題ですが、>>905をベースとして、
12, 13, 14, 15, 16, 17, 43, 44,
を
44, 12, 13, 14, 15, 16, 17, 43,
に、
51, 52, 53, 54, 126,
を
54, 51, 52, 53, 126,
に変えて試してみていただけないでしょうか... うそをうそとみぬけないひとはこのけいじばんをつかうのはむずかしいとおもいますね >>953
Ubuntu入れてますが。
それ位のスレの流れはちゃんとやってますよ。 残念ながらM-CELPと改良型RL-CELPは別物だから、どうにかして改良型RL-CELPを積んだ実機をどこかで確保して解析しないとダメなんだよ。 夜間留め置きの電車から無線機盗んだとかたまにあるけど、だめだぞ。 デジタルラジオマイクもこのスレの範疇?
2.4Gは無理かもしれないけど1.2とWS帯は研究しがいがあるのかな うそをうそとみぬけないひとはこのけいじばんをつかうのはむずかしい >>962
その気になれば実機を買えるし、いいネタだね。 >>951
>>956
もはや、お前に教えることは何もない。 おつかれさまです。
>>952
>>919と変わらない感じでした・・自分の処理間違いかもしれません >>967
お手数をおかけして申し訳ないです...
並べ替えをする前のビット列のうち、No Error保証された84ビットは、
(0-11) 前半フレーム, サブフレーム1:6bit+サブフレーム2:6bit
(12-17) 後半フレーム, サブフレーム3:6bit
(18-24) LSP.7bit
(25-42) 前半フレーム, サブフレーム1:8bit+サブフレーム2:10bit
(43-60) 後半フレーム, サブフレーム3:8bit+サブフレーム4:10bit
(61-65) LSP,5bit
(66-71) 前半フレーム,サブフレーム1:6bit
(72-83) 後半フレーム, サブフレーム3:6bit+サブフレーム4:6bit
残りのエラー訂正無しの部分の54bitは、
(84-91) LSP, 8bit
(92-114) 前半フレーム, サブフレーム1:11bit+サブフレーム2:12bit
(115-137)後半フレーム,サブフレーム3:11bit+サブフレーム4:12bit
とのフィールド分けを統計的に求めまして、>>905はこれをMCAのM-CELPのフィールド構成に想像で割り当てたものです
各フィールド内のビット列の順番は順不同の可能性ありと思い、お手数をかけていただいた次第です
こちらでも精査できるように引き続き準備を進めたいと思います... >971
おじいちゃん、かわいそうにボケたのね。。
わかりやすく浮上しないのよ。。 ところで、今般のM-CELPの解析で大元である800MHz帯デジタルMCAについても音声デコードできたりしそうですか?
>>577の通り毎通信のたびにスクランブルが異なるそうなのでハードルは高いかとは思いますが汗 ホントにそれ消防のSCPCで使われてるM-SELPなん?? デジタルMCA機から抽出したコーデックによって概ねの内容が理解できる音声としてデコードに成功したんだから、F-CHのM-CELPと同じで正解じゃないのかなと。
>>116の通りSCPC/F-CHとデジタルMCAのフレーム規格が相似してる事から鑑みても納得じゃないですかね >>968
ありがとうございます、お手数おかけします。
今いちど連絡しました。 >>978
確認しました
おっしゃる通り、>>905のままが今のところ最良だと自分も思います >>975
総当たりでも確か32767通りのはずですので、リアルタイムで無くて良いのなら可能だと思います >958
三菱単独ではなく下請へ出していれば末端の孫請からの流出に期待するしか無さそうだな
あるいは一応車載機だけではなく受令機もあるから故障した受令機の流出とか >>980
総当たりとなるとさすがにリアルタイムデコードは厳しいんですね、でも不可能ではないというのはワクワクします。
いつかデジタルMCAの通信も聞いてみたいです >>981
元JRの関係者なのですが、東に関して言えば、アナログ時代と比べて今のD機は受令機も含めて厳重管理なので、まず"おこぼれ"は期待出来ないかもしれません。廃棄に関してもアナログ機ですらハンマー入れを徹底してましたんで。
ただ今後改良型RL-CELPを搭載した列車無線システムはJR以外の各民鉄への波及が見込まれている(すでに採用・運用してる所もある)ので、あとはその民鉄関連からの"おこぼれ"を期待するしかないですかね。 文句言う人がちらほらいますが解析されてる方は気にせず書き込んでほしい! 高速のEL-CELPも実機がやはり確保出来ないと解析は難しそうだな
ただ本四高速とかはなぜかFSK使ってて聞けるが
タクシーでもQPSKの方は似たようなの使ってたか? 高速も鉄道も行政系も全部TETRAかFSKで十分だろ
地デジのBカスといいガラパゴスの糞システムなんてメーカーと総務省のオナニーでしかない
>983
警察や消防とかでも当然不要な機器をボカスカやってそうだな
不要な携帯破壊する時もだが基盤割るだけでなくチップを一撃必殺で粉砕しないとチップだけ生贄で取られたらそこから解析されそうだな >>987
Motoのtetra使え〜って花札大統領に圧力かけてもらうしかないな、かつての携帯電話方式のようにね。 ETCだって、導入当初は世界で最高峰のシステムだったな
情報提供とか駐車料金決済とかいろいろな日本独自の機能が盛り込まれた 受信機メーカーが一転して官公庁御用達メーカーになったんだからwinwinの関係というやつだな。 おつかれさまです
>>979
バグがどこにあるか見つけられない(位相がひっくり返る)状況ですが
テスト信号を折り返してみました(PWは以前とおなじ)
ttp://whitecats.dip.jp/up/download/1561048483/attach/1561048483.zip
とりあえず>889の様子を見たいと思います >>989
高速道路の決済以外の機能は使われなかったけどなw
時速180km/hでも通信可能なエアインターフェースだったけど、そんなの使える道路は日本にはないw アナログのままで十分なんだよ。だからIP無線にしろって言う話が広がるんだよ
狭帯域デジタルのメリットなんてねえんだから >>991
ほんのちょっとポツポツがある以外はほぼ同じでメリット5じゃないですか!すげえ >>991
いい感じですね。位相が反転するのは「そんなもの」な気もしますが...
こちらも何とか環境が整って、変換しているところなのですが、どうも最大音量付近に問題がありそうです
ゲインコードブックのマッピングミスがありそうな感じです
あと、古いPCなので変換が遅いです(42秒ぶんの変換に768秒かかりました)
これは、謹製コンバータのバグを取る方向で解決したいです... >>996
ご評価ありがとうございます
ぶつ音の件で今いちどご連絡さしあげました
ご指導お願い申し上げます。 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 869日 10時間 8分 6秒 レス数が1000を超えています。これ以上書き込みはできません。