小ネタ

　smarter every dayがローレロンの動画作るみたいな話ししてたけどあれどうなったんだろう。

　固体モーターが燃焼終了してしばらく慣性飛行して、ある程度減速してから分離してパラシュートを出したけど、固体燃料の残留推力で綺麗に突っ込んできている。昔の衛星の打上げとかで残留推力が問題になった例はいくつかあるけど、映像で見せられると説得力があるな。

　距離というか速度のほうが見たいけどな。あと、表面にマーキングして角運動量とかも解析してほしい。

　155mm砲くらいの大きさだとハイスピードカメラでトラッキングするソリューションがあるけど、6mmくらいだと長距離の飛翔を観測するのは難しそうな気もする。ホップアップが効いてくるのはある程度の距離を飛んだあとだから、ハイスピードカメラでマズルから全体を計測するのは厳しそう。

　実銃だと例えば5.56x45mmは直径だけ見ればBB弾より小さいわけだし、速度では10倍くらい早いから、実弾の長距離の飛翔中の解析ができればBB弾の解析も余裕だろうけど、とはいえ銃弾の飛翔中の解析ってのもあんまり需要なさそうな気もするし。

　155mm砲弾とかのトラッキングって、そういう機械を売っている以上は需要があるんだろうけど、どういう解析をやってるんだろう? 衝撃波の形とか砲弾の回転とかは適当な固定ウインドウでハイスピード撮影すれば解析できるだろうし。

　【Fit Boxing feat. 初音ミク】ミ　ク　と　一　緒　に　エ　ク　サ　サ　イ　ズ【石神のぞみ／にじさんじ所属】 - YouTube

　何十年後かの老人ホームって、三八式の代わりにサイリューム持たせて、こういうので体力維持を図っているんだろうな。ペンライトが普及しても老人ホームからの根強い需要でサイリュームの生産が続く世界か……

　経験で覆すのがベンチャーの強み - Synspective小畑氏が目指す小型衛星の将来 - 宇宙ビジネスの開拓者たち(2) | TECH+（テックプラス）

　おそらくJERS-1の話だと思うんだけど、ちょっとしたエピソードとか。こういう面白い話、いっぱいあるんだろうから誰かまとめて本にしたらいいと思うんだけどなぁ。噂話を聞く程度でも面白い話は色々あるんだから、「なにか面白い昔話ありませんか～」って聞いて回ればたくさん出てくるだろうに。

/* JERS-1はクリティカルフェーズでSARが展開せず、パネルを保持していたピンが抜け残ったと想定されたため、揺さぶって抜くための「共振マヌーバ」を計画していたところ、実行前に展開が完了した(打ち上げが2月11日、クリティカル運用は当初16周(ほぼ1日)の予定(実際には31周までクリティカル運用を継続)、4月4日に引っ掛かりが外れ、シーケンスを順次実施して9日に展開を完了) */

https://www.jstage.jst.go.jp/article/sicejl1962/24/6/24_6_565/_pdf

　1985年。地球センサに使われる焦電センサ、松下で作ったやつがいくつかの衛星に搭載されて使われていたらしい。最近だとパナがキューブサットを作ったりしてるけど、昔から宇宙用の機器を作ってたりしてたんだな(パナのやつは民生品の宇宙利用だけど)。

https://www.jstage.jst.go.jp/article/itej1978/41/4/41_4_299/_pdf

　1987年当時の衛星とかの概観。テレビジョン学会誌に掲載されたものなので、幅広く解説されている。まあ、「(前略)一般論として、将来的には完全再使用型の宇宙輸送機が出現することは確実と考えられている」という感じの時代だが。

　将来構想として静止プラットフォーム(GPF: Geostationary Platform)についても。NASDAの16トン級のイラスト。800MHz移動体通信用の30mアンテナが2個、Ku帯やK帯の小型(といっても2mから5m)がいくつか。

　20年くらい前に、MEMSを使った固体燃料アレイという構想があったらしい。MEMSから想像するほど緻密・複雑なものでもないけど。直径0.8mmくらいの穴に固体燃料を充填して、表面のヒーターに電力を投入することで点火させる。1mNs程度を想定していたようだ(当時は0.02-0.3mNsくらいしか出ていないが)。このマイクロスラスタを1.2mmピッチで2次元に大量に(1万個程度)並べて、推力が必要なときに必要な量を着火する。比推力は180s程度を想定していて、コールドガスジェット(50s程度)より高性能を目指す。

　2001年前後に開発が始まって、「マイクロ衛星」のコンスタレーションとかを構想していたらしい。東北大とISASで研究していたのかな? 東北大のエネルギー系のMEMSをやっていた研究室がISASに持ち込んだみたいな流れらしい。

　この頃はNASAやJPLで半導体プロセス(MEMS)を研究する設備を導入していたらしい。宇宙用のMEMSは地上では全く用途がないから、研究をアウトソーシングすることができず、アメリカではNASAやJPLが自身で研究設備を所有していた。日本でこのような動きはなかったから、大学の研究室からISASへ売り込んだ、みたいな流れなのかな。で、複雑なMEMSを作るのは大変だから、まずはシンプルに固体燃料アレイを、みたいな感じか(固体燃料アレイ自体は1990年代末頃にアメリカの企業で考案されたものらしい)。

https://www.jstage.jst.go.jp/article/kjsass/52/609/52_262/_pdf/-char/ja

　2004年。宇宙用のMEMS、特に推進系。コールドガス、固体燃料、液体燃料、電気推進、色々提案されている。

　LUNAR-Aのペネトレータの姿勢制御にマイクロ固体燃料アレイを使おう、みたいな話も。ペネトレータのラムライン制御は初期案でGN2を想定しているから、マイクロ固体アレイはあとから出てきた案か、あるいはMEMSチームが勝手に言ってるだけかもしれないけど。

　太陽電池とかも含めてワンチップ化した衛星のコンセプトとかも。太陽電池はシリコンベースならシリコン基板で作れるし、スラスタもMEMSで作れるなら同じ基板に載せられる。計算リソースももちろんシリコンで作れる。シリコン半導体をほとんどむき出しで宇宙空間に持ち込めるかとか色々あるだろうけど、コンセプトとしては面白い。MEMSスラスタはシリコンを4枚重ねて使うような提案もあるし、最終的にはスラスタとか計算リソースとか太陽電池は別々に作って重ねるなりするのかもしれないけど。3Dチップレットならそれぞれの用途(太陽電池、MEMS、計算)に合わせてプロセスを最適化できる。とはいえあまりに物性が違う半導体基板を使うと熱膨張率とかの兼ね合いも出てくるだろうし。

　最近だとJAXAでミニマルファブを使ってIC(4bitシフトレジスタ)を試作みたいな話もあるけど、とはいえミニマルファブ自体がまだ開発中の段階だからなぁ。ある程度大きなMEMS機構は作れるだろうけど、計算機とかを作るのはまだまだかかりそう。将来的にミニマルファブの0.5インチウエハで太陽電池やらスラスタやら計算機やら無線機やらを全部作って、それを重ねて宇宙に持っていけたらデモンストレーションとしては面白いだろうけどな。大電力が必要な通信系は厳しいとしても、例えば1m未満程度の近距離通信で良ければ大容量電池(シリコンで作りづらい)は不要だろうし、JEMの暴露部に0.5cmくらいのメッシュで小さい部屋を作ってその中で動き回らせたりはできるだろうし。1ヶ月とか1年とか浮かべておいて、HKを取りつつ、適当なタイミングで地上に持ち帰って実物の劣化状態を解析したりとか。

　小型衛星(数kgくらい)で蒸気圧の低い潤滑油をインクジェットで打ち出すスラスタとか作れないものかな。細いチューブで必要な箇所に分配して、MEMSヘッドで打ち出す。リアクションホイールとかの可動部に対しても同じ液体を供給して、スラスタと共通のヘッドで回転部に潤滑油を定期的に打ち出す。

　インクジェットプリンタのヘッドにはピエゾとバブルの方式があるけど、これを組み合わせて、ピエゾで押し出し+流路を閉塞して、ノズル側のヒータで加熱する、みたいな方式とかも作れそう。ヒータで熱エネルギーを追加できる分で比推力が改善する。

　MEMSで斜め穴が作れれば1個のヘッドで1軸並進+3軸回転とかを作れるけど、半導体プロセスで斜め穴は難しそう。制御部はMEMSで作ってノズルは樹脂なりを機械加工で削って、ノズルの向きで推力ベクトルを制御するみたいな形はできるか。

　ETS-VI(きく6号)、SAPは4枚2翼構成だけど、GTOでは1枚だけを開く部分展開モードというのがあるらしい。内側のパネルやヨークは構体に固定されているはずだからパドル駆動(太陽追尾)はできないけど、GTOでは太陽指向の弱いスピン安定で運用するのかな。TT&CはUSB(オムニアンテナ)だから向きは関係ないだろうし、アポジとかでスラスタを吹くときは短時間だからバッテリで間に合うだろうし。最近の衛星のSAPってワイヤとかプーリで全体を連動させて(均等に)開かせる機構が主流な気がするけど、部分展開をやる場合ってパネルの同期はどうやってたんだろうか。特に同期とかは気にせずにエイヤと開いていたんだろうか? それで支障が出てきたから同期して開くようになってきたんだろうか。

　なーんか、Razerのサイドボタンがチャタり気味なんだよなぁ…… crtl-wに割り当てているスイッチが2度押しされる。1日に1回から数時間に1回程度の頻度。

　Razerくんさあ、買ってからまだ1年と3ヶ月程度だぜ? ゲームで使ってるわけでもなし、そりゃ大量にブラウザのタブを開く病に罹患している自分はctrl-wは頻繁に使うとはいえよ。エンコーダといい、スイッチといい、寿命短すぎだろうがよ。

　正道としてはハードウェアトラブルが発生したら躊躇せずメーカーサポートに連絡して交換してもらうべきなんだろうな。何回も交換が発生すればサポートコストがメーカーの負担になる。それが製品寿命の向上への圧力になる。複数回の交換に応じてくれるのかはわからんけど。

　とりあえず、サイドパネルは3種類付属していて、一番スイッチが多いやつを使っているから、あと2枚ある。バラして部品取りに使えるか見てみるのはアリか。バラせるような構造なのかはわからないけど。

　Anker V6 Color Engine、1月末ごろに開発中止になってたんだな。

　元々V6には期待せずにM5を買っていたし、そもそも手を出せる価格でもなかったけど、やはり残念よなー。せめてフィラメント保管容器としてガワだけでも売ればよかったのに。他メーカーのドライヤー/ストレージにはコスパで勝てないとしてもよ。発売予定まで数カ月ってことはハードウェアスペックはほとんど固めてあとはソフトウェア側で頑張ろう、あたりまでは来ていたはずだと思うんだけど。金型とか生産ラインとかも用意していたんだろうし、ストレージ機能だけでも売ってくれればもの好きは買うだろうに。ブランド品が好きな自分としては、V6はちょっと手が出せないけど、複雑なヘッドとか供給機構とかを除いた部分(保管容器)として多少安くなってれいれば値段によっては買ったかもしれんぞ。ガワの金型は流用してそのうち別の機構で開発し直すのかもしれないけど。

　暖かくなってきたので、ちょこちょこと3Dプリンタの使用を再開している。社外のフィラメント(純正の半額)を使うことが多かったんだけど、手持ちのフィラメントで使いたい色が純正のやつだったので、久しぶりに純正フィラメントを使用。ホットエンドを加熱している間にめちゃくちゃフィラメントが吹き出てくるんだけど…… これってフィラメントの水分が発泡してるんだろうか? やっぱりフィラメントを複数本入れておけるストレージボックス(除湿機能付き)欲しいなぁ。いや、本当に必要なものはストレージボックスではなくシリカゲルを再生するためのホットプレートな気もするけど。

***

　rtl_tcp.exeのクライアント、一瞬3ch同時のISDB-Tコンスタ表示が動いたんだけど、そこからチマチマ手を入れてたら2ch動作も厳しくなってきた。誰だ!! C#のTask/async/awaitが簡単だなんて言ったのは!!

　試しにFourier.Forwardの処理時間をStopwatchで計測

　縦軸はミリ秒、横軸は秒。10秒辺りまでは1ms以内で処理できているけど、それ以降は処理時間が長くなっている。18秒あたりで処理時間が短くなっているけど、これは計測上の問題。

　シンプルなテストコードで、並列10スレッドで2048ポイントの乱数FFT(スレッドの中で乱数の生成も行っているので、FFT自体の並列数はもっと少ない)

　並列数が多いのでより処理時間が長くなっている(内部的には並列処理になっているはず)。最初は処理時間がある程度狭い範囲に固まっているけど、一定以降では処理時間のバラツキが増えている。短くなったり、長くなったり、変な挙動。

　ISDB-TのOFDMは1.134ms(@6MHz,GI1/8)間隔で送られてくるから、FFT(1024pts or 2048pts)は少なくとも1ms以内に終わる必要がある(SP等価くらいまでなら処理負荷はそれほど大きくないから、FFT処理時間が支配的)。

　リアルタイムISDB-TクイックルックはFFTライブラリが難関かなー。FFTってもっと早いものだと思ってた。例えばCortex-M4(168MHz)で複素数(32bit)のFFTは2048ptsで1.6msくらいなので、2-4GHzくらいで動くCore i7が同じくらいの速度しか出ないというのはちょっと直感に反する。

　試しに自分でFFTを書いてみた

　青がISDB-T用の2048pts、橙がウォーターフォール用の16384pts。自作FFTメソッドはシングルスレッドなので、処理時間のバラツキは少ない。なんかMath.Netより早いんじゃね?という気がするけど多分気の所為。どちらにしろ、一定時間で処理時間が急増している。

　内部処理的には全く無関係のメソッド(Math.NetのFourier.Forwardと自作のFFT)で同じような変化の仕方ってのが不思議。GCかどっかが大量にリソース食ってメインの処理が圧迫されてるみたいなシナリオなのかな? 大量にメモリを食ってそうな場所か…… 心当たりが多すぎて。。。

　GUI(ヒストグラム、ウォーターフォール、GI相関、コンスタレーション)の表示を消して、最小構成で実行

　処理落ちするまでの時間が伸びた。やっぱりメモリ消費量とかの問題なのかな?

　リリースビルドで実行するとGUI全部有りの3ch並列(ISDB-Tフルセグ)でもしばらくは問題なく動く。

　10分程度は問題ないかな。運が良ければ30分程度でも。3ch並列でもCPU負荷はタスクマネージャで5%程度。

　FFTをMath.Netに戻すとリリースビルドでも比較的短時間で処理落ちするので、やはりMath.NetのFFTライブラリにも何らかの問題はありそうな気もする。とはいえ、自作FFTでもデバッグビルドでは満足に動かないので、全体的に問題があるんだろうけど。

　ISDB-Tのコンスタレーションの表示機能はノリと勢いで実装したような部分なので、ちゃんと動いてくれなきゃ困る、というものでもなく、こればっかりにかかりきりになるのもな、とは思っているんだけど、やはり動いてくれないのは気持ち悪いわけで。どうしたものか。

　とりあえず、Task/async/awaitは無関係っぽいな。

UNDERGROUNDサインボード

　ガミさんの新衣装可愛すぎ!!! ということで(唐突)、部屋の奥に置いてあるUNDERGROUNDサインボードを作ってみた次第。

***

　手持ちに白と黒のフィラメントしかなくて、いつも使っているブランドの赤のフィラメントをamazonで注文したら「納期6月中旬ね」とかいわれたので、とりあえず文字は白で作った。やっぱり色が違うとあんまり雰囲気でないね。

　文字にはLEDが入っているので、赤で照らせば夜は近い雰囲気になる。カメラで撮ると色ムラが大きいけど、肉眼で見ればもっと綺麗(机に反射している方の雰囲気が近い)。

　24bitのフルカラーLEDが入っているから、ゲーミングモードも可能。スクロールさせたりすると結構綺麗。そりゃストリーマーはみんなRGBLEDを背景にするよね、みたいな納得感がある。

　今回はフレームをワンピースで3Dプリンタのベッド(235x235)に入るような大きさで作ったので、文字の高さが30mm、横幅が28cm、くらいの大きさ。オリジナルよりだいぶ小さいけど、机の上に置いたりするにはちょうどいい大きさ。これより小さいと文字が小さくなって光路が狭くなるし、大きいと机の上では邪魔になる。棚の上に置くならもっと大きくてもいいけど。

　使ったLEDはWS2818が144個/mのやつで、39個を2列入れている。上下2分割なのでうまく制御すれば結構いろいろ表現できる。LEDが78個入っているから、1個50mAとして4A20Wくらいの消費電力。だいぶ発熱する。最大輝度だとかなり明るいから、照明器具として使うつもりでないなら10%くらいで十分。

　WSの制御は例のごとくFT234X(inv)でPCに接続して、C#から適当なコードで色パターンを作っている。マザボのアドレサブルヘッダとかファン/ラインティングコントローラに接続すればメーカー製のユーティリティからも制御できるはず。対応しているゲームであれば、例えばEuro Truck Simulator 2だと警察に違反切符を切られるとパトカーのパトランプの色で光るとか、そういう動きもできるはず。

*

　買い物に行く機会があったので、ホームセンターで赤のスプレー塗料を購入。白の文字に塗ってみた。

　期待以上にいい感じ。パネルは着脱可能なので好きなモードを選べる(白文字ならゲーミングモードが映えるし、赤文字ならオリジナルの雰囲気に近い)。

　スプレーで塗るときはカロリーメイト9個入り(amazonで売ってるやつ)の段ボールを使うと便利。適度に大面積だし、蓋を閉めれば埃とかも落ちてこないし、展開しておけば1枚板になるから収納にも便利。蓋を閉めれば何個か重ねておけるから、プラモデルとかで小さい部品を大量に塗装したいときに便利そうな気がする(組み立て途中で放置するときにも便利)。塗装直後に密閉すると乾燥が遅くなりそうだけど、活性炭の消臭剤なりシリカゲルなり入れておけばいいだろうし。高さがあまりないのでクリップとかで挟んだ部品を入れるのはちょっと大変そうだけど。

***

　内部

　LEDたくさん。電源や制御はAWG24で配線。最大輝度で点灯させるとAWG24では容量に不安があるけど、そもそもLEDの発熱が多すぎるので最大輝度での点灯はやらないし。

　反対側でDOUTを最短距離でDINに接続している。LEDの配置は左右で折り返すことになるので、制御側はそれに応じた設定が必要になる。

***

　ハウジング(水色)、LEDストリップ(紫)、文字フレーム(緑)、光拡散パーツ(橙)、表示文字(黄緑)。

　気休め程度にベンチレーションを入れてはいるけど、30mmに満たない差だから、煙突効果なんて期待するべくもなく。後ろに光が漏れるので、壁際とかに置くと壁が間接照明的に若干照らされるので、熱設計というよりはデザイン的な機能かな。

