2019-02-09

ちっこいテスラの進捗

　今までテスラコイルというとデカいテスラ (VU200級) ばっかり作ってきたので, ちっこいテスラに結構躓きました。しかし, とりあえずは進捗は生みましたよ。ハイ。

f:id:Kamomesan:20190209230209j:plain — コイル～

　今回, オリジナルテスラコイルリスペクトで, エキストラコイルを使っています。実はこのサイズでエキストラコイルつかってもあまり意味はないので実質飾りなんですけどね^^;

f:id:Kamomesan:20190209230828j:plain — テスラのエキストラコイル

　とりあえず今回のテスラコイルでの目標は

・SSTC

・和音演奏に特化した制御周り

・放電距離は求めない

・可能な限りお金をかけない

ってところでした。結果から言うとまぁ満足ってかんじです。

　次に自作MIDIインタラプタ。

f:id:Kamomesan:20190209231056j:plain — 和音対応MIDIインタラプタ

f:id:Kamomesan:20190209231122j:plain

　このMIDIインタラプタは, Arduino Leonardo (ATmega32U4) を使用しており, ケース含めなければ1000円ちょいで作成できます。Windows デバイスドライバを書き, USB-MIDI変換ケーブルを必要とせずPCと直接つなぐだけでMIDIデバイスとして認識されます。出力はSP/DIFコネクタで光信号を出します。光を使った理由は, コイルとの物理的距離を十分に確保しやすいので装置の暴走を起こしにくくできるからです。このインタラプタはそのうち, オープンソース化する予定です。特徴としては,

・USBケーブルでPCとつなぐだけで使える

・光出力で安全なテスラドライブ

・小さくて扱いやすい

・制作費が安い

・64和音対応

・ピッチベンド, モジュレーション等CC対応

ってところですかね。和音対応に関してはブリッジの負荷を考慮して, ある程度音数が増えると負論理とし, 音が増えても電流が増えないよう工夫をしております。これをする前では20和音あたりでほとんど無変調状態になり, スライダックがうなってしまいました^^;

f:id:Kamomesan:20190209231957j:plain — ブリッジ部

　これは今回のパワー部です。ACDC変換は単純なブリッジダイオードを使った全波整流回路であり, ブリッジはIRFP260を使ったハーフブリッジです。IRFP260は2並列にして電流をある程度流せるようにしています。バスコンデンサはちょっと容量不足な気もしてます。

f:id:Kamomesan:20190209232328j:plain — ブリッジ

f:id:Kamomesan:20190209232344j:plain — ブリッジ

　ブリッジはユニット化したことにより素子の交換がとても楽です。実は今までにミスで3つ破壊してます^^; ヒートシンクはどこからか拾ってきたDCファン月のものです。もともとはマザボにでも付いてたんでしょうか。なかなか冷えてくれるので今のところブリッジが暖かくなったことは無さそうです。

　後にデカ2次コイルを置いて遊んでたのですが, IRFP260はやっぱり強いですね。スライダックが大分うなりますが今のところ正常動作中に焼けてません。

f:id:Kamomesan:20190209232516j:plain — 実験風景

　なかなか簡素にまとまったと思います。

f:id:Kamomesan:20190209232713j:plain — フィードバック波形

　今回は初めCTを使った電流フィードバックをしてましたが, ちっこいテスラコイルのせいか入力電圧が10Vとかになるとまともにフィードバックかからなくなってしまうので, 電圧フィードバックに変更しました。波形の質はともかくはっきりと取れてます。

だいぶ伸びた
40V
スライダックが唸る(^_^;) pic.twitter.com/kSze99jEfC
— Hkat (@igbtbreaker) February 8, 2019

40VAC入力でこんなもん。演奏用テスラならこんなに放電いらないですね。

これぐらいがちょうど良いか pic.twitter.com/rutfcL9CwV
— Hkat (@igbtbreaker) February 8, 2019

結局20VACあたりがちょうど良いという結論になりました。後々スライダックいらないような改造を施す予定です。

20V入力
デカコイル
放電距離はちっこいのと大して変わらない pic.twitter.com/oVKS9noSb0
— Hkat (@igbtbreaker) February 8, 2019

思いつきで以前作っていたデカコイルを今回の装置に置いてみました。20V入力でミニコイル40Vくらいの放電が飛びます。やっぱりQの高いコイルは良いですね～。

私は電気人間だっ！ pic.twitter.com/ZxIbEUCJh8
— Hkat (@igbtbreaker) February 8, 2019

いつもの如く蛍光灯をチラチラできます。これは単純にデカコイルだとトロイドが蛍光灯に近いからかと思います。

今後の予定

・現状スライダックで電圧調整をしてますがめんどうなのでそれをいらない構造にする予定です。簡単なのはバックコンバータかな？

・現状ON時間の制限をしていないので音によっては2msとか流れて非常に恐いです。これは回路を追加して制限する予定です。

・制御回路へのノイズ対策。とくに影響は出てないようですが放電中オシロで見るとやばげなノイズが乗るので恐い^^;

・ハードをちゃんとつくる。1次コイルのステーも作ってないもでちゃんとします。

2019-02-09

フィードバック制御の基礎, PID制御について

　ロボコンにもロボカップにも使うであろう, PID制御について適当に書いていきます。ただ, どっちの界隈でももっと単純な制御で十分だと思う事も無いことも無いですね^^; ああいう競技ロボットって, シンプルなハード＆シンプルな制御の組み合わせが最強だってn回言われてますし(笑)

まず制御とは何か

　簡単な話, 「ある物(制御対象)を現在の状態から目的の状態になるまで動かす事」です。例えばモータ軸に接続されたカメラがあったとして, 只今カメラは西方向を向いてるとすればそれを東方向に向けるようモータに印加する電圧を適切に設定するのは制御です。さらにボイラー内の温度を20℃のから240℃一定にしようとする操作も制御になります。このように, 制御できる制御対象はモータなどのアクチュエータだけでなく温度湿度, 電圧電流, 周波数, 磁束などさまざまな事象も含まれます。

フィードフォワード制御とは

　例えばモータを使って何かしらのデバイスを0°から90°の方向に向けたいとします。この制御を達成しようとしてまず思いつくのは, 「12Vでこの回転速度なら, 1秒くらいかければ90°になるやろ」って感じだと思います。また, カーラジコンを今の位置から5m先に停止させたい場合は, 「10秒くらい前進ボタンを押せば5mくらいで止まるやろ」ってなるでしょう。このように, 制御対象の特性を予め把握しておき, その特性から目的を達成できる操作を予測し制御することを「フィードフォワード制御(オープンループ制御)」と言います。

f:id:Kamomesan:20190209212407p:plain — フィードフォワード制御のイメージ

