「万有引力定数Gの計測は実験ではなく乱数発生器だ」
【先パイと】MEX金沢2026の出展機をゆるっとごあんない！【後ハイが】 - YouTube
堅苦しすぎずテンポが良くて良いな。
豪州政府と次期汎用フリゲートの共同開発・生産に関する契約締結 | 三菱重工
個人的にはロービジロゴがステルスっぽさ(最新鋭の代名詞)があってカッコいいと思っているので、カンガルーもグレーのロービジになってほしいな。空自のF-35Aも元々は赤色だったのが実際にはロービジになっていたし、模型では目を引くワンポイントとして赤を使いつつ、実際に建造したらロービジに、みたいな可能性もあるけど。
後工程で高まる精度要求、半導体“積層化”支える2次元スケールで描く成長曲線：FAインタビュー - MONOist
マグネスケール社。
ソニーから買った会社で、元々はソニーの磁気記録・再生技術を計測に応用して開発した技術らしい。同様にレーザを使った計測も、ソニーの光学メディア由来だそう。
アイコムが模倣品対策を強化、製品の正規品判定をQRコード認証に一本化：製造マネジメントニュース - MONOist
QRコードで個体認証ってどんなすごいぎじゅつを使ったんだ?と思ったら、意外とアナクロだった。でも、こんなもんでもいいんだろうな。
南極観測船の運用、海自が撤収へ…警戒監視が必要なエリア増大で体制維持が難しく : 読売新聞
なんかどこかで見た世界線に似た話になってきたぞ……
JAMSTECに移管するというのは妥当だろうけど、とはいえJAMSTECだって現状でもカツカツ(or不十分)な運用体制だからなぁ。この上さらに地球の裏側に行くような大型船を運用する体力があるのかどうか。
後続艦の運用が行われたあかつきには現しらせを民間に払い下げて運用資金の足しに……
NTTとJAXA、低軌道衛星でのMIMO通信を実証 伝送量向上へ（Impress Watch） - Yahoo!ニュース
衛星MIMOってどんな仕組みなんだろうか。MIMOってマルチパスを積極的に使う手法だと思うんだけど、地対地通信なら(特に都市部なら)建物のマルチパスを使うとか、屋内(WiFiとか)なら壁やら家具やらのマルチパスを使うことができるけど、衛星の場合はどうなるんだろう。
https://journal.ntt.co.jp/wp-content/uploads/2022/09/nttjnl5004_20221001.pdf
衛星側でアンテナ間0.7m、地上側でアンテナ間70kmで、2x2MIMOで伝送レート2倍、とのこと。
地上から出すならこれもうビームフォーミングだろ、というような感じだけど、衛星から出してるから、MIMOという考え方でいいんだろう。IoTで主に地上から出した信号を衛星側で受信することを考えているなら、MIMOというよりビームフォーミングのほうが適切な気がするが。
革新的衛星技術実証4号機（小型実証衛星４号機）による低軌道衛星MIMO技術の軌道上実証実験を開始しました | JAXA | トピックス（2026年）
IoTのMIMOの使い方はあくまでも軌道上で収集したデータを下ろすのに使うのが目的かな? IoTはプロトコルが乱立しているから衛星では波形のサンプリングだけを行って、それを高帯域幅な回線で地上におろして、地上でソフトウェアで解析したい、ついてはMIMOで高速回線を構築したい、ということか。
LPWA的なプロトコルはキャリアスケルチと相性が悪いから、信号が入ったところだけ切って下ろす、みたいなことはできないはず。乱立したプロトコルがそれぞれに使っている帯域全体をカバーする必要があるし。MIMOで帯域幅を2倍にしたところで、足りるかな? 民生用FPGAをスクリーニングして軌道上でデコードするほうが楽そうな気がしないでもない。
IoTを衛星で中継してダウンリンクするってのはARGOSとかDCPと似たような用途になるのかな。ニッチな用途で欲しがる人はいるだろうけど、でも最近は既存のスマホとStarlinkやらを直結してテキストを投げたりとかのサービスが提供され始めているから、こういう用途にも5Gモジュールを積んで、人間の生活範囲では地上回線で、それが届かない場合は自動的に宇宙回線に切り替え、みたいな通信プランが出てくるのも時間の問題だろうし。
Iridium SBDみたいなモジュールがこの用途に広く普及しないのはコストの問題だろうけど、衛星通信がスマホレベルで普及しちゃえば、SBDとは桁違いに安くなるだろうし。IoT中継用の小型衛星を必要数バラまくコストを考えると、5Gの通信モジュールのほうが安くなりそう。
ダウンリンク用のMIMOはたしかに便利な技術なんだろうけど、とはいえ若干使いづらそうな気はするなぁ。数カ所の地上局を占有して数倍程度の改善しか得られないなら、観測衛星みたいな用途なら光中継みたいに桁違いに高速な回線を頑張ったほうが良さそうな気がするが。
ただまあ、MIMOは冗長系の考え方と相性がいい、という利点はあるか。衛星側はブロードなアンテナと送信機の組み合わせを複数個用意しておいて、地上側もサイトダイバーシチを兼ねた複数のアンテナを運用して、定常時はそれらでMIMO通信、地上で片方が悪天候とかトラブった場合はSISO通信、衛星側の送信機が1系統壊れてもSISO通信、ビーム幅で分離するわけではないから衛星側のアンテナの要求が少なくて済む(首振りも不要)、みたいな。
とはいえ、昔の衛星ならミッション回線もブロードだろうけど、最近の大型衛星なら首振り、小型衛星ならボディポインティングで細いビームを振り回すだろうから、MIMOに使えるかというと……
むしろそこまでリソースのない、50kg弱クラスの衛星からのダウンリンクを考えれば利点は大きいのかな? その程度の規模の衛星で複数の地上局を占有させるに足るミッションがあるかどうかはさておき。
使い捨てレベルで運用する超小型光学衛星とかを考えると、とにかく低コスト化したいから光通信はNG、ウインドウが狭いからMIMOで素早くダウンリンク、とかはできるか。20kgくらいの規模で、イプシロンとかで800kmくらいにばらまいておいて、いざ有事になった場合は固体モーターで近地点をガッツリ下げて解像度を稼いで、遠地点側のエネルギーを使って1週間くらい撮影して、みたいな。時間分解能が必要な場合は複数の衛星で交互に撮影していって。うーん…… 大型衛星でいいのでわ?って気が。こういうクリティカルな用途の衛星がブロードな電波をバラ撒けるかというと、怪しいし。低軌道から高解像度な画像を得るなら精密な姿勢制御は必須だから、ならその光学系を流用してレーザーを出すくらいできるだろうし。
まあ、素直な空間(非マルチパス環境)でのMIMO通信も、基礎データを取っておけば後から色々別の使い方(含衛星以外)をすることだってできるだろうしな。
最近のウェザーニュースの雨雲レーダー、かなり怪しい気がする。雨降っててあとどれくらいで止むだろと思ってレーダー見たら現在降ってない判定、とか。
あと、ウェザーニュースアプリの津波注意報は全く信用がない。内陸で発生した地震でも毎回必ず津波注意報を出してくるから、どうせまたいつものやつやろ、とオオカミ少年化している。そのうえで、NHK等はすぐに「津波の心配はありません」みたいな速報を出したあとも、ウェザーニュースは「津波に注意しろ」以降それの解除メッセージは出ないし。
津波の予測は莫大な実測値や計算リソースが必要だからいち民間企業でどうにかなるものでもないんだろうけど、だからといって何度も誤報を出すくらいなら、多少のレイテンシがあっても気象庁からの情報をリレーするほうがマシな気がする(彼らとしては「津波が来るぞ」と言っているわけではなくて「気をつけろ」としか言ってないから誤報とは思ってないんだろうけど)。
そもそもウェザーニュースの地震速報って何をソースにしているんだろう? 例えば気象庁から震源の座標を含むデータを受け取っているのであれば、それで一定程度は津波もフィルタリングできるはず(明らかに陸域に震源がある地震には警報を出さない、とか)。そういうことができていないということは、自営の地震計からデータを集めて、観測震度だけで(震源を決めずに)津波警報を出すか決めているんだろうか? とすると、おそらく地震計は陸地にしか設置していないだろうから、遠洋で発生した(陸地での観測震度が低い)地震由来の津波は警報が出せない可能性がありそう? 気象庁は海底の水圧計ネットワークから津波の発生を直接観測して警報を出せるけど、ウェザーニュースはそういうことはできない?
先日、レコーダの背面周りをいじる機会があって、その時に地上波のラインとBS/CSのラインが逆に刺さっていることに気がついた。レコーダの受信強度の表示だととりあえず問題ない程度ではあるけど、正しい接続に切り替えたら10目盛りくらい改善した(単位不明)。最近このあたりは触っていないから、だいぶ前からこの状態だったはず。それで問題なく視聴できていたのも結構謎い。
アンテナ類は屋外のプリアンプで地デジとBS/CSのIFを混合して1本にまとめてから窓枠の隙間を通して、レコーダの前でスプリッタで地デジとBS/CSに分離して、レコーダに突っ込んでいる。レコーダ側が地デジ・BS/CSを明確に分離しているのであれば、スプリッタの特性が悪いということになる。そりゃまあ、1000円未満で変えるRFコンポーネントの周波数特性がそんなに良いわけ無いだろうけど。
ガルパン最終章4話分を視聴。アニメは当時リアルタイムで見てたんだっけか? リアルタイムでは見てない気がする。劇場版はBDが出たらすぐ買って見たはず。最終章は1本あたりアニメ2本分くらいだから、4本なら8話分程度で、1クールよりは楽に見れる。
最終章は見てなかったんだけど、YouTubeで見かけた、エイブラムスに乗ってた兄ちゃんのリアクション動画(「俺はアニメは見ないんだけどお前らがそこまで言うなら」みたいなスタンスだったのにドハマリしていく様)が面白かったので、予習を兼ねて最終章を視聴した次第。
内容としてはまあそう唐突なわけでもなく、アニメとして誇張が強くなった感もありつつ、良くも悪くも過去作の延長線上という感じ。
黒森峰が平気で麦ジュース飲んでるのが面白いな。プラウダも瓶に入った透明な液体を飲んでいるし。
聖グロもコーヒーや麦ジュースを飲むキャラを出してほしいものだな。紅茶なんてミーハーな飲み物ではなく、伝統ある麦ジュースを……
***
日中はだいぶ暖かくなってきて、気安く外に10分くらい出ても寒くないので、GPSアンテナを持ち出してAirspy R2でサンプリング。とりあえずテキトーに書いたコードでドップラスキャン。……全然ピークでないでやんの。。。
コードが悪いんか?と思ってRTL-SDR blog v3ドングルでサンプリングして、サンプルレートとIQファイルの読み出しだけ変えてスキャンしたら、ちゃんとピークが出る。ということで、おそらくAirspy R2側の問題だと思う。
Linearity Gainを変えてサンプリングしてみると、狭い範囲ではピークが出ることがある。ゲインが低いと当然ピークは出ないし、ゲインが高すぎてもだめっぽい。R2のLinearty Gainというのは結局R860内の3種類のVGAを調整しているだけで、LPC4370側では一切信号処理は行っていないはずで、R860内のVGAに関してはRTL-SDRドングルと全く同じ使い方をしているはずだから、両者で結果に差があるのは釈然としない。
可能性としてはAirspy host toolsのDLLに入っているフィルタが悪さをしているというのは捨てきれないけど、これを検証するのは面倒くさい。ISDB-T(64QAM)を復調できることを考えると、帯域幅でせいぜい半分のBPSKを通す程度は問題ないと思うんだけどなぁ。
R860のゲインはそれぞれ15段階が3段なので、トータルで15^3=3375種類の組み合わせがある。仮に1つの設定あたり1秒間サンプリングしたとすると、それだけで132GBにも上る。GPSのドップラスキャンだけなら0.1秒もあれば十分だけど、それでも結構な量になるし、念のためのセトリング時間とかも考えると波形を取得するのに2時間近くかかる。それだけの組み合わせのファイルを解析する手間もある。
とりあえず、3段ステップで0から12までの計125セットを相関処理(PRN195、50msec)
相関強度は振幅100%の正弦波を0dBに正規化されているはずなので、ノイズフロアが前段の増幅率に影響を受ける(ただしR2はS16の100%よりはるかに低いレベルで飽和する)。
比較しづらいので、ピークを基準に正規化
利得が低いと全く相関が出ない組み合わせもあるし、弱い相関(4dB程度)のものもあれば、強い相関(8dB程度)を示すものもある。まあ、そういう組があるとわかるだけで、その組のゲイン設定がどういうものなのかはわからんが。。。
変数が3個と結果(相関値)で4次元の画像化が必要になる。凡人がそんなものをどうやって認識しろと…… 手間と工夫を惜しまなければ、2次元平面+アイコンの形で3次元を表現して、輝度なり色度なりで相関強度を表す、みたいなこともできるのかもしれないけど、メンドクセ。
とりあえずLNAとMixerの設定毎にグラフ化
一番左の列はLNAを固定してMixとVGAを可変したもの。それ以外の列はLNAとMixを固定してVGAを可変したもの。
VGAが0の場合はいずれの組み合わせも相関が出ない。VGAが12の場合、LNAが0でもMixが12なら5dB程度の相関は出る。逆に、Mixが0でもLNAが12なら8dB程度の相関が出る。
今回はゲインの最大値(各14)まで達していないので、最大ゲインにしても問題ないのか、あるいは飽和するのかまでは確認できていない。ただ、比較的早い段階でノイズフロアが下げ止まっているから、LNA, Mix, VGAすべて9くらいに固定しても良さそう。とはいえ、これがすべてのR860に当てはまるのか、それとも個体差があるのか、あるいはGPSアンテナにも依存するのか、といったところは把握できない。
あとは、ノイズフロアの原因が熱雑音なら、R860チップを積極的に冷却すればSNRが改善する、といった可能性もある。ケース(アルミ)の中にはかなり空間があるから、ペルチェ素子の2段スタックとかも入りそうだけど、とはいえそこまでやって劇的に改善するとも思えないしなぁ。満足な計測環境もなしにそんなこと試したってオカルト以上の結果は得られないだろうし。
それぞれのゲインを10-14の5段階に設定して相関処理(数時間離れて取り直したので別の衛星で、信号強度が変わってノイズフロアも変化)
ゲインを最大に設定したら飽和してSNR下がるかと思ったら、そんなこともなく。
前のゲインを下げてピークが出るようになったサンプルの理由がわからん。たまたまとか? あるいは、たしか今回とは別の個体のアンテナを使っていたはずなので、アンテナの種類によって違うとか? アンテナ側のLNAでめちゃくちゃ増幅するようなデザインだとR860側で増幅したら飽和する、とか?
縦軸に相関強度、横軸に時間
10Mspsで取っているので、ちゃんと綺麗な三角形になる(RTLの1.92Mspsとかだとほとんどインパルス信号に見える)。
QZSSも(ゲイン変えて取り直したサンプルから)
QZS1RのPNT(L1C/B)とSLAS(L1C/A)。C/Aは綺麗な形だし、C/AとC/Bのピークは同じ位置に出ているけど、でもC/Bってこんな形になるんだっけ? なんか違う気がする。
C/BってC/Aのチップレートを2倍にしてチップの前後で単に符号を変えただけだと思ってたけど、実は違うのかな。
***
Airspy R2でrawでサンプリングして、4象限サンプルをゼロ埋めして20Msps相当のWAVに書き出して、SDR#に読み込み
ゼロ埋めしているので、左右端の5MHzは折り返し。内側の-5MHzから+5MHzまでの10MHz幅が実際の信号。
サンプリングしたのはFMラジオの帯域なので、ノイズフロアはある程度平坦になるはずだが、高周波側が不自然に高くなっているのと、600kHzくらいは強烈にカットされている。
SDR受信機の特性の測定か…… IFを見る内だけにしても、少なくとも8MHz程度のフラットな信号源。fl2kで作れないこともなさそうな気はするが。周波数特性がDACのSinc特性ならそれを補償するフィルタを通してある程度フラットにするなり、そもそもそれが問題にならない程度に低い帯域を使うなり。
試しにfl2kを叩いてみた。そうだ、fl2kってデバイス解放で死ぬんだった。。。使い終わってるからエラーが出たところで、という考え方はあるにしても、気持ち悪いものは気持ち悪い。
Airspy host toolsのDLLはlibusb-1.0.dllとphtreadVC2.dllに依存している。fl2kのDLLはlibusb-1.0.dllとlibwinphtread-1.dllに依存している。どちらもlibusb-1.0.dllが必要だが、Airspyのv1.0.10に付属しているものはv1.0.20.11004で、fl2kに付属しているものは1.0.25.11692と、バージョンが異なる。fl2kは新しい機能に依存しているので、1.0.20では動かない。1.0.25を入れていても、airspyは動作する(必要な範囲で後方互換性がある)。ただ、1.0.25を使っていると、airspyでもデバイスを閉じるときにFatal Errorが出る。
試しにgithubからlibusbの最新版(1.0.29.11953)のバイナリを取ってきたところ、airspyもfl2kも、デバイスを閉じるときにFatal error. 0xC0000005が出る。古いバージョンでairspyを使えば問題なくて、新しいバージョンではfl2kもairspyもエラーが出るということは、これはfl2kではなくlibusb側の問題なのか。
同じく1.0.22を入れてみると、fl2kでデバイスを閉じるときにはwarningが出るが、とりあえずFatal errorは出なくなる(airspyも問題なし)。1.0.23では、airspyでは問題ないが、fl2kではFatal errorが出る。
とりあえずは1.0.22を使っておくのが良いかな?
しかし、1.0.23のリリースは2019年8月だから、かなり古い。fl2kやairspyの不具合の原因がlibusb側にあるならかなり長いこと放置されていることになる。流石に考えづらいような……???
***
QZSSのGNSS ViewのAndroid版、現在位置から見える衛星の配置を表示したい場合、fineの位置情報が必要らしいんだけど、なんでcoarseじゃだめなんだろう? coarseの場合は最大で数km程度の分散になるはずだから、GNSS衛星の方位を大雑把に把握する程度なら問題ないはずなんだけど。
別に内閣府が配布しているアプリを疑っているというわけじゃないけど、必要もないのに高い精度の位置情報を要求するのは昨今のトレンドからすると……
プロペラ一体型のアウターローター型モーターという空想。
コンセプト通り、プロペラの中に磁石が埋め込まれて射出成形されたもの。ドローンを組み立てるときにプロペラを小さなネジで固定しなくていいので楽。プッシャー型で使うならネジ等による保持すら不要(停止時は磁力で保持)。
プロペラの単価が高くなるので民生用で使うのは難しいのよな。軍事用を始めとした使い捨てドローンみたいな用途だと、ユーザーの手間が減って便利だと思うんだけど。使い捨てに振り切るなら、例えば軸受もベアリングではなくメタル軸受とかを使うことも考えられる。
今のところこの使い捨てのドローンでも概ね民生品の転用が多い感じで、トータルの製品設計としては過剰な部分もありそうな感じがする(ミサイルの構造を弾性範囲で設計する、みたいな)。かといって、あまり開発コストをかけすぎると低価格という利点が相殺されるから、あまり大規模な基礎研究はできないんだろうけど。このあたりがCOTSの難しいところよなぁ。多少のミスマッチがあっても大局的に見れば安くなるよね、という。でもあまりに大量に消費するなら専用設計したほうがやすくなる可能性もあるし、でもそれでコケたら一大事だし……
0 件のコメント:
コメントを投稿