【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。
コテハン推奨。
前スレ
【C4FM】デジタル信号復調【π/4DQPSK】
http://mint.2ch.net/test/read.cgi/radio/1434951910/ いかん、早速つまずいてしまった汗
[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の無音時のフレーム(秘話解除後)が手に入れば、それと比較することで大きなヒントになり得ると思います
出来ることをガンガン進めたいですね! >>242
お疲れ様です!
こちらは味噌が有名な市ですが、無音時のビットパターンは同じでした。
数がないと何とも言えませんが、行政間でスクランブルコードに違いはなさそうですね。
ちなみに全体のエラー数ではなく、最初にエラーが見つかったインデックスも出力できれば解析がはかどるかなと思いますがいかがでしょうか? お!fc490eb79f724098ed332bb2e5035fa3e60ddf16b4c3eee490e002f2d3247706 出たわ
同じなんですね!
あ、ピーナッツ県です。 うちもたこやき府の受信できるので協力したいが、機材と知識が無いorz
協力者が増えれば手がかりも多くなると思うが、何すれば良いかわからん。 >>243
ありがとうございます
無音時パターンが同じ局はかなり多いですが、全く無い局もあって、???だったりします
エラー比較しているのはdeconvolution.cのfunc_f594()なので、この中に入れれば良さそうですね
次回はデバッグログ出力を入れてみたいと思います なんか上2つの無音パターンに似たパターンが連続で出たすよ、
真の無音ではなく無音に近い若干の音を含んでた感じかな?
TCH: fd494fb79e624098 ec332bb2e6135db3 aa0ddf97b4c3eee4 09e18da852246e05
TCH: ff494cb79d691f98 ac3329b2e6135db3 e70ddf16b482efe4 d0e001f2d22561dd
TCH: fc490ab79b634098 ed332bb2ec155bb3 e60ddf16b482eee4 94e002f2d3257706
TCH: ff494cb79d634098 ac3329b2e6125db3 e70dde16b483efe4 d1e003f2d22561dd
TCH: 6ae8c5023b66ee80 879ce573490cad20 e60ddf16b482eee4 d4e002f2d3257706
VOICEデータ眺めてるとたまに規則性に近いものを感じてくるときがあって面白いですね >>246
まずはSDR#で受信できる環境ですね
SDR#で使えるUSBワンセグチューナーを手に入れて下さい
(SDR#はあくまでワンセグチューナーのテスト用なので、実際の受信には使いません)
安物(FC0012使用)だと送料込み500円くらいですが、R820T2を使ったもののほうが個人的にはお勧めです >>244
ピーナッツ県だと、PICHの4フィールド目(12ビット)が00010000xxxxだったりしますか?
たぶんここが消防団体コード(非公開)だと踏んでいるのですが...
因みに山の上での受信をまとめると、
東京: 00010010xxxx、
神奈川: 00010011xxxx
埼玉: 00001110xxxxと00001111xxxx
茨城: 00001011xxxx
栃木: 00001100xxxx
群馬: 00001101xxxx
な感じに見えてます(一部例外あり)
>>248
その「ちょっと違う」というのもインターリーブの重要なヒントだったりします
>>250
それです! >>251
>>244>>248のピーナッツ県です。PICHの4フィールドですがまさに00010000xxxxでした。 >>252
ありがとうございます。この情報も全国的にまとめてみたいですね。
(大半がwikipediaの『消防本部一覧』の順に並んでいるみたいです) 些細ながら私も受信したうち気になったところの報告です、首都FIREの受令です
#S2: RICH: 11 011 001 110 000000 ** VOICE ** RCH/SACCH: 9001e TCH: fc490eb79f724098 ed332bb2e5035fa3 e60ddf16b4c3eee4 90e002f2d3247706
S6: RICH: 11 011 001 110 000000 ** VOICE ** RCH/SACCH: 99999 TCH: ff490cb79d724098 ec3329b2e6035da3 e70dde16b4c3efe4 91e003f2d2247506
S6: RICH: 11 011 001 110 000000 ** VOICE ** RCH/SACCH: b506f TCH: fc490eb79f724098 ed332bb2e5035fa3 e60ddf16b4c3eee4 90e002f2d3247706
S6: RICH: 11 011 001 110 000000 ** VOICE ** RCH/SACCH: 88503 TCH: ff490cb79d724098 ec3329b2e6035da3 e70dde16b4c3efe4 91e003f2d2247506
S6: RICH: 11 011 001 110 000000 ** VOICE ** RCH/SACCH: 07d70 TCH: fc490eb79f724098 ed332bb2e5035fa3 e60ddf16b4c3eee4 90e002f2d3247706
S6: RICH: 11 011 001 110 000000 ** VOICE ** RCH/SACCH: 3b10a TCH: 400b21ecb924e294 c87f238fb64075be e70dde16b4c3efe4 91e003f2d2247506
1〜5段目のTCHデータは>>242のコンフォートノイズパターンと一致ですが、
6段目、1・2ブロックは規則性から外れた内容。しかし3・4ブロックは>>242の規則パターン。
皆様の役に立てれば幸いです。 >>251
カナガワですが自分近くですと00010100xxxxですね・・・ 追記ですがPICHの第4ブロック、>>251と一致です。00010010xxxxでした。 >>250
自分が持ってるのは
X-tal 常温/温特±10PPM実装TV28Tv2DVB-T(R820T2)チューナー単品ブラック[RTL2832U+R820T2][DVB-T+DAB+FM][広帯域受信用]【USBコネクター換装品】
って奴だけど違いがよくわからない >>257
それ、よく見かけるけど、もう何言ってるのかよく解らない型番w TV28Tv2DVB-T(R820T2)
[RTL2832U+R820T2][DVB-T+DAB+
/(^q^)\ >>252 >>254 >>255 >>256
ありがとうございます
まとめますと
茨城: 00001011xxxx
栃木: 00001100xxxx
群馬: 00001101xxxx
埼玉: 00001110xxxx 00001111xxxx
千葉: 00010000xxxx
??: 00010001xxxx (たぶん千葉)
東京: 00010010xxxx
神奈川: 00010011xxxx 00010100xxxx
先頭8ビットが地域番号で、後ろ4ビットが団体番号というのが裏付けられそうです
(雑誌のおまけの周波数帳にちゃんと載せてくれれば買いますよ > 関係者) >>258
歓迎光臨!
不躾で何なんですが、何かちょっとしたことでもヒントを頂けましたら... 水色チューナーじゃないとダメなんだよな
黒色チューナーだとダメ >>263
団体コードは県防災にももちろん番号は振ってあるけど防災ヘリぐらいしか出てこないのね。で、各団体に振ってある番号だと、10進であれば、
団体CD 局番号
0001 0001
こんな感じで無線機ごとに振ってあります。
番号構成は24ビットのバイナリで、1〜12ビットが個別局番号、13〜22ビットが団体コード、残り2ビットは予備、となります。
雑魚ネタですまぬ。 >>268
大変ありがとうございます。団体コードは実質10bitでしたか...
また機会がありましたらご教示下さい。 >>268
貴殿におかれましては解析は順調ですか? >>269
MCELPボードの表は汎用チップなんだけどボードのウラにある管理番号と菱印のシールが貼ってあるチップが何者かなあと。 >>271
すでにチップ実物入手されているのですね。朗報待ってます、頑張ってください。 >>271
見ただけですw
持ってたらそのまま使いますよ >>249
機材そろってるけど、何かできることありますか? >>274
Fチャンが受信できる体制を整えて、幾らかのフレームを受信して溜めていただければ、
音声フレームの地域毎のエンコードの違いの有無(いまのところ数箇所では違いが無いようです)、
消防団体コードの全国調査、ほかには周波数ごとの発信局情報のまとめなどが出来ると考えられます。 >>250
次はデジタルMCAの中古実機を入手すること 役に立つかわからないですけど、首都FIREで無音データにそっくりな連続データがでましたよ
S6: RICH: 11 011 000 110 000000 ## IDLE ## RCH/SACCH: 88503 TCH: 4d0981d23630e6a9 f4475fd0fa215d87 e60ddd16b4c3ece4 93e003f2d0247706
S6: RICH: 11 011 101 000 000000 -- FREE -- RCH/SACCH: 88503 TCH: 4d0981d23630e6a9 f4475fd0fa215d87 e60ddd16b4c3ece4 93e003f2d0247706
VOICEではなくIDLEとFREEなの。スペースの関係上乗せてませんがIDLEでは上記のデータが数十行FREEで3行出ましたわ。
なぜかFREEのあとのVOICEデータがbinから変換取得できなかったんですけど、
いわゆる無音データと思われるfc490eb79f724098 ed332bb2e5035fa3 e60ddf16b4c3eee4 90e002f2d3247706
と似てるあと思ったんですよ。
・・・って気のせいですかね? 自己レスですが、なぜ>>278のようなデータが出てるか判明しました。
長いtxtなんで↓を参照下さい。
http://fast-uploader.com/file/7055423450219/ PASS:周波数
この通り、VOICEデータの最後の行で出たデータがそのままIDLEとFREEに通しで使われてるんですね。
さすがに用途まではわからないのですが・・・。
こういったデータ役に立ちますかね?皆様ご参考にどうぞ。 >>278 >>279
フレームデータの多数決により、エラーフリーのフレームデータとして使えると思います。
ビット化けが無いフレームというのは、計算する上でとても重要です... IDLEやFREEのフレームは、
(1) 全て0
(2) def0ef01f0120123 1234234534564567 56786789789a89ab 9abcabcdbcdecdef
(3) 有意なフレーム(VOICE,DATA,FACCH)の最後の行の繰り返し
の三パターンあるみたいです
メーカーのソフトウェアの実装の違いでしょうか? >>281
メーカーの違いなら各地域ごとの入札結果から使用しているメーカーを絞りこめる場合もあるので
照らし合わせてみると面白いかもしれませんね。 ■ このスレッドは過去ログ倉庫に格納されています