小ネタ

「2泊してからラベンダー見に来い」

　……ラベンダーが有名なエリア付近の人かな???

　YouTube、デザイン変わった気がする。トップページのサムネがデカくなって1画面で見れる情報量が激減した。Googleが時々やる改悪。今回の場合は見づらくなるとかその程度でさほど大きな問題ではないとはいえ。。。

　でっかいテレビをリビングにおいて離れた場所からリモコンでポチポチする、みたいな使い方を考えると、サムネが大きいと便利そうではある? PCから見るなら不便すぎるけどな。

　米ミサイル防衛システム「ゴールデン・ドーム」、スペースＸが重要部分で最有力候補に | ロイター

　今更固体燃料に手を出すつもり? 既存の軍需企業が作る固体燃料より安く作れるかもしれないけど、とはいえベンチャー企業がアジャイル開発する製品をド正面の防衛装備品に使うのはちょっとなぁ…… 歴史のあるメーカーが作ってるミサイルの固体燃料だって場合によってはトラブってるのに、全く経験のない会社がいきなり信頼性の高いものを作ろうとしてそう簡単に作れるとも思えんが。

　それとも液体燃料を使うつもりなんだろうか? NCADE(弾道ミサイルのブーストフェーズを撃墜するAIM-120サイズの空対空ミサイル、キャンセル)では制御に1液グリーンプロペラントを採用する予定だったわけだが。とはいえ、それにしたって固体燃料で加速したあとの話だし。一応、SpaceXもドラゴン宇宙船(有人系)でヒドラジン系を扱っているし、常温系液体燃料のノウハウもそれなりにありそう。しかし、AAMならともかく、SAMで液体燃料を使うかなぁ。そういう固定観念を壊して安く作ろうぜ、って話になるのかもしれないけど。

　SpaceXってわりと燃料種類のバリエーション多いよな。ロケット用のケロシン/LOXやメタン/LOX、ロケット用RCSのLN2コールドガス、輸送船のハイパーゴリック、衛星の電気推進。いままで固体燃料を使わなかったのはやっぱり制御性の悪さとか? これを機にDoD予算で固体燃料の経験を得よう、みたいな腹づもりなのかしら。そんな「予算の浪費」が許されるかな?

　ルネサス製品ForgeFPGAの評価ボードを使ってロータリエンコーダを動かしてみた | 組込み技術ラボ

　Nucleoみたいに投げ売りして販促するボードじゃないから、開発ボードいい値段するね。パッケージ/ピン互換のチップを載せ替えて色々試せるように、とか、デバッグ用の機能も色々乗ってるんだろうけど。

　マイコンみたいに単体でいろいろ使えるようなものでもないし、評価ボードの売り方も難しいんだろうけど。

　せめてブレッドボードに載せられるような簡素な変換ボードが秋月あたりで販売されれば楽に遊べるようになるんだけどな。書き込み(USB-SPIブリッジとか)に一工夫必要だけど、Arduinoを使い回すとかすればいいわけだし。なんたって自社のMCUが乗ってるんだからな。

　ミニマルファブの時代がやってくる！：半導体工場を3000万ドルで構築（1/3 ページ） - EE Times Japan

　記事中では「ミニマルファブ」や「ミニファブ」が出てくるけど、産総研等が開発している固有名詞としての「ミニマルファブ」とは無関係っぽい。まぎらわしい…… 名は体を表すという意味ではミニマルファブという固有名詞はわかりやすいけど、とはいえ直交性が悪いよなぁ。

　MCUの「礎」的存在、Microchip「PIC16」：マイクロプロセッサ懐古録（3）（1/4 ページ） - EDN Japan

　Microchip設立の由来とか。

　Flash ROMの搭載で「(前略)だからといってProduct Definitionの期間が短くなるというのは理解しにくい」という話、後からFlushを書き換えて機能の変更ができるのであれば、最初の製品定義の段階で顧客の需要をキッチリ作り込む必要がなくて、後で必要な機能とか不要な機能が出てきたらそのときに対応すればいい、みたいなことなんじゃなかろうか。

