私家版PYNQ FAQ（購入前）

先日オープンソースカンファレンス2016東京でIkaLogを出展した際、PYNQ-Z1をIkaLogのデモ用ハードウェアに利用したのですが、その際に色々と質問されることがありました。今回はPYNQ-Z1がどのようなものなのかについて、私の偏った視点から紹介します。

PYNQって何ですか？

PYNQというのは、基板やLSIパッケージではなく、Xilinx社が提供する「Jupyter Notebookから使えるFPGAデモシステム」を指しています。以下はXilinx社が公開しているPYNQプロジェクトの概要を引用したものです。

PYNQ is an open-source project from Xilinx that makes it easy to design embedded systems with Zynq All Programmable Systems on Chips (APSoCs). Using the Python language and libraries, designers can exploit the benefits of programmable logic and microprocessors in Zynq to build more capable and exciting embedded systems. PYNQ users can now create high performance embedded applications with

• parallel hardware execution
• high frame-rate video processing
• hardware accelerated algorithms
• real-time signal processing
• high bandwidth IO
• low latency control

See the PYNQ webpage for an overview of the project, and find documentation on ReadTheDocs to get started.

PYNQ-Z1って何ですか？

PYNQ-Z1はDigilent社が販売するARM搭載FPGAボードであり、Xilinx社のPYNQに対応しています。以下はDigilentが紹介しているPYNQのスペックです。

ZYNQ XC7Z020-1CLG400C:

• 650MHz dual-core Cortex-A9 processor
• DDR3 memory controller with 8 DMA channels and 4 high performance AXI3 slave ports
• High-bandwidth peripheral controllers: 1G Ethernet, USB 2.0, SDIO
• Low-bandwidth peripheral controller: SPI, UART, CAN, I2C
• Programmable from JTAG, Quad-SPI flash, and microSD card
• Artix-7 family programmable logic
• 13,300 logic slices, each with four 6-input LUTs and 8 flip-flops
• 630 KB of fast block RAM
• 4 clock management tiles, each with a phase-locked loop (PLL) and mixed-mode clock manager (MMCM)
• 220 DSP slices
• On-chip analog-to-digital converter (XADC)

Memory:

• 512MB DDR3 with 16-bit bus @ 1050Mbps
• 16MB Quad-SPI Flash with factory programmed globally unique identifier (48-bit EUI-48/64™ compatible).
• MicroSD slot

Power:

• Powered from USB or any 7V-15V source (see recommended products)
• USB and Ethernet:
• USB-JTAG Programming circuitry
• USB-UART bridge
• USB OTG PHY (supports host only)
• Gigabit Ethernet PHY

Audio and Video:

• Electret microphone with pulse density modulated (PDM) output
• 3.5mm mono audio output jack, pulse-width modulated (PWM) format
• HDMI sink port (input)
• HDMI source port (output)

Switches, push-buttons, and LEDs:

• 4 push-buttons
• 2 slide switches
• 4 LEDs
• 2 RGB LEDs

Expansion Connectors:

• Two standard Pmod ports
• 16 Total FPGA I/O
• Arduino/chipKIT Shield connector
• 49 Total FPGA I/O
• 6 Single-ended 0-3.3V Analog inputs to XADC
• 4 Differential 0-1.0V Analog inputs to XADC

搭載されているはXC7Z020-1CLG400Cというもので、デュアルコアのARMプロセッサが搭載されたFPGAパッケージです。そこにLEDやスイッチ、Arduino互換のペンヘッダ（メス）、HDMI入出力、オーディオコーデック（コンピュータエンジニア的にはサウンド用DAC/ADCといったほうがピンときそう）、Digilentが提供する拡張基板が接続できるPMODヘッダなどが搭載されています。

SDカードスロットが搭載されており、ここからLinux環境をブートしてLinuxマシンとして利用できます。ARMプロセッサにイーサネットポートとUSBホスト用コネクタが接続されていますので、この部分は組み込みARMプロセッサとしても利用できます。

Raspberry Pi とのARMプロセッサの比較は？

CPU

• ZYNQ: ARM7 2cores、650MHz
• Raspberry Pi 3: Cortex A53、4 cores、1.2GHz

Memory

• PYNQ: DDR3 512MB
• Raspberry Pi 3: LPDDR2 512MB

GPU (Framebuffer)

• PYNQ: なし
• Raspberry Pi 3: あり

H.264/MPEG2ハードウェアエンコーダ／デコーダ

• PYNQ: なし
• Raspberry Pi3: H.264デコード、エンコード(追加オプション)、MPEG2(追加オプション)

ネットワーク

• PYNQ: イーサネット
• Raspberry Pi 3: イーサネット(有線、無線)

PYNQ向けの設計・開発に必要なソフトウェアは？

ロジックの設計Xilinx Vivado HL Design Design Suite（Eclipseのような設計環境）のWebPack Editionが無償で利用できます。最近は、無償ライセンスでも機能制限が緩くなっており、評価ボード上のXilinx FPGAパッケージ（最上位のVirtexを除く）を相手に開発する程度であれば不自由なく使えるようになりました。高位合成についてもVivado HLS が 2016.2 あたりから無料で利用できます。ただし、WebPack Editionはツール利用状況の統計情報がXilinx社に吸い上げられます。

Xilinx Vivado HL Design Suite によってFPGA向けのビットストリーム（コンピュータのバイナリファイルに相当）生成処理は非常に重いため、できるだけ高クロック多コアで快適な開発環境（Linuxを強く推奨、もしくはWindowsでも利用可能）が必要になります。Vivado HL Design Suiteはインストールにおよそ20GBの空き容量が必要です。

PYNQで提供されているビットストリームは現在バージョン2016.1向けになっています。より新しい2016.2、2016.3も提供されていますがPYNQのプロジェクトを実行できませんのでPYNQ前提でVivado Design Suiteをインストールするのであれば2016.1をインストールすることをオススメします。なおディスク容量があれば複数バージョンをインストールすることも可能です。

PYNQどこで買えるの？いくら？

Diglientのサイトから購入できます。

http://store.digilentinc.com/pynq-z1-python-productivity-for-zynq/

本稿執筆時点で通常価格229ドル、学生向けには65ドルで販売されており、一人一台までの制限があります。送料が5000円近くかかるそうなので購入時は複数の方でまとめてオーダーし小口数をまとめてもらおうとしている方々もいるようです。経験上オーダーを確定してから２〜３日で日本まで届きます。

