新規ハードディスク購入で深い沼にはまったので、記事にしてみようと思う。


今回8T HDDの値段がこなれて来たのでST8000DM004を中古(18000円前後)で購入した。
メインのwin10のPCにつないでデータバックアップ用として使用してみることとした。
書き込み読み込みも100MB/s超えており、最近のHDDはすごいなぁと思いつつ5TBくらいのデータ群を書き込んだ。特に異音もなく動いているし、割と最近のモデルなので中古だけどすぐには壊れないだろうとたかをくくっていた・・・

そしてある日、「なんだかパソコンが重いな」といって再起動をかけたところ

BIOS画面から動かない。

電源ボタンで強制終了してからまたつけてもBIOS設定画面すら開かない。ASUSのロゴがでてなにも受け付けない
まさかパソコン壊れた・・？
もう5年以上にもなるし常にBOINCやらマイニングやらで24時間フル稼働させていたからいつどこがどうなってもおかしくないと思っていた。
マザボはP9X79で、これにはcpuやメモリ、グラボに異常がある場合に知らせてくれるLEDランプがついている。今回はPCI Express x16スロットの横にあるBOOT DEVIDE LEDが点灯状態だった。

ははーんグラボだな、と思ってグラボを変えてみたけど変化なし。今度は電源を疑う。グラボに給電する電力が足りないのだろうと。外部電源を必要としないAMD HD7750にしてもやはり変わらず。
PCI Express x16の給電が足りないのだろうとやはりしつこく電源を疑う。ちなみに他の原因を考えたがそもそもOS画面に行く前なのでOSは関係なし。メモリの異常ならばマザボのDRAM_LEDが点灯しないのはおかしい。CPUの異常でも同じくCPU_LEDが点灯してないのはおかしい。
あとはマザボ自体の異常。電池切れとか。
いろいろ外しながらやっているうちに、OSの入ったSSD以外のドライブを外したところで起動した。そして原因特定。一番最近つけたST8000DM004だ。

それも再現率100%で、このHDDつけたときだけBIOSが起動しない。HDDのせいでBIOSすら起動しないことあるの？普通に考えたらHDDの故障・・
これは考えたくない・・大事なデータがいっぱいはいってるんだ(大事じゃないのも多いけど)

それでググってみるけどやっぱりHDDの故障が一番考えられそうだった。

ただちゃんと電源投入時にHDDも回っている音がするので完全に死んだわけではなさそう。
諦めきれずに数千円のSATA - USB3.0変換ケーブルを購入して、USB経由でデータ救出を試みた。結果はまさかの、BIOSでフリーズ。USB経由でもフリーズとか怖すぎる。しかも今度はHDD回ってる音しないし。

心折れかけたけど、別のPCに、USB経由でなくマザボからしっかり(?)つないでみたところ・・
OS起動！
しかも中のデータは全部完全に生きていた！！！！！

結局データは全部取り出せて、今でもこの8TBのHDDは問題なく稼働している。



今回のをまとめると
メイン機
マザボ：P9X79
CPU：core i7 3820
メモリ：PC3-12800(DDR-1600) 8GB*4 クアッドチャネル
グラボ：RX 480+HD 7970
OS：windows 10 pro 64bit
SATAデバイス：Crucial_CT525MX300SSD1(SSD OS用)、M4-CT128M4SSD2(SSD データ用)、ST4000DM004(HDD データ用)、ST8000DM004(HDD データ用)

で再現率100%でBIOS画面のフリーズ。ST8000DM004なしの構成だと問題なく起動。


サブ機
こちらにつないで救出できた。
どうも調べてみると3TBのHDDをexFATで初期化するとBIOS起動しないなどちらほら情報がでてくる。

今度はデバイス情報取得
公開されているPyOpenCLサンプルを改変

# -*- coding: utf-8 -*-
# OpenCLで使用できるデバイスを列挙して、デバイス情報を取得＆表示
import pyopencl as cl
from pyopencl import device_type
from pyopencl import device_local_mem_type


for platform in cl.get_platforms():
    for device in platform.get_devices():
        print('''
        PLATFORM                 = {}
        VENDOR                   = {}
        Name                     = {}
        Type                     = {}
        OPENCL_C_VERSION         = {}
        GLOBAL_MEM_SIZE          = {}
        Max Compute Units        = {}
        Max Work Group Size      = {}
        Max Work Item Dimensions = {}
        Max Work Item Size       = {}
        Local Mem Size           = {}
        Local Mem Type           = {}
        '''.format(
            device.platform,
            device.vendor,
            device.name,
            device_type.to_string(device.type),
            device.opencl_c_version,
            device.global_mem_size,
            device.max_compute_units,
            device.max_work_group_size,
            device.max_work_item_dimensions,
            device.max_work_item_sizes,
            device.local_mem_size,
            device_local_mem_type.to_string(device.local_mem_type)
        ))