　オープンループ制御は簡単ですが, 問題があります。それは, 高速に目的を達成できない事, 外乱に対応できないことです。例えば, モータの話では, 0°から90°に動かすという目的をできるだけ早く達成するために, モータ電圧を高くしようとすると, モータ軸や負荷の慣性で90°を通り越しやすくなってしまうのは容易に想像できると思います。当然ゆっくり回した方が90°でぴったり止めやすいですよね。このように, 制御対象を目標の状態にもっていく時間をどれだけ短くできるかという能力を, 制御システムの速応性と言います。例えば人の方向を追尾するカメラを作ったとしたとき, 速応性が高いほど人のいる方向にピッタリと張り付きます。逆に, 速応性が低いと人のいる方向にカメラが向くまで時間がかかります。

f:id:Kamomesan:20190209213440p:plain — 速応性

　外乱に対応できない, という話は簡単で, 先のモータの話だと例えばモータ回転中に人がモータ軸を握ったりした場合, 目的の90°にはたどり着けないよね, という事です。単にある時間だけ電圧を印加してるだけですので, 軸をロックされると目的の角度にたどり着けないのは当たり前の話ですね。外乱に対する制御系の適応能力を, 制御システムのロバスト性と言います。

f:id:Kamomesan:20190209213455p:plain — ロバスト性

フィードバック制御とは

　それでは, オープンループ制御では不十分である場合どうすれば良いかといえば, それは「現在の状態を監視し, それに応じて制御する」という事でしょう。オープンループ制御で速応性とロバスト性が不十分となる原因は, 制御コントローラ(マイコンなど)が現在の制御対象の状態を把握できていないという部分が大きいでしょう。例えば人に目隠しをして, 10m歩けと指示する場合はオープンループ制御となり, 歩く人は自分が1歩あたり進む量から推測して止まるしかありませんし, 10mピッタリに止まるのは難しい事です。しかし, 目隠しを外して地面に10m測れる定規が置いてあれば10mピッタリ歩くのは簡単ですよね。このように, 制御コントローラが制御対象の状態を監視し, 目的の状態に制御する方法を「フィードバック制御(クローズドループ制御)」と呼びます。

f:id:Kamomesan:20190209214510p:plain — フィードバック制御の例

　フィードバック制御を用いれば, 先のモータの話のように0°から90°に回したい場合に人がモータ軸を握っても, 離せば90°に向かうよう制御が行えます。なぜなら, 制御コントローラはセンサなどによりモータ軸の位置を把握しているので, 途中で軸をロックしても「まだ90°になっていない」という事が分かるからです。

f:id:Kamomesan:20190209215414p:plain — モータの角度を制御する例

PID制御とは

　それでは本題のPID制御です。先に述べたとおり, フィードバック制御は制御対象の状態をモニタリングすることでより正確な制御を可能にするものですが, その方法は色々ありますが, ここでは自動制御, フィードバック制御の基礎とされ, 工学では最も多く利用されるPID制御について書きます。

　PID制御は,

・比例制御 (P制御 : Proportional Control)

・積分制御 (I制御 : Integral Control)

・微分制御 (D制御 : Derivative Control)

を組み合わせた制御方式です。この3つの制御方法を理解すればPID制御も分かると思います。それぞれの制御方法はそれほど難しいものではありません。

比例制御 (P制御)

　比例制御は, 簡単に言うと「制御対象が目的の状態から離れていれば離れているほど, 強く目的の状態にしようとする制御」です。

f:id:Kamomesan:20190209220041j:plain — P制御のイメージ

現在の状態が目的の状態からどれだけ離れているか, という値は偏差 e と言い, 現在の状態を y , 目的の状態を r とすると,

$e = r - y$

と表せます。たとえば, 目的の角度が90°とするとき, 現在の角度が88°なら

$e = 90 - 88 = 2$

です。この偏差 e は後々説明する I制御, D制御でも使用します。

　P制御は「制御対象が目的の状態から離れていれば離れているほど, 強く目的の状態にしようとする制御」なので, つまりは偏差 e に比例して操作する量を大きくしよう, ということです。 P制御を数式であらわすと次のようになります。

$c = K_p \cdot e$ (簡易形)

$c(t) = K_p \cdot e(t)$ (時間関数形)

$C(s) = K_p \cdot E(s)$ (s領域形)

ここで, c は操作量, $K_p$ は比例ゲインと呼ばれる定数パラメータです。先のモータの話では, 目的の状態は軸が90°になっている事を指します。モータに対する操作量 $c$ は電圧なので, 例えば現在の状態が 0°としたときにモータに印加する電圧 $v_m$ は次のようになります。

$v_m = K_p \cdot e = K_p \cdot (90-0) = K_p \cdot 90$ [V]

　比例ゲインは制御対象の特性を考慮して適切に設定する必要があります。↑の例だと, $K_p = 1$ とするとモータには 90 [V] の電圧をかけることになります。コレを3V用モータでやるとモータが焼けますよね(^_^;) ゲインの決定方法はいくつかありますので後述します。今回は適当に $K_p = 0.1$ として話を進めます。

　現在の状態が0°なので 9 [V]がモータに入力されます。これによりモータの軸が回転し, ある時軸が30°になったとします。このときモータに印加する電圧は,

$v_m = K_p \cdot e = 0.1 \cdot (90-30) = 6$ [V]

ですね。さらに回転し, ついに90°になった時には,

$v_m = K_p \cdot e = 0.1 \cdot (90-90) = 0$ [V]

となり電圧は印加されませんね。しかし, モータには回転子にも負荷にも慣性が存在しますので, $K_p$ の値によっては目標値を通り過ぎるオーバーシュートが発生します。また, 制御開始からオーバーシュートのピーク時までの時間を行き過ぎ時間, ピーク時の目的値から離れた大きさを行き過ぎ量と言います。

例えばオーバーシュートして100°になってしまったときにモータに印加する電圧は,

$v_m = K_p \cdot e = 0.1 \cdot (90-100) = -1$ [V]

となり, 先ほどとは逆回転させて目標値に戻そうとする事がわかります。

　このように, 比例制御はこの式をマイコン等に計算させることで簡単に実現できる, 簡単な制御方法です。比例制御は現在の制御対象の状態を制御に反映させる制御方法と考える事ができます。

積分制御 (I制御)

　積分制御は, 簡単に言うと「制御対象が目的の状態から離れている時間が長ければ長くなるほど, 強く目的の状態にしようとする制御」です。

f:id:Kamomesan:20190209220105j:plain — I制御のイメージ

積分制御は次の式で表せます。

$\displaystyle c = K_i \cdot \int_0^t e$ (簡易形)

$\displaystyle c(t) = K_i \cdot \int_0^t e(t) dt$ (時間関数形)

$\displaystyle C(s) = K_i \cdot \frac{E(s)}{s}$ (S領域形)

　ここで, $K_i$ は積分ゲインとよばれる定数で, これも比例ゲインと同じく制御対象に応じて適切に設定する必要があります。この積分制御は, 例えば先のモータの話では軸を手で握って止めると時間が経つにつれモータに印加する電圧を徐々に増加or減少させ, 拘束を逃れようとする働きをします。