購入する場合には、オシロスコープをお持ちでない方には、Analog Discovery 2の同時購入がをオススメしています。AD2はUSB接続し利用できるオシロスコープ／ロジック・アナライザなどとして利用でき、FPGAのほか各種電気回路を作ったときに波形を見るのにも使えるからです。アカデミック対象であれば割引がありますし、Analog Parts Kitは学生による同時購入に限り無料で販売してくれるようですのでぜひ入手してください（私は持っていません）。

オシロやロジアナ皆無でFPGAや電子回路をいじるのはprintfデバッグすら封印して一発で複雑なプログラムを完成させようとするようなものです。

私が持っているのは初代Analog Discoveryですが、実際持っているとすごい便利なのでとってもオススメです。

PYNQを買ったので遊んでいる（Project Inq）

久々にFPGAいじりをしています。

今回入手してしまったのはPYNQ。Xilinx Zynq7020シリーズを搭載した評価ボードで、あらかじめ用意されたイメージをSDカードに書き込んであげればJupiterからWebブラウザ経由でもいくらか操作を試せるというお手軽さがウリ。



届いたPYNQのパッケージ

秋葉原の職場に送ってもらったので、受け取ったら早々と部品やでヒートシンクと熱伝導シーツを調達。

SDカードにイメージを焼いて起動したら、当然とはいえ、普通にヘッドレスなARM7 Linuxマシンとして起動してきた。OSはUbuntu 15。 OpenCVは 3.1 で、FFmpegサポートも入った状態でコンパイルされている。……これは色々と便利なのでは？

試しにIkaLogでビデオファイルを解析させてみたら、あっけないほど簡単に動いた。

PYNQにはビデオキャプチャ利用を想定したHDMI Inputポートがあるので、これでキャプチャできるかは大変興味があるところ。Jupiter上でOpenCVの顔認識をするコードを途中まで実行したら、WiiUの画像がキャプチャできた。



ただしPYNQのbase.bitではDDCの応答内容に問題があるのかWiiUからビデオ信号が出てこない。このためHDMIマトリックススイッチやスイッチャーなどの機械を挟んでいる。また、720pだと色々安定していないような感じ……。過去に試していたとき、ZYBOではDigilentのdvi2rgbのEDIDを書き換えたらWiiUの信号を直接、安定して食えるようになったので、そのときの成果を持ってくれば解決するだろう。だいたい解決策は見えているので後回し。ちなみに以前ZYBOで実験していたときの写真がこちら。

自作HDMI-RGB回路でWiiU画面うつるようになった。 pic.twitter.com/kMH2UQH0NL

— もつなべおじさん (@hasegaw) 2015年12月5日

Jupter で操作した内容を IkaLog の映像インプットとして使えるようクラスを追加して、とりあえずだけども対応完了。
https://github.com/hasegaw/IkaLog/commit/5b6b9ce55e1ae32e57c2dd6f05ae20aa00c9b3fd

HDMIのキャプチャは実現できたが、PYNQにはHDMI Outputもあるので、こちらにパススルーすると、PYNQがIkaLogマシン＋ビデオキャプチャ＋HDMIスプリッタを兼ねるという、いままでIkaLogを利用するにあたって必要となる３つのアイテムをワンボードで実現できることになる。

Pynqのドキュメンテーションを読んでいると、じつは上記の設定でHDMIパススルーも実現できていることがわかった。上記の設定を行うとOut側がIn側のバッファからデータを受け取るようなかたちでパススルーしてくれる（プロセッサは通していないと思う……フレームバッファは通しているかも？）

というわけで、数時間でできちゃったIkaLog+PYNQ（キャプチャ機能＋映像のみスプリッタ機能）。

PSoCが可能にした、10Wで動作する #IkaLog Hardware（ARMアーキテクチャ、HDMIキャプチャ／スプリッタ内蔵）の Proof of Concept です。ご確認ください。リアルタイムで解析したデータはこちら https://t.co/2zbp1yl5bk pic.twitter.com/osoKH4S0W8

— もつなべおじさん (@hasegaw) 2016年10月15日

Pynqで動くIkaLog、Project Inqと命名。Pynqの利用用途として思いついてはいたけども、思った以上に簡単に実装できてしまった。ここまでの成果については下記 WIki ページを見ていただければ再現できるはず。
https://github.com/hasegaw/IkaLog/wiki/en_Installation_Pynq

これをしばらく動かしてみるといくつか課題が見えてくる。

一つ目の課題は、HDMI Outputから出力された映像がたまに縦にずれたりする。たぶんHDMI映像の伝送が、ARMのDDR3メモリに置かれたフレームバッファを介していて、IkaLogが走っているとメモリ帯域やバス幅が足りなくなるんじゃないかと疑っている。

二つ目の課題は、HDMIのスプリッタ機能といっても HDMI 信号を音無しの DVI 信号としてピクセル情報に落とし、それを DVI 信号として HDMI ポートから出しているだけなので、音が消えてしまう。もちろんレイテンシの問題もあるし、キャプチャ機能はそのまま使うとしても、 HDMI Input から入ってきた信号をできるだけ忠実に HDMI Output に出力するよう変更したい。

Xilinx FPGAなのでHDMIのシリアル信号をISERDESE2で受けて、出力するときはOSERDESE2で送信している（はず）。これらを直結すればナノ秒レベルのディレイでシリアル信号をそのまま伝達できるだろうけど、ビデオキャプチャ機能も必要なので、dvi2rgb IPと共存することは考えないといけない。

とりあえずPYNQについてきたbase.bitは忘れて、dvi2rgb -> rgb2dvi でパススルーするデザインを作ってみた。



WiiU の信号が直接映らないのは相変わらずだけども、画像がたまに縦に１ドット間延びするような現象は解決した。ARMプロセッサ側のDDR3メモリを介さずに、受け取った信号をそのまま送出しているからだろう。

でも、やはり音のデータは消えてしまっている。

手元に高速ビデオ・インターフェース HDMI＆DisplayPortのすべて という書籍があった。


これを読み返してみると、オーディオ信号はVSYNC直後のブランク期間などに入っているとのこと。ここが現状どうなっているかを調べると、色々解決しそう。 dvi2rgb がブランク期間中の信号を捨ててしまっているのではないかという想像だ。もし信号が捨てられていない事が分かればラッキーで、今度は送出側 rgb2dvi が信号を捨てていると考えればよさそう。

Integrated Logic Analyzer を追加して信号を眺めてみる。





案の定 dvi2rgb がブランク期間中の信号をゼロでマスクしているようだ。この 000000 になっているところに、本当はオーディオ信号も乗っているはず。ここにあるはずの信号も含めて rgb2dvi の OSERDESE2 に流し込んであげれば、きっとオーディオ含めてスプリッタとして動作してくれるだろう。

とりあえずの調査はここまで。

買って良かったと思った家電製品ベスト３

