2017年3月28日火曜日

2015年7月に発生したSM-2爆発のはなし

 画像:CNNの記事より

 すこし前の話ですが、2015年7月18日に行われたスタンダードミサイル2発射試験にて、発射直後に爆発するという事故がありました。前々から気になっていたのですが、ちょっと調べてみたのでまとめです。
 僕は壊滅的に英語ができないので、変な理解で書いてたらごめんなさい。艦や兵装等についても素人なので、そのあたりも間違ってたらごめんね。



 2015年7月18日に米国大西洋岸で行われたスタンダードミサイル2 Block3A(Standard Missile-2、以下SM-2)ミサイルの発射試験において、発射直後にSM-2が爆発するという事故がありました。発射を行った艦はアーレイ・バーク級ミサイル駆逐艦のDDG-68 ザ・サリヴァンズ(USS The Sullivans)です。
 爆発による負傷者は報告されていませんが、小規模な火災が発生したとのことです。
 数週間後に掲載されたニュース記事では、ザ・サリヴァンズの修理におよそ$100k(当時のレートで約1250万円)を要するとのことです。爆発によるダメージは上部に集中しており、艦の構造に及ぶ影響は無かったとのことです。
 事故後、ザ・サリヴァンズは大西洋側の海軍基地で修理を受けており、事故後1ヶ月程度で修理は終わるようです。


 ザ・サリヴァンズはフライト1という、アーレイ・バーク級の初期に建造されたグループです(現在まで、フライト1, 2, 2Aの3種類が就役しており、現在フライト3が計画中です)。フライト1では前部甲板にミサイル発射機が29セル、後部甲板に61セルあり、このSM-2は前部左側の発射機から発射されたようです。
 アーレイ・バーク級のSM-2は垂直に発射されるため、この高さであれば、前部甲板の直上で爆発したということになるはずです。距離的には艦橋部分の直近ですが、おそらく大半の艦橋要員は直接爆発を見ることはなかったはずです(もちろん爆音には晒されたでしょうし、閃光も見えたはずですが)。
 手元にある資料によれば、アーレイ・バーク級のマストにはHF, VHF, UHFの各種アンテナと、赤外線光学系が搭載されているようです。
 アーレイ・バーク級は艦橋構造物が鋼製のため、多少の熱には耐えられるようになっています(過去の火災事故の教訓で、耐熱性が強化されています)。一方、マスト部分はアルミで作られているので、「ダメージは上部に集中している」というのは、熱や衝撃に弱いアルミには影響し、鋼で作られた船体には影響が少なかった、ということかもしれません。

 スタンダードミサイルを始めとして、現在多用されているミサイルは基本的に固体燃料ロケットを使っています。上画像でも爆散した破片が白く発光していますが、これは燃料が燃えているためです。
 固体燃料は酸素を自分で持っていることから、液状・泡状などの消火剤によって酸素の供給を停止しても、燃焼を止めることができません。燃焼にも高発熱を伴うため、冷却しての消火も困難でしょう。おそらく小規模な火災というのは、燃え残った燃料が甲板上に落下したことによるものだと思いますが、これを消化するのは非常に大変だと思います。ただし、量はそれほどでもないと思うので、燃え尽きるまでにそれほど時間は必用としなかったはずです。

 蛇足ですが、固体燃料の内、白煙を引くタイプは、燃料にアルミニウムが含まれ、高温で燃焼するタイプの燃料です。高性能な固体燃料を作るには高精度でアルミニウム粉末を作る技術が必要となります。逆に、最近は赤外線センサに悪影響を与えないために、あるいは敵から発見されづらいように、低排煙な固体燃料も使われてはいます。ただ上画像では白煙が見えており、また高温で燃焼しているので、破片が真っ白に発光しています。


 事故の原因は、SM-2に使用されているMk 104 Mod 2 デュアルスラストロケットモーター(Dual Thrust Rocket Motor)に欠陥があったとのことです。このモーターはThiokol(サイオコール、あるいはチオコール)社、現在のATKランチ・システムズ・グループで25年ほど前に製造されたものだそうです。この会社は様々な固体燃料を製造していますが、死者7名となったスペースシャトル・チャレンジャー号の爆発事故もこのこの会社が製造した固体燃料ロケットに原因の一端があります。
 このロケットモーターを使用したいくつかのSM-2は「戦時限定」の制限が加えられたそうです。つまり、平時の訓練では使うな、ということのようです。
 ミサイル防衛で使用されているスタンダードミサイル3や、新型のスタンダードミサイル6もMk 104を使用していますが、これらは異なるデザインであるため、影響は無いとのことです。

 今回はある程度の高い位置で爆発したため、上部構造物にダメージが出た程度で済みましたし、負傷者もなかったとのことです。
 しかし、もしも見張り台に人間が出ていればかなりの怪我になったはずですし、もっと艦橋に近い位置であればさらに広範囲に被害が広がっていたでしょう。もしかしたらイージスシステムの要であるAN/SPY-1レーダーにも悪影響が有ったかもしれません。
 さらに言えば、万が一、VLSセルの中で爆発した場合、艦の内側に爆風が閉じ込められ、燃え残りの燃料も艦内に残り、周辺のミサイルも高熱にさらされていたかもしれません。そのような事態になってしまえば、1960年台に発生した空母フォレスタルの火災事故のような大惨事になっていたかもしれません。
 そういう意味では、人的被害もなく、修理費も新造に比べれば非常に安く抑えられており、より深刻な事故が発生する前に問題のあるミサイルを発見し、使用に制限を出せたことは、ある意味では幸運とも言えそうです。

 この事故は同盟国で発生した事故、というだけでは済みません。アーレイ・バーク級を原型とした船は、日本でもこんごう型護衛艦、あたご型護衛艦として、現在6隻が就役しています。また、これらの艦艇にはSM-2ミサイルも搭載されています。
 海上自衛隊はあまり実弾演習を行いませんが、それでも皆無というわけではないでしょうし、有事の際にはしっかりと使える状態のものである必要があります。


 個人的に、この事故の事は気になっていたのですが、速報的に騒ぎ立ててるところはあれど、その後を書いているところは見つからなかったので、素人ながらすこしまとめてみました。最初にも書きましたが、何分英語はチンプンカンプンで防衛装備等も素人ですので、間違っていたらごめんなさい。




