【C4FM】デジタル信号復調 2 【π/4DQPSK】 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
各種測定器、SDR、ソフトウェアなどを最大限に利用してデジタル通信の復調にチャレンジする人たちが集うスレです。
コテハン推奨。
前スレ
【C4FM】デジタル信号復調【π/4DQPSK】
http://mint.2ch.net/test/read.cgi/radio/1434951910/ おはよございます。
当スレもどうぞよろしくおねがいいたします。 でもDNVさんはね
笑止千万のキロワット免許ですよ
で爺たる 保守を兼ねて・・・消防・JR・タクシーなどの各種デジタル波の解析期待しています。 検索すると神戸ハーバーなんたらの警備とかで使われてるらしい
都会は聞けるデジタル波多いのかも >>12
神戸ハーバーランド以外にも、413MHz帯のデジタル一般業務無線の半分はDMRだろ。もう半分はNXDN。 >>11
使われてるとしたら、VU簡易のデジタル化かな?
それしかないか >>13
おお、そうなのか
DMR、適当に当たりをつけて聞いてみよ >>15
一般業務無線のデジタル化だろ。
甲子園球場もVHF帯の一般業務無線を使っていたのに、400MHzのmototrboに移行した。 >>17
MotoTRBOってそう言やDMRのトランキング派生規格だったか
DV1でも復調出来るの? AR-DV1はアマチュアデジタルとデジタル簡易しか無理なはず お前ら、メーカーの公式サイトくらい見てから書き込めよ。
http://www.aor.co.jp/ar-dv1/
日本国内でポピュラーなデジタル簡易無線(登録局/免許局)はもとより、業務用デジタル通信の世界標準でもあるTDMA方式を採用したMOTOTRBO、
DMR方式のデジタル通信、北米/オセアニア地域で警察、消防、救急などの公共安全通信に採用されているAPCO P25方式の復調が可能です。
その他アマチュア無線において使用されているD-STAR、八重洲無線C4FM、アルインコ EJ-47の各デジタルモードへも対応します。 DSD+で聞ける?
こっちは田舎でほとんど聞けないけど、413辺りの割り当て? >>24
ほらよ。
http://www.tele.soumu.go.jp/musen/SearchServlet?SC=1&pageID=3&SelectID=5&CONFIRM=0&OW=FB+0&FF=413&TF=414&HZ=3&SK=2
他にも300MHz帯にもデジタル一般業務無線の割り当てがある。 >>25
システムエラーが発生しました。??
??
??
??
ヘルプ編集
????
総務省ホームページ
総務省の情報通信政策に関するポータルサイト >>26
普通に見れるが。
というか、無線局等情報検索で413MHz帯の基地局を検索しただけだろ。 >>26
URL途中で切れてるだろ
リンクされてないのもURLだぞ http://www.icom.co.jp/release/20170214/
IC-R8600発表されたね。
裏ファ−ムでコッソリ対応しないかね>消防・JR等 >>31
それなwww
消防デジタル対応(復調)できるなら、30万でも買うわwwwww このスレ的な使い勝手はDV1より期待できるのかな? >>31
当然簡易無線の秘話対応とかしてるんだよな 裏コマンドでK撮無線聞こえるなら
30万出してもいい。
秘話コードは高速スキャンで解読できるの。 TETRAな防災行政無線とか空港MCAはteliveとかでデコードできるんじゃないかな。
あいにく自分の周辺にはTETRA局がないから試せずですが・・・
https://www.youtube.com/watch?v=De6RZao8Yu4&t=4s デジタル携帯とかデジタルコードレスとか電話系はどうでもいい
公共性の高いJRデジタル、私鉄デジタル、高速道、タクシー、デジタル同報ぐらいは聞けるようになってほしい >>40
それだな
携帯とか全く興味なし
警察、消防、鉄道、高速だけ聞ければ 人畜無害の一般人が、警察聴けてどうすんの、という気はするのだが……
反社が改造して傍受に利用しかねない、という理由でデジ受信機が止まってるのだとしたら、
鉄道無線とか聴いてるだけの身としては大迷惑この上ないという気もする >>43
一般人が鉄道なんて聞いてどうするんだよ
乗車中なら車内放送、駅なら構内放送を聞いて指示に従えばよろし
家にいるなら情報自体不要 おっしゃるとおり。
聞けてどうするの?といわれれば、それまで。 俺は携帯電話の通信が聞きたいな。
悪質な政治家の通信を傍受したい。 >>46
何千万回線の中の一つを探し当てるとかもうねw 昔アナログ聞けたころは、基本料が月8万くらいで、確かに政治家や企業社長に高確率で当たっただろうが、今の小学生がスマホ持ってる時代は、天文学的に幸運がないと無理だな >>50
それだなw
昔は永田町でスキャンしたら結構凄かったわ
あと移動警電も 民進は公安か警察が監視してるはず
テレビでやってた >>50
あの頃はお水とかヤクザも多かったな。
聞いてて怖くなる会話を何度か聞いたわ 政治家の通信は常に国民が聞けるようにして
違反なところがあったら警察にすぐ
通報できるようにしてほしい。 そんなのすぐに揉み消されて電波法違反を被せられて薮蛇 悪質な政治家向けに憲法違反の施策が実行されると
自分自身にも適用されうる状態になるって事が理解できないのか
他人事じゃないんだよ >>46
アナログ時代は、ある程度は基地局ハンドオーバーまで追いかけられたから面白かったな。
基地局で持ってる周波数も限られてたし。
アマチュア機にクラニシのFC308Wっつうコンバーター使って聴いてた。 デジタル化された周波数の傍受することは可能なのでしょうか?
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1343363903 DSDのNXDN部分のソースを弄ってDCRに流用できたりしないだろうか。
https://github.com/szechyjs/dsd >>67
コードレス受信、再びか。
DECTって国内でどれくらい普及してるんだろうね。 STD-T101準拠として、パナソニック、シャープあたりから発売されている。
1.9GHzだし、TDD-TDMAだし、PHSと何が違うんだろ。変調方式か。 今売っているのはDECTが主流だけれども、普及率はどうなんだろうね。
未だにアナログ使ってる家もあるみたいだし。 アルインコのアマチュア無線のデジタルは復調良いですか?
内緒話に使いたいんだけど >>68
リンク先見ればわかるけど
音声は無理だぞ >>70
いまのところ2.4GHzが多いような気がするけど、固定回線自体がもうなぁ・・・ 前スレ>>43のT79報知情報表示プログラムうpしてくれないかな。
T79波は結構捕捉できているんだけれど、少しでも情報が見られたらなって思う。 どっかに纏めてうpってくれると有難い。おなしゃす、エロい人。 春オン、デジ簡は業務局とヘビー QRM 起こしてたな。ケロってどっちもデコードしないという。 .
★★べっぴんさんでしょう?★★
http://nx47.com/modules/rssc/single_feed.php?fid=31622446
上から5,6枚目の写真の帽子をかぶった右側の女の子がわたくし中里牧子よ。
■http://log.d-star.info/usr/view_log.html
■コールサイン欄にjp7elnを挿入してみよう!!!
※閉経ばあさん、追跡列伝。笑えます。無料公開中。
.
D-STAR クイーン登場!
. >84
だな。 ゆーちゅーばーとかが動画で水平偏波運用を奨励でもしない限り、広まらないだろうけど。 混信対策として何を推奨してるかと言えば、秘話だもんな。
対策になってない。
ユーチューバーは電波工学も知らん連中ばかりだから、仕方ない。 確かにゆうちうばぁの奴等のテクニカルな知識は、違法 CB トラッカー以下だしなぁ・・・ ___
/ || ̄ ̄|| ∧_∧
|.....||__|| ( ) どうして現場に血が流れるんだ・・・
| ̄ ̄\三⊂/ ̄ ̄ ̄/
| | ( ./ /
___
/ || ̄ ̄|| ∧_∧
|.....||__|| ( ^ω^ ) どうして現場に血が流れるんだ!?
| ̄ ̄\三⊂/ ̄ ̄ ̄/
| | ( ./ /
___ ♪ ∧__,∧.∩
/ || ̄ ̄|| r( ^ω^ )ノ ララララララ!
|.....||__|| └‐、 レ´`ヽ サムバディトゥナイ!
| ̄ ̄\三 / ̄ ̄ ̄/ノ´` ♪
| | ( ./ /
___ ♪ ∩∧__,∧
/ || ̄ ̄|| _ ヽ( ^ω^ )7 ララララララ!
|.....||__|| /`ヽJ ,‐┘ サムバディトゥナイ!
| ̄ ̄\三 / ̄ ̄ ̄/ ´`ヽ、_ ノ
| | ( ./ / `) ) ♪ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) ___
/ || ̄ ̄|| ∧_∧
|.....||__|| ( ) どうして現場に血が流れるんだ・・・
| ̄ ̄\三⊂/ ̄ ̄ ̄/
| | ( ./ /
___
/ || ̄ ̄|| ∧_∧
|.....||__|| ( ^ω^ ) どうして現場に血が流れるんだ!?
| ̄ ̄\三⊂/ ̄ ̄ ̄/
| | ( ./ /
___ ♪ ∧__,∧.∩
/ || ̄ ̄|| r( ^ω^ )ノ ララララララ!
|.....||__|| └‐、 レ´`ヽ サムバディトゥナイ!
| ̄ ̄\三 / ̄ ̄ ̄/ノ´` ♪
| | ( ./ / 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) >87
「DCR で蛍光灯が点灯」って動画で、「ショートアンテナだと点きます」って・・・ 大変ご無沙汰してます
前スレ>>963>>970に触発されて調べました...
やったこと&分かったこと:
・FM-807F02(EF-6190)のROMを読み出してファイル化する(2MB)
・DSP部分の190000-1bffff(192kB)を切り出して、さらに32kBブロック6つに分ける
・ブロック1と2, 3と4, 5,6が組みになっているので先頭から交互に1バイトずつ読み出して64kBのブロック3つにする
・1+2がPAGE1(18000-)、3+4がPAGE2(28000-)、5+6がPAGE3(38000-)の中身
・PAGE1はデータ領域でPAGE2と3がファーム
・ファームは"-m tms320c54x"が使えるobjdumpを使えばディスアセンブルできる
・ファームのバージョンは192kBの末尾24バイトを見ると分かる(手元のはup205r57 2007/08/22)
・CELPモジュールのエントリは292aa, 29311, 29365(初期化,エンコード,デコード) >>100
おお、凄いですね。
その吸い出したコードを同じDSPに食わせたら、あの無線が聞こえるかもしれませんね。 >>101
本当にM-CELPだったら嬉しいですが、今一確信が持てていなかったりします
音声のデコードだけなら、FM-807F02のRS-232へTCHの中身を突っ込むと
スピーカーから音声が出てくるようにMPU側ファームを書き換えられれば... >>103
P35の表3-16には、m-celpと書いてある。 >>103
ありがとうございます。p35に"M-CELP"とハッキリ書いてありますね...
これを信じて解析を進めてみます >>102
MCAccess eには録音/再生機能があるので、そこのバッファを乗っ取れれば、音声を再生出来るのではというアイデアの話です
念のため
>>104
ありがとうございます もし成功したらヤフオクの中古MCA機がバカ売れするのかな どなたかFM-807F02/EF-6190のシリアルコンソールが引っ張り出せた方がおられましたら方法を教えてください
>>108
まだ全然そんなレベルじゃ無いです... PSI-CELPってどうなんでしょう?
どこかの特許とか絡んでいるのでしょうか? >>112
PDCハーフレートだよね。今さら何をするの?
開発は横須賀通研だから、特許はNTTが持ってるんじゃないかな。 ARIBの規格の付録でサンプルコードがあったような気がする。 >>113
素人なんでサッパリなんですが、RL-CELPの原型と書いてあったのを見掛けたので、お聞きしました。 中途報告です
(up205r57 2007/08/22を前提にした話です)
・プログラムは292aa〜2966bと2c68f〜2f9d6 前者は外部とのインタフェース、後者が本体
・データは1dfb0〜1f9f3 固定コードブックやμ-LAW変換テーブルなど
・ワークRAMは8kワード(16kB)程度使っている模様
・データフレームは、インターリーブとは別に3つのランダマイズパターンがある模様
・CELPモジュールのデコード入力は138bit単位、出力は320ワード単位(1単位40ms)
生フレームが138bitというのは、「無線脳の視点」さんのM-CELP情報とも合致しますね... >>116
すごいですね
ROMをどうやって読み出してるんだろう >>117
基板からROMを剥がして、ROMライタを使って読み取ってます メーカーとか出版社の特殊部隊に後は任せたい気分です... >>118
すごいですね! EF-6190が手元にあります。
TIのDSP,NECのチップ,パナのCPUらしきものなどが見えますが
ターゲットのROMがどれが教えていただけないでしょうか。 >>121
ROMはCPUやDSPの反対面にある、東芝のTC58FVT160ATG-70です
これにMPUとDSPの両方のファームが含まれています
DSPのファームの組み立て方は>>100を参照してください ついでに
FM-807F02とEF-6190のファームが同一なのは確認済みです
FM-857F02/EF-6195A(新型MCA)はファームも新型ですので、別途解析が必要ですが、まだやってません >>122
549さんありがとうございます、ありましたー
自分のには黄緑の〇シールがついてました。
これは敷居が高いなぁと思います。
何とかうまく行ったら20年前のC54xアセンブラに
登場してもらおうと思います。
行かなかったときは、またご相談させてください。 >>124
ROM外しは、お知り合いにハード屋さんが居られるようなら、お任せするのが良いでしょうね...
かなり悩んだのですが、ハードをお持ちの方なら問題なかろうと思い、セーブ領域を除いたファームをupしておきました
ダウンロードパスは、裏蓋に書かれている技術基準適合証明番号の先頭9桁で、展開パスは、裏蓋の一番上の行全体です
ttp://fast-uploader.com/file/7049362643618/
C54xアセンブラは今回の件で勉強を始めたところなので、経験者の方からのご助言を頂けるとありがたいです またまたついでに
FM-857F02(新型MCA)のファームをざっくり調べました。0x320000-0x34ffffがDSP部分で、組み立て方はEF-6190と同じです
M-CELPと思しき部分に関しては、外部インタフェース側は2関数増えていましたが、本体は全く変わらずでした >>125
121です。ありがとうございます。
ほんとに以心伝心ですね。.bin(2031616byte)受信できました。
当方はC54xDSKが手元にありますが全くシロウトですので
549さんのお役にはとても立てないです。。
お礼に昔遊んだときのデータをお送りします。
ttp://fast-uploader.com/file/7049392377638/
ダウンロードパスは、125でいただいた技術基準適合証明番号に
該当する全て(11桁)で、解凍パスはbinと同じです。
(ちょっとドキドキですので流出なしということで・・) >>121です。up205r57....20070822....(.=0x00)確認しました。596さんには脱帽です。
10年ぶりのCでフレーム構築してみます。 >>127
度々すみません。番号がたくさんありました。
10番目は125の6桁目のHEX読み-9、11番目は同様に-3でお願いします. >>127
頂きました。ありがとうございます...
蛇足で、組み立てた各ページのバイナリとページ1のHEXダンプ、ページ2,3のディスアセンブルしたものをupしました
ダウンロードパスは、プリント基板の"PbF"の下に書かれている、基板の品番の、末尾1文字を除いた7文字です
展開パスは>>125と同じです
ttp://fast-uploader.com/file/7049465101036/
どなたかが別CPUへ移植してくれることを期待してます... ピン数多いチップの取り外しはchip quikみたいな低融点はんだがオススメ
あるとないとでは難易度かなり違う >>133
お疲れ様です。
基盤の品番の末尾抜きましたがダウンロードできません。
R25の左に書いてある品番ですよね? >>135
基板表面の、DSPの下、CPUの左あたりの大きなシルク印刷です
R25は印刷されていませんので、それは別バージョンの基板かもしれません... すいません、旧スプリアス基準(証明番号の末尾が03)の無線機は別基板でした...
改めてダウンロードパスを変えてupしておきました
ttp://fast-uploader.com/file/7049508271637/
>>135
よろしければこちらもお試し下さい >133
121(=124=127≠135)です。資料いただきました、ありがとうございます。
昨日組み立てた3PAGEは同じ内容になりました。自分のCodeExplooerがWin95専用なので
先に進むのに時間かかりそうです。
127届いてよかったです(少し拡散してしまいました...)。
ご興味があれば別ad送りますのでご連絡ください(その時は何かキーワードいただけると
助かります。PAGE3のアドレスFFD5〜FFE3のFF除く8文字など)。 >>137
無事ダウンロードできました!
ありがとうございます!
お騒がせしました。 >>133
蛇足の蛇足で、CELPのデコードに必要な部分のみ切り出したものを作ってみました
ttp://fast-uploader.com/file/7050064635546/
ダウンロードパス、展開パスは>>125と同じです
ディスアセンブルリストも、中途半端ですがちょっと読みやすく整形してあります
申し訳ありませんが、MPU側の録音・再生部分の解析に篭りますのでDSP側は一旦手を離します... スレチかもしれないが、京急とか小田急のデジタル列車無線の仕様とコーデックって何ですかね?
京急のは三菱の提供だから改良型RL-CELPだったりするのかな? ん?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の無音時のフレーム(秘話解除後)が手に入れば、それと比較することで大きなヒントになり得ると思います
出来ることをガンガン進めたいですね! >>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
メーカーの違いなら各地域ごとの入札結果から使用しているメーカーを絞りこめる場合もあるので
照らし合わせてみると面白いかもしれませんね。 う〜ん、インタリーブ手強いなあ。早く解きたいぜ。規則性を見出したい。
まさかこれフレーム間同士でインタリーブされてないよね? 気分転換に河原を散歩してたら、誰かが捨てた共通仕様書落ちてたりしないかな… とりとめの無い駄文失礼します
無音部から有音部に移るところですが、TCHの前半分が無音で無いビット列、後ろ半分が無音と同じビット列になっているのが散見されます
逆に有音部から無音部へ移る時も、TCHの前半分が無音と同じビット列、後ろ半分が無音で無いビット列となっているのが同様に散見されます
というのは、前スレ624あたりに書いたのと重複するのですが、
CELPのほうの解析によって1フレーム138ビットの内訳が以下のようになっているのが分かりました(decode.cのfunc_c975のコメント参照)
8 + 12 + (8 + 16 + 7 + 5 + 16 + 7) + (8 + 16 + 7 + 5 + 16 + 7) = 138(bit)
カッコ外の20ビットはフレーム共通、1つ目のカッコ内が前半20ms、2つ目のカッコ内が後半20msのデータですが、
よって、後ろのカッコの59bitをエンコードしたものが前半128bitの一部に、前のカッコのほうは後半128ビットの一部に混ざらずに割り当てられていることが強く推察されます
これがインターリーブのヒントになるんじゃないかと踏んでいるのですが、頭がパンクしそうです
ご参考まで >>284
上記の推察と、「遅延:85ms以下」という情報をあわせると、フレーム間インターリーブはしていないんじゃないかと思ってますが確信は無いです >>287
138ビットの内訳での8 + 12のフレーム共通とは各フレームともに共通ということですか? >>288
共通仕様書は制御系インターフェース部分の解説はあってもその他の規格はARIB STD-T61がベースだった気がします。 ここのところコーデックのフレームの構成のこと話してるのになんでここで共通仕様の制御系インターフェース??
怪しいと思ってたけどこの人本物じゃないよね?MCELPボードも「ぼく見たことあるもん」って子供かよ
知らない人が無理して書こうとして墓穴掘ってるように見えるんだが >>291
スルーすればいいのに
貴重なレスに横槍入れて邪魔すんな >>291
トリップついてるから本人でしょ。
2ちゃんねるの事あまり知らないのに無理して書いて墓穴掘ってますなw >>296
書いちゃっていいのか?
G1Eさんは前スレでお客さんがどうこう書かれてるから納入業者の人か何かで
技術のことは政治的な理由か何かで一度も書かれたことはないけど
本当はエンジニアさんだから詳しいことをトボケて聞いたらポロっと答えてくれるかも
ってことでしょ?
>>291は書かないことと書けないことの違いがわかってないから論外だけどね
もうやめたほうがいいでしょ? >>240
失礼します
ファイルが消えてしまいましたので改めまして...
ttp://fast-uploader.com/file/7055574420140/
>>240と同じファイルですのでお持ちの方は改めてのダウンロードは不要です
ダウンロードパス・展開パスは以前と同じ >>125 の通りです >>289
そのフレーム内での共通のパラメータという意味で書きましたが、分かりづらいですよね...
別々のフレーム間では内容は異なると思います
余談
8 + 12 は (1+7) + (6+6) だったりしますが解析する力が尽きてます >>290
>>299
いろいろ申し訳ないです
実生活に面倒の及ばない範囲で、これからもお願いいたします... >>301
289です。なるほどそういうことでしたか。お答えありがとうございます。
無音以外も含めた各フレームでの共通部分なんかがあればいいんですがね。 >>301
古い資料ですがRCR STD-27の5.2.2はお読みになりましたか?
関係あるように見えますが、どうですか? >>302
前にメールいただきましたっけ?
共通仕様書には通信制御な内容(一斉通信とか個別通信とかグループ通信とか割込切断とかデータ通信とかそういうの)は書いてあっても、三菱CELPの音声符号化に関することは書いてないんです。
その点で考えれば、特定のコーデックを使ってない東消のほうが前スレ549さん向きかなと。 >>305
周回遅れで参加したもので話題に乗り遅れてしまい、メールは送っておりません
三菱CELPはハードウェアモジュール供給とのことで、内部を詳述したものは無いのかもしれませんね...
尚、AMBE+2のチップは既に手に入れております
M-CELPデコードに関しては、行き掛かり上、このままライフワークにしようかと思っております >>304
STD-27を確認しました。PSI-CELPですね
M-CELPもこれの改良発展系だったと思いますので、インターリーブやエラー訂正の考え方等、参考にしたいと思います
ありがとうございます こんばんは
毎度駄文を失礼します
CELPの送信側の解析をまとめました
(1) CELPモジュールから出力された138ビットは、18+23+43+54ビットとして別々に計算し、84+54ビットとして格納します(func_f82f)
(2) この84ビットの先頭18ビットと末尾23ビットを使ってパリティ演算(func_f5cb)をし、その結果を84ビットの前に4ビット、後ろに5ビット連結し、93ビットとします
(3) (2)の93ビットの後ろに0を8ビット付けた101ビットを、R=1/2, K=9の畳み込み演算をして、202ビットにします(func_f5ab)
(4) その202ビットと、(1)の54ビットを連結し、256ビットにします
(5) (4)をインターリーブします(func_f7ac)
(6) (5)を(1/2/4フレーム間)インターリーブします(func_f777/func_f721/func_f74c)
(1)にはconst.cの末尾にある "voice frame offset/voice frame bit position" が使われています
このテーブルがモジュールパラメータだとすると、このテーブルをFチャン仕様に再構成することが全てでは無いかと考えています
(以下妄想)
FチャンがM-CELPを採用するにあたって、何も実績が無いcodecをいきなり新規採用するとは考えにくいので、MCAデジタルでの実績を基に売り込んだんじゃ無いかな?
その際モジュール内部のロジックを弄っては元も子もないので、このテーブルと、フレーム間インターリーブ方式等の、モジュールパラメータだけを変更したか?
(妄想ここまで)
R=1/2, K=9の畳み込み演算というのが確定したので、総当り演算量はかなり減ったと思います
K=9というのが地獄ですが... >>309
k=9確定ってのは、>>309に書かれてる仮定が正しければってことですよね?
それとも他にソースありましたっけ >>310
まあ、仮定といえば仮定ですね
ファームのディスアセンブルリストからロジックを拾い出したものですので >>311
そもそもFがK=9確定っていう話はしてない感じですか? >>310
>>312
549さんが行っている解析はFチャンがこのデジタルMCAと同一コーディクであることは仮定(前スレなどから挙げられた資料からFと同一名のコーディク)ですが
そのデジタルMCAのファームを逆アセした結果このデジタルMCAでの畳み込みがK=9であることが確定したということでは? >>312 >>313
変な仮定をすると嵌るかもしれませんが、
何も仮定をしないと先に進まないので、これで進めています
Fの無線機?受令機?のファームが入手できれば別ですが(前スレには入手された方も...
人それぞれ色々なチャレンジがあっていいと思います >前スレなどから挙げられた資料からFと同一名のコーディク
マジすか!見落としてました
ホワイトニングないなら総当たりでいけるかもしれないですね! >>314
313ですが私もいろんな方向性があってそれぞれ解析をすすめられればいいと思います。
むしろそのほうが盛り上がりますし進展も早いかもしれませんし。
去年のFハンディのヤフオク騒動を思い出しました。。。 >>312 >>313
まあでも、convolution/deconvolutionに関しては、全然違うかも知れんとも思ってます
FチャンTCHのビット列を薄目を開けて眺めると、16ビット毎の周期性が見られるみたいなので >>249
そろえたら次はSDR#で受信できればいいんですか? >>318
SDR#で、274.000MHzを中心に受信してみてください
ちょっと太めの縦線が出ていれば受信できているはずです >>249
250です。国際郵便で時間かかりましたがブツ届きました。
お手数ですがデータの提供方法教示ください。余ってるwindowsマシンあります。
環境整ったら地元や実家など複数の消防波受信してきます。 >>321
青いヤツ(R820T2)を買われたと仮定してお話します
アンテナは274MHz周辺の受信できるものを、出来るだけ見晴らしの良いところに設置します
郊外ならお手軽にスリーブアンテナ等で良いでしょう
都会なら、アーバンノイズに強い『磁気ループアンテナ(スモールループアンテナ)』が効果を発揮します
付属のアンテナと基台は波長が合わないのであまり使い物にはならないです
基台の下側のシールを剥がすとケーブルが外せますので、MCXコネクタの付いたケーブルとして利用するのが良いと思います
次は、SDR#をインストールして既知の周波数の電波を受信してみてください
(SDR#の詳しい使い方は割愛します)
地元のFMラジオ等が良いと思います
ここでUSBドングルの周波数のズレを把握しておきます(歯車メニュー⇒Frequency correction(PPM))
暖まるまでは結構ズレますので、気長にやりましょう
ppm単位でだいたい合わせられたら終了です
次に、274MHz±1MHzを受信して、電波が出ている周波数を把握してください
Snap to Gridにチェックを入れ、Step Sizeに6.25kHzを指定すると分かりやすいです
見つかった周波数を全てメモしておきます
連続送信している局があればbestです
(一旦ここまで) >>322の続き
次に、>>223に書いてある環境を構築します
USBメモリは出来るだけ速いのが良いです。遅いヤツだとGUIが立ち上がるまでに無茶苦茶時間がかかってしまう場合があります
これはUSBメモリのせいだけではなく、PCとの相性もあるようです
USBメモリから起動したら、まずは端末を起動し、volk_profileコマンドを実行しておきます
volk_profileの結果はUSBメモリに記録されますので、一度きりで良いです
(PCを変えたりする場合は再度実行すべきですが)
次に本題のGRCを起動します。起動すると、既にt61.grcが読まれている状態になると思います
(なってなければ"Open an existing flow graph"→"t61.grc")
中段左にある"RTL-SDR source"をダブルクリックして、"Ch0: Freq Corr.(ppm)"に以前調べた誤差値を入れてOKを押します
その他は多分いじらなくてOKのはずです
次に、上のメニューバーの、緑の右三角を押すとt61.grcが実行されます
連続送信している周波数が見つかっていればそれを"Frequency"に入れます。無事コンスタが出れば、"Fine Tune"を弄って真っすぐにします
("Frequency"や"Fine Tune"はマウスホイールでも操作可能ですので簡単に微調整できると思います)
この状態で、"Monitor"タブに切り替えると、ビットマップが表示されていると思います
また、ホームディレクトリに"output.bin"というファイルが出来ています。それが受信データになります
受信の終了は、"pi/4 DQPSK demodulator"ウィンドウの左上の×をクリックします
GRC側のメニューの×をクリックすると、受信アプリの強制終了になってしまいますので好ましくありません
(一旦ここまで) >>323の続き
出来上がったoutput.binは、端末を起動して、コマンドを
100 < output.bin > output.t61
500 < output.t61 > output.txt
と実行すると、テキストファイル(漢字はShift-JIS)が出来ます
そのままUbuntu環境で見る場合は、"sudo apt-get nkf" をした上で、
nkf output.txt | less
等で見てみてください
Windows等で見たい方は、
sudo cp output.txt /cdrom
と実行すると、USBメモリのFAT32エリア(casper-rwがある場所)へ書き込めますので、
リブートしてWindows等を立ち上げ、USBメモリのルートディレクトリをチェックしてください
(毎回毎回scandiskが必要なのはUbuntu側の問題だと思いますがご愛嬌)
とりあえず以上です
駄文散文失礼しました こんばんは
>>309 の最後に書いたことですが、間違いでしたので撤回します...
R=1/2, K=9の最初と最後の状態遷移のビットパターンを正順逆順インターリーブ・オフセット有で全検索しましたが、見つかりませんでした...
TCHの前半後半の相関をハミング距離から求めようとしましたが、これも相関無しっぽいです
やはり前半後半が別々に符号化されている可能性が高いみたいです
69ビットを符号化して128ビットになる符号化パターンを探さねばなりませんが、仮にパンクチャが絡むとすると、大変難しいです >>326
多項式に触れられていませんがCDMA等と同一の(g0,g1)=(657, 435)octで検索されたのでしょうか
多項式が標準的なものではない可能性も残っていると考えておいて良いですか? >>327
IS-95 CDMAの多項式
G1(D) = 1 + D4 + D5 + D6 + D8
G2(D) = 1 + D + D3 + D5 + D6 + D7 + D8
を使用しました
多項式が違う可能性はあると思います やっとUbuntu環境立ち上がった
非UEFIなx64環境だとunebootinが不調でした
そしてT79はアイパターン見えたけどT69は見えない
というか普段電波出てない??
別PCのRTL-SDRで見てるとたまに出てる感じがする
ちなみに24県の?市 >>322
うちのあたりだと、6秒送信8秒停止を同期してる周波数が複数見つかった
通話のあるときだけ送信されてるわけじゃないんですね 毎度思い付きレベルでスミマセン
音声TCHって、フレーム間インターリーブしてるかも知れんなあと思い始めました
nフレームの前半とn+1フレームの後半に相関が見られる気がしませんか...? なかなか難儀なんでこれからデジタルMCAのTCHとデータ比較してみたいと思うんだが、先例でそもそものデジタルMCAのTCHから音声復号に成功した人いるすか? ubuntuの扱い方から始めないといけないな
output.binはできるけど、その後のファイルが0byteになってしまう ちゃんと周波数とコンスタとれてる?それだけでbinに落ちてくるっしょ? binはできるけど、txtにできないんです
ubuntuの操作ミスなんだろうけど
100
500
ってコマンドがググってもよくわからない やっとできたー
triple県 00100010XXXXでした
IDLE/FREEは>>281の2のパターン 受信実行中に、別ウィンドウで
tail -f output.bin | 100 | 500
とか起動すると、擬似リアルタイムデコード表示になります
(終了はコントロールC)
output.binに影響は無いのでお試しあれ F-D
ARIB STD-61(SCPC方式)
変調 4πシフトQPSK(9600bps)
音声コーデック M-CELP >>337
ありがとうございます
データらしきものが見えるようになりました
周波数設定がシビアなのか、RICHやRCH/SACCHっていうのが見えたり見えなかったり… コンスタレーションがきれいに出ないから放置してたら、
・・
・・
みたいに、いつの間にか教科書通りのきれいなコンスタレーションが出るようになってたw PICHの4フィールド目の先頭8ビットのまとめ(想像を含む)です
訂正歓迎です
00000000 北海道
00000001 北海道
00000010 北海道
00000011 北海道
00000100 青森
00000101 岩手
00000110 宮城
00000111 秋田
00001000 山形
00001001 福島
00001010 茨城
00001011 茨城
00001100 栃木
00001101 群馬
00001110 埼玉
00001111 埼玉
00010000 千葉
00010001 千葉
00010010 東京
00010011 神奈川
00010100 神奈川
00010101 新潟
00010110 新潟
00010111 富山
00011000 石川
00011001 福井
00011010 山梨
00011011 長野 >>343の続き
00011100 岐阜
00011101 岐阜
00011110 静岡
00011111 愛知
00100000 愛知
00100001 愛知
00100010 三重
00100011 滋賀
00100100 京都
00100101 大阪
00100110 大阪
00100111 兵庫
00101000 兵庫
00101001 奈良
00101010 和歌山
00101011 和歌山
00101100 鳥取
00101101 島根
00101110 岡山
00101111 広島
00110000 山口
00110001 徳島
00110010 香川
00110011 愛媛
00110100 高知 >>344の続き
00110101 福岡
00110110 福岡
00110111 佐賀
00111000 長崎
00111001 熊本
00111010 大分
00111011 宮崎
00111100 鹿児島
00111101 鹿児島
00111110 沖縄
00111111 沖縄
例外があるようなので、とりあえずの目安としてご利用下さい 2進数で管理してないし。違っても 例外 ではないよ。 そろそろ前スレ549氏は捨てアド晒して地下に潜った方が情報集まると思いますよ?
我らには経過報告さえ入れてくれたらよろし。 >>348
いやいやいや、ちょっとまってお前何言ってんの?
我らには経過報告さえ入れてくれたらよろしとか、なにその上から目線。
しかも”我ら”って。我らじゃなくてそう思ってるのはお前だろ?周りに聞いてもないのに周りを巻き込むなよ。
はなっから他力本願でまじむかつくわお前。
前スレ549氏だって時間を割いて解析に挑んで、それでもなかなか難しいからこのスレで
解析結果とか具合とか示してくれてるし、前スレ549氏以外にも微塵かもしれないが複数人が手伝って情報提供とかやってきてんでしょが。
俺だって音声がデコードできたらそりゃワクワクするから手伝いたくて技術力無いなりに色々勉強してるぞ、そういう互助精神あってもよくないか?
なんもするつもりもなく情報が降りてくるのを望んでるんだったら黙ってスレ覗いてろバカ! そだね。
俺は何ヵ月か前から黙ってROMってます。 なんか「我ら」がツボにハマったw
ここに書いてあることは誰でもできるレベルだから
みんな挑戦してみればいいかと んで?そのずっとROMってることを公表してどうした? sage忘れスマぬ、>>352は>>350に対するレスです念のため >>349
ちょっと落ち着け。>>348はかなり言葉足らずだが、多分549氏の身を案じての書き込みだろ。俺はそんな風に感じた。
みんな方向性は同じだから、仲良くしようぜ。 >>354
取り乱し、大変失礼いたしました。スレを汚してしまって申し訳ないです。
前スレ549氏の身を案じているのだろうと私も感じていたものの、つい・・・
仰せの通りです、今後とも仲良くやりましょう。 どうなんだろう
下手にグループを作ると組織犯罪の対象になりそう >>354
あら、騒がしちゃったね。
過去に公表されてた資料を掘り出して持ってる人がいれば、直接ぶっこんだら近道もあるかなと思ってさ。
消防団体コード自体は最大1023なんだし、消防の場合は県別のコード管理にはなってないと思うんだよね。 >>355
大丈夫。
仲良く楽しくやろう。
>>357
気にしない。
確かに連絡先あるといいかもしれんね。
やっぱりみんなの方向性は同じでヨカタ。
ここは多分唯一無二の集合知だと思う。
俺も何か出来ればいいんだけど。 >>358
それがな、北から若い順に通し番なんだよ。
団体の規模によって連番で複数個割り当てられてる ややこしくなってきた
348 我らさん
349 取り乱しさん
354 集合知さん よっこらしょ。
∧_∧ ミ _ ドスッ
( )┌─┴┴─┐
/ つ. 続 行 |
:/o /´ .└─┬┬─┘
(_(_) ;;、`;。;`| | とりあえず意欲のある人はUSBチューナーで
>322-324を見てやってみるべし
4/πシフトQPSKの復号だから難しくない >>357
どこで公開されてたんだろう
総務省とか自治省あたりか? >>367
じゃあ、過去に公表されてた資料って何? >>368
関東某所の役所の入札公告で、添付資料として共通仕様書が出てた時があったんよ。 >>369
どこの市町村か覚えてる人がいたらここで探し出せないかな
軽く調べてみるとネットからでは見られない物もあるけど
http://warp.da.ndl.go.jp う〜んインターリーブ全然解けそうにないなぁ。早く解きたい。
一体どんな多項式で仕組まれているんだ voiceデータで0の羅列が出る事もあるんだね。これ数行連続で出ましたよ↓
** VOICE ** RCH/SACCH: 00000 TCH: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 それと、無音パターン(と思われるやつ)。
@ff490cb79d724098ec3329b2e6035da3e70dde16b4c3efe491e003f2d2247506
Afc490eb79f724098ed332bb2e5035fa3e60ddf16b4c3eee490e002f2d3247706
無音が続いてると思われるとき、殆どは↑の@とAの繰り返しだったんだけど、
いまさっき@が数行連続で出ることがありましたよ。
必ずしも@とAの繰り返しパターンじゃないんですね >>370
古いページなら過去に遡って
https://web.archive.org/
から見られる。
何がとは言わないが。 デジタルのことは解らないけど
使ってないドングルあるし手助けになればと参戦
団体コードはこれ?@信玄県
RICH: 11 011 001 100 000000 >>38
遅ばせながら入れてみたけど地元じゃやっぱり使われてないっぽい…
防災もT80ではなくT79(NECっぽい)だし
なかなかうまくかないね >>376
ありがとうございました
調べたら>>343の通り
信玄県は00011010でした
現場?地図はgoogleMapなのね 署とガソリンスタンドしか地図に出てこない
田舎は平和だね MCA機ゲットしたけどEF-6195だった…
DECT試そうかと思ったけどRTL-SDR(R820t)だと範囲外なのでE4000なチューナーを買うかどうしようか検討中
アナログBSチューナーからモジール引っ剥がして1.9GHzあたりにセット→IF出力をRTL-SDRにぶっ込んだら見えるかな? ご無沙汰しておりました
個人的に身辺がゴタゴタしていたので長く活動できませんでしたが
ざっと見ただけでも進展があっているようですね
昨年個人的にやり取りさせていただいた方には特に申し訳ないです
以後も精力的に活動したいと思います 日本人は程度が低いなあ。この程度のを解読できないなんてw お手数をおかけして申し訳ないのですが
どなたかスクリプト類を再うpしていただけないでしょうか >>385
自分のupしたものでしたら、>>223 >>237 >>300 のリンクが生きてます
もうすぐ消えるのもありますので、ご入用でしたらお早めにどうぞ >>386
すみません
幾つかアクセスして消えていたのでそれらも消えたものと思い込んでいました
失礼いたしました
これまでの進展に関するファイルは概ね >>223>> 237 >>300 に入っていますでしょうか >>387
Fチャンの受信とπ/4-DQPSKデモジュレート、T61フレームのデコードと可読化(できるだけ)は >>300 に入っています
(ソースはホームディレクトリのGNU_Radio/以下に入っています)
>>237 は、上記に入っている100.cをWindows用に一部書き直したものです Windowsで無ければ不用でしょう
>>223 は、EF-6190(デジタルMCA:旧型)のファームからCELPデコードモジュールを掘り出して、C言語で書き直したもの(不完全につき不動)です
EF-6190のファームそのものと、それからDSPのファームを組み立てたものは現在消えています
必要、かつ本体をお持ちでしたら再upしますが、いかがしましょうか? >>388
ありがとうございます
EF-6190やDSPのファームについては読んで見たいと思いますが
本体が手元にありません
本体を調達すべきであればそのようにいたしますが如何でしょうか >>389
今のところ、F-chとは直接の関係は見出せていませんので、急ぐ必要は無かろうかと思います
F-chのTCH(256bit) → (謎のエラー訂正処理)→M-CELP(138bit) の、(謎のエラー訂正処理)が謎なのです
この部分、デジタルMCAのほうの解析は進みましたが、残念ながらF-chへそのまま適用は出来なかったです
このあたりを精査されたい場合には、実機を入手されてから改めてご連絡下さいませ >>390
有志の方より機材を提供いただけそうなので手元に届いたら改めてお願いいたします 呆けてますね... > 自分
>>388 の説明の、>>300 と >>223 が逆になってます
すんません >>324
Windowsで見ようとsudo cp output.txt /cdromを実行するとsudo cp output.txt /cdromの後に宛先のファイルオペランドがありませんと表示されて困っています
他にWindowsに移動させて見る方法がありましたらよろしくお願いします >>396
別のUSBメモリを挿すと、自動で認識してウィンドウが開くと思います
その場所に、output.txtをコピーすれば良いと思います >>396
俺もスペース開ける場所間違ってソレ出たから
もう一回見直してみて >>381
E4000なチューナーのドングルってまだ売ってます?
売ってるなら欲しい 前スレ549様のT61 Fire解析表示を利用してみました
http://i.imgur.com/1TH4W8b.png >>401
100.cのデバッグメッセージが出まくってますね...
先頭近くの #define DEBUGを#undef DEBUGにしてコンパイルし直すと変な出力が止まります
次のイメージはundefしておきます tail -f record.bin | 100 | 500 | tee -a analysis.txtしておりましたが
幸いデバッグメッセージがエラー出力であったので
analysis.txtは綺麗に保存されていました
標準入出力でデータを加工する方式はプロトタイプには使えますので
この点はこのままの仕様で継続した方が良いと思います >>403
デバッグメッセージで誤解されてしまった方(>>379)もいらっしゃいますので、必要な方は再コンパイルという方向でお願いしたいところです
標準入出力は当面このまま行こうと思います FC0012搭載のチューナーを持ってるけど青いR820T2は買い換えて損はないほど感度はいいかな?外部アンテナ系を強化しようと思ってるんだけど
>>279
明太県で先日初めて挑戦したところ似たようなデータが出たんですがもう一度txtをアップしてもらえませんか?
>>378
地図というのは平時ではなく指令時のみ見れるものですか? >>405
了解です、申し訳ありませんが今夜は泊まり勤務なので明日までお待ち下さいませ。 >>405
デジタル以前の設備の関係か分かりませんが位置情報(DATA)などは地域などの違いで出る波と全く出ない波があるみたいですよ。
自分の地域は全く出ないです。泣 PICH第四フィールド00110110が佐賀のような気がするのですが誤認でしょうか こんばんは
>>223 のリンクが消えましたので、バージョンアップ品をupしました
(空き領域をクリアしたら小さくなりました;約58MB)
ttp://fast-uploader.com/file/7057841519041/
・デコード表示の利便性のために、nkfとfdcloneをインストールしました
・100のマイナーバージョンアップとして101を、500のマイナーバージョンアップとして501を入れてあります
・前の100, 500はそのまま入っています
・100_mingw.cを含むソースは、前と同じく ~/GNU_Radio/ 以下に入れてあります
・~/.fd2rc に書いてありますが、fdを起動すると bin, t61 ファイルをリターン一発でデコードして表示するようにしてあります
・デコード表示の都合で、端末の横幅のデフォルトを140文字にしてあります
・Firefoxのブックマークツールバーに、前スレと本スレを登録しておきました
USBメモリ容量に余裕がある方は、今のものを casper-rw.old 等にリネームしておいて、切り替え可能にしておくと安全です (>>410 の続き)
101は、100の機能+同期ワードのビット化けの強制上書きです
ある程度は役に立つと思いますが、あまり期待しないで下さい
501は、500の機能のうち、DATAとFACCHのTCHフィールドの表示を復活させたものです
このため、DATA/FACCHフィールドのレイヤ2の表示が変わっています(ちょっと見にくいです)
レイヤ3はそのままです
あと、RCH/SACCHのデコード前に無効フィールドチェックをして、無理にデコードを試さないようにしています
気持ち軽くなっていると思いますが、たぶん誤差の範囲内です
あと、「こんな機能が欲しい」等のリクエストがございましたら、『情報を添えて』ご連絡下さい
できるだけ善処したいと思います >>409
情報ありがとうございます
あのリストは多分に間違いを含んでおりますので、これからもどんどん修正していきたいと思います >>410 >>411
お疲れ様です。いつもありがとうございます!
さしでがましいですが101と501単体のものもアップしていただけるとうれしいです。 >>413
お使いいただきまして有難うございます
単体ですと何ですので、全部入りzipをあげておきました
(47kB)
ttp://fast-uploader.com/file/7057845680985/
改良していただけるとありがたいです
(余談)
自分のupしたものは改造・配布・販売等何でもOKですので、みなさんお気軽にどうぞ (蛇足)
数字だけのコマンドにしているのは検索エンジンに引っかかりにくくするためです
ご了承下さい >>414
お手数おかけしてすみません
有難く頂戴いたします。 >>408
周波数のヒントが無いと難しかった
3つある受令波のうちの1つね >>407
うちの地域もそれらしきデータが見当たらないです..
>>408
遅れましたがありがとうございます。 首都FireのT79の解析を進めているのですが、こっそりできた方、TCHの信号組み立てのヒント頂けないでしょうか?
スロット間インターリーブの有無、畳み込みがあるのか、信号構成情報が付加されるのか等について教えていただけると幸いです。
もしかして、誤り訂正とか全部コーデック側でやってくれるから何も考えないでぶち込んじゃえって? >>414
まだ実装していないネタですが、
RICHの第4フィールド 110: 基地局送信 100: 折り返し送信
PICHの第5フィールド 000000000001: 基地局一斉送信
というのがあります
(仕様書は見ていないのであくまで想像です)
あと、CELPのほうですが、>>331の仮定が正しいっぽい、というか反例が見当たらないので、この方向で進めています
ということで、これと矛盾する>>289は撤回(保留)します... >>420
拾った情報ですとRICHの第4フィールド(D:動作モード)は110で一斉 100はBUSY(一斉)みたいな仕様?があるみたいですね。 >>421
おお、そうですか
慌てて実装しなくて助かったみたいです
自分も情報をもっとしっかり集めたいと思います (平成29年2月2日)消防救急デジタル無線機器の製造販売業者に対する排除措置命令及び課徴金納付命令について
ttp://www.jftc.go.jp/houdou/pressrelease/h29/feb/170202_01.html
に5社が載っているのですが、製造業者ってこれで全てでしょうか?
・富士通ゼネラル
・日本電気
・沖電気工業
・日本無線
・日立国際電気 >>422
下記の情報です。お役に立てれば幸いです。
ttps://astamuse.com/ja/drawing/JP/2012/074/843/A/000004.png
ttps://astamuse.com/ja/published/JP/No/2012074843 >>424
大変参考になります ありがとうございます >>425
こんなのも見つけましたPICHについての記載などがあるようです。
ttp://www.ekouhou.net/%E7%84%A1%E7%B7%9A%E9%80%9A%E4%BF%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0/disp-A,2012-227792.html >>426
ありがとうございます
> PICHには、バースト信号を示す識別情報と、通信要求信号、同期確立信号などのメッセージ種別を識別するメッセージ種別情報と、送信局の識別情報IDと、送信相手局の識別情報などの情報が入っている。
> メッセージ種別が通信要求信号であれば、通信要求信号の総送信回数と送信毎の順番情報が入り、メッセ−ジ種別が同期確立信号であれば同期確立カウント値の情報が入る。
具体的にはこのあたりですね
第5フィールドが分割できそうな気がしてきました 訂正
>>420の最後の>>289は>>287の間違いです すみません ご無沙汰してます121です。解析が進んでびっくりです。
自分もようやくGRG起動できました。
>>343
当地(S玉県庁所在市)は、受信できた4波(S9+6)はみな00001101でした。
※xxxx=1010
>>242
当地のシステムでも、無音パターン?はff490cb…が先行します。
また、IDLE→VOICE直後のTCH変化例で
TCH: ff490cb79d724098 ec3329b2e6035da3 e70dde16b4c3efe4 91e003f2d2247506
TCH: fc490eb79f724098 ed332bb2e5035fa3 e60ddf16b4c3eee4 90e002f2d3247706
TCH: ff490cb79d724098 ec3329b2e6035da3 e70dde16b4c3efe4 91e003f2d2247506
TCH: fee695b297043adc f6b8ce2665829087 e60ddf16b4c3eee4 90e002f2d3247706
が記録されたり、同様にDLE→VOICE直後のTCH変化例で
## IDLE ## RCH/SACCH: 99910 TCH: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
** VOICE **RCH/SACCH: 9990a TCH: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
** VOICE **RCH/SACCH: 9990a TCH: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
が記録されたりしました(☆は4点に収束状態)。
ROMはまだ見れていません。。がんばります >>427
PICHの第5フィールド(12bit)を、前半6ビットと後半6ビットに分け、前半を宛先、後半を発信元と考えると辻褄が合いそうです
当地の消防活動波の定時試験通信の一例を見ているだけですが...これも情報を集めて強い仮説に持ち上げたいです
>>429
おつかれさまです&ご無沙汰してます
自分の仮説(地域番号)はすでにかなり崩壊してます 混乱させてしまって申し訳無いです
音声フレームについては、どうやら全国共通のフォーマットなので安心しているところですが、皆さんから戴いた情報を一旦まとめねばならんと思っています 文中記載より↓
”本発明に関連する公知技術として、特許文献1には、基地局に特別な外部装置の接続や保守モードの設定をすることなく誤り判定が可能なSCPC方式の無線通信システムが開示されている。
特許文献1では、音声データ等のユーザデータをそのままCRC(Cyclic Redundancy Check)符号化、畳み込み符号化、インターリーブ、無線フォーマット化して無線回線に送信し、
受信側ではリインターリーブ、ビタビ復号化、CRC符号エラーチェックをする技術であり、
無線通信システムの動作時の送信信号を用いてBERの計測あるいは誤り判定を行っている。”
https://astamuse.com/ja/published/JP/No/2014099690
もしや?と思ったけど、出願情報だから反映されてるとは限らないかな。さすがにアテにはならないっすよね汗 ん〜、T61がFchだけじゃないからなー。タクシーとかもあるしね。
参考にはなるからサンクスなんだけどFchの音声デコード仕様は公開情報とは一線を画してたりしないかな想像だけど。
試してみたいけどいかんせん技術が足らない俺www >>431
特許文献1の 特開2007-295532 の方を調べてみました
最終ページの図11にインターリーブのビット割り当てが略図として書かれてましたので、まずはこれを試してみようかと思います おお、なんという偶然!私も同じ特開2007-295532見てました。
流れは図5ですか、ちょと頭ほじくってみます。 >>434
図5では元のビットが96bitしかないので、M-CELPの138bitとは合致しないかなと思い、後回しにしたところです
パターンはいろいろ考えられるのですが、色々ありすぎて何だか知恵熱が出そうです >前スレ549様
昨日FM-807F02を入手いたしました
ファーム関連のファイルを再うpしていただけると大変ありがたく存じます
またその他個人的には
kcl0aqq6[at]outlook.jp
まで連絡くださいますようお願い申し上げます 無音パターンがフレームの前半と後半が入れ替わってるっぽい所を眺めて見ると、
前半128bitと後半128bitの内容に食い込みが感じられずそれぞれ独立してるようにも見えるんですが、どうでしょう?
256bit=16行×16桁のインターリーブというよりも、256bit=(後半)16行×8桁+(前半)16桁×8桁だったりもしませんかね?
妄想失礼しました。 桁じゃなくて列だった、失礼しました。
ちなみにですが、仮にインターリーブが解けたとして、その次の課題ってなんですか? >>436
upしました。ご確認下さい
ttp://fast-uploader.com/file/7058145448182/
ダウンロードパス・展開パスは>>125と同じです(FM-807にあわせてあります)
中身はファームそのものとDSP部分を組み立てたものとを一緒に入れてあります
※ 固定コードブックテーブルの著作権問題が解決不可のため、ハードをお持ちの方に限らせていただいております
※ このファイルに関しては再配布等不可でお願いします >>438
> 仮にインターリーブが解けたとして、その次の課題ってなんですか?
デインターリーブの後は、符号化ブロックの復元(&エラー訂正)です
符号化パターンとして、畳み込み、BCH、LDPC、TURBO等々、既知のアルゴリズムを試すことになろうかと思います インターリーブ以前の問題として一つ情報をば:
ttp://fast-uploader.com/file/7058186120361/
ダウンロードパスは今日の日付(数字8桁)です
これは、通信開始のSYNCからVOICEに遷移したところをまとめたものです
各々、上りの通信の折り返しと思われます
無音部と思われますが、パターンが異なっています
ランダマイズされているのでしょうか?
PN(9,5)などのLFSRで解決出来れば良いのですが 浅はかな思考ですが、従来の無音パターンと異なる内容の連続パターンの部分って、
もしかして単音のセレコール音の部分だったりって無いですか?
とはいえ従来の無音パターンと異なる内容の連続パターンのヤツは、
@ff490cb79d724098ec3329b2e6035da3 e70dde16b4c3efe491e003f2d2247506
Afc490eb79f724098ed332bb2e5035fa3 e60ddf16b4c3eee490e002f2d3247706
のヤツみたいに@A@A・・・・・みたいな交互パターンじゃなくて、
@@@@・・・・みたいな感じで単パターンの繰り返しなんですよね。この差は一体・・・。
線形帰還シフトレジスタっていうんですか、知らなくてググってみたんですけど
やばい全然理解できなかった(笑) >>443
いやセレコールってことは無いんじゃないかな?
俺も一瞬そうかなと思ったけど、>>442のファイル見る限り連続パターンの内容、かなり複数あるやん。 複数ある単音セレコールと聞いて、横消の救急波の個別呼び出しトーン思い出したわw
昨今は当然PICHで呼び出しを管理してるだろうから、んなわけないけどねwww >>442
このようなパターンは自分の地域では見たいことがないですね。
>>443 での@が連続で何行も出たことはありますが。 >>443
ファイル内、下から2つ目のヤツが、よく見るヤツの単パターン版ですね
移動局の無音部は基地局とは違うのかも? >>444
ああ、確かにそうですね。失礼しました汗 >>436
文意を誤解しておりました
たった今メールしましたので宜しくお願いします >>213
TIのCCSV4がlいつの間にかlicenceフリーになったようです。
xpに入れて試してみましたが歯が立ちませんでした。
誰か使い手の方いませんか? binファイルを2進ビット単位で可視化して見たいんですが、
いいソフトご存じの方いましたら教えて頂けますか? こんばんは
SACCHでショートメッセージを送っている局がありましたので、デコーダーをそれに対応させました
ttp://fast-uploader.com/file/7058611860367/
いつもどおり、gcc -o 502 502.c でコンパイルできます
ご意見等はここへ書き込んでいただけるとありがたいです >>454
すみません簡潔で構わないので手順を教えてくれませんか。 >>455
簡潔にですと、
(1) >>410のファイルをダウンロードします
(2) >>223の手順を参考にしてUSBメモリに書き込みます
(3) USBメモリから起動します(Ubuntuが起動します)
(4) >>454のファイルをUSBメモリ内にダウンロードします(Firefoxが使えます)
(5) >>454の手順でコンパイルします
(6) 出来た"502"コマンドをホームディレクトリのbinにコピーします ("cp 502 ~/bin/" を実行します)
(7) "~/.fd2rc"をエディタで開き、501と書かれているところを502に変更します
あとはfdコマンドを起動し、矢印キーで*.binや*.t61の上にカーソルを動かしてリターンキーを叩けば表示されます
(終了はqキー) 発信者番号表示
自消防本部に限らず、他消防本部管内で相互通信を行う場合移動局の所属消防
番号体系)表示により確認できる機能。
2受信機並行動作の移動局は、基地局を経由した発信局と直接通信の移動局の両方から伝送される発信者番号表示ができる。 260MHz帯
低城侧(FL) 264.025~266.000MHz
高域侧(FED 273.025~275.000MHz
SCPC (Single Channel Per Carrier)
π /4シフトQPSK
FDD (Frequency Division Duplex)
6. 25[kHz]
伝送速度9600[bps]
音声符号化方式M-CELP方式
音声符号化速度6400[bps]以下(誤り訂正を含む) 緊急消防援助隊の出動その他消防の応援等に関する情報通信システムのうち、消防救急デジタル無線通信システムに係るものの仕様を定める件(平成21年消防庁告示13)
http://www.fdma.go.jp/concern/law/kokuji/hen51/51010000110.htm T79のbinからスロット別にデータを分離するプログラム、欲を言えば内容をデコードするプログラムをお持ちの方はいらっしゃいませんか? 0[dB μ V]以下
注)符号長511ビット周期の二値擬似雑音系列で変調した信号を
ビット伝送し、ビット誤り率が11%]となる受信入力レベル RLのPch解析の記事懐かしいな〜。
当時高校生でPC9821に手が出せなくて諦めたんだよなぁ。こういう時代にSDRが普及してたら面白かっただろうね。 そうだろうね、あの頃は良かったよなぁ。いまのRLとくりゃ・・・。
当時のPchはコーデックを必要としないデルタ変調(だったけ?)だったんだよね、今思えばすごい時代。
そういやAPRってどんなコーデック使ってるんだろう? 一度でいいからMPR復調してみたかったぜ、専務系聞けなくても方面系・高速系聞きたかったな〜。
地下鉄サリンの時の無線もなかなか緊迫感あったけど、知っていた事件の内容だと構える緊張感がなんか薄いんだよな、不謹慎かもしれないけど汗 >>468
15年ぐらい前だったっけ。
今の技術だったら、簡単に出来るのかな。 あれからM-CELPに関しては進展無い感じですかね・・・? >>471
当時独自に同期検波回路作ってでビットストリーム取り出すところまでやったけど、SDRがあったらもっと簡単にできたよ。
暗号の部分もRLの記事が正しいのなら検波から音声出すまでSDRで出来ただろうね。
秘話コードの解析もかなり効率的に出来ただろうね。 早ければ年内発売するとか…
防災無線と消防聞けなければ
聞く対象無いから買わない 市販のままで消防は聞けるようにならないから諦めなよ まだ消防無線を聞ける受信機がいつか発売されると思っているやつがいるのか。 聞きたいなら解析してSDRでプログラム組めばいいのに。
ハードはあるんだから後はソフト作るだけ。 Fchの方、私の無い知識なりにいろいろやってみてるんですが、インターリブ等々さっぱり解けず…。
お手上げです、ヒントが欲しい!
厳重な仕様書だけあって特異的な規格なのかしら?
今はただ飛び交うFchのバイナリデータをしこたま集めてoutput.binをbitpixで眺めてる日々。
それだけでもかなり勉強になったし面白いのですが、スレが動かなくなって寂しくなってきちゃいましたね。
前スレ549さん、あれから進捗はどうですか? >>481
地道な解析には頭が下がるし、いつも心のなかで応援してるよ! 大変ご無沙汰しております
私的に多忙だったりして、中々発表できるような成果が得られなくて、ここに出てくるのを躊躇していました
すみません
今日までの作業結果として上げておきます
ttp://fast-uploader.com/file/7061889716114/
いつも通り、gcc -o 503 503.c でコンパイル可能です
変更点は、
・SACCHのデコードで、出動の種別表示(火災・救急・救助・その他)を追加しました(不完全です)
・FACCHのデコードで、緯度・経度の後ろに、車の進行方向と速度の表示を(存在する場合に)追加しました
進行方向は16通り(N,NNE,NE,ENE,E,...)で表示されます
速度はkm/hです
音声デコードのほうは、インターリーブのパターンを絞り込んで、しらみつぶしをしていますが、まだ全然です >>483
お疲れ様です!
ファイル頂きます。
方向、移動速度がわかると擬似リアルタイムに地図上で動かせたりもできそうですね。
インターリーブはかなり難しそうですね。
なにかお力になれることがあればいいのですが、、、 >>484 >>485
ありがとうございます やっと落ち着いてきたので、今後はいろいろやれそうです
インターリーブなんですが、MCAの方は一旦忘れることにして、基本に立ち返って考え直しています
絞り込んだ考え方を書き殴ってみます
音声TCHの前半と後半を分けてみると、前半+次のフレームの後半が一組のデータと思われます
fc490eb79f724098ed332bb2e5035fa3の右下がe70dde16b4c3efe491e003f2d2247506、
ff490cb79d724098ec3329b2e6035da3の右下がe60ddf16b4c3eee490e002f2d3247706
となっているのが見て取れます
無音から有音、また有音から無音への遷移時もこれで説明がつきます
インターリーブの大目的はバースト誤り耐性のためですので、隣り合ったビットが可能な限り離れるように、
かつ均等に分散させることにします
また、フレーム間インターリーブがかかっているので、この各々のビットも均等に割り振られるようにします
前半のフレームのビットをA0〜A127、後半をB0〜B127として既述しますと、
このような感じに並べ換えることで前記の条件を満たせます
A0 B0 A16 B16 A32 B32 A48 B48 A64 B64 A80 B80 A96 B96 A112 B112
A1 B1 A17 B17 A33 B33 A49 B49 A65 B65 A81 B81 A97 B97 A113 B113
:
:
A15 B15 A31 B31 A47 B47 A63 B63 A79 B79 A95 B95 A111 B111 A127 B127
これは一例で、前記条件を満たすものは複数考えられます
これらを基にしてブロックを組み立てた上で、畳み込みの最初と最後のパターンが見つかるか、
という判定をすることになります
あと>>442に書いた問題ですが、秘話パターンではないかと思っています
STD-T98だとPN(15,14)なので、試しにこの32767通りを処理前のA,BブロックにXORをしてから
上記インターリーブを試してみたりしています あまり知識無いのですが、このLFSRって15bitですよね?XORする際は例えばMSBに"0"等を付加して16bitにしてXORするとかなんですか?それとも無理くり15bitでXOR? >>487
15bitはそのまま使うんじゃなくて
擬似乱数を発生させるシフトレジスタにセットする初期値の15bitです
wikiで線形帰還シフトレジスタで調べれば出てきますよ 皆さんお疲れ様です、僕も微塵ながら地道に挑んでます、前スレ549さんはじめ皆さん共に頑張りましょう!
さて最近になってwindows側でもデコードを始めたんですが、
windows10でtail -fのようなコマンドを走らせる方法がわからなくって汗
>>337のような疑似リアルタイムデコード表示をwindows10で行う方法わかる方がいましたら教えてくださいませ。 >>489
tail -f相当ならWindows PowerShellを使えば出来るらしいよ ええ、ググってみたらPowerShellで出来そうなんですが、記述がダメなのか上手くいかなくて >>489 >>491
Linuxと同じように走らせたいならMinGWとか使ったほうが良いのではないでしょうか? >>483
SACCHの出動の種別表示が87(???)というのが出ましたがこれは? >>493 >>494
分署の近くの公園で音声を聞きつつ、別途受信したデータと突合させるのは疲れます...
やってることは不審者そのものですし >>494 >>495
なるほど...ご返答ありがとうございます。
自分も近くの音声が聞けるところで照らし合わせてみます。 どこからSACCHを判明させたのだろうと思ったら、まさかそこまでのご苦労があったとは! 情報収集ですが、くれぐれも無理をなさらないようにお願いします > 皆様 駄文失礼します
>>337に書いた擬似リアルタイムデコードですが、
(1) t61.grcの"File Sink"の"Unbuffered"をOnにして、
(2) 端末から、"tail -fs 0.1 output.bin | 101 | 503" 等と実行すると、
よりリアルタイム性が増しますのでお試し下さい
(UnbufferdをOnと、tail -fs 0.1が肝です) >>499
Unbufferedいいですよね!
個人的にはfs0.2ぐらいが文字読める速度で照らし合わせるときとかには重宝です。 出動の種別表示が87(???)の時の自治体サイトなどで公開されている同時刻の出動情報を確認してみると3回中3回共に「災害」になってますね。屋内事故などでしょうか?
ちなみにY浜ふぁいやーです。 まとめてのレスで失礼します
>>497
音声デコードのヒントが無いかと思って出掛けましたが、ついでのほうで若干の成果があったのでした
>>500
Unbufferedだと負荷に弱くなるはずなので、安全サイドに倒しておいたのですが、気のせいだったようです
t61_multi.grcでも問題になりそうにないので、Unbuffededをデフォルトにしようかと思います
>>501
地域によって使われている情報が異なる可能性がありそうなので、どうしようか思案中です
04/84(その他)は(警戒)かも知れんなあとも思ってますが、なにぶん情報不足なもので... 皆様お疲れ様です。
大変お手数をかけて申し訳ないのですが、もしよろしければ>>410のファイルを再びアップしていただけないでしょうか… >>503
再upしました ご確認下さい
ttp://fast-uploader.com/file/7062251279850/
前と何も変わってませんので、既にお持ちの方はダウンロード不要です
(その後にupしたものは統合されていません これはそのうち...) >>504
遅い時間に申し訳ありません。
まだまだ勉強中ですが、使わせていただきます、ありがとうございます! >>504
統合版をupしました(約51MB)
ttp://fast-uploader.com/file/7063084997109/
502,503を統合しただけで、使い方は>>223と変わっていません
よろしければお使い下さい >>507
どもです
もうネタ切れなので、新たなネタが仕込めるまで篭ります... 前スレ549さん
FM-807F02の実機を入手したんですが(技適末尾14)
再度ROM諸々うp出来ますでしょうか?
よろしくお願いしますm(__)m >>509
再upしました ご確認下さい
ttp://fast-uploader.com/file/7063533488731/
ダウンロードパスは以前と同じです
展開パスはFM-807F02に合わせてあります
これでよろしいでしょうか? >>510
ダウンロードできました!
可能であれば
>>130 >>140 >>240
も再うpお願いできますか?
色々と研究してみようと思います。。。 >>511
>>140のものを掘り出しましたのでupしました
ttp://fast-uploader.com/file/7063542546906/
他のものも掘り出し次第upしますのでしばらくお待ちを... >>512
>>510でupしたアーカイブには>>133相当を含んでいますのでご承知おき下さい >>511
>>240+αをupしました
ダウンロードパス、展開パスは先ほどの>>510と同じです
ttp://fast-uploader.com/file/7063543512151/
+αは>>247に書いたデバッグログの追加です
ただ、インターリーブの部分はFchとは互換性が無いのが明らかになっているので、あまり参考にならないと思います >>516
元のファイルそのままなので、展開パスがEF-6190のやつになっていると思います >>517
富◯通のシステムを使っている局なら、分かることもありますという程度です >>481
インターリーブなんですが、きっかけになりそうな情報が実験で得られました
音声TCHの256ビットを、MSBから並べて0〜255としますと、
(1) 19と51に相関がみられます(19が0なら51が0、19が1なら51が1)
(2) 95と127に逆の相関がみられます(95が0なら127が1、95が1なら127が0)
(1)は、R=1/2の畳み込み演算の先頭に出てくるパターンと同一です(ただし秘話演算無しとした場合)
現在、19と51が隣り合わせ、かつ95と127が隣り合わせのビットとなるインターリーブパターンを探索中です...
ご参考まで 共通仕様書を行政文書開示請求したら
さらっと全文開示したりするかもよ?
一件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 とか言うの入れてみた
昔に比べると子供でもできるレベルまで簡単になってて驚いた 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のファイルの誤りでした。もう一度アップは可能でしょうか。 >>627
最新版とマージしますのでしばらくお待ち下さい >>627
おまたせしました
ttp://fast-uploader.com/file/7074764268981/
使い方はこのスレに以前に書いたものと変わっていませんので、そちらを参考にしてください
不具合ありましたらお知らせ下さい
あと、UEFIブートは、boot\grub\boot.cfgをエディタで開いて、menuentryの中のlinuxで始まる行の末尾に persistent を付けると正常にブートできると思います
(BIOSブートは何もせずにOKです 念のため) ありがとうございます。半年ぶりだったので新たに環境を構築してうまく起動しました。>>626のファイルですが既存のファイル置き換えで構わないのでしょうか。 >>630
基本的には置き換えでOKです(お手元で何か変更をされているならバックアップをお願いします)
一部には仕様を変えることなく高速化&軽量化を図っている部分がありますが、たぶん誤差の範囲です... 大変ご無沙汰してます
消防団体コードを研究されている各位にお願いなのですが、
全国消防便覧 ttp://www.fdma.go.jp/disaster/syobobenran/ に記載されている本部の並び順と、分かった範囲での並び順が同じかどうかを教えていただけますでしょうか
自分の調査では、県によって同じ場合と違う場合との両方がある感じです
(日光県はバラバラ、グンマーはだいたい同じ並び、彩の国県は二つに分かれているけれど、ほぼ同じ並び) >>631
かなり遅れましたが迅速な対応ありがとうございました。半年ぶりに実行して期待しましたが受信結果は前回と変わらず笑
これからも色々試していきたいと思います。 >>633
状況が良く分かりませんが、一番シビアなのが周波数の誤差だったりしますので、そのへんを注意してみて下さい
ご健闘をお祈りします 重洲無線株式会社は2018年3月12日、C4FMデジタルモードとアナログFMモードを搭載した144/430MHz帯(バンド切り替え式)のモービル機「FTM-7250D(50Wモデル)」「FTM-7250DS(20Wモデル)」を発表した。
フロントパネルに大音量(3W)で高音質のフロントスピーカーを搭載、FACC冷却システムにより安定したハイパワー出力が得られるという。
発売開始は2018年4月予定、希望小売価格(税抜)はFTM-7250Dが49,800円、FTM-7250DSが47,800円。
https://www.hamlife.jp/2018/03/12/yaesu-ftm7250d-release/ ↑なんだよスレチじゃねぇか。
他スレからの情報だと、
SDR#&TETRAプラグイン又はgrd&winteliveで成田空港のTETRA聞けるらしいぞ、このスレのみんなも是非試してみて。
俺も試してみたんだが良好に音声デコードできるぜ。
ちなみに受信地は千葉市。 家近いけどsdr#がtetraプラグイン読み込まなくて断念したわ。終了しようとしてもエラー出るし grd+msys2+winteliveで試してみるといいよ。
てかみんなSDR#プラグインだめでコケてるみたいだね。
ちなみに俺もです。 もちろん。音声として聞ける。
複数局音声通信してる際はデコードが追いつかなくてブツブツになるけど。 >>644
ありがとう。
いわゆる日立の無線機を使ってる
空港内のやつよね? それはT87タイプだから違うすよ、
今回のはTETRA対象、つまりT114て事です。 空港内デジタルでもT87とT114に分かれてる訳で、当然導入が早かったのは羽田空港(多分)のT87なんですが、以後2017年に成田の空港内デジタルにT114仕様でTETRAが導入されたって訳です。
面白いのが、この二つのシステムが概ね460〜462MHzの間に共存されてるんですよ。
当方千葉市だからなのか成田・羽田空港は相方とも良好に受信できるコンディションなので試してみたんですが、
SDR#で捕らえられたスペクトルと比べてみるとTETRAとしてデコードされる周波数とされない周波数に分かれてるのがわかります。デコードされないのが恐らく羽田空港のT87空港内デジタルだと思われます。
ちなみにT114の仕様書の64ページ以降にこの二つのシステムの共存・干渉について詳しく書かれています。 >>644
複数局って、ドングルいくつつけてるんだよw いや、そういう複数局って意味じゃなくて、grd+MSYS2+winteliveのシステムって最大10波同時デコードトランキングできるのよ。
ドングルは1個ですよ(笑)
つまり、そのwintelive走らせてる時に複数局が音声通信してる時は聖徳太子状態になるんだけど、
よく聞いてるとそれぞれ音声がブツブツしてて、どうやら複数局が音声通信してる際はACELPでのデコーデックが追いついてないみたいなんですよ。
っていうことです。
ちなみに調べた結果ですがご参考に↓
成田
460.3250 460.3750 460.4250 460.4750 460.6250 460.7750
460.9250 461.0750 461.2250 461.3750
羽田(だと思われる)
460.5250 460.6750 460.8250 460.8750 460.9750 461.0250
461.1250 461.2750 461.3250 461.4250 この時間になると保守作業がメイン。
誘導路や滑走路の点検、ランプ等の設備点検や補修作業の交信が多いです。
そのため誘導路・滑走路への進入・終了をいちいち管制塔と交信して承認を得ているのがわかります。
日中は旅客誘導・ゲートセキュリティ的なやつ・荷物積み込み的な交信が多いです。
いずれにしても交信量は割と多いので面白いですよ。
私は航空知識は疎い方なんですが、ある程度知識ある方はなかなか楽しめるんじゃないかと思います。 諸兄のためにgrcのブロックをupしときます。その他msys2とかwinteliveの導入はググってね。
http://fast-uploader.com/file/7076463727995/
導入後はこんな感じ↓
https://imgur.com/67LqSDz
WinTelive monitor のとこのPlayingにチェックついてるところが
音声デコードしてるch。ご覧の通り複数局受信できるのよ。 私も、SDR#はダメ。エラー出る。
grd+MSYS2+winteliveの導入はできたけど、如何せん足立区じゃあ無理だった。
そもそも、SDRのスペクトラムに該当周波数出てないしで、電波自体拾えてない・・・
もっと成田に近ければなぁ(・。・; F-chのやつ、さっぱりお手上げだ
どうにかして消防救急デジタル無線共通仕様書が手に入らないかなぁ〜...
前スレ549さん、その後進捗はどうですか?MCAの無音部分取れましたか? 大変ご無沙汰しております
>>654
進捗、丸っきりだめです
MCAの電波を丸々二日分記録したのですが、自動解析プログラムを作ろうとして途中になってます...
新しい人の新しいアイデアのお出ましを願いたいところです >>655
大変お疲れ様です。何一つお手伝いできないのに進捗ばかり気になってしまいすいません(汗
自動解析プログラム・・・なかなか気になります。 >>656
膨大なデータを入力して、復号の総当りをして、出てきたパターンを記録・比較して...とやっていると、人力では限界なので、ある程度肩代わりさせようという魂胆です
セッションを意識して...とかやってるうちに混乱してしまい、中断してます しかしながら肝心のところが・・・。
でもこれは収穫でかい、ありがとう! >>660
印刷可版仕様書のスキャンPDFだね。
デジタル移行が始まった初期の頃に役所の発注資料にたまに添付されてた。 結局の所、今現在、何が出来てて何が出来てないことになるの?
主流は消防救急みたいだけど、たとえば音声だけ聞ければのとき、あと何が足りないの? この人かね
994 :名無しさんから2ch各局…:2017/01/27(金) 13:06:48.79
http://aatw.xtreemhost.com/kotsu/hiwa-v.mp3
このスレの住人ならこの秘話の解読は簡単? まだこんな秘話が使われているのか
しかも電話の会話だし
只の反転秘話とは異なるから面倒かも この秘話の書き込みを、どこか見た思いがしてて、気になって探してたら見つかった。
https://lavender.5ch.net/test/read.cgi/radio/1465448247/260
書き込み見ると面倒には見えないけど、一般人には無理なのかな。 波形見ると下のICで復調出来そうな感じ
http://eleshop.jp/shop/g/gFC8125/
今ならソフト的に何でも出来るけど、アナログ秘話の解読をいまさらやってもね・・・ >>653
若干亀レスですが、有志によりプラグインが改良されSDRsharpでもtetraの音声デコードが出来るようになりましたお。 このフォーラムのTSSDR氏のレスを翻訳して参照くだされ。
そのレス中にプラグインのリンクがあります。
http://www.radioscanner.ru/forum/topic50051-17.html 乙です。
早速SDR#にプラグイン嵌めてみたら、今回はエラーなく無事嵌りましたわ。
今度千葉方面行く時に試してみるとします。 >>677
あざ〜す!
tetra嵌めたがdecodeできる波がない・・・ @関西圏 >>676
成田近郊に車で移動して動作してみたんですが、
あれ?tetra decoder動作しねぇぞ?と小一時間設定やらを悩ましく確認していたんだけど、
このdecoderを動作させるにはNFMからWFMにして帯域幅を広げるんですね。
無事に音声デコードしました。
なかなか面白かったです。
「到着の○○○便にビーフジャーキーの開封のお客様いまして、検疫1番誘導お願いしてもらっていいですか?」
空港の業務の忙しさを知りました。 タクシーとか?
何が聞けて何が聞けないリスト、テンプレに欲しい デジ簡の免許局は聞けてるよ。地域により異なるのだろうけど、警備関係が賑やか。あとはバスの連絡 JRの駅のガードマンは、アナログ簡易無線だったのが意外。一度導入したら壊れるまで買い換えないのかな。 >>686
使えるうちは使い続けるんじゃないの?
そこそこ台数入れてるだろうから、入れ替えるとしたら一気にやる必要があるしね。 今更の質問なんだけど、
東消TDMAってARIBの仕様で言えば何になるんですか?
T39?T79? >>687
T102の第2編に準拠してるやつは普通に聞けるはず
第1編準拠の方もDV1と同じ手順で一応聞ける状態にはできるらしいが なぜマイナーな方式のタクシーに対応して、メジャー方式に対応しなかったのか… 第2編のほうはホワイトニング方式とかいろいろDCRと共通だからな >>689
STD-T79。
音声チャンネルの解析がうまくいかなくて放置してた。 >>697
電波のデコードにはGNU Radio、データ解析には自作のソフトウェアを使用してます。 >>698
自作でしたか〜。
ちなみにgrcのブロックも自作してます?
4スロットやフレームの分離はソフト側で? >>699
GRCブロックは既存のものを使用しています。
まずは仕様を確認したかったのでFile Sinkでダンプし、後処理としてソフトで解析してます。 しかしこうして見ると、ほんと、またしても業務無線をガラパゴス化してしまったな、総務省
いくらでも安く買える海外規格と揃えずに、なんだかんだで1台20-40万円台とは
全ての不利益はユーザー負担
目に見えてたなこうなることは 国内メーカーも海外でのNXDNやらの売上がほとんどだろ
非関税障壁なんてのは中央省庁役人の自己満足だよ まぁ、役人云々より、規格策定の段階で策定メーカーがそういうようにするんだろう。
で、その国内規格の無線機だって、特定の代理店以外には資料すら出さないし、当然売る事が出来ないから入札すら排除しているものもあるからな。 アベノミクスで岩盤規制突破!
その象徴が加計学園獣医学部 前スレ549さん、お忙しいところ恐れいりますが>>629のファイルを再upしていただけますでしょうか? 大変ご無沙汰しております...
>>709
ttp://fast-uploader.com/file/7085737883405/ にupしました
ご活用下さい
>>619 >>620
遅まきながらプログラムを書いてデバッグ中です
もう少しお待ち下さい T○DのT79の解析している人ってまだいるかな?
CACの部分は仕様書にないパラメーターがあって苦労しているけど、なんとか見えてきた。
TCHのヒントをどなたか… SDRドングルで地元のデジタル消防無線周波数(活動波)を割り出すことは可能ですか?
また消防団もデジタル化移動と同時に466Mhzアナログ無線も使用されなく
なった模様で、こちらも周波数を探しているのですが、一向に確認できません。
デジ簡でもなさそうななので、SDRドングルを購入して割り出したいのです。 >>714
う〜ん、可能だけど、なぜSDRドングルを使ってまで割り出したいのかがよくわからんが・・。
受信機に割当周波数を全部メモリして、消防署の目の前でアンテナ外してひたすらスキャンしてたらわかると思うよ。 試験の時刻がわかってるとか近くでサイレンが聞こえるなら
パソコンでSDR使ってウオーターフォール画面みるとすぐにわかるんじゃない?
基地局側が274MHZ周辺なのはわかってるんだから中心を274MHZにして
2MHZ幅のモードにしてれば多分でてるでしょうよ 周波数わかってもデコードできないけどね
ガーガー聞こえるだけ >>713
TCHについても仕様書通りでは無いんですか?となるとインターリーブパターンとかホワイトニングとかそこらへん?あとあるかな? >>715
えっ?団同士の連絡間でもIP無線がほとんどなのですか?
>>716
今までアナログの時はアマ無線ハンディ機VX-1(古過ぎますよね・・・)受信で
事足りていましたが、この機種だと200Mhz帯表示はありますが、使えません。
ステップセレクトもこの機種では無理っぽいですし・・・。
近所で火災があった時に使った時にデジタル特有のガーガー音ですら受信
できなかったので、せめて周波数だけでも割り出したくSDRドングルならどうかな?
と思ったのです。ちなみにこちら関東地方某所ですが、消防は広域組合なので
基地局から直線距離で10km離れていますが、アナログ時代ではフルスケルで受信
できていましたが、デジタルでも信号自体は受信できますよね?
>>717
試験の時刻はアナログ時代と多分かわらないと思います。
火災時は防災無線が鳴りますので、それから274MHZに合わせていましたが
VX-1ではダメでしたのでSDRドングルならどうかなと思い、相談投稿しました。
>>718
とにかく周波数だけでもわかればいいかなと思っています。
ちなみに管轄の署活系(PSW)はガーガー音だけでも周波数はわかりました。
PSWになる前と周波数が変更しているっぽいですね。 >>721
スケルチ開放にして273〜275MHz辺りをSメーターを眺めながらグリグリすればすぐ見つかると思うが
ただ、VX-1の受信感度がどのくらいかわからんが >>721
なるほどね。
確かに200メガ帯あたりが得意でない受信機は多いかも、vx-1かぁ。
SDRならアンテナのセレクトを間違えなければ、受信はできると思う。
IP化に関しては正直?だね。でも466帯を廃止?するなんてねぇ。意外と割当周波数だけ変えたかもしれないかもね。 >>721
元々200MHz帯なんて需要が無い、捨て帯域だからメーカーも受信感度を重視してないかもな
90年、2000年代は120、150、350、380MHzが人気バンドだったから >>723
そのように試してみたのですが、やはりダメだったのです。
VX-1受信感度自体がダメだと思うのです。
スケルチ開放するとAM調なかんじですし、信号らしきものもひっかかりません。
>>724
そうですね。200MHZ帯がダメっぽいんですよね。なのでSDRなら大丈夫かな?
と質問させていただきました。
466帯廃止はデジタル化と同時だったので、デジ簡?特小?に移行したのかと
思ったのですが、デジ簡ではなさそうですし、特小も微妙なところです。
ちなみに管内の全市町役場の総務課にはデジタル受令機があるようで、窓口
からもスピーカーから聞こえている模様です。
>>725
各団の消防車にはデジタル受令機はなく、指令課から団員の携帯にメールが
入るそうです。
>>726
120、130、140、150、350、360MHzは90年代も人気だったと思います。
アナログ署活系の頃、県内系をそのまま流してたこともあって聞けてましたし。
>>727
昔でいう「簡易」になっているみたいです >>728
うちも消防団だけどデジタル後はメールになった
現職の署員に受信機のことを聞いたら御上が許すなら聞いて活動してもらった方が楽だって言ってた >>728
とりあえず地域(都道府県)はどちらなのかな? 指令システムとメール配信が連動してるならそっちのほうが楽なのかな>消防団 >>713
となるとUSCも一癖あるのは自然の理なんかな。もはやT79の仕様というよりは派生した新規格だなそりゃもう。
あのRLの記事の関係者ないし詳しい記事の降臨を待つしかないのだろうか・・・
ところで差し支えなければ周波数を教えてくれないか?
260〜270帯は防災行政も共住してるから、SDRで眺めてみてもT◯Dの正確な位置が掴めんのですよ汗 >>728
地元(愛媛県)の消防団はIP無線になったらしい。田舎すぎてそっちとは事情が違うかもしれんが。 >>732
基地局が細分化されているようだから具体的な周波数は避けるけど、基地局DownLinkはSCPCのちょっい下くらいかな。
前スレ >>725 にあるように、BCCHはT79とほぼ同一だから、仕様書通りにデコーダ作ってそこから改造していくのが良いと思われ。 >>729
メール配信しているところが多いみたいですね。
>>730
栃木です。
>>732
こちらの方が田舎すぎですよ >>735
SDR#等を動かしておいて、同時にtwitterの "安全ねっと/栃木" を見ていると大体つかめると思います
自分が知ってる範囲ではこんな感じです
足利:67, 123, 163
佐野:99, 195
栃木:7, 103
鹿沼:209
石橋地区:159
周波数は 273MHz + 上記番号 * 6250Hz です >>736
ありがとうございます。
アナログの時には上記地区も聴こえていました。
SDRが届いてから宇都宮、芳賀地区、塩谷地区、小山あたりも
探してみようと思います。 ヤフオクに「消防無線の検査機」って出てるけど、これって増幅機?
もしかして…憎き三菱チップ入り? >>741
俺も気になった
アナログの払い下げ品だと思うが 大変ご無沙汰しております
>>619
デバッグが終わって安定しましたので公開します ファイル名に年月日時分秒を付ける形で落ち着きました
ttp://fast-uploader.com/file/7089635035605/
使い方の簡単な説明:
(1) fifo_logging.cをコンパイルします (例) gcc -o ~/bin/fifo_logging fifo_logging.c
(2) GRCのブロックの file sink の Unbuffered を off、Append file が Append にします
(3) file sinkの出力ファイル名と同じ名前のFIFOを作ります (例) mkfifo output.bin
(4) (1)でコンパイルした fifo_logging コマンドを、引数にFIFOの名前を付けて実行します (例)fifo_logging *.bin
(5) (2)のGRCブロックを起動します
デモジュレート結果は fifo_loggingを起動したところからの相対パスで、 ./logs/[年月日]/[年月日時分秒]_[元のファイル名] に都度出力されます
複数の局の受信にも対応しています(設定上は最大80) fifo_loggingコマンド に複数のFIFOを指定してください
手元では同時待ち受け60局、同時受信12局には成功しています(CPUパワーによります)
以上簡単ですが説明を終わります 質問ありましたら適当に投げてください... >>748
付け足し:
fifo_loggingコマンドは、必ずFIFOのあるディレクトリで実行してください
(ファイル名生成の手抜きが原因です) >>748
失礼します。
当方、パソコンなど全く詳しくない者です。
レベルは中卒程度です。
それを承知でお尋ねします。
RTL2832U(USBチューナー)は持っていますが何も改造などしていません(買ったまま)が初期設定など、1から教えて頂きたく思います。ダウンロードしてどのように使用したらよいか教えてください。
大変失礼かと存じますが、よろしくお願い申し上げます。 >>750
単純にSDR使い方を知りたきゃ、こっちを見た方が。
http://lavender.5ch.net/test/read.cgi/radio/1487419319/
ここのスレ内容、パソコンを触れるかどうかぐらいの知識では到底ムリ。
と、盆でヒマなので少しマジレス。 >>750
まず、このスレの全体に目を通されて、プログラムの目的が消防波のデコードの研究であることを理解されておられるならば、 >>456 の通りに事を行ってみてください
現在casper-rwは消えてしまっていますので、必要ならば再upしますのでお申し付け下さい このスレは滅茶苦茶レベル高いと思うwホントに…
アナログの無線なら見よう見まねで(解説してる人も沢山いるし)頑張って欲しい 全スレ549さんって、T61以外もチャレンジしてるのかな? >>754
今はFchのM-CELPデコード以外チャレンジしておりません >>755
以前行われていたと思われるT79の件で相談したいのですが、よろしければ連絡頂けると幸いです。
cmux4b7h あっと svk.jp >>756
T79のほうは、人様へお見せできるようなものは作っていないので、過度な期待はなさらないようお願いいたします...
また、オープンに出来る話題でしたら、このスレで承ります
# T79に関しては、このスレの諸先輩方(複数)のほうが詳しいと思われます...
その他、どうしても事情があってと仰られるならば、 jbd03233 [at] outlook.com へメール下さい
ほとんど開かないメールですので、「送ったよ」等をこのスレに書き込んで下さるとチェックが早いです >> 757
送ってみましたが、送信エラーになりました… >>758
すいません、comじゃなくてjpでした... 某KGの人みたいに無線機器メーカーに囲われないように気をつけろよ
F-chだと○菱辺りから誘いの連絡が来そうだからな
報酬待遇につられて契約したら最後、 秘密保持契約までさせられて関する以降の研究解析結果の公開もできなくなるぞ
『関係者になった以上、公開すれば情報漏洩という名目で訴えるからな』っていう算段だ 現実は、余程の事じゃない限り、ヘッドハントも無いし誘われる事も無い。
個人が研究や解析するレベルと、企業や大学でやるレベルは全く違うレベルだから… >>761
え?KGの人はメーカーに取られたの?一時期防災無線の復調やられてたみたいだけど >>763
ブログだかを見た限りだとタクシーのAVMをマップ上にプロットさせることに成功したってのが最後の更新だったと思う >>761
トラップに引っかからないように気をつけます... >>765の補足だけどAVM関連は"技術系で"最後な
ラストは
N○C?(詳しくは忘れたが通信関連メーカー)から声が掛かったからその会社へ就く
とかいったニュアンスの記事があってそれ以降の更新は無し
程なくして掲示板閉鎖、ソフトウェアライセンス発行・サポート更新停止 確かデジタルMCAのソフト開発が結構進んでた時だった気がする IP無線の方に劇的に移行してるのに本当お前らは馬鹿w そもそもデジタルではない件。
東消方面波のアナログも死んだいま、なぜもう使われないそのスクランブルを追うのかね?テープに大量に保存でもしてるの?
そういえばだが、既出なのかもしれないけど、
今後波及するであろうNEC式の民鉄用デジタル無線の音声圧縮はもっぱら三菱製の改良型RL-CELPが用いられるみたいなんだね。
そうなると、色んな努力をしてもやはりコーデックが肝だから、コーデックがどこかで掘り出されない限り音声デコードは無理だよなちくしょー まあでも音声はデコードできなくてもデータ通信のデコードだけでも期待はできるよね。
D化したJRや京急やら小田急やらのデータ通信が読めるようになると面白いだろうなぁ〜。 でも仮に、一般人に消防無線の音声がデコードされてその方法がおおっぴらになった日には開発関係会社は顔面蒼白だろうな
談合までして得た権利と今までの多額の開発費と特許料が無と化す訳だからな
総デジタル化しちまった今
解読されるたび
「納入した機材だけど、聴けちゃうみたいだから、セッティング変えるために本体外して会社に送ってちょんまげ」
とは簡単にはいかんだろ >>775
鉄道無線機も警察や消防並みの厳重な管理をするだけだろ そうでしょうね、露骨に「他からの傍受を避けるため」と明記されているワケですから。 まあなんだ、無線なんか傍受しないで大人しく公式発表を待てって事だね。
それが普通の日本人 消防無線はアナログ時代から利権と談合セットだから、デジタルになって更に酷くなっているのではw >>775
10番Aタイプのパソコンリアルタイム復元ソフトが出来たように
録音されて20年経った今なら解読できる可能性があるかもよ あの時代あれが傍受できたから、今思えばラッキーだったんだよ、あの緊迫の内容、昨今リアルタイムで傍受出来ても深い話しは携帯端末で百%無理でしょうね。てかあの頃の人以外これを傍受って概念の人は、いないよね 東消のキュルキュル秘話ってなんていう名称なんだろうな
時分割音声反転方式とか言ったっけ?
むかしRLだかABが復調したけどリアルタイムでは無理で遅延があるとか見た気がする 東消秘話は複数のアナログ秘話を組み合わせて
傍受を難しくしているらしい
欠点は復調した音声がかなり聞きとりにくく、
大規模災害や山岳救助では秘話を解除していた 552変換機も市販はされなかった。
解読した噂はRLかABだったか聞いたことがある 東証のは音声反転+時間軸伸縮入れ替えタイプだな。
3kHz付近にあるキャリアに伸縮と入れ替えのタイミング情報を乗せてる。
までは解析した。
色々調べると1980年代中頃にKDDが開発した秘話装置に構造が酷似してる。 デジタル信号復調?!とか言ってるけど
特許とかの問題もあって復調装置の市販化は無理。
デジタル信号復調は個人で内緒で楽しむ趣味になる 個人で使う分には問題ないだろう。
ただし秘匿化に関する具体的な技術は特許出さないと思う。特許出したら公開されて丸わかりになるから。 >>790
現代社会の暗号化アルゴリズムはどれもオープンだぞ。
鍵さえ漏れなければよい >>791
M-CELP とか RL-CELPは音声コーデックにある程度の秘匿化の仕組みが入ってるみたい。それは知的財産権とか営業秘密で守られてる。
AESみたいなちゃんとした暗号ではないと思うけど、現時点では秘匿化できてるよね。 ご無沙汰しております...
Fchの音声ビット配列をM-CELPのそれに変換するパターン候補を絞り込んでみました
DSPのシミュレータを動かせる方に評価していただければ幸いです
{
65, 64, 63, 22, 21, 20, 19, 18,
137, 136, 62, 61, 60, 59, 135, 134, 133, 132, 131, 130,
17, 16, 15, 14, 13, 12, 40, 39,
38, 37, 36, 106, 105, 104, 35, 103, 102, 101, 100, 99, 98, 97, 96, 34,
11, 33, 10, 9, 8, 7, 6,
32, 31, 30, 29, 95,
28, 27, 26, 94, 93, 92, 25, 91, 90, 89, 88, 87, 86, 85, 84, 24,
5, 23, 4, 3, 2, 1, 0,
71, 70, 69, 68, 67, 66, 58, 57,
56, 55, 54, 129, 128, 127, 53, 126, 125, 124, 123, 122, 121, 120, 119, 52,
83, 51, 82, 81, 80, 79. 78,
50, 49, 48, 47, 118,
46, 45, 44, 117, 116, 115, 43, 114, 113, 112, 111, 110, 109, 108, 107, 42,
77, 41, 76, 75, 74, 73, 72,
} >>793
貴方は本当にすごいと思う。ラジオラ◯フ編集部に爪の垢を取って送って上げて 私はDSPのシミュレート環境がないので結局見学者のような者ですが、
この138bitのインターリーブ配置のあとにスクランブルパターン抽出ですの? >>794
どもです
>>795
驚異の粘り腰でしつこくしつこくやっているだけですので...
なお、RL誌様におかれましてはぜひとも意味のある周波数帳をお願いしたいです
>>796
このパターンは、TCHの256ビットを加工処理した138ビットの最後の並べ替えを示しているものです
一番ありそうなパターンを統計的に予測した結果なので、ここから部分的な入れ替えが必要かもしれません
スクランブルは、例えば自動音声アナウンスにはかかっていないようですので、これを優先して解析してます
なお、スクランブルがかかっている通信は、現在までで2256パターンを収集しましたが、まだ法則性は掴めてないです >>797に付け足し
統計処理への入力は、自動音声アナウンスの「ピーポー」や「プー」音をエンコードした(と思われる)フレームを使いました
(「ピーポー」は「ピー」と「ポー」で分けて別々に処理しています)
このような一定音だと、フレームの前半後半で同じビットパターンが出現することを想定しています 123 憂国の記者 2017/09/09(土) 19:26:48.23
>>121
別に消防無線の受信機ぐらい手に入る立場だけど
こんなものを大枚はたいて買わないよ。あほらしい。
D-STARはすでに持ってる。ただ、一台に統合したいので
FSKと両方聞けるようにしてほしいと言ってる。単三電池
2本で動作するようにしてほしい。DV10が出ても燃費の悪さを
考えると買わないと思う。
301 憂国の記者 2018/09/03(月) 05:37:12.75
>>300
単なる馬鹿でしょ。
みなさんも、消防の受信機買える立場になればいいね
俺はいつでも買えるかど、買わない。一台15万とかアホじゃねえかと思う 秘話かけてないなら、秘話と平文どちらを受信しても音声になるようなシステムなのか
っていうか、受信だけでよくわかるな >>799
で、この妄想クソアホ糖質下痢便アナルクソコテ野郎がなんだって? >>799
ちなみにこの妄想クソアホ糖質下痢便アナルクソコテ野郎はすでにNG物故未済みだからな
妄想クソアホ糖質下痢便アナルクソコテ野郎工藤大介貴様のクソ書き込みはクソNGなので一切見えないのである
バアアアアアアアアアカ
.,r‐--,,,_、
.゙l゙'i、 `゙''-,,,,,,,,,,,,,,,,,_
: ゙l `'i、.,r‐-、,,`'-,、 `''ー、_
゙l ,/゛ `゙''''ミッ、 ゙゙'''-,、
У `!ヽ、 ._,,i、 ,,,,,、
/ ゙r゙l, / ‘i、 { ゙i、
| ゙'i゙l ./ |, ゙l、 ゙l
| _,,,,_ .゙'},. | ,/ ゚i、 ゙l ゙l、
゙l ,r'"` `゙゙''',゙',lri、,,/ .゙l ゙l ヽ
│ .| .彳 ゚|″ | .| │
│ .ヽ_ _,,-° `i、 .| .,,゙l, .゙ケ'=ッ、
゙l, ,,,,,,、  ̄ ̄ .゙l,-'シ'',!.゙l ,/゜ ゙'i、 .}i、`.゙'i、
`'| `'i、 ,,,rン・'゙,,,-'i| .| .l、,,」 ゙= |
.゙ヽ, .゙!, i″ ゙''i, .l │ /" .゚┓ .|
‘'''l" ゙'-,,、゙l、 .,,「 | ゙l、 ゜ .|
゙l'-,、 `゙''゙‐'" ./ .ヽ .|
| ゙'ヽ,、 / '゙l .,ノ
′ .~'―--―ー¬''" ヽ-, |、
" .l゙ スクランブル値ってやはり団体ごとに違う感じなんですかね?それとも全団体とも規定値のスクランブル?
統制波ってどうやってるんだろう。 >>805
基本、全部共通みたいです
グループ同報とか個別通信の場合に、たまにスクランブルがかかっている感じです
統制波も手元のデータを見る限りはスクランブル無しです
無音パターンが以下の2行の繰り返しならば、スクランブル無しと思って良さそうです
fc490eb79f724098ed332bb2e5035fa3e60ddf16b4c3eee490e002f2d3247706
ff490cb79d724098ec3329b2e6035da3e70dde16b4c3efe491e003f2d2247506 レスありがとうございます。なるほど、特定の通信を除いてほぼほぼスクランブル無しなんですね!
確かに例のTCHの無音パターン2行は各所の活動波・主運用波・統制波とも共通で出てますからね、納得です。
仮に>>793のbit入れ替えが正しいとなると、スクランブル無しの部位は以前頂いたdecode_moduleのCELP出力でいよいよ音声化に達するんですよね。
特に音声としてデコード出来るとなると色々と判明するデータが多いですから期待に胸が躍ります。 549様おつかれ様です。
>>571の代わりにfunc_c975につながるのが>>793ということですね?
これをMCA形式に再構築してEF6190に割り込ませたらうまく行ったりするでしょうか。 >>808
> >>571の代わりにfunc_c975につながるのが>>793ということですね?
そうです
ただ、うまく音声を出すためには要素の部分的な入れ替え等、もう少し紆余曲折があるかと思いますです... >>807
decode_moduleのバグが無事取れれば...です
ここはTMS320VC5416 DSKなどの実機を持っている方のフィードバックが欲しいところだったりします ところで1.2GのFPUを受信したいんですけれど、都内でどこか受信できるところ内ですかね? 1.2の新波なら中継やってるところの10km圏内くらいなら8PSKがよく使われてるけどそのFPUとは違う? >>812
どもです。STD-B57のOFDM波が見られればと思ってますが、見たことありますか? 549様おつかれ様です。
>>809
>>309準拠の構成お見事です!
549様は旧MCA実機の音声ループバックには成功しておられますか? >>814
どもです
音声ループバックはチャレンジ出来ていません
シリアルコンソールも見つかっていないので...(NECのGALチップの近くかなと思っていますが)
うまくいっているならこっそり教えてください 毎度毎度失礼します
decode_moduleの実験版をupしました
あいかわらず動作は不完全ですのでデバッグ用途としてご了承下さい
ttp://whitecats.dip.jp/up/download/1539254151/attach/
(Fast Uploaderの調子がいまいちなので今回は白猫アップローダーを使わせてもらってます)
ダウンロードパス、展開パス共に >>125 に書かれている通りです
音声デコードの実験にお役立ていただけましたら幸いです
今回はおまけとして、解析時のメモ書きとして使ったFreeMindのマインドマップ形式のファイルを付けています
(FreeMind自体は ttps://ja.osdn.net/projects/freemind/ をご参照下さい)
これを見ると解析屋の気分を味わっていただけると思います
入り口はfunc_eaf4.mmです 赤い矢印を押すと各々の関数を辿れます
突っ込み歓迎です よろしくおねがいします こんばんわ、お疲れ様です。
decode_moduleいただきました、ありがとうございます。
いきなり詰んでます、実行ファイルへはどうやってデータを投げればいいのでしょう?教えて下さいませ汗 >>817
毎度手抜きですみません
proc.sh に書いてある input.txt を作ることが必要なのです
input.txtは1行1フレームで、16進数36文字ですが、これは今の601コマンドの出力では無くて、並び替えのテーブルを >>793 のものに置き換える必要があります
近々このへんを整理して出したいと思いますです どこかでSTD-T79, T80, T116を受信することはできませんか?SDRあるので試してみようかと、思ってます。
場所は都内がいいです。 >>818
すいません。
EF-6190( 2010年製)を手に入れたのですが、展開パスがわかりません。
機体番号とは違うのでしょうか。 >>821
一番上の行を漢字英数字混じりでそのまま入れて下さい
英数字は半角です
7-Zipを使うと漢字も入れられます 遅まきながらEF-6190 2台(1台はメモリーユニットA付き)を入手しました、しがない組み込み屋でございます。
部品のリワーク等は得意なんですが、既にダンプどころか解析も佳境のようで敬服しております。
前スレからの流れを改めて追わせていただきます。職場のHDDの肥やしになっていたこれをインストール
しましたので、お手伝いできることがありましたらお知らせ下さい。
https://imgur.com/a/1Z3N2uv >>824
よろしくお願いします
ファームの再upが必要でしたらお申し付け下さい
早速で何なのですが、適当なところにブレークポイントを設定して、
>>564 の手順を踏んだうえで、(5)の内容を教えていただきたく思います
(6650〜の9wordはオール0でお願いします)
お手隙なときにでもよろしくお願いします >>825
6650〜じゃなくて6550〜でした
すみません 早速レスありがとうございます。
TSOP48の読み出しは可能なんですが、アップしていただけるようでしたら
バージョン等の比較や組み立て方の確認用に使わせて頂きます(__) >>827
上げておきました(元バイナリ、組立済、ディスアセンブル済等々)
ttp://whitecats.dip.jp/up/download/1540463974/attach/
いつも通り、ダウンロードパス、展開パス共に >>125 に書かれている通りです
突っ込みなどありましたらよろしくお願いします OP25ってのを見つけたけど当方だとP25運用局なし
ttp://osmocom.org/projects/op25/wiki
AESとかあるのが気にはなるんだけど 前スレ549様
>>748を再うpいただけると助かります >>830
ご所望のファイルを再upしました
ttp://fast-uploader.com/file/7098798860991/
(暗号化アーカイブではないのでFast Uploaderにしました) >>831
ありがとうございます
度々お手数をおかけして申し訳ございませんが
601.c等が含まれるファイルも再うpいただけると幸いです >>832
あまり整理せずに全部詰め込んでみました
ttp://fast-uploader.com/file/7098872344919/
初公開のプログラムもありますが説明等は省略します 分からなければご質問ください >>833
お手数をおかけいたしました
ありがとうございます 削除されただけでしょ
あの音声聞いたけどどこかで録音した感じだった 前スレ549様、ほか活動中の皆様
5416DSKボードが起動できるようになり>>825を試そうと数か月・・
COFFヘッダ的なものが見当たらず>>100をメモリ転送できない状況です。
PAGE1->DATA、PAGE2->PROG0に割り付ければ何とかなる?と思うのですが
何か名案はないでしょうか... 大変ごぶさたしております&本年もよろしくお願いいたします
>>839
自分は手を出せていないのです...
自分ならまずはGCCのobjcopyコマンドを最初に試してみると思います 前スレ549様、大変ごぶさたしております。
>>840
ありがとうございます。
今更ですが、objdump -D で自己解決では?と思ったのですが、
自分の環境では当時から -d の対応すら出来なかったことを思い出しました。
.asmに成功されたおすすめのobjdumpを差支えなければ
ご教示いただけないでしょうか。 >>841
確か自分でビルドしたbinutilsを使ったと記憶しています
確かこの↓のページを参考にしました ここに置いてあるMinGW用バイナリで事足りるかもしれません
ttp://7shi.hateblo.jp/entry/2013/07/30/011348
supported architectures: に tms320c54x が入っていれば正解です >>841
1ヶ月頑張ってみました。
C54xのオブジェクトは -d(と-D)で.asmが生成できるようになりました。
549様のPAGE2,3は相変わらずうまく行きません。
-b binary -m tms320c54x とすると,binaryとは認識しますがそこまでです。
549様のop設定、各PAGEの連結や変換など、良いお知恵はないでしょうか。 >>844
レス遅くなってすみません
ディスアセンブルに使っていた環境がしばらく前に壊れてまして、再構築していなかったのです
これから再構築してみますので、もうしばらくお待ちください... ここの有志で共同購入して549氏に渡してもいいかなと思ったり >>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
併用でとても楽になりそうです。
入力側の応用は思いつきませんでした
鼻づまり感の雑感で毎回初期化すべきか
悩んでいました >>949
独り言ですが破声音や鼻濁音(連続パルス)の
mca実機はどんな感じ?と思ってます >>947
ええ、すでにデジタルMCAの実機持ってますよ >>949
音質の問題ですが、>>905をベースとして、
12, 13, 14, 15, 16, 17, 43, 44,
を
44, 12, 13, 14, 15, 16, 17, 43,
に、
51, 52, 53, 54, 126,
を
54, 51, 52, 53, 126,
に変えて試してみていただけないでしょうか... うそをうそとみぬけないひとはこのけいじばんをつかうのはむずかしいとおもいますね >>953
Ubuntu入れてますが。
それ位のスレの流れはちゃんとやってますよ。 残念ながらM-CELPと改良型RL-CELPは別物だから、どうにかして改良型RL-CELPを積んだ実機をどこかで確保して解析しないとダメなんだよ。 夜間留め置きの電車から無線機盗んだとかたまにあるけど、だめだぞ。 デジタルラジオマイクもこのスレの範疇?
2.4Gは無理かもしれないけど1.2とWS帯は研究しがいがあるのかな うそをうそとみぬけないひとはこのけいじばんをつかうのはむずかしい >>962
その気になれば実機を買えるし、いいネタだね。 >>951
>>956
もはや、お前に教えることは何もない。 おつかれさまです。
>>952
>>919と変わらない感じでした・・自分の処理間違いかもしれません >>967
お手数をおかけして申し訳ないです...
並べ替えをする前のビット列のうち、No Error保証された84ビットは、
(0-11) 前半フレーム, サブフレーム1:6bit+サブフレーム2:6bit
(12-17) 後半フレーム, サブフレーム3:6bit
(18-24) LSP.7bit
(25-42) 前半フレーム, サブフレーム1:8bit+サブフレーム2:10bit
(43-60) 後半フレーム, サブフレーム3:8bit+サブフレーム4:10bit
(61-65) LSP,5bit
(66-71) 前半フレーム,サブフレーム1:6bit
(72-83) 後半フレーム, サブフレーム3:6bit+サブフレーム4:6bit
残りのエラー訂正無しの部分の54bitは、
(84-91) LSP, 8bit
(92-114) 前半フレーム, サブフレーム1:11bit+サブフレーム2:12bit
(115-137)後半フレーム,サブフレーム3:11bit+サブフレーム4:12bit
とのフィールド分けを統計的に求めまして、>>905はこれをMCAのM-CELPのフィールド構成に想像で割り当てたものです
各フィールド内のビット列の順番は順不同の可能性ありと思い、お手数をかけていただいた次第です
こちらでも精査できるように引き続き準備を進めたいと思います... >971
おじいちゃん、かわいそうにボケたのね。。
わかりやすく浮上しないのよ。。 ところで、今般のM-CELPの解析で大元である800MHz帯デジタルMCAについても音声デコードできたりしそうですか?
>>577の通り毎通信のたびにスクランブルが異なるそうなのでハードルは高いかとは思いますが汗 ホントにそれ消防のSCPCで使われてるM-SELPなん?? デジタルMCA機から抽出したコーデックによって概ねの内容が理解できる音声としてデコードに成功したんだから、F-CHのM-CELPと同じで正解じゃないのかなと。
>>116の通りSCPC/F-CHとデジタルMCAのフレーム規格が相似してる事から鑑みても納得じゃないですかね >>968
ありがとうございます、お手数おかけします。
今いちど連絡しました。 >>978
確認しました
おっしゃる通り、>>905のままが今のところ最良だと自分も思います >>975
総当たりでも確か32767通りのはずですので、リアルタイムで無くて良いのなら可能だと思います >958
三菱単独ではなく下請へ出していれば末端の孫請からの流出に期待するしか無さそうだな
あるいは一応車載機だけではなく受令機もあるから故障した受令機の流出とか >>980
総当たりとなるとさすがにリアルタイムデコードは厳しいんですね、でも不可能ではないというのはワクワクします。
いつかデジタルMCAの通信も聞いてみたいです >>981
元JRの関係者なのですが、東に関して言えば、アナログ時代と比べて今のD機は受令機も含めて厳重管理なので、まず"おこぼれ"は期待出来ないかもしれません。廃棄に関してもアナログ機ですらハンマー入れを徹底してましたんで。
ただ今後改良型RL-CELPを搭載した列車無線システムはJR以外の各民鉄への波及が見込まれている(すでに採用・運用してる所もある)ので、あとはその民鉄関連からの"おこぼれ"を期待するしかないですかね。 文句言う人がちらほらいますが解析されてる方は気にせず書き込んでほしい! 高速のEL-CELPも実機がやはり確保出来ないと解析は難しそうだな
ただ本四高速とかはなぜかFSK使ってて聞けるが
タクシーでもQPSKの方は似たようなの使ってたか? 高速も鉄道も行政系も全部TETRAかFSKで十分だろ
地デジのBカスといいガラパゴスの糞システムなんてメーカーと総務省のオナニーでしかない
>983
警察や消防とかでも当然不要な機器をボカスカやってそうだな
不要な携帯破壊する時もだが基盤割るだけでなくチップを一撃必殺で粉砕しないとチップだけ生贄で取られたらそこから解析されそうだな >>987
Motoのtetra使え〜って花札大統領に圧力かけてもらうしかないな、かつての携帯電話方式のようにね。 ETCだって、導入当初は世界で最高峰のシステムだったな
情報提供とか駐車料金決済とかいろいろな日本独自の機能が盛り込まれた 受信機メーカーが一転して官公庁御用達メーカーになったんだからwinwinの関係というやつだな。 おつかれさまです
>>979
バグがどこにあるか見つけられない(位相がひっくり返る)状況ですが
テスト信号を折り返してみました(PWは以前とおなじ)
ttp://whitecats.dip.jp/up/download/1561048483/attach/1561048483.zip
とりあえず>889の様子を見たいと思います >>989
高速道路の決済以外の機能は使われなかったけどなw
時速180km/hでも通信可能なエアインターフェースだったけど、そんなの使える道路は日本にはないw アナログのままで十分なんだよ。だからIP無線にしろって言う話が広がるんだよ
狭帯域デジタルのメリットなんてねえんだから >>991
ほんのちょっとポツポツがある以外はほぼ同じでメリット5じゃないですか!すげえ >>991
いい感じですね。位相が反転するのは「そんなもの」な気もしますが...
こちらも何とか環境が整って、変換しているところなのですが、どうも最大音量付近に問題がありそうです
ゲインコードブックのマッピングミスがありそうな感じです
あと、古いPCなので変換が遅いです(42秒ぶんの変換に768秒かかりました)
これは、謹製コンバータのバグを取る方向で解決したいです... >>996
ご評価ありがとうございます
ぶつ音の件で今いちどご連絡さしあげました
ご指導お願い申し上げます。 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 869日 10時間 8分 6秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。