　積分制御はほとんどの場合比例制御と組み合わせて比例積分制御(PI制御)として用いられます。PI制御ではモータに印加する電圧を $v_m$ , 制御開始からの現在時間を $t$ とするとき,

$\displaystyle v_m = K_p \cdot e + K_i \int_0^t e \cdot dt$ [V]

と求められます。積分ゲイン $K_i$ も比例ゲインと同じく適切に設定する必要があります。基本的に制御系における積分要素は系全体を不安定にしやすいので, いきなり大きなゲインを設定すると簡単に制御対象を破壊してしまう場合がありますので, 慎重に検討しなければいけません。

　積分制御は今までの偏差を積分するため, 過去の制御対象の状態を考慮する制御方法と考える事ができます。

微分制御 (D制御)

　微分制御は, 簡単に言うと「制御対象早く動くほど逆方向に力をかける制御」です。つまりブレーキのような動作をします。

f:id:Kamomesan:20190209220126j:plain — D制御のイメージ

積分制御は次の式で表せます。

$\displaystyle c = K_d \cdot \dot{e}$ (簡易形)

$\displaystyle c(t) = K_i \cdot \frac{de}{dt}$ (時間関数形)

$\displaystyle C(s) = K_i \cdot sE(S)$ (S領域形)

　ここで, $K_d$ は微分ゲインとよばれる定数で, 制御対象に応じて適切に設定する必要があります。この微分制御は, 例えばモータに何かが衝突するなどして回転速度が急激に変化しようとしたとき, それを抑えようとするブレーキのような働きをします。

微分制御も, 積分制御と同じく単体で使用されることはほとんどなく, 比例制御と組み合わせて比例微分制御 (PD制御) として用いられます。PD制御ではモータに印加する電圧を $v_m$ , 制御開始からの現在時間を $t$ とするとき,

$\displaystyle v_m = K_p \cdot e + K_d \frac{de}{dt}$ [V]

と求められます。微分ゲイン $K_d$ も比例ゲインと同じく適切に設定する必要があります。微分ゲインは大きくしすぎると, 制御の速応性 (目標値に到達するまでにかかる時間)お大きくなってしまいますので, 比例ゲイン, 微分ゲインともに調整が必要です。

　微分制御は偏差の微分値(つまり, 傾き)に注目する, つまり未来の制御対象の状態を予見する制御方法と考える事ができます。

比例積分 微分制御 (PID制御)

　これまで紹介した比例制御, 積分制御, 微分制御を単純に組み合わせる事で, PID制御とすることができます。数式で見ると,

$\displaystyle v_m = K_p \cdot e + K_i \int_0^t e dt + K_d \frac{de}{dt}$ [V]

となります。またS領域では,

$\displaystyle C(s) = K_p \cdot E(s) + K_i \cdot \frac{E(s)}{s} + K_d \cdot sE(s)$

となります。

(書き途中)

2019-01-15

例のグラボ「Radeon RX470」の性能はどんなもん？

　先日やっとの思いで2枚購入した例のグラボですが, 実際の性能ってどんなんやろ？と思っている人は僕だけじゃないと信じているので, 体感してみました。とりあえず自分のつい最近組み始めたPCの構成は次のよう。

・CPU : Celeron G3930

・RAM : 2GB DDR4 2400*2 + 8GB DDR4 2400*1 = 12GB

・GPU : 改造済み Radeon RX470 8GB + 未改造 Radeon RX470 8GB CF

・M B : SuperMicro C7Z270-CG-L

・PSU : MouseComputer MCH850AT 850W

・BOX : Junk ￥500

　なんというか, CPUはCeleronだしRAMは変な構成でしかも人権(16GB)を得られていなかったりと散々ですが, ジャンク志向がPCを組むとこうなりますので(笑) 本来はCPUはCore i7 7700Kにする予定でしたが, 高額を支払って入手した石が死んでいるという悲しい出来事があったので3000円ほどで手に入るCeleron G3930を一時的に乗っけているんですねぇ…。

　今回ベンチマークするにはあまりにもCPU等貧弱すぎるのでトータルスコアは重視しませんでした。GPUだけ評価するにはGPGPUでゴリゴリ計算させれば良いんですが, いちいちHIPを書くのもめんどくさいので「3DMARK」というわりとメジャーなベンチマークソフトでいい感じの負荷をかけてこんなもんか～って評価しました(適当)。

f:id:Kamomesan:20190115222407j:plain — 負荷テスト開始！！

　とりあえずデフォルトの条件で「SKY DIVER」というベンチを行ってみました。

f:id:Kamomesan:20190115222838p:plain — 落ちる～

　序盤はスカイダイビングで, 広域の渓谷の描画, 雲のフォグ描画, キャラクタの反射等確認できますが200fpsを超えます。これはうれしい！！しかし, 時々映像がプチプチ停止します、これはCPUが足を引っ張っていそうです^^;

キャラクターが地上に降り立つとパーティクルの評価が行われます。これはスカイダイビングの時よりフレームレートが上がり, 常時280fps程です。すばらしい。

f:id:Kamomesan:20190115223809j:plain — きらきらぽわぽわ

次に, 岩の破壊？のようなCPUによる物理演算能力が評価されます。

f:id:Kamomesan:20190115223841j:plain — 何故か同時に岩を破壊しているハンマー。岩が何をしたというのか。

　物理演算はCPUをメインに使用しているようなので, 流石にCeleronではキツかったのか, 50fps程まで落ち込みました。まぁ実用的な範囲ではあります。

f:id:Kamomesan:20190115224010j:plain — 物理演算+キャラクタの描画

　岩破壊の物理演算に加えキャラクタとマグマの描画が追加されるとさらに30fpsほどまで落ちます。はやくCPU変えたい^^; 最終的なスコアは次のようになりました。　

f:id:Kamomesan:20190115224358j:plain — SKY DIVER スコア

　グラフィックのスコアは 56041 と, GTX1080tiのスコア約52000 (以前違う構成のPCで行ったもの)を突破しました。物理スコアは 3843 とちょっと残念な結果です。まぁこれはちゃんとi7を乗せられたらある程度改善するかもしれません…。グラフィックのスコアだけ見れば, 1080tiに十分太刀打ちできる性能がありそうという事はわかりました。

　次に, 「Cloud Gate」ベンチマークを実行してみました。これはなんか雲の中に浮かぶ要塞的なのがいろいろパカパカしたり宇宙船みたいのが射出されたりします。

f:id:Kamomesan:20190115225651j:plain — 要塞内部？

f:id:Kamomesan:20190115225709j:plain — 要塞の横？

f:id:Kamomesan:20190115225727j:plain — 写真じゃわからないけどいろんなところがパカパカしてる

　このベンチマークはフォグの描画, 発光(ライト)の描画と反射を評価している感じですね。デカイオブジェクトがせわしなく稼動している中雲の描画とライトの描画も行っているのでかなり重い部類の処理なはずです。これも物理演算が評価されます。なぜかサンゴがジェットで吹き飛ばされます。

f:id:Kamomesan:20190115230027j:plain — サンゴがなにをしたというのか