2017年3月26日日曜日

超音波風速計 ちょっと計測方法を変更

 久しぶりの超音波風速計ネタ。
 動作確認の手段がないので、できることが少ない。


 以前は等価時間サンプリングを使って位相を計測していたが、今回は実時間サンプリングを実装してみた。 
 

 しばらく部屋で放置していた時のグラフ。部屋の外でファンヒーターを炊いていたので若干気温が上昇傾向に有る。が、データとして有効なほどのΔtは得られていない。

 位相の計算は整数演算を使用しており、扱いとしては固定小数点演算に近いはず。整数部16bit(内1bitが符号)、小数部16bitで、小数部16bitのみを取り出して位相データとしている。16bitではおよそ4桁の精度なので、0.0001フェーズくらいまでの分解能が有る。
 センサ間150mmではだいたい0.035フェーズで1度Cあるいは1m/sくらいになるので、数字だけなら10ミリケルビン or 1cm/sくらいの分解能が有る。本当か?
 もっとも、分解能と精度は全く関係ない話であり、精度は0.5degC、1m/sくらいあればいいなーといったところ。


 等価時間サンプリングを使っていたときも、ほとんどの計算は整数で行っていたので、大幅な高速化といった利点は無い。一方で、ETS変換テーブルの220バイト程度が削減されたりとか、配置換えのループが無くなった分のメリットは得られるはず。
 とはいえ、実時間サンプリングは計測できるフェーズ数が多いから、計算量は増えているはず。


 現在はSTM32F103CBT(48ピン,ROM128k,RAM20k)を使っている。ピン数に余裕はないが足りないと言うほどではない。動作速度も、更新レートが充分に低ければ問題ない。しかし、RAMがかなりカツカツで、RTOSの機嫌を伺いながらメモリを確保しているという状況。ROMは70k程度なので、まだ3割以上残っている。
 STM32F103VET(64ピン,ROM512k,RAM64k)であればメモリにだいぶ余裕があるが、基板サイズ的にちょっと大げさな気がする。
 STBee F4miniあたり使うと楽になれるのかなーと思うけど、まだ機会がなくて買っていない。


 これから暖かくなってくると、Δtが稼ぎづらいので、今のうちにいろいろ試験しておかなければ。とはいえ、暖かくなれば外で風に当てるとか、いろいろできるようになるのだけど。

2017年3月25日土曜日