度々まわりにお勧めしている便利な家電ベスト３を紹介してみる。持っていない人は是非トライ！

1. 超音波電動歯ブラシ ソニックケア

2004年の就職当時、職場の人から「長谷川くんはコーラ星人だね」っ て言われたことがあるほどにコーラというか炭酸飲料が好きだ。コーラを飲むとどうしてもカラメルが歯にこびりついてしまいネトネトするし、それが、歯並び が悪いせいで磨きづらい隙間にいっぱい残るので虫歯もできやすい。歯医者に教えてもらって知ったけど、唾がビヨ〜〜〜ンとのびるのは糖分が口の中にある証 拠だそうで。歯は綺麗な状態だったら触るとキュッキュッとなるけど、なかなかそこまで磨くのは手間がかかる。歯磨きが面倒で糖分を避けてみた時期があった けども、力が出なくなってしまったので、ある程度の甘い物は必要なんだなあと悟った。

ある日ソニックケアを購入したところ、歯磨きにあれだけ苦労していたのに、ソニックケアならコーラを飲んでもすぐに歯を綺麗な状態に磨けることに気づいた。ソニックケアは安いのなら１万円もしないし、効率と虫歯リスク減らせることを思えば即買うべきだと思う。

同僚にその話をしたところ「ボクは○○○○○ｏ○の電動歯ブラシを使っていますよ」と言うけども、ソニックケアに買い換えさせたら、その後、使い始めてとても感動していた。まあ最終的にどれが合うかは人それぞれだろうけど、ソニックケアはお勧めだと思う。また何種類かあるけども、複数モデル使ってみたかんじ、自分は一番安い本体でも十分だったので無理に高い本体は買わなくてもいいと思う。

2. 乾燥機能付き洗濯機

2006年、社員寮（浴室乾燥つき）から追い出され、その直後に雨の日が続いて洗濯物が乾かず閉口し、わずか２年しか使っていない洗濯機を下取りに出して買い換えた。

購入したのは日立の白い約束 洗濯7kg／乾燥4kgのモデル。7kgは実家で家族4人の洗濯物をさばいていたサイズなので一人暮らしには相当おおきいように思えるけど、乾燥4kgの部分でサイジングした。洗濯機の設置場所がかなり狭くて、搬入出時には事前に物件のドア（木ネジで蝶番が固定されている）を外しておかないといけなかった。

乾燥機能つき洗濯機を買ってからはユニクロの下着や靴下、タオルなどは全て乾燥機能に任せている（寮時代も浴室乾燥に任せていたけど）。家事に時間をかけたくないし手間が大幅に減るので、社会人になる人には間違いなく乾燥機能つき洗濯機を購入してほしいと思う。

ただの温風ではなく、ちゃんと乾燥できるモデルを調べた上で購入しないと痛い目に合うかもしれないので、 2ch とかで購入時の乾燥機能付き洗濯機の最新機種をチェックしよう。一人暮らしなら、イニシャルコストと稼働頻度を考慮して、ヒートポンプ式でなくてもヒーター式水冷除湿タイプでいいと思う（私が持っているのは、このタイプ）。

3.ノイズキャンセリングヘッドホン

 2011年、出張ではじめて海外 に出たとき、ソルトレイクシティ（実際には隣のパークシティ）のアウトレットモールにあるBOSEの店舗にて QC-15 を購入。当時は円が非常に強くて90円をきっていた ので、日本円でたぶん2万5000円をきっていたように思う。少なくとも3万出した覚えはない。購入時は半信半疑だったけども、使い始めてコレがすごく便利なものだと判った。

このヘッドホンを使ってい ると、飛行機のなかで10時間とか過ごしていても騒音をかなり軽減してくれるので、ぐっすり眠れる。なぜか私はこのヘッドホンで L'arc-en-Ciel の曲を再生していると本当にぐっすり寝てしまうので、はじめての出張の帰路から飛行機での移動があまり苦痛に感じなくなった。サングラスやアイマスクと組 み合わせると完璧。

また、深夜バスで青森にスキーに行くときにも重宝する。バスの走行音が大幅に軽減される。２１時 頃出発のバスが７時頃に青森につくので９時間はバス内で揺られることになり、昔は本当にこの時間が辛かったけども、 QC-15 を使うようになってからは移動時間のほとんどはぐっすり寝てしまうようになった。

QC-15 は二度断線して修理に出した。どちらも保証期間を過ぎていたので1万円ちょいの金額を支払うことで良品への交換をしてもらった（二度目は追加料金で現行モデルへの QC-25 にアップグレードしてもらったので、今使って居るのは QC-15 ではない。製品＋このあたりのアフターケアも良いのでブランドバリューがあるんだなと思った）。

移動時間がとても快適になったので、長時間移動が多い人はノイズキャンセリングヘッドホンは是非もつべきだと思う。まあ、モデルによるけども、国内市場価格 3万円後半〜 4 万円後半は、私自身でも手は出せないかな……。海外にて、国内市場価格より安く手に入りそうだったら、検討すると良いと思う。

とある素晴らしいオンラインソフトウェアにおける、シェアウエアとしての形態

この記事はこのソフトウェアに対する文句とかではなくて、ただただ”ソフトウェア開発に費やしている技術も、それのマネタイズ の方法もうまいなぁ”と思って関心している、特定のオンラインソフトウェアの話で、別に作者を晒し上げようとか、そんなつもりは全くない。このソフトウェアは対価を支払う価値は十分にあるし、作者が下記のとおりに書いていないのは意図的だと思うから、特定のソフト名はここでは書かないことにした。

某 Slack でとあるシェアウエアがよく考えられているという話をした。

そのソフトウェアは、ビデオキャプチャデバイスと組み合わせて利用するもの。プレビューのほか録画機能も持っている（名前的にはそちらが主眼なのだろう）。ただ録画機能を持つソフトウェアだが、独自の突出したコーデック部分が別配布になっている。

メインの実行ファイルが入っているソフトウェアを実行するためには、別途配布されているコーデックもインストールしておく必要がある。技術的には、そのコーデックをインストールしておかなくてもメインの実行ファイルは動作するはずだ。でも、コーデックがないと実行できないよ、とエラーを表示して、終了する。

そうするとユーザーはコーデックとして配布されているパッケージをインストールしようとする。そのコーデックは有償で、数千円と、けっこういい値段が付けられているソフトウェアだ。コーデックはシェアウエアの形態なのでレジストしなくても利用できるが、未レジストの場合にはウォーターマークが表示される仕様だ。

私は２０１２年にこのソフトを見つけて使い始めたけども、この作者はほんと凄いなぁと関心した。技術的にもよくできているし、稼ぎ方もうまく考えているなぁと思ったから。

