Wolfspeed社が破産準備、半導体を急激にコモディティー化する中国の戦略 - 吉川明日論の半導体放談(339) | TECH+（テックプラス）
旧Cree系のパワエレ企業。
Cree自身はLEDから手を引いて社名も変えてパワエレ系に中力していたけど、CreeはCreeで別の会社にブランド名売って残ってるのよな。
アメリカ(というかトランプ)が一部の企業(大昔からある鉄鋼とか自動車みたいな企業)の保護に力を入れてR&Dみたいな方向の支援を絞る一方で、中国は様々な分野に幅広く補助金等を与えて、アメリカのEVみたいな企業は環境保護系の補助金の打ち切りで窮地に立たされるし、その間に様々な分野の中国企業は政府からの補助金で力をつけるし。どんどんアメリカと中国の差が縮まる(or開いている)感じがするな。
マスク氏、トランプ氏の弾劾求める スペースＸの宇宙船退役も宣言 - CNN.co.jp
別の投稿で同氏は「大統領が私との政府契約を打ち切ると表明したことを受け、スペースＸは宇宙船ドラゴンの退役を直ちに開始する」と述べた。
その後撤回したし、イーロンはそういう人間なんだろうけど、とはいえもうちょっと考えて話せよ、とは思うよなぁ。トランプからすればドラゴンがISS補給任務から離脱したらスターライナーにテコ入れするだけのような気もするけど。第一次大戦中から米国の軍事力を支え続けてきたボーイングだから、トランプも喜んで金を突っ込みそうだし。
燃料を使わずトラクターミリ波ビームでロケットに推進... | プレスリリース・研究成果 | 東北大学 -TOHOKU UNIVERSITY-
燃料を使わずトラクターミリ波ビームでロケットに推進力を与える実証実験に成功 ─ 地球と地球外惑星からのロケット打ち上げに期待 ─
どちらかといえばパルスジェットエンジンに近いイメージ。前方から吸気して、外部からミリ波でエネルギーを供給して、プラズマ化させて高圧を得て、その反作用で推力を得る。
従来方式(ノズル側から照射)ではノズル付近に残ったプラズマにエネルギーが加わるとそこで点火してしまい、燃焼室の中の最適な位置での点火を持続することができなかった。
新方式では吸気側から照射するから、照射ビーム内にプラズマが残留することがないため、繰り返し点火した際の特性が安定する。
原理的に大気圏内でしか使用できないから、エアブリージングロケット程度にしか使えないはず。あるいは、大気圏外でも使いたいならLN2みたいに適当な形で推進剤を持っていくか。化学エネルギーを自分で持っていく必要がない分でエアブリージングよりはマシだろうけど。
エネルギーは進行方向側から照射する必要があるが、人工衛星から照射することを想定しているらしい。宇宙太陽光発電システムみたいなものが必要になるから、実用化段階で打上げコストを多少下げられるとしても、最初の実証実験までのハードルがとても高そう。あるいは、先にSSPSの実用化を期待していて、それのビームを振り替えて実証しようみたいなことなのかもしれないけど。しかし、ロケット1機を純電力で軌道投入するようなエネルギーって、どれほどの規模のSSPSが必要になるんだろうか。普通の(地上へ送電する用の)SSPSとは全く別物になりそうだし(少なくともビーム径を3桁くらい絞らなきゃいけない)。いろいろハードル高そうだなぁ。
前方から電波を突っ込みたいだけなら、上部にリフレクタを積んでビームを90度曲げて側面(地上)から照射すればいいんじゃね?って気もする。リフレクタに適当な曲率を与えるか、あるいはISARAみたいに集光させれば、リフレクタ1枚で点火用の集光も兼ねられるし。というか、そもそも、噴流とビームが同軸なのが問題なんだから、ロケット側面から照射しても良さそうな気がするが。地上から照射するにしたってヤシマ作戦みたいな様相になりそうだけど、軌道上から照射するよりは遥かにマシなはず。
富良野 市内初のウイスキー蒸留所の建設計画 三者が協定締結｜NHK 北海道のニュース
富良野にはワインの醸造所があるけど、ウイスキーってことはワインの蒸留(ブランデー)ではなくて、別の酒(ビール)を蒸留するのか。元の酒はどこで作るんだろう。せっかく作ってるんだからワインも蒸留すりゃいいのに。
大樹のウイスキーとか余市のワインとか、最近は北海道で新しく酒関係の話題が多い感じがするな。
https://www.jstage.jst.go.jp/article/showabungaku/24/0/24_145/_pdf
1992年。陰陽寮の話とか。明治6年の改暦の頃の話もちょろっと。どちらかといえば近代史の方向なので、暦とかの方向の資料ではないけど。
List of objects dropped on New Year's Eve - Wikipedia
大晦日に落とされたものの一覧。いくつかの国で色々落としているけど、アメリカはダントツで多いな。その地域を象徴するアイテムを落としがちらしい。受験生に勉強の息抜きとして大晦日のイベントにつれていくのはNGか…… いや、少なくとも日本のイベントで物を落とすことはそう無いだろうから、それに関しては大丈夫だと思うけど。
USNOでは現在でも毎日正午にタイムボールを落としている、みたいな記事を見かけたんだけど、本当だろうか? YouTubeで探しても動画が一個も出てこないが。世界初のタイムボールはグリニッジ、と書いてある記事なので、話半分程度かなー。いちおうタイムズスクウェア公式のWebサイトっぽいんだけども。
USNO本部は敷地内にアメリカ合衆国副大統領の公邸があったりするので一般公開はされていないんだそうだ。ストリートビューで見てみても、本部屋上のタイムボールが見えるような隙間はなさそう(敷地内はストリートビュー無し)。近所にあるイギリス大使館の屋上からだと見えるかな? ギリギリ木が邪魔そうな気もする。
そもそも、なんでこんな場所にタイムボールがあるんだろう? こんな内陸まで海軍の船が入ってきてたんだろうか?
***
夜中に風呂から出て、暑いから窓を開けたらスズメバチが入ってきてびっくり。しばらく格闘してようやく駆除。せっかく風呂に入った後なのに汗びっしょり。
あいつらって明るいところに行きたいらしいのな。懐中電灯に突っ込んできたり、壁に貼ってあるコピー用紙めがけて頭くっついてるのに直進しようとしたり。昼間は窓開ければすぐ出ていくし。夜中に入ってきたときのためにLED入りの内側が白い段ボール箱とかを用意しておくべきか……
これまでも窓の外にスズメバチが飛んでいることはあったけど、部屋に入ってくることはほとんどなかった。今年みたいに何回も部屋に入ってきているのは異常。
スズメバチの羽音のスペクトル
思ったより録音音量低くてSNR悪い。500Hzと1kHzに小さいピークがあって、これが羽音だと思う。ただ、ググった感じだとスズメバチの羽ばたき周波数は150-200Hzくらいそうだから、もっと下にスペクトルがあるはず。
チャチャッと適当なプログラムを書いてフーリエ変換。無線で遊んでた経験が役に立ったな。AF用のスペクトル解析ソフトを探してダウンロードするほうが早い気がするけど
きれいな1/f波形。/* 人間相手の1/fってここ数年のトレンドだと思ってたんだけど、結構古いんだな。1997年の資料にも1/fのCDや扇風機が販売されているというのが書いてある */
44.1ksps、8192pts(青)と32768pts(橙)、Blackman、21回(青)と5回(橙)インコヒーレント積分。20kHz弱で綺麗にカットオフしてる。レコーダー側の仕様かな。
140Hzあたりに鋭いピークがある。2倍弱の236Hz付近にも鋭いピークがあるけど、ちょっと低い。その上は520Hzとか、937Hzとか。あんまり綺麗な高調波って感じには見えないなー。サンプル数が少ないし、SNRも悪いし。
別の日に入ってきたやつ。なんでそう頻繁に夜中に入ってくるんだよ……
前回はマイクのHPFが有効だったので、フラットな特性に切り替えたらだいぶ強く録音できた。
時間窓を短縮。積分回数が減る分でノイズは増えるけど、線幅はかなり狭くなる。適当なピーク、例えば1.31kHzを選んで、これが12倍とすると、109Hzが基本波になる。低周波部分のノイズ(PCのファンとか?)に埋もれているけど、小さいピークが見える。その上は2倍で218Hz、3倍で327Hz、というふうに、各ピークが109Hzの自然数倍で並んでいる。
150-200Hzと考えると、109Hzはだいぶ低い。夜行性のスズメバチにはモンスズメバチという種類がいて、こいつはスズメバチの中でも大型な種類らしい。大きくて周波数が低いと考えれば、110Hzあたりは妥当なのかな?
設定を変えてFFT
44.1ksps、4096pts、10回インコヒーレント積分(約1秒間)。ちょーっとSNR悪いかなーって感じ。積分期間を長くしようとすると線幅が広がったりするし、そもそも蜂が通過してしまう。かといって短い時間だとSNRが悪いし。アルゴリズムで蜂の羽音を検出するのはちょっと難しそうだなー。
2^16pts、1.48s
だいぶガタガタになるな。
10Hzから1kHzの範囲を、15倍波の範囲までインコヒーレント積分
110Hzの基本波付近は周辺ノイズが強すぎて埋もれている。2倍の220Hzには明確なピークが見える。3倍以降はピークは見えない。線幅が広がってエネルギーが分散しているんだと思う。
橙の点線は対数近似したもので、いい精度で一致する。線幅が十分に狭く(または弱く)、対数近似に与える影響が少ないと仮定すると、対数近似に対して一定以上の差(例えば3dB)があれば信号として検知する、みたいなアルゴリズムは作れそう。
今回取った波形では、ノイズや羽音は1/fで減少しているから、10倍波は10分の1しか寄与しない。積分してノイズ除去したい場合、あまり良くない。とはいえ、n倍波を単純にn倍して加算するとノイズも大幅に増える。n倍波の寄与をn^(1/2)とかn^(1/3)とかにすれば高調波の寄与を増やせるけど、グラフをぱっと見た感じではSNRが改善している感じはない。
時間方向に積分してから、周波数方向に積分
(16x4096)/44.1kspsで約1.5秒くらいの区間。周波数分解能が高いほうが明らかにピークが綺麗に出る。しかし、この波形だと200Hzあたりを直接見るほうが良くね?って気がするな。
そもそも、周波数方向に積分した波形と元の波形のピークの高さが同じだから、積分効果が全く出ていないんだよな。単にノイズを加算しているだけという感じ。うまいことモデル化すれば音声ベースで蜂検出できるのかもしれないけど、いい方法が思いつかない。
***
12 point nutみたいな形を簡単にデザインして3Dプリンタで出力
M12、二面幅17mm、くらいで、普通の六角ナットと同じ寸法。ただし高さを増やしてフランジを付けたり上に伸ばしたりしている。
この形は高張力が要求される場所で使うことが多いみたい。高さがある分で噛み合う部分が長くなるので、ネジ山が負けなくて済む。通常の六角ナットは6点で接触するが、12角ナットは12点で接触するから、高トルクで締め付けたときに角が負けずに済む。
P&Wの航空機用ジェットエンジンとかでセクションを結合するのに使うことが多そう。
F-35用のP&W F135エンジンのモックアップ。ケースのボルトは実物とほぼ同じ配置。めちゃくちゃ大量のボルトが並んでる。P&W以外にも、いろいろなメーカーで同様に採用している。
今回はスレッド部は普通のナットとしてデザインしたけど、本物はおそらく先端が楕円形にカシメてあるはず。それでボルトに食い込んでセルフロックナットとして使える。12角が上部まで無いのは、セルフロック用の変形を見込んだ分もあるのかも。
とりあえず、12角ナットで使用する工具の疑問は解けた。市販の普通の12角レンチやソケットが使える。それだけ。12角レンチ/ソケットは12角ナットと6角ナットの両方に使えるけど、6角レンチ/ソケットは12角ナットには使えない。
12角ナット、手で回すのにすごく手触りが良い形状。セルフロックナットだと最初の方しかねじ込めないけど、それでもhand-tightで締めるのに便利そう。
***
PRN36が320週目576996秒(Sat 16:16:36Z、6月1日)から出ていたっぽい。数フレームに1回(SF4/5のタイミング?)で不正なメッセージが放送されている。金曜17:48:36Zのサブフレームが最後かな?
正常なサブフレームは、ざっと見た感じは内容も正しそう。ただし当初はURAが大きくてSV HEALTHが全ビット1埋め。最後の方に受信したサブフレームは、SV HELATHこそ全ビット1埋めは変わらないけど、URAは6まで下がっていた。
不正なサブフレームは、ワード1とワード2は正しそう。少なくとも、正常と考えられる衛星と同じビット列が放送されている。ワード3からワード10までは全ビット(パリティ含)が1と0の繰り返し(0x2AAAAAAA)で埋められている。ただしワード10の最後の2bitは航法メッセージの構造上、ゼロクリアされている。
PRN36のエフェメリスから求めた適当な時刻の位置と、同じ時刻(18秒前)をTLEで計算すると、NAVSTAR 63 (USA 203)が4.1kmくらいの差になる。TLEの精度を考えれば非常に高い精度で位置が一致しているから、PRN36は34661U 2009-014A USA-203で間違いないはず。
WikipediaのList of GPS satellitesによると、この衛星はL5のデモ機として打上げられたが、信号品質が悪かったために正式に運用される前に退役して、予備として置いておきつつ時々運用している衛星らしい。
USCGのWebサイトで、NANU 2025017として、PRN35, 36, 37を使うと通知が出ている。35,37は今のところ見かけていない。
あと、PRN142のエラーフレームも復調してみたけど、MT2,3,4(高速補正)、25(長周期補正)、MT26(電離層補正)が出ていて、しかもCRC値が必ず同じ値になる。ランダムエラーの場合CRCはランダムな値になるはずだから、毎回同じCRC値が出るということは、意図的な不正メッセージだと思う。ただ、なんでそんな物を出しているのかが理解できない。
不正なメッセージ(SBASの仕様で定められたアルゴリズムから逸脱したメッセージ)を実験的に放送する手段として、CRCが固定値になるように改変したメッセージを放送して、通常の受信機ではCRCエラーで棄却、実験用の受信機では予め設定したCRCが得られたら実験用メッセージとして読み込み、みたいなことをやっている可能性は皆無ではないにしても、そんなことやるかなぁ。
あるいは受信側(復調処理)の問題かもしれないけど、142からも正常なメッセージが受信できているし、142以外のSBAS衛星(QZSS L1S含む)では全く問題なく受信できているから、少なくとも142固有の相性問題だと思う。でも、SBASメッセージに衛星固有のメッセージは無いからなぁ。
LNAVは航法メッセージにTOWがあるので、衛星時刻を直接時刻を観測できるけど、SBAS衛星にはそういうメッセージは無いので、LNAVから時刻情報をコピーして、SBAS衛星の時刻を観測。LNAV/SBASのエフェメリスから観測点との距離を求めて、グラフ化。
青がLNAV放送衛星、橙がSBAS放送衛星。
LNAV衛星にフィッティングした直線にSBAS衛星も乗っているので、正しく測定できていそう。
LNAVだけでも8機いるから、SBASを使う旨味っていまいちないのよな。あと、PRN142みたいに明らかに不正なSBAS衛星(エフェメリスが正しくない)もいるから、それを除外するアルゴリズムも必要だし(現状の142のエフェメリスだと、Z軸の位置と速度が0なら除外する程度で良さそうだけど)。
SBASを含めると13機まで増えるからDOPは多少下がるけど、静止衛星は天球上の一部に偏って分布しているから、大幅な改善にはならないかな。
***
C#のDateTime/DateTimeOffsetのParse、文字列の後ろにZが入っていると特殊な処理が走るけど(UTCとして取り扱って、DateTimeならローカル時刻のオフセットを加算、DateTimeOffsetならタイムゾーンゼロで保持)、ToStringのformatオプションにZを入れてもUTC処理が走らないのが地味に不便。フォーマットにZを指定したらUTCに換算して表示してくれたら便利だったのにな。C#の互換性のポリシー的に今更変えることもできないし。
C#、byte[]arrayに対してif(array is "hoge"u8)とかif(array is [0,1,2,3,.."hoge"u8])みたいな書き方できないのが不便なんだよなー。
VS CodeでJavaScript書いてて、三項演算子をネストすると1段ごとにインデントが1段増えるの、地味にキモいからやめてほしいんだよなー。
0 件のコメント:
コメントを投稿