　Cloud gateの最終スコアはこんな感じです。驚きですね, 400fps出てます。やはりCPUがネックになってしまってますね^^;

f:id:Kamomesan:20190115230059j:plain — Cloud Gate スコア

　とりあえず適当にベンチかけてみましたが, RX470*2 CF はとても使い物になりそうでした。しばらくはこれで作業をこなせそうです。(といっても, 僕自身まともなグラボはGTX1080tiくらいしか持ってないのでグラボオタクの皆様から見たらそうでもないのかもしれませんが^^;)

結論

・スコアだけみれば1080ti超え。場合によっては400fpsを超えることも！

・CFが効果あるかどうかはゲームやソフトによってかなり変わるっぽい。

・CPUとグラボの性能が釣り合ってないと最悪CPUが足を引っ張る。

2019-01-15

例のグラボ「マイニング専用 Radeon RX470」をグラフィック化改造

　お金が無くて流行に乗れないかと思いましたががんばってお金を得たので早速手を出してしまいました(笑)　秋葉原のパソコン工房(Buy more)さんやARKさんで大量入荷＆格安セールしていた例のグラボ「RX470」です。

f:id:Kamomesan:20190115105844j:plain — 例のグラボ

　AMDから出ているRadeonブランドのRX470。しかし, セールででているのは映像出力機能が省かれたマイニング仕様の製品です。お一つ5980円。Amazonでは同製品が45000円程度で販売されているので驚きの安さです。通販もあります。

www.pc-koubou.jp

akiba-pc.watch.impress.co.jp

www.google.com

　ビットコインバブルがはじけた(?)影響か, どこからか大量に入荷した物のようです。Buy more店舗にはショーケースにもたんまり積まれてましたし(2019年1月14日現在), 僕が買ったときは店の裏から出して貰ったので在庫はかなりありそうです。しかしこれを買ってマイニングをする気なんぞサラサラ無いので, 早速映像出力できるように改造します。Buy moreでは1ヶ月の保障が付いてましたが改造すると当然保障も受けられないでしょう。作業は慎重におこないます。

　ちなみに, CrossFire (並列処理) 前提ならグラボを改造するのは1台のみでOKです。ただし, 後述するファームウェア書き換えは全部のRX470でやる必要があります。

　まず, 改造するにあたりファンが邪魔なので外します。ベイのパネルも外します。計6つのネジを外すだけで改造できる状態まで持って来れますが, ファンのコネクタがつながっているので丁寧に抜きます。

f:id:Kamomesan:20190115110709j:plain — ファンを外すとHDMIコネクタが隠されていた！

　ファンとベイのパネルを外すとHDMIコネクタが現れます。ベイのパネルはこのHDMIコネクタを隠すように作られているので, コネクタの部分(ネジ穴は切っちゃダメ！)を適当なソーでカットしてやる必要があります。

f:id:Kamomesan:20190115221049j:plain — これを, こうして,

f:id:Kamomesan:20190115221121j:plain — こうじゃ！

　今回このRX470でHDMI出力できるようにするにはどう改造するかというと, チップ部品を追加するだけです。HDMIコネクタ付近にある下図の場所にチップ部品をハンダ付けします。

f:id:Kamomesan:20190115111325j:plain — 部品を追加する箇所

　ここは簡単に言うとHDMIの信号線の部分で, マイニング用ということでパーツが乗ってません。単なるノイズ減衰回路, フィルタのようなのでどのグラボも大体同じ回路定数になると思いますが, 今回はPC修理廃人さんのツイートを参考にさせていただきました。

マイニング用RX470のHDMIの追加部品の詳細がわかりました。
GTX1080の回路図を参考にし、廃基板の実測値とも一致したのでこの値でいいと思います。

インダクタは手持ちの機材で測れなかったのと回路図ではFB(600Ω 0.3A)だったので不明としました。

ID付きの画像はブログ等でご自由にお使いください。 pic.twitter.com/2hSYYoHa6u
— PC修理廃人 (@pana_junk_pc) January 12, 2019

　追加する部品は1005というサイズのチップ部品なのですが, コレが秋葉原じゃなかなか手に入らないんですよね(^_^;) ちなみにサイズはこんなかんじ。

f:id:Kamomesan:20190115111811j:plain — ピンセットの先がピンセットって感じじゃない

　このサイズのハンダ付けに慣れてないと今回の改造はツライと思います…。というか, 人の手でやるもんじゃないです^^;

　今回は, PC修理廃人さんのツイートどおりのパーツが秋葉原では用意できそうになかったので, 次のようなパーツを用意しました。

f:id:Kamomesan:20190115112827p:plain — 実装図

　未実装の部分はフィルタとかなので無くても動きはします。当然あった方が良いですけど…。レシーバ(ディスプレイ側)があまりにもシビアだと映らないかもしれませんが大体大丈夫でしょう。購入先はそれぞれ

akizukidenshi.com

https://www.sengoku.co.jp/mod/sgk_cart/detail.php?code=EEHD-57F7

　チップ抵抗の方は千石で10個入りのが売っています。これらのパーツをハンダ付けするわけですが, やはり1005のパッドに1608を実装するのは難しいですね^^; 結構時間を取られてしまいました。

f:id:Kamomesan:20190115113531j:plain — 実装した

　実装したら満足してしまって整形はしませんでした、ハイ。ちゃんとハンダ付けできてれば多少曲がったって動作に影響はありません。さすがに隣とハンダブリッジで短絡とかは厳しいですけど^^;

　今回の改造で映らないとしたら, しっかりハンダ付けできていない(パーツとパッドが接触していない)か, ハンダブリッジによる隣同士の短絡, 加熱のしすぎでパーツが死ぬくらいですかね。下手するとグラボ自体がお釈迦なので勇気のいる改造ではありますね。

　部品の追加ができたら, コネクタの接続を忘れないようファンとベイパネルを戻し, PCに接続です。PCIeの補助電源コネクタの接続も忘れずに。

f:id:Kamomesan:20190115113908j:plain — 2枚挿し

　グラボのロットによるらしいですが(基板上のスイッチ操作だけでいけるのもあるらしい。僕のはダメでした^^;) グラボ内部のファームウェアを書き直さないといけないようですので, まずはBIOSのセットアップからプライマリディスプレイを内部映像出力をInternal, もしくはOnboardにしておきマザボの映像端子から映像を吐かせるようにしときます。

　RX470のファームウェアを書き換えるためのソフト「ATIFlash」を使い, RX470で映像出力できるようにします。

www.techpowerup.com

上のATIFlashと下の新ファームウェアをダウンロードします。

www.techpowerup.com

　ATIFlashの実行ファイルと同じディレクトリに新ファームウェアを置いておき, コマンドプロンプトでそのディレクトリを開いたら下記のコマンドを実行します。

> atiwinflash -f -p 0 Sapphire.RX470.8192.160715.rom

