2025年11月5日水曜日

小ネタ





 Pocket Mill|小スペース用CNCミル|垂直ミル‐Haas CNC機械

 40テーパー、単相電源で使用できて、ベースモデルは25kUSDから、必要に応じてオプションでATCや5軸も対応。

 ベースモデルでSYIL X5と比べれば確かにPocket Millのほうが安いけど、とはいえ向こうはATC標準搭載だからなぁ。色々オプションを積むと40-50kUSDくらいは行きそうだし。とはいえ、ベースモデルを25kUSDで買ってガレージに置いて、物足りなくなったら後からオプションを追加して、それでも足りないなら、Pocket Millを中古で売って大型の機械(VFとか)に買い替えた場合でも、ツールホルダを含めた工具や操作感が共有できるのは、小さいショップから始めて拡張していけるという点では面白そうではある。Haasの小型な機械は30テーパー(CompactMillは20テーパー)の製品もあるから、低価格化をアピールするなら30テーパーとかで作ってもいいはずなのに、そうしなかったということは大型機への移行も考えてそうだな。

 DesktopMillが10kUSDだからPocketMillと性能差の割に値段差がほとんどないけど、DesktopMillの方は教育機関みたいなところでいくつも並べるような使い方を想定しているだろうしな。




 猫背のエンジニア。

 蜘蛛型のロボットを投げて、敵を発見したらネットランチャーで拘束する、ってのは面白いけど、しかしなぜ6本足なのだ…… 蜘蛛というからには8本足でないと。構造が複雑になれば故障率も上がるけど、とはいえ6本足→8本足なら冗長系が増える分で利益が大きそうだが。消費電力とかコストはともかくとして。

 エンジニアだし正面から撃ち合ったら打たれ弱い感じかな。そのわりにサポートとしても中途半端な気がする。あまりガジェットを有能にすると偵察と競合するんだろうけど。『ナショナル・トレジャー』のハッカーみたいな雰囲気だけど、彼ほど有能でもなさそうな感じ。DFの世界観じゃハッキングして使えるアセットもあんまりなさそうだしなぁ。偵察衛星とかSAMとか色々ありそうだけど、ゲームバランス的にねぇ。



 大口径光学アンテナ合成開口実証(OSCAR-J)プロジェクト|JAXA|研究開発部門

 JAXA、MELCO、NAOJで分担して、副鏡および主鏡2枚(全6枚中)の1/1スケールを作成し、検証。

 これ、合成開口かぁ? 強いて言えば開口合成、一般的には普通の分割鏡望遠鏡では?

 これから高性能かつ大規模な地球観測(Opt/SAR)コンステレーションが構築されるであろうことを考えると、この手の観測衛星の必要性は提案当時から比べるとかなり小さくなっているけど、とはいえ他の目的に転用できるのが強みよなぁ。外に向ければ大口径の天体観測衛星として使えるし、地球以外の惑星(コンステが構築されていない場所)で使うことも考えられるし。とはいえ天体観測衛星で使うのはともかくとして、地球以外の惑星で何に使うんだよ、という話ではあるけど。

 姿勢の自由度を増やしておいて、例によって2,3機を日本付近の静止軌道に入れておいて、平時は最低1機を地上観測用に、予備機は外に向けて天文観測に使って、地上で大きなイベントがあれば全部地上に振り向けて、宇宙で大きなイベントがあれば可能な限りそちらに振り向けて、みたいな運用をやっても面白そうよな。回線設計をうまくやれば、常時高速通信で接続して、地上の状況だけでなく、天文現象もリアルタイムの動画を降ろして、珍しい天文現象が起きたらYouTubeで配信したりも考えられる。重力波望遠鏡で見つけた超新星爆発の映像をリアルタイムにYouTubeで配信する、とか。あくまでも地球観測衛星がベースだから精密な天体観測に使えるものではないだろうけど、とはいえひまわりで金星の気象を長期的に把握したりとかもしてるしな。十分に低コスト&気軽に使える光学系が宇宙にあれば天文屋も使うだろうし。NAOJが噛んでるのも、共有するにしろ新造するにしろ、宇宙用の分割鏡望遠鏡が作れるか検討したいってことだろうし。

 作るならDS2000ベースだろうけど、DS2000って外宇宙を見れるほど振り回せるんだろうか。QZSでヨーイングはやってるけど、それにしたって地心指向であることに違いはないし、地心以外に向ける運用はDS2000ではやってなさそう。気象衛星だと放熱面の太陽角の問題とかもあるだろうけど、静止光学衛星の場合は分解能を稼ぐために短めの波長を使うはずだから、冷却はさほど問題ではなさそうな気もする。鏡の精度が得られなくて結局長めの波長になる可能性もあるけど、いちおうJWSTで使っている長波長側ではなく世界初となる可視光を目指しているわけだし。問題があるとすれば通信周りだろうけど、緊急用のテレコマはオムニだろうし、ある程度のボディポインティングは前提だし、通常はミッション用の超広帯域回線を使う前提なら、最初から外側を向けるように設計しておけば問題はなさそうな気もするな。イラストだと大型のパラボラアンテナを積んでるけど、これだとボディポインティングも難しそう。できればオーストラリアとかの晴天率の高い場所に光地上局を置いてもらって光で直結できれば嬉しい。光開口ならあまりかさばらないから地球側と反地球面に置いて内側も外側も向けるようにとか、あるいはうまくやればジンバリングで1個の開口でも成立するだろうし。



 新作TPS『ARC Raiders』は、“『Escape from Tarkov』が難しい”と感じるプレイヤーも遊べる脱出シューターだった。ヒリつきは残して課題を解決 - AUTOMATON

 個人装備はソ連みがあるな。

 ゲームシステムは面白そうだけど、西側の現代的な装備が好きなので、世紀末っぽかったり未来っぽかったりファンタジーっぽかったりソ連っぽかったりするゲームはあまり触手が伸びないな。


 数日毎に1回30分くらい遊んで楽しいゲーム(FPS/TPS)ってないものかなー。対人ゲーで最初にガッツリ自習しないと始めることすらできないみたいなゲームは気軽に遊べないし、プレイスキルが重要なゲームは週1くらいで軽く遊ぶことはできないし。

 対人ゲーでプレイヤースキルがあまり重視されないのって、大量のプレイヤー数でマッチングを頑張るくらいしか対応できない気がする。プレイヤー数が十分にいれば、少なくともゲーム始めたての初心者とランクをカンストした最上位層を同じマッチに入れてリスキルされ続ける、みたいなことは避けられるはず。

 とすると、初心者はプレイヤー数が多いゲーム、つまり発売直後のメジャータイトルを買うのが一番楽しそうな気もする。ローンチ直後ならプレイヤー数が多いことを期待できるし、それらのプレイヤーがある程度フラットな状態を期待できるし、必要であればSNSで情報も集めやすいし。結局リアルマネーでPay to Winってことになりそう。懸念点があるとすると、大抵はフルプライスのゲームを定価で買わなきゃいけないという点だけど、そこはもうPay to Winとして諦めるしかないかな。




 バトロワPvPでステルス特化って珍しい気がするな。

 面白そうだけど、従前の理由で……




 タイピングゲーム。短い単語が周囲から押し寄せてくるので、片っ端から入力して撃破していく感じの。寿司打と違ってランダムリード速度のオーバーヘッドがないから、常にキーボードを叩いている状態にできて、結構楽しい。

 雑魚敵は短い単語だからそれほど大変ではないけど、ちょっと違和感がある単語がちらほら。それと、ボス敵は著作権切れの古い文章を使っているやつがいるので、現代文の入力にしか慣れていないと大変。

 変な入力を強要されるのはバグっぽい気もするな。ローカライズの人が大量の単語のデータセットを作るときにちょっとミスった、みたいな。バグった方に慣れると後でバグフィックスされたときに大変そうだけど、とはいえ、違和感の少ない状態に直してほしさが強い。

 あとは、ゲームシステム(自機の種類やアップグレード)が分かりづらいかな、という感じ。



 Appleの商品ページ、Windows(非慣性スクロール環境)から見るとスクロールがガッタガタでめちゃくちゃダサいWebサイトなのが残念な気がする。「ウチの製品で見ればヌルヌル綺麗に表示できるよ!」とアピールしたところで、御社の製品を購入済みのユーザーにそれをアピールしても顧客の獲得にはあまりつながらないのでは? むしろ御社の製品を使っていないWindowsユーザーに対して強くアピールできるWebサイトを作るべきなのでは? WindowsからAppleのWebサイトを見ると「Appleってこんなダサいデザインしかできない会社なんだ」的に見える気がする。