値を表すのに必用な桁数

 値を表すのに必用な桁数はlog関数で求めることができる。C言語のmath.hではいくつかのlog関数が用意されており、logなら自然対数、log10なら10、log2なら2を底とした冪指数を得ることができる。たぶん無指定なら10だろ~とか思ってlogを使うと違う結果になるので注意すること。任意の底を使いたい場合はlog10(value) / log10(base)のような計算になる。
 10進数「10」を2進数で表すのに必用な桁数は、ceil(log2(10))のようになる(ceilは天井関数)。この結果は4となり、2^4=16だから、実際に10を含むことができる。ただしこれは正数のみを考えた場合であり、2進数では上位1bitで符号を表すから、負数も扱うなら5bitが必要となる。
 10進数の場合でも同様の手順で桁数を計算することができる。「わざわざ計算しなくても、自分で考えればいいじゃないか」という人もいるかもしれないが、CPUに対して「この変数を表示するには何桁の表示領域が必用なんだい?」なんて聞くコマンドは(おそらく)実装されていないから、計算するプログラムを組む必要がある。


 ほんとうは、FIR(有限インパルス応答)を正数で計算するあたりの事を書こうと思っていたんだが、頭がまわらないので次の機会に。
 1週間ほど前はいい感じの生活サイクルだったんだけど、また夜型のリズムになってしまった。なかなか位相ロックが行えない。位相ロックループはちゃんとロックできるイベントがないとダメなんだなぁと変なところで実感したり、イベントがないとロックループじゃないだろ、とも思ったり。なんかテンションがおかしいぞ。早く寝よう。。

2017年3月24日金曜日

グラボを増設した

 今メインに使っているデスクトップPCは自分で組んだものだが、パーツを買った店の購入履歴を見ると、13年8月末に部品を買ったので、13年9月頃から使っているということになる。もう4年半か。
 ちなみに買ったのは某大手家電量販店だが、店頭で注文してもネットで注文しても一括で履歴が確認できるようになっていた。型番までわかるものは通販で買えば楽だし、詳しい店員に聞きたいなら店舗で買えばいい、という使い分けができるので便利。ま、基本的に全部amazonで買っちゃうので、amazonでは売ってないものメインになってしまうのだけど。

 で、その直後、13年9月初めにはamazonで部品を買い足して、その際にグラボを購入しているらしい。すでにこの頃はGT6xxが発売されている時期だが、この時に買ったのはGT520だった。履歴によると3千4百円程度だったらしい。

 その後、16年5月にもう一度グラボを購入している。
 最初にPCを組んだときは、とにかく安く組むということで、Core i5 3.2GHzを買っていたが、この頃はRAW現像を頻繁に行っていた時期で、いいかげん早いCPUが欲しくなり、Core i7 4.0GHzを購入し、ついでにGTX950を買った。直後にGT10xxが発売されたので、もう少し待てば値下がりしたのかもしれないが、この時の購入価格は1万9千円ほどだった。
 ちなみに、この時買ったCore i7を組んでも起動せず、その後返金サポートを受けた。あんまりIntelの初期不良というのは聞かないが、はやり量産品である以上、多少の不良は有るようだ。

 で、GTX950を組んだ後はグラボ1枚でFHD液晶2枚を接続していたのだが、今回、サブディスプレイの接続用にGT520を追加してみた。


 両方共PICe x16スロットだが、520を接続している方はバスがGen2x4レーンしか無い。それと520はGen1で接続されている?
 キャプチャ撮影時はArma 3をプレイ中で、950は約1.33GHzで動作している(キャプチャ時はArmaのレンダリングが止まってるので若干クロックは下がってる)。

 サブディスプレイはWebブラウザを置いておくか、ブルーレイプレイヤーを起動しておくかくらいしか使っていないので、あんまりグラフィック性能は必要ないので、520だろうとバスが細かろうと特に問題は無い。今のところは正常動作しているらしいし。

 なぜわざわざグラボを増設したかというと、Arma3をプレイ中に950のP Stateが8固定になっている場合があったためで、どうやらNVIDIAはマルチディスプレイに不具合があるようなので、試しにホコリを被っていた520を追加してみた、というわけ。
 PS8だとおよそ400MHz程度までしかクロックが上がらないので、本来の性能の3分の1程度しか性能が出ていない。実際、普段は60fps程度出るが、PS8のときは20fps未満となってしまい、プレイに支障が出る。
 P Stateが固定されてしまうのは決まったタイミングはなく、傾向としてOS稼働時間が伸びると固定される可能性が増える、程度のものなので、本当に解決しているかは別問題だが、とりあえず今のところは正常に動作しているようだ。


 マイコンを趣味にしていて、クロックの計算で苦労している身からすると、動作中にクロックが変わるというのはかなり恐ろしいことなのだが、GPUはいともたやすくクロックが変化するね。


 そろそろ4k液晶を使ってみたいなぁとか、思ってるんだけど、まだ手が出ないなぁ。他にも色々有るけど、それをツールにして稼いでるわけじゃないから、投資とか言って買うわけにもいかない。ぐぬぬ。でもHDDはそろそろ交換しておきたい。

