GoogleGlassの視線（カメラプレビュー）をiPad でリアルタイムに共有して、かつ、指示を送ってみる その一

Glassを身につけている人の視線（カメラプレビュー）をリアルタイムに共有できたらとても便利と思いませんか？

更にお互いに何かのアクションをやりとりできたらどんなに素敵でしょう。さまざまな仕事やエンターテイメントに応用できるはずです。

ということで、Glass の視線をiPadで共有し、ついでに、iPadからGlassに対して指示を送るサンプルを作ってみました。「ここを見て！」という指示が飛ぶようにします。



アプリの流れは以下のようになります。

[Tips] Google Glassの発熱対策

以前GDKでActivityを多様することは本体の発熱量が高くなるに少し触れましたが、今回はその発熱対策として放熱板の取り付けを行ってみました。

元々Google Glassには既存で放熱板が取り付けられています。

しかしコストの高いアプリを作成し、動作を続けるとタップやスワイプなどを行う右側部分（装着時）のフレームの発熱が非常に高くなることがわかりました。






※ピンク：既存の耐熱板。Glassフレームを囲うように装着してある。

　赤 ：発熱が最も高い部分。今回はここに自作の耐熱板を装着する。




少し温かくなる程度であれば問題ないのですが、カメラ機能を使い続けるようなコストの高いアプリを動作させ続けると、Glassをかけ続けることも辛いほどの発熱量となります。

そこで既存の放熱板だけでは不足な発熱の対策としてオリジナルの放熱板を取り付けることを試みました。

用意したもの

• 熱伝導性シリコン


• 熱伝導性接着剤


• コイン


• プラスチックの線


• ハサミ


• ペンチ

手順

１）シリコンを発熱対策を行いたいフレームのサイズに合わせてカットし、熱伝導性の接着剤を使い重ね合わせます。






２）更に放熱度をあげるため、重ねたシリコンの間にコインを挟みます。






３）２）で作成したものをGlassの放熱を行いたい部分に装着します。

このとき、放熱板とGlassに隙間ができると放熱効果が下がるため、しっかり密着させることが重要。

装着イメージ

放熱板を装着したことによる違和感は特に気にならず。

成果

オリジナルの放熱板を取り付けることにより、以前に感じていた発熱を抑えることができました。

またカメラビューを使い続けるようなアプリをGlassで動作させ続けた際の動作時間を以前の約倍近くまで延ばすことができました。

今回苦労した点

Glassに放熱板の密着度を意識しながら取り付けたことぐらいです。

ですが、これが重要です！！！！




今回の放熱板の取り付けにより発熱対策は行いましたが、より多様な機能を搭載したアプリを開発するには設計段階からの省エネ対策が必要となります。

[コラム] 日本アンドロイドの会2月定例会に参加してきました。

2014年2月の日本アンドロイドの会定例会に参加してきました。

https://www.android-group.jp/event/event28.html

iBeaconとはどんなもので、アンドロイドで実現する場合に注意すべきことは何かなどを、この方面で活躍されている方を招いて勉強するという内容でした。

まず、今度の2/15、16に会津でBLEハッカソンを企画されている、Aka Beacon で有名なGClue の佐々木陽氏が、iBeacon とは、UUID、Major、Minor でビーコンを区別し、Immediate/Near/Far/Unknown などの近さが取得できるものですよ、ということを自作したデバイスを使ってデモを行いながら、非常に軽やかに説明されました。

また、iOSのバックグラウンド処理についても触れて、アプリがバックグラウンドにいてもRegion IN/OUTのイベントを受信でき、15秒間は動作可能ということも述べられていました。結局、もっとバックグラウンド動作を伸ばす方法はあるみたいですが…。

アンドロイドは、各アプリがビーコンを監視する部分を独自でもつため、ビーコンを利用するアプリが立ち上がるほど、電力消費が大きくなるとのこと。対して、iOSは、フレームワーク部分がビーコンの監視を行ってくれているので、ビーコンを使うアプリがたくさんいても省電力になっているとのこと。だから、アンドロイドでもビーコンを扱うサービスを作り、省電力な設計を行う必要があるとおっしゃっていました。

あとは、エコシステム、Appcessoryを中心とする最近のビジネス状況について、BLEデバイスのモジュール化のベンチャーが増えていることなどを説明してくれました。

続いて、Applixで研究開発をされている日向さんがビーコンの電波特性について、非常にわかりやすく解説してくれました。屋内測位をやっていると、電波特性というものに敏感になるもので、なんでこんなに状況によって電波強度がかわるのか深く知りたくなってきます。日向さんの調べたところによると、床や壁などに当たって跳ね返ってくる反射波との干渉により、場所によって電波の強弱が変わってしまうということです。また、電波強度と距離の関係式も、２、３mくらいまでなら大体合っているが、距離が遠くなるに連れて、実際の値とのずれが大きくなってくるとのこと。屋内測位をやったときもFarのビーコンは無視すると非常にうまく行きましたから、納得です。日向さんの考えでは、RSSIからもとめる距離の精度も対数をとった値なら実用に耐えられるのでは、とのこと。

あとのお二人は、iBeaconを使った事例でした。

元頓知ドットさんのおでかけスクラップサービス"tab"は、失敗事例などいくつか紹介しており、非常に参考になりました。