過去に bt878 のテレビチューナーを使ったときはソフトウェアスタックが本当にダメだったし、 2012年に購入してから IkaLog 開発にまで活躍してきた DC-HD1 でも、ドライバがおかしいんじゃないのって死に方をよくする。今時の Windows ってそう簡単にブルースクリーンなんて出ないけど、キャプチャまわりをいじっていると、けっこう死ぬ。キャプチャまわりは絶対的にユーザ数が少ないので QA が十分にできていないんだろうなぁと推測している。 Webcam の利用数は相当数あるだろうし、そっちの問題は比較的少ないと思うと、やっぱりチップセット側のドライバの問題なんだろう。

で、ちょっと操作した瞬間にドライバが OS を道連れにするような実装が度々あるキャプチャデバイス群を使って映像を取得し、リアルタイム表示もわりと低遅延でがんばっていて、画像処理もまじめにやっていて、さらにはコーデックまで独自に提供してしまうソフトウェアがあるわけだけど、これが、コーデック以外の部分は事実上フリーソフトとして使えるようになっている。

独自形式で録画時・再生時に使うコーデック以外の機能も充実しているのでコーデック部分に課金するのはチャンスロスが大きいんじゃないかと思う人は度々いるはずだけど、これがなかなか良く考えられていると思う。なぜなら、キャプチャデバイスとの相性で起動できなかったり、映らなかったり、 OS を道連れにしてしまうような部分では課金していないのだから。課金対象は、 DirectShow 向けのコーデックとして、 OS から渡された画像データをエンコードしたり、デコードしたりして OS に返す部分だけ。ここはハードウェアが絡まないので相性問題などは発生しづらい。なので、課金したユーザが「金払っているのになんなんだコレは」と言っても、買ったのはコーデックであってキャプチャデバイスを制御するソフトウェアではない、というカラクリ。

 購入サイトには直近のレジスト数の情報がでていて、一日に１０ライセンス以上、どんどん売れているように見える。このペースだと下手なコンピュータエンジニアの月給を超える副収入が生じているはず。開発者の収入は給料の倍になっているかもしれないし、そのソフトウェアの出来を思うと、本職では余裕でもっと稼いでいる人かもしれない。

巧いなあと思いつつも、ちょっとずるい気もする。なぜなら有償のコーデックを使わないと動かないような文面がサイトにあって、それがインストールされていないと、それ以外の部分も利用できない点。文面を素直にとると、多くの人は、そのソフトウェアを動かすためには有償のコーデックを買わないといけないように理解するだろう。実際にはコーデックにレジストしても、録画時のウォーターマークが消えるだけだ。録画を主眼に置いていない人はコーデックにレジストしなくても十分に使えてしまうし、他のコーデックを組み合わせて使えば回避はできる。

私も実際コーデックを買わないと使えないのかと思ったけど、とりあえずレジストせずに動かしてみて、この仕組みを理解して、ちょっと感動した。

このソフトウェア（の事実上フリーな部分）は DirectShow のほか Direct3D をはじめ各種マルチメディア系の API を駆使しているのは見ればすぐにわかるし、開発には相当時間がかかっているのがわかる。キャプチャデバイスをいっぱい持っていて、リリースにあたっては動作検証やドライバ不具合との戦いも色々しているのだと思う。また、有償提供されているコーデックも、これはこれで動かしてみるとすごい。 確証はないけど、とあるユーザの手元でにある Core2 Duo のマシンですら IkaLog を動かしながら録画ができてしまうのは、たぶんコイツのおかげなんだと思う。

ところで時々”どうして IkaLog で金を取らないのか”と聞かれるけども、 IkaLog もキャプチャデバイスと組み合わせて使うものでソフトウェアの実装レベルで互換性を全て吸収できるようなものでもないし、仕組み的に環境依存で動かないことも考えられるので、そのような場合にはサポートしきれない、また画像認識というアプローチ上１００％の精度は出せないという気持ちがあった。下手にマネタイズしたら怒られるかもしれないというのも。

 Web カメラ対応をまじめに考えていたときは、高品質な Web カメラの代わりにスマートフォンに付いている高品質 CCD カメラを使え、IkaLogに画像を送信するだけの「イカログカメラ」は有償化しようと思っていた。結局、Webカメラベースでの画像認識はチャレンジが多かったので、それ自体を無くしてしまったけど。

ルータがPPPoEで取得しているIPアドレスが変わったらRoute 53のレコードを更新するスクリプト

リモートから自宅のネットワークに接続できるようにしている方も多いと思いますが、ウチも出先からリモートアクセスしたりしています。

これまで外部の Dynamic DNS サービスに頼っていたのですが、利用していたサービスに変更があったのをきっかけに自前の仕組みに置き換えました。今回は、その仕組みについて紹介します。

私の自宅では RTX1100 が上流ネットワークとの PPPoE 接続を行っており、 pp 1 インターフェイスが外側のアドレスを持っています。このインターフェイスのアドレスを、自分が Amazon Web Services の Route 53 上で管理するゾーンのAレコードとして登録します。

ちょっと面倒だったのが RTX1100 の外側 IP アドレスの取得をどうするか、です。最初は 「SNMP クライアントでつっつけば出てくるじゃろ？」と適当に snmpwalk してみたのですが、よくわからなかったので、結局 telnet で調べるローテクで実装しています。

使っているコードのうち自宅依存部分を取り除いたものを https://github.com/hasegaw/route53update に Push してあります。


この中には3つのファイルが含まれています。

• rtx1x00_show_status_pp_1.exp …… RTX1100 と telnet して IP アドレスを取得する
• route53update.py …… 取得したアドレスを R53 に反映する
• run.sh …… 実行方法

rtx1x00_show_status_pp_1.exp

RTX1100 に telnet して IP アドレスを取得します。このスクリプトは実際には RTX1100 と通信して、その内容を標準出力に書き出すまでです。実行には expect が必要です。引数としてホスト名とパスワードをとります。



route53update.py

上記 Except スクリプトを実行し、ルータからの出力を実際にパースし、 Route 53 のレコード内容と比較してみて、必要なら反映するのがこちらのスクリプトです。ファイル内にいくつか設定項目があります。（レコード名、 ゾーン名、ルータのホスト名とパスワードなど）
おまけで Slack にも対応しています。


 run.sh

route53update.py を実行する方法の例です。 AWS の API キーを設定しスクリプトを叩いています。手元ではこのスクリプトを cron に仕掛けています。


定期的にこのしくみが実行されることにより、Route 53 上の A レコードが常に自宅のルータに向くようになります。また、 Slack に新しい IP アドレスが通知されるため、ネットワークの不調に気づきやすかったり、などのメリットがあるかもしれません。

