ついこの間まで暑くてやる気でねー、とか嘆いてたのに、急に寒くなってきて。寒くなると、寒いところに放置した液晶画面みたいに指が動かなくなる。文字入力の多い作業はつらい。ブログ書いたり、プログラム書いたり。明らかに誤字が増えてる。誤字は寒くなる前から増えてた気もするけど。
今年の冬季は部屋に電気ポットとミニ冷凍庫を置いておきたいな。待機電力が大きい? それが目的なんだよ! いや、たかが電気ポットの待機電力で部屋保温できるとも思えないけど。電気ポットってどれくらい蒸発するんだろうか? 去年は部屋に加湿器おいてたけど、3L/dayくらい突っ込んでたからな。さすがにそんなに蒸発するとも思えないが。98℃設定ならそれなりに蒸発するかな? 電気ポットなら超音波加湿器みたいに手入れもいらないし、ちょっと水分突っ込みたいときには便利そう。なんといってもそのまま飲めるのが便利だよね。すぐに飲みたいときは熱すぎるので冷却用に氷を保管しておくミニ冷凍庫もあればもっと便利。Xbox Mini Fridge買うか?(いや、先にXbox Series X買えよ)
古い民家なので家電なんて扇風機1個くらいしか想定してないような部屋で、コンセントも1部屋あたり2口1個くらいしかないけど、ちょっと機会があって部屋の消費電力大きめなグループの消費電力を測ってみたら、通常使用で200W前後くらいだった。デスクトップPCって思ったより電気食わないんだな。ゲームやってるときは300Wくらいまで増えるけど。/* グラボが950なのでせめてこれだけでも載せ替えたい。。。 */
ということで、部屋に電気ポット置くくらいなら(電力的には)問題ないかな、と思っている(空間的な問題は別として)。
そういえば、ダンボーのパネルヒーターとかないんだろうか? (暖房ダンボー)
使い捨てカイロとか加湿器とかはあるようだけど。ダンボーのカイロをFLIRで見たら目の部分だけ熱くなってたりしないかな?
ワンポイントちっぷす。洗うのが面倒な場所でココアは飲むな。コロイドが沈殿して悲惨なことになるぞ!! 飲むなら紅茶にしろ。これなら溶液だから安心だ。ミルクティーはコロイドじゃねーか、というツッコミが来そう。ミルクティーは今の所問題ない感じ。粒径の問題かな? 各種スティック飲料のコロイドの粒径とか沈殿量を研究した論文とか、物理屋の気分転換に書かれてそう。なんたってスパゲティの乾麺が査読付き論文に掲載される業界だからな。
紅茶ついでに、ミルクティーの面白話、このPDFが短くきれいにまとまっていてオススメ
前書きに書いてある話も面白い。
スパゲティの論文
/* バジル・オードリーでぐぐったらパスタの写真出てくるのGoogleさんさすがやなって思ったけど、バジルに引っ張られてるだけなのか */
サイエンス系YouTuberによるスパゲティの検証動画
このアメリカ人、元は防衛関係の政府機関で仕事していたらしい人で、クリアランス取りやすいのか、いろいろなところで撮影してる。F-16で超音速飛行してみたり、アポロ計画で持ち帰った月の石の分析施設に行ってみたり(バニースーツ!!)、ULAのロケット工場(ITAR規制されてる)とか、最近だと米海軍の攻撃型原潜に乗り込んで色々紹介するシリーズとか。自転車に乗る動画もオススメ。
/* The Slow Mo Guysとかもそうだけど、向こうのYouTuberへのPhantom(DJIじゃなくてVision Researcheのやつ)の普及量が高いのだどうしてなんだ? アメリカの1ドルって日本円で10円くらいの価値なの?? */
***
前回のエントリ
Q. 船にCNCフライス載せて使えるのかな?
↓
A. 船にTormach 770載せた人がいるようです
数日前に投稿された動画。波に揺られても使えるのかといったような話はまだ出てきてないな。
米海軍のYouTubeチャンネルの動画
原子力空母エンタープライズのマシンショップ。
船の工作室って、たしか船を建造する段階で機械も入れてしまうはずなので、大型の機材は船が建造されるよりも前に入手可能なものしか使われていないはず。エンタープライズは起工が1958年なので、かなり古い船(世界初の原子力空母だからな)。LEDのDROがついてるので必要に応じて改修はしているんであろうけども。
こっちはジョージ・H・W・ブッシュ
起工は2003年と最近だけど、少なくとも小型旋盤は手動を使っている。
番外編、アフガニスタン・カンダハル飛行場に置かれたコンテナの中にあるマシンショップ(米空軍)
手動のフライスに液晶のDRO。
外観は20ftコンテナの横が開いて床面積が倍になるヤツみたいな感じ。機械もコンテナに入れたまま船で運んできたのかな? 横に飛び出ている部分、地面から少し高さがあるので、コンテナの横に部屋をつけたんじゃなく、コンテナの横から飛び出してくるタイプだと思うんだけど。
前述のYouTuberが原潜に乗ったときに機械室を見せてくれと頼んでたけど、「エンジンルーム(原子炉の近く)に置いてあるから君のクリアランスではダメだ」と言われていたな。曰く「カッコいいものは全部エンジンルームに有る」だそうだ。
***
米陸軍が高高度気球の準備を始めたようです。
……ハイスクール・フリートの世界かな???
一昔前だと通信情報機器(これが破られると指揮系統が敵に握られる)を使い捨てにするとか大変だろうけど、今だとSDR化されてたりするから、一定時間が経ったらSRAMをイレースして暗号化プロトコル削除する、くらいで機密情報扱えそう。
ヘリウムはどれくらい必要なんだろうか? 30kgのボンベまるごと1本くらいは必要なのかな。まぁ、あの国の備蓄量は凄まじいから足りるんであろう。。。なんせ米軍ですから、優先的に使える。これから先どうなるのかはわからんけども。
ボンベ持っていくより水を電気分解したらいいんじゃね?とか思ったけど、結構大変そうだ(「結構大変」というのは「成立しない程度には」くらいの意味)。リーク分だけでも補充できれば飛行時間増やせて便利そうだな、と思ってたんだが、電気分解で水素作って補填するよりポンプで水捨てるほうが楽そう。
CO2フリー水素の研究とかゴリゴリ進められて、電力・水素の変換効率の改善とかもある程度進むだろうけど、それにしたっていきなり2桁改善できるとも思えないし。とはいえ、今後SDGsとかで水素のハンドリングのノウハウが溜まったり、安全に使える部品が民生品で出てきたりすると、高高度気球みたいな回収できない用途では水素の利用が進むかもね。フーゴー・エッケナーの夢再び!!
/* 大きな乗り物の比較の図、ヒンデンブルク号とかエンタープライズとかノック・ネヴィスとかに並んでエンパイアステートビルとかペンタゴンが書いてあるのはわかるけど、Apple Parkも書いてある。アレってそんなにデカイんだな。そしてその巨大な建物にわずか6メートルまで迫る船……ッ!! */
***
ノースロップ・グラマンの月ゲートウェイのモジュールのモックアップ。
天井と床に照明が配置されてる近未来的な雰囲気。
JEM作ったときに照明もいろいろ試した結果、「上から光が降り注ぐほうが自然で酔いづらい」みたいな結論になったんじゃなかったっけ? 他の国のモジュールも同じような設計思想な雰囲気。宇宙飛行士に対する質問で「どうやって上下を判断しているのか」に対して「壁に書いてある文字の向きとか、光の方向とか」みたいな回答があったり。姿勢を認識する上で光の方向は結構重要らしい。全方向から光が降り注ぐ宇宙船はSF映画みたいでカッコいいけど、実用性としては微妙な気がする。
これが例えば赤色矮星みたいな放射エネルギーの低い恒星系で発達した生命体の場合は「地面(視界より下)からの光エネルギー(火山や噴出ガスの燃焼等)を見て生きてきたから地面付近が光っているのが当たり前」という可能性もあって、そういう由来を持つ知的生命体が作った宇宙船であれば、光は下から照らされるのが自然、という設計思想になるはず。
恒星間を飛び回って、いろいろな恒星からやってきた乗員で構成された宇宙船であれば照明の設計もいろいろ多様化してくるだろうし、「今の時代に照明が上にしかない宇宙船など差別的だ!!」とか言われるのかもしれないけど、我々人類が月へ足を伸ばすくらいの時代なら照明はすべからく上からだろう。月の南極にENGがいる可能性もあるけど、あいつだって上からの光で成長する以上は、当面は下から照らしてやる照明デザインは必要ないはず。
推進システムも面白い。静止衛星みたいな形してる。信頼性のある設計図流用したほうが楽ってことなのかな。PAF小さいしIESがPAFの横についているので別の設計かもしれないけど。NGはMEVとかも作ってるし、通信機器とかの無い単純に移動手段としての宇宙機の経験も色々持ってそうだな。
***
名前が「ゆか」という電波キャラが居る日常アニメとかで、クラスメイトが「ゆかたんマジゆかたん」とか言うと、マヤ語で「ゆかの言ってることは意味が分かんない」としてちゃんと意味が通るのか……マヤ語を解するJK!! という謎の発見。/* 久しぶりに映画『メッセージ』を見たら何か受信したらしい */
北海道に宇宙船が着陸したって!? 見に行かなくちゃ!! 『コンタクト』でも宇宙人テクノロジーの乗り物が北海道で作られてたり、わりと謎い。適当に大陸から遠くて人口密度低いから隠しやすい? いやぁ、ソ連とか結構近いぜ…… リソース吐き出させる交渉しやすい国ってことか。EU域に謎機械作らせるよりはやりやすそう。
***
物理攻撃には強いけど特殊な物質使うと攻撃が通る殺せんせーみたいな敵を想定して、これなら弾頭うまいこと作れば.22LRとかSimunition FXみたいな弾でいいからサバゲーマーくらいの人間でも扱えるんじゃね、という妄想。BB弾でいいのでは？という気もするけど、射程が短いのがネック。市街地で戦うならBB弾程度のエネルギーは安全ではあるんだけどね。
そーいえば.22LRの弱装弾あったよな、と思って検索。Colibriというやつ。パウダーを抜いてプライマーだけで撃つような感じだった気がする。10Jくらい出るらしい。銃口初速は420fpsなので130m/sくらいと、エアソフトの数割増しくらいだけど、弾頭重量が20gr(約1.3g)で、BB弾の数倍増し。トータルで1桁増。.22LRはリムファイアなのでプライマーの薬量をへらすのは大変そうだ。ま、いくら頑張ったって日本でエアソフトと同じ程度に気軽に.22LR撃てるとも思えないしなぁ。
最近の.22LR用のライフル、プリンキング(的撃ち)とかバーミント(ネズミとかの害獣駆除)用で売ってるやつ、普通にカッコいいし、3万円未満で買えるらしいし、気軽に撃てる某国がうらやましい。マルイのVSRと同じくらいの価格帯でスポーツシューティングにも害獣駆除にも使えるんだからそりゃ買う人も多かろう。
夏休みの縁日で鍛えた某艦長はその射撃でエイリアンの宇宙船も攻撃したし、我々もエアソフトと侮らず日々訓練せねば。……最近エアガン撃ってないなぁ。射的? クソ田舎の祭りでそんなモノあるわけなかろう!!
/* 田舎って救急車もほとんど走ってないんだよね。ドップラー効果の説明、アレ実は都会人のマウントなんじゃないかと疑ってる今日このごろ */
***
ネットで見かけた「絶対に期限時刻までしかレポートを受け取らない教授」vs「どうにかして期限を引き伸ばす学生」の話、学生が電波時計を使っていて教授がGPSを使っていてうるう秒の取り扱いが違うから、というオチ、電波時計の伝搬遅延とか言い出したりしてないのかな? GPSはマイクロ秒単位で時間を合わせるけど、電波時計は伝搬遅延の補正はされていないから、例えば北海道大学で考えると単純計算で2ミリ秒(600km/c)の遅延が生じる(実際はもっと大きな遅延になる)。GPSの精度から考えると非常に大きな遅延。電波時計自体の誤差? んなもんミリ秒オーダーの言い争いしてる学生がそんな不安定なもの使っているわけがなかろう!
天文やってる人曰く市販の長波電波時計は誤差が大きすぎて使い物にならないとのことだけど、精度求めたらどこまで高精度化できるんだろうか? 受信感度依存かな。長波の伝搬速度ってどれくらいなんだろうか? 電離層反射とか色々影響するせいかいまいち数字が出てこない(ちゃんと探してない)。LORAN-Cみたいに伝搬時間が重要な長波システムもあるし、古い論文漁ったら出てきそうな気もする。こんど調べてみよう。
***
マウスに欲しい機能、過去1秒分の積算のスクロールホイールを符号反転してブチ込むボタン。離れた場所に書いてあるヤツをスクロールして確認したいときに便利そうな気がする。適当なホットキー設定してそれに反応するプログラム書けば作れるか。あんまり使い所がないのが難点…… あとメインで使ってるマウスはゲーミング用のボタン多めのやつだけど、それですらすでにボタン埋まってて割り当てられるボタンがない。
次のタブ(Ctrl-Tab)、前のタブ(Ctrl-Shift-Tab)、タブ閉じ(Ctrl-W)、ページ戻り(Alt-Left)、ページ進み(Alt-Right)、あと中クリック(タクトスイッチ)が死んだのでこれを別のボタンに割り当てて、締めて6ボタンが埋まってる。
***
電子工作の作例探しで見かけたブログの「なんで動かないんだろう?」みたいなの、なんとなく心当たりはあるけど、でもそれくらいは確認済みだろうなぁ、とか思ってスルーするのがたまにある。GitHubとかにソース置いてあるとそのあたりを確認してコメントできるのが便利なんだろうなー。ソースの一部しか書かれていないと確認ができない。それとも確認済みである可能性があってもコメントとかするべきなんだろうか? コミュ障にそれは難しい……
***
CMSIS-RTOS API v2で使えるスレッドフラグ、C++から使おうとすると、適当なスコープ有りの列挙型(enum class)を使うことが多い。で、複数のフラグを監視したりしようとすると、ビット演算が必要になる。が、C++でenum classのビット演算を行うことはできないから、static_castを大量に使う必要がある。enumがスコープを持つので名前も長大になる。
ぐぐったら、いい感じの方法が出てきた。
【C++】列挙型をビット演算する方法【ビットマスク処理・整数演算】 | MaryCore # 演算用の演算子を独自定義する
この例だと、列挙型を受け取って列挙型を返す実装になっている。というか、普通はそうあるべきだろう。
僕の場合は、or演算は列挙型を返し、and演算はboolを返すように実装してみた。複数のフラグをosThreadFlagsWaitで監視するような場合はorでいくつかをまとめて渡すし、返り値から特定のフラグが存在するかを確認するときはifの中でandを取るため。andで列挙型を返すとifの中にstatic_castが必要になるので旨味が減ってしまう。
列挙型のandでboolを返すのは一般的には直感的じゃないと思うので、あんまり多用するのもどうかと思うけど、osThreadFlagsは一つのソースファイルの中でしか使わないので、無名名前空間の中で特定の列挙型だけorとandを定義しておけば、他のソースファイルから列挙型を使うときは都度static_castが必要だし、定義したソースファイルの中でも他の列挙型には影響がないから、今のところはいい感じに使えている。
CMSIS RTOSのスレッドフラグ(の下に入っているFreeRTOSのタスク通知)、ちょっと微妙な実装になってていまいち使いづらい感じがする。複数ビットを使うときは、NoClearで読み出して自分でClearするのが一番確実かな。
フラグを読むときは0x7FFF'FFFFとか渡してもいい気がする。一部だけ読むと面倒なことになる。CMSISラッパーは最上位ビットが立っているとエラーなので、Flags::error = 0x8000'0000とか定義しておいて、それでAND取ってtrueならエラー処理。
もうちょっと上手いやり方がありそうな気がする。
***
STM32F4でPDMのマイク2chの受信。PDMで受信してPDM→PCM変換してDACで出力。
ノイズだけなので実質DACのSincしか見えてないけど。いちおう、音を出せばそれっぽいスペクトルは出る。
PDMのクロックはTIMで作って、それをマイク2個とSPI2個に入力している。SPIは片方が立ち上がりエッジ、もう片方が立ち下がりエッジでキャプチャするので、PDMの2chを受信できる。マイクを指で触るとch1の波形が変わるので、タイミングとか不正かも。PDMのアナログ的な挙動で偶然動いてるだけなのかもしれない。ch2は触っても大して影響ない感じ。
今回使ったマイクは高クロックを一気に起動できなくて、一旦適当な周波数を挟む必要がある。SPIはクロック周波数の解像度が悪いのと、動作中にクロックを切り替えられないので、TIMでクロックを作った(RM0090によるとSPI分周は「動作中に変更できない」ではなく「動作中に変更しないで」としか書いてないので、何らかの副作用込で変更はできるのかもしれないけど。どっちにしても分解能が足りないが)。クロックを出してから一定時間(マイクの起動時間)待ってから、RTOSを止めてループでカウント値見て一定の範囲のタイミングで周期とパルス幅を書き換えている。これで1.2MHz50%→4.2MHz50%をある程度正確に(かつシームレスに)切り替えられる。頻繁に切り替えるならDMA使うと楽だし正確だけど、起動時の1回しか使わないのにDMA使うのはもったいない気がして。。。
受信したデータはPDM→PCM変換しなくちゃいけないので、色々工夫してSIMDでCICを通している。N4R8に通して525kSa/sに落としてからDACで出力。ゼロイチをN4R8に通すと4096までになるので12bitのDACに丁度いい。SIMD使うと2chまとめて処理できるので、1chでも2chでも負荷的にはほとんど同じ。RAM必要量が倍違う程度(あとはデータバスと)。
マイク自体は超音波にも対応しているので、適当な超音波パルスをぶつけるとちゃんとピークが出る。この超音波測距モジュール、「水晶乗ってるから正確に動作するよ」みたいなこと書いてあった気がするんだけど、公称40kHzからかなりズレてる。出力もパルス幅なのでマイコン側の精度に依存だし。さすが安物測距モジュールって感じ。まぁ超音波パルスが欲しくて買っただけなので測距性能とかは求めてないのだが。
バットディテクターとか作って遊ぶと楽しそう。データシート見ると超音波は周波数特性ぐちゃぐちゃだけど。それに信号処理も大変そう。STM32G4ならFIRをオフロードできるので作りやすそうかな? G4はPDMインターフェースが乗ってるらしいけど、デシメータは乗ってないらしいので、F4同様にソフトウェアで頑張るしかなさそう。まぁ、PDMインターフェース乗ってるだけでもタイミング(アナログ)的な部分を気にしなくても済むだけでも便利か。
MCUが動作中はLowを、アイドル時はHighを出している(ちょこちょこヒゲが出てるのはコンテキストスイッチ(1kHz)とかUSB(1kHz)とか)。クロックが4.2MHzで2x8192x8bitのバッファに受けているので約64Hz(約15msec)周期で処理が走っている。CIC処理で50%超のリソースを食ってる(→最適化してちょっと改善して最終的に47%くらい)。結構重い処理。単純な加算だけなんだけど、それだけに切り詰められる箇所がない。アセンブリダンプ覗いてももうこれ以上はどうしようもなさそう。命令数数えて実行時間と比較したわけじゃないのでどっかボトルネックがある可能性はあるけど。
ループはfor (uint32_t i=0;i<N;i++){}(Nはリテラル)がぱっと見てわかりやすいけど、uint32_t i=N;do{}while(--i);のほうが目に見えて早い(N倍で効いてくるのでつよい)。処理にiが必要な場合は使えない場合もあるけど、配列アクセスならポインタ経由するとかでいろいろ工夫すると結構効いてくる場合がある(配列はそもそもポインタ経由のほうが早い)。Cortexは数値の比較できるのでゼロで比較しなくても良さそうな気がするけど、定数をレジスタに読み込む分で負けてるのかも。デクリメントしてゼロならリテラルが不要になる分有利そうだ。
CICの中でfor使うと話にならないほど遅いので、ループは手動で展開している。フィルタの大きさをC++のテンプレート引数で設定してやると部分特殊化が使えるので、フィルタの大きさに最適化した処理を書ける。もちろん、パラメータを変えると関数を書き換えなきゃいけないけど、少なくともコンパイルエラーは出るので、修正忘れをすることはない。もっとも、ヘッダでfor回す処理を実装しているとそっちが使われるので「なぜか処理がクッソ遅くなった」という事象は発生するけど。こういう用途だとヘッダは宣言だけやって定義は各自用意するのが良さそう。
最初はint32_t型でテンプレートを宣言していたけど、SIMDで書き直す際にuint32_tで宣言し直した。フィルタ処理は符号付き整数で行うけど、SIMDは符号なし整数で処理されるので、テンプレートの符号の有無でSIMDの有無も切り替えられる。SIMD有りの方は2ch分を一気に処理するので単に型を変えるだけじゃなく、呼び出す側も多少は書き換える必要があるけど。
***
久しぶりにSDカードのドライバ書き直し。いまいちいいやり方が見えてこない。キューに突っ込んでスレッドで順次流す方法と、ミューテックスで使用権を確保してそれぞれのスレッドで読み書きする方法。基本的に組込機器なら外部ストレージにアクセスするスレッドは1つしかないはずだから、後者の方法で問題ないはず(もっと言えば、ミューテックスも不要)。試しに前者を実装してみたけど、予想以上に面倒なことになってきたので、後者に切り替えて実装してる。
ロジアナでバス見ながら書いてるけど、メモリが足りん。LAP-C Pro使いてぇ……
とりあえず、シングル/マルチブロックの読み書きに対応したので、最低限の用は足りるはず。525kSa/sのWAV流せるほどの速度が出るかは知らんが。。。
ということで、今回はここまで。/* 今回はネタが殆どなかったのに結局いつもの長さに近いな。YouTubeからネタ拾ってくると簡単に文章量を水増しできる。 */
0 件のコメント:
コメントを投稿