2017年3月22日水曜日

JS Orbitのアップデート

 JS Orbitをちょっと更新しました。
 JS Orbit


 configのorbitLineでAltitudeを選択すると軌道の予測線がグラデーションになり、地図下側にスケールが表示されます。
 静止トランスファ軌道(GTO)やモルニヤ軌道のような、離心率が大きい場合は、なんとなくグラデーションになるのがわかります。一方、ISSのような離心率の小さい軌道ではまったくと言っていいほどグラデーションになりません。GTOのような軌道でも、思ったほど面白い表示にはなりませんでした。

 もうちょっとあちこちいじりたいところが有りますが、更新できるようになる前に飽きてしまうかもしれません。

2017年3月18日土曜日

エコースター/ファルコン

 久しぶりの軌道ウォッチです。

 スペースX、"脚なし"ファルコン9ロケットの打ち上げ成功 - 回収は未実施 | マイナビニュース

 JS Orbit


 現在のところ、近地点高度が約180km、遠地点高度が約36000km、軌道傾斜角が約22度、離心率が約0.73の典型的な静止トランスファ軌道です。
 まだ放出されて間がないせいか、衛星本体とデブリの軌道の差はほとんどありません。
 静止トランスファ軌道が、というか、離心率が大きい軌道は見てて面白いですね。どうしてこういう軌跡になるかと考えると頭がごちゃごちゃしてきますが。

 一般的にプログラムで絵を書く場合、複数の点を経由する一色の線というのはかなり簡単に書くことができます。一方、複数の点を経由する、区間毎に色を指定して線を書くというのは、区間ごとに線を引く必要があり、プログラムは若干複雑になります。また、その下で動いてるプログラムはさらに余分な処理が増えるはずです。
 という理由により、JS Orbitでは軌道全域を1色(赤色)で書いています(過去の軌道は青ですが)。
 ですが、こういう離心率の大きい軌道を見る場合は、それぞれの区間ごとに色が変わると面白いかもしれません。チェックボックスか何かで切り替えれるようにしてみるのもアリかもしれませんね。
 ふと思い出して、前にC#で作ったときのスクリーンショットを見てみると、背景色と軌道の色が混ざったり、いろいろ苦労しているようです(ソレを作ったのはドローンやら人工衛星やらを追尾できるアンテナを作った時でした。もう2年も経つんですね)。

 JS Orbitをいじるにしても、早くて来週中頃になると思いますが、とりあえず試すだけ試してみようと思います。

2017年3月13日月曜日

シャッタースピードとか


もうちょっとうまい表現方法がありそうな気がするんだけど、なかなかうまくできない。

 例えば完全に晴れた屋外で撮影する場合、Ev15あたりが適正露出となるので、Tv1/512sec, AvF8.0, ISO100あたりを設定する。
 感度を基準(ISO100)以外にする場合は、設定したISOに応じたEvを照度の値から引いて表を読む。Ev15でISOを400にする場合はEv15 - (-2)でEv17が適正露出となるから、Tv1/512, AvF16, ISO400や、Tv1/2048, AvF8, ISO400のような設定になる。

 晴れた満月の夜に撮影する場合、照度は-4で、感度を上げてISO3200にすれば1が適正となり、F4のレンズなら8secが適正な露出となる。
 ISO204800でF2.0のレンズなら、1/32secほどなので、広角なら手持ちでもなんとかなるかな。

 加算減算の順番を変えるだけでTv優先やAv優先やISO優先を計算できる。なれてくるといちいち全部計算しなくても設定できるようになる。さらに慣れれば表を使わなくても…となるはずなんだが、僕はオートを多用しているのでそこまでの計算はできない。

2017年3月12日日曜日