Oculus Rift CV1 をスムーズに迎え入れるためのポイント

?! pic.twitter.com/ECP8tpbZXA

— もつなべおじさん (@hasegaw) 2016年5月1日

ゴールデンウイーク突入早々に Oculus Rift CV1 が届いたのですが、実際に動かせるようになるまで、思った以上に時間がかかりました。

というわけで、自分が Oculus Rift CV1 を入手して色々試した上で、「Oculus Rift CV1 到着前に知っていたら良かったかも」と思ったことをいくつかまとめてみます。

GPU のドライバを最新にアップデートしておく

GeForce や Radeon など GPU のドライバを最新のアップデートしておきましょう。そうしないと Oculus Rift のセットアップが途中で「アップデートするように」と注意されてしまいます。

ドライブの容量をあけておく

Oculus Rift のランタイムをセットアップする際、インストール先のパスを指定します。ここで指定されたパスの下に、今後インストールする Oculus 対応アプリケーションも保存されていきます。このため、 Oculus Rift のランタイムのインストール先は容量に余裕をみておく必要があります。

ランタイム自体が 1.2GB 、さらにゲームタイトルをロードするスペースが必要です（たとえば一作 20GB など）。つまりは100GB程度空きあれば、とりあえずは安心です。別に、足りないならば、コマンドプロンプトでジャンクションきってもいいですけど。

おまけ。私の環境は C: (SSD 50GB空き / 256GB), D: (HDD 1TB空き / 2TB), K: (ioDrive2 200GB空き / 1.2TB) という構成だったのですが、なぜか K: にしかインストールさせてくれませんでした。おそらくインストーラのバグだと思います。
ランタイムのインストーラが、可能なドライブしか表示してくれませんが、そこでなぜか本当に K: しか出てきませんでした。 K: のドライブレターを外したらインストール可能なドライブがひとつも見つからずにセットアップできず、です。なので、私の環境では ioDrive2 に Oculus および関連ファイルがインストールされています...。

CV1 が届く前にランタイムのダウンロードを済ませておく

Oculus Rift ランタイムのセットアップは oculus.com/setup からファイルをダウンロードして実行します（と、ハードウェアとともに届く説明書に書いてあります。）。
このアドレスから入手したインストーラが 800MB 近くのファイルをダウンロードするので、そこでもけっこうな時間待ちがあります。 Oculus Rift 自体がなくてもソフトウェアのセットアップ（ダウンロードおよびインストール）は可能なので、先に済ませておきましょう。

ソフトウェアをインストールした後に Oculus Rift 、センサ、コントローラの設定を行う必要がありますが、そこは実機がないと進めないと思います。

XBox 360 ワイヤレスコントローラがあるなら、 PC に接続しておこう

Oculus Rift CV1 には Xbox One コントローラが付属していますが、これは日本国内だと無線で利用できず、配線が邪魔になります。 XBox 360 用のワイヤレスコントローラとレシーバがお持ちでしたら、そちらを PC に接続して利用すると快適です。

Steam を準備しておこう

Oculus 向けのアプリケーションは Oculus のアプリストアである Oculus Store から購入可能になります。同時に VALVE が運営する Steam でも VR 対応アプリケーションが購入できます。

「どうして Oculus Store ではなく Steam を使うの？」 一部のゲームは Oculus Store で Oculus Rift 専用として独占販売されるようですが、見た感じ Oculus Store と Steam で扱われているタイトルも複数ありました。タイミングによるでしょうが、為替の都合同じタイトルが Steam のほうが安くなっていたりするケースもあります。

また、 Oculus Store で購入したソフトウェアが HTC Vive など他の VR ヘッドセットで使えるのか良くわかりませんが、 Steam で購入したソフトは、対応していればどちらでも使えそうです。また、 Steam では Virtual Desktop など、 Oculus Store に無いけども便利なアプリケーションなどもあります。 Oculus Store にあるものは Oculus Store から買ったほうが楽だとは思いますが、 Steam も準備しておくと色々ナイスです。

 Oculus Rift が届く前に済ませておくべき事は下記４点です。

• Steam のアカウントを持っていなければ、作成する
• Steam クライアントソフトウェアを Oculus Rift のホストとなる PC にインストールする
• Steam クライアントから、Steam VR をインストールする
• 購入を決意しているタイトルがあるのなら、事前に購入してインストールを済ませることも可能

Oculus Rift が到着し、 Rift のセットアップを済ませたら、下記の作業ができるようになります。

• Steam VR のコンフィグレーションを済ませる（そうしなければ、 SteamVR が起動に失敗します）
• Oculus の設定画面で「Unknown Source」を有効にし、 Oculus Store 以外から入手したソフトウェアも実行できるようにする

それでは、よい VR ライフを。

Oculus Rift と組み合わせて無線式のコントローラを使う

ついにコンシューマ向けの Oculus Rift が発売開始され、日本の予約者の方々のところにも続々と届いているようです。

ただ、日本のユーザにとっては、日本でのみ（？）残念な点として、本来 Oculus Rift に同梱されている XBox One コントローラのレシーバーが省かれ、代わりに USB ケーブルが付いてきています。それでも価格据え置きなのはちょっと残念ですが、まあそれはおいておいて。

XBox One のワイヤレスレシーバは、日本国内で利用できない周波数を使うため、並行輸入品を購入して利用していると、知っているか知らないかに関わらず電波法違反になります。もちろん技適も通っていません。手元で動くかどうかはともかく「使っちゃダメ」、というわけで、 Oculus Rift のパッケージからは日本向けのパッケージに限ってレシーバーが除かれています。

とはいえ、Oculus Rift 本体からは HDMI および USB3.0 のケーブルが出ているほか、 XBox One コントローラを手元にまで引っ張ってくると、ケーブルが増えて邪魔です。 Rift 本体のケーブルはどうにもなりませんが、とりあえずコントローラは無線化することにしました。

これを....

こうじゃ！



写真を見て判る人はもう判ったと思いますが....  Oculus Rift 付属の XBox One コントローラを使わずに、XBox 360 の無線式コントローラを接続して使っているだけです。以前 XBox 360 用の 2 台目のコントローラを買うときに、 Windows マシンにも接続できるよう、 Windows マシン用のレシーバーが付属しているパッケージを購入していました。 いままで一度も Windows でこのコントローラを使ったことはないのですが、 Oculus Rift と組み合わせて使うために、今回はじめてレシーバーを Windows 10 マシンに接続してみました。さすが Windows と XBox 360 レシーバーです。レシーバーのペアリングボタンを長押しし、コントローラもペアリングモードにして、あっさりと接続できました。