自分の環境では

PC１
構成　CPU：core i7 3820、GPU：HD 7970、RX 480
で
認識プラットフォーム１つ
認識デバイスは３つ(上記3つ)

PC２
構成　CPU：core i7 4710MQ、GPU：intel(R) HD Graphics 4600、GTX 860M
で
認識プラットフォーム２つ
認識デバイスはプラットフォーム１でcore i7 4710MQとintel(R) HD Graphics 4600
プラットフォーム２でGTX 860Mを認識した。



環境によっては同じデバイスを複数のプラットフォームから認識される可能性もあると思う

多分これがPyOpneCLで計算する一番最小構成

# -*- coding: utf-8 -*-
import numpy as np
import pyopencl as cl

ctx = cl.create_some_context()
queue = cl.CommandQueue(ctx)

cl_mem_a=cl.Buffer(ctx,cl.mem_flags.READ_WRITE,4)
cl_mem_b=cl.Buffer(ctx,cl.mem_flags.READ_WRITE,4)
cl_mem_c=cl.Buffer(ctx,cl.mem_flags.READ_WRITE,4)
a = np.array([1])
b = np.array([1])
c = np.empty(1, dtype = np.int32)

cl.enqueue_write_buffer(queue,mem=cl_mem_a,hostbuf=a)
cl.enqueue_write_buffer(queue,mem=cl_mem_b,hostbuf=b)

global_work_size=(1,1)
local_work_size=(1,1)

prg_string="""
__kernel void Onlyadd(__global int* A,__global int* B,__global int* C)
{
   C[0] = A[0] + B[0] ;
}
"""
program=cl.Program(ctx,prg_string).build()
kernel_Onlyadd=cl.Kernel(program,"Onlyadd")
kernel_Onlyadd.set_arg(0,cl_mem_a)
kernel_Onlyadd.set_arg(1,cl_mem_b)
kernel_Onlyadd.set_arg(2,cl_mem_c)

cl.enqueue_nd_range_kernel(queue,kernel_Onlyadd,global_work_size,local_work_size)
cl.enqueue_read_buffer(queue,mem=cl_mem_c,hostbuf=c)
print(c)

デバイス(GPU等)上に要素1の配列でA,B,Cを確保。
C＝A＋B
をやってホストに結果を戻して表示

PyOpenCLはじめました
python 3でnumpy、PyOpenCLのインストールが最低必要

# -*- coding: utf-8 -*-
import numpy as np
import pyopencl as cl

ctx = cl.create_some_context()
queue = cl.CommandQueue(ctx)
data_mem=cl.Buffer(ctx,cl.mem_flags.READ_WRITE,32)
hostdata=np.empty(32, dtype = np.int8)
global_work_size=(1,1)
local_work_size=(1,1)

prg_string="""
__kernel void hello(__global char* string)
{
   string[0] = 'H';
   string[1] = 'e';
   string[2] = 'l';
   string[3] = 'l';
   string[4] = 'o';
   string[5] = ',';
   string[6] = ' ';
   string[7] = 'W';
   string[8] = 'o';
   string[9] = 'r';
   string[10] = 'l';
   string[11] = 'd';
   string[12] = '!';
}
"""
program=cl.Program(ctx,prg_string).build()
kernel_h=cl.Kernel(program,"hello")
kernel_h.set_arg(0,data_mem)
cl.enqueue_nd_range_kernel(queue,kernel_h,global_work_size,local_work_size)
cl.enqueue_read_buffer(queue,mem=data_mem,hostbuf=hostdata)
res_string=""
for i in range(len(hostdata)):
    res_string=res_string+(chr(hostdata[i]))
print(res_string)

はい
長過ぎる笑
むりくりOpenCLで文字列扱ってるから逆に難しくなってしまった
多分1+1=2の計算をやるほうが簡単

今回ブログが始まって以来初めてプログラミング以外のことを書くこととなった。本日はドローンと電子工作のお話。ドローンといっても社会的な問題を取り上げるのではなくあくまでバッテリー等の技術的な、理系一色な感じで話をしようと思う。


　2015年10月頃、訳あってDJI Phantom3というドローンを購入した。早速あけて家の中で飛ばしてみた。非常に安定しているし、操作が簡単で、とても面白い！

