【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。
コテハン推奨。
前スレ
【C4FM】デジタル信号復調【π/4DQPSK】
http://mint.2ch.net/test/read.cgi/radio/1434951910/ ん?141ですが、別のところで何もしてないですよ?
私鉄のデジタル列車無線もARIB規格に準拠してるんだろうけど、そこらへんどうなんだろうかな?と疑問を持っただけです。
小田急・京急・千葉モノ・TX・箱根登山と、色々仕様がありそうですが、いかんせんちょっと遠方住まいなので、それでもいずれ現地へ行って軽く目を通したらわかるかなとは思いますがコーデックはパッとわかりませんし汗
いずれにせよ142さんすいません、場を濁したようなのでこのスレから引っ込みます。 全然良くね
142が何考えてるか知らないがここは適切なスレだと思うよ
自分はSHUREのπ/4shiftQPSKで奮闘してる デジタル列車無線で既知のコーデックのやつってあるのかな〜、確かに気になる所。
DSDに突っ込んでパッと音声復調とはいかないとは思うが、既知のコーデックなら少しは希望も持てるよね。
京急・JR・千葉モノは三菱、小田急・箱根はNEC、TXは日立?
三菱系は推測に過ぎないけどCELP系でしょうかな、CELP系となるともうなんだかね(´・ω・`)
個人的にはかなり前からあるTX気になるわー。
>>143 戻っておいで、
>>142こそ引っ込んでよろし >>146
そうそう 送信機は仕方ないけど受信機たっけぇからさ…ソフトでどうにかなったらハードに移植したい >>148
すごい!!がんばって。
ワイヤレスマイクに手を出してる人を初めて見た。 デジタルワイヤレスマイクって、送受信機間でペアリングして暗号化かけてなかったっけ? おはよう。
とりあえず変調方式まとめた。
京急→PSK
JR→PSK
千葉モノ→PSK
小田急→PSK
箱根→FSK
TX→PSK ここに出入りしているすごい方々は、鉄道、消防、行政防災といろいろ解析をされていると思いますが、どれが一番難易度が低いのでしょう?関係ないレスですまん・・ >>153
仮にT102みたいな仕様ならもしかしたら?とか思っちゃうけど、そうは問屋が卸さないと思うぜ。
ホワイトニングコードとかがネックになったりとかね。
しかしながら僅かな希望を抱き試してみたい。でも箱根遠いよ〜ww >>155
職場から近いから、 (っていっても20キロくらいあるが)
今週どこかで試してくる。 >>153
箱根登山のNEC型デジタルはDV1で解読できるよ。
ただ、あそこは連続キャリアじゃなくてPTT押下したときだけ波が出るからできるらしい。
それなら、同じ方式の小田急線も行けそうだよね。
連続キャリアをどうにかすれば >>157
小田急→PSK
箱根→FSK
同じ方式って何情報? 箱根登山を試しにきたけど全然交信がない。
終電まで粘ってみる。 やったね!
願わくば、関西私鉄のデジタル化の際には、是非この方式で。
NECの営業力に期待。 ちなみに待ってる間、小田急も試したけど全然だめ。
PSKということで手動でT-DMにしても全く反応なかった。 >>162
希望の光だな
昔は体たらくRLがスクープすべきネタなんだが
もしかして金欠で受信機持ってないとかw 箱根登山の件お疲れ様でした。見事な収穫すね!
π/4QPSK・TDMAのもSDRの類で突破できればな〜、もしかしたら小田急とかのNEC式もAMBEでいけるかな⁉︎知識浅いけどちょっと頑張ってみようかな。
そういえばM-CELP解析陣の方々、その後はどうですか? 近所はJR(関西地区の東海道でデジタル化済み)しか走ってないが、何か調査に協力できそうな事があったらやります。 しばらくぶりに覗いてみたら賑やかになってきてますね!おらワクワクすっぞ!!
さて遅ばせながら、私もROMでいずにこれから近いうちにSDRでデジタル無線の解析を始めようと思っているんですが(特にπ/4DQPSK)
揃えるのはとりあえずTV28Tv2DVB-T(R820T)とSDR#やgnuradio・pi4qpsk_demod.grcといったところでいいんですかね? >>170 だいたいOK
青いチューナー(R820T2)のほうがS/N比が良いらしい fc0013の方が消費電力少なくてオススメ
前に検証記事見たけど820とSNは変わらず >>174
対象がないだろ。
防災固定系?
もしかして、多重無線? 現行で波及してる防行のデジタル同報系って16QAMじゃなかったっけ?音声デコードでつまづくだろうけど。
んでま、今後は色々な規格で同報系広がるんだね。
AMR-WB+とかいうコーデックは初めて知ったわ
https://www.jstage.jst.go.jp/article/bplus/9/3/9_187/_pdf >>176
AMR-WB+はソースが公開されているので、できる人には楽勝なはず。
ttp://www.3gpp.org/ftp/Specs/archive/26_series/26.273/26273-800.zip R820T2導入しました、アドバイス下さった方々ありがとうございました。なかなか手強そうな感触、慣れるのに時間ちょっとかかりそう(汗
前スレ549さん、恐縮ながらお願いがあるのですが、以前前スレ618でupされていたT79様式復調のソースファイル、同じく前スレ958にてupされてましたT61様式復調のファイルの2点を再upして頂けませんでしょうか?
お忙しいなか恐れ入りますが宜しくお願いいたします。 こんばんは、ご無沙汰しております
>>179
全部入りをupしておきましたのでご活用下さい
ttp://fast-uploader.com/file/7052474630207/
>>168
> そういえばM-CELP解析陣の方々、その後はどうですか?
頭が破裂しそうなのでお休み中です、すいません 本当にありがとうございます!
まだまだ慣れてないところもあるんですが、なんとか頑張ってみます。
(今夜泊まり勤務なので、明日DLさせていただきます)
M-CELPもなかなか一筋縄ではいかなさそうですよね。
期待に胸踊らせていますが、どうかお体を壊さないようご自愛下さいませ。ごゆっくりお休み下さい。 >>180
159さん
頑張ってください。
応援しています。 >>180
549さん
頑張ってください。
応援しています。 いかん、早速つまずいてしまった汗
[R82XX] PLL not locked!
と
RuntimeError: can't open file
この二点の対処方がわからない・・・
https://www.fastpic.jp/images.php?file=1428556530.jpg
誰か教えてください! t61.grcでも同様の症状・・・
もしや根本的にgnuradioとドングルとの接続未良なのかとおもいきや、
どこかで拾ったFM_Receiver_1ch_RTL-SDR.grcとやらは[R82XX] PLL not locked!と出るも
エラー無くWFM音声を再生。なんだこりゃ。 >>180 >>183
ありがとうございます
驚異の粘り腰でがんばります
>>184
"PLL not locked!" は無害ですので置いておいて...
エラーの本体は"output.bin: Permission denied"なので、GRCを起動したディレクトリの書込み許可が無いためと思われます
File Sinkのパスを変えるとどうでしょうか?
(WindowsのGRCはいろいろと不完全なので、前スレの579に書いた、USBメモリを使ったLinux(Ubuntu)のGRCを使うのが良いと思います) 早速ありがとうございます、パスを変えたらpi/4 DQPSK demodulatorでるようになりました!
まだコンスタが出るまでに達してなくてこれから調整を要しますが、引き続き頑張ってみます。 私も>>187さんのように昨今から私も復調に挑んでいるんですが、先日前スレ574さまがUPしてくれたファイルのうち、
500.cなどのソースコードと出力されたoutput.binのバイナリデータの扱い(使い方?)がわかりません。
お恥ずかしながら初歩的な質問なのかもしれませんが、どなたかご教示願います。 >>188
それはつまりC言語が読めないってこと? 大変申し訳ありません、Cは高校生の時に一時的にポケコンで少々かじっていた程度でして、
それ以降の知識はさっぱりで・・・
.cということですからコンパイルすると.exeが現れる、そこまではわかっているんですけどね
一応visual studio 2017やMingwとかはインストールしてあります。
ちなみに500.cをコンパイルして現れたa.exe、これをどうにかするんですか? ちなみにconstellationはとれてるんですけどなぜかビットイメージが出ない。
http://i.imgur.com/ZXbBf9x.jpg >>190
とりあえずコンパイルするのは100.cと500.cだけでOKです
コンパイルしたa.exeを各々100.exe, 500.exeにリネームしておいてください
100.exe < output.bin > output.t61 とすると、フレームを整列したファイルが出来ます
それを、 500.exe < output.t61 > output.txt とすると、デコードしたテキストになります
あとはテキストエディタとかで眺めてみてください
>>191
WindowsだとQWT5なのでビットマップが出ませんね...
実行時に"Warning QWT has been found..." 云々と出ているのがそれです
Windowsでの解決策は分かりません、すみません >>192
ありがとうございます、100.cをコンパイルした際に
100.c:229:1: warning: return type defaults to 'int' [-Wimplicit-int]
writebuf(const char *ptr, int len)
と、出たので????っとなりましたが、500.cは問題なくその後output.txtが出せるようになりました。
Warning QWT has been found出てました!やはりWINじゃだめなんですね。
Ubuntuの方でgrc動かすように今後準備してみますです。
>>193
恐れ入りますが、すでに持ってます。 >>194
すいません、228行目に int と書いてもらえれば警告は消えるはずです
手元のも直しておきます うーむ、T79なかなか解析がうまくいかんな〜。
報知情報も捕りたいけど、とりあえず音声フレームの抽出ができるまでなんとか頑張るぜ。もしかして出来てる人いる? すいません前スレ見たら相当数ヒント出てましたね汗
前スレ見ながら引き続き頑張ってみます。 大変ご無沙汰してます
今回は皆様のお力を拝借いたしたく、スレ汚し失礼します...
ttp://fast-uploader.com/file/7054376538497/
ダウンロードパス、展開パスは >>125 と同じです
コンパイル・リンクは出来ますが、たぶんバグがあって動きません
バグを見つけた方はここで教えていただけると幸いです
実験のたたき台として使っていただきたく思います
プログラムは相変わらず標準入出力を使っています
入力はTCHの中身(32バイト単位)、出力は16bit-PCMを想定しています >>199
もちろん自分でもデバッグは続けるつもりですが期待しないで下さい >>199
度々すみません
展開パスですが、「形」→「型」にして下さい
ミスばかりで申し訳ないです >>199
お疲れ様です!いただきます。
コンパイルはできましたがこの入力はどのような形式ですか? >>202
想定している入力は、T61の音声TCHフレームを一送信分まとめたものです。
SYNC-VOICE-FREEの形で送信された一連のフレームの、真ん中のVOICEのTCHデータをバイナリエディタを使って並べ、ファイルに書き出せば良いです。 >>203
ありがとうございます。
試してみます。 >>199
>>200
早速バグ見つけた orz
decode.cの474行目は 1 << 8 に括弧が要ります
同じくdecode.cの360行目は (a >> 16)をマクロのAHに換えねばダメです >>199
>>200
公開すると次々バグが見つかる法則 orz
init.cの81行目 誤:ar6 = mem[ar4]; 正:ar6 = ar4;
同じく182行目 誤:ar2 = mem[ar6]; 正:ar2 = ar6;
すんません >消防デジタル無線では団体コード(非公開)をシフトレジスタの初期値として利用しているようですね。
http://scanner-hobbyist.blog.jp/lite/archives/65135213/comments/1492890/?p=2
↑これは推測かも既出かもしれんがワシ知らなかったわ。今更ながら勉強になった。
あと、これも参考になった。現行のシステムに反映されてるかわからんけどかなり勉強になりましたよ↓
https://www.google.com/patents/WO2013042454A1?cl=ja デバッグの段階だけどうまくいった人いる?
上記以外のバグ箇所がわからん、おいらお手上げだ MCアクセスeの通話中のTCHを数秒分バイナリーファイルに書き出してみたものの
上げていただいたソースファイルをコンパイルするための環境もやり方もわからないのでもうお手上げです >>209
一緒に入ってるMakefileからできましたよ。 ご迷惑をおかけしております
いくつかバグを取ったものを再度上げておきます
ttp://fast-uploader.com/file/7054633888898/
ダウンロードパス、展開パスは毎度同じ >>125 の通りです
今回は「形」で間違いありません
一応変換は完走するようになりましたが、手元のデータではエラー訂正がダメで音声になりません
たぶんインターリーブかランダマイズの問題だと思いますが、ヒントが無いと難しいところです
>>209
コンパイルは、USBメモリを使ったGNU Radio(GRC)環境が用意できれば、その中でも可能です
Windowsなら、MinGWとかCygwinを使ってもコンパイル出来ると思います
コンパイル自体はmakeコマンド一発にしてあります お疲れ様です、コンパイル無事できました。
このconstがコードブックに値する物ですよね?ここまで分析が進んでいたとは!
残すは音声データの解析、私も頑張ってバイナリにらめっこしながらじっくりトライしてみますわ^ ^ >>212
> このconstがコードブックに値する物ですよね?
そのはずです(固定コードブック)
他にもいくつかの構造が含まれているようですが、まだ詳細はつかめていません
適応コードブックはmulti_session.cでセーブ/リストアしているものに含まれるはずですが、これもよく分かっていません
現時点ではdeconvolution.cのエラー訂正ロジックが不完全な動作をしているっぽいので、対になるエンコード側も調べ始めたところです
余談ですが、TIのCode Composer Studio(CCS)のV2にはこのDSPのシミュレータ(実機が無くても動くやつ)が含まれているみたいなので、持っている人は試して欲しいなぁ、なんて思ってます
あと、gDSPsimというプログラムも、PC上で動くシミュレータみたいなのですが、RedHat系のLinuxをターゲットにしているみたいで、まだ手が出せていません
勇者の方の挑戦をお待ちしてます! 209です、>>210 >>211 教示ありがとうございます。
まだ環境の準備ができてませんが週末に中古PCでも買おうと思います。 スレ汚しすみません
またまた重大なバグです orz
>>211
deconvolution.cの1131行目あたりに、brc = 63; を挿入して下さい
よろしくお願いします 流れぶった切ってしまいすみません。
どなたか、B54向けのgrc作成しておりませんでしょうか?
勉強がてらチュートリアル等見ながらやってるのですが、パラメータが悪いのかうまく動きません…
どこかにうpしていただけると幸いです。 一日一バグ orz
>>211
bcd命令とbanzd命令が正しく遅延実行されていない部分が多数ありました
修正までしばらくお待ちを...
>>216
自分も欲しいです どなたか宜しくお願いします
自分はgr-ysfを改造しようとしてそのまま放置してます 技術的に追いついてなくて恥ずかしくて聞けなかったんですが、gnuradioからバイナリデータを1MBくらいに相当量保存しておいたんだけど、
100.cからの出力のうちvoiceデータが含まれたTCHのフレームの切り出しが始まったとたんに
1〜4フレーム切り出すことが出来ず、なぜかフレームの切り出しがその時点止まってしまう。
SYNC・FREE・IDLEしか含まれない時は最後まで完走するんだけどなぁ・・。
もしかして俺だけ? 訂正です、意味が違ってきちゃうんで汗
誤 : 1〜4フレーム切り出すことが出来ず
正 : 1〜4フレームしか切り出すことが出来ず こんばんは
環境にお悩みの皆様に罪滅ぼしとして...
>>180 のファイルがもうすぐ消えるので、代わりをupしておきました
ttp://fast-uploader.com/file/7054988098995/ (約95MB)
準備:
Windowsマシンと、8GB以上の消しても良いUSBメモリと、
ubuntu-16.04.2-desktop-amd64-gnuradio-3.7.11.iso と、
unetbootin-windows-647.exe と、
上のリンクの 001.casper-rw.7z を用意します
USBメモリへの書込み:
消しても良いUSBメモリをPCに挿します
unetbootin-windows-647.exeを起動します
ディスクイメージに ubuntu-16.04.2-desktop-amd64-gnuradio-3.7.11.iso を指定します
スペースは、リブートしてもファイルを維持するために使用(Ubuntuのみ)に、最低限の32MBを指定します
OKを押してしばらくすると書込みが終わります(かなり長くかかります)
書込みが終わったら、そのUSBメモリのルートディレクトリに、001.casper-rw.7z の中身の casper-rw (約4GB)を展開します
これで完成です
日本語ベースのUbuntu環境+GNU Radio Live Image+例のファイル(ホームのGNU_Radioディレクトリ以下)という構成になってます
キーボードレイアウトも日本語で、タイムゾーンも東京にしてあります
Anthyも有効にしてありますので、日本語入力もOKです
(有線LANの時に悩むことになるUSRPのネットワークエントリは削除してあります) >>220 >>222
環境がWindowsだったりしますか? おおお!大変ありがとうございます!
はい、メイン機はWindows10です。
ubuntu+gnuradioのベースで使う用のサブPCとUSBメモリも一応持ってるんですが、
使いこなす前にサブPCが先日クラッシュしてしまいまして笑、
以降まだメイン機ではubuntu+gnuradio 走らせてないんです。 故に現時点はgnuradioはWindowsベースですが、ブートメニューからのubuntuの環境は出来ているのでなんとかやってみます。
常々前スレ549さんがubuntu環境からの使用を推奨してるのにWindows環境のままでこんなお手間をかけてしまい申し訳ありません。 >>225 >>226
Windowsだと、もしかすると標準出力をRAWモードでopenし直さねばならないかもしれません
Windowsプログラムが本職の方が居られると良いのですが...
出来れば >>223 のイメージをお試しいただければと思いますです ご教示ありがとうございます。
早速やってみているのですが、日本語ベースのUbuntu環境と例のファイルがみつかりませぬ汗
http://or2.mobi/index.php?mode=image&file=162668.jpg
USBメモリのルートディレクトリ以下にcasper-rwの展開ですから↓であってますよね?
http://or2.mobi/index.php?mode=image&file=162666.png
お忙しい時に申し訳ありません。 もしやubuntuの環境設定から言語変更か?と、そちらも確認したのですが、URL先がエラーで日本語パッチ導入不可でしたので、日本語へ変更できてませんが、そこでもないですよね? >>228
たぶんですが、
ルートディレクトリにある、syslinux.cfgをエディタで開いてみてください
"label unetbootindefault"のブロックの"append"の行の末尾に"persistentが付いていなければ、それを付けてセーブして再起動するといけるとおもいます >>228
ダブルクォートをミスったので改めて一行全部
"append initrd=/ubninit file=/cdrom/preceed/ubuntu.seed boot=casper quiet splash --- persistent"
となっていればOKです
32MBのファイルを作っていればpersistentが付くはずなんですが... 連投すみません
CELPの方ですが、週末にまとめてやりますのでもう少しお待ち下さい
蛇足
東消のオネーチャンの抑揚の無い声がもう一度聞きたいというモチベーションでがんばってます >>231
昨夜はあんな遅い時間にサポートいただきましてありがとうございました。
label unetbootindefaultの項目ですが、ちゃんとpersistentになってたんですが、
やっぱり反映されませんでした。再インストもしましたがだめでした。
未だ実っておりませんが色々調べながらやってみます。
お忙しいところありがとうございました。CELP頑張って下さい!
差し入れ持って応援に駆け付けたいくらいですよ、私も多摩指令の張りのあるお兄さんの声もう一度聞きたいです笑 >>234
うまくいきませんでしたか。お役に立てなくてすみません...
isoファイルが違うバージョンとか、HDD上にcasper-rwというパーティションがあるとか、実は違うディスクから起動していたとか、ほとんど無さそうなことしか思い浮かびません...
CELPの方ですが、DSPの評価ボードが無いので仕様書を片手に動作を想像で書いているのと、C言語を忘れ気味ということで、苦戦しています
あと、大きなハードルとして、インターリーブの方法を総当りで解かねばならない部分が考えられます
いつもの驚異の粘り腰でがんばります
余談
前スレのコテハンさんも、ここをみてらしたらちょっとは出てきて欲しいなぁ... >>235
何か解析に協力できそうなことがあれば致しますよ。複数マシンで分散解析とか可能であれば5台は回せますよ。 こんにちは
>>220 >>221
100.cへMinGW用のコードを追加しました。#ifdef __MINGW__ 〜 #endif の間がそれです
ttp://fast-uploader.com/file/7055134784893/
このコードで改行(LF)の出力がWindowsだとCRLFにされてしまったのを抑制できると思います。
MinGW以外でもだいたい同じだと思いますので、適当に修正してみてください。
よろしければお試し下さい >>236
ありがとうございます
本当の総当りだと、256! (= 256 x 255 x 254 x ...)になってしまって、億年単位どころではなくなりますので、
現実的なところに絞り込んで、その後にお願いするかもしれません
そうなりましたらよろしくお願いします 改めましてCELPのほうです
相変わらずデコード自体は未確認・未完成です。実験にお使い下さい
ttp://fast-uploader.com/file/7055141371559/
ダウンロードパス・展開パスは以前と同じ >>125 の通りです
(CELPのコードブックが含まれていますので、実機をお持ちの方限定とさせていただいております)
バスエラーの原因は取り除きました
その他ケアレスミス多数を修正しています
フレーム毎のエラー訂正数を表示するようにしましたので、インターリーブの試行錯誤に役立つと思います
ご活用&フィードバックいただければ幸いです >>240
お疲れ様です!頂戴します。
インターリーブはなにか手がかりがあればいいかもしれませんね。 >>241
手がかりといえばこの辺....
ff490cb79d724098ec3329b2e6035da3e70dde16b4c3efe491e003f2d2247506
fc490eb79f724098ed332bb2e5035fa3e60ddf16b4c3eee490e002f2d3247706
上の2行(2フレーム)はFチャンの無音時のもので、これがエラー0でデコード出来るデインターリーブパターンを導き出せばOKのはずです
あと、デジタルMCAの無音時のフレーム(秘話解除後)が手に入れば、それと比較することで大きなヒントになり得ると思います
出来ることをガンガン進めたいですね! ■ このスレッドは過去ログ倉庫に格納されています