***


 ある日の1090ログ

 航空大の機体。Mode-3/A,C,Sが出ている。旭川空港で1200でタッチアンドゴーを行って、帰るときにスコークを変更。かなり強い信号を受信している。単に距離が近いからという理由だろうけど。

 パルスはコヒーレントだけど、傾斜が変。

 Mode-Sの応答。ログの都合上短く分割されているけど。灰色のドットが位相。

 最初は上昇傾向、すぐに下降傾向に移って、最後はほぼ水平。謎い。PAの昇温でXtalの温度特性が見えている、という感じでもない。電源周りの特性とか?


***


 fl2kからGPS L1, L2, L5を出したときの配置の例。L1, L2, L5の振幅の差があまり大きくないものをいくつかピックアップ。結構多くの選択肢があるので適当に選んだ数個。

 ↑12.75Msps

 ↑21.086956Msps (ゾーンが違うけど20.370367Mspsでも同様の特性)

 ↑35.35714Msps

 ↑51.764703Msps

 ↑89.090907Msps (89.000000Mspsや89.166663Mspsでもほぼ同様)

 ↑96.25Msps


 96Mspsや89Mspsはだいぶ特性が良い。89MHzはL4とL3がゾーン境界に近いけど、まあ、民間人でそんなバンドを使うやつもおらんやろ…… ただ、96Mspsとか89Mspsはデータレートがかなり高いので、データの生成も高コストだし、FL2000に通すのもUSBコントローラーの帯域幅的に結構大変そう。

 52MspsはL2, L5の特性はいいけど、L1がゾーン境界に近いのでちょっと厳しそう。他のサンプリングレートもL1は厳しい。低サンプルレートだと21Mspsがゾーン境界からの距離はちょうどいいかな? 急な傾斜のそばだから補償フィルタを通そうとすると大変そうだけど。

 今回は拘束条件としてL1, L2, L5の高さ(Sinc関数の利得)が近いことを設定したけど、利得に関してはキャリアの振幅で調整すればある程度自由に設定できるから、これはおそらくあまりいい条件設定ではない。周波数の低いL5はSincのヌル点近くの傾斜が急な場所に配置されるし、周波数の高いL1はSincのピークの近く(ゾーン境界近く)に配置されてしまう。ピークから適当な距離(周波数で5MHzとか、正規化周波数で0.2とか)ずらした場所を拘束条件として探すほうが良さそうな気がする。


 ということで、試しにL1,L2,L5のゾーンを拘束して探索

 ↑19.375Msps (2.91dB@L1,2,5)

 ↑34.838701Msps (2.89dB)

 ↑70.666660MHz (3.53dB)

 ↑79.999992Msps (2.79dB)

 ↑85.714280Msps (1.36dB)

 ↑86.0Msps (2.56dB)

 ↑100Msps (2.94dB)


 35Msps以下はL5とL2の間にピークが入るので、SAWフィルタでエイリアスを切れない。エイリアスの除去を考えると少なくとも70Msps程度(L2-L5の1.5倍程度)が必要。この場合、L1とL2で2.8dBくらいの差があるので、この差を減らそうとすると85.7Mspsに設定する必要がある。サンプリングレートにキリの良さを求めるなら86Mspsとか100Mspsとか。fl2kの入力は10MHzだから、100Mspsなら外部クロックと高いコヒーレンシー(ジッタ特性)が期待できる可能性もある。100MspsならL1, L2, L5, L6がすべてちょうど良さそうな位置にある(フィルタの特性次第)。


 京セラのSAWだと1ポート入力で2ポート(L1,L2/L5)出力とか3ポート(L1,L2/L5,L6)出力の製品はあるけど、複数ポート入力1ポート出力の製品はなさそう。個別のアンテナを使ったらマルチバンドの意味がなくなるから複数入力ポートは不要ってことなんだろうけど。しかし、マルチバンドGNSS受信機って帯域ごとに入力ポートが独立してるのかな? それならfl2kから2,3chで信号を出して軽くDC付近(大きな振幅)を消してから、まとめずにバンドごとに突っ込めば良さそう。外付けのフィルタに依存してアンダーサンプリングとかやってると困りそうだけど。