　これだけでしばらく待機すればファームウェアが書き換えられます。失敗した場合はグラボがちゃんとささっていないとか, 補助電源忘れとか, 最悪グラボが死んだとかかな。

　ちなみに, 複数挿しで2枚目以降のファームウェアも書き換える場合は -p オプションの数字を変えるだけです。

> atiwinflash -f -p 1 Sapphire.RX470.8192.160715.rom

　ファームウェアが書き換えられたら, 次にデバイスマネージャを開いてみます。ディスプレイドライバのところでグラボと思しきデバイスが！に成っていると思いますが, これはドライバが無いためです。下記のAMDサイトからドライバを落としてインストールすれば！が消えます。

www.amd.com

　あとはとりあえず再起動をかけてBIOSセットアップからプライマリディスプレイをAutoとかDefaultとかに戻すとRX470のHDMIが使えるようになってるはずです。

f:id:Kamomesan:20190115115450j:plain — うまくいったの図

　ちゃんと出力されてたらあとはゲームをやるなりCrossFireで1080を泣かすなり自由です。

　そういやいままでマザボ裸で動かしてましたがついにケースに入れました。

ケースはツクモに500円のジャンクで落ちてました^^

f:id:Kamomesan:20190115115604j:plain — ケースに入れたよ

2018-12-21

カルマンなジャイロ・地磁気センサ「JY901」の使い方

　ロボットなどの工作物で角度をセンシングしたくなるときってありますよね。私の場合は, RCJ (ロボカップジュニア) でロボットを作ってるので, 正確かつ外乱に強い,しかもYaw軸(Z軸)が読める角度センサを探してたのですが, メジャーなMPU6050などを使ってみても会場の電力系統の影響をモロに受けたり, どうしてもドリフト (静止していても角度が徐々に変化してしまう事) したりしてしまって, どうもうまくいかない時がありました。そこで, JY901というジャイロ&地磁気センサの存在を知り, 実際にAliexpressで購入, 動かしてみるとかなりうまくいったので使い方を記事に書いておきます。

　購入したのはここ。

ja.aliexpress.com

　以前はもうちょっと安かったんですが, なんか微妙に高くなりました。Wit-Motionという中国のメーカが製造してるセンサで, 地磁気, 加速度, ジャイロ, 演算角度, 温度, 気圧, 高度などがUART, I2C, PWMのいずれかの方法で出力できます。この値段でこの性能はなかなか強い方ではないでしょうか。

JY901の使い方

　このセンサ, Arduino用のライブラリなど公開されているのでそれを引っ張ってきて使うのが一番楽かもしれませんが, 私の場合愚直にUARTで操作してもそんな難しくないなぁと思いました。データシートは以下。

http://wiki.wit-motion.com/english/lib/exe/fetch.php?media=module:wt901:docs:jy901usermanualv4.pdf

　シリアルのフォーマットは単純で, センサからマイコン等ホストに送信されるデータは

0x55 | データ種類 | 8バイトのデータ本体 | チェックサム

となっています。データ種類バイトの値によってホストは何のデータかを判断できます。また, 最後にはサムバイトが返ってくるのでデータの破損もチェックできます。データ種類の値とデータ内容の関係はデータシートを見れば分かるとおもいます。

　例えば, Arduinoで加速度を取得したい場合はおおよそ次のようになります。

(手順説明用に適当に書いたのでこのままでは動かないよ！)

void setup(){
Serial.begin(9600); //JY901のUARTボーレートはデフォで9600 baudです。
}
void loop(){
byte buff[11];
if(Serial.available()){ //シリアルバッファにデータがあることのチェック
buff[0] = Serial.read();
if(buff[0] == 0x55){ //データが来たことのチェック
buff[1] = Serial.read();
if(buff[1] == 0x51){ //加速度のデータ種類は 0x51
for(int i=0; i<9 ;i++){
buff[i+2] = Serial.read(); //データ本体+サムの取得
}
}
}
}
}

実際には取りこぼさないような工夫やマイコンの処理速度等考えて書かないといけないんですが…。まぁこの手順で buff 配列に加速度のデータが入りますので, あとは煮るなり焼くなり。

　データの取得はデータシート通りのフォーマットに従えば簡単にできました。次に, ホストからJY901に命令を出すシリアルフォーマットについて。データシートによれば, ホストからJY901へのシリアルフォーマットは次のようになります。

0xFF | 0xAA | 操作種類 | データ下位バイト | データ上位バイト

操作種類バイトの値はデータシートの Register Address table に乗ってます。ホストからJY901へのデータ送信は受信より簡単かもしれません。例えば, リターンレート (1秒間に何回データを送ってもらうか) を200 Hz に設定するのは以下のようです。

void setup(){
Serial.begin(9600);
}
void loop(){
byte buff[5] = {0xFF, 0xAA, 0x03, 0x0B, 0x00}; //return rate を 200 Hz にする命令
Serial.write(buff, 5); //バッファの内容を5バイト送信
}

　これでJY901は1秒に200回データを返してきます。(デフォでは10回) 実際には, デフォのボーレート 9600 で 200Hzデータもらうのはハードウェア的に厳しいので, ボーレートを上げるかリターンレートを下げることになるでしょう。ボーレートを115200に上げるのは次のようにします。

void setup(){
Serial.begin(9600);
}
void loop(){
byte buff[5] = {0xFF, 0xAA, 0x04, 0x06, 0x00}; //baud rate を 115200 にする命令
Serial.write(buff, 5); //バッファの内容を5バイト送信
}

　当然この命令を実行した瞬間にJY901のボーレートが9600から115200に変わるので, 通信できなくなります。ボーレートが正常に変更できていれば Serial.begin(115200); に変更することで通信を再開できます。

　以上の通りJY901はUARTで制御すると簡単なんですが, I2Cでも基本やる事は同じです。フォーマットは違いますが手順は同じですね。

Processed Angle (演算角度) について

　JY901は, 地磁気, 加速度, ジャイロのデータを使ってカルマンフィルタをかけ信頼できる角度を算出する 9軸演算モードと, 加速度, ジャイロのデータを使う 6軸演算モードがあります。9軸演算モードで計算されたアングルはJY901のロットにも精度が大きく変わることが分かっていますので, 6軸演算モードを使うのが無難です。一時期のロットでは, 9軸演算モードにするとキャリブレーションしてもドリフトが発生したり, 角度の収束に数秒の遅延が発生したりと散々な結果になってましたね(^_^;) 演算モードの設定はデータシート 7.2.6 Algorithm transition の通りです。

センサキャリブレーションについて

　加速度センサ, 地磁気センサは購入直後の状態ではまともに使えませんので, キャリブレーション (較正) を行う必要があります。キャリブレーションはシリアルで命令を送ることでもできますが, 目で状態が見えないので miniIMU という公式(?)GUIソフトを使う事をオススメします。といっても, なんかバグだらけのソフトなんですが, キャリブレーションくらいはちゃんと動くみたいですので。ダウンロードは以下のgithubから。

github.com

f:id:Kamomesan:20181221141013p:plain — miniIMUでのキャリブレーション

