【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。
コテハン推奨。
前スレ
【C4FM】デジタル信号復調【π/4DQPSK】
http://mint.2ch.net/test/read.cgi/radio/1434951910/ 共通仕様書を行政文書開示請求したら
さらっと全文開示したりするかもよ?
一件300円で出きるから消防庁宛に試してみるか f f 490 c b79 d 724 0 98e c 332 9 b2e 6 035 d a3e 6 0dd f 16b 4 c3e e e49 0 e00 2 f2d 3 247 7 06
f c 490 e b79 f 724 0 98e d 332 b b2e 5 035 f a3e 7 0dd e 16b 4 c3e f e49 1 e00 3 f2d 2 247 5 06
d e f0e f 01f 0 120 1 231 2 342 3 453 4 564 5 675 6 786 7 897 8 9a8 9 ab9 a bca b cdb c dec d ef
0123 1234 2345 3456 4567 5678 6789 789a 89ab 9abc abcd bcde cdef def0 ef01 f012
0 1 2 3 4 5 6 7 8 9 a b c d e f
インターリーブのパターンと関係あるのかな? 新参者です。周波数パスのヒントをお願い出来ませんか >>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 とか言うの入れてみた
昔に比べると子供でもできるレベルまで簡単になってて驚いた ■ このスレッドは過去ログ倉庫に格納されています