がぶっくでカバーしてほしいなぁ。
KDDI山口衛星通信所がクレジットされてる。データセンターのシーン、ラックに入ってるユニットがだいぶ本物っぽい雰囲気だけど、これも山口通信所で撮ったんだろうか?
Amazon.co.jp: レッド・ワンを観る | Prime Video
しっかりバカバカしいし、しっかり面白かった。
超高精度で1秒を刻む「光格子時計」を小型化、東大など 「秒」の再定義へ | TECH+（テックプラス）
気軽に持ち運べるような大きさではないけど、だいぶ小さくなったな。商用のセシウムとかルビジウムに比べるとまだ大きいけど、周波数標準用セシウムや商用の水素メーザーよりはだいぶ小さい感じ。光学定盤の上に置いてあるけど、一番下のプレートには取っ手がついているから、2人で持ち上げられる程度の規模感なんだろう。長期間安定して使えるようになればメーザーとかから置き換えが進むのかな。
商用の水素メーザーはMicrochipがかなりのシェアを取っているらしいけど、光格子時計がUTCとかVLBIに使われるようになったら日本メーカーの製品が普及するんだろうか? それとも結局は海外の製品がシェアを握るんだろうか。海外でも光時計は色々と研究されているらしいし、海外製の製品も出てくるだろうし。
Microchip、原子時計を各種(Cs, Rb, HM)取り揃えているのが謎い。なんでその社名でラックマウントの原子時計とかを扱ってるんだ。MHM-2020とかなんてラックマウントできる規模ですらないし。CSACとかはちゃんとした原子時計のノウハウを持っているからこそ作れる製品なんだろうけど、原子時計の部門はどういう由来でMicrochipにあるんだろう?
原子泉型周波数標準、原子の運動の様子が泉のようだからその名前になった、みたいな説明がよくあるけど、いまいちイメージできない。泉って凪いだ水面みたいな印象がある。意味合い的には地面から湧き出た水(湧水)であって、その上の水が溜まった場所ではないから、語源的には泉でいいんだろうけど、感覚的にはちょっと違う気がする。
英語ではatomi fountainといって、これはチョコレートファウンテンのfountainだから、わりあいイメージ通りの名前な気がする。とはいえ、atomic fountainを直訳して原子噴水型みたいに書いたとて、じゃあ水ってなんだよ、という話になるだろうし。結局は原子泉型が一番しっくり来るのかな。
旭酒造、宇宙で獺祭を造る。三菱重工など協力、2025年後半打上げへ | TECH+（テックプラス）
「天使の取り分(宇宙飛行士の試飲)」
熟成じゃなくて醸造を宇宙で行うらしい。ISSの0G環境ではなく、1/6g環境で行うんだそうだ。将来的には月面で酒を作ることを想定しているとのこと。米は水分量が少ないのでぶどうみたいなものに比べれば輸送コストが低く済む。地球から米を運んで、月で採取した水で酒を作る。高揮発性で燃焼性で酩酊症状のある酒を月で飲めるかどうかはさておき。
Can You Make Alcohol in Space? | WIRED
宇宙で酒を作る事に関する記事。
結論(DeepL翻訳)「(前略)アルコールの製造過程で最も危険なのは、飲み過ぎたときに起こることだろう。 言い換えれば、まさに地球上の状況そのものなのだ」
月面とか火星表面で作れる原料はせいぜい量はしれてるだろうから、製造量もそれで制限されるし、地球みたいに1年サイクルで作るわけじゃなくて、1週間とか1ヶ月とか位相をずらして1年中栽培と醸造と蒸留とを繰り返すような感じで、そこをボトルネックにすればアルコールの供給量(摂取量)はある程度リミットできそう。あとは入植者が勝手に作付面積や醸造設備を増やさないようにしてやれば、過度な飲酒は防げそうだ。作付面積と醸造設備を厳しく制限する地球側と、それに対して違法な醸造を行う月or火星入植者たちの戦い。1本SF書けそう(小並感
無重力で醸造・蒸留するのは結構難しいらしい。醸造では、酵母菌レベルではおそらく無重力でも問題ないだろうが、培地を維持するのが難しい。蒸留も現在大量生産で使用している方式は重力を使ってアルコール蒸気を分離するから、別の方式を考える必要がある。
無重力環境(嘔吐彗星)で酒の匂いが嘔吐反応を引き起こしたといって、それが無重力環境での酒に由来するのか、そもそも嘔吐反応のしきい値ギリギリまで来ていたのか、判断が難しそう。適当な理由付けに使われただけのような気もする。例えば宇宙で1週間くらい体を慣らしてからなら酒の匂いは問題ないかもしれない。あるいは、それでも駄目かも知れないが。実際のところ、宇宙に酒を密輸していたやつもいたらしいし(まあ、ロシア人が律儀に禁酒を守るとは思えないし)、宇宙で酒を飲んだところで適量なら大して問題にならないんだろう。(表向きのところ、現在のISSで酒類が禁止されている理由は環境維持システムの機能がアルコールで問題が起こる可能性があるから、という理由であって、人間の問題ではないらしい。人間のせいにすると「自分は酒に強いから大丈夫だ」とかゴネるやつが出てくるからかもしれないけど)
酒の場合、密造が比較的簡単なのが規制側からするとネックよね。微量の酵母が持ち込まれるだけで、通常の食品から酒を造れる可能性が出てくる。月や火星で都市を作ったときにそれを規制しようとすると、環境維持システムでアルコールを検知してアラートを出す、みたいな消極的な対応しかできない。適当な機材(環境維持システムの予備機材とか)で独立した陰圧室を用意されたら検知できない。武器や薬物は、作るのが絶対に不可能とまでは言えずとも、それなりに大変そうだし、実用的なものを安定的に供給しようとするとある程度のロジスティクスが必要だろうから、規制はしやすそう。/* 『アルテミス』では蒸留酒を提供するために、煮詰めた蒸留酒(アルコール分を飛ばした液体?)を輸送し、別ルートで密輸した無水エタノールと混ぜて試作していたから、あの世界では酒の密造は行われていないんだろう */
キリンの飲料倉庫で動き出す、三菱重工の自動ピッキングシステムを見てきた | TECH+（テックプラス）
黄色いロボット、FANUCのやつだと思うけど、茶色の斑点というか、白の網目模様みたいなのがないのが残念。
なんでもセンサー(万能表示器)キット - Nandemo-LCD - Strawberry
何でもという割に対応センサは結構少ない。エアクオリティセンサみたいな面白いやつ&動作確認が面倒なやつこそ対応してほしい。加速度や角速度や地磁気の3軸表示は液晶の表示領域が狭くて難しいとしても、特定の軸だけ表示してみるとか、絶対値を表示するとか、そういう機能はあっても良さそうな気がする。あとはToFも非対応。ストリナはToFのラインナップが豊富なだけに、ToF非対応はちょっと不思議(最近のSTのToFはマイコン側にある程度大きなROMが必要だから、小さいチップじゃ対応できないってことで全部非対応にしているのかな)。
難易度の高いミリ波設計を容易に 超小型アンテナモジュール：MWE 2024でADIがデモ展示（1/2 ページ） - EE Times Japan
5Gのビームフォーミング、LEO/HAPS向けの地上局、月面GNSSの受信機、等。
LNSSのモジュールの名前が「LNSS TRANSCEIVER PM」になっている。レシーバーじゃなくてトランシーバーってことは送信機能もついてるのかな。受信したIQ信号をリアルタイムにKuとかに載せ替えてダウンリンクするみたいな機能が載ってたりするんだろうか? あるいはシュードライト的に広帯域RF電波源として使って、月軌道上や地上で受信する試験とかもできるようになっているんだろうか。
GPSの周波数方向のスキャン
FFTで入力とレプリカ(1code)をラグを変えて畳み込んで、相関値のピーク値(青色)と、コヒーレント積分したときの強度(橙色)、それと、コヒーレントに目視でフィッティングさせたsinc関数の絶対値。
メインローブの横に少し膨らんでいる場所があるけど、1個目のサイドローブが見えているのかな?
コヒーレント積分のメインローブはほとんどSincに近い綺麗なカーブ。Magnのピーク値はノイズの影響で綺麗な形にはならない。コヒーレント積分するとノイズの分で損をするので、スケールを合わせるとMagnのピーク値よりかなり低い値になる(√2くらい小さいのでスケーリングをミスっている可能性もあるけど)。ピークとノイズフロアの比でいうとコヒーレント積分したほうが有利。ピークの中心位置もおそらく正しい位置に近いし。理想的にはSincにフィッティングして中心位置を推定するほうがいいのかもしれないけど、結構面倒そうな気がする。コヒーレント積分の最大値をそのまま使うほうが楽。±500kHz位の場所で2箇所の強度比が1:1になる場所を中心にしてもいいかもしれないけど。どちらにしてもSNRが悪くなってSincの頭しか出なくなると正しく推定できなくなるから、結局はピーク位置を探すほうが良さそう。
今回は約100Hzステップ(正確には99.993Hz程度)でラグをインクリメントしている。ヌル点が±1kHzの場所にあるので、500Hz位の範囲であれば1/2の強度が得られる。ただし後続のもう少し精密なドップラ推定に250Hzで折り返す曖昧さがあるから、少なくとも100Hzくらいの間隔でスキャンしたほうがいい(2.4Mspsとして100Hz分解能は2^14.55pts、2^15ptsなら73.2Hz分解能)。
最初に2^15pts(約13.7ms)でキャリアのドップラを大雑把に推定して、その後で2^20pts(約437ms)でキャリアとコードのドップラ・位相を推定すれば、十分な強度の信号ならそれなりに良い精度で推定できる。あらかじめ十分な精度で推定できればその後のPLLで引き込む範囲が狭くて済むから、パラメータの設定が楽な気がする。±10kHzをスキャンするのに500ms弱、周波数・位相を推定するのに300ms弱、くらい。ちょっと時間がかかるけど、まあ、妥協できる程度だろう。最適化すればもう少し早くなってくれるかな、という願望もある。あと、Releaseビルドにすれば数割は早くなるはず(願望)。FFTライブラリの挙動として最初のパスはLUTの生成のために結構時間がかかるのがデバッグ時には不便。キャリア・コードの周波数・位相推定は処理内容的には通常の受信処理とほとんど同じだけど、これが2倍未満程度しか出ないとなると、複数機分のリアルタイム受信はちょっと厳しそうな見込みだが。どこまで最適化できるか。
キャリア・コードの位相ロックはある程度動くようになってきたので、とりあえず航法メッセージの取り出しを実装したいな、といったところ。前回はキャリアはFLL的な動作だったけど、今回はPLL的な動作で、搬送波に位相ロックできているはず。できれば干渉計としても使ってみたいなーとか考えつつ。一応、Bias-Teeを出せるドングルは3本持ってるし、LNA内蔵L1アンテナも2個持ってるから、干渉用のサンプルは取れるはず。1周波だと整数値バイアスの除去が面倒そうだけど、長基線長で使うわけじゃないから、アンテナの距離を1m程度に制限してブルートフォースで処理するとか、あるいはアンテナを2個並べた状態で整数値バイアスがゼロの状態で開始するとか、そんな感じでどうにかなるはず。まあ、まずは単独測位をできるようにしないとな。。。
GPSの復調はいろいろな段階が密結合になっていて段階的に進めるのが結構面倒くさい気がする。ISDB-Tだと基本的にはデータは上流から下流に向けて流しっぱなしでいいので、各段を分離しやすかったはず。GPSはビットレートがアホみたいに低い(50bps)のに、それ以上に信号強度が低いので復調がだいぶ面倒。
0 件のコメント:
コメントを投稿