小ネタ

 

　3Dプリンタをエポキシ花崗岩の型枠兼外装みたいに使うと考えれば、安価な3Dプリンタでも結構リジッドな機械を作ったりできそうだな。ある程度の大型の構造物でも複数のパーツに分割して印刷して、内側をマステで貼るみたいにエポキシが漏れてこない程度の密閉だけしてやればいいから、3Dプリンタより大きな構造も作れるし。ここまで来ると3D printedとは一体、みたいな話になるけど。/* エポキシグラナイト、粒径の違う砂粒で空間を埋めて最後の最後にレジンを詰め込んだりするあたり、固体燃料っぽさがある */

　ギ酸を水素のキャリアにして、微生物に反応させるプラントのコンセプト。ギ酸へ、またはギ酸から、双方向に処理できるそうだ。

　65℃、1.5bar程度で活性で、低温状態では長期保存できる。嫌気性なので環境へ流出しても直ちに死滅する。嫌気性微生物を使うので、システム内に酸素がほとんど不要で爆発の危険も無い。

　想定としては、電気分解で水から水素を作って、それを微生物でギ酸に変換して、それを抽出して輸送、輸送先でまた微生物で水素へ戻して、燃料電池で電気へ戻す。

　メーカーの主張としては「生物の進化ほどエネルギー効率の高い物はない」「人間ほどエネルギー効率に無関心な生物はいない」だそう。

　この微生物を採取したのは「アフリカのキブ湖」だそうで、そりゃ温水中で二酸化炭素とか炭化水素をうまく使うやつもいるやろなぁ、みたいな納得感が。

　スカパーJSATが静止軌道の宇宙ステーション「Yamato」構想を出展 - 第1回SPEXA | TECH+（テックプラス）

　スペースシャトルが飛ぶ前から似たようなコンセプトがある。LEOで組み立ててGEOへ運んで運用、必要に応じてLEOへ戻してモジュールを交換したりして運用。各国で5-30トンくらいの計画があって、30mくらいのアンテナでUHFを使って地上の移動体通信と直接通信する、みたいなものも。でかい方向だとJPLのSSPSで8x8kmくらいの計画もあったし。

　当時はスペースシャトルの運用開始で輸送コストが下がるから巨大な構造物を運ぼうぜみたいな構想があったけど、最近もスターシップ等で輸送コストが下がれば……みたいな計画が色々出てくる。

　アンテナ直径100mは結構でかいけど、とはいえETS-VIIIは19x17m(楕円)を2枚だから、差し渡しでは2倍程度の大きさなんだよな。面積でいうとだいぶでかくなるけど。DSNのでかいやつが70mだから、これより一回り大きい。電波望遠鏡みたいに振り回すわけじゃないし、重力や強風に抗う必要もないから、地上にある物ほど巨大なものを想像する必要はない。大きさでいうと国際宇宙ステーションとほぼ同じ面積(太陽電池間の隙間を全部埋めたと考えた場合)。

　墓場軌道でめっちゃぶつかるだろうから、アンテナは開くだけでなく閉じる機構も(数十年後に動作する品質保証で)作るのが面倒そう。まあ、墓場に持っていってから導爆線で切り刻むとか色々方法は考えられるにしても。あるいは、LEOに下ろして修理して使い回すという手もあるし、もしくは大面積のメッシュで墓場軌道を大掃除みたいな用途も考えられるけど。

　需要さえあれば直径100mクラスの静止軌道構造物は(初期費用がかなり高そうではあるけど)極端に困難な感じはあまりなさそう。静止軌道は非修理系であって、LEO(以前であれば例えばシャトルの修理ミッションが計画できた)に比べて要求信頼度が高い難点がある(70年代から80年代にかけて計画されていた大型静止軌道構造物はこれの対策として、LEOで組み立てて動作確認を行ったうえで静止軌道へ持ち上げる)。ただ、最近の月開発とか惑星間有人探査を考えると、それらの宇宙船を流用すれば静止軌道への有人ミッションが現実的になってくるから、有人施設を含めた静止軌道上の大型構造物は従来に比べて実現性が高くなってきている。