残念ながら、帰阪するため参加できたのはここまででした。

iBeaconでブームとなったBLEの流れですが、アンドロイドでちゃんとしたサービスが展開されるのはまだまだ先なのかなという印象を受けました。

GDKでActivityを使ってみる

GDKでは、以前お伝えしたCardの仕組みを使わずにAndroidと同様にActivityを使ってアプリを構築することができます。



注意点としては以下があります。

• 640 × 360 の解像度


• スワイプダウンが戻るボタンに該当する


• Androidのようなタッチ操作はできない

しかしActivityだけではアプリが timeline 上に表示されない為、ユーザーがアプリを起動する手段がありません。そこで、アプリ起動用Serviceを用意してonStartCommand()のタイミングで任意のアクティビティを起動してやる必要があります。

なんだかとても面倒に感じますが、とても簡単。

まずサービスクラスを用意します。

単純にアクティビティを起動するだけのサービスクラスに必要なコードはたったこれだけ。

public class HelloService extends Service {
    @Override
    public IBinder onBind(Intent arg0) {
        return null;
    }
    
    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        Intent aIntent = new Intent();
        aIntent.setClassName("com.example.helloactivity","com.example.helloactivity.MainActivity");
        aIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); 
        startActivity(aIntent);
        return START_STICKY;
    }
}

あとは timeline からサービスを呼ぶようにマニフェストファイルを設定するだけ。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.helloactivity"
    android:versionCode="1"
    android:versionName="1.0" >

    <uses-sdk
        android:minSdkVersion="15"
        android:targetSdkVersion="15" />

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >
        <activity
         android:icon="@drawable/ic_launcher"
            android:name="com.example.helloactivity.MainActivity"
            android:label="@string/app_name" >
        </activity>
        <service
            android:name="com.example.helloactivity.HelloService"
            android:icon="@drawable/ic_launcher"
            android:label="@string/app_name"
            android:enabled="true"
            android:exported="true">
            <intent-filter>
                <action android:name="com.google.android.glass.action.VOICE_TRIGGER" />
            </intent-filter>
            <meta-data
                android:name="com.google.android.glass.VoiceTrigger"
                android:resource="@xml/voice_trigger_start" />
        </service>
    </application>
</manifest>

この intent-filter と meta-data が重要で、これを記述することによってサービスが timeline 上に表示されるようになります。

            <intent-filter>
                <action android:name="com.google.android.glass.action.VOICE_TRIGGER" />
            </intent-filter>
            <meta-data
                android:name="com.google.android.glass.VoiceTrigger"
                android:resource="@xml/voice_trigger_start" />

これだけで、Androidと同様のActivityを使ったアプリをGlassで実現することができます。

しかし、AndroidアプリをGlassに簡単に移植できる、とは考えないで下さい。

現時点で Activity は Glass にはコストが高く、非常に動作が重くなり、本体の発熱も凄いです。

現時点では、Glass に Activity を使うのは良い選択肢ではないと考えます。

それを示すように、Activity を使って描画を行っているサンプルは Google から提供されていません。

そもそもソースコードも公開されてませんし、Glass は Android と似て非なるもの なのです。

iBeaconで屋内測位成功のヒントをつかんだ！

本ブログ「屋内測位をやってみました」で、始めた屋内測位ですが、あれからいろいろやってみて、だいぶまともに動くようになってきました。今回はある会議室にビーコンをだいたい３m四方に12個配置しました。使用したビーコンは、Estimote社のものを使っています。このビーコン出力が弱いため、精度を出すには３mという短い間隔で置くしかありませんでした。使用した測位アルゴリズムも、トリラテレーション（Trilateration）ではなく、近辺のビーコン位置にRSSI値をもとにした加重平均をとる方法を採用しました。

では、実際の実験の様子をご覧ください。

GDKでHelloWorldを作ってみる

Google からGlass Development Kit（以後GDK）が発表されてしばらく経ちました。

合わせて開発者用Glassの販売も行われ、今後市場投入に向けての動きが活発になることが予想されます。

しかしこの開発者用Glass、2014年1月時点で日本からは購入することができません。

USAでも開発者向けの招待メールでしか購入ができないようになっています。

弊社は現地支社がある為、いくつか購入することができました。

Glassを使った開発ノウハウが徐々に溜まってきたので、GDKでHelloWorldを書く方法をお伝えします。



さて、まず一言。

HelloWorld を書くのにこんなに苦労したのは久しぶりでした

完成されたSDKであれば普通、HelloWorldというのはプロジェクトを新規作成すると自動的に生成されるスケルトンプロジェクトに、ちょちょいと追記するだけで簡単に作れるものなのですが、現在のGDK（Rev.2）にはスケルトンコードを出力する機能がありません。

従って今回は、GDKの中に含まれるサンプルコードをリファクタリングしながらHelloWorldを作ります。

Google Glassの開発環境

Glassの開発環境は基本的にAndroidと同じで、IDEはEclipseを使うのが最も簡単でしょう。

Android SDK Managerから Android 4.0.3 > GDK を選択して開発環境をインストールします。

HelloWorldを作ってみる

それではGDKに含まれるサンプルコードをリファクタリングしながらHelloWorldを作ってみます。

新規プロジェクト > Android Sample Project > GDK > Timer を選択します。最後の画面でプロジェクト名をHelloWorldに変えておきます。