XBox 360 コントローラとワイヤレスレシーバのセット商品は、いまでも市中在庫があるようです。これからコントローラとセットで買いたいかたはこちらを購入すればいいのではないかと思います。



もし XBox 360 コントローラをすでにお持ちで、コントローラを購入する必要のない方は、下記のレシーバーを購入すれば、たぶん手持ちのコントローラを Oculus Rift との組み合わせに転用できます。



「ところで、 Rift 付属の XBox One コントローラを使わなくても大丈夫なの？」という疑問をお持ちのかたへ。ちょっと調べてみたところ、 Rift 向けのソフトウェア開発では XBox 360 コントローラはよく使われているそうです。 Windows の仕組み的には XBox 360 / XBox One のコントローラは特に区別もしていないようですし、ボタンの数とかも一緒のはずなので、 XBox 360 用コントローラを使っても問題は無いはずです。

よい VR ライフを。

ZFS (on OpenIndiana VM on ESXi) のディスク交換

先日 ZFS の RAID-Z1 アレイがデグレードした。デグレードしたアレイは下記の構成。

• WD RED 4TB X5、パリティ一発の構成
• メンバディスクは2014年頃に購入してからこれまでは安定
• たびたび自宅のブレーカー断 が発生。その仮定でディスクに損傷がおきている可能性はありそう
• ESXi に SATA ポート経由で接続し、 RAW デバイスマッピングを介して OpenIndiana VM に接続

はじめに現れた症状

VMware 上の OpenIndiana で動く ZFS ストレージをその ESXi 自体で NFS データストアとしてマウントしているが、そこで動く BIND が落ちて自宅のネットワークが不調になった。原因なんだろうなーと思ったが、どうやら ZFS アレイのデグレが原因の模様。

 root@vm230:~# zpool status
  pool: array3
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: scrub repaired 523M in 22h40m with 0 errors on Sun Feb 14 07:48:45 2016
config:

        NAME        STATE     READ WRITE CKSUM
        array3      DEGRADED     0     0     0
          raidz1-0  DEGRADED     0     0     0
            c3t1d0  ONLINE       0     0     0
            c3t5d0  ONLINE       0     0     0
            c3t4d0  DEGRADED     0     0 8.15K  too many errors
            c3t2d0  ONLINE       0     0     0
            c3t3d0  DEGRADED     0     0 1.36K  too many errors
        logs
          c3t8d0    ONLINE       0     0     0
        cache
          c3t9d0    ONLINE       0     0     0

VMware ESXi 側で仮想マシンの仮想ディスクのレイテンシを確認すると最悪値が 10 秒に達している仮想ディスク（c3t4d0）があり、ハードウェアレベルの障害と確証を持った。OpenIndiana カーネル側には下記のようなメッセージが出力されていた。ディスクがエラーを起こしているときに出しているようだ。

Feb 16 10:26:55 vm230 scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci15ad,1976@10/sd@3,0 (sd4):
Feb 16 10:26:55 vm230   disk not responding to selection

この状態における zpool scrub の必要性

色々試してみてわかったんだけど、ディスクを交換するつもりなら事前に scrub する必要はなかった。
まず、DEGRADED となっているメンバはドライブ障害が発生している旨フラグが立っているものの、まだ ZFS が見捨てたわけではなく、稼働中だということを示している。ここが UNAVAIL もしくは REMOVED だとドライブがそもそも応答しないかパス障害になっているので、もうひとつドライブが見えなくなった時点でこの ZFS プールはオフラインになるだろう。だが今回は DEGRADED ステートになりつつも、障害が起きているドライブ2台はまだ辛うじてオンラインのまま。
ここで zpool scrub を行えばアレイ全体を検査と自動修復を行えるけども、のちに実行する zpool replace コマンド中でも事実上スクラブ相当の処理が行われる。一時的にディスクが UNAVAIL になったためアレイセットのなかで置いて行かれた状態などであれば scrub する意味があるだろうけど、今回は辛うじて全ドライブがオンラインのままだし、ディスク交換前に scrub を繰り返してとどめを刺しても仕方ないので、結果論としてスクラブを試す強い理由はなかった。せいぜいディスクのエラーカウンタをリセットした後にスクラブしてみて不良かを再判断できる程度。

交換用ディスクを調達、 VM に接続

今回は東芝製MD04ACA6 (6TB)をメンバディスクとして使ってみる。RAID-Zなので不具合が出たディスクだけ6TBのディスクにしなくとも、4TB前後で十分なのだが、これから数年後に4TBクラスのディスクが大量に転がっているのは避けたいし。 先の zpool status の状況からディスク2台に障害がおきていると想定し、交換用のディスクは2台準備した。
問題のディスクは SUPERMICRO 社製 X9SRA の SATA ポートに接続されている。残念ながら SATA ポート自体は ZFS プールのメンバ群などで埋まっているので、相手いる SAS ポートに今回用意した SATA ディスクを接続して復旧作業を進める。（一般的にSASポートはSATAディスクも扱える）
横着だがマシンが稼働した状態のまま SATA ケーブルでシステムボードの SAS ポートとMD04ACA6を接続し、SATA電源ケーブルを慎重にプラグし活性接続。ディスクトラブルが起きているときはマシンの電源を切りたくないし、可能ならマウント（インポート）している仮想マシンの電源も落としたくない。 vSphere Client を介して VMware ESXi に対しストレージのリスキャンをかけると接続したディスクが認識されていたので ESXi の再起動なしに先に進めそう。
ESXi 上で ls -l /vmfs/devices/ を実行してみると、新しく接続したディスクが naa.50000396aba018c8 として認識されていたので、このディスクを RAW マッピングする VMDK ファイルを生成する。

/vmfs/volumes/(snip)/vm230b # vmkfstools -z \
    /vmfs/devices/disks/naa.50000396aba018c8 \
    array3f_50000396aba018c8.vmdk

残念ながら仮想マシンを止めないと OpenIndiana に対して仮想ディスクを追加できない（と思う）。 ZFS プールは DEGRADED 状態だがメンバが足りていないわけではないし、仮想マシンを起動しなおした時点で今みえている仮想ディスクが見えなくなることも考えづらい。 DEGRADED 状態でも辛うじて I/O はできているようなので、なんとかなるだろうと判断（でもこわい。慎重を期すならここで別のファイルシステムにバックアップをとったほうがいい）。再起動後もきちんと戻ってくると信じて VM シャットダウン、仮想ディスクを追加して OI 再起動。

root@vm230:~# format
Searching for disks...done

c3t6d0: configured with capacity of 5589.03GB


