ここ最近、インターネットが調子いい。少なくとも、DNSが見つからない(8.8.8.8にPING打ってタイムアウトする)みたいな事態は発生していない。深夜時間帯はあいかわらずYouTubeの画質がだいぶ下がるけど。なんか、ほんとに春夏頃の季節限定で回線が遅くなってるんじゃないか、という気がする。基地局の設備がたかだか北海道の夏程度で熱ダレするとも思えないんだけど、では他に何があるかというと…… 空気中の水分量の違いはありそうだけど、それにしたって水蒸気がせいぜい数GHzを膨大に吸収するとも思えないし(電子レンジが2.4GHzなのは一番水に吸収される周波数だからだって? 何言ってるんだ!!)。
***
JAMSTECの音を使った水中通信。
6kHzから9kHz(幅3kHz)のOFDM/QPSKっぽいなー。
軽く相関処理させてみるとピークが2本(自己相関とGI相関)出てくるので、OFDMで間違いないんだろうけど、いまいち納得感の薄い結果になってしまった。ということで相関結果の詳細は省略。
軽くググったところによると、水中の通信速度の評価基準は距離とビットレートの積で、市販の機器だと40kbps・kmくらい、JAMSTEC開発のやつで500kbps・kmくらい、らしい。しんかい6500の場合は直上の母船まで6.5kmなので、80kbps近く出る。ワンセグが312kbpsくらいなので、その4分の1くらい。カメラの解像度はワンセグと同等、フレームレートは40分の1くらい。ビットレートが遅い以上にフレームレートが低くなってる。ワンセグは強烈な非可逆圧縮でビットレート落としてるのかな? 母船で拡大して見るに耐える画質で送ろうとするとあんまり圧縮できないのかな。
水中のシステムも面白そうだなー。僕の場合は日本47都道府県のうち全周を海に囲まれたただ2つの道県のうちの一つに住んでいるのに、あまりにもデカすぎて海に全く縁がない生活を送っているので、水中システムとも縁遠いわけだが。まぁ、そんなこと言ったらこのブログで扱うネタ全判(航空宇宙防衛装備その他)も縁遠いけど。
/* ちなみに、ウチから一番近い海岸は直線で100km、車道で120kmくらいのところ。予想以上に近かった。人口1500人くらいのエリアらしい。 */
蛇足。水中生活中の楽しみの一つ。
ちなみにこの笑顔で炭酸飲料を振り回す髭のおじさんはSpace Oddityでおなじみクリス・ハドフィールド。
***
USB Type-C Power Deliveryなハンダゴテ。やっと出てきた? 製品自体は1年近く前から売ってるのかな? もっと早く出てくると思ってたんだけど、僕の観測範囲だとこれが最初(可視狭いからなぁ)。
24.99USDだって。
USB Type-C Power Delivery、以前で100W、最新規格で240Wも出せるんだからもっと色々使えても良さそうなのになぁ。いまいち広まってない感じが。
/* 節電テクを紹介するサイト、石油ファンヒーターが消費電力700Wで計算されてて信用しちゃいけない匂いがプンプンする。こいつカタログスペックの最大消費電力しか読んでないな? */
***
昔読んだファンタジー物で、自然発生する魔素が飽和するとスタンピードが発生するからなんとかしなきゃいけないんだけど、ある地域ではスタンピードが発生したことがなく、そこの管理人がすごく優秀、みたいな話で、しかしその実態は地下に大きな魔物(ベヒモス)を閉じ込めて魔素を固定しているだけで、こいつらが暴走すると大惨事に、みたいな話だった気がする。
なんでそれを思い出したかというと、ヘリウムみたいに岩盤の下に二酸化炭素を入れるの、どっかで読んだような話だなぁ、とか思ったので。深海に埋まっているメタンハイドレートは実は有史以前の管理人が温室効果ガスを埋めた結果だったのだ!! ナ、ナンダッテーッ
今から数千年後に寒冷化した地球で細々と生き延びていた人類が石油を掘ろうと思ってボーリングしていくと不燃性のガスが噴出し、調べてみると膨大な温室効果ガスが岩盤の下に埋まっていることが発見され、それを放出することで地球を温めて生物が生活できる惑星を取り戻す、みたいなSFはありそうだ。
「みらいの人類たちへ。寒くなったらここを掘ってね」みたいな書き残しのある洞窟。偶然に猟犬が迷い込んでそれを追いかけてきた人が文字を発見するのかな。
植物が育たなくなり、動物も減り、食べるものにも苦労する世界で、狩りも採取も下手な、いつもよくわからない模様が彫ってある板切れを眺めている村の爪弾きもの。ある日、採集に出かけていた老人が面白そうな模様を見かけたと言って書き写してきてくれた。その少年はその文字を読むことができ、数少ない自分を信じてくれる大人たちと洞窟の探検にでかけて……
うーん、莫大な量の二酸化炭素を掘り出すんだろ。絶対二酸化炭素中毒で死ぬやつやん…… 温室効果ガスを放出したって地球全体が凍ってたら温まるのに相当時間がかかるだろうし、「あんな奴を信じて旅立った大人たちは馬鹿だったんだ」とか村に残ったやつに言われて、そいつらが老人になる頃に「俺たちが若い頃は苦労したんだ。昔はもっと寒かったんだよ」みたいな昔話になるんだろうなぁ。
作業を手伝ってくれていた大人たちがバタバタ倒れていく中で、少し高いところで指示を出していた少年は大人たちより発症が遅れて、知識のある彼は「これは二酸化炭素中毒の症状だ! 僕たちは世界を救うことができたんだ!」と知って倒れていくエンディング。切ねぇ話だ……
洞窟を発見するのは、猟犬使いの女の子のほうがいいか。歴史的にも。洞窟で見かけた模様が、幼馴染の男の子が熱中している模様と似ていて、狩りから帰ってから「このあいだ入った洞窟でそんな模様見かけたよ」みたいな話をするの。見に行って、旧人類の遺跡だと言うことを知り、一旦戻ってから手伝ってくれる大人を探して遺跡の奥へ向かう。女の子は帰らなかった人たちを思いながら、洞窟を教えた自分を責めて大人になり、やがて温かい世界で、動けなくなった体を横たえて「もうすぐ会えるね。あなたがいなくなってから生きやすくなった世界を教えてあげるよ」と目を閉じるエンディング。
あれ? なんでこんなに登場人物が死んでいくんだ? そういう作品は嫌いだって言ってるじゃないか!!
寒冷化した未来の地球に遺すのなら、赤道付近の安定した岩盤に井戸を掘る必要があるか。アフリカプレート、現在のコンゴあたり? ただ、寒冷化した場所だと火山地帯に人が集まりそうな気もする。でもそういう場所で地下貯蔵は嫌だよなぁ。
次に地球が寒冷化するのはいつなんだろうか。万年オーダー? そんな先まで保つ井戸、大変そうだ。開閉する必要はない(開けるときは破壊すればいい)という考え方なら多少はマシだろうけども、それにしたってなぁ。あんまり頑丈に作りすぎると次の文明で開く手段がなくなるし。爆薬を準備しておくにしてもそんなに長期間置いといたら変質しそうだし。
氷河期の数万年サイクルを考えると、「万年雪」って実は適切な表現なのかな?と思ってぐぐってみたら、「数年単位で代謝するのが万年雪」「数万年単位で代謝するのが氷河」だそうで、なんとも迷惑な名前をつけたものだ。。。万年単位で代謝するほうに万年雪って名前つけるべきだろ!!
次の文明にどうやって遺言を残すか、という話は放射性廃棄物の関連で出てくる話題。もっとも、こっちは「絶対に掘り返すなよ」というメッセージだけど。「目印を残したら興味本位で掘るやつがいるから何も残さない」みたいな案があったはず。オーダーとしては10万年くらいなので、上記の次の表記に対するメッセージと近い。
***
イプシロンロケットでISSに定期便、という空想。
イプシロンならISSに1発1トンくらい打てる。2ヶ月ごとに(年6機)打上げれば、HTVを年1発打つのと同じペイロードを運べる。コスト的には、イプシロンの低コスト化が進めば6xイプシロン < 1x(H-IIB+HTV)となり、打上げ単価的には許容範囲。
固体段は通常のイプシロンを流用。液体段(PBS)は新規設計。有人安全の実現と6自由度化が必要。ドッキングはHTV技術を応用。近くまで接近した上で地上からの遠隔操作によってキャプチャ。
ペイロードは与圧・非与圧を混載。与圧物資は与圧ボトルを非与圧貨物の扱いで搭載する。与圧ボトルはJEMエアロックを通過できる形状とし、船内に持ち込んだ上で開封作業を行う。
JEMのエアロックは300kg程度しか通せないらしいので、全物資を与圧とするなら、少なくともボトル3本以上に分割して打上げることになる。定期便なので、ペイロードごとにパッケージングしてからまとめて搭載・打上げ、という形になるか。
元ネタは「宇宙で気軽に生鮮食品を食べるには」というやつで、詳しく読んでないけどどうやら食品の長期保存みたいな文脈だったらしいんだけど、今回はロケットの定期便という方向で話を転がしてみた。
単体で見るとわりと実現性ありそうな気がする。定期便とせずとも、固体ロケットの保存性を考えると「緊急時に即座に1トンを打てるランチャーを常に準備しておく」とかは良さそうな気がするな。ある程度保管しておいて消費期限が近付いてきたら適当にリザーブされてた小型衛星やキューブサットを打てばいいし。まぁ、そういう緊急用の備えはドラゴンやスターライナー、シグナスみたいな欧米の補給機でカバーできるだろうけども。そんな事態になったら支援物資を用意するのだって大変だし、帰還カプセル使うだろうし。
HTV回収カプセル(HSRC)、微妙にJEMエアロックを通過できなくて残念な形状なんだよなぁ。直径で1%ほど、高さで3%ほど、エンベロープをオーバーしてる。なんか中の人同士ががケンカしてカプセルチームが「絶対エアロックなんか使ってやるものか!!」とかスネたんじゃねーかってくらい。
JEMエアロックをHSRCが通るなら、実験サンプルをHSRCに入れてイプシロンで打上げて、JEMに取り込んですぐに実験開始、実験終了後は直ちにHSRCに戻して日本付近へ再突入させて回収、というシーケンスが組めるんだけど。
/* メモ：JEMのエアロックのエンベロープを最大に使うと比重0.46で300kg */
***
「ラングレーが開発した超高感度なセンサ」と聞いて、人は一体何を思い浮かべるだろう? わりと無視できない数の人が、某国中央情報局が開発したいわくつきのデバイスを思い浮かべるんじゃないだろうか? ボロメータがそんないにしえの装置だとはつゆ知らず、ぼくはまんまと騙されたのでした。「ははーん、さすがあの国の情報組織は一味違うね」
ラングレーと聞いて、バージニア州の地区を思い浮かべる人は、物理学者を思い浮かべる人よりは多いと思うのだが、どうだろうか。
ラングレーさん、スミソニアン天体物理観測所の初代所長とか、ボロメータの開発とか色々と残していて、デバイスとか天文が好きな自分は高く評価している一方で、スミソニアン博物館とライト兄弟の確執とかもあって、航空機好きの自分は評価下げ気味。
ASTRO-Hの観測機器しかり、ボロメータは活躍しているけど、短波長(高エネルギー)側ってもっと良い検出器ありそうなのに、「ぶつかってきたエネルギーを熱として計測する」という、すごいシンプルな検出器使ってるんだよな。エネルギーが高いからこそ使えるのかな。あるいはエネルギー分解能の問題かもしれないけど。
これだけ研究開発が盛んに行われているカメラの周波数分解が3binしか無いんだから、半導体単体でエネルギー分解やるのは大変なんだろうな。Faveon X3みたいに垂直方向に色分解する画素もあるけど、それでも信号処理で3binに分解してるだけだし。原子核乾板も垂直方向でエネルギー分解する鉛板とのミルフィーユもあるけど、それにしたって分解能は悪いだろうし、電気的に検出しようとするとセンサを多層に配置しなくちゃいけないから大変そうだ(エネルギー検知は粒子の通過だけ検出できればいいので空間分解能は不要とはいえ)。結局はエネルギーをエネルギーとして検出したほうが使いやすいのかな。
カメラの画素が3binしかないのは「人間の視覚がそういうものだから」という話なのかもしれないけど、今の時代なら2次元をスペクトル分光できるカメラがあれば色々便利な気がする。ある程度安く作れれば、少なくとも植物を管理する業種の人たちは喜んで買うはずだし。マシンビジョンで使うにしたって異物検出とか色々応用がありそう。店の果物コーナーでスマホを取り出す人が増えそうだ。「店内でのスマートフォンのご使用はご遠慮ください」なんて張り紙が出る未来もそう遠くはない可能性が。で、日本のスマフォメーカー各社は自主規制として青果コーナーのある店でのカメラの起動を防ぐプログラムを入れて、結果的にゼンリンが儲かる未来。今のうちにゼンリンの株を買っておけ!! /* ZENRINとSIEMENSのロゴってどうしてあんなに似てるんだ? */
そういえば、ハッブル宇宙望遠鏡はCCDだと紫外線に感度がなくて、どうやって検出するかで苦労したみたいな話を、ディスカバリーチャンネルだったかでやってたな。曰く虫の目の蛍光を応用したんだとか。蛍光物質が入った液体は「バグジュース」という名前で呼ばれていたらしい。そんな名前にするから光学系バグって…… おっと、だれか来たようだ。
宇宙の膨張自体は、それこそハッブル宇宙望遠鏡の名前にもなっているエドウィン・ハッブルが観測した「ハッブルの法則」によって知られていたわけだけど、それでもHSTでは紫外線観測が重要だったんだな。その後続機たるジェイムズ・ウェッブ宇宙望遠鏡は紫外線どころか可視光すらも観測せず、膨張によって引き伸ばされた赤外線に狙いを定めているのだが。「思ったより宇宙って広いんじゃね」っていうのは、ハッブル・ディープ・フィールド等で得られた知見だけど、それを観測した次の望遠鏡では一気にそれ狙いで観測するようになってしまって。まぁ、間が空きすぎって話なんだけど。
NROからもらった衛星はどうなったんだ?と思って調べてみると、2025年打上げ予定だとか。まぁ、当然遅れるんであろうが。予備部品もらって組み立ててそんな時間経って大丈夫かね? /* そうか、米国家偵察局からもらった部品で海王星探査機を作ると「Neptune Reconecense Orbiter(略称NRO)」が作れるんだ…… */
***
Waveファイル、dataチャンクのサイズってゼロでいいんだな。びっくり。SoundEngineでもGoogle Chromeでも正常に再生できる。Windows Media Playerはハングアップしたけど。SoundEngineはalign bytesが無いと再生できないのに、dataチャンクの長さは不要らしい。
歴史的経緯で考えると、Waveを録音中にチマチマdataチャンクの大きさ書き換えるの面倒くせーよ、みたいな実装が多くて、dataチャンクの大きさがゼロの場合は以降のデータをすべてdataチャンクとして扱う、みたいな事になったのかもしれない。
で、さらに驚きなのが、dataチャンクの大きさがゼロの場合、32bitリミットに引っかからずにデータを格納できる点。例えば16bit,2ch,48kSa/sで8時間のデータは5.15GiBとなり、32bitで表現できる範囲(4GiB)を超えている。にもかかわらず、SoundEngineもChromeも、正常に8時間の音声データを認識している(いちおう、シークバーを動かせば正しく再生はできることは確認したが、単純なトーン信号なので、本当に正しく再生できているかは未確認)。
地味に嬉しいトリックを見つけてしまったかもしれない。ソフトウェア無線のベースバンドをWAVファイルで書き出そうとすると4GiBリミットをどうやって解決するかが面倒なんだけど、とても簡単だった。
「データをとにかく書き込んでいけ。データサイズはゼロで固定しておけ」
データチャンクの大きさを64bitで管理しておいて、閉じるときにチャンク長が32bit未満であれば通常のWAVとして書き出して、それを超えていればチャンク長をゼロのまま閉じる、みたいな実装にしておけば、4GiB未満であれば互換性が十分あり、それ以上でもデータ自体は保存できる(対応していれば開ける)、という感じになりそう。
rtl_sdr.exeでバイナリファイルに書き出して、あとから先頭44バイト部分にWAVヘッダを上書きする、みたいな処理でも良さそう。
これってどれくらい一般的な挙動なんだろう? Wav64が普及しないのはこの実装のおかげなのかな。もっとも、4GiB超える音声データって普通は使わないと思うので、そもそもWav64なんてほとんど必要とされてなかった、みたいな理由なんだろうけど。
Chromeは結構すごくて、768kSa/sまでのWAVを再生できる(768.001kSa/sはダメ)。数値的に意味がある値ではないので、メディア関係のライブラリ書いた人がエイヤと決めた値なんだろうけど。せっかくなら2048kSa/sくらいまで対応しててくれれば、ソフトウェア無線の中間ファイル(デシメーション前)を直接再生できるのでデバッグに便利なのに。
***
今週は進捗ダメでした。
特小受信ソフトは中断状態。次のネタ…… なにやろう……
0 件のコメント:
コメントを投稿