このサンプルはその名の通りタイマーアプリで、設定した時間をカウントダウンすることができます。

まず、アプリがどのような動作をするか確認します。

遷移図を作りました。



Glassはタップによる文字入力ができませんので入力項目は全て選択式になります。従って、シンプルなアプリですが画面数はとても多くなる傾向にあります。

Timerサンプルを解析してみる

次はTimerサンプルのコードを見て行きます。

まずはManifestから。

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.google.android.glass.sample.timer"
    android:versionCode="2"
    android:versionName="1.0" >

    <uses-sdk
        android:minSdkVersion="15"
        android:targetSdkVersion="15" />

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_timer"
        android:label="@string/app_name" >

        <activity
            android:name="com.google.android.glass.sample.timer.MenuActivity"
            android:label="@string/app_name"
            android:theme="@style/MenuTheme"
            android:enabled="true" >
        </activity>

        <activity
            android:name="com.google.android.glass.sample.timer.SetTimerActivity"
            android:label="@string/app_name"
            android:enabled="true" >
        </activity>

        <activity
            android:name="com.google.android.glass.sample.timer.SelectValueActivity"
            android:label="@string/app_name"
            android:enabled="true" >
        </activity>

        <service
            android:name="com.google.android.glass.sample.timer.TimerService"
            android:icon="@drawable/ic_timer"
            android:label="@string/app_name"
            android:enabled="true"
            android:exported="true">
            <intent-filter>
                <action android:name="com.google.android.glass.action.VOICE_TRIGGER" />
            </intent-filter>
            <meta-data
                android:name="com.google.android.glass.VoiceTrigger"
                android:resource="@xml/voice_trigger_start" />
        </service>

    </application>

</manifest>

Activity が三つにServiceが一つ宣言されています。

こんなに小さなアプリでActivityが三つもあるのは何故か？

Glassでは基本的にActivityはコンテンツを描画する目的では無くメニューを表示する目的で使われます。従って、メニュー（設定項目や選択項目）が増えるとActivityがどんどん増えていく傾向があります。

Service内のmeta-dataは音声認識によるアプリ起動をサポートします。

次はソースコードを見て行きます。

• MenuActivity.java


• SelectValueActivity.java


• SelectValueScrollAdapter.java


• SetTimerActivity.java


• SetTimerScrollAdapter.java


• Timer.java


• TimerDrawer.java


• TimerService.java


• TimerView.java

この中で最低限必要なクラスは以下です。

• MenuActivity.java


• TimerDrawer.java


• TimerService.java

一つのGlassアプリには必ず一つのサービスが必要です。

サービスである為、アプリを終了する為のメニューが必要となるでしょう。必然的にメニューを表示するActivityも一つは必要となります。

さっき、Activityはメニューを表示する為に使うと説明しました。では、肝心のコンテンツはどのように描画するか？

GlassではCardというAndroidには無い仕組みが有ります。

Cardとは

Androidでは一つのActivityで一画面を表現しますが、Glassでは一つのCardで一つの画面を表現することができます。

CardにはStatic CardとLive Cardの二種類があり、画面の更新頻度に応じて使い分けるとDocには書かれています。

TimerサンプルはLive Cardを利用している為、今回はLive Cardを使うことにします。

Live Cardは以下のような仕組みになっています。



Glassではアプリ一覧が並ぶUIの事をTimelineと呼びます。

Timeline からアプリのサービスが起動し、サービスでLive Cardを生成しコンテンツの描画を行います。

HelloWorldを作ってみた

Timerサンプルを元に作成したHelloWorldのプロジェクト一式はこちら。




重要なのはTimerServiceのonStartCommand()で、それ以外はAndroidと全く同じです。

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    if (mLiveCard == null) {
        //LiveCardを生成したい
        mLiveCard = mTimelineManager.createLiveCard(LIVE_CARD_TAG);

        //レンダリング用Drawerを追加したい
        mLiveCard.setDirectRenderingEnabled(true).getSurfaceHolder().addCallback(mTimerDrawer);
        
        //Menu用Activityの生成と追加をしたい
        Intent menuIntent = new Intent(this, MenuActivity.class);
        menuIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK);
        mLiveCard.setAction(PendingIntent.getActivity(this, 0, menuIntent, 0));

        //LiveCardを表示したい
        mLiveCard.publish(PublishMode.REVEAL);
    } else {
        // TODO(alainv): Jump to the LiveCard when API is available.
    }

    return START_STICKY;
}

尚、Cardを使わずAndroidと同様にActivityのみでアプリを構築する方法もあります。

しかしこの場合、そのままではTimelineからアプリを起動することができない為、アプリを起動する為だけのGlassアプリを用意する必要があります。これに関してはまた別の機会に書きます。

Glassの開発難易度

残念ながら現時点ではGlass用のシミュレータはありません。実機が無いとアプリのテストができない為、早急なシミュレータ環境の提供を期待するばかりです。

コードを書く事だけを見れば、Cardの概念さえ理解すれば後はAndroidとほとんど同じである為、Androidアプリ開発経験者はスムーズに開発を行うことができるでしょう。

しかし、実際にGlassを身につけるとよくわかるのですが、この最低限のアプリケーションでも、起動すると本体が非常に熱くなり、継続した装着が困難になります。