隠しコマンドについて

　データシートに書いてない命令を見つけてしまったので置いときます。ロボカップではもはや必須な操作, 「Yaw(Z)軸の0点設定」です。この命令を送信すると, 現在のYaw角度を0度として演算角度を返すようになります。

0xFF | 0xAA | 0x01 | 0x04 | 0x00

I2Cについては使ってないので未調査です(^_^;)

2018-12-17

通信インタフェースの選択, 組み込みプラットフォームの選択について

　今年, 私は高専ロボコンに特別要員としてむりやり参加させられた (まぁ楽しかったのでﾖｼ！) のですが, そのとき工作物, 主にロボットに使う通信インタフェースの選び方やマイコン等組み込み周りのプラットフォーム選定があまりにも適当すぎる現状を知りました。まぁ, こうゆうこともあり結局大会でロボットは動かなかったんですよね… スタートゾーンから (笑)　ということであくまで自分なりにどう通信インタフェースを決定するか, 組み込みプラットフォームを選定しているのかを書こうと思います。

通信インタフェース

　マイコンを触っている方ならパラレル, シリアルという言葉は理解しているでしょう。情報・通信機器間の通信は主に電気信号で行う必要があり, それの送り方をパラレル, シリアルと大別しています。通信インタフェースは機能間の通信を担う要素なので, 当然選択を誤ると無駄に通信速度が遅くなったり, 連続性が欲しいデータにジッタが現れたりします。今回, 高専ロボコンではマイコン間での通信にEthernet (TCP/IP) を, 無線通信に WiFi (IEEE 802.11) を使っていました。残念ながら, 僕が呼ばれた時にはコレを採用する流れになっていまして, 今思えば全力で止めるべきでしたね…。

通信の種類

　工作界隈でよく使われてそうなインタフェース, 方式, 無線を並べます。

・RS-232 (UARTと呼ばれたら大体コレ)

・I2C

・SPI

・CAN

・Ethernet (TCP/IP, UDP)

・Parallel (GPIO controlled)

・WiFi

・Bluetooth

・Zigbee

…くらいですかね。

通信の種類によるメリットデメリット

　各通信方式, 通信バスにはそれぞれ特徴があり, 適材適所といった所です。選択を誤ると無駄に開発時間がかかったり通信が遅くてイライラしたり…。簡単に書いておきます。

RS232

　「UART」と言われたら大体RS232の事を言っているのでしょう。一般的なシリアル通信の規格です。今のマイコンには大抵UARTが乗ってるので, マイコン間通信, マイコン-PC間通信に最も多く利用されてる通信ですね。まず, UARTは非同期式なのでマイコンがデータの到着を知ることはできません。(UARTバッファの要素数を読んで現在何バイトデータがたまっているかを知る事はできます。) 非同期通信の難しいところはデータを取るタイミングでしょう。非同期という名の通り, データ送信側はデータを送りたいときに送り, 受信側は取りたいときに取ります。大抵のマイコンには 32～512 byte のUART受信バッファが乗っているので物理的にデータが到着してからソフトがデータを取るまである程度時間的余裕がありますが, データの到着速度に対してソフトの読み取りが遅いとUART受信バッファの内容は順次破棄され, 正しいデータを得ることができません。うーん, 言葉で説明するのは難しいですね (^_^;)

例えば…

・受信バッファが32byteのUARTに対して1秒間に8バイトデータ送信すると, 受信側は何もしなければ4秒後にはバッファがあふれる。

・受信側のマイコンはソフトでUART受信バッファからデータを1byte読み出すとUARTバッファからデータが順次1byteずつ抜き取られる。

・到達するデータより読み取るデータの方が多ければバッファはあふれずデータはちゃんと読み出せる。

・到達するデータが読み取るデータより多ければいずれバッファはあふれる。

ってかんじでしょうか。絵に描かないとわかりづらいかも(^_^;)

よって, デメリットはデータレートとソフトで読み出せる速度を考えないとデータが壊れるという事でしょうか。これはボーレートをいじればある程度解決する問題ではあるんですけどね。

メリットとしては, 対応してるデバイスが多い, 配線が簡単, 多少のノイズに耐える, くらいでしょうか。非同期通信は回路を簡単にできる分, ソフト面で考えることが多いんですよね…。

　マイコンの設定によりパリティチェック, オーバーランエラーチェック, チェックサム, CRC を行えるので, データの保障もある程度はできます。

I2C

　I2C (Inter Integrated Circuit, IIC) は低速な2線通信バスです。速度で言えばノーマルモード 100kbit/s, fastモードで 400kbit/s ほどです。場合により1Mbit/sでも可能。データ配線(SDA)とクロック配線(SCL)はプルアップされたオープンコレクタ信号で, このプルアップ抵抗を忘れて通信できねーってなる人も多いはず…。こいつのデメリットは, ノイズに弱い, なにより配線長を伸ばせない事でしょう。そもそもオープンコレクタ信号線を1ｍとか引き伸ばすものではありませんね。あくまで基板内通信ですから, 配線をビローンと伸ばしてデバイスを接続するような方法はあまりよろしくありません。あまり配線を長くしすぎるとデータが読み出せず, マイコンによってはI2CのACK信号を待機し続けフリーズしてしまうでしょう。メリットは, 対応してるマイコンが多い, 配線が楽, アドレスを振って同配線で複数のデバイスを共存可能, ってとこでしょうか。あと同期通信なのでデータの送受信タイミング自由に設計できます。

SPI

　同期3線式のシリアル通信インタフェースです。通信速度は数Mbit/sほどまでいけます。I2Cに比べると信号線の本数が増えますが, 配線の長さに!2Cより自由がある印象です。はっきりと定義されている通信ではありませんが, 通信の仕組みはとても簡単で, デバイスを自作するときなんかに一番実装しやすいインタフェースだったりします。デメリットは信号線が増えること, メリットは高速, SS(スレーブセレクト)信号により複数スレーブ対応, ロジックICだけでも実装できるほど単純, くらいですかね。

CAN

　CAN (Controller Area Network) はマイコンやデバイス間が直接通信できる, ノイズに強い車載向け通信バスです。自動車だけでなく, 工業機械やロボットの内部通信にも多く用いられています。マルチホスト通信で, 差動信号線信号線により複数ノード間のデータ通信を行いますので, 40mとか配線を伸ばしても1Mbit/sの通信ができたりします。デメリットは対応しているマイコンがそれほど多くなく外部にCANコントローラを用意する必要があるかもしれない事, メリットは配線長を伸ばせる, データの到着タイミングが保障される, くらいですかね。

Ethernet