***


 FMラジオ用のfl2kの適当な計算。

 IFのサンプルレートを285ksps(15x19kHz)に設定すると、250倍で71.25Mspsが作れる。71.25MspsはFL2000で出せるからちょうどいい周波数を出せる。76MHzから99MHzの範囲はゾーン3に入る。

 44.1kspsから285kspsに変換する場合、44.1ksps*950=41.895Msps/147=285kspsでかなり高い場所を経由する必要がある。かなり高い、とは言っても、DACのサンプリングレートの半分程度ではあるけど。

 48kspsからであれば48ksps*95=4.56Msps/16=285kspsで、かなり低い比で変換できる。

 FMステレオ放送を変調する場合、パイロット信号はNCOで作ればいいし、サンプルレートもそれほど高くない範囲に選べば計算量はあまり多くないから、大抵はNCOで問題ないはず。だた、RDSみたいなデジタルデータを扱いたい場合、少なくともパイロット信号の整数倍を選んでおくと、計算が楽になるはず。285kspsなら285ksps/57kHz=5で、データキャリアの1周期を5サンプルで表現できる。ちょっと分解能悪いけど、どうせBPSKだし、デジタル変調だし、なんとかなるはず……


***


 CICと補償フィルタの例(N6, R10、入力正規化周波数0.06でカットオフする補償係数)

 補償フィルタを通しても高周波側が上がってくる特性が謎だったんだけど、FIRの次数が少ないとこうなるらしい。特に32タップの場合は全体的に高くなっていて全く補償特性がないし、64タップの場合もDC付近が少し持ち上がっている。

 拡大するとこんな感じ

 1024タップでも細かく見ればやはり高周波側は持ち上がっていて、2048タップでも程度の問題。CICフィルタはなまじ整数演算で計算誤差がほとんどないから、厳密に見るとこういう細かい誤差が綺麗に見えてくる。

 128タップが顕著だけど、綺麗な曲線ではなく、多少うねうねした形になっている。これはFIRのリプルが窓関数(Blackman)を抜けて出ているもの。



 入力端の正規化周波数を0-0.5の範囲で周波数スイープした複素信号をCICに入れて振幅をグラフ化

 青が期待した値、橙がその結果。ぴったり重なって、その差は0.001dBより小さい。

 振幅の期待値は(sin(pi*f*R)/sin(pi*f))^Nで計算できる。CICの応答はSincのN乗という説明がよくあるけど、分子にRが入っているし、分母にsinが入っているので、ちょっと違う形になる。



 FMステレオ用のFIRの特性

 48kspsを入れてFIR、↑CIC(N6、R95)、↓CIC(N5、R16)をシリーズに通して285kspsを得るような形。FIRは512タップ、プリエンファシスはとりあえず50usを設定している。バンドパス特性はほとんど直線な感じ。CICやエンファシスが重なって偶然そうなったんだろうけど。/* 直線と言っても片対数だけど */