Glassで実用的なアプリケーションを構築する為には高度な省エネのスキルが要求されることでしょう。

しかし、Glassはソースコードが公開されていません。その為、基本的に Java 層で省エネを実現する必要があります。

実験的なアプリケーションはAndroidの延長線上で作れるものの、現時点のGlassの性能で実用的なアプリケーションをFixする為には非常に高度な開発スキルが求められると考えます。

Java で省エネって、アメ車に低燃費を求めるようなもんですよね

[Tips] iBeaconの領域識別子とは？

今回は、あまり余所のブログでは取り上げられていない領域識別子（identifier）に注目してみた。

CLBeaconRegionオブジェクトの生成時に指定するidentifier（日本語で言うと、識別子）は、領域の識別子である。これはそのアプリケーション内で自由に決められるものである。

CLBeaconRegionオブジェクトの初期化処理（initWith...）には、次の種類がある。

• - (id)initWithProximityUUID:(NSUUID *)proximityUUID identifier:(NSString *)identifier;
• - (id)initWithProximityUUID:(NSUUID *)proximityUUID major:(CLBeaconMajorValue)major identifier:(NSString *)identifier;
• - (id)initWithProximityUUID:(NSUUID *)proximityUUID major:(CLBeaconMajorValue)major minor:(CLBeaconMinorValue)minor identifier:(NSString *)identifier;

したがって、識別子をつけられる対象は、次のような組み合わせだけである。

組み合わせ

• proximityUUID
• proximityUUID、Major
• proximityUUID、Major、Minor

ここからわかること、および、実際に動かしてわかったことがある：

1. 同じUUIDを持つデバイスが複数あるときに、３階層のグルーピングが可能である

2. 異なる組み合わせには、同じ識別子を付けられない
（実際、同じ識別子で異なるUUIDのCLBeaconRegionオブジェクトを作ろうとすると、後から作ったオブジェクトで上書きされてしまう）

3. 同じ組み合わせに対して、異なる識別子が付けられる

２つ目はあまり意識されていないところだと思うが、重要である。例えば、いろんなメーカーから購入したiBeaconデバイスを寄せ集めて、ひとつの領域を監視したいとする。しかし、そのようなiBeaconデバイスの中には、UUIDが予め決められていて、購入者が変更できないものもあるかもしれない。そうなると、これらのデバイスすべてを、同じ領域を表すためには使えないことになる。（たいていのiBeaconは、購入後もアプリケーションからUUIDが変更できるようになっている。）

この識別子、使い方によっては非常におもしろいことができる。ひとつのiBeaconに近づいたとか離れたとかといった使い方は基本中の基本で、本質的な使い方は、文字通り、領域にはいったかどうかである。例えば、同じUUID、MajorをもつiBeaconが、下図のように輪っかになっている場合は、そのUUIDとMajorの組に対して付けた識別子は、その赤い輪っかの領域を表す領域識別子として使用することができる。

３つ目の性質に着目すれば、同じビーコンでも異なる領域として使用可能なので、次図のように同じビーコンの配置に対して、いくつもの異なる領域が考えられる。（ただし、この場合、異なるビーコンには同じ識別子が使えないので、識別子自体をURLのようなドメイン構造にする工夫が必要となる。図では、aグループ、bグループ、cグループとしている。どのビーコンも２つの領域に属している。）

    

これは、iBeaconを社会インフラとして考えた場合、非常に柔軟に扱えることを意味している。たとえば、ある区域にiBeaconを均等に配置しておき、適切な識別子を与えただけで、あるルートを表す領域が取得でき、iBeaconの電波を拾って道案内を行うなど、低コストなナビゲーションシステムが実現できる。

例えば、次の図のように大阪駅構内にiBeaconを配置しておく、御堂筋北口から中央きっぷ売り場への道順を表す領域（赤枠）や、御堂筋南口から高速バスターミナルまでの道順を表す領域（青枠）など、おなじiBeaconインフラに対して、ことなる領域を定義することが可能となる。

領域の識別子をうまく使うことが、柔軟で低コストなiBeaconサービスを提供するための必須条件であることは間違いないだろう。

ビーコンの声を聞いてみよう！

ビーコンって何を考えてるんでしょうね？聞いてみたいと思いませんか？

と、唐突に書き始めてしまいました。開発のやりすぎで頭がおかしくなったのでしょうか？　いえ、そうではなくて、今回は、ビーコンの近さに応じて、再生する音の大きさを変えてみようというお話です。でも、それはまるで、ビーコンが「近づいたよ〜」「遠のいたよ〜」と言っているように聞こえるので、結構、たのしいのです。（実際には、電波が強くなったよ〜、ですが。。。）

では、さっそく作って行きます。

１．ボタンを押したら、曲を再生する、というところまでを作ります。xcodeのプロジェクト（BeaconVoiceという名前にしました）を作成し、AVFoundation.frameworkを追加します。また、"sounds"というフォルダを作成し、そこに用意したMP3ファイルをおきます（図参照）。

画面はこんな感じ（図参照）。

しょぼいですね〜。音量と電波受信強度のラベルだけはつけときました。

ソースコードは、こんな感じです。（STARTボタンを押すと、曲が再生されて、もう一度押すと、停止する、という動きにしてます。）

ViewController.m

はい、では、次行きましょう。