　しかし、Microchipって社名の通り最初からマイクロコントローラーの会社なんだな。なんで原子時計扱ってるのか本当に不思議。

　Amazon.co.jp: All You Need Is Kill (集英社スーパーダッシュ文庫) 電子書籍: 桜坂洋: Kindleストア

　https://www.amazon.co.jp/dp/B00C7PU87G/

　そういえば読んだことないなー、と思って。2004年発売(映画は2014年)。

　原作と映画ではストーリーが全く違うな。原作はいかにもライトノベルという感じ。結末は映画のほうが好きだけど、映画では説明されていない部分も色々と書いてあるので、原作もオススメ。設定がだいぶ違うからそのまま流用できるわけではないけど。

　全く知らなかったけど、1ヶ月ほど前にアニメ化が発表されていたらしい。原作とも映画ともまた異なる内容だそう。自分としては原作と映画の中間くらいの感じで作ってくれると嬉しいなーといったところ。

***

https://www.jstage.jst.go.jp/article/zisin1948/44/Supplement/44_Supplement_15/_pdf

　1991年。地震計の波形の伝送に関する話。

　従来は無線回線、現在は専用回線や電話回線が主流で、衛星回線も出てきた。従来はアナログ波形の伝送が多かったが、計算機で信号処理する場合はどこかでA/D変換が必要になるから、地震計でデジタル化すれば信号を劣化させず、圧縮処理等も行いやすいから、これからはデジタル化が進むだろう。ただし伝送帯域を大幅に増やすことはできないから、非線形符号化等でダイナミックレンジを広げると大きな波形に乗った小さな波形が見えなくなったりとか、課題もある。

　衛星回線を使ったシステムでDCPの例もある。1MBのメモリと太陽電池・蓄電池を持ち、衛星経由のデータは基本的には磁気テープの形で得られるが、必要に応じて管制センターに問い合わせれば数分以内に取得できる。日本のひまわりを含めて4機の衛星が対応しているが、日本にはDCSを使った地震計は無いとのこと。

　衛星1機で数千台の地震計を中継できるそう。1日1440分でタイムスロット1.5分とすると最大限に詰め込んでチャンネルあたり1日に1000パケット弱、複数チャンネル(衛星1機あたり133ch中継できる)を割り当てればその数倍、需要さえあればまあ、割当はできるか。

　周回衛星を使った場合、1日に1KB程度しか伝送できないらしい。

　DCSは1パケットで600文字強(7ビットデータ+パリティ、バイナリデータ不可)を送れるから、16進で325バイト程度のバイナリを送れる。1キロバイトを送るには3パケットくらい必要。1パケットを送るのに1分、最大仰角の1パスで2,3パケット送って、場合によっては前後のパスで1パケット程度、と考えると、1日に1KB程度というのはそう遠くないか。DCSって転送レート結構低いんだな。

　データ転送を目的に周回衛星のDCPを使うのは難しそうだ。そもそも、低緯度地域なら静止衛星を使えばいいし、高緯度地域なら周回衛星のパスが多いから、場所によって相手を選べば問題ない、という設計思想だろうし、片方を選択して使うというものでもないんだろうけど。というかDCSってすべての衛星で(静止・周回問わず)共有のアップリンク周波数を使うはずだから、静止衛星相手に指向性アンテナを使うみたいなことをやらない限りは、ユーザーからは静止・周回の区別なく使えるはずなんだけど。

/* そういえば、1パケット最大650文字程度の制限は日本独自の仕様であって、海外仕様だとその制限はないはずだから、海外のDCS地震計は、リンクさえ成立すれば1パスで一気に1KBくらい送れるのかも */

　この当時はISDNはまだ都心部だけだが、64kbpsは現在より1桁増えるので、利用地域が広くなれば地震観測にも使いたい。

　地震計は市場規模が小さいので十分に開発リソースが投入されているとは言い難い。日本では優秀な技術スタッフを満足な待遇で雇用することも難しい。一方で、地震計は地震学の中で珍しい「ものを作る」という分野。

