電子レンジで秒数間違えてひどいめに遭った。めちゃくちゃ熱い。これがワトソン・ワットの祟りか…… 速度違反とか茶化すから。。。うっかり生卵とか加熱しないように注意しないと(それは別のグループ
***
この人のSparkleのカバーが好みで結構聞いてたんだけど、最近はあんまり聞いてなかったんだよなー。
NAOJ/茨城大学の茨城日立局っぽい。'83年設置の三菱電機製32m。'07年までKDDIが衛星地上局として使用。'09年に移管。元々はCバンド(4/6GHz)だけど、電波望遠鏡としては22GHzまで使ってるそうだ。
同じようなアンテナが250mくらい離れてもう一つ設置してあるんだけど、片方が日立でもう一方が高萩。どういう命名規則なんだ?と思ったら日立市と高萩市なのか。敷地内を境界が横断しているらしい。なんでそんなところに用地確保したんだよ……
もう少し長い映像では経緯台に乗った反射式を覗いているシーンがあって、その後ろでアンテナがアジマス軸を駆動している。カタログスペックだと0.3度/sec(20分/回転)とのことだが、それよりはるかに早く動いているような気がする。元々は静止衛星用のアンテナだろうから、たまに衛星をスイッチしたり、必要に応じて1日周期の南北追尾程度の想定だと思うので、ΔVLBIみたいに素早い首振りが必要な運用は想定外じゃないかなぁ。そういう観測ができるように駆動系を改造したのかも。フルのMVが楽しみ。メイキングとかもあったら楽しそう。まぁ、僕が見たいような映像が入っていることはないと思うんだけども。。。
***
***
Gravityってスモークオイルとか入れる場所ないんだろうか?
***
映画撮影の機材は兵器類のテストを担当する部署が手伝いましたよ～
機内に設置するカメラでも、緊急脱出でキャノピー開けたときに乗員の方に飛んでこないように、強風にも耐えられるか確認する必要があったりとか。
カメラをボムラックに吊るアダプタとか。質感からして映画用に作ったものじゃなく、普段から使ってそうだ。
もしかしてMIL-STD-1760で接続して1553経由でカメラを操作したりNTSC経由でMFDにカメラのライブビューを表示したり、みたいな機能も作ってあったりするんだろうか? 偵察ポッドに偽装すればジンバルやズーム、モード、録画、一通り操作できそうだが。映画1本のためにそこまで作ることはないだろうけど、兵装類のテストを専門にやってる組織なら、そういう操作をやるためのアダプタの一つや二つは自前で作ってそう。
ネットに落ちてる1760のドキュメント、Appendixに座標系の定義が大量に書いてあってすごい。飛行制御とかフライトシミュとかをつくる人はこの資料を眺めるだけで座標系の定義で混乱しなくて良さそう。兵装類のドキュメントだから相対距離とかの定義もある。機内での座標系とかも定義されてる。戦闘機くらいのスケールならパララックスは問題なさそうな気もするけど、JDAMのINSとかだとそのあたりも計算しているんだろうか? むしろF-16みたいに柔軟な機体だと座標の歪みの影響が大きそうな気がする。AIM-120みたいに長時間の中間段階で慣性誘導を使うようなミサイルだと最初の角度誤差がかなり大きな値になりそうだし。射程が長い兵装を使うときは1G飛行だから気にしなくていい、みたいなことなんだろうか?
データ交換フォーマットも色々定義されてるけど、これはちょっと使いづらそうかな。CANでFBWみたいなシステムを作るなら使えるかな? とはいえさすがに飛行制御に使えるようなフォーマット(アクチュエータへの指示とか)は定義してないと思うんだけど。ドローンで吊り物つけるような大型のやつならあるいは……
***
前回はアナログTVで遊びましたが、またワンセグ。
前々回でコンスタレーションまで復調していたので、色々細工してビタビ復調まで
パスメトリックがゼロになって、204バイト/行でダンプしたら列で固まって47Hが出てくるので、おそらく正常に動いている気がする。
ビタビはパンクチャド(punctured)の場合、軟判定である必要があるようだ。手軽にやるなら抜かれたビットが0と1の両パターンでブランチメトリックを計算して、低い方でパスメトリックを計算すればいい。硬判定(ビットゼロ固定でエラービットとして処理)では正常に復元できない。
畳み込み符号/ビタビ復号、かなり面倒くさいアルゴリズムなんだな(例に漏れずエンコードは楽だけど)。ちゃちゃっとコード書いてみても全然動かないので、しかたなくホワイトボードで手動復号。拘束長3で5bit(+終端2bit)を復号するのに30分もかかってしまった。でも、終盤はだいぶ慣れて早く解けるようになってきたので、3時間くらいやってれば結構早く解けそうな気がする。サマウォで暗号鍵の解読繰り返して最後は暗算でやってたけど、あながち大嘘でもないのかな、という気がしてきた(暗号解読は人間が可能なものとする)。
qiitaでビタビ復号を探しても出てこないので、結構マイナーな遊びなのかな? ビタビアルゴリズムで探すと記事がいくつか出てくるけど、タイトルを見た雰囲気では誤り訂正とは別の分野の記事のようだ。ビタビとか最尤判定は音声認識とかの分野でも使われている概念(『南極点のピアピア動画』でも音声認識で最尤判定が使われていたはず)。
逆拡散後、TSPヘッダの抽出
同一PID内でCCがインクリメントされていたり、PID0x1FFFがFFhで埋まっていたりするので、たぶんちゃんと読めてる。予想よりFFh埋めが多い。そりゃエネルギー拡散も必要だろうて。同期バイトが一番最後に来ているのが謎い。どっかの実装間違ってるかも。
RS符号は後ろに訂正用のデータを追加する形なので、畳み込み符号のようにデータ列そのものが書き換えられるわけではない。なのでビットエラー率ゼロで伝送できているなら後ろの追加データを消せば元のデータが得られる。
末端17バイト(RS符号+同期)を捨てた187バイトを、頭に47hを追加して188バイトずつにしてバイナリデータで書き出して、拡張子を.tsにしてからffmpegでMP4に変換したら、ちゃんと映像や音声が再生できた。短時間のデータなので動画も一瞬だけど、それでもちゃんとワンセグの画質でワンセグが見れた。
ということで、ワンセグチューナーで受信したワンセグ放送のIQストリームからトランスポートストリームを取り出すのは動くようになった(だいぶ手抜きだけど)。結構大変だったなー。ただ、デジタルデータ故に大部分でデジタル的な処理ができるから、アナログテレビ放送みたいにAGCとか同期信号とかの面倒な部分は触らなくて済む。
*
Visual Studioってコード中でF1キーを押すとカーソル位置に関連するドキュメントに飛べるんだな。言語仕様とか、標準ライブラリとか、ググって出てくるlearn.microsoftには一通り飛べる? 一部飛べないコード(e.g. 範囲処理/array[i..j])もあるけど。今までいちいちブラウザを開いて関数名とかは名前空間も含めてググってたので、F1で直接飛べるとなるとめちゃくちゃ便利だ。知らなくて相当損してた。。。F1キーというと古いPCでクッソ重いダイアログが出てくる悪夢が。。。あの当時のヘルプファイルってなんであんなに遅かったんだろうな。
***
小ネタ中の小ネタ
乾燥海苔とか焼海苔はDNA分析で原産国を判別できるらしいから、生化学の実習で使うことはできそうだ(何の話だ
ゲストの人、前回もそうだったけど、理論の方の人だからかこういう企画とは相性が悪そう。
[攻め旅] 世界一まずいアメ！？『サルミアッキ』がフィンランドではお菓子売り場の約6割を占める理由とは？とっておきアレンジレシピも | これって攻めすぎ！？世界旅行 | NHK - YouTube
リコ…… いや、それじゃない。BASF、最近やたら見かける気がする。まぁ、実際には今までも目にしていたけど、認識していなかっただけなんだろう。リコリスとかも。……秋月電子とか。
Call of Duty: MW2 FSS Hurricane IRL - YouTube
AR-57は日本だと5年ほど前に発売された某ビデオゲームで使った記憶が。たしかリリース当初はこの銃を使うと進行できなくなるバグが有ってなぁ。装弾数多くて反動少ないので好んで使ってて何故か進めないって延々悩んだ記憶が。。。/* そういえばあのゲーム序盤しかやってないのでわ…… */
H-IIA#14のトラブル、ググっても出てこねーんだよな。原因とか、対策とか。
DCS F-16、編隊飛行や空中給油、コツというほどじゃないけど、HUDや水平線を意識したら負けかな、という気がしてきた。そういう外部の姿勢情報を取り込むとそっちに引っ張られてしまう。相手だけを見て付かず離れずを意識すれば、それなりに安定して飛べる。本物の飛行機だとどうか知らないけど、少なくともゲームで遊ぶ分にはそういう意識で飛ぶと安定する。
地球近傍小惑星の2010RF12、8月に再観測されていたらしい。2095年に4.6%の衝突確率と言われていたやつ。新しい衝突確率は数万分の1程度へ大幅に下方修正。元々は観測点が少なかったので安全側に大きく振っていたのだろう。小さい小惑星なので地球に突っ込んできても大した被害はないという予想だったから、ちょっと残念というか、なんというか。いや、突っ込んできたところで見れるわけじゃないけれども。
北海道 (留寿都・札幌) における「マルチワンセグメントサービス実験」への参画について〈参考〉 | 2008年 | KDDI株式会社
地下街等を対象に、地上で受信したフルセグから部分受信(1セグ)を取り出して、複数ch分を13セグにパックして中継する。放送側はフルセグ用の送信機にソフトウェアの変更程度で13ch分を再放送できるから機材的には楽なのかな? 受信側は少なくとも標準ISBD-Tでは対応できないはずなので、結構大変そうな気がするが。セグメントが変わるとインターリーブのパラメータも変わるので、PLLの制御を変えて中間周波数だけ動かすみたいな対策では対応できないはず(全部セグ0のパラメータで出してる可能性もあるけど)。
別の資料によると地下街等で独自のコンテンツも同時に放送するような仕組みを考えていたらしい。
https://www.jstage.jst.go.jp/article/itej/64/12/64_1854/_pdf/-char/ja
ワンセグは，地上デジタルテレビジョン放送（以下ISDBT）の一部であり，ワンセグ単独の規格はありません．もちろん，ワンセグという呼称も，いわゆるニックネームであり，技術規格のどこを読んでもその名称は出てきません．
ARIB STD-B31v2.2およびB21v5を読む限り、どちらも少なくとも数か所は「one-segment」という字面は出てくるから、「どこを読んでもその名称は出て来ない」というのは言いすぎな気がする。もちろん英語版の資料なので「ワンセグ」という呼び方は出て来ないが、日本語版の規格書なら「ワンセグメント受信」くらいの表現は出てきているはず。
ワンセグ放送(映像や音声)はアナログテレビとの後方互換性のような観点で作られたそうだ。アナログテレビを車載で受信することは可能だったし、例えばch1,2,3であれば通常のFMラジオでも(ある程度は)受信できていたから、同様にデジタル化しても移動受信や簡易的な装置での音声受信ができる必要があった。当時(1990年代末頃)の技術では帯域幅6MHz、伝送レート20Mbpsというような情報量を実用的な消費電力で扱うことが困難だったから、ワンセグ放送(狭帯域幅・低伝送レート)で実現した(Gbps前後を通せる最近のスマホからすれば大昔の話だ)。
http://www.shimafuji.co.jp/product/Download/semc6001pamphlet.pdf
当ブログではSpaceWire関連でお馴染みのシマフジの、ワンセグ送信機。微弱無線局扱いで免許不要で運用できるモードもあるそうだ。外部からTSを突っ込んで、マイコン(RISC1200MIPS)でIFFTまで行って、FPGA(Xilinx)経由でRFへ。
FPGAの担当がかなり狭い気がする。XilinxならFFTライブラリとかもあるし、マイコンはキャリア列の生成までで、FFT以降をFPGAに投げたほうが楽そうな気がする。マイコンから時間ドメインの信号列が順番通りに出てくるならFPGA噛ましてFIFO組む利点もほとんどないだろうし。
https://j-nav.org/navsys/workshopreport/report/r2006a/abst2006a/material/knb.pdf
ワンセグ放送でGPSの補正情報を放送する実験。ワンセグには未使用のパケットが5.8kbps分あるので、ここにGPS補正情報を入れる(ワンセグ放送の画質を落とさずに済む)。cmオーダーの精度が出るそうだ。
https://www.jstage.jst.go.jp/article/itej1954/28/3/28_3_192/_pdf/-char/ja
1974年の静止画放送の論文(実用化はされなかったシステム)。例えばテレビ放送を流用するシステムでは1秒間に30枚(あるいは60枚)の画像を伝送できるから、TV1ch分で膨大な静止画を伝送できる。ニュースの文字起こしのように時間軸の分解能が低くていい媒体の伝送を考えていた。あるいはレイテンシ数秒程度のランダムアクセスとしても使える。
画像ではなく文字データを伝送して受信側で文字発生器を使う方法は英語圏のシステムとして紹介されている。「わが国のように漢字が必要な場合は文字発生器がぼう大なものになるから実用性はない」だそうだ。完全に使い物にならないと切り捨てている。漢字ROMが出てくる少し前の時代だからなぁ。1家に1台置くようなレベルで普及させるには厳しかろう。
https://www.jstage.jst.go.jp/article/itej1954/30/10/30_10_860/_pdf/-char/ja
'76年に書かれた静止画放送関係の話。各国のシステムとか。
文字放送の場合は誤字脱字があっても人間が文脈上から補正できるとか書いてある。誤り訂正を人力でやるシステムだ。
アイパターンって最近のGsy/sくらいの時代の話だと思ってたけど、この頃にはすでに使われてるんだな。
メモリはまだ磁気を使う想定だけど、半導体メモリも十分使い物になるという雰囲気。全画面のメモリで「せいぜい50kbである」だそうだ。QVGA程度の解像度で1bit/pixelならその程度であろう。システムによっては文字の色を切り替えたりする機能もあるので、もう少し容量多いほうが良さそうな気はするけど。
テレビで、深夜にサブchで音楽放送やってるのがあるんだな。メインチャンネルはニュースとか。ニュースは読み上げメインなら画質はほどほどでいいし、音楽放送も画質はそれほど必要ないから、ニュースと音楽を階層化して放送するのは理にかなってるのかな。ワンセグ放送だとTMCCで端末ON/OFFの制御が可能だから、音楽放送が終わるときに端末をOFFにするみたいなシステムも作れるんだろうけど、基本的に緊急放送用のはずだからそういう運用はできなさそうな気がする。そもそもワンセグはニュースの方を放送しているはずだから音楽放送は受信できないだろうし。次世代地上波放送だとそのあたりもう少し柔軟に作れるのかな? 小型端末向けの低画質放送を2種類、固定受信向けの高画質放送を2種類、みたいな。まぁ、寝ながら音楽聞くみたいな使い方ならスマホでストリーミングなり流しながらスリープタイマー設定すりゃいいじゃん、という話ではあるけど。
0 件のコメント:
コメントを投稿