　RJ45コネクタでつなげる有線LANとかのアレです。通信プロトコルは工作で使うものだとTCP/IPかUDPじゃないでしょうか。この通信は市販のLANケーブルがそのまま使えるので配線のハンダ付けの必要が無く, またパソコンで最も扱いやすい通信でしょう。WireSharkなどの解析ソフトを用いれば, マイコンから送られてくるデータをPCでモニタリングできたり, ブロードキャストが使えたり, スイッチを使ってデバイスを簡単に増設できたりします。デメリットは, Ethernetに対応してるマイコンが少なく外部にコントローラやパルストランスを用意する必要があること, ホストコンピュータの処理処理, OSの状態によっては通信が停止したり, 数百msの遅延やジッタが発生したりすること, バッファを適切に設定しないと通信速度がモロに低下するなど。メリットは, デバイスの増設が楽, PCでモニタリング, 制御が簡単であることくらいですかね。

Parallel

　パラレル通信です。回路の配線引き回し設計は慎重に行わなければ成りませんが, 大抵シリアル通信より高速にデータ送受信ができます。また, GPIO (汎用入出力)より簡単に実装できますので, どのマイコンでも実装できます。マイコンによっては専用のパラレル通信コントローラが載ってる場合もありますが, 基本的にIOレジスタを叩くだけで通信ができるので特別なコントローラ無くデバイスを制御できます。デメリットは, 配線本数がデータのビット数に応じて多くなること, メリットは高速に通信できること, どのマイコンでも実現できること, デバイスによって自分で通信規格を実装できること, くらいですかね。

WiFi

　WiFiです。

Bluetooth

　Bluetoothです。

Zigbee

　IEEE802.15.4で規格化されている低速短距離無線通信。日本だと電波法的に2.4GHz帯なので普通に混信しますが, Zigbeeモジュールなんかは簡単に手に入るのでとっつきやすい無線ではあります。

通信インタフェース, 方式の選び方

　各通信を適当に紹介しましたが, どれもメリットデメリットがあって使う場所と場合を考えないといけません。でないと, 弊学ロボコン部みたいに通信で詰むことになりますのでw といっても, どれもこれもコントローラの性能やソフトの処理によって大きく左右されるので, それもディベロッパーが考慮しなければなりません。

　まず, データの信頼性を保障したい場所 (この場合は, データが届くか届くかではなく, 届いたときにデータ壊れていない事) ではUART, Ethernet(UDP), SPI, パラレルは適さない場合が多いですね。まぁ, エラーチェックがあるかないかで大きく変わるところがあるので微妙なんですけど^^;　データの内容を保障できるのは I2C, CAN, Ethernet (TCP/IP) ぐらいでしょう。

　データの時間的安定性を保障したい場所では, UART, SPI, I2C, CAN, パラレルのどれかでしょう。Ethernetはホストコンピュータの処理によって数ms～数百msの遅延が常時発生しますので, リアルタイムでデータを取りたい場合には向いていません。

　簡単に実装できる事を優先させる場合には, UART, I2C, SPI, パラレルが簡単です。それ以外では専用コントローラが必要になる場合が多いです。

　耐ノイズ性を保障する場合は, UART, SPI, CAN, Ethernet でしょう。

　拡張性を求めるなら I2C, SPI, CAN, Ethernet かな。

　総じて考えると, ロボットのようなリアルタイム性重視でかつ過酷な状況下で動かす事を想定する場合はCANでの通信が一番強そうであることが言えます。まぁ, そうゆう規格ですしね。しかしコントローラの用意が少しばかりめんどうですね…実はArduino Dueでできたりするんですけどね。標準関数だと何故か使えないのでそのうちCANライブラリを公開しようかなぁとも思ってたり。ちなみに, ロボットの制御系全体にEthernetを使ったのが弊学ロボコン部です(^^) こうゆう場面で一番向いてない通信ですよね…ｳﾝ…。

　無線通信の場合, 周りの状況に配慮しないと混信を起こし, まともにデータ通信できなくなります。例えば人ごみの中でWiFi通信をしようとすると, 大量のスマホからアクセスポイント等情報が飛んできまくり絶望します。Bluetoothも同じです。この場合は, 800MHz帯等周りが使ってなさそうな帯域の無線通信をするなどして解決するしかないでしょう。ロボコン会場でWiFi, Bluetooth通信を使ったのが弊学ロボコン部です(^^)

通信インタフェースまとめ

　結論 : 必要な利点と必要でない利点を良く考えて通信方式を選ぼうね！！

組み込みプラットフォーム

　場所と場合によってデバイスを選択する能力によって, 今後の開発効率やできる事, モチベが大きく変わってきます。(まじです。)　結論から言えば「慣れてるデバイスが一番！」に限るんですが, 案外そうは行かないこともあるんですよね。例えば, 慣れてるデバイスだと実装したい機能が実現できないジャン！とか。

　組み込みプラットフォームを選ぶ基準は大きく次のようだと考えます。

・処理速度は十分か

・機能は十分使いやすいか

・インタフェースの量は十分か

・ドキュメントは充実しているか

・開発環境が使いやすいか

・開発に慣れているか

　僕の判断基準では, 例えば

・LEDの点灯, リレーの駆動やパルス生成等レベルの低い分野, リアルタイム性が求められる場面

→ AVRマイコン, FPGA, PIC16, PIC24等

・それより少しレベルの高い領域 (簡単なベクトル計算, 三角関数など多用する場面)

→ SAMマイコン, STMマイコン等 ARM Cortex M シリーズのコアを搭載したリアルタイムマイコン

・さらに少し高度な処理 (リアルタイム信号処理, DSP等)

→ i.mx RT ファミリーやdsPIC等

・更に高度なアプリケーション寄り処理 (LCDの描画, アプリケーションの実行等)

→ PIC32 や i.mx 8 等 Cortex Aシリーズコア搭載チップ, FPGA

って感じですかね。

　これらは全てプラットフォームの性能で判断しましたが, これだけでは不十分な場合があります。それは, 使いやすいアーキテクチャになっているか, 開発環境やドキュメントが充実(可読性が高い資料が豊富)してるかも重要な要素だからです。

　アーキテクチャに関しては, 十分なメモリとコアの性能, ペリフェラルの性能が必要なのは大前提で, 結構気になるのはペリフェラルの使い方です。基本コントロールレジスタで制御することになると思いますが, この辺の設計が変だと開発で変な時間もってかれます。

　開発環境について, これはあくまで僕の意見ですが, Arduino IDEは非常に簡素なUIで操作も簡単, リファレンスも日本語で充実してますので, Arduino = ちょっとしたテストや脳死で実装できる部分に使おうって感じになってるんですよね。ST Micro の CubeMXはGUIにも関わらず十分高度なコンフィグレーションができますし, サードパーティのエディタやドキュメントも充実してますので, 本格的に実装したい部分, とにかく開発速度を得たい部分なんかに使います。FPGA使うときなんかもQuartusは分かりやすいと思いますし, ちょっと動かしたいときにシミュレーションからコンフィグレーションまでパパッと実現できます。

　ちなみに, Microchip 製品 (PICとか) は個人的に好きではありません。MP Labはメモリは無駄に食いますし, Harmony等, コンフィグレータにもバグが多いですし。なによりドキュメントが冗長でクソ読みにくい…エラッタも多くてどうも使う気になれませんね…。(といってもPIC32はMZをちょっと触った限りですが^^;)