シャッタースピードとか

 普段は絞りオートばっかり使ってて、動きモノ撮るときはシャッターオート、輝度の変化が素早いモノのときだけマニュアルで、みたいな使い方なので、あんまり気にしたことなかったけど、ためしに絞りとシャッターと照度のグラフを作ってみた。


 左の表はISO100でシャッタースピードとF値とEVの関係。中央の表はEVとルクスの関係。右の表はISOとEVの関係。
シャッター1秒、絞り1.0を基準として、明るさが半分になるとEVが1増える。明るさが半分になるためには、シャッターが開いている時間を半分にするか、レンズの有効面積を半分にする。面積を半分にするには√2だけ直径を減らせばいい。ということでF1段は√2倍ステップとなる。ISOが倍になるとシャッター開時間が倍になるのと同じなので、EVは1段減ることになる。


もうちょっと実用的な表がコレ。シャッター、絞り、ISOの各EVの表。

 例えば軽く流し撮りをしたい、という場合。時間を南中前後として適正露出がEV14だった場合を考える。
 流し撮りをするから、シャッターは1/64あたりを使う。ということで適正EV14からシャッターEV6を引き、残りは8となる。残る要素はISOとF値だが、とりあえずISOを100に設定してみる。するとISO100はEV0だから、残りは8のまま。ということでEV8に相当するのはF16なので、そのように設定する。最終的に、シャッター1/64、F16、ISO100という感じになる。

 もう1つ例を挙げる。
 月明かりで風景を撮影したい、という場合。月明かりは0.2lux程度なので、適正露出はEV-3あたりとなる。今回使うレンズは解放F4なので、絞りはEV4となり、(-3)-4=EV-7となる。感度は400を設定し、ISO400相当EV-2を引いて(-3)-4-(-2)=EV-5となる。あとはシャッターをEV-5相当の32secに設定すれば、(適正露出-3) - (絞り+4) - (ISO+2) - (シャッター-5) = 0で設定EVと適正EVの差が0となり、適正露出となる。


 さて、最初に書いたとおり、普段の撮影では絞りオートとかシャッターオートを使うので、いちいち計算する必用はない。というか面倒なので計算したくない。
 なぜこんな計算をしたかというと、マイコンで照度を測り、シャッタースピードを自動制御したいと思ったから。
 マイコンからカメラの絞りやISOを操作するのは大変なので、ISOや絞りを固定にして、バルブのレリーズで露光時間を変更すれば輝度が変わっても一定の明るさで撮影することができるはず。
 で、南中10万luxから月明かり0.2luxまでをカバーしようとすると、EV16からEV-3あたりをシャッタースピードだけで調整する必要がある。
 ISO100、F4とするとEV16時でシャッター1/4096sec、EV-3時でシャッター128sec、くらいのレンジが必要になるらしい。レリーズに0.25msecのパルス入れてちゃんと1/4000のシャッターとかになるのかしら。。。
 昼間の雲のヌルヌルした動きから、夜中の星の動きまでをインターバル撮影しようとすると、どうしても夜間のシャッタースピードに引っ張られてしまうので、2.5分に1枚が限界かな。1時間あたり24枚なので、24fpsの動画にしても、24時間撮影してたかだか24秒。ひえー。しかも3600倍速で再生。
 せめて感度だけでも動かせたら楽なんだけど。

 一時期オープンソースカメラみたいな話が流行ったけど、結局スマフォアプリのAPIを公開しただけだった気がするし、すぐ下火になった気がする。
 SPIとかI2Cで全部設定できたり、簡単な画像処理のスクリプトを走らせてUARTとかに渡せるようなカメラがあればほしいんだけど。

2017年3月5日日曜日

NTDSのアイコン

 気分転換に、海軍戦術情報システム(NTDS: Naval Tactical Data System)のアイコンをC#で描いてみた。
 

2017年3月2日木曜日