***


 SDR#のWFMのエンファシス特性。乱数+FFTで1kHzから5kHzの雑音を作って、それをFMステレオ変調しIQファイルへ書き出して、SDR#で復調。右下のAudio Spectrumが問題の部分。

 ↑0.1us(エンファシスOFF模擬)

 ↑50us(米国のFM放送)

 ↑75us(日本のFM放送)

 デエンファシスは高周波を下げるので、プリエンファシスがない場合(今回は0.1usで模擬)は明らかに右肩下がりのスペクトル。50usと75usはほぼ平坦だが、どちらかといえば50usのほうが水平に近い。とはいえ、ほぼ違いはない。


 エンファシス特性、10usから100usまで

 エンファシスOFFと50usは高周波では12dBとか変わるので音源によっては比べなくてもわかると思う。しかし、50usと75usでは3dB程度しか変わらないから、片方だけ聞いて正しいエンファシスか、不正なエンファシスかを判断するのはかなり難しいと思う。4kHzを超えればどちらも3dB差程度でほぼ一定だから、大抵の場合は単に音量の違い程度にしか聞こえないはず。


 本来は特性を期待できる受信機(例えば日本メーカーが開発した広帯域受信機のWFMとか)にfl2kの出力を突っ込んで、実機でも比較してみるべきなんだろうけど、ハードウェアも色々準備しなきゃいけないし、録音方法も考えなきゃいけないし、録音したもののスペクトルを見る方法も考えなきゃいけないし、ちょっと手間が大きいので、また気が向いたらやる方向で。。。