https://www.jstage.jst.go.jp/article/sicejl1962/16/9/16_9_714/_pdf

　1977年。地震観測技術に関する話。

　情報工学の専門家に地震計測の現状を話すと、必ずといっていいほどその情報量があまりにも多いことに驚く。さらに詳しく話すと、われわれが一生けん命集め保存してあるデータと、その収集方法にはたいへんなむだがあると指摘し始める。そこに地震学の現状が表されており、また自然科学の中での特殊性が見られる。

　とはいえ、「地震学者はほとんどの場合自分の研究のために必要十分なデータを手にしたことはない」とも書いてあるわけだが。

　短周期の地震のデータ量。50Hzまで見るために200Hzでサンプリング、1回の地震は10秒、3成分で、10箇所で観測して、1日10回、として、200*10*3*10*10=600kw/日。8bitで記録したとしても600KB/日、もう少しダイナミックレンジを広く取って16bitで記録すればその2倍。1週間で10MBあたりか。「こんな情報を交換することは不可能である」だそう。10MBなんて今の時代からすればスマホの写真2-4枚程度の容量だけど、半世紀前だもんなぁ。

　データの保存。「オンライン監視がなされていない場合、例えば無人観測点を置いたとき、われわれは欠測の恐怖に襲われることになる。目指す地震が発生し、その記録を回収に行ってみると、ちょうどその前から故障していたということによく出会う。やりなおしのきく屋内実験との差を最も痛切に感じるのである」 地震計のテレメータ化は研究者の精神的にはだいぶ良くなったんだろうなぁ。回線使用料を考えると予算取得の面で苦しそうではあるけど、。

　地震観測システムを設計するとき、多くのメーカの技術者と出会って感じたことは、どのような研究をどのような方向で進めようとしているのか、ということを理解してもらわない限り、良いシステムは完成しないということであった。細かい数字は具体的な問題にぶつかったとき改めて整理してみればよい。計測技術の発展の方向を理解した科学者と、その分野の研究の方向を感じとる技術者とが、出会うことが科学を一歩進めるために重要な意味を持っていると思う。

https://www.jstage.jst.go.jp/article/jscejseee/69/4/69_I_448/_pdf

　重力異常の調査を目的に、サーボ加速度計にデジタル制御を組み込んで、ダイナミックレンジを広げる提案。ダイナミックレンジが広ければ船舶や航空機に対して防振機構を経由せずに搭載できるから、観測が容易になる。

　レンジ200Galで分解能1uGalだから166dBくらい。地震計に比べると10-20dB広い程度? 新しい方式だし、今後もう少し広くなるんだろうけど。

　重力系の試験で観覧車を使うという話。高低差を容易に得られるから、とのこと。高低差がほしいだけならエレベーターに乗ればよくねって気もするけど、中層ビルだと重力変化が少なすぎて、超高層ビルだとエレベーターの加速度が高すぎる、みたいな話なのかな。

https://www.jstage.jst.go.jp/article/kokusaianzenhosho/41/2/41_116/_pdf/-char/ja

　2013年。CTBT(包括的核実験禁止条約)に関する説明とかいろいろ。どうやって核爆発を把握するか。

　CTBTが集めるデータは世界各地で得られたデータなので、地球規模の現象を把握するうえで効果的。本来想定していた用途以外にも使えるのではないか。例えば微気圧振動で火山噴火を把握することで航空機が噴煙に突っ込むことを防止できる。

　かつてはGPS衛星の使用すら軍事由来(米軍が構築したシステム)だからと嫌がってた民間航空機業界が、監視用とはいえ核兵器関連の技術まで使うとは、時代は変わるものだなぁ。まあ、「IMSデータの使用を認める」という書き方だから、彼らとしてはあくまでも自分たちが集めたデータに加えてCTBTデータも含める、みたいな扱いであって、軍事技術に依存しているわけではない、ということなのかもしれないけど。

「核実験が必ずしも頻繁に強行される現状にない今日において、CTBTの検証制度を高価な玩具にしないことも重要であり、近年IMSデータが多目的に活用され始めていることは理にかなったものである」

