【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。
コテハン推奨。
前スレ
【C4FM】デジタル信号復調【π/4DQPSK】
http://mint.2ch.net/test/read.cgi/radio/1434951910/ >>872
ありがとうございます
とは言っても、自分もさっぱり?なので、今後検証したいとおもいますです... 関東以外の私鉄もいずれ安価なFSKでデジタル化する所が増えてくるだろうけどその一方で新スプリアス対応の新型のアナログで設備更新する事業者もかなりあるな。 >>872
ご無沙汰しております。どうかよろしくお願いします。
自分のXp環境を辿ってこれを発見しました。
ttp://whitecats.dip.jp/up/download/1556203119/attach/1556203119.zip
パスワードは549様に合わせました。
(今はフリーのようですが、連休明けに下げます)。
ボードと同じ答えが出ましたので、ご検証いただければ思います。
どうかよろしくお願いします。 大変ご無沙汰しております...
>>876
白猫さんが行方不明みたいですので、代わりに本家の場所を置いておきます
ttp://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/CCSv3/CCS_3_3/exports/CCS_3.3.83.20_Platinum.zip
これは本家のサポート掲示板(ttps://e2e.ti.com/support/tools/ccs/f/81/t/580754)に書かれているものなので、個人的には秘密でも何でもないと思っておりますです... 前スレ549様
大変ご無沙汰しております。
>>877
ご配慮ありがとうございました。
>>825
MSM7717-02の+0ぽいのが出ました。
手作業なのでその先は分かりません。。
自分には作れないので恐縮なのですが
603.cの8ビットシリアル出力版的なものを
ひょっとしてお持ちではないでしょうか。 >>879
さらに力業でやってみました。596様は神です。
>>808
この通りだと思いました。時間幅が広くて自分には無理そうです。 (誤)>>808
(正)>>809 です、失礼しました >>879
おつかれさまです
音声デコードに初成功ですね!
603.cの音声部分のみの出力ですと、ワンライナーでは
cat hoge.bin | 101 | 603 | grep VOICE | awk -F ' -> ' '{ print $2 }' | sed 's/ //g' > hoge.hex
とか書いています
これで空行を含んだ16進表記テキストが出来ますので、これを xxdコマンドを使ってバイナリに戻します
xxd -r -p hoge.hex hoge.mcelp
こんな感じでやってます
もちろんパイプで繋いで一発バイナリ化も可能です
>>880
ここまで来ておいて何なんですが、あのテーブルはまだ完全ではなさそうな気がしています... おい!ポコチン!ハンネ出せなくなったのにまだいるのかよ! >>882
少しずつですが前進しているようですね。期待しています!! >>882
大変おつかれさまです、まだ全然だめです
間違った合成の機械音ですので、色々ご指摘ください
ttp://whitecats.dip.jp/up/download/1558421635/attach/1558421635.zip
PASSは以前と同じです
<<486の前後戻しをしないで強行してもそれなりではと思い
603に>>793を適用して>>564を140回単純繰り返しました
ノイズなくデジタルぽい音色の有無が分かる程度です
部分的にレベル破綻したので、共通データの共用は必要みたいです
音節の引っ張りが長続きしないので、時間インタリーブ的なものか
係数の関係で違う波形になったのか・・ここらが不明です
エンコードがうまく行ったら統計を取ってみようと思います あらあら暖かくなったからかな?
玄人気取り虫が湧いて出てきたわい >>885
頂きました。が、Windows標準のメディアプレイヤーでは再生できませんでした...
で、ここまでの調査経過といくつか情報をまとめておきます...
・M-CELPは1フレームあたり139ビットで構成される
・138ビットが実パラメータで、1ビットはフレームパリティ
・1フレームは40ms相当で、10msサブフレームが4つ
・138ビットは、(1+7+6+6)+(8+16+7)+(5+16+7)+(8+16+7)+(5+16+7)に分割される
・(1+7+6+6)はLSP(線スペクトル係数パラメータ)
・(8+16+7)と(5+16+7)はサブフレーム情報(各々10ms)
・第1,3サブフレームの8はピッチディレイ(=適応コードブックインデックス)(≒周波数情報)
・第2,4サブフレームの5は第1,3サブフレームのピッチディレイの整数部分からの差分値
・第1〜4サブフレームの16は代数コードブック(=固定コードブック)インデックス
・第1〜4サブフレームの7はゲインコードブックインデックス
・これによく似たデータ構造を持っているのが、AMR-NBの10.2kbpsモード
・処理全体としては、CS-ACELP(ITU-T G.729)に酷似している
CS-ACELPもAMRも文献やソースコードが公開されているので、取り寄せて比較調査中です... >>885
失礼しました。u-law形式は開けないことを忘れてました。
PCM形式で再アップしました。つまらないですが。
ttp://whitecats.dip.jp/up/download/1558525910/attach/1558525910.zip
訳は分かりませんがエンコード部を構築中(残り半分くらい)です。 pokoちゃんかる〜く擁護されちゃって
ファンがいるんやねw >>896
G1EとpokoはRLの一件からスレにでれなくなったんだよ。
知りたきゃ過去スレ漁れ!!通りすがりからは以上です! スレ汚すなと言われてるけど、反応してすいません。
過去スレからずっと見てきてるんですけど、それあなたの妄想じゃありませんか?RLのTFDの記事を言ってるんでしょうが、両氏が関係者だなんて私にはさっぱりそう見えないんですけど。個人的に気に入らないから両氏を排他したいだけに見えるんですよ。違いますか?
仮にコテ外して現れてるとしても、挙がって来る情報から有益をもたらしているのであれば、それはそれでいいんじゃないですか?ここは技術の共有と成果を拓くためのスレですよね? 気持ちはわかるけど、エサ与えてるだけだから反応しちゃダメ!堪えろ!
>>899
もう来んな 擁護にあたるようなことが書かれれば書かれるほど
pokoにゃんとG1Eの香ばさが増すからやめれ 苦労して解読できても音声通話は少ない
本部から○○指揮1
○○指揮1ですどうぞ
スマホ開局せよ
スマホ開局了解 大変ご無沙汰しております...
>>885
>>793の代わりの配列をもう一つ作ってみました
603.cの1090行目が"#if 0"の、逆順表示用です
評価していただければ有難いです...
{
/* LSP */
18, 19, 20, 61, 62, 63, 64, 65,
84, 85, 21, 22, 23, 24,
86, 87, 88, 89, 90, 91,
/* 1st half */
66, 67, 68, 69, 70, 71, 25, 26,
27, 28, 29, 92, 93, 94, 30, 95, 96, 97, 98, 99, 100, 101, 102, 31,
0, 32, 1, 2, 3, 4, 5,
33, 34, 35, 36, 103,
37, 38, 39, 104, 105, 106, 40, 107, 108, 109, 110, 111, 112, 113, 114, 41,
6, 42, 7, 8, 9, 10, 11,
/* 2nd half */
12, 13, 14, 15, 16, 17, 43, 44,
45, 46, 47, 115, 116, 117, 48, 118, 119, 120, 121, 122, 123, 124, 125, 49,
72, 50, 73, 74, 75, 76, 77,
51, 52, 53, 54, 126,
55, 56, 57, 127, 128, 129, 58, 130, 131, 132, 133, 134, 135, 136, 137, 59,
78, 60, 79, 80, 81, 82, 83
};
(これは無音→有音と有音→無音の遷移の際のビットパターンから求めたものです) >>905
一部意味不明になってしまったので追記します
逆順表示は未公開だったようです...すみません
逆順表示にするには、1090行目あたりを、
for (i = 5; i < 89; i++) celp_mca[j++] = deconvo_result[i];
for (i = 101; i < 155; i++) celp_mca[j++] = deconvo_result[i];
から、
for (i = 88; i > 4; i--) celp_mca[j++] = deconvo_result[i];
for(i = 154; i > 100; i--) celp_mca[j++] = deconvo_result[i];
に(for文のカッコの中身を)置き換えてください ご無沙汰しております
>>905
大変おつかれさまです
前回のデータは603.cの書き換えを1か所していませんでしたので
4通り(>>793、>>905 それぞれでif0、if1)試してみました
ttp://whitecats.dip.jp/up/download/1560191198/attach/1560191198.zip
793のif1と905のif0が歪が少なく、いい感じですが言葉になってません
※フレーム間インターリブの想定は試せていません
encoderは暴走(intmで何処かに飛ぶ)がようやく収まった感じですが
decoder折り返しでまともな音にならず、先に進めていません
全体的に勘違いが多くてdecoderも動いていないだけかもしれません… これじゃ私信じゃねーか
もうスレじゃなくてどっちかが捨てアド出してやれよ ダメなの?別によくないか?
俺はこのスレの展開をいつも楽しみにしてるから、進展が見れて嬉しいぞよ。 >>908
このスレの本質や意味が解らないなら静かに見てて。 >912
お前>908とはまた違うアホだなw
有益なことの共有?んならお前んち定期的に解放して自称技術者オフでもやってやれよw わかる人が判ればそれでいいんだよ。
わからない馬鹿は黙ってろ ?FT-3D買おうと思うんだが私設BTノードって作れるようになったんか >>914
馬鹿なレスは >/dev/null で。 >>907
デコード結果はとてもいい感じの音に聞こえます...ソースは自動音声でしょうか
なんとなく音声として聞き取れそうなところが悔しいですね...
>>905のテーブルですが、どうやら部分的にビットローテートが必要なようです
66, 67, 68, 69, 70, 71, 25, 26,
を
67, 68, 69, 70, 71, 25, 26, 66,
に、
33, 34, 35, 36, 103,
を
34, 35, 36, 33, 103,
にすると数値の見た目的なバランスが良くなるのですが、試していただけないでしょうか... >>919
付け足しですが、603.cだとテーブルを使っていないので、外部で変換するなどしてください... 前スレ549様、大変お疲れ様です
>>919
ありがとうございます、試してみます
ところで、これまでのレスを総復習して、暴走するencoder出力を参考に
603.cの>>905(if0)+1114行あたりの数行を一段階処理(古風なやまのやつ)
すると、結構(かなり)◎的と分かりました→活きた人ではなかったですが
「数字2桁(肉の間にじゅう)、○○○○○○○○センター」でした
※○は漢字1文字
>>793のif1も試してみて、>>919も適用して、また報告します
ちなみに、>>757の連絡先はまだ運用OKでしょうか? >>919
ひょっとすると類似の操作かもしれません
>>920
ありがとうございます、今のところ603改で内装できましたが
今のままではアップしたサンプルの作成でデータ処理+CCS手載せ+mu-law
変換の手作業で1時間以上かかってしまいます。
>>882は試せてないのですが、MCAジャンク活用も視野にいれながら
何とか自動化したいです ちなみに、MPU解析は進んでおられるでしょうか? >>919
やってみました
905if0(M5-)>>793if1(M3)>919if0(M3-~2+)
他はM1(既出)という感じです
M5-の-は、時々ピーククリップがある位ですので
処理的にはほぼこれかなーと思います >>921
おつかれさまです
音声になりましたか。おめでとうございます!
ところで...
> 1114行あたりの数行を一段階処理(古風なやまのやつ)
これはいったい...?
ちなみに、 >>757 >>759 はまだ生きているようです(今ログインできました) >>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
おじいちゃん、かわいそうにボケたのね。。
わかりやすく浮上しないのよ。。 レス数が950を超えています。1000を超えると書き込みができなくなります。