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の誤差量に説明がつきそうだが、しかしそれぞれの軸は双方向対象に計測しているから、理想的な状態であればそもそも計測誤差は発生しないはず。

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