　多少無理をしてもASTRO-Gを開発して大型アンテナの軌道上特性を測っておけば商用衛星通信で使ったりもできたんだろうけど。ISASは科学観測がメインターゲットだから、商業展開につながる技術開発を行う方向性はなかったんだろうな。NASDA側から提案して通信衛星用の大型アンテナの宇宙実証兼VLBI観測にも流用みたいな方向性で立ち上げていれば、多少の予算超過を許容してでも技術開発を行うみたいな方向性はあったかもしれないけど(LDRはNASDAで開発したものなわけだし)。とはいえ、スペースVLBIで使うにはある程度の軌道傾斜角がほしいし、通信衛星(静止軌道)でVLBI観測は難しそうだな。極端に東西基線だけ伸ばしても。GTOでアンテナ展開とか一通りやってVLBI観測も、みたいな方向性がない訳では無いにしても、GTOはペリジが低いからあんまり長期間は置いておけないし、NASDAが主導するなら先に通信衛星として評価してから、残りの寿命はISASに貸し出すみたいなスケジュールになるだろうし。

　15年前から比べれば解析技術とかも色々発達してるし、直径で10倍、運用期間で5倍だと展開したらあとはそのまま形状維持ではなく、アクチュエータでアクティブに形状制御は行うだろうし、ちゃんと予算かけて開発すれば作れるんじゃないかな(商業的に採算が合う範囲に収まるかは別として)。

　ラノベとかで時々出てくる、テック系のキャラが使っている「違法改造されたデバイス」(e.g. スマホ、ノートPC)、具体的にどのあたりが違法なんだろうか。電子機器に適用される法規制はいくつかあるけど、大半は製品として販売するときに適用される法律な気がする。エンドユーザーレベルで改造(or修理等)で抵触する法律ってどんな物があるんだろうか。

　一番わかりやすそうなところだと、電波法で規制されている部分を違法に改造して通信の信頼性を向上させるとかは考えられるか。ただ、PCやスマホに内蔵されている通信モジュールを改造するとなると、あんまり改造の方向性って広くなさそうな気がするんだよなぁ。例えば通信機器の送信出力を上げたところで、基地局から送られてくる信号の出力は変わらない(むしろ信号レベルが高いと物理距離が近いと判定されて送信出力が下げられる可能性すらある)わけで、通信距離の改善にはあまり役に立たないはず。基地局側(に類する設備)まで含めて触れるならともかく。

