【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。 コテハン推奨。 前スレ 【C4FM】デジタル信号復調【π/4DQPSK】 http://mint.2ch.net/test/read.cgi/radio/1434951910/
>>521 の続きをご報告します エラーフリーと思われる音声TCHフレームを統計処理して、インターリーブパターンを絞り込みました たぶんこれでOKだと思います const int voice_tch_interleave[256] = { 95, 127, 79, 111, 223, 255, 207, 239, 31, 63, 15, 47, 159, 191, 143, 175, 94, 126, 78, 110, 222, 254, 206, 238, 30, 62, 14, 46, 158, 190, 142, 174, 93, 125, 77, 109, 221, 253, 205, 237, 29, 61, 13, 45, 157, 189, 141, 173, 92, 124, 76, 108, 220, 252, 204, 236, 28, 60, 12, 44, 156, 188, 140, 172, 91, 123, 75, 107, 219, 251, 203, 235, 27, 59, 11, 43, 155, 187, 139, 171, 90, 122, 74, 106, 218, 250, 202, 234, 26, 58, 10, 42, 154, 186, 138, 170, 89, 121, 73, 105, 217, 249, 201, 233, 25, 57, 9, 41, 153, 185, 137, 169, 88, 120, 72, 104, 216, 248, 200, 232, 24, 56, 8, 40, 152, 184, 136, 168, 87, 119, 71, 103, 215, 247, 199, 231, 23, 55, 7, 39, 151, 183, 135, 167, 86, 118, 70, 102, 214, 246, 198, 230, 22, 54, 6, 38, 150, 182, 134, 166, 85, 117, 69, 101, 213, 245, 197, 229, 21, 53, 5, 37, 149, 181, 133, 165, 84, 116, 68, 100, 212, 244, 196, 228, 20, 52, 4, 36, 148, 180, 132, 164, 83, 115, 67, 99, 211, 243, 195, 227, 19, 51, 3, 35, 147, 179, 131, 163, 82, 114, 66, 98, 210, 242, 194, 226, 18, 50, 2, 34, 146, 178, 130, 162, 81, 113, 65, 97, 209, 241, 193, 225, 17, 49, 1, 33, 145, 177, 129, 161, 80, 112, 64, 96, 208, 240, 192, 224, 16, 48, 0, 32, 144, 176, 128, 160 }; これで終わりではなく、まだこれに加えて秘話パターンを求める必要があります 秘話パターン256ビットでxorした上で逆インターリーブ、先頭202ビットの逆畳み込み、その他諸々をすると84ビット出てくるので、 それと後ろの54ビットをくっ付けると138ビットのM-CELPフレームになるという算段です 秘話パターンがLFSRとかで求まれば、後ろ54ビットのxorビットが求まりますので、これでM-CELPの正常フレームが得られます (ちなみに畳み込み部202ビットの秘話パターンはトライ&エラーで求めることが可能と思われます) とりあえず以上です おおすげえぇ!超ワクワクしてきた! よく特定できましたね、インターリーブパターンどうやって解いたんですか? >>528 19:51と95:127が畳み込み関連というのが分かったので、まず深さ32ビットのインターリーブをかけて、隣り合うビットを特定しました その上で、19:51と95:127のどちらかが先頭だろうと目星をつけたところ、95:127のほうが正しいっぽい、となりました 具体的には、95:127が01と10になっているので、それを別々のフレーム群に分割して、00/01/10/11のうち、 いずれか2つのみで構成されているビットペアの位置を検索し、それを分割し、またまた検索し... とやって、ある程度パターンが見えたところで見切った形です エラーの無いことが保証できる数千フレームを処理すれば完全な形が見えると思います インターリーブパターン、縦列で見れば 6,8,5,7,14,16,13,15,2,4,1,3,10,12,9,11列の配列なんですな。 ブロックに分けると | 6,8,5,7 | 14,16,13,15 | 2,4,1,3 | 10,12,9,11 | 更に配列順を見ると | 2,4,1,3 | 2,4,1,3 | 2,4,1,3 | 2,4,1,3 | そんでもってブロックを配列順で見ると | 2 | 4 | 1 | 3 | ほおお、なるほどなァ 言いたい事伝わったかな?(笑) ここまで丁寧に解説してくれるとチンプンカンプンだった自分もおおーとなったよ ARIB STD読むと勉強になるね 前スレ549さん辺りはとり掛かってると思うけど F-chとMCAのCELPが同一規格を前提として MCAの無音データ138ビットの作成からやってみるか 大変ご無沙汰しております >>532 気付いてはいましたが、まだやっておりません > 無音データ 最近分かったことを箇条書きにしてみます ・エンコードはK=9, R=1/2の畳み込みで確定 生成多項式も0x11d, 0x1afで、CDMAと同じ ・秘話は単純なXORではない ・逆インターリーブした音声TCHデータを2ビット毎に区切り、四進数として{0,1,2,3}とすると、 パターン0:{0,1,2,3}→{3,1,2,0} パターン1:{0,1,2,3}→{0,2,1,3} パターン2:{0,1,2,3}→{1,3,0,2} パターン3:{0,1,2,3}→{2,0,3,1} の4パターンを使って変換すると逆畳み込みが可能なビット列になる 逆に分かってないことは、 ・パターン0,1,2,3のどれが二進数の00,01,10,11に該当するかはまだ不明 ・変換パターンがLFSRなのかどうかも不明 となります パターン変換マップの101文字は、以下のどちらかではないかと考えています (1) 30112210000123231133210211113212222103210220233111221033012201330002133201232302303120000211200131301 (2) 30112210000123231133210211113212222103210220233111221033012201330133102113031202303120000211200131301 無音データが入手できれば、このどちらかが正しいか、それとも両方が間違いかが分かるはずです なお、これらはあくまでも勝手な複数の仮定に基づく妄想の産物ですので、野暮な突っ込みはご遠慮下さい... >>533 この実験に使ったソースを上げておきます よろしければ参考にしてください ttp://fast-uploader.com/file/7065792921533/ 使い方: (1) まず最初にmakeを実行してvoice_tchコマンドを作っておきます (2) 503コマンドの出力(テキストファイル)を、step1.txtとリネームして同じディレクトリにおきます (3) sh step1.shを実行します(step2.txtが出来ます) (4) sh step2.shを実行します(step3.txtが出来ます) (5) sh step3.shを実行します(step4.txtが出来ます) (6) sh step4.shを実行します(result.txtが出来ます) あとはresult.txtを眺めてみてください ビットエラーがある場合は、右端に見つかった最初のエラー位置(左端を1とした文字数)が出ます >>534 ご苦労様です! 参考にさせていただきます。 >>534 の訂正です step4.shの中の数列を以下のものに換えて下さい 30112210000123231133210211113212222103210220233111221033012201330133102113031202303120000211200131301 正解は相変わらず分かっていません... >>536 補足です この数列パターンは、無音部のパターン2つのうちの1つが全て0でデコード出来るようにしたものです (これが現状の大きな仮定のひとつです) この数列によって、現状、エラー検出とViterbi的なエラー訂正が可能になりました この数列を使ったデコード済みビット列は、末尾にある8個の0(畳み込みのパディング)を除き、MCAデジタルのフォーマットとよく似ています MCA: 5+18+43+23+4+8 = 101ビット Fch: 4+23+43+18+5+8 = 101ビット フォーマットをMCAデジタルと同じにするには、Fchのビット列を逆順に読むだけで良さそうな雰囲気ですが、はたしてどうでしょうか? ともあれ、正しい数列が見つかれば、先に進めそうな感じです >>537 お疲れ様です。 解析が進むにつれ、やはりFのMCAとの類似点が増えてきましたね。 >>538 どもです 自分でもかなりいい所まで来てる実感があります デコード後のhash値の演算も通ったので、あとはビットの組み換えをすればM-CELPの本体へ渡せそうです (訂正) >>537 で書いたMCAとFchのビット構成ですが、正しくは MCA: 4+18+43+23+5+8 = 101ビット Fch: 5+23+43+18+4+8 = 101ビット でした なるほど・・・と、言いたかったが頭がついていかん(笑) しかしながらかなり複雑な仕様なんだと理解できた、並の努力じゃここまで判明しなかったでしょう。 前スレ549さんのお手伝いしたかったが、結局ここまで何も出来ず。 お弁当の差し入れくらいしたかったぜ、お茶付きで。 ちなみに質問ですが、これらは移動局側にも適用できる感じですか? >>540 ここまで来るのに、何だかんだで1年近くかかってますね... 成果物は、ほぼ全て公開しましたので、普通に使ってもらって過程を楽しんでもらえたら嬉しいです 完璧な結論を早く出せ!と仰る方には、ごめんなさいをしておきます 移動局(uplink)のほうは、通常時は大丈夫そうです 手元でも幾つかデコード出来ています >>442 のようなパターンが出るとダメですが... (逆畳み込みは出来るのですがその先が不明) ご回答ありがとうございます、やはり反映できるのですね! 私も>>442 のパターンが解けるかどうかが関心事でした。 デフォルト外の秘話設定ぽかったりします? 今後音声をデコードできるようになれば、未確証だった団体コードや出場種別等々、判明することも多いかと思うので今後が楽しみです。 >>542 正確に記述しますと、>>442 のパターンは全てが ・逆畳み込み:OK ・ハッシュによるフレームエラーチェック:OK なので、他の受信フレームと同様に並び替えをしてM-CELPへ渡せば良さそうなのですが、 ぱっと見の心象が悪いビット列なのです(ここは完全に主観です) M-CELPデコーダを動くようにして、このビット列を突っ込むまで本当のところは分からないです 現状、これは今後のお楽しみということで何卒宜しくおねがいします コーデック自体が一般流通してないもので、かつ権利・著作物の関係で不特定多数への配布に難があるから、だからとりあえずは中古であれコーデック吸い出した実機同様のEF-6190を持っておきましょうよ、という事だと思いますがそういう解釈で合ってますかな? >>548 自分的にはまさにそういう意図でお願いしています CELPアルゴリズムに著作権は及ばないのですが、コードブック部分はどうしても回避出来そうにないので... コードブック部分の自動生成が出来るようになったら事情が変わるかもしれません EF-6190っていろんな会社が製造してるんだな アイコムやパナソニックがメインみたい >>550 製造してるのは三菱1社。 その他のメーカーはOEM供給を受けて販売しているだけ。 もしM-CELP突破できればの話ですが、同じ三菱系のJRデジタルの解析にも応用できる可能性があるのでしょうか? >>534 デコードした結果を使ってM-CELPのデータ構造を組み立てるように追加コーディングしました ttp://fast-uploader.com/file/7066297450891/ 使い方は>>534 と同じです 前回から、次の点を加えてあります (1)hashの計算と比較 (2)MCAのデータ形式への変換と表示(2進数) (3)M-CELP形式への変換と表示(16進数) また、引数に与えていたマジックナンバーを内包しました これは、voice_tch.c先頭近くにある#undefを#defineに変更すると以前と同じ仕様になります まだ出力結果は評価出来ていません(DSPのシミュレータを動かせる人求む!) みなさんの実験のベースとして参考にしていただけるとありがたいです MCA実機でNECチップの型番ググっても全く情報出てこない オプション?外部端子の通信用みたいで無視しても構わなそうだけど気になる >>553 お疲れ様です。 いつもありがとうございます。 ダウンロードさせていただきます。 Code Composer Studio とチャイナ製のJTAGアダプタで 実機デバッグできて色々とイジれそうですね〜 TMS320C54x. のシミュレーター見つけたんで貼っときます gdspsim.sourceforge.net >>556 CCSのシミュレータで検証 C54x用はCCSのVer4以上では含まれておらず Ver3はダウンロード出来ず断念 gdspsim CentOS上で実行してみたけど実用的じゃない・・・ 実機で検証用にJTAGアダプタ入手待ちです だれか動作環境のあるかたチャレンジ求む!! CCS Ver5だとC55xのシミュレータが実行出来て C55xはC54xとソフトウェア互換らしいのでMCAのバイナリ読ませて 実行までは出来たんだけどC55xから実装された可変命令長が邪魔して 逆アセみるとニーモニックが変になってる・・・ C55xのアセンブラでC54x互換モードが有るらしい C54xのバイナリを逆アセンブル→C55xでアセンブル CCS Ver5のC55xシミュレータで旨く行けば実行出来る? このC5509A評価ボードに付いてくるDVDにはCCS3.3が入っているみたい。だれか試しに買わない? ttps://www.aliexpress.com/item/free-shipping-DSP-development-board-DSP5509-development-board-TMS320VC5509A-development-board/32607704473.html >553 お疲れ様です。自分の環境でも state = 0x00 : OK !! が出ました。 これを>515に入れてみたいのですが、どうやったらいいでしょう? PCMが出ればwavにしてみます。よろしくお願いします。 >>561 あのソースはまだ不完全で、鋭意デバッグ中ですので、もうしばらくお待ち下さい (現状だと何を入れても全部0の出力しか出ません) こんにちは Fchデコーダーを改版しました ttp://fast-uploader.com/file/7066959438477/ いつも通り、gcc -o 504 504.c でコンパイル出来ます 503からの変更点は、 (1) >>553 の成果を取り入れて、音声フレームのCELPフレームへのデコードと表示を行うようにしました (2) RCH/SACCHのデコードを、スーパーフレーム末尾で無く、逐次に行うようにしました (3) RCHのデコード結果を、成功した場合にのみ表示するようにしました (4) SACCHの無効フレーム時には、invalidを含め何も表示しないようにすっきりさせました (5) (S/F)ACCHの出動種別87(disaster)を追加しました (>>501 さん御提供) (6) その他、細々とした高速化を図っています です 使ってもらって感想をいただけるとありがたいです >>563 の付け足し CELPのフレームですが、9word(18byte)分の16進表記で、先頭からの138ビット+1ビットを使っています +1ビットは、hash計算エラーのフラグです(1なら失敗) 実機シミュレータならば、 (1) 0x6792に1を書き込んで逆畳み込みを抑止 (2) 0x292aaを呼び出してセッション初期化 (3) 0x6550~の9wordにCELPフレーム+フラグを書き込み (4) 0x29365を呼び出してデコード (5) 0x6650〜の320wordのPCMまたはμ-LAWデータを読み出し (6) セッションの間、(3)〜(5)を繰り返し となるはずです(未検証) また、EF-6190実機の音声録音バッファも同じデータ構造のはずですので、ここを乗っ取れれば実機から音声が出力できるはずです(未検証) これにはデバッグシリアルを探し当てることが必須です >>515 のプログラムは、何か根本的なところ(ALUを使った演算部のエミュレーション?)が間違っているのでまだ動きません 全面的な書き直しを含め、今後の作業を悩み中です >>563 表示がゴチャゴチャして非常にうざいので、スッキリさせたバージョンを作りました ttp://fast-uploader.com/file/7067419362771/ gcc -o 600 600.c でコンパイル出来ます 比べてみてご意見下さい >>565 いつもありがとうございます。使わせていただきます。 差し出がましいですが、常時記録だとFREE時省略のオプションなども欲しいかも? >>566 手元ではこんなのを使ってます ttp://fast-uploader.com/file/7067506803987/ コンパイル後、 101 < output.bin | 299 | 600 という感じに、間に挟んで使います (こういう意味じゃ無かったらすみません) >>567 おお、まさにこれです!ありがとうございます。 大変お疲れ様です。 >>565 MCA→CELP変換テーブルのあるROMアドレスをご教示いただけますか。 565ですと、24,25、127が2つあるので。 ※想像ですが、81番目が14、82番目が15、114番目が126かなと 思っています・・ >>569 あぁ、やっちまいましたね... > 自分 早急に見直します.... なお、テーブルですが、ROMのPAGE1の0xfaf4〜0xfb7eと0xfb7f〜0xfc09になります 前者がワードオフセットで、後者がビットマスクです >>570 >>569 さんのご想像通り、その3ヶ所が間違えていました >>553 の voice_tch.c, >>563 の504.c, >>565 の600.cに影響があります 以下の配列が正しいものになります const unsigned char celp_conv_table[139] = { 41, 42, 43, 18, 19, 20, 21, 22, 84, 85, 44, 45, 46, 47, 86, 87, 88, 89, 90, 91, 23, 24, 25, 26, 27, 28, 48, 49, 50, 51, 52, 92, 93, 94, 53, 95, 96, 97, 98, 99, 100,101,102, 54, 0, 55, 1, 2, 3, 4, 5, 56, 57, 58, 59,103, 60, 61, 62,104, 105,106, 63,107,108,109,110,111,112,113, 114, 64, 6, 65, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 66, 67, 68, 69, 70, 115,116,117, 71,118,119,120,121,122,123, 124,125, 72, 29, 73, 30, 31, 32, 33, 34, 74, 75, 76, 77,126, 78, 79, 80,127,128, 129, 81,130,131,132,133,134,135,136,137, 82, 35, 83, 36, 37, 38, 39, 40,138 }; お手数ですがコピペしてご使用下さい どなたかMCAの無音CELPフレームの取得に成功された方がおられましたら、いただけないでしょうか... MCAってT85でしたっけ?ちょっと試してみようかな。 どなたかT85のgrcのブロック組み立てた方いますか? >>574 拙作t79.grcの周波数を変えて試してみてください >>575 お返事遅れてすいません、早速周波数部分を変更して使用させていただいております。 タイミングが悪いのか通話してる波がなかなかキャッチできないっす笑 >>576 毎回異なるスクランブルがかかっているはずです... 総当りすればいけるのかもしれませんが 一か月位かかって中国からDSPエミュレータ届いたんだけれど 象にでも踏みつぶされたように破損してるよ!! また送ってもらうのに早くて半月位かかるな〜 >>228 亀レスですが... UEFIブートが有効になっているとGRUBが起動すると思いますが、どうもこの周辺にバグがあるようで、 casper-rw等が正常にマウント出来ないようです BIOSでUEFIブートを切るとUNETBOOTINになりますが、こちらでは正常にマウントされて起動します (手元で再現しました) ご参考まで... やっとDSPエミュレータが届いたぞ! 色々と忙しいんで、ゆっくりとやってみますよ dat落ち防止保守。前スレ5494は元気に頑張っておられますか。 たいへんご無沙汰しております >>582 インフルエンザで寝込んだりしていましたが、何とか生きてます 近況としては、CELPのデコーダを全面書き直しして、止まらずにピロピロ音が出るようにはなったのですが、 正常に動作させるには、現状のフレームフォーマットを2ひねりくらいする必要がありそうな感じです 引き続き、>>572 の無音フレームの取得に成功された方をお待ちしています よろしくお願いします 549様おつかれ様です。 >>569 >>570 offset→CELPワード、fbit position→ワードbit位置かなと想像して f7daと格闘・年越しましたが、そもそも同じ変換テーブルにできませんでした… (2f7f4、2f803に関連する0x720cの謎が解けず、無理やり並べても 44,46,47,48,49,50,72,…,128,129,138にしかなりません) 関連しそうな関数f605とf5cbは、自分にはもう完全にお手上げのため 大変恐縮ですが、0x720cの意味合いについて 何かヒントをいただけませんでしょうか。 >>584 かなり良い所までいっている気がします まず、44,46,... ,129,138 の隣に0...138の番号を書きます 次に、44,46,....,129,138 を昇順にソートします そして、隣の番号を順に読むと... というわけです 参考までに自分が求めたときの表を上げておきます ttp://fast-uploader.com/file/7071996969638/ >>584 肝心なところを書き忘れました 0x720cは、ページ0のアドレス=RAM(ワークメモリ)を指すものだと思います 手元の解析メモでは、Viterbiデコーダーの出力(84ワード)と書いてあります (だいぶ忘れてしまっていますので正確さは保証の限りではありません すみません) >>585 おおっ!ソート処理で全一致しました! ありがとうございます、すっきりしました 再お願いですみません、ソートのコード番地はどの辺でしょう? >>586 デコーダの件は了解です、勉強してみます >>587 ソート自体はDSP側には無いです デコード時にエンコード用の配列を毎度逆に読むのが嫌だったので、手元でソートしただけでした DSP側は毎度逆に読んで処理しているはずです お疲れ様〜。 そんな単純じゃ無いんだわさ。 ある部分が変わり続けるんだよ。 >>589 やっぱりそうなんですか 難しいですね... 音声通話自体が激減してるのに ほんと未練がましい老害 タクシーも消防も無線機がデジタルになっただけで通話頻度ほとんど変わってないが やはりそうだよね。1通話が復調出来ても次に変わっちゃうんだよね。 聞こえてない奴はレス禁止 ここは、マルマルできてる奴が暗語でお話しするスレ 繰り返す 聞こえてない奴はレス禁止 >>598 ブログは見たことある ただ音声の復調はダメだったかと メーカーと機種の表示はできてた 初めまして 前スレ334さんのフローグラフを見よう見まねで作ってみました とりあえず表に見えるパラメーターだけ書き写してやってみたら5秒だけ縦に真っ直ぐ筋が出ましたが以降は綺麗なビットマップが出ませんでした。 現在地からは防災・Fともに強力に入ります 完成しているプログラム再うpしていただけると助かります、よろしくお願いします 前スレ334ではありませんがWarning QWT has been foundと出てたりしませんか? そのフローグラフ(grcファイル)をupしていただけますか? レスありがとうございます 最初はubuntuでやっていましたが仰るとおりQWTのバージョンがうんぬんと出たのでwindowsでやると上手く出ました fastuploderの期間はどのぐらいがおすすめですか? upするのが初めてなので教えて頂けると幸いです。 あぁ、fastuploderの削除までの期間のやつですよね。 私はあまり考えず1週間とかにしてました笑 upしてみました http://fast-uploader.com/file/7073384180873/ パスは270帯の変調方式のアルファベット4文字(小文字)です 期限は24時間にしてます そちらの都合が悪くDL出来なかったら再度upします >>601 拙作t61.grcとt79.grcをupしておきます 参考にしていただければ幸いです ttp://fast-uploader.com/file/7073467140862/ おお! ビットマップが真っ直ぐに現れました! 自分が作ったのは途中から同期出来なくなり、ぐちゃぐちゃになってしまいました。 頂いたものを参考に見比べてます、ありがとうございます! p.s. 334さんは多重分離されてるみたいですね、分離できたら面白そうだなー 事のついでに、F-chデコーダをupしておきます (CELP関係に特に進捗は無くて申し訳無いです) ttp://fast-uploader.com/file/7073476505599/ いつもどおり、gcc -o 601 601.cでコンパイル出来ます 600.cからの変更点は、 (1) PICHの表示を、8進数から一部を10進数に変更しました 10進数には頭に#を付けています (2) DATAのデコード時、緯度経度の時に変な空行が表示されるのを抑制しました (3) 音声の未訂正ビット54ビットの並びを逆順で扱うようにしました(合っているかどうかは不明) (4) PICHに本部名と局名を追加表示するprint_station関数を追加しました(ファイル末尾) 漢字(Shift-JIS)を使っていますので、エディタで開く際にはご注意下さい です 皆様の情報を元に(4)を充実できればと思っています よろしくお願いします 601です grcからのデータを流したら8桁のバイナリと「XXX unknown sync word」と出ました 地方だからデータベースに合わないのかな? でもビットマップを見て妄想してます >>610 T61の話と仮定しまして... output.binはフレーム単位に並べられていませんので、拙作101を使って並べなおしてから601に食わせてください ttp://fast-uploader.com/file/7073545963136/ 使い方は、 101 < output.bin > output.t61 601 < output.t61 > output.txt という感じです(テキストには漢字(Shift-JIS)が含まれることがあります) おお! IDELとか出ました 案外電波が弱くてもデコード出来るんですね すごい、ありがとうございます! >>609 お疲れ様です。 いつもありがとうございます! 601いただきます。 print_stationこちらでも照合してみます。 皆さんで充実させられたら良いですね。 >>613 print_stationについては、以前の自分の大失敗(>>343 >>344>>345 )がありましたので、予断をせずに保守的に進めたいと思います 現在書かれている内容も、全て正しいわけではありませんので、記述のサンプルとして参考程度にしていただければと思っています 都道府県に関しては、『無線脳の視点』さんのブログ(※)に書かれている、「都道府県・主運用波(1〜7)」を受信すると、近所の都道府県は分かってくると思います また、住所や緯度経度が表示されるような局であれば、そこから本部名が類推できます 個別の局名は、いまのところ力技でしか判別出来ていません... (※) ttp://blog.goo.ne.jp/jg7ubp/e/829cd86302fe0c741a9ee3cce6b9d682 >>614 こちらで試した参考程度の情報ですが firedepが321と325は神な川県っぽいです。 325はY浜本部?でしょうか。stationの方は全然見当つきません。 >>615 情報ありがとうございます Wikipediaの『消防本部一覧』を見ると、K奈川ですと24本部あるようですので、 1本部1波としても最低24波ですね...大変だ こういうのは周波数帳をおまけで出している雑誌社に丸投げしたいですね たのむからもっと意味のある周波数帳を出してくれ... > 某社 800MHzMCAの無音部抽出うまくいかんな〜。 そもそも音声通信を捉えるのが意外とムズくてねぇ。 前スレ549氏提供のM-CELPコーデックのTX側を見つけそれに音声突っ込んでみて、 そこから比較分析をしてみようか考えてみたが、 技術力が追い付かないことに気付き断念したぜ(笑) あー、送信前のコーデック変換に無音入れてみて、その出力とF-chの無音部を比較してみるってことか >>616 615です。参考にして頂けたら幸いです。 601などの出力結果に受信時刻のタイムスタンプを追加する良い方法などありますでしょうか? 後から照らし合わせする場合に捗るかなと思ったのですか。 >>619 追加実装が必要ですが、binファイルのファイル名に日時を入れる方法が考えられますね (1フレームは40msですので、各フレームは先頭からの相対時間で求められると思います) スケルチが閉じたらファイルも閉じて、次に開いたときには別のファイルに書き込む、というのが良さそうです GRCのOOTモジュールは自分には荷が重いので、外側で何とかならないか検討してみます ubuntu とか言うの入れてみた 昔に比べると子供でもできるレベルまで簡単になってて驚いた 615です。 firedep 321と325ですが321もY浜市消防局のような気がしてきました。 1ヶ所の消防局でfiredepが2種類以上存在することはあるのでしょうか? >>622 横浜の団体コードは連番で5つ、団にも振ってあります。川崎は4つ、相模原は3つ。 東京はなんと13も割り当ててあります。 参考まで。 >>623 なるほど、そうなのですね。参考にさせていただきます。 5つとなると区域でわけてあるのかな? すみません>>180 のファイルをもう一度アップしてもらえないでしょうか? >>625 とりいそぎ現時点での全部入りをupしておきます ttp://fast-uploader.com/file/7074515536006/ 不具合ありましたらお知らせ下さい 申し訳ありません>>223 の95MBのファイルの誤りでした。もう一度アップは可能でしょうか。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる