【反省ポーズ?】NEXUSのFMR(フライト・マネージメント・レシーバーと呼んでいる,コマンド受信用マイコン等から成るサブシステム)は,NEXUSのシステムの中で一番偉いサブシステムで,通常は,地上局から「〇〇時間後に〇〇をしなさい」といったコマンドはFMRが基本的にはさばくそうです.

つまり,例えば,「5時間後にC&DH系のマイコンをONにしなさい」とか,「8時間後にトランスポンダーをONにしなさい」とかいったコマンドを送ると,FMRが時間を管理して,ONにするそうです.

で,・・・ 今回,C&DHをONにして,センサーデータをメモリに保存し始めてから,9時間後にC&DHをOFFにする,というコマンドを打ったそうなんですが,なぜか,1.7時間くらいでOFFになっていて,1.7時間分のデータしかメモリに保存されていなかったと・・・

となると,「さて,こうなる原因として,どんなことが考えられるでしょう?」っていうようなテスト問題を出したくなりますよねえ.

で,結論としては,3.5時間くらい以上先のことを予約するコマンドは打てないそうで(打っても,実行する時間がおかしくなるだけ)・・・ 本当は,932時間先まで,予約コマンドが打てる仕様にしてあったはずだそうなんですが・・・

これ,結構,痛い・・・

例えば,8時間後に何かをしたいとしても,実際には,3.5時間後からずっとそれをやり続けるようにしておく(つまり,3.5時間後にONして,そのままの状態にしておく)しかないということのようで・・・

これだと,例えば,トラポンのように消費電力が大きくて,1時間弱しか動かせないものを8時間後に動いている状態にするのは無理,ということで・・・

そうなってしまった理由が,なんか,「いやあ・・・ありそうだなあ・・・」というもので・・・ もちろん,「ああしていれば防げた」,「こうしていれば防げた」っていうような話はいろいろ出てきてましたが,まあ,ねえ.実際,コンパイルは通っていたわけでねえ・・・ 実際に,EMに「8時間後にトラポンをON」というコマンドを送って,8時間待って,実際にどうなるかを確認する,ってことをしないと,気づかなかったんじゃないかなあと. ってことは,やっぱり,長期運用試験で何をするかが大事,っていう,すご~く当たり前の結論になるわけで.

まあ,でも,ひとつ言えることは,あまり普通じゃないコードを書くと,えてしてね,ってことですね.

ちなみに,FMRのソフトは,基本的にはSPROUTのをそのまま引き継いでいるそうで,「多分,このバグは,SPROUTのFMRにもあったであろう」,ということだそうで・・・(実は,OBもこのバグもSPROUTの運用をしていて気づいていたのだろうか・・・ やはり,自分がちゃんとSPROUTのことを見ていなかったツケがこういうところに出るんですよね・・・ 反省・・・).

まあ,でも,うまく運用して,ミッション自体は続けていきましょう,というところです.