　註の13に、地震波形を周波数解析することで、核実験か否かの判定に利用できる、みたいな話が書いてある。ソースの論文は気象庁のものだけど、オンラインで読めるものではなさそう。

https://www.jma.go.jp/jma/kishou/books/kenshin/vol81_1.pdf

　2017年。地震計に記録されるいろいろな震源の種類。主に人口由来のものを文献から参照している。エネルギーとマグニチュードの関係とか。観測した振幅と距離からマグニチュードを推定してエネルギー変換効率を推定したり。

https://www.jstage.jst.go.jp/article/kaihatsukogaku1984/13/2/13_2_27/_pdf/-char/ja

　1994年。NHKの人が書いたもの?

　情報は大手メディアが選別したものを配信する一方通行の「垂直の流れ」から、送り手と受け手の区別のない、管理・選別されない情報が絨毯にこぼした水のように「水平の流れ」へと変わるだろう、というような話。その例として、1993年の核実験をNGOが探知した事例をあげて解説している。衛星画像を入手する方法や地震波形の解析とか。

　最後に情報の流れが変わったあとのメディアのあり方の話とか。

　30年前にこういう話がすでにあって、現在になってこういうグダグダになってるのか、というのでちょっとアレな感じもする。

　高速フーリエ変換のアルゴリズムを再発見した動機が核爆発の探知を目的とした地震波形の解析だそうだけど、日本語資料だといまいちこのあたりの話題が少ないのよなー。普通に地震計の資料とか読んで終わった感じ。日本語資料だと北朝鮮の核実験の話題が大半で、その他にCTBT関連の話題があって、解析とかの話はあまり見当たらないかな、という感じ。古い資料だと米ソの核実験のデータ解析とか中国の核実験の話題も出てくるけど、その当時はまだ日本の地震観測網もあまり発達していなかったっぽいし。

　地震計も地震計でダイナミックレンジめちゃくちゃ広いので計測システムとしても面白いし、地球物理学みたいな計測対象も面白いんだけどな。気圧変化によって重りの浮力が変わるから上下方向にノイズが出るとか、なかなかにすごいものを測っている(気圧変化のない気密容器に入れると差圧で歪んで水平方向に出てくる)。

　非理系大学の学生?が書いた論文で、核実験の直接的な検出を目的として、ニュートリノ検出器を使う話を見つけた。それらしいワードでググっても他に出てこないのであまり主流の話題では無いんだろうけど。

　原子炉をニュートリノで監視するみたいな研究は実験的に行われているようだけど、今のところは原子炉建屋のすぐ直近で炉のON/OFFの差が見える程度らしい(おそらく絶対値でON/OFFを見分けるところまでは行ってない)。原子炉(制御した臨界)と原爆(ほとんど暴走状態の臨界)では放出されるニュートリノの量も違うだろうけど、それにしても数十mとか数百mで差を見るのがギリギリとすると、1000kmとか離れた場所の核実験の検出は難しそうだ。検出器を大量に配置して同時にイベントが発生するのを探す、みたいな方法はありそうだけど。

　ただ、ニュートリノ検出器って、潰しが効かないのがちょっと大変そうよなぁ。原子炉監視用の検出器はトラックで運べる程度の規模とはいえ、核爆発検知用は一回り大きくする必要があるだろうし、それを世界中に数千台くらい設置したとして、核実験の検出にしか使えない。地震計とか微気圧変動は、普段の地震観測とか火山監視とか応用が効くけど、ニュートリノはそういうお題目が無い。天文へ応用しようにしても、数で感度を補えるとしても、角分解能が足りなさそう。

　カミオカンデみたいな大容量の検出器ならなにか見えそうな気もするけど、ググってもそういう話題は出てこない。少ない記述によると、帯域(エネルギーバンド)とか角分解能の問題らしい。