***


 SoundEngine Free(v5.23)のヴィジュアルのFFT、連続して見ていると正常に表示できなくなるときがある気がする。一時停止してまた再開すれば正しそうなスペクトルが見える。

 あと、ヴィジュアルのFFTは、FFTの分解能(Hz/bin)と表示の分解能(Hz/pixel)が違うが、そこのレート変換に変な特性があって、線スペクトルを表示すると振幅が正しく表示されないっぽい。振幅が正しくない程度ならまだいい方で、場合によっては完全にスペクトルが消えることもある。テスト信号みたいに線スペクトルが入っている音声信号を見たいときは気をつけないとまずそう。


 ↑すべての線スペクトルがある程度等しい強度で表示されている状態

 ↑フロアが暴れている状態。低周波側が顕著だが高周波側のスペクトルの隙間もかなり浮いている。

 ↑横幅を減らして表示した状態。例えば18kHz付近のピークがほぼ完全に消滅しているし、付近のピークもかなり減衰して表示されている。


 線スペクトルの高さが正しく表示されない問題は、表示領域を広くすればある程度緩和できる。おそらく適当な幅のbinを加算平均とかしていて、線スペクトルが消えるんだと思う。表示範囲を広くすると平均化に使用するサンプルが減るから、線スペクトルが相対的に浮いてくる。うちの環境だと4KモニタとサブのFHDの合わせて5760ピクセルの領域で表示すると、ほとんどすべてのスペクトルが同じ高さに見える。3840ピクセル程度だとまだガタガタする。

 高周波側が顕著で、正規化周波数で0.2あたりまではかなり安全。ただ、これはFFTの周波数分解能の問題だと思う。低周波側は、長期的には線スペクトルであってもFFT窓内ではブロードなスペクトルになって、複数binで平均化したときにノイズフロアに引っ張られなくなる、みたいなことだと思う。

 信号処理(フィルタ処理とか)のテストのために波形をWAVで吐き出してSoundEngine Freeで表示して確認する、みたいな方法は結構危険かもしれない。


 フロアが暴れるのは横幅を広くしたときに顕著で、幅が狭いときはほとんど出ない。高さはおそらく無関係。線スペクトルが消えないように横を広くするとフロアが暴れるし、フロアが暴れないように横を狭くすると線スペクトルが消えるし。難しい。


0 件のコメント:

コメントを投稿