【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。
コテハン推奨。
前スレ
【C4FM】デジタル信号復調【π/4DQPSK】
http://mint.2ch.net/test/read.cgi/radio/1434951910/ >>847
4台なら安いもんじゃない?
俺、これぐらいで普通に買えるなら喜んで出すよ。
これ、研究以外の人が落とせたとして、お住まいの地域の周波数は書き込めるんだろうか。 どうせもうリモートでロックかけられてて起動すらせん状態だろうけど
下手すればi社とかM社とかの息の掛かった人間が落札して技術が漏れないように処理されるかもしれない
できれば"デコードするために頑張っている人間"の手に渡って欲しいもんだ >>852
ほんとだ、赤枠のやつだけだね。
>>851
受令機はそんな機能無いんじゃない? 落札して解析してる人に渡したいけど先立つものがねえ... 10万超えてるし、いたずらor関係者の妨害入札が混ざってきた感じ?解析班が入手して本気出すなら支援しても良い。 これデジタル消防の受令機なの?
特小のジャンクにしか見えない >>855
関係者ならヤフーに連絡してオークション自体中止にできるんじゃないかな
まあ、自治体単位だからどこから流出したかもわからず
親切に手を打つところがないとこのままだろうけど…
落札阻止するなら総務省に通報かな? >>857
出品者は具体的なの事は何も書いていない。
写真と思わせぶりな最低価格で周りが勝手に祭りにしている。
外装だけで中身カラッポだったら面白いがw >>856
モニタの周りが赤いやつね。
阻止とか野暮な事は止めよう。
巡り巡って何か有益な事になるかも。
つか、流出が始まった事が確認出来ただけでも有益だ。いつか縁があるかもしれんしね。
どう動くか、騒がずに見守ろうや。 ジャンクだからねえ・・・
開封して完全にぶっ壊されている可能性もあるし まぁ…今度は本当に静かに騒がず見守りましょう。ここで誰かが騒ぐと、また聞ける日が遠ざかってしまう、、
これを解読班の方々が是非落札して、パソコン1台で復調される日を、皆様で待ちましょう。 >>845
遅くなりました、レスありがとうございます。
PAGE2,3と同じものができました(素人なので単にパラメータ不足でした…)。
PAGE1の未開示コードは本体と関係ありでしょうか・・
※基板への流し込みは継続検討です。
別件ですが、当地の状況からtype=84は「調査」のようでした。 >>866
全然作業が進んでいなくて、フォロー出来ずにすみません...(公私共にトラブってまして...ぎっくり腰とか)
PAGE1はデータ専用領域なので、データとして固定コードブックなどが入っているはずです
(質問の意図を読み間違えている気もします すみません)
あとtype=84の件ありがとうございます 参考にさせていただきます 保守。
久しぶりにTFDの方面波聞きたいわ〜
TDMAかつAMBE仕様の方面波の音声デコードを報じたRLの記事から、かれこれ幾歳月経ったけどあれから続報も無くてね、gnuradioとかで試してみたいから少しはヒントでも欲しかったんだけどなぁ。
あの記事はSDR#からパイプしてるから凄えなぁと感心してたけど、雑駁な概要しかわからなくて
SCPCがコーデックの絡みでムリでもTDMAは何とか頑張ってデコードしてみたい。
だれかTCHとかのフレーム構成とかヒントをお持ちでしたら、教えて下さいませ。 >>867
ご無沙汰しております。
とうとうちょっとだけコードが呼べたので(メモリが足りず全部は無理)
謎のc7cfをやってみました。リロケート環境なので間違っていると思いますが
参考に報告します。6b06~6B0f(6b10からも同じ)
→f838,cdbb,09da,1201,1ae3,2425,2d0b,3611,3f2d,485d
何なのかはさっぱり??です。 >>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
併用でとても楽になりそうです。
入力側の応用は思いつきませんでした
鼻づまり感の雑感で毎回初期化すべきか
悩んでいました レス数が900を超えています。1000を超えると表示できなくなるよ。