　ニュートリノ振動の説明だと1.5GeV以上と以下のグラフがあるから、このあたりが観測帯域の中央付近なのかな? 核分裂で発生するニュートリノがMeVあたりのはずだから、3桁くらい違うのか。それと、この図ではcosθを10分割してヒストグラムを取っているから、角分解能は20度程度しか無いらしい。1000km先で幅300kmの分解能だから、なにかイベントがあっても拘束がちょっと弱い。九州とか北海道あたりにもMeVレベルが見えるSKクラスの検出器を設置すれば北朝鮮の核実験をToFで絞れるかもしれないけど、いくらなんでもコスパが悪すぎる。

*

　地震計のデータ圧縮でフィボナッチ符号というのが書かれていたので、C#で実装して遊んでみた。

　0以上の自然数は隣接しないフィボナッチ数の和で表すことができるから、連続する1をデータの区切りとして使うことで、容易に復号できる(単純なビット演算で可変長ワードの区切りが見つかる)。符号化する際も比較的単純な演算で行える(先にフィボナッチ数テーブル(数百バイト程度)を用意しておけば、それと比較しながら減算とビット加算を行うだけ)。64bit処理系なら2^43.9(10^13.2)くらいまでを簡単に扱えるから、広ダイナミックレンジな信号を容易に圧縮できる。

　0以上の自然数しか符号化できないから、負数を扱うには工夫が必要になる。また、0を符号化するには余計に1,2bitが必要になるから、1以上の自然数に正規化するほうが有利なはず。正数しか扱わないなら1を足すとか、負数まで拡張したいなら、正数なら2倍して1を足す、負数なら-2倍する、みたいな感じで。

　符号化する数値の絶対値が大きいほど長いビット数が必要になる。何回か微分して書き出せば多少圧縮率を稼げる。綺麗な波形(Sincとか)であれば2回微分程度で比較的良い圧縮率が得られるけど、正規分布みたいなノイズを与えてやると急激に圧縮率が低下する。

　圧縮率はDeflateとほぼ同じ程度かな。Deflateが使えるなら、わざわざフィボナッチ符号を実装する理由はなさそう。ただしDeflateは過去のデータから一致位置を探したりハフマン木を作ったり、アルゴリズムが重いしメモリ空間もある程度広く必要な欠点がある。フィボナッチ符号は過去のデータ列が必要ないし、微分するにしても大して追加リソースは必要ないし、アルゴリズムも非常に軽い。

　観測対象が十分に精度良くモデル化できて(例えば2回微分すると単位時間あたりの絶対値の和が小さくなるとか)、かつSNRが十分に高い場合は、非常に低コストで圧縮できるフィボナッチ符号は良さそう。

　半世紀前の地震計だとデータ圧縮の動機はありそうだけど、昨今はどうなんだろうか。イザというときにDCPを使うことを考えると需要はあるのかな? とはいえたかだか数百バイト程度しか送れないなら50%まで圧縮できたところで地震波形を送るなんてことはできないだろうしなぁ。組み込みコンピュータの計算能力でゴリ押しして地震波のパラメータ(時刻や振幅)だけ送るような感じになってそうな気がするが。

　IoTみたいに計算リソースが少なくて帯域幅が狭いプローブに使うのにフィボナッチ符号は良さそうではある。まあ、8バイトのデータを6バイトに圧縮するくらいなら、生のまま飛ばすほうが楽だろうけど。

***

追伸

　私事ですが(というと仕事で書いてるみたいですが)、先日誕生日を迎えて30歳になりました(計算を間違っていなければ)。10進数では節目の年なのでなにか書こうかとか思ったりもしたんですが、ちょっと筆を執ってみると思ったより精神的にキツかったので、やめました。うーん、結構引きずってるなぁ……

　いくつかのSNSを転々としつつ、結局このブログが一番続いてます。昔のネットも(楽しかったけど)結構ギスギスしていて疲れたのに、最近のネットは本格的にPvPの殺し合いみたいな世界らしいしね。何事もなければしばらくはこのブログの週1更新は続ける予定です。書くネタなにも無いけど。

　最近何やったかなーと振り返ってみても、ここ10年くらいマジで何もやってないんだよなー。本格的にやばい気がする。とか思いつつ何もやらないあたり現状の因果関係がはっきりしていますが。