　現に弊学ロボコン部でも, 回路班がPIC32とMP Labに苦しめられてましたからね。アレに関しては, 素直にPICを切り捨ててARMに移行してた方が時間もコストもかからなかったように思いますが…。できないプラットフォームに執着するより一般的で親しみやすいプラットフォームを探して移行する方が賢明ですよ。ホントに。

組み込みプラットフォームまとめ

　結論 : 身の丈にあったプラットフォームを探そう！

おわりに

　はい, これら全て僕の意見なので, あんまり鵜呑みにしないほうが良いかと思います。結局は, 手を動かして地道に最適解を探すしかないんですよねぇ…。変な先入観や周りの意見にとらわれていると, 結果として後悔することになりますし。にしても, 私個人としては, 後輩, チームメイトなんかには経験を伝えることしかできませんのでね。難しいところです。。

2018-12-17

デジットのちっこいCRTを動かす <輝点編>

　こんばんは, 先ほどお風呂で寝て溺れ死にかけてました。なんだか久しぶりに命の危機を感じましたねぇ、ええ。まぁそれは良いとして, 今回はちっこいブラウン管を動かしてみましたので書いておきます。

　ちょっと前に学校の校外研修(という名の遠足)で神戸へ行ったんですが, その時大阪日本橋のデジットさんでちっこいCRT(ブラウン管)をゲットしました。物はコレ、M01KUA07WB30 です。

eleshop.jp

　商品説明にあるように, 古いカメラのファインダー用のものと思われます。とにかく小さいです。なので勝手にマイクロCRTって呼んでますw 表示面の面積は1円玉より小さいです。正直, 映像を映しても実用レベルにはならないんじゃないかと思います。それこそファインダーみたいに目の前に持ってくるような工作でないと(^_^;)

f:id:Kamomesan:20181216232632j:plain — マイクロCRT

　黒いカバーみたいな部分は表示面の多くを隠してしまっていて邪魔だったので, ジクロロメタンで樹脂を溶かし, 外してしまいました。これで古き良き丸いCRTになりましたね。

f:id:Kamomesan:20181216232705j:plain — はがれたノリ

　んで, 今回はこいつを何とか動かして, 輝点を表示させるとこまでやりました。ちっこいとはいってもただのCRTなので, 各ピンを適切にバイアスすれば動くはずです。割れてたりしなければネ()　この管の場合, 次の図に示すピンが生えています。偏向ヨークの配線は除いています。

f:id:Kamomesan:20181217002328p:plain — 構造

f:id:Kamomesan:20181217003726p:plain — ピンアサイン

　この管, ネットを漁っても仕様があがってなくてどうしようと思ってましたがもうメンドクサイので勝手に調査してしまいました^^ 上のピンアサインの図は管のおしりから見た図です。各端子の電圧をいじって, それぞれ微妙に動きそうな電圧と, 破壊しそうな電圧の間を取る方式で値を求めました。

・フィラメント電圧 : 2.2 ~ 3.0 [V]

・カソード電圧 : 0[V]

・制御グリッド電圧 : -20 ~ 0 [V]

・収束グリッド電圧 : -20 ~ 500[V]

・アノード電圧 : 1000 ~ 2500[V]

　フィラメントは2Vでもけっこう明るめに光ります。フィラメントの端子間抵抗は大体 20 [Ω] 程度でした。フィラメント電源を設計する時はこの抵抗値を考えなければいけませんね。3V以上は蛍光面にフィラメントからの光が現れてしまったので, これ以上あげても無駄でしょう。

　カソード電圧は 0 [V] 固定, 制御グリッド, 収束グリッド電圧はそれぞれ十分に操作できる電圧レベルということで -20V [V] を最小値に。アノード電圧はフィラメント電圧 3 [V] の時に 1000 [V] 程印加してうっすら輝点が表示されるくらい, 2500 [V]以上となると内部でよろしくなさそうな放電が起きたのでまぁこの範囲でしょう。

　てなわけで, 印加する電圧は全部で下図のようになります。

f:id:Kamomesan:20181217011020p:plain — かいろず

　とにかくこの通りに電圧かければ輝点がでます。初めの試験では制御グリッドと収束グリッドはGND (0 [V]) で良いかもしれません。うっすらと輝点が出たら, はっきり見えるように各グリッドの電圧を調整しました。

　輝点を表示するだけならアノード電圧とフィラメント電圧だけ生成できれば十分なので, 早速そこらへんに落ちてたユニバーサル基板とCCFLインバータ用のコア&ボビン, トランジスタ等々で昇圧回路を組んでみました。簡単な自励式トランス昇圧回路です。後々グリッドを使うことを考えてアノード電圧以外に -20 [V] , 200 [V] 用も出力できるようにしておきました。

f:id:Kamomesan:20181217001209j:plain — ほそい！！

　アノード用高圧巻線はφ0.1mmのUEWを使いました。とにかく細い！！そしてブチブチ切れる！！巻き終わった頃には目がしょぼしょぼになってしまいました(*_*)

f:id:Kamomesan:20181217001516j:plain — 自作したトランス

　コアを固定するのに接着剤では不十分そうだったので元の固定テープもそのまま流用しました。両サイドの汚い巻線はグリッド用の巻線 + フィードバック巻線です。1次巻線は 25 + 25 [turn] でセンタータップ付き, 2次アノード巻線は正確にはカウントしてませんが 2000 [turn] くらいでしょうか。フィードバック巻線は 3 [turn], グリッド用巻線は 30 + 30 [turn] です。

　フィラメント電圧はこれまたそこらへんに落ちてた3.3 [V] レギュレータを使いました。

f:id:Kamomesan:20181217002044j:plain — できた回路とマイクロCRT

　(回路図お待ちください！)

はい, 輝点がでてますね。電子銃で熱電子が加速し, 蛍光塗料を発光させられている証拠です。あとは偏向ヨーク (電子の軌道を曲げる電磁石) に信号を入れれば, 輝点の位置を自由に変えられますので, これで映像なりリサジュー図形なり表示できます。

　ここで, スマホのイヤホン出力で偏向ヨークを駆動し, 音楽の波形を表示させてみました。

音の波形も映せた
スマホのイヤホン出力で直接偏向ヨーク駆動してるw pic.twitter.com/K3SH70bBaj
— Hkat (@Fushi1212) December 16, 2018

　ちゃんと音に同期して波形が変化してますね。ちなみに, この映像では収束グリッドの電圧も調整ししっかりピントを合わせた状態で動かしています。収束グリッドをとりあえず 0 [V] とかにしてる場合はマイクロCRTの個体差なんかで輝点の状態が大きくかわるかもしれませんので, 電源入れてもガッカリせずに, ピント調整を行ってみましょう^^

　と, いうわけで輝点の表示ができましたので, 今後映像やら図形やら表示できればなぁとおもっています。いつになるかは知れませんが(^_^;)

～適当な工作情報を投げるブログ