２．CoreLocation.frameworkをセットして、ビーコンを受信できるようにします。この辺りは、このブログで何回か紹介してますので、コードだけ載っけます。

ViewController.hのプロパティ

ViewController.mのViewDidLoadの中

ViewController.mの中のLocationManagerのデリゲート処理

はい、できました！

では、実行の様子をお聴きください...。

ああ、残念です。音声がお伝えできない。

音量は、0.0〜1.0までの値です。RSSIの値は、-90〜-58にしています。つまり、この画像では、最大値になっています。iPhoneもビーコンもスクリーンショットを撮った開発環境のPCに接続しているので無理ないですね。では、ちょっとビーコンを遠くへ離してみます。

か、かすかに音が聞こえます。そして、ときどき、ゴハッって感じで音が大きくなります。まるで溺れかけの人のように。おおお、いい感じでビーコンの声が聞こえてますね。

まとめ

もともとビーコンの電波がどれくらい不安定なのか知りたく思い、音で体感できるようにしたかっただけなのですが、なかなかいい感じで確認できることがわかりました。例えるなら、トンネルに入ったときのラジオの音でしょうか？でも、ビーコンに近いときは、安定して聴けます。

応用として、ある範囲では、クラシック、ある範囲では、ジャズなど、特定の範囲でだけ特定の音楽が聴けるとかのサービスができそうですね。

（おわり）

Google Glassの新機能をハックする

はじめに

GoogleGlassの新型(V2)の目玉の一つにイヤホン(Earbud)のサポートがあります。

このイヤホン、実は両耳タイプも存在しているのですが、Explore招待プログラムの時期には発売されておらず、なんとか新型の入手に成功できたものの、同時購入することができずに悔しい思いをされている方も多いのではないかと思います。また標準添付のイヤホンもGlassのロゴをあしらったお洒落なデザインで見た目はかなりクールなのですが、実際に使ってみると装着感がいまひとつで常時着けて使うのには残念な品物でした。





そこでGlassに自分好みのイヤホンを付けられるようにしてみましたので、その方法についてレポートいたします。

iBeaconで海外渡航を楽しく

はじめに

飛行機を使った移動で一番困るのが到着時の荷物受け取り
いつまで待っても預けた荷物が出てこない、いやとっくの昔に出てしまったかも？、もしかしたらロストバゲット！？
流れるベルトコンベアを眺め続けながら、いつもこのような不安がよぎります・・・
今回はそんな悩みをiBeaconで解決してみたいと思います。

〔番外編〕 電力測定ツールも自作してみよう - アプリ編

※今回の記事は「〔番外編〕 電力測定ツールも自作してみよう」の続編です

今回は測定ツールの第２弾としてアプリケーション編を紹介いたします。


免責事項

この記事に書かれている内容は技術的な参考資料として記載しています
端末等の破損や作業上の事故について弊社および記事作成者は責任を持ちません
また設計上の品質についても保証を行っていませんので、作成時は各自で性能確認等を行うようにしてください。

１. 測定ツールの構成について

前回の記事である測定ツール自作編で作成したハードウェアは次のような構成になっていました。

今回の記事ではArduiono MEGA ADK側で動くスケッチとAndroidタブレットで動作するアプリを作成し、測定ツールで検出した電力値をAndroidタブレットに表示できるようにします。
・Arduino
　測定冶具で検出された電流信号をA/D変換しUSB-HOSTからAndroidタブレットにデータを送信
・Androidタブレット
　ADKプロトコルを使用して取得した測定値を画面に数値およびグラフ化して表示する

２．測定アプリ

今回作成したアプリは弊社内のニーズに基づき次のような機能を実装しました。
・ダミーバッテリの供給電圧
・現在の消費電流
・積算電力(積算電流)
・消費電流のグラフ

実際の表示画面はこのようになっています。

2-1. Arduinoのスケッチ

ADK2011(2012)のサンプルコードをベースに独自の機能を追加しました。
実際のコードについてはこちらを参照下さい スケッチ

・タイマー割り込みを使って1msecごとに電圧と電流のA/D変換
・取得した電流値を積算
・ADK経由でデータを送信

なおArduino上で実際の電圧/電流値に計算しようとすると処理時間が間に合わなくなることからAdruino側ではA/D変換とデータ保持のみを行い、実数化はAndroidアプリで行うようにしています。
被検対象となるAndroid端末のカーネルタイマーが1msecなので10倍の0.1msecごとに電流値を取ることができれば、より高精度な測定が可能となりますがアプリ動作の測定に絞るだけなら1msecでも十分評価できると思います。