　拡散と文字は軽い圧入、文字フレームはハウジング側の突起で保持、という感じなので、接着とかネジ止めは使っていない。文字Assy(フレーム、拡散、文字)は分解する必要は無いから、接着剤で軽く固定していたほうが安心かもしれない。ハウジングは接着しちゃうとLEDストリップを修理する必要が出たときに困ることになる。裏側からM3のキャップとかで固定するような構造でもいいけど、止り穴用のタップは持っていないので、今後の課題。

　LEDストリップは両面テープで固定している。発熱がかなり大きくて、輝度を上げて長時間点灯していると軽く60℃を超える。放熱なしの20Wだからな。面積が違うけど、半田ごてと同じ程度の発熱量、電気ストープの10分の1くらいの発熱量。結構熱くなる。熱くなりすぎると両面テープが剥がれたりする。両面テープはナイスタックの普通タイプだけど、これ、熱すると弾性が強くなるみたいな特性があるっぽい? 普通接着剤とかって温めたら柔軟性が増えるような方向だと思うんだけど。/* 非接触温度計なんて使わないし……と思って放置していたけど、いざ使えるようになれば使うもんだな */

　ガミさんの部屋で光り物がエアコンの近くに固めてあるの、熱対策かなぁ(空想)。

小ネタ

 

　3Dプリンタをエポキシ花崗岩の型枠兼外装みたいに使うと考えれば、安価な3Dプリンタでも結構リジッドな機械を作ったりできそうだな。ある程度の大型の構造物でも複数のパーツに分割して印刷して、内側をマステで貼るみたいにエポキシが漏れてこない程度の密閉だけしてやればいいから、3Dプリンタより大きな構造も作れるし。ここまで来ると3D printedとは一体、みたいな話になるけど。/* エポキシグラナイト、粒径の違う砂粒で空間を埋めて最後の最後にレジンを詰め込んだりするあたり、固体燃料っぽさがある */

　ギ酸を水素のキャリアにして、微生物に反応させるプラントのコンセプト。ギ酸へ、またはギ酸から、双方向に処理できるそうだ。

　65℃、1.5bar程度で活性で、低温状態では長期保存できる。嫌気性なので環境へ流出しても直ちに死滅する。嫌気性微生物を使うので、システム内に酸素がほとんど不要で爆発の危険も無い。

　想定としては、電気分解で水から水素を作って、それを微生物でギ酸に変換して、それを抽出して輸送、輸送先でまた微生物で水素へ戻して、燃料電池で電気へ戻す。

　メーカーの主張としては「生物の進化ほどエネルギー効率の高い物はない」「人間ほどエネルギー効率に無関心な生物はいない」だそう。

　この微生物を採取したのは「アフリカのキブ湖」だそうで、そりゃ温水中で二酸化炭素とか炭化水素をうまく使うやつもいるやろなぁ、みたいな納得感が。

　スカパーJSATが静止軌道の宇宙ステーション「Yamato」構想を出展 - 第1回SPEXA | TECH+（テックプラス）

　スペースシャトルが飛ぶ前から似たようなコンセプトがある。LEOで組み立ててGEOへ運んで運用、必要に応じてLEOへ戻してモジュールを交換したりして運用。各国で5-30トンくらいの計画があって、30mくらいのアンテナでUHFを使って地上の移動体通信と直接通信する、みたいなものも。でかい方向だとJPLのSSPSで8x8kmくらいの計画もあったし。

　当時はスペースシャトルの運用開始で輸送コストが下がるから巨大な構造物を運ぼうぜみたいな構想があったけど、最近もスターシップ等で輸送コストが下がれば……みたいな計画が色々出てくる。

　アンテナ直径100mは結構でかいけど、とはいえETS-VIIIは19x17m(楕円)を2枚だから、差し渡しでは2倍程度の大きさなんだよな。面積でいうとだいぶでかくなるけど。DSNのでかいやつが70mだから、これより一回り大きい。電波望遠鏡みたいに振り回すわけじゃないし、重力や強風に抗う必要もないから、地上にある物ほど巨大なものを想像する必要はない。大きさでいうと国際宇宙ステーションとほぼ同じ面積(太陽電池間の隙間を全部埋めたと考えた場合)。

　墓場軌道でめっちゃぶつかるだろうから、アンテナは開くだけでなく閉じる機構も(数十年後に動作する品質保証で)作るのが面倒そう。まあ、墓場に持っていってから導爆線で切り刻むとか色々方法は考えられるにしても。あるいは、LEOに下ろして修理して使い回すという手もあるし、もしくは大面積のメッシュで墓場軌道を大掃除みたいな用途も考えられるけど。

　需要さえあれば直径100mクラスの静止軌道構造物は(初期費用がかなり高そうではあるけど)極端に困難な感じはあまりなさそう。静止軌道は非修理系であって、LEO(以前であれば例えばシャトルの修理ミッションが計画できた)に比べて要求信頼度が高い難点がある(70年代から80年代にかけて計画されていた大型静止軌道構造物はこれの対策として、LEOで組み立てて動作確認を行ったうえで静止軌道へ持ち上げる)。ただ、最近の月開発とか惑星間有人探査を考えると、それらの宇宙船を流用すれば静止軌道への有人ミッションが現実的になってくるから、有人施設を含めた静止軌道上の大型構造物は従来に比べて実現性が高くなってきている。

　多少無理をしてもASTRO-Gを開発して大型アンテナの軌道上特性を測っておけば商用衛星通信で使ったりもできたんだろうけど。ISASは科学観測がメインターゲットだから、商業展開につながる技術開発を行う方向性はなかったんだろうな。NASDA側から提案して通信衛星用の大型アンテナの宇宙実証兼VLBI観測にも流用みたいな方向性で立ち上げていれば、多少の予算超過を許容してでも技術開発を行うみたいな方向性はあったかもしれないけど(LDRはNASDAで開発したものなわけだし)。とはいえ、スペースVLBIで使うにはある程度の軌道傾斜角がほしいし、通信衛星(静止軌道)でVLBI観測は難しそうだな。極端に東西基線だけ伸ばしても。GTOでアンテナ展開とか一通りやってVLBI観測も、みたいな方向性がない訳では無いにしても、GTOはペリジが低いからあんまり長期間は置いておけないし、NASDAが主導するなら先に通信衛星として評価してから、残りの寿命はISASに貸し出すみたいなスケジュールになるだろうし。

　15年前から比べれば解析技術とかも色々発達してるし、直径で10倍、運用期間で5倍だと展開したらあとはそのまま形状維持ではなく、アクチュエータでアクティブに形状制御は行うだろうし、ちゃんと予算かけて開発すれば作れるんじゃないかな(商業的に採算が合う範囲に収まるかは別として)。

　ラノベとかで時々出てくる、テック系のキャラが使っている「違法改造されたデバイス」(e.g. スマホ、ノートPC)、具体的にどのあたりが違法なんだろうか。電子機器に適用される法規制はいくつかあるけど、大半は製品として販売するときに適用される法律な気がする。エンドユーザーレベルで改造(or修理等)で抵触する法律ってどんな物があるんだろうか。

　一番わかりやすそうなところだと、電波法で規制されている部分を違法に改造して通信の信頼性を向上させるとかは考えられるか。ただ、PCやスマホに内蔵されている通信モジュールを改造するとなると、あんまり改造の方向性って広くなさそうな気がするんだよなぁ。例えば通信機器の送信出力を上げたところで、基地局から送られてくる信号の出力は変わらない(むしろ信号レベルが高いと物理距離が近いと判定されて送信出力が下げられる可能性すらある)わけで、通信距離の改善にはあまり役に立たないはず。基地局側(に類する設備)まで含めて触れるならともかく。

　コンビニの冷凍食品を加熱するだけの簡単な作業すらまともにできなくて自己嫌悪に陥るので冷凍食品は健康に良くない(おい

　ぶっ、ぶつりほうそくがわるいだけだから！誘電率なんて物があるせいで……ッ!! 吸収率がポジティブフィードバックなのマジで迷惑だよなー。ネガティブフィードバックならどれだけ食文化が豊かになることか。

　SSPA型の電子レンジが出てきたところで、食材や温度や相によるエネルギー吸収率の差はどうにもならないので、当面は改善の余地は多くはなさそう。ただ、精密にビームステアリングできる製品が出てくれば、反射率からその焦点の吸収率が見えるから、吸収率の高い場所を避けて照射するみたいな、能動的な吸収率のキャンセルはできる。精密に制御するとなると24GHz帯あたりを使いたくなるはずなので、高周波・大電力の精密制御が必要になるから製品として成立させる難易度は高そうだけど。あと、周波数が高くなると吸収率も高くなるので、食品中に浸透しなくなるんだよな。かといって解凍用の24GHzと加熱用の2.4GHzのデュアルバンドに対応させる、みたいなことはコスト面でも難しいだろうし。

　30℃位で切れる導電性のフィラメントがあれば、それを食品に添加すれば、低温では電磁波を良く吸収し、十分に加熱されたら電波の吸収率が下がる、みたいな感じに使えるんだろうけど、しかし食品に添加できるような材料というのがネック。ストロー状の可食フィルムに氷点の低い液体を入れて食品中に分散させておいて、冷凍状態では内部の液体で電波の吸収率が高く、加熱したらストローが弾けて吸収率が急減して、みたいなものは作れそうかな。

　コンビニのプラのスプーン、口から引き抜くときに歯に当たると表面のわずかな凹凸が感じられる。横手方向に接触させてもわからないから、横向きの凹凸があるんだろうな。金型を切削するときに横方向に往復させて表面を作ってるのかな。長手方向に走らせて仕上げれば歯に当たったときの感触が良くなりそうだが。

***

　あまりにも暇すぎて、本棚の奥底に放置されていた安物の非接触温度計を修理。10年以上前に買ったやつだけど、わりと短期間で起動しなくなったやつ。当時の症状からしてタクタイルスイッチの劣化だろうなと予想はしていたんだけど、使うこともあまりないし、延々放置してたやつ。

　爪だらけで分解が面倒、樹脂の劣化で爪がバキバキ。スルーホールなのでスイッチを外すのが面倒なので、足を切って1本ずつ除去。手持ちのスイッチは高さが高かったので、トリガのパーツを切断して対応。

　電池が006Pで、手持ちに無かった(昔まとめ買いして残ってたやつはほとんど液漏れで死んでた)ので、安定化電源で動作確認。トリガーを引けばちゃんと反応するので、修理は完了。

　計測モジュールの近くにあるSOP8は1Kbのメモリ。コンフィグ保存用かな?

　電源の入力にシリーズでダイオードが入っている。006Pは固定はできないにしても逆接は容易な端子形状だから、こういう対策が必要になるんだろうな。

　液晶の裏にCOBが乗ってて、これが全体の制御かな。温度計モジュールを固定するネジの無理矢理感よ。。。モジュール側は斜めに切り欠いてるんだから、切り欠きに合わせてネジ穴つけておけばいいものを。斜め穴はダイカストだと面倒なのかな?

　世の中のタクタイルスイッチの寿命短すぎ問題、どうにかならんのかなー。

***

　SDRクライアントソフトのやつ。

　終了時に設定をJSONで保存、起動時に読み込み、ドラッグアンドドロップでも読み込み、という感じの機能を追加。必要な項目だけ(e.g. 周波数)JSONで書いておけば、その項目だけ読み込む。周波数は2重の配列になっていて、外側の要素が複数個あればダイアログで選択できる。例えば日本のISDB-Tに合わせて40個のリスト(その中に3個の周波数のリスト)を作っておいて、そのファイルをドラッグアンドドロップすれば、特定のチャンネルを受信できる。サンプリングレートもJSONから指定できるけど、このソフトは接続時にしかサンプリングレートを読まないので、サンプリングレートの変更を含むファイルは再接続する必要がある。

　データレートの表示を追加。300kspsや1024kspsではその2倍のデータレートが表示されているけど、3.2Mspsは少し低めに出ている。

　3.2Msps、3.0Msps、2.8Msps。ヒストグラムが変な形。

　3.0Mspsは明らかにデータレートが低い。記録したIQファイルをSDR#で復調すると、3.2Mspsと2.8Mspsは正常に聞こえる一方で、3.0Mspsは明らかに再生速度が早い。ただ、ブツブツ途切れるわけじゃなく、単に再生速度が少し早い程度。rtl_tcp.exeのログを見ると3.0Mspsでも3000000.178814spsに設定されているのだが。

　librtlsdrのサンプリングレートの設定は単純に一定の範囲(225k-300ksps、900k-3.2Msps)に入っていればOK、それ以外はinvalid sample rateエラーになるだけだから、正常には動作しない設定でも一見動いているように見えるのかも。

*

　1090MHzの受信。とりあえず3分程度受信して、振幅復調して0.1秒毎の最大値をグラフ化。

　2.0Mspsと2.56Mspsは感度に若干の差はあれど大きく違うわけではない。3.2Mspsは明らかに振幅が低い。傾向としてはサンプリングレートにかかわらず同じようなデータが得られている。

　時間分解能を0.1msでグラフ化

　最初のパルスの位置を合わせているけど、だんだん時間がずれる。3.2Mspsを0.991倍くらいにすると位置が合うので、実際のサンプリングレートは3.171Mspsあたりかな?

　rtl_tcpで設定したサンプリングレート(exact sample rate)と実際のサンプリングレートがずれるの、どう解決するのがいいんだろう。十分に信頼できる信号源があるならそれをサンプリングして位相を追っていけばサンプリングレートも決定できるだろうけど、その信号源をどこで確保するか。

*

　モニタ機能を追加中

　……またこいつISDB-Tで遊んでるよ。。。

　上の三角形の波形がガードインターバルの相関値、下がOFDMのコンスタレーション(SPで等価後)。

　ヒストグラムの白い菱形のマーカーが信号の飽和レベルを示している。マーカーが一番下に落ちていれば飽和していないが、マーカーが上がってくると飽和したサンプルが含まれていることを示している。

　OFDMって少しでも飽和すると急にEVMが悪化するんだな。ここまで敏感だとは思わなかった。ほぼリアルタイム(1Hz)に見れるので、いままでのIQファイルの復調では気が付かなかったことが見える。もっとも、処理速度が遅いのでフルセグ全体(3x 2Msps)のリアルタイム監視はできないけども。

　ガードインターバルの相関値のピークが移動しないように調整すれば1ppm以内には追い込める。ただ、ガードインターバルの相関は計算コストがかなり高い。通常の受信時にはガードインターバルの相関処理は不要だから、専用の計算リソースを割かないといけない分で効率が悪い。

　パイロット信号(SP)を使えばOFDMシンボルを追跡できるので、適当にフィードバックしてやれば28.8MHzを送信所のルビジウムに同期できるはず。ただ、いまのところ1フレームをまとめて処理しているから、0.2秒単位(帯域幅2.5Hz)程度でしか処理できない。まあ、一旦フレームに同期すれば以降は1シンボル単位(帯域幅1kHz)で処理できるわけだが。

　ただ、そこまでして精度を稼ぐ意味があるかというとな。サンプリングレートが最大でも2Msps程度(ISDB-Tを受信する場合)だから、サンプリングレートの精度は0.5ppm程度にしかできない。そもそもクロックの補正も1ppm分解能だし。

*

　比較演算子の連結(if (0 <= hoge < 10)みたいな文法)、Pythonとかで使えるらしいけど、なんでこんなに普及率低いんだろう? 他の言語だとif (0<= hoge && hoge < 10)みたいに書かなきゃいけないから、かなり冗長。比較演算子の連結はあった方が絶対便利だと思うんだけど。

　C#のMath.Signに類する機能、引数がゼロ以外の場合の戻り値が固定されていないのが気持ち悪い。var tmp = float.Abs(hoge) * float.Sign(fuga);みたいな処理が実装依存になる。C#って実装依存とかをできるだけ減らそうみたいな設計思想のはずなんだけど、なんでこういう変な仕様が入ってるんだろう?

　途中で不注意で100KBくらいのファイルを秒50個くらい同名で上書きするような処理を走らせてしまって、OSレベルで動作が遅くなってめっちゃ焦った。AFOPで遊んでたときに遭遇したOSハングアップと似たような挙動な気がする。

　このPC、CドライブがNVMeのRAID1(チップセット処理)なので、細かな書き込みが大量に発生するとディスクアクセスにかなり大きなペナルティが発生するような傾向がありそう。

　また別件で、Visual Studioのエディタの中に巨大なテーブルを貼り付けて、めちゃくちゃメモリ食われた。

　64GBも乗せておいて99%まで食われるなんてな。仮想メモリに退避されるのでディスクアクセスが大量に発生して、ものすごい動作が遅くなる。

　RAM、4スロットの内2スロットしか使っていないので、128GBまで増設はできる。さすがにそんなに使わんやろ……と思って64GBしか積んでないけど。DDR4だし、メモリキットが市場にあるうちに買っておいたほうがいいかな。生産中止になったりして在庫がなくなると4本丸ごと買わなきゃいけなくなる。今なら2本買うだけで済む。欲しいものリストがどんどん積み重なっていく。

小ネタ

　XRISMのマイクロカロリメータを製造したのはNASA GSFC。

　GSFCとスミソニアン博物館ってかなり近いんだな。スミソニアン天体物理観測所の初代館長も努めたラングレー氏が活動していたのがこのあたりのはずだけど、ラングレー氏はボロメータの開発も行っていた。ボロメータを小型化したのがマイクロカロリメータで、ほとんど同じ場所で150年近くも開発が続けられてるんだな。/* 映画とかでよくCIA施設として出てくる「ラングレー」もスミソニアン博物館からほど近い場所だけど、ラングレー氏とは無関係のはず */

　PCの表示領域が狭く感じるようになってきて、4K液晶1枚追加したいなと思っている今日このごろ。メインに23.8"4Kを置いてサブに23"FHDを置いているので、このFHDを4Kに変えたい。ただ、24"くらいの4Kってほとんど選択肢が無い。メインで使っている液晶と同じ機種を中古市場で買おうかな、とかも思ったり。

　ドローンのローターで、プロペラのパラメータをちょっと広めに取った製品ってないのかな? 例えば先端部分を切削して個体ごとにkgf/rpmを少しずらすとか。1機のドローンで複数枚(大型のドローンだと8枚とか)のプロペラを使う場合に、それぞれのプロペラで同一の推力を生むのに必要な回転数が異なるから、可聴域のスペクトルを分散させることができるので、静音化ができそう。あるいは、切削加工を行うわけだから、ダイナミックバランスや回転軸と推力軸のオフセットを軽減したプロペラも作れる。機械振動が減って良さそう。

　とはいえ、大型のドローンだとモーターを背中合わせに2個積んでペラを同軸に2枚みたいな形になるから、それだと制御で回転数を分散させられるんだよな。上のモーターは早めに回して下のモーターは遅めに回して1組で発生する推力は一定を維持して、各組毎にずらし方を少しずつ変えて、みたいな感じで。そもそも必ずしも各推力点毎に推力をバランスする必要もないわけだし。とするとわざわざペラの特性を変えるまでもなく、可聴帯をスペクトル拡散できる。わざわざ切削してまで作るほどの利点はあんまりなさそう。

　小型の太陽電池、防災とかポータブルとかを重視したやつ、インフレータブルなリフレクタと組み合わせた製品ってどうだろう。アルミ蒸着シートみたいなやつで球面とか放物面を近似して光を集める。太陽電池の発電量は基本的に受光面積で決まるけど、ポータブルな用途だと大面積化が難しい。リフレクタで集光するなら格納状態ではかなり小さく作れる。

　太陽の向きに合わせて10分毎くらいに向きを調整しなきゃいけないのが使いづらいところ。あと、風とかの影響も受けやすい。それと、凹面鏡を作る必要があるので陽圧でなく負圧にしなきゃいけないので、何らかのフレームが必要になる(フレームを陽圧で作る手もあるけど)。

***

　1090MHz、モード3/A/C/Sあたりの復調

　1列目がタイムスタンプ(秒、ファイル先頭から)、2列目がパルス幅(マイクロ秒)。モード3/A/Cの場合は3列目にスコークを、4列目に高度(有効な値の場合)を表示している。モードSの場合はバイナリ値を表示している。

　24bitアドレスとかスコークが正しそうなのが見えていて、高度の値もほぼ同じ値が得られている。VSが0じゃないのと、Fr24とIQに多少の時刻差があるのと、モードCで送られてくる気圧は規正していない気圧なので、高度値は多少ずれた値が出ている。

　モード3/AはPRI20ms(PRF50Hz)くらいで何発かまとめて出てる。とりあえず頭の1秒程度をデコードしてみてるけど、モード3/A/Cは何回も安定して出ているので、空港のSSRが質問しているわけじゃなさそう(空港のインテロゲータはモードSだろうし)。

　ADS-B(パルス幅120usくらいでDF17)は時々出てくるけど、10秒に1個とかその程度でしか出てこないのがちょっと謎い。飛行中ってもっと高頻度に出してるはずなんだけど。

　時々、1090MHzにモードSのプリアンブルで88us前後のパルスが大量にあるんだけど、用途がわからない。

　モードCで送るギルハム(Gillham)コード、変形グレイコードで、スコーク3桁目(10の位)が0, 5, 7は高度として不正な値。あるいはD1も0固定(4桁目が偶数)。全体として、モード3/Aで送れる4096個のコードの中、モードCで送れるコードは(en.wikipediaの表に従うなら)1280個、送れないコードは2816個と、全体の7割近くはモードCで送れないコードになっている。スコークの割当でモードCで使えないコードを優先的に使うみたいな運用ってあるんだろうか? 普通のATC SSRで使う分には全く不要の気遣いだけど。

　ギルハムコードのエンコード、設計思想としてはおそらく機械式気圧高度計の1千ftの針と1万ftの針を機械式エンコーダで読み出したものだと思うんだけど、アネロイド式気圧計で10接点くらいの機械式エンコーダを回すって相当な負荷になりそうだけど、ちゃんと動くんだな。

　ギルハムコードは気圧未規正の値が送られてくるけど、計器パネルの気圧高度計は必要に応じて規正した高度値を表示するはずで、そのニードルを読み取るエンコーダも規正値を送るはずなんだけど、どういう処理になってるんだろうか。

　ja.wikipediaのトランスポンダの説明で「モード3/A」と「モード3/C」という分類があるけど、これって間違いじゃね? モード3とモードAは互換性があるから3/Aという表記になるけど、モード3とモードCは別物だから3/Cという表記はできないはず。en.wikipediaでもモードCがモード3の中に入っているような表記になってるけども。。。

　ATCトランスポンダ、東芝とか三菱電機が地上で使うやつ(インテロゲータ)を作っている話題は見かけるけど、オンボード用のやつ(トランスポンダ)の話題はほとんど(というか全く)見かけないのが不思議。日本でATCトランスポンダって作られてないんだろうか?

https://uavionix.com/downloads/IFF/IFF_Mode_5_Brochure.pdf

　トランスポンダのカタログ。無人機向けの50-100g程度のやつ。モード5まで対応。

　一部の製品で、ミリタリーユース用にモードAのX-bitの制御ができる、みたいな記述。用途は特に書いてないけど。

　モード3とモードAの違いがX-bitの使用の有無のはずなんだけど、ググってもほとんど情報が出てこない。

***

　rtl_tcp.exeのクライアントソフトを試作中。復調機能は無しで単純にクイックルックとIQの保存だけ。

　とりあえず同時に最大3chをサンプリングできるようにしてみた。チャンネルごとに共通の機能はユーザーコントロールで作ってあるから、必要に応じてコピペすれば増やすこともできる。

　サンプリングレートとか周波数は個別に設定できるようにしている。接続先(サーバーやポート)も個別に設定できる。サーバー側でドングルとポートの対応を固定すれば、クライアント側からドングルを指定できるから、例えばドングルAは広帯域の無指向性、ドングルBはVHFのワイドビーム、ドングルCはUHFのナロービーム、みたいな使い分けもできる。

　グラフは上段が信号レベルのヒストグラム、中段が瞬時のスペクトル(平均値を色で、最大値を白で、最小値を黒で表示)、下段がスペクトルの時系列。ウォーターフォールは約1px/0.1sくらいの速度だけど、サンプリングレートが違うと速度が多少変化する。

　左端が1Msps、中央が2.56Msps、左端が3.2Mspsでサンプリングしている。ゲインはインデックスで22,22,28、という感じ(このドングルは28が最大)。3.2Mspsは感度がかなり悪い。デシメーションでの処理利得が少ないからかな。

　PCの負荷が高い時(特に描画周り)に送信バッファが埋まってる感じのエラーログが出ることがあるけど、大抵は3.2Mspsでも問題なく受信できる。全体の受信処理はGUIからasyncメソッドを呼んでその中でTCPから読んでいて、そのループの中でグラフの描画も行っているから、Windows側の描画負荷が高くなるとC#の描画も止まって、受信処理も止まる。このあたりは要改善。

　あとは周波数の設定ファイルとかに対応したいな。ドングル単体だったり複数個の組み合わせだったり。

　試しに周波数とかサンプリングレートを同じにして受信したIQファイルを相互相関させてみたんだけど、全くフラットで何もピークが出てこない。もう少しなにか見えても良さそうなのになぁ。インコヒーレントって本当にインコヒーレントなんだな。とはいえ、ドングル間のクロックエラーが5ppmくらいあったとしても数十秒の1秒くらいの長さではコヒーレントなはずなんだけど。

　試しに地デジ28ch(NHK G)の上端付近(566.1MHz)を2.048Mspsでサンプリング

　短いモノポールなのであんまり強度は高くないけど。橙が明らかに周波数がズレてるな。

　上端付近(無変調キャリア周辺)を拡大

　青と緑も結構ずれてる。2.4kHzくらいずれてるかな? 2.4k/566.1M=4.3ppmくらいか。データシート曰くTCXOの初期オフセットが最大2ppmだから、経年劣化も含めれば5ppm弱ずれてても不思議ではないか。橙はだいぶ前に買ったものなので、ロット差とか経年劣化で更にズレが大きい。

　2Mspsで2kHzのズレだと2Mpts(1秒)で2000回転、1kptsで1回転。片方は256ptsくらいで相互相関すればコヒーレントかな。

　ということで、片方を2^21pts(2.1Mpts)、相手を256ptsで相互相関(横軸ミリ秒、512ミリ秒以降は負の時間の折り返し)

　14msあたりに強いピークが出てるな。

　横軸が時間、縦軸がクロックエラーで相関値を画像化

　結構きれいにピークが出る(輝度・縦軸は対数スケール)。ヒートマップで上の方にある直線はクロックエラーがゼロの行で、IQ信号のDCオフセットが見えている成分。

　FFTの長さが262kpts(2^18)でサンプリングレートが2.048Mspsなので、時間分解能は0.488us、積分時間は0.128s、周波数分解能は7.8Hz。周波数方向は±4096で±16kHzの範囲を処理して、その中で最大値を探している。

　周波数方向のスキャンはFFTのbinをずらしているけど、クロックエラーと周波数オフセットは本来は別のパラメータ。とはいえ、今回の場合は比帯域幅が狭い(0.36%)から、特に気にする必要はないはず。

　この計算にスレッドを10本並列で回して17秒くらいかかる。周波数方向は単に総当たりで探すだけなので、クロックエラーの推定値があるなら数十倍とか数百倍早く処理できる。FFT長は探索時間・周波数分解能・時間分解能に影響があるから、FFTを短くすると推定誤差が増える。ただ、500MHzに対して7.8Hzは0.0156ppm程度だから、受信機の性能(調整分解能1ppm)より明らかに過剰なので、FFT窓はもっと短くてもいい。FFT窓は主に時間軸のズレが問題になる。ただしFFT窓が長いほうがSNRを稼げる。

　とりあえず、特定のドングルを基準にして、同じ周波数とサンプリングレートで取得した波形を相関処理して、ドングル間のクロックエラーとタイミングエラーを推定できるのは動きそうな気配。計算コストは高いけど、そう頻繁に行う処理でもないし。

　なんかVLBIの信号処理じみてきたな。このドングルは何箇所かはんだ付けすれば複数の受信機でコヒーレントに受信できるので、電波干渉計も作れるわけだが。適当に運動量があって、それなりに帯域幅が広くて強度の強い電波源か…… そんなに都合の良いものがあるかな。。。

　ちなみに、FMラジオを1Mspsで相関するとこんな感じ

　何も見えない。256kspsでも似たような結果。シングルキャリアは相互相関を取るには使えなさそう。

*

　C#のユーザーコントロールで(int?, double?)みたいなプロパティを作ると、デザイナが変な初期化コードを書いてビルドエラーになる? 自動生成コードを手動で書き換えてやれば一応ビルドは通るけど、気持ち悪いし、次に自動生成が走ったらまたエラーになるコードが生成される。

　タプルとかレコードが駄目なのかな? タプルだと型の判定がミスって、レコードだとプロパティにそれぞれ初期値を入れようとしてinitに値をいれるからコンパイルエラーになる。

　タプルのプロパティを自分で{ get; set; }に上書きしてやれば、一応コンパイルは通るようになる。クラスで等価判定とか色々自分で書くよりは、レコードを上書きするほうが楽かな。

　ユーザーコントロールの仕様をゴリゴリ変えながらフォーム側も同時並行で作っているからか、デザイナー周りに変な挙動が出て困惑してる。イベントハンドラの登録が、VSのGUIで登録したものと、そこから生成されたコードで登録している先が違うとか。

小ネタ

　amazonで「買っておいたことにする」みたいな機能が欲しいなとか思ったり。普通に購入して支払いもカードなりポイントなりで決済するんだけど、1ヶ月くらいamazon倉庫に置いておく。「近い内に(遅くとも2,3週間程度で)また買い物するはずだからそのときにまとめて送って」的な。あとでまとめて注文すればいいだろ、という話ではあるんだけど。

　夜中に裏山を歩いていたらフクロウに遭遇した。全くの無音で飛んでくるので結構不思議。飛び立ったあとに枝のひずみエネルギーが開放されてカラカラ鳴る程度。よくよく耳を澄ますと少しだけ羽音が聞こえるかな、くらい。生き物らしい音が全くしない。そりゃ不吉の象徴とか言われるわけだ、みたいな納得がある。

***

　STM32G031J6Mで1-Wireデバイスの制御。一時期秋月で売っていたチップ。

　今回はTIMで作ってみた。ch3でPWMを出して送信、受信時はch4でパルス幅を計測する。あんまりスッキリしないけど、一応1-wireに必要な機能はストロングプルアップも含めて実装。ストロングプルアップはEXTIとか割り込みが必要かと思ってたけど、結果的には非常に簡単に処理できた。

　今回はRTOSは乗っていないのでポーリングで処理している。DMAを使えば1バイト分の転送とかをまとめてハードウェアで処理できるだろうけど、DMAで処理するのは結構面倒な気がする。特に送信用のARRとCCR3はメモリtoペリフェラル、受信用のCCR4はペリフェラルtoメモリだから、少なくとも2本のDMAが必要になる。タイマとかDMAの同期とかも考えるとなかなか大変そうだ。

　STM32はGPIOをオープンドレインとプッシュプルで使えるので、オープンドレインで使えば外付けのダイオードが不要になる。また、プッシュプルに設定すればストロングプルアップとしても使える。ということで、最終ビットの立ち上がりエッジでGPIOをODからPPに切り替えれば、ストロングプルアップとして使える。ただ、ストロングプルアップ直前の1バイトはファンクションコマンドでマスターから送るだけだから、ODである必要はない。ということで、最終1バイトを送る前にPPへ変更している。1-WireにI2Cのクロックストレッチみたいな機能があるとちょっと困ったことになる。まあ、そういう機能はないはずなので、PPで送信しても問題ないはず。

　タイマはch3が出力、ch4が入力で、どちらも同じピンに割り当てている。ただ、STM32CubeMXでは一つのピンにタイマの出力と入力を同時に割り当てることはできないから、この部分はユーザーコードで初期化している。

　窓の外に置いたプローブで計測

　1dC/div、1hour/div、左端が22時過ぎあたり。夜中なので直線状に温度が下降している。開始後2時間目あたりから1時間ほど温度が上がっているけど、ここは窓を開けていた時間。少し隙間を開けていた程度だけど、かなり影響するな。5時頃から温度降下が止まっているが、太陽が出てきたからかな。9時頃から急激に温度が上昇しているけど、天気が変わったりとかかな? 温度センサだけ見ても面白いけど、他のセンサも欲しくなるな。

　ハードウェアはこんな感じ

　SOP8変換基板にSTM32を実装して、裏面に8x8のユニバーサル基板を貼り付けて、そこにSOT-89のレギュレータを乗せている。FT232系チップでUSBから5Vを取って、マイコンからはUARTの送信だけ。SOP側から出てる2本の端子はプログラムの書き込み用のSWD端子。

　1-Wireデバイス側は一応3線式(GND, DQ, VDD)の接続にも対応しているけど、今回は2線式(GND, DQ)のセンサを接続している。というか、3線式ならFT232に直結できるので、わざわざマイコンを挟んで温度を測る必要もないしな。。。

　小さいパッケージのSTM32

　ブレッドボードに乗せるならこのあたりが楽で良い。QFP48だと変換基板が2列の四角形になるのでブレッドボードに載せられない。まあ、基板作れって話なんだけど。。。

***

　気まぐれに、ワンセグチューナーで1090MHzを2Mspsで受信。

　なんかそれっぽい信号が見えるな。

　1000あたりは1.45us周期で15個のパルス位置があるので、Mode 3/A/Cの信号っぽい。Mode 3/A/Cはコードや高度が送られてくるけど、どっちが出てくるかは下から見てるとわからないのがな。

　3000あたりのやつはMode Sだと思うけど、波形が変な形。おそらくクロックエラーでパルスを分離できていないだけだと思うんだけど。位相を見てみると、63kHz(58ppm)くらいの角速度。RTL-SDR blog v3ドングルがそこまでずれることはないだろうから、大部分は送信側のクロックエラーのはず。

　Mode Sってどの程度の周波数エラーが許容されてるんだろうか? 2Mspsみたいなことをやらない限りはクロックエラーはある程度広く許容できそうな気がするし、飛行機みたいに温度環境が厳しい場所でこれだけ大量に普及させてるんだからある程度広く設定してあるはず。そうするとワンセグチューナーベースのADS-Bのデコーダがどうやって処理しているのかが謎いけど。

　古い資料だと、モードSの周波数の許容偏差は15000ft以下のみを飛行するなら±3MHz、これを超える場合は±1MHz、ということらしい。最近だと±1MHzに統一かな? 専有帯域幅が10MHzを超えるようなシステムなので、許容偏差もそれに応じて広め。そもそも帯域幅2MHzとかの受信機で受信する信号じゃないからな。。。

　別のサンプル

　位相の回転はほとんど無い。しかし相変わらずパルス位置の復調がうまくいかない。

　更に別のサンプル。rtl_tcp.exeが3.2Mspsくらいまで取れることがわかったので、試しに3.0Mspsでサンプリングしてみた(3.2Mspsだと2.048Mspsとかに比べて感度が低い気がする。デシメーションで処理利得が稼げないからかな。いちおう、rtl_tcp.exeではエラーログは出ず、FMラジオを復調すれば途切れずに聞こえるから、3.2Mspsが通っているはず)。

　さっきよりはマシ。ちゃんとパルス間が0付近まで落ちてるし、プリアンブルの形も綺麗に見えてる。

　試しにいくつかのサンプルを機械的にデコードしてみると、1個だけCRCが0になる(誤りが無いと考えられる)パケットが見つかった。DF17, CA5で、ICAOコードをFr24で検索するとちゃんと家の近くを飛んだログがある。ということで、正常にデコードできていると考えられる。

　ただ、大半のパケットはCRCが0にならない。ビット位置がずれると正常に復号できないので、0.3bit幅ずつ数ビット分の幅をずらして総当たりでデコードしても、復調率は改善しない。開始位置のオフセットとクロックのオフセットで2次元のfor回してスキャンしたりすればあるいは……

　短いパルスは3/A/Cの応答として復調すると、Fr24に記録されているSquawkと同じ値が時々出てくる。値は4箇所くらいに固まっているかな。普通民間の飛行機1機からはA/Cの2つの値が出てくるから、4個のグループがあるということは2機が飛んでいたということになる。ただ、Fr24のログだと航空機は1機しか記録されていない。もっとも、家のエリアはMLATは非対応だろうし、A/Cしか出していない機体(ADS-B out非対応機)が飛んでいた可能性は捨てきれない。

　1機(特定のICAOアドレス)から送られてきたMode Sスキッターの位相をグラフ化してみると、傾向として位相回転は見えるけど、一貫性はあまりなさそうな感じ。送信機は今の時代にわざわざインコヒーレントに作る意味もないだろうし、水晶を逓倍して1090MHzを作ってゲートを通してからHPAに通して送信、みたいな回路だろうから、ある程度の安定性はあるはずなのだが。もう少し高いサンプリングレートで見れば安定して見えたりするんだろうか?

　位相回転は送受信間の周波数オフセット(DC成分)に距離変化分のドップラー成分が乗っているはずだから、パルスの位相変化を見れば最接近の検出ができないかな、とか思ったんだけど。

　うちのあたりは飛行場からも遠いし、その飛行場も便数がさほど多くないので、ATC SSRを受信するにはあまり条件が良くない。サンプルデータを集めるのも一苦労。

　手軽にADS-Bを受信して遊ぶなら、ワンセグチューナーを3Mspsで走らせれば良さそう。もうちょっと簡単にデコードしたいなら4Mspsくらいあると安心だけど、とはいえそうするとAirspy miniあたりが必要になるので、ワンセグチューナー系の5,6倍くらいの値段になる。まあ、1回買えばしばらくは遊べるから思い切って買うという手もあるんだけど。ただ、おそらくAirspy系のドングルはlibrtlsdr(rtl_tcp.exeとか)からは触れないので、他の方法を考える必要がある。SpyServerでネットワークに接続できるけど、これは独自のプロトコルで、データを圧縮していたりするらしいから、触るのが面倒くさそう。SpyServerのOSSクライアントもあるらしいから、それを参考にクライアントを作るという手もあるけど。SpyServerはRTLドングルにも対応しているらしいから、とりあえず手持ちのドングルでSpyServerを起動して使えるかどうか確認して、使えそうならAirspy miniを買う、みたいな手もあるか。

　ADS-Bは世界各地で受信できるデジタル変調だけど、デジタル復調の遊びとして使うにはあまり向いてないかな。そもそも変調方式の情報もほとんど見当たらないし、ちゃんとした資料が必要ならICAOから買わないとだめだろうし、個人で買えるようなものでもないだろうし。デジタル復調で遊ぶならワンセグとかを復調したほうが楽しい。いちおうワンセグとかフルセグは英語版のドキュメントが配布されているし。フルセグの方は基本的に暗号化データだから、復調後にエラー率を見たりして動作確認は行えるけど、復調したデータを見れないのが残念なところ。ADS-Bは一応は意味のあるデータが出てくるからな。ADS-Bはシングルキャリアのマンチェスタ符号、ISDB-TはOFDMで処理内容も全く違うから、そもそも比較対象でも無いんだけど。

*

　軍用機(戦闘機とか)によく積んであるA/A TACANって飛行機間の距離を測定する機能だけど、Mode 3 XPDRでも距離は測れるわけで、軍用機で測距にMode 3を使わない理由ってなんだろう? TACANはチャンネルを設定できるけど、Mode 3だってコードを設定できるわけだから、周波数分割を使うか符号分割を使うかの違いでしかない。Mode 3だとATCに見えちゃうから、みたいな理由なのかな。そもそも軍用機には元からナビゲーション用にTACANインテロゲータが積んであるんだから、Mode 3を使うかTACANを使うかはどちらでも良くて、自由度が高いTACANを使った、みたいなことなんだろうか。

小ネタ

　20ftコンテナフォームファクタの折りたたみ太陽光発電システム。広げると120mくらいの長さになる。傾斜なしで平面に設置だから発電効率は若干ペナルティがありそう。長期間設置するなら手間をかけてでも既存のシステムで作ったほうが良いだろうな。駆動系統とかでコストも掛かるだろうし、展開したらレールとかも下に残るから、一緒に設置する他のコンテナに流用するみたいなこともできないだろうし。スポット的な需要には良さそうだけど、とはいえそのスポット的な需要の期間に綺麗な晴天を期待できるかというとまた別の話だし。20ftコンテナフォームファクタの蓄電システムと組み合わせて、需要の数日前に搬入して蓄電しつつ、当日の需要は蓄電したものを使って、みたいな感じになるか。

　AZKiと石神のぞみのドライブvlog概念。ツッコミ不在のギャグ大連発激オモロ動画。地理とか地図とかドライブとかが好きそうな人たちなので面白そう。

　リコリスのワッペン、サードのやつ出してくれないかなー。FDEとかタンとかマルチカムみたいなベースに合いそう。

　DJIのドローンとか、特に小型なやつで、そろそろボールとかフリスビーみたいに投げたらそのまま浮かぶ機能が欲しいよね。いちいち地面から離陸させなきゃいけないのが古くせー感じがする。バックパックから送信機を取り出して電源をON、続けてドローンを取り出して電源を入れて、ペアリングでき次第スナップを効かせて投げたら、そこで浮かんでてくれる。近未来の世界観のドローンってこういうイメージなんだけど、未だに何十年も昔のラジコンヘリみたいな離陸の仕方しかできない。フェイルセーフとかセンサのキャリブレーションとかいろいろ理由はあるんだろうけど。

　家に設置してあるストーブが操作しづらいとのことで、ためしに分解。めっちゃ分解しやすいな。順番にネジを外していくだけ。価格/質量と修理性レートは大部分で反比例しそう。密度が高いとネジを使わず接着したり、密度が低ければ組み立てのときの余裕も大きいし。

　操作部のPCBを取り外して観察。問題のスイッチは2本足のタクタイルスイッチだった。4本足しか持ってないや。ということで、別の操作(時計とかタイマーの設定用、全く使ってない機能)のスイッチと交換。とりあえず必要な操作は正常に戻ったかな。今シーズンはもう使わないだろうし、気が向いたら合いそうなスイッチを買って在庫しておこう。

　2本足のタクタイルスイッチは秋月でも売ってるけど、秋月のは高さが5mm、PCBに乗ってたやつは4.3mmくらいだった。ちょっと高さが違う。高い分には削ればいいし、低い分にはテープか何か貼ればいいんだろうけども。

　'12年製なので10年くらい使っていて、1年の1/3で稼働していたとして、1日に10回操作したとして、1万回くらい押されているスイッチ。1日に10回も押さんだろとか稼働時期の端は少なくなるだろと考えると、もう少し少ないかな、といったところか。家のあたりは温泉地というわけでもないし、秋月で売っているやつが10万サイクルくらいのオーダーであることを考えると、もう少し長持ちしてほしいところ。/* メーカー曰く設計寿命は8年とのことだから、製品本体の設計寿命は十分に超えている */

　NTTだかプロバイダだかを名乗るところから電話があった。

　曰く料金プランが変更になるので手続きを行うと安くなる、大きな手続きは必要ない、なるべく早く手続きをやってくれ(そのほうが早く安くなるから)、という感じ。手続の内容を軽く聞いてみたら、電話相手が3,4回たらい回しにされるから先々で従ってくれ、あと現在契約中のプロバイダの解約(or契約変更)手続きを行ってくれ、とのこと。おい。

「今は時間がないから後で手続きをしたいのだが、手が空いたときに電話したい」旨を伝えると「こちらの電話番号を教えることはできない」だそう。まともな会社なら問い合わせ窓口くらいあるだろうよ。。。

　うーん、詐欺っぽ、と思って通話終了。大事な手続きならまたあとで電話来るだろ…… そういう心理をついて詐欺業者が繰り返し電話してきてもまた困るんだけど。

***

　STM32F303K8で定電流回路

　外付けのNch MOSFET(とりあえず手持ちのIRLB3813PBF)をオペアンプでドライブして、ソースを1Ω5%の抵抗で電流計測。オペアンプでフィードバック制御して、電流指令値はDACを分圧して入力。電流センスは0.1Aで0.1Vになるので、12bitのADCで125binくらいにしかならない。本来であればPGAで増幅したいところだけど、303K8の唯一のOPAMPはフィードバック用に使用しているので使えない。

　安定化電源を接続しているので電圧は一定のはずだけど、ブレッドボードの接触抵抗でだいぶドロップしてる。

　とりあえず三角波の指令値を出していて、平均するとFETは0.56Wくらいの消費電力になる。この程度でも触るとほんのり温かいな。

　適当な定抵抗負荷(100Ω5%を2本並列＋470ΩのLED)

　電流指令値に対して飽和している(電圧に対して抵抗が大きい)。

　電流(縦軸) 対 電圧(横軸)

　きれいな直線状。傾斜の傾きからして抵抗値は34Ωくらいか。実測値は49.8Ωくらいなのでかなり低く出ている。

　死んだNi-MH電池がたくさんあるので適当な電子負荷を作って特性を測ってみたいなとか思ったり。STM32F303K8はVINMが1本しかないのでCC/CVをハードウェアで組むことができないから、CC専用の負荷でCVはソフトウェアで実装みたいな感じになるのかな。電池の放電試験くらいならソフト実装の帯域幅(250Hz前後)でも十分じゃろ。あるいはシャントからPGA(x16)に通してADCで計測して、CC/CVどちらもソフトウェアで制御するみたいな方向性もあるか。

　ある程度の電流を引きたい場合、安い電池ボックスだと接点容量の心配がな。マルツ(DigiKey)でkeystoneのアルミ板金のいかにも大電力対応みたいな見た目のやつも売ってるけど、さすがのお値段。樹脂製の安価な電池ボックスの20倍くらいする。

　タミヤの電池ボックスって性能どんなものなんだろうか。細い針金でコイル作ってるわけじゃないからそこそこ抵抗低そうな気はするのだが。それを試すための電子負荷か……

***

　簡単なテストコードをCortex-M4で走らせてみた。

　こんな感じのコード

uint32_t start, end;

__asm__ volatile(

    R"(

      mov r12, #128

      ldr %[start], [%[CYCCNT]]

      .balign 8

      # ↓ NOPの数を調整

      nop

      nop

      nop

      nop

      nop

      nop

    label6:

      subs r12, #1

      bne label6

      ldr %[end], [%[CYCCNT]]

 )" : [start] "=r"(start),

      [end] "=r"(end)

    : [CYCCNT] "r"(&DWT->CYCCNT)

    : "r12");

printf("6 %lu\n", end - start);

　インラインアセンブリで単純なループをさせる。経過時間をDWT.CYCCNTで計測。ラベル前のNOPの数を変えて走らせる。ここで、NOPは16bit命令へ変換される(32bitのNOPが欲しい場合、nop.wを指定する)。PICマイコンとかだとNOPは1サイクル分の「何もしない」命令になるけど、Cortex-Mの場合、NOPはそのまま実行されることもあるし、実行されないこともあるらしい(実行されないというか、パイプラインに取り込まれずにスキップされる)。NOPは「何もしない」というよりは、「後続の命令の位置を動かすためのパディング」くらいの感じらしい。ということで、今回のNOPの使い方は本来(想定)の使い方ということになる。

　で、結果は、

　というような感じ。NOPの数が4でmod取って0と1が最小、2と3で処理時間が増える、という感じ。16bit命令4個で1サイクルなので、64bitが1周期となる。

　今回はカウンタをデクリメントするだけの一番小さなループだから効果が大きく出ているけど、命令のアライメントはそれなりに効きそう。gccのインラインアセンブリなら.balign nで次の命令のアライメントを指定できるから、パフォーマンスがほしいループなら.balign 8とか指定すると良さそう。ジャンプ先のアライメントはループ数に比例して増えるのに対して、balignで挿入されるNOPはループ数に反比例して影響が減るから、ループが小さく回数が多いほどbalignでアライメントするほうが有利になる。ただ、同じCortex-M4でもチップによって(F3とG4とか)フラッシュの帯域幅が違うらしいんで、ターゲットによってアライメントを調整したほうがいいかもしれないけど。

　処理時間はsubが1サイクル、bが最大4だから、計算上は最小384、最大512程度のはずなんだけど、明らかに遅い。命令に要するサイクルはあくまでもスムーズに流れたときに最短でこの程度、という感じなのかな。

STM32G4のFDCANでチョット遊ぶ

　STM32G4のFDCANを軽く触ってみた。

　FDCAN1とFDCAN2を有効化、GPIOはAF_ODで初期化して、47Ωでプルアップ。ボーレートは250kbaudと2.5Mbaudに設定。FDCAN1から送ってFDCAN2で受信。

　ドライバ無しのCANネットワークはArduinoとか小規模なマイコン(回路)でTXをダイオードORして1本にまとめてRXへ分配するのと同じような考え方。

　試しに、標準、FD(低速)、FD(高速)、標準、FD(低速)、FD(高速)、FD(低速)、FD(高速)、という8個のパケットを送信。

　オシロで見ると、ちゃんとボーレートが切り替わっているのが見える。ジャンパワイヤを何本か飛ばした程度であれば、オープンドレインの470Ωで2.5Mbaudは問題なさそう。もう少し早く(or容量が大きく)なるとちょっと厳しいかな。抵抗値は220Ωくらいまでは問題ないと思うけど、あんまり小さくしてもねぇ。ちゃんと使いたいならドライバ入れろって話だし。

　SiglentのオシロはCAN 2.0Bまで対応かな? CAN FDはデコードできない。ただしCAN FDのパケットは単にエラーになるだけで、ほとんどの場合はそれに続くCAN 2.0パケットは正しくデコードできる。CAN FDでは2.0のリモートフレームで8バイトを超えるデータ数を要求できるけど、Siglentのデコーダではこれはエラーとして処理している。

　プロトコルトリガはスタートならFDにもトリガがかかる。プロトコルトリガ自体はたぶんFPGAとかで簡易的に処理しているはずなので、データ流しっぱなしにすれば画面更新レートも非常に高い(デコーダは追いつかないけど)。

　IDとかでトリガすることもできるけど、操作性がかなり悪い。まあ、このオシロはデフォで操作性が悪いので、プロトコルトリガだからという問題ではないのだが。Siglentのドキュメントを読むとTelnetでCANバストリガ関係も設定できるんだけど、試しに叩いてみても反応しない。

　LAP-Cは一応CAN FDにも対応。ただしCAN FDを使う場合はBRSのON/OFFが混在していると正常にデコードできない。一旦エラーになると多くの場合で後続のパケットも巻き込んでエラーになる。BRSのON/OFFを混在させなきゃいけない状況というのも特に思いつかないので、実用上は問題ないのかもしれないけど。