　外では近くに飛ばせる場所がなくて、電車で２時間、はるばる奥多摩までいって飛ばしたのが外での初フライトとなった。がしかし、このPhantom3用のバッテリー(Intelligent Flight Battery)1つではたった25分くらいしか飛ばせない(これでも他のドローンよりはるかに長い)。こんなこともあろうかともう1つ予備バッテリーを購入していたが、あわせても長くて50分ほどしか飛ばせなく、せっかく片道2時間かけて来たのになんだか遊び足りない！もっと遠出した先で飛ばすのなら、やはり25分×5～10回は飛ばしたい。
　では予備バッテリーをもっと増やせばいいのではないか？これは一番簡単な解決方法だが、経済的によろしくない。1つ2万円するバッテリーを5本も買ったらそれだけで10万、次のドローンが買えてしまう。
(下のコレが1個20,000円)

安い方法で何度も飛ばしたい！
何かいい方法があるはず・・・と思ってgoogle先生に聞いてみるもあまりパッとする案がない。一番有力なのが「Anbee シガーライターカーチャージャーとアダプタ 」(2,800円位)を使って車のシガーライター12vを電源として、Phantom3用バッテリーを充電して使いまわす、という方法。これならまぁバッテリー3つ程用意して、飛ばし終わったら即充電に回してってやればかなり遊べる。
ただその場に車がないと話にならないのが致命的・・・。



　まず、そもそもこのIntelligent Flight Batteryは本当に20,000円の価値があるのか、しっかり検証する必要がある。バッテリースペックは以下の通り。
電圧：15.2V(4セル)
容量：4480mAh
重量：365g
15.2 * 4.480 = 68.096 より68Whとわかる。
15.2÷3.8 = 4より4セル直列とわかる。

　次にそのほかの機能。このIntelligent Flight Batteryは、ドローン本体からリアルタイムにバッテリーセルの各電圧をチェックできるだけでなく、充電回数や寿命、温度まで把握できるようだ。

　確かに、バッテリー側には+-電極以外に信号線と思われる2つの金属端子が見えてる。これを介して、温度や電圧などの情報をやりとりしているのだろう。Intelligent Flight Batteryの付加価値はこういったところにある。
しかしこれだけではなかった。調べてみたところリポバッテリーを長生きさせる様々な機能があった。

　まず、自己放電機能。これはリチウム二次電池全般に言えるが、満充電で長期保管することはとても電池に悪影響。すぐに電池がダメになってしまう。そのため、このバッテリーには満充電で一定期間が経つと容量65%位まで自己放電してくれる機能が備わっている。素晴らしい！
　次に、高温での充電防止機能。リポバッテリーでは満充電並みに気をつけなければいけないのが45℃以上の環境下で充電することだ。これも同じく寿命を縮めてしまう。これを防ぐために、このバッテリーには温度センサーが備わっており、40℃以上の時に充電できないようにされている。
　他にも過電圧による過充電防止機能、各バッテリーセル電圧の均等化機能など当たり前の機能は備わっているようだ。

　なかなかやるなこのDJIという会社は。中国の企業とは思えぬハイクオリティ。ここまでバッテリーに気を使える会社はなかなかない。
　ここまでされると、Intelligent Flight Battery 20,000円という価格設定はあまり高すぎるとは言えないように思える。リポバッテリーで、容量だけならだいたい同じもので6000円台のを見つけることができた。しかし上記のような機能はもちろんついていない。

　少なくともドローンとバッテリー間に電圧温度情報の信号線がある限り、単に＋極と－極をつなげるだけではうまくいかないだろう。つまりIntelligent Flight Batteryを安い代替品にすることは難しい。
　それならばIntelligent Flight Battery自体を外で充電する方法は？超大容量モバイルバッテリーを作るなんてどうだろう？
　これほど優秀なバッテリーの機能はそのまま使いたいし、実際現地で足りないのは電力だけ！できるかどうかは分からないが、ちょっと面白そう。



早速やってみることにした。

まず大まかな構想として、電源は重量エネルギー密度から最も有利なリチウムイオンバッテリーを使う。これを入力とし、出力側は３通り考える。
・17v4A DC→直接Intelligent Flight Batteryを充電できる
・12v6A DC→上記シガーライターカーチャージャーにつなぐことで充電できる
・100v AC　→標準のコンセントタイプのバッテリー充電器につなぐことで充電できる

話はそれるが、持ち運びできる100v AC電源があれば非常に便利なのに意外とそういう商品はない。なんでだろう・・
今回は変換効率と電子回路の勉強のため一番上の17v4A出力の回路設計で行こうと思う。もし失敗したら2番目の12v出力で(笑)。

最低目標として、Intelligent Flight Batteryを5回以上充電できること。かつ値段が10万を超えないこと。


次回は電源部分に当たるリチウムイオンバッテリーの選別について