<Tips> Android 4.1以降の端末でサンプルコードを使うには
公開されている初期のADKのソースコードはADK2011のみしか対応していないことからADK2012をサポートするAndroid4.1以降の端末ではADKを認識することができなくなりました。
その場合、次のようなパッチを当てると動作させることができます。
AndroidAccessory.cpp
bool AndroidAccessory::switchDevice(byte addr)
{
..
-    if (protocol == 1) {
+    if (protocol >= 1) {
        Serial.print("device supports protcol 1\n");
..
ただし今後のバージョンアップにてプロトコルの互換性が失われる場合がありますので使用にあたってはGoogleの動向をチェックするようにしてください

2-2. Androidアプリ

ADK2011のAPIを使い簡単なアプリケーションを作ってみました。
ADK経由でAdruionoからA/D変換値を取得し、アプリ側で電圧/電流/積算(Sum)に変換して表示します。また電流値をグラフ化して表示も行っています。
サンプルとしてアプリのソースコード添付しました ソースコード

Sum値は取得した電流値を積算したもので累積電力の目安として表示しています。
これがあると長時間に渡る消費電力を知ることができスリープ時の省電力を見るのに便利です。この値に電圧値を掛ければ電力値になりますが、今回アプリでは電圧を一定で測定しているので電流のみとしています。またもし表示を時間単位としたい場合はサンプリング時間を測りながら計算するように書き換えるととよいでしょう。

3.使用方法

・測定ツールと被検対象となる端末を接続してからACアダプタを接続します。
・ACアダプタからの給電が始まるとAndroidタブレットにADKのダイアログが表示されますのでOKボタンを押します。
・次にOFFボタンを押すとボタン表示がONに変わり測定が始まります。
・再度ONボタンを押すとOFFに戻り測定が中断します。スクリーンショットを取る場合に利用してください。
・Clearボタンは測定結果をクリアするときに使います、押すと積算値とグラフ時間軸がゼロに戻ります。

４. 少し特殊な使いかた

測定冶具基板に付いている半固定抵抗を回すとダミーバッテリの供給電圧を変えることができます。これによりバッテリ残量が少ないとき特有の挙動も見ることも可能です。電圧を可変させる際は Androidアプリ画面で表示している電圧値を見ながらバッテリ電圧範囲内でゆっくり可変させるようにして下さい。半固定抵抗は機械的接点で抵抗値を変動させているもののため、乱暴に回すと急激に電圧が変動し端末が破損する危険性があります。なお端末側で統計的に残量計算している機種が多いので反映するまでしばらく掛かる場合があります、その場合は一度再起動するとよいでしょう。

５. 今後の展開 -- 高機能版への進化

弊社ではこの測定ツールを進化させた商用版を準備しております。
本ブログで公開したものに比べてさらに次のような機能がパワーアップしています。
1. サンプリングの高速化
2. 取得データを収集サーバーへ転送
　サーバー側にデータを逐次送信することにより長期間の測定が可能になりました
3. 複数端末のデータ取得
　複数の測定ツールを同時使用することにより多くのデータを蓄積することができます
4. データの分析
　サーバー側で蓄積したデータを用いて統計的なデータ評価が可能となりました
　１台だけの評価に比べて試験環境による誤差が少なくなります

まとめ

今回で測定ツール自作編は終了となります。
ツールを自作することにより本ブログ開始時に使っていた機材に比べて小型軽量化され安価に消費電力が測れるようになりました。

蛇足ではありますが「あのスマホ」もダミーバッテリの作成を行い、端末の電力測定できるようにしました。弊社端末アプリ開発チームのところで重宝しております。

目的を絞ったツールを自作すれば測定器を揃えるよりも小型で安上がりに消費電力を確認することができることがご理解頂けたかと思います。
これで読者の方々のところでもツールを自作してみようという気風が高まれば幸いです。

ブランド戦略部 - 中村和貴

[コラム] NFC Hacks発売中です！

弊社で取りまとめを担当した書籍「NFC Hacks」がオライリー・ジャパン様から発売中です。



http://www.oreilly.co.jp/books/9784873116242/

1章　NFCを知る

1.　RFIDと非接触ICカード

2.　NFCの利点

3.　「NFCタグ」を知る

4.　NFCデバイスの3つのモード

5.　Reader/Writerモード

6.　Peer-to-Peerモード

7.　Card Emulationモード

8.　NFCを利用した国内のサービス

9.　NFCを利用した海外のサービス

10.　NFC対応デバイス

11.　対応チップ

12.　NFCの物理学的基礎

13.　電磁誘導の結合強度




2章　NFCの規格を知る

14.　NFC Forum Type 1 Tag

15.　NFC Forum Type 2 Tag

16.　NFC Forum Type 3 Tag

17.　NFC Forum Type 4 Tag

18.　ISO-DEPについて学ぶ

19.　NFC-DEPについて学ぶ

20.　LLCPについて学ぶ

21.　SNEPについて学ぶ

22.　NDEF

23.　RTD（Record Type Definition）




3章　AndroidでNFCをHackする

24.　SettingからNFCを設定する

25.　NFCタグを読み取るためのクラス群（android.nfcパッケージ）

26.　NFCタグのタイプ別機能のためのクラス群（android.nfc.techパッケージ）

27.　Android 2.3で使えるNFC機能

28.　Android 4.0で使えるAndroid Beam

29.　Android 4.1/4.2/4.3で使えるNFC機能

30.　Android端末をReaderモードで使う

31.　アプリケーションでNFCタグを読む方法

32.　NDEFを読み込むアプリを作成する

33.　Android端末をWriterモードで使う

34.　アプリケーションでNFCタグを書く方法

35.　NDEFを書き込むアプリを作成する

36.　Android Beamを知る

37.　Android Beamを送受信するアプリを作る

38.　Android Beam送信時にデフォルトのNDEFメッセージを送信しないようにする

39.　Bluetooth Handoverについて

40.　タグ情報を使いBluetoothデバイスに接続切断する

41.　Secure Elementを使用するCard Emulation機能について




4章　WindowsでNFCをHackする

42.　NFP機能を使う

43.　PC/SC

44.　PC/SCによるNDEFタグアクセス

45.　PC/SCによるNFCデバイスアクセス

46.　Proximity APIの利用

47.　Proximity APIでのNDEFアクセス

48.　Windows環境でのP2P通信




5章　セキュリティに配慮したNFC応用サービス

49.　キーポイントを押さえてセキュリティモデルを検討する

50.　非暗号化領域を利用しつつネットワーク連動サービスを構築する

NFCの基礎から、規格の詳細、Android/Win8での実装方法、NFCを応用したサービスについての考察など、幅広い内容になっています。

NFCについて一から勉強してみたい方、何となく知っているけど分からないことがある方、仕様を確認したい上級者の方にお勧めです。

ぜひ読んでみてください。

[コラム] Bluetoothデバイスは免許不要ってよく聞くけど...どういうことか？

Bluetoothは2.4GHz帯だから、免許不要だということをよく聞く。しかし、技適はとらなくちゃいけないというのもよく聞く。免許と技適って違うものなの？などと頭が混乱してくる。電波のことをやっていて、"技適"を知らないというのはどうも恥ずかしいことなのか、誰もちゃんと教えてくれない。技適のことを知らないと、安心してBLEを使えない。ということで、今回は、"技適をちゃんと知る"ということと、それとBLEがどう関係するのか、ということに焦点を当ててみる。

技適とは、日本の総務省が定める「技術基準適合証明又は工事設計認証」の略称。

認証制度について、総務省「電波利用ホームページ」の概要は、次のようになっている：

無線通信の混信や妨害を防ぎ、また、有効希少な資源である電波の効率的な利用を確保するため、無線局の開設は原則として免許制としており、当該無線局で使用する無線設備が技術基準に適合していることを免許申請の手続きの際に検査を行うこととしております。

ただし、携帯電話等の小規模な無線局に使用するための無線局であって総務省令で定めるもの（特定無線設備）については、使用者の利便性の観点から、事前に電波法に基づく基準認証を受け、総務省令で定める表示（技適マーク）が付されている場合には、免許手続時の検査の省略等の無線局開設のための手続について特例措置が受けられます。（特例措置の概要は下図参照。）

ここでは、この特例措置の適用を受けるために必要な無線設備に関する基準認証制度の概要をご紹介します。なお、詳細は電気通信機器基準認証制度マニュアルをご参照ください。

ちなみに、技適マークとは、こんなマーク。
（左が平成７年４月から運用されているもの。右は昭和62年10月からの旧マーク。詳しくは、ここを参照。）

日本国内で電波を発する製品はすべてこの技適を取得していないといけない。技適マークが付いていない無線機器を使用すると、電波法違反になる。さらに、技適を取得していたとしても、一般の無線機器は総務大臣の免許が必要となる。ただし、上の概要にあるように、特定無線設備に関しては、技適を取得していれば、総務大臣の免許が不要になる。つまり、免許が不要というのはこの意味だったのである。ただし、無線機器としての性能などは保証されなければいけないので、認証を受ける必要があるということだ。ということは、Bluetoth機器は、この特定無線設備に含まれるということなのか？特定無線設備について、見てみる。

特定無線設備は大きく分けて、４つある。

1. 免許不要局（２０種別）
2. 特定無線局（３７種別）
3. その他（１００種別）
4. 特別特定無線設備（２４種別）

Bluetoothデバイスは、2.4GHz帯（2,402〜2,480MHz）を用いるので、免許不要局の

　2.4GHz帯高度化小電力データ通信システム(2,400～2,483.5MHz)

に属している。

というわけで、Bluetoothについては、技適は必要だが、総務大臣の免許は不要ということで一応納得できました。

参照URL：

• wikipedia 
• 総務省「電波利用ホームページ」
• 総務省資料「日本における無線通信機器の基準認証制度の概要」
• 無線化.com

余録

日本国内については、技適という認証が必要ですが、海外ではどうなっているのでしょうか。海外では、例えば、北米では、FCC認証、ヨーロッパでは、CE認証というものがあります。

そして、現在、相互承認協定（MRA）という、外国に行って認証試験を受けなくても、その国の認証試験が国内で受けられるという制度があります。電気通信機器に関しては、日欧間(平成14年１月発効)、日シンガポール間(平成14年11月発効)日米間（平成20年1月発効）で締結されています。これは、携帯電話などを海外へ輸出するメーカーにとっては、コスト面などで非常に助かる制度になっています。

[コラム] Bluetooth トレーニングイベントに参加してきました。

本日、大阪IMPビルで開かれた、BluetoothSIG主催のBluetoothトレーニングイベントに参加してきました。

https://www.bluetooth.org/ja-jp/Pages/qualification-training-sessions.aspx

私自身BluetoothSIGのイベントに参加するのは初めてなのですが、BLEによる盛り上がりを受けてなのか、アジアでは東京、大阪、ソウル、上海と連続して本イベントが開かれ、BluetoothSIGが今回のイベントに非常に力を入れているのがわかりました。またこれ以降も、ブレイクスルー・アワード 2014（12/4受付締切、1/6結果発表）、1月にはCES、2月にはMWCとイベントが続きます。スポンサー企業を中心にこの流れを維持し、マーケットを開拓していこうというムードが伝わってきました。

ざっと、内容を記載します。

      前半      

BluetoothSIGからのあいさつ
  Marriot Winquist (Bluetooth SIG)

Bluetoothの基礎概観（Part1）
  Masamitsu Suzuki  (Texas Instruments)

• Bluetoothの歴史
• アーキテクチャの説明
• プロファイルの説明
• BR/EDR（クラシックBT）のプロファイル
• BLEのプロファイル

Bluetoothの基礎概観（Part２）
  Masahiko Seki (MCPC/Sony)

• GATT-Based Profile 概観

MCPC プレゼンテーション
　モバイルシステム検定試験の案内

　※MCPC（モバイルコンピューティング推進コンソーシアム）は、
　　モバイルコンピューティングの健全な発展のためと環境整備のために
　　設立された組織で、研究機関、企業などにより運営されています。
　　（http://www.mcpc-jp.org/）

Texas Instruments プレゼンテーション
　自社商品「SensorTag」の紹介


      後半      

Interoperabiliy & Testing
  Sakai Itsuo (MCPC/TUV), Asami Yokoi(Frontline)

Qualification and Listing
  Takayuki Shimada (UL vs Ltd)

Frontline社アナライザの紹介

Ellisys社のアナライザ紹介

BluetoothSIGのマーケティングプログラムの紹介
　再びMarriotさん


以上。

前半のアーキテクチャやプロファイルは、一度アンドロイドのミドル層のBluetoothの開発に携わったこともあり、だいたい知っていましたので、「ああ、そうだったなあ」と忘れてた記憶が呼び起されて、いい復習になりました。HIDプロファイルは、単なる土管で、実装者はUSBのHIDファンクションを使わないといけないということをおっしゃっていて、以前からUSBのHIDと、BluetoothのHIDは似てるけど同じものなの？と思っていたのですが、そのなぞが解けました。

これから様々なGATTベースのプロファイルがBLEで導入されるらしいです。世の中に出回っていないものはまだBluetoothSIGのワーキンググリープ内で検討中らしいです。講演で紹介されていたそのようなプロファイルの中に、「Indoor Positionning」というプロファイルがありました。BLEを使った測位は、このブログの中でも取り組んでいますが、電波の精度に問題があります。しかし、BluetoothSIGの中で検討されているということはまだまだあきらめてはいけないという気になりますね。

後半になると、会場の雰囲気が変わりました。みなメモをとるぞ～という体勢になりました。私もそうなのですが、みなBluetoothの認証試験の仕組みややり方を知りたがっていたのでしょう。最初のSakaiさんの説明は、わかっている人には非常に詳しく、ノウハウが詰まった内容となっていたのでしょうが、私には使用している言葉（Componentとか、Subsystemとかいう言葉）が理解できず、ほとんど頭に入ってきませんでした。ただし、次の嶋田さんのレクチャーは、まずComponentやSubsystemという言葉の説明からされていたので、とてもわかりやすかったです。Sakaiさんと嶋田さんの順番が逆だったなら、Sakai さんの説明がよくわかっただろうなあ、と思いました。残念です。

トレーニングとは関係ありませんが、お昼に参加者全員分のお弁当が用意されていたのには驚きました。おかげでお昼代が浮きました。また、午前と午後に15分ほどの休憩時間が入ったのですが、コーヒーが用意されていました。単純に、BluetoothSIGっていいね！って思いました。ほんと。

今回は、BluetoothSIGの方たちの意気込みを感じることができ、たいへん貴重な体験となりました。iBeaconをとっかかりにこのブログを始めましたが、iBeaconという枠組みが非常に小さな枠組みであることを痛感しました。iBeaconは、Appleの作ったiOSのLocation機能の一部です。BLEの波はそれよりもずっと広大で、スマートフォン、ウェアラブル、家電などを巻き込んでいくものです。BLEの未来は明るいです。

追記

正直言って、iBeaconだけではネタが尽きかけていたので、今後はBLEに視野を広げブログ更新していきます。

[コラム] Android 4.4 Kitkat詳細（開発者向けハイライト・その４）

原文：Android KitKat | Android Developers

[コラム] Android 4.4 Kitkat詳細（開発者向けハイライト・その３）

原文：Android KitKat | Android Developers

[コラム] スマベン関西に参加してきました。

11月2日(土)に、スマベン（=スマートフォン勉強会）関西が開かれました。

http://sumaben.jp/?KansaiSpecial05BLE

今回は、メインスピーカーに上原昭宏氏を迎えて、Bluetooth Low Energyの勉強会をするということで私も参加してきました。

参加者はハードウェアの製造をされる方からソフト開発者、ウェブサービス開発者、マスコミ関係者まで幅広く、マッシュアップが非常に期待される顔ぶれでした。それほどBLE/iBeaconに対する各分野からの関心が高いということでしょう。

[コラム] Android 4.4 Kitkat詳細（開発者向けハイライト・その２）

原文：Android KitKat | Android Developers

[コラム] Android 4.4 Kitkat詳細（開発者向けハイライト・その１）

原文：Android KitKat | Android Developers

[コラム] Android4.4 Kitkat 速報（コンシューマ向けハイライト・後編）

Android 4.4 Kitkatが発表されました。本記事では速報として概要をお届け致します。

※前編に続いて、詳細機能の概要です。