超音波風速計 センサ間の距離を計算してみる


 ADTで計測した気温から音速を計算し、センサで計測した時間差との積で距離を計算し、その値を使って計算してみた。
 今日も暖かくてなかなか温度差が作れない。
 南北方向の風速は温度ドリフトがかなり少なそうだが、東西や上下はかなりドリフトしてる。
 センサの計測軸はCh1が60度、Ch2は180度、Ch3は300度の方向にある。南北方向は0.5Ch1, -1Ch2, 0.5Ch3の加算で誤差が平均化される。東西方向は0.5Ch1, 0Ch2, -0.5Ch3の加算で、平均化はされるが南北が3軸の平均されるのに対し、東西は2軸の平均なので若干ドリフトが有る。上下はすべての軸が加算されるから、平均化されることはない。と、考えると、ENUの誤差量に説明がつきそうだが、しかしそれぞれの軸は双方向対象に計測しているから、理想的な状態であればそもそも計測誤差は発生しないはず。

 さて、これからどうしようかねぇ。
 風洞作り、恒温槽作り、あるいは無響箱、その他何らかの校正に使える機材をどうにかしないと。

2017年3月1日水曜日

超音波風速計 温度センサを追加した

いままでは温度センサとしてサーミスタのみを使用していましたが、ADT7420という、精度が±0.2℃くらいのデジタル温度センサを追加しました。サーミスタはそれ自体の誤差や、分圧回路を校正する抵抗の誤差など、様々な誤差要因があるわけですが、ADTは未校正で0.2℃の精度があるそうです。比べてみると、だいたい2℃くらいずれているようですね。

 今日はかなり温かい一日でした。何日か前は一日の大半の時間でファンヒーターを稼働させていましたが、今日は日が照ってからは使っていません。
 外気温が低ければ気密の悪いこの部屋の気温も下がるわけで、ファンヒーターのON/OFFで簡単にΔTempを作ることができましたが、これからは温度変化を作るのはかなり大変になりそうです。
 恒温槽を作らなきゃですが、たぶん超音波風速計本体の2-4倍くらいのお金がかかるんじゃないかなぁ。なんだかなぁ。せっかく恒温槽を作っても、せいぜいΔTempは10℃程度でしょうし、他に使い道がないんだよなぁ。風洞も同様。


 とりあえず部屋の中は無風のはずなので、超音波から計算した温度がADTと一致するように、超音波から計算した風速が0になるように、パラメータを設定して、その状態で放置して温度ドリフトをチェックしてみようと思います。いくら暖かくなってきたとは言え、日没後ならまだ充分に温度変化を作れるはずです。

超音波風速計 小ネタ

上が気温、下が風速。途中でピークが有るのは息を吹いて気温を上げたところ。
 よく見ると風速に温度ドリフトが見られる。以前に取ったログも含めた傾向として、0.1m/s/1℃くらいありそう。
 分解能は0.02m/sくらいありそうだが、ノイズが0.1m/s以上ありそう。全季節ずーっと使うなら温度ドリフトで5m/sくらいは動きそうだし、精度5m/sとか風速計としてはひどいもんだ。
 アメダスは0.1m/sの分解能で出しており、精度もそれに近い値が有ると考えると、それに比べて10分の1から50分の1くらいの性能、という感じだろうか。市販の超音波風速計とくらべて値段が50分の1くらいなので、コスト比で言えば納得できなくもない性能なんだが、ちょっと物足りない。

 今のところ、ADCを0.64285714Msps(72MHz/112)で走らせているが、STM32F4ならMax2.4MHzとのことで、単純計算で分解能がおよそ3.7倍になる。等価時間サンプリング(ETS)に合わせてサンプリングレートを調整する必要はあるだろうが、それでも2.5倍くらいの分解能になるはず。あるいは、分解能を維持したままETSのサンプル数を減らすか。
 欲を言えば100Mspsくらいの実時間サンプリング(RTS)で取り込みたいけど、100Mspsってエントリークラスのオシロスコープくらいのサンプリングレートなので、マイコン1個でフィルタリングとか解析とかやるのはちょっとつらそう。
 このあたりの性能を目指すとなると、自前で全部作るより、DSO Quadのようなオープンソース・ハードオシロスコープのファームウェアを改造したほうが楽かもしれない。DSO Quadならファンクションジェネレータも入っているようだから、デマルチプレクサとマルチプレクサを外付けし、それを制御する簡単な回路をどっかから引き出すなり、外側にチープなマイコンを1個載せてファンクションジェネレータの配線経由で制御するなり、そういう感じになるのかな。


 とりあえず、まずは温度ドリフトの原因探しが先かなぁ。送信パルスも受信タイミングも同じクロックソースだから、クロックの温度ドリフトではないだろうし、それ以外で温度による周波数変調がかかるようなモノは積んでないはずだし、データ処理の問題だと思うんだけど。イザとなれば温度から補正することもできるだろうけど、それは最後の手段ということで。