　コンビニの冷凍食品を加熱するだけの簡単な作業すらまともにできなくて自己嫌悪に陥るので冷凍食品は健康に良くない(おい

　ぶっ、ぶつりほうそくがわるいだけだから！誘電率なんて物があるせいで……ッ!! 吸収率がポジティブフィードバックなのマジで迷惑だよなー。ネガティブフィードバックならどれだけ食文化が豊かになることか。

　SSPA型の電子レンジが出てきたところで、食材や温度や相によるエネルギー吸収率の差はどうにもならないので、当面は改善の余地は多くはなさそう。ただ、精密にビームステアリングできる製品が出てくれば、反射率からその焦点の吸収率が見えるから、吸収率の高い場所を避けて照射するみたいな、能動的な吸収率のキャンセルはできる。精密に制御するとなると24GHz帯あたりを使いたくなるはずなので、高周波・大電力の精密制御が必要になるから製品として成立させる難易度は高そうだけど。あと、周波数が高くなると吸収率も高くなるので、食品中に浸透しなくなるんだよな。かといって解凍用の24GHzと加熱用の2.4GHzのデュアルバンドに対応させる、みたいなことはコスト面でも難しいだろうし。

　30℃位で切れる導電性のフィラメントがあれば、それを食品に添加すれば、低温では電磁波を良く吸収し、十分に加熱されたら電波の吸収率が下がる、みたいな感じに使えるんだろうけど、しかし食品に添加できるような材料というのがネック。ストロー状の可食フィルムに氷点の低い液体を入れて食品中に分散させておいて、冷凍状態では内部の液体で電波の吸収率が高く、加熱したらストローが弾けて吸収率が急減して、みたいなものは作れそうかな。

　コンビニのプラのスプーン、口から引き抜くときに歯に当たると表面のわずかな凹凸が感じられる。横手方向に接触させてもわからないから、横向きの凹凸があるんだろうな。金型を切削するときに横方向に往復させて表面を作ってるのかな。長手方向に走らせて仕上げれば歯に当たったときの感触が良くなりそうだが。

***

　あまりにも暇すぎて、本棚の奥底に放置されていた安物の非接触温度計を修理。10年以上前に買ったやつだけど、わりと短期間で起動しなくなったやつ。当時の症状からしてタクタイルスイッチの劣化だろうなと予想はしていたんだけど、使うこともあまりないし、延々放置してたやつ。

　爪だらけで分解が面倒、樹脂の劣化で爪がバキバキ。スルーホールなのでスイッチを外すのが面倒なので、足を切って1本ずつ除去。手持ちのスイッチは高さが高かったので、トリガのパーツを切断して対応。

　電池が006Pで、手持ちに無かった(昔まとめ買いして残ってたやつはほとんど液漏れで死んでた)ので、安定化電源で動作確認。トリガーを引けばちゃんと反応するので、修理は完了。

　計測モジュールの近くにあるSOP8は1Kbのメモリ。コンフィグ保存用かな?

　電源の入力にシリーズでダイオードが入っている。006Pは固定はできないにしても逆接は容易な端子形状だから、こういう対策が必要になるんだろうな。

　液晶の裏にCOBが乗ってて、これが全体の制御かな。温度計モジュールを固定するネジの無理矢理感よ。。。モジュール側は斜めに切り欠いてるんだから、切り欠きに合わせてネジ穴つけておけばいいものを。斜め穴はダイカストだと面倒なのかな?

　世の中のタクタイルスイッチの寿命短すぎ問題、どうにかならんのかなー。

***

　SDRクライアントソフトのやつ。

　終了時に設定をJSONで保存、起動時に読み込み、ドラッグアンドドロップでも読み込み、という感じの機能を追加。必要な項目だけ(e.g. 周波数)JSONで書いておけば、その項目だけ読み込む。周波数は2重の配列になっていて、外側の要素が複数個あればダイアログで選択できる。例えば日本のISDB-Tに合わせて40個のリスト(その中に3個の周波数のリスト)を作っておいて、そのファイルをドラッグアンドドロップすれば、特定のチャンネルを受信できる。サンプリングレートもJSONから指定できるけど、このソフトは接続時にしかサンプリングレートを読まないので、サンプリングレートの変更を含むファイルは再接続する必要がある。

　データレートの表示を追加。300kspsや1024kspsではその2倍のデータレートが表示されているけど、3.2Mspsは少し低めに出ている。

　3.2Msps、3.0Msps、2.8Msps。ヒストグラムが変な形。

　3.0Mspsは明らかにデータレートが低い。記録したIQファイルをSDR#で復調すると、3.2Mspsと2.8Mspsは正常に聞こえる一方で、3.0Mspsは明らかに再生速度が早い。ただ、ブツブツ途切れるわけじゃなく、単に再生速度が少し早い程度。rtl_tcp.exeのログを見ると3.0Mspsでも3000000.178814spsに設定されているのだが。

　librtlsdrのサンプリングレートの設定は単純に一定の範囲(225k-300ksps、900k-3.2Msps)に入っていればOK、それ以外はinvalid sample rateエラーになるだけだから、正常には動作しない設定でも一見動いているように見えるのかも。

*

　1090MHzの受信。とりあえず3分程度受信して、振幅復調して0.1秒毎の最大値をグラフ化。

　2.0Mspsと2.56Mspsは感度に若干の差はあれど大きく違うわけではない。3.2Mspsは明らかに振幅が低い。傾向としてはサンプリングレートにかかわらず同じようなデータが得られている。

　時間分解能を0.1msでグラフ化

　最初のパルスの位置を合わせているけど、だんだん時間がずれる。3.2Mspsを0.991倍くらいにすると位置が合うので、実際のサンプリングレートは3.171Mspsあたりかな?

　rtl_tcpで設定したサンプリングレート(exact sample rate)と実際のサンプリングレートがずれるの、どう解決するのがいいんだろう。十分に信頼できる信号源があるならそれをサンプリングして位相を追っていけばサンプリングレートも決定できるだろうけど、その信号源をどこで確保するか。

*

　モニタ機能を追加中

　……またこいつISDB-Tで遊んでるよ。。。

　上の三角形の波形がガードインターバルの相関値、下がOFDMのコンスタレーション(SPで等価後)。

　ヒストグラムの白い菱形のマーカーが信号の飽和レベルを示している。マーカーが一番下に落ちていれば飽和していないが、マーカーが上がってくると飽和したサンプルが含まれていることを示している。

　OFDMって少しでも飽和すると急にEVMが悪化するんだな。ここまで敏感だとは思わなかった。ほぼリアルタイム(1Hz)に見れるので、いままでのIQファイルの復調では気が付かなかったことが見える。もっとも、処理速度が遅いのでフルセグ全体(3x 2Msps)のリアルタイム監視はできないけども。

　ガードインターバルの相関値のピークが移動しないように調整すれば1ppm以内には追い込める。ただ、ガードインターバルの相関は計算コストがかなり高い。通常の受信時にはガードインターバルの相関処理は不要だから、専用の計算リソースを割かないといけない分で効率が悪い。

　パイロット信号(SP)を使えばOFDMシンボルを追跡できるので、適当にフィードバックしてやれば28.8MHzを送信所のルビジウムに同期できるはず。ただ、いまのところ1フレームをまとめて処理しているから、0.2秒単位(帯域幅2.5Hz)程度でしか処理できない。まあ、一旦フレームに同期すれば以降は1シンボル単位(帯域幅1kHz)で処理できるわけだが。

　ただ、そこまでして精度を稼ぐ意味があるかというとな。サンプリングレートが最大でも2Msps程度(ISDB-Tを受信する場合)だから、サンプリングレートの精度は0.5ppm程度にしかできない。そもそもクロックの補正も1ppm分解能だし。

*

　比較演算子の連結(if (0 <= hoge < 10)みたいな文法)、Pythonとかで使えるらしいけど、なんでこんなに普及率低いんだろう? 他の言語だとif (0<= hoge && hoge < 10)みたいに書かなきゃいけないから、かなり冗長。比較演算子の連結はあった方が絶対便利だと思うんだけど。

　C#のMath.Signに類する機能、引数がゼロ以外の場合の戻り値が固定されていないのが気持ち悪い。var tmp = float.Abs(hoge) * float.Sign(fuga);みたいな処理が実装依存になる。C#って実装依存とかをできるだけ減らそうみたいな設計思想のはずなんだけど、なんでこういう変な仕様が入ってるんだろう?

　途中で不注意で100KBくらいのファイルを秒50個くらい同名で上書きするような処理を走らせてしまって、OSレベルで動作が遅くなってめっちゃ焦った。AFOPで遊んでたときに遭遇したOSハングアップと似たような挙動な気がする。

　このPC、CドライブがNVMeのRAID1(チップセット処理)なので、細かな書き込みが大量に発生するとディスクアクセスにかなり大きなペナルティが発生するような傾向がありそう。

　また別件で、Visual Studioのエディタの中に巨大なテーブルを貼り付けて、めちゃくちゃメモリ食われた。

　64GBも乗せておいて99%まで食われるなんてな。仮想メモリに退避されるのでディスクアクセスが大量に発生して、ものすごい動作が遅くなる。

　RAM、4スロットの内2スロットしか使っていないので、128GBまで増設はできる。さすがにそんなに使わんやろ……と思って64GBしか積んでないけど。DDR4だし、メモリキットが市場にあるうちに買っておいたほうがいいかな。生産中止になったりして在庫がなくなると4本丸ごと買わなきゃいけなくなる。今なら2本買うだけで済む。欲しいものリストがどんどん積み重なっていく。