　LPA-Cのプロトコルトリガは結構手抜き実装な感じがあるな。LAP-C Proだと改善してるのかな? /* LAP-CとLAP-C Pro、当初は併売してたけど、もうLAP-Cは売ってないんだな。価格帯が全く違うから、電子工作用のロジアナとしてZEROPLUSはもう高級品だ */

*

　STM32G4のFDCANで、CAN 2.0BとCAN FDを混在させた時に、時々CAN FDの長いパケットの後ろがゼロ埋めになることがある。

　例えば受信結果は

     635 12 ESI0 BRS0 CLS     0 63 1  RMT

0000019F 64 ESI0 BRS0 CLS     0 63 1  DAT: 70 D7 5D D6 95 8E 47 8A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0BB80000  3 ESI0 BRS0 CLS     0 63 1  RMT

000006E7  4 ESI0 BRS0 CLS     0 63 1  DAT: C6 E7 3E 20

　みたいな感じになる。

　その区間をオシロで見てみると

　前後のId635やId0BB80000は正しく見えているけど、Id0000019FはBitRateSwitchがOFFで64バイトなのに、明らかに短い。

　起動時直後に頻発するような印象。少し送信してると問題なくなる感じ。

*

　G4のFDCANはTIM3と連携して、送信時と受信時のTIM3のカウント値を記録する機能がある(FDCANに内蔵したカウンタも使えるけど、BRS ONだとtickの長さが変わるので、with BRSで使うならTIM3が必要)。受信側は受信時のタイムスタンプが得られるけど、送信側はあくまでも送信したタイムスタンプを後で読み出すことしかできない。STM32F1のbxCANではSOFのタイムスタンプ値を8バイトの末尾2バイトに埋めて送信する機能があるけど、G4のFDCANではそういう機能は無いはず。

　例えばTIM3のtickを16us(170MHzならプリスケーラ2720)に設定してやれば1.048秒で1周期になるので、GPSの1PPSでTIM3をクリアすれば、あるパケットを送信した時刻をUTCに対して16us秒の分解能で計測できる。続くパケットで「さっきのパケットはUTCで何マイクロ秒の時刻でした」というのを送ってやれば、受信側でも1個目のパケットの受信時刻を計測しておいて、続くパケットに含まれる時刻情報と1個目の時刻を比較してやれば、UTCに対して良い精度で自分のカウンタを同期できる。差を微分すればUTCに対する自分のカウンタの速度差も計測できる。

　このタイムマーカーパケットはあくまでも送受信間でタイマを比較するために使うだけ(決められた時刻ピッタリに送る必要はないもの)だから、破棄されない程度の優先度であれば良いので、大きなパケットが流れているバスでも時刻比較に使うことができるはず。ただしルータを通すとディレイやジッターが増えるから、ルータを使うのであればルータ自身が時刻決定を行ったうえで、下位のネットワーク(タイムサーバーから遠い方)へ伝播させる必要がある(ジッタはルータ1段ごとにランダムに増えていく)。

　ランダムなパケットを送りつつ、タイムマーカーを送るテスト。

　Std123h DLC0が基準パケット、Std123h DLC2が基準パケットを送信した時刻を送るパケット。ランダムなパケットはFIFOの空きが1より多い場合に送信しているから、タイムマーカーを割り込んで送ることができる。

　受信側はStd123h DLC0のパケットを受信した際のタイムマーカーと、Std123h DLC2で送られてくるタイムスタンプを比較して、時刻サーバーと自身の時刻差を求めることができる。あるいは、Std123h DLC2だけを送って、前回のStd123hのタイムスタンプを送る、みたいな運用でもいい。ただしこの場合はStd123hを送る間隔分、タイムスタンプ値を得るまでの遅延が発生する。

　また、TIM3のリセット(外部入力で蹴られる)をトリガから出力して、TIM2で受ければ、外部から入力された1PPSの数をカウントできる。適当な原点からの経過時間をGPS基準で32bitの秒と16bitの分数で表現できる。今回の場合だと分解能16usで130年程度(ほぼ47.93ビットレンジ)を計測できる。例えば1970年1月1日0時からの経過秒数とか、1980年1月6日0時からの経過秒数とか。ロールオーバーが気になるならシステム起動時とか任意の時点を原点にしてもいいし。

　タイムマーカーのパケット(Std123h DLC0)を送った時刻を、32bitの秒と16bitの分数の合わせて8byteとして送信している(8バイトに収まるのでCAN 2.0で送れる。もちろんCAN FD with BRSで送ったほうが短く遅れるけど)。

　今回はTIM3のクロックソースにコアクロック(外付け水晶を逓倍したもの)を使用しているけど、GPSから10MHzを受けられるのであればそれを使うのが一番精度が出る(10MHzである必要はなくて、今回の場合であれば62.5kHzの整数倍であればいい)。

　STM32G4のFDCANを使えば、かなりシンプルな方法で広い範囲に正確な時刻を共有することができる。

*

　CAN/CAN FDは車載の安全要求の厳しい環境で使う前提だからか、STM32G4のFDCANは、他のSTM32のペリフェラルとはだいぶ雰囲気が違う。ビットフィールドが中途半端な位置に配置されていたり、あるいはリファレンスマニュアルで一切解説されていないビットが定義されていたり、いろいろと謎い。外部のガイドラインみたいなものに従って実装してるのかな?