AVAILABLE DISK SELECTIONS:
       0. c3t0d0 <VMware-Virtualdisk-1.0 cyl 2085 alt 2 hd 255 sec 63>
          /pci@0,0/pci15ad,1976@10/sd@0,0
       1. c3t1d0 <VMware-Virtual disk-1.0-3.64TB>
          /pci@0,0/pci15ad,1976@10/sd@1,0
       2. c3t2d0 <VMware-Virtual disk-1.0-3.64TB>
          /pci@0,0/pci15ad,1976@10/sd@2,0
       3. c3t3d0 <VMware-Virtual disk-1.0-3.64TB>
          /pci@0,0/pci15ad,1976@10/sd@3,0
       4. c3t4d0 <VMware-Virtual disk-1.0-3.64TB>
          /pci@0,0/pci15ad,1976@10/sd@4,0
       5. c3t5d0 <VMware-Virtual disk-1.0-3.64TB>
          /pci@0,0/pci15ad,1976@10/sd@5,0
       6. c3t6d0 <ATA-TOSHIBA MD04ACA6-FS2A-5.46TB>
          /pci@0,0/pci15ad,1976@10/sd@6,0
       7. c3t8d0 <VMware-Virtual disk-1.0-1.00GB>
          /pci@0,0/pci15ad,1976@10/sd@8,0
       8. c3t9d0 <VMware-Virtual disk-1.0-200.00GB>
          /pci@0,0/pci15ad,1976@10/sd@9,0

新しく接続したディスクは c3t6d0 として認識されている。なお、仮想ディスクの構成はこうなっていた（ずっと前に適当に構築したので完全に忘れていた）

• c3t0d0 (SCSi 0:0): OSイメージ
• c3t1d0 (SCSi 0:1): データ用ZFSプールのメンバディスク 1
• c3t2d0 (SCSi 0:2): データ用ZFSプールのメンバディスク 2
• c3t3d0 (SCSi 0:3): データ用ZFSプールのメンバディスク 3 (エラーが発生)
• c3t4d0 (SCSi 0:4): データ用ZFSプールのメンバディスク 4 (エラーが多く発生)
• c3t5d0 (SCSi 0:5): データ用ZFSプールのメンバディスク 5
• c3t8d0 (SCSi 0:8): データ用ZFSプールのslog
• c3t9d0 (SCSi 0:9): データ用ZFSプールのL2ARC

ここに下記デバイスを追加した。

• c3t6d0 (SCSi 0:6): データ用ZFSプールの交換用メンバデバイス

いざリプレース

zpool replace でエラーが多数発生しているメンバディスクを新ディスクに置き換える。

root@vm230:~# zpool replace array3 c3t4d0 c3t6d0
root@vm230:~# zpool status
  pool: array3
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Feb 15 06:14:01 2016
    51.9M scanned out of 17.4T at 5.76M/s, (scan is slow, no estimated time)
    9.94M resilvered, 0.00% done
config:

        NAME             STATE     READ WRITE CKSUM
        array3           DEGRADED     0     0     0
          raidz1-0       DEGRADED     0     0     0
            c3t1d0       ONLINE       0     0     0
            c3t5d0       ONLINE       0     0     0
            replacing-2  DEGRADED     0     0     0
              c3t4d0     DEGRADED     0     0     0  too many errors
              c3t6d0     ONLINE       0     0     0  (resilvering)
            c3t2d0       ONLINE       0     0     0
            c3t3d0       DEGRADED     0     0     0  too many errors
        logs
          c3t8d0         ONLINE       0     0     0
        cache
          c3t9d0         ONLINE       0     0     0

errors: No known data errors

約21時間後に zpool replace が完了。死んだディスクをリプレースしたディスクで置き換えたが、現在接続されている SAS ポートから SATA ポートへ新ディスクを移動させると VMware の RAW マッピングがきれる事が想定される。このため一度 zpool export した状態で VM を停止する。
SAS ポートに接続していた新ドライブを死んだドライブの位置に移動し ESXi でデバイススキャンをかけると vmfs/devices/disks/t10.ATA_____TOSHIBA_MD04ACA600__(snip)Y5C7K3SERIAL というパスで認識された。やっぱりパスが変わった。SERIAL の部分は実際にはディスクのシリアル番号が入っている。先に作成した RAW デバイスマッピングを削除して作り直し。

# rm array3f_50000396aba018c8*
# vmkfstools -z \
    /vmfs/devices/disks/t10.ATA_____TOSHIBA_MD04ACA600__(snip)Y5C7K3SERIAL 
    \ array3f_Y5C7K3SERIAL.vmdk

仮想マシンの構成変更。リプレースされて不要になった c3td40 = SCSI 0:4 およびパスが変わってしまった c3t6d0 = SCSI0:6 を VM から削除。新たに作成した array3f_Y5C7K3SERIAL.vmdk を SCSI 0:4 として追加。
VM を起動し zpool import array3 する。これで１台目の重傷ドライブが交換完了となりアレイのステータスは ONLINE に。
ただ、重傷だったオリジナルの c3t4d0 のほかに c3t3d0 でもエラーが出ていた。
重傷ドライブのせいで同時にデグレったかのように見えたのかも？？と思いつつも、とりあえず軽傷なほうも zpool replace してみることにする。やることはさっきと同じ。 SAS ポートに次のドライブを接続して RAW デバイスマッピングを作成し、 SCSI 0:6 として追加して、 zpool replace で c3t3d0 から置き換える。
しばらくは順調だったけども、 resilver が 20% 越えたあたりからチェックサムエラーが出たり dmesg に下記メッセージがでたので、このディスクもやっぱりハードウェアレベルで異常があることは間違いなさそう。

Feb 16 10:26:55 vm230 scsi: [ID 107833 kern.warning] WARNING: /pci@0,0/pci15ad,1976@10/sd@3,0 (sd4):
Feb 16 10:26:55 vm230   disk not responding to selection

24時間もたてば replace は終わっているだろう。そうしたらいったん zpool export して VM を落としておき、古い c3t3d0 を取り外して、 SAS ポートに接続されている新ディスクを c3t3d0 として改めて追加し zpool import しなおせばディスク交換終了の見込み。

スプラソン用キット、稼働開始 #splathon

週末に開催された第二回スプラソンにて、パブリックビューイングシステムを導入しテストしてみました。今回は機材の都合上４画面のみの投影となりましたが、なかなか会場を盛り上げてくれたんじゃないかと思います。

第二回Splathonを開催したぞ（42日ぶり2回目の #splathon ）
第二回Splathon@Speee（IT企業対抗スプラトゥーン大会） まとめ #splathon


第一回スプラソンの際に特定のプレイヤーの行動のみが大型スクリーンに投影されており、できれば両チームの視点からプレイを見たい、と思ったので、色々と検討していました。

一番簡単？なのは WiiU の出力を全部ひとつひとつ大型テレビなどに投影し、並べて見ることです。しかし、大型テレビが８台も沸いてくるようなリッチな環境は滅多にありません。また、プレイ画面とＰＶ画面を別にするとスプリッタの準備も必要です。あわよくば、そこまでするなら、各プレイヤーの動きを録画したり、解析したら面白そうです。

各プレイヤーの動きを録画したり解析するには、たぶんPCにHDMIキャプチャで入力してIkaLogもしくは相当野ツールで処理するのがよいでしょう。しかし、そうするとHDMIキャプチャデバイスを最大8個準備する必要があります。ヘビーです。

で、色々考えていたのですが、スプラトゥーンは 4対4 なので、画面を半分に縮小して 4-in-1 したらいいのではないかと思ったわけです。

4-in-1 しようとすると、通常はお高い機械が必要です。たとえば BlackMagic Design の MultiView を使えば最大16画面をひとつにまとめてスクリーンに投影できたりしますが、メーカーさんなどが悪いわけではありませんが、スプラトゥーン遊ぶのに 16 万円の機械を導入するのは流石に無理です。

「まてよ？ HDMI 信号を FPGA で受信してミックスすればいいのでは？」

なんか変なことを考え始めて色々と検討をはじめました。

そんなこともあろうかと自宅には ZYBO (ARM搭載FPGA)

開発機は入手しています pic.twitter.com/7lAXlO4ZDg

— もつなべおじさん (@hasegaw) 2015, 12月 3

あれ？？？見えないような、、、、 pic.twitter.com/YJW1IAJLtg

— もつなべおじさん (@hasegaw) 2015, 12月 4

自作HDMI-RGB回路でWiiU画面うつるようになった。 pic.twitter.com/kMH2UQH0NL

— もつなべおじさん (@hasegaw) 2015, 12月 5

ハードウェアが得意なわけでもないのでかなり無謀

しかし自分の机を思えばHDMIにからみつくノイズは気になるじゃろ pic.twitter.com/YRVnKx3vmn

— もつなべおじさん (@hasegaw) 2015, 12月 8

ユニバーサル基板で適当に作ったHDMIブレークアウト基板では1GHzオーバーのデジタル信号はやはり無謀だった。 でも映ってる！！！二枚目が期待値。 pic.twitter.com/DoWJc0Ys8M

— もつなべおじさん (@hasegaw) 2015, 12月 11

あとは4チャンネル同時に信号を受けるようにして（FPGAや回路はソフトウェアと違い並列に並べること自体は容易）、受け取ったデータを一度DRAMに書き込んで（DDR2メモリの性能ならまあ適当に作ってもなんとかなるだろう）、その結果をHDMIもしくはRGBとして出力すればOK、、、というところで、いくつか問題が浮上してきました。

ひとつ目の問題は FPGA 上に載っている PLL ブロックの数に限りがある、ということです。開発に利用していた ZYBO の Zynq-7000 には MMCM という PLL 的なものがふたつしか載っていません。しかし HDMI はピクセルクロックで同期しつつその10倍の速度でシリアルデータが送られてくる仕様になっていて、最大 1.5GHz でデータがパタパタ流れ込んできます。 ZYBO 自体でこのクロックを作るのはかなり無理ですし HDMI のピクセルクロックを元に必要なクロックを生成するのが現実的ですが、その回路がふたつしかないのえす。ひとつを入力、もうひとつを出力を使ったらもうありません。どうやって残りの３チャンネルを受ければいいんだ。

手元にあるもうひとつの FPGA 評価ボード NEXYS 4 には MMCM が 6 ありようなのでここで勝利を確信します。しかし、トレーニングボードのネットリストを見てみると PMOD に差動信号ペアとして使えるピンが全然でてないじゃないですかーやだー。ふざけんなよなんでこんなデザインになってるんだよ。俺は差動信号を１２ペアぐらい突っ込みたいんだよ。

ここでひとつの悟りをひらきました。まず私が想定している回路はFPGAで作ることは可能です。ただ問題として、HDMIの1.5GHzクロックで流れ込んでくる信号をきれいにさばくには基板の設計を数回繰り返す必要があります。さらに、私の手元にはHDMIの信号を同時に4つ受けられるようなFPGAボードがないのでそこから制作するとなると、何百ものピンが出ているFPGAパッケージとHDMIコネクタを正しく接続したボードを作って、そこに諭吉さんクラスのFPGAを購入し業者に万単位のカネを払ってチップマウントして貰わないと作れないということが現実的にわかってきました。もちろん私が一発で成功させられるわけがないのでそれを繰り返すことになりかねません。

そこまでは難しいので、どうにか外部インターフェイス部分だけの製作で済ませようとするとこういうFPGAボードが載せられる基板をつくる手があるのですが、そもそもこのFPGAボードが10万スタートでかなりハードルが高いです。

BlackMagic Design の MultiView が安く見えてきました。

が、世界の工場で作られた「とりあえず 4-in-1 が可能なハードウェア」を入手することに成功しました！

というわけで、今回のスプラソンに投入してみたわけです。

この上映システムやばい #splathon #Splatoon pic.twitter.com/abkHAbH5lM

— kana (@kana1) 2016, 1月 10

やばい #splathon pic.twitter.com/M8N4nv2JUq

— takanamito (@takanamito) 2016, 1月 10

この上映システム最高だ #splathon #splatoon pic.twitter.com/6iPjJMg5T4

— kana (@kana1) 2016, 1月 10

4画面分割でライブとか充実しすぎ #splathon pic.twitter.com/6vPyX4mNCU

— Haruka Iwao (@Yuryu) 2016, 1月 10

楽しい！ #splathon pic.twitter.com/EnUgxMJbLL

— じゅうなんざいいり(筆の戦士見習い) (@10nanzaiiri) 2016, 1月 10

Ikalogで4画面をリアルタイム画像解析して、RS-232CでHDMIミキサー制御して、シーンによってライブスクリーンの画面分割制御してるって言ってた。すごい。 #splathon

— Haruka Iwao (@Yuryu) 2016, 1月 10

このシステムはスプラトゥーンをプレイする人々（別にほかのゲームでもいいですが）のためにお貸し出しできるように揃えています。仲間うちでプレイしたい、みんなでプレイするときにこの機材が使いたい、という方は是非ご連絡ください。

イニシャルがけっこうかかっていますので無料というのはきついですが、場合によっては一ヶ月分の給料に相当する程度の機材を気軽に利用してもらえるように準備しています。