IoT
ESP32 モジュールのフラッシュメモリ暗号化機構に関するメモ
ESP-WROOM-32 の内蔵フラッシュメモリについて調べていたところで Flash Encryption に興味を持ちその便利さを実感しました。 利用方法にやや込み入った要素も含まれるため自分用のメモとして一連の情報を控えておくことにします。
- Flash Encryption - ESP-IDF Programming Guide - esp-idf.readthedocs.io
重要： この記事には誤りが含まれている可能性があります。たとえその誤りが原因で何処かで何らかの損害が発生したとしても筆者ならびに当社は一切の責任を負いません。実験や操作は上記公式ドキュメントを熟読の上必ず自己責任で慎重に行って下さい。
概要
ESP32 モジュールのフラッシュメモリは esptool を使えば簡単に読み書きできるためバックアップ等に便利ですが、その一方で、自分の手を離れた場所で装置を稼働させる場合などに他者に不正なクローンを作成されたりコードに含まれるセンシティブな情報を読まれてしまう可能性もあります。 こういった懸念は Flash Encryption 機構を利用すれば格段に軽減されます。所定のモジュールのもとで暗号化したイメージを他のモジュールへ持ち込んで稼働させることはできず、そこから情報を窃視することもできません。
ただし、Flash Encryption の利用には大きくふたつの注意すべき点があります。
- ESP32 チップ内の OTP メモリへの不可逆な書き込みを伴う
- ひとたび Flash Encryption を適用したモジュールにおいてそれ以降のイメージの更新時に再暗号化を実施可能な回数は「3 回」まで
このように、アクティブな開発や実験のフェーズ向きではなくおおむねプログラム完成段階での本番機や製品への適用を想定した機構と言えるでしょう。そういった事情も相まってか、これを積極的に利用している個人ユーザは今のところあまり多くないように見受けられます。
フラッシュメモリ暗号化の多くのメリットを考えると惜しく感じられますが、実際には上記 2. の制限は「事前生成暗号化キー」を適切に取り回すことで回避が可能です。その方法であれば Flash Encryption をごく手軽に扱えるため、たとえばプロトタイピング段階での試作機での利用など様々な活用方法が考えられるでしょう。
以下の記事では、最初に Flash Encryption のしくみの整理を行い、次に上記の事前生成暗号化キーを利用する手順と実際にその操作を行った記録を列挙、最後に Arduino core for ESP32 環境での対応方法等について手元で行った実験の内容とその結果に触れています。 なお、Espressif は別のセキュリティ機構である Secure Boot との併用を推奨していますが、この記事ではまず Flash Encryption 単体に注目しています。
Flash Encryption のしくみ
まず、公式ドキュメントの内容をもとに Flash Encryption のしくみを整理します。
全体像
- Flash Encryption は ESP32 モジュールの内蔵フラッシュメモリ上の所定のパーティションの内容を AES-256 で暗号化するもの
- 暗号化キーは当該モジュールで初めて暗号化を行う際に ESP32 チップ内の efuse 領域内にランダムに生成され永続的に保持される。生成されたキーへの外部からのアクセスはデフォルトで不可
- ESP32 efuse の詳細 => espefuse - github.com/espressif
- 暗号化はブートローダが行う。具体的には、make menuconfig - [Security Features] - [Enable flash encryption boot] オプションを有効にした状態でビルドしたブートローダが、他のパーティションイメージとともに make flash された後の初回起動時に一括して暗号化を実施する
- つまり、上記オプションはその目的に即したブートローダコードを生成するものであり、その他のパーティションイメージは通常の内容でビルドされる
- 暗号化の対象は以下のとおり
- ブートローダ （オフセット 0x1000, 最長サイズ 0x7000 バイト）
- パーティションテーブル （オフセット 0x8000, サイズ 0xC00 バイト）
- Type = app のパーティション
- encrypted フラグの指定されたパーティション
- ただし、手元の確認では設定上 spiffs パーティションの定義に「spiffs,data,spiffs,0x291000,0x16F000,encrypted」の要領で指定を付与し暗号化を有効にしたところプログラム実行時に次のエラーが発生した： "spiffs can not run on encrypted partition"
- nvs パーティション （key-value ストア領域） を暗号化することはできない。 spiffs と同様に nvs にも専用の API セットが用意されておりそっち側の実装とのかねあいだったり？
- ドキュメント上の関連箇所の引用。ちなみに手元ではまだ使ったことのない「phy」パーティションについての言及があるが、「physical access readout」が NG につき esptool 等で読み出し不能であるためトレードオフを理解した上で利用すべきだろう
- None of the default partition tables include any encrypted data partitions.
- It is not necessary to mark “app” partitions as encrypted, they are always treated as encrypted.
- The “encrypted” flag does nothing if flash encryption is not enabled.
- It is possible to mark the optional phy partition with phy_init data as encrypted, if you wish to protect this data from physical access readout or modification.
- It is not possible to mark the nvs partition as encrypted.
- 稼働中のプログラムからフラッシュメモリ上のデータ参照の際の復号は透過的に行われる
注意点
Flash Encryption においては 8 ビットの「FLASH_CRYPT_CNT」efuse が非常に重要。あらかじめその役割と意味を正しく把握しておく必要がある。
- まず、手元にある Flash Encryption 未実施の ESP32-DevKitC に対し Espressif 提供の espefuse ユーティリティの summary コマンド, dump コマンドを実行した結果を以下に示す
$ espefuse.py --port /dev/ttyUSB0 summary espefuse.py v2.3.1 Connecting..... Security fuses: FLASH_CRYPT_CNT Flash encryption mode counter = 0 R/W (0x0) FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 0 R/W (0x0) CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 0 R/W (0x0) ABS_DONE_0 secure boot enabled for bootloader = 0 R/W (0x0) ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0) JTAG_DISABLE Disable JTAG = 0 R/W (0x0) DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0) DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0) DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0) BLK1 Flash encryption key = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W BLK2 Secure boot key = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W BLK3 Variable Block 3 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W Efuse fuses: WR_DIS Efuse write disable mask = 0 R/W (0x0) RD_DIS Efuse read disablemask = 0 R/W (0x0) CODING_SCHEME Efuse variable block length scheme = 0 R/W (0x0) KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0) Config fuses: XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0) XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0) XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0) SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0) SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0) SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0) SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0) SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0) DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0) Identity fuses: MAC MAC Address = 30:ae:a4:02:59:c0 (CRC 9b OK) R/W CHIP_VER_REV1 Silicon Revision 1 = 0 R/W (0x0) CHIP_VERSION Reserved for future chip versions = 0 R/W (0x0) CHIP_PACKAGE Chip package identifier = 0 R/W (0x0) Calibration fuses: BLK3_PART_RESERVE BLOCK3 partially served for ADC calibration data = 0 R/W (0x0) ADC_VREF Voltage reference calibration = 1100 R/W (0x0) Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
$ espefuse.py --port /dev/ttyUSB0 dump espefuse.py v2.3.1 Connecting.... EFUSE block 0: 00000000 a40259c0 009b30ae 00000000 00000036 00000000 00000000 EFUSE block 1: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 EFUSE block 2: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 EFUSE block 3: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
- FLASH_CRYPT_CNT は暗号化を行った回数と暗号化の有効無効状態を管理する。初期値は上のとおりゼロ （BIN: 0000 0000）であり、ブートローダが初めて暗号化を行った時点で BIN:0000 0001 に変化する （不可逆）
- FLASH_CRYPT_CNT の ON ビット数が偶数の場合は暗号化が無効な状態、奇数の場合は暗号化が有効な状態であることを示す
- FLASH_CRYPT_CNT の ON ビット数が奇数、すなわち暗号化が有効な状態で別のプレーンなイメージを make flash すると起動不可となる。これは、ESP32 が efuse 領域に保持しているキーで暗号化されたイメージの期待される状況であるにもかかわらず場違いなイメージに直面した結果の所作
- Device keeps rebooting - www.esp32.com
- Disabling Flash Encryption - Flash Encryption - esp-idf.readthedocs.io
If you’ve accidentally enabled flash encryption for some reason, the next flash of plaintext data will soft-brick the ESP32 (the device will reboot continously, printing the error flash read err, 1000). :
- Device keeps rebooting - www.esp32.com
- 上記のような場合には以下の手順で Flash Encryption を無効化することができる （注：手元ではこの操作は未確認）
- make menuconfig - [Security Features] - [Enable flash encryption boot] オプションを確実に無効化して make && make flash
- 手作業で FLASH_CRYPT_CNT の ON ビット数を偶数にすることで暗号化無効の状態にする。具体的には、espefuse ユーティリティを使って FLASH_CRYPT_CNT に対し burn_efuse コマンドを発行すると現在もっとも上位の ON ビットの左側のビットが ON になる。つまり、FLASH_CRYPT_CNT ＝ BIN:0000 0001 の状態で実行すると BIN:0000 0011 に変化する => ON ビット数が偶数なので暗号化無効状態
espefuse.py --port /dev/ttyUSB0 burn_efuse FLASH_CRYPT_CNT
- ESP32 ボードをリセットすると正常に稼働する
- OTP メモリである efuse 領域への変更は不可逆であるため、8 ビットの FLASH_CRYPT_CNT に対する上記の「暗号化と無効化」の上限回数は 4 回。以下に状態の一覧を示す。 9. の無効化 4 回めで全ビットが ON ＝ 0xFF になると当該 ESP32 モジュールでの Flash Encryption は永久に無効となる
- BIN:0000 0000 工場出荷時
- BIN:0000 0001 暗号化 1 回め
- BIN:0000 0011 無効化 1 回め
- BIN:0000 0111 暗号化 2 回め
- BIN:0000 1111 無効化 2 回め
- BIN:0001 1111 暗号化 3 回め
- BIN:0011 1111 無効化 3 回め
- BIN:0111 1111 暗号化 4 回め
- BIN:1111 1111 無効化 4 回め
- なお、ある時点での FLASH_CRYPT_CNT の状態を永続化させたい場合は espefuse.py の write_protect_efuse コマンドを実行する。誤って実行すると手詰まりになるため要注意
espefuse.py --port /dev/ttyUSB0 write_protect_efuse FLASH_CRYPT_CNT
- また、以下の事情にも注意が必要
- Read- and Write- protecting efuses - espefuse - github.com/espressif
NOTE that efuses are often read/write protected as a group, so protecting one will cause some related efuses to become protected. espefuse.py will confirm the full list of efuses that will become protected.
- Read- and Write- protecting efuses - espefuse - github.com/espressif
事前生成暗号化キーの利用による Flash Encryption
ESP32 チップ内部に保持されるフラッシュメモリ暗号化キーはホスト PC 上で生成することが可能です。キーの生成を ESP32 側で行うとそれ以降の暗号化処理は前述の FLASH_CRYPT_CNT の管理下でブートローダへ委ねることになりますが、ホスト PC 上でキーを生成すれば開発者が主体的に所定のイメージの暗号化を行うことが可能となり、貴重な FLASH_CRYPT_CNT を消費することなく Flash Encryption を継続的に利用できます。ホスト PC 上で生成したキーは espefuse ユーティリティの burn_key コマンドで ESP32 の efuse 領域へ書き込んだ上で使用します。
概要
ドキュメントより。
- Reflashing via Pregenerated Flash Encryption Key - Flash Encryption - esp-idf.readthedocs.io
Reflashing via Pregenerated Flash Encryption Key
Google 訳：
It is possible to pregenerate a flash encryption key on the host computer and burn it into the ESP32’s efuse key block. This allows data to be pre-encrypted on the host and flashed to the ESP32 without needing a plaintext flash update.
This is useful for development, because it removes the 4 time reflashing limit. It also allows reflashing the app with secure boot enabled, because the bootloader doesn’t need to be reflashed each time.
Important
This method is intended to assist with development only, not for production devices. If pre-generating flash encryption for production, ensure the keys are generated from a high quality random number source and do not share the same flash encryption key across multiple devices.
:事前生成されたフラッシュ暗号化キーによるリフラッシュ
ホストコンピュータにフラッシュ暗号化キーを事前に生成し、ESP32のefuseキーブロックに書き込むことができます。これにより、データをホスト上で事前暗号化し、平文フラッシュ更新を必要とせずにESP32にフラッシュすることができます。
これは4回のリフラッシュ制限を取り除くため、開発に役立ちます。また、毎回ブートローダをリフラッシュする必要がないため、セキュアブートを有効にしてアプリをリフラッシュすることもできます。
重要
このメソッドは、開発の支援のみ目的としており、本番用のデバイス用ではありません。プロダクション用のフラッシュ暗号化を事前生成する場合は、キーが高品質の乱数ソースから生成され、複数のデバイス間で同じフラッシュ暗号化キーを共有しないようにしてください。
:
手順
以下の一連の手順では、既出の esptool, espefuse に加え、espsecure ユーティリティを使用する。
初回の暗号化を終えるまで
第一段階として、まず初回の暗号化までを完了させる。ホスト PC 上で生成した暗号化キーを ESP32 の efuse へ先行して書き込むことがここでのポイント。
espsecure.py generate_flash_encryption_key ./mykey.bin
espefuse.py --port /dev/ttyUSB0 burn_key flash_encryption ./mykey.bin
※この手順で下記「3. 初回の Flash Encryption」に先行して efuse へ暗号化キーを書き込むことにより、本来はブートローダによる初回の暗号化実行の前処理として ESP32 チップ内で行われる暗号化キーの生成がスキップされる
初回の暗号化は事前生成キーを使わない場合の手順と同じ
ホスト PC 上でのイメージの暗号化とフラッシュメモリへの書き込み
初回の暗号化は上の手順で OK。それ以降にビルドしたイメージについては手元で暗号化を行った上で ESP32 へ転送すればよい。以下の例は app パーティションイメージ分だが、必要に応じて他のイメージも暗号化して書き込む。なお、ビルドしたままの状態のブートローダイメージを再度フラッシュしてはならない。ESP32 側ではブートローダ自体もすでに暗号化されているため。
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o build/mySimpleApp_Encrypted.bin build/mySimpleApp.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0x10000 build/mySimpleApp_Encrypted.bin
前項の操作を行った記録
手元で実際に前項の操作を行いその様子と結果を記録しました。これが初めての Flash Encryption の操作で、各動画は一発撮りしたものです。
テスト用のプログラムとして以下の「mySimpleApp.c」を使用。LED 点滅ループ中に Flash Encryption の有効無効状態をシリアル出力する内容。
動画 A
以下、事前生成暗号化キーを使った Flash Encryption 操作の記録。
#include <stdio.h>
#include "esp_flash_encrypt.h"
#include "esp_event.h"
#include "esp_log.h"
#include "driver/gpio.h"
const char *secretData = "**** this is secret data ****";
const char *TAG = "TAG";
void app_main()
{
ESP_LOGI(TAG, "%s", secretData);
gpio_set_direction(GPIO_NUM_2, GPIO_MODE_OUTPUT);
int sts = 1;
for (int i = 0; i < 10; i++) {
if (esp_flash_encryption_enabled()) {
ESP_LOGI(TAG, "Flash Encryption is enabled");
} else {
ESP_LOGI(TAG, "Flash Encryption is disabled");
}
gpio_set_level(GPIO_NUM_2, sts);
sts = !sts;
vTaskDelay(1000 / portTICK_PERIOD_MS);
}
}
まず Flash Encryption 有効化前の素の状態のボードに対し make flash monitor を行った様子。"Flash Encryption is disabled" の出力が見える。
これで FLASH_CRYPT_CNT を気にすることなく Flash Encryption を利用できるようになりました。
$ espsecure.py generate_flash_encryption_key ./mykey.bin
espsecure.py v2.3.1
$ espefuse.py --port /dev/ttyUSB0 burn_key flash_encryption ./mykey.bin
espefuse.py v2.3.1
Connecting......
Write key in efuse block 1. The key block will be read and write protected (no further changes or readback). This is an irreversible operation.
Type 'BURN' (all capitals) to continue.
BURN
Burned key data. New value: 6a 60 3c a7 d0 3f d4 9f b0 a3 f9 ca 77 61 10 47 30 57 80 c5 5c fd bc a0 ce 30 3e 36 b1 b5 ac c4
Disabling read/write to key efuse block...
動画 B
$ espefuse.py --port /dev/ttyUSB0 summary
espefuse.py v2.3.1
Connecting......
Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 0 R/W (0x0)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 0 R/W (0x0)
ABS_DONE_0 secure boot enabled for bootloader = 0 R/W (0x0)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
JTAG_DISABLE Disable JTAG = 0 R/W (0x0)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0)
BLK1 Flash encryption key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -/-
BLK2 Secure boot key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK3 Variable Block 3
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
Efuse fuses:
WR_DIS Efuse write disable mask = 128 R/W (0x80)
RD_DIS Efuse read disablemask = 1 R/W (0x1)
CODING_SCHEME Efuse variable block length scheme = 0 R/W (0x0)
KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0)
Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0)
SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0)
SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0)
SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0)
DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0)
Identity fuses:
MAC MAC Address
= 30:ae:a4:02:59:c0 (CRC 9b OK) R/W
CHIP_VER_REV1 Silicon Revision 1 = 0 -/W (0x0)
CHIP_VERSION Reserved for future chip versions = 0 -/W (0x0)
CHIP_PACKAGE Chip package identifier = 0 -/W (0x0)
Calibration fuses:
BLK3_PART_RESERVE BLOCK3 partially served for ADC calibration data = 0 -/W (0x0)
ADC_VREF Voltage reference calibration = 1100 -/W (0x0)
Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
$ espefuse.py --port /dev/ttyUSB0 dump
espefuse.py v2.3.1
Connecting....
EFUSE block 0:
00010080 a40259c0 009b30ae 00000000 00000036 00000000 00000000
EFUSE block 1:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 2:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 3:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
$ make
CC build/bootloader/bootloader_support/src/bootloader_clock.o
CC build/bootloader/bootloader_support/src/bootloader_flash.o
CC build/bootloader/bootloader_support/src/bootloader_init.o
CC build/bootloader/bootloader_support/src/bootloader_random.o
CC build/bootloader/bootloader_support/src/bootloader_sha.o
CC build/bootloader/bootloader_support/src/bootloader_utility.o
CC build/bootloader/bootloader_support/src/efuse.o
（中略）
CC build/xtensa-debug-module/trax.o
AR build/xtensa-debug-module/libxtensa-debug-module.a
LD build/mySimpleApp.elf
esptool.py v2.3.1
To flash all build output, run 'make flash' or:
python /home/t/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/bootloader/bootloader.bin 0x10000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/mySimpleApp.bin 0x8000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/partitions_singleapp.bin
余談ながら、上の最終行のコマンド例中の「--after hard_reset」の記述が気になり Advanced Options - espressif/esptool Wiki で確認したところ、「--after no_reset」オプションの存在を知った。デフォルトは「--after hard_reset」。esptool 操作後に自動的にリセットがかかると具合のわるい場合があるが、no_reset 指定でそれを回避できることを覚えた。
動画 C
$ make flash monitor
Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.3.1
Connecting........_
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 25296 bytes to 14703...
Wrote 25296 bytes (14703 compressed) at 0x00001000 in 1.3 seconds (effective 156.4 kbit/s)...
Hash of data verified.
Compressed 140160 bytes to 68713...
Wrote 140160 bytes (68713 compressed) at 0x00010000 in 6.1 seconds (effective 184.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.0 seconds (effective 1885.7 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (31) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (31) boot: compile time 16:28:39
I (31) boot: Enabling RNG early entropy source...
I (37) boot: SPI Speed : 40MHz
I (41) boot: SPI Mode : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label Usage Type ST Offset Length
I (60) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (67) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (75) boot: 2 factory factory app 00 00 00010000 00100000
I (82) boot: End of partition table
I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05888 ( 22664) map
I (103) esp_image: segment 1: paddr=0x000158b0 vaddr=0x3ffb0000 size=0x02284 ( 8836) load
I (107) esp_image: segment 2: paddr=0x00017b3c vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685
I (113) esp_image: segment 3: paddr=0x00017f44 vaddr=0x40080400 size=0x080cc ( 32972) load
I (136) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?
I (161) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884cc size=0x00668 ( 1640) load
0x400884cc: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412
I (162) esp_image: segment 6: paddr=0x0003235c vaddr=0x400c0000 size=0x00000 ( 0) load
I (174) boot: Loaded app from partition at offset 0x10000
I (174) boot: Checking flash encryption...
W (179) flash_encrypt: Using pre-loaded flash encryption key in EFUSE block 1
I (187) flash_encrypt: Setting CRYPT_CONFIG efuse to 0xF
I (205) flash_encrypt: Disable UART bootloader encryption...
I (205) flash_encrypt: Disable UART bootloader decryption...
I (208) flash_encrypt: Disable UART bootloader MMU cache...
I (214) flash_encrypt: Disable JTAG...
I (218) flash_encrypt: Disable ROM BASIC interpreter fallback...
I (237) esp_image: segment 0: paddr=0x00001020 vaddr=0x3fff0018 size=0x00004 ( 4)
I (237) esp_image: segment 1: paddr=0x0000102c vaddr=0x3fff001c size=0x01ce8 ( 7400)
I (247) esp_image: segment 2: paddr=0x00002d1c vaddr=0x40078000 size=0x00000 ( 0)
I (253) esp_image: segment 3: paddr=0x00002d24 vaddr=0x40078000 size=0x04584 ( 17796)
I (701) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05888 ( 22664) map
I (709) esp_image: segment 1: paddr=0x000158b0 vaddr=0x3ffb0000 size=0x02284 ( 8836)
I (712) esp_image: segment 2: paddr=0x00017b3c vaddr=0x40080000 size=0x00400 ( 1024)
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685
I (716) esp_image: segment 3: paddr=0x00017f44 vaddr=0x40080400 size=0x080cc ( 32972)
I (736) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?
I (762) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884cc size=0x00668 ( 1640)
0x400884cc: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412
I (763) esp_image: segment 6: paddr=0x0003235c vaddr=0x400c0000 size=0x00000 ( 0)
I (768) flash_encrypt: Encrypting partition 2 at offset 0x10000...
[0;3oets Jun 8 2016 00:22:57
rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (30) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (30) boot: compile time 16:28:39
I (30) boot: Enabling RNG early entropy source...
I (36) boot: SPI Speed : 40MHz
I (41) boot: SPI Mode : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label Usage Type ST Offset Length
I (59) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (67) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (74) boot: 2 factory factory app 00 00 00010000 00100000
I (82) boot: End of partition table
I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x05888 ( 22664) map
I (103) esp_image: segment 1: paddr=0x000158b0 vaddr=0x3ffb0000 size=0x02284 ( 8836) load
I (107) esp_image: segment 2: paddr=0x00017b3c vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685
I (113) esp_image: segment 3: paddr=0x00017f44 vaddr=0x40080400 size=0x080cc ( 32972) load
I (136) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?
I (163) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884cc size=0x00668 ( 1640) load
0x400884cc: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412
I (163) esp_image: segment 6: paddr=0x0003235c vaddr=0x400c0000 size=0x00000 ( 0) load
I (175) boot: Loaded app from partition at offset 0x10000
I (175) boot: Checking flash encryption...
I (180) flash_encrypt: flash encryption is enabled (3 plaintext flashes left)
I (188) boot: Disabling RNG early entropy source...
I (193) cpu_start: Pro cpu up.
I (197) cpu_start: Starting app cpu, entry point is 0x40080e4c
0x40080e4c: call_start_cpu1 at /home/t/esp/esp-idf/components/esp32/cpu_start.c:225
I (0) cpu_start: App cpu up.
I (208) heap_init: Initializing. RAM available for dynamic allocation:
I (214) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (220) heap_init: At 3FFB32C0 len 0002CD40 (179 KiB): DRAM
I (227) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (233) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (239) heap_init: At 40088B34 len 000174CC (93 KiB): IRAM
I (246) cpu_start: Pro cpu start user code
I (264) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (265) TAG: **** this is secret data ****
I (265) TAG: Flash Encryption is enabled
I (1265) TAG: Flash Encryption is enabled
I (2265) TAG: Flash Encryption is enabled
I (3265) TAG: Flash Encryption is enabled
I (4265) TAG: Flash Encryption is enabled
I (5265) TAG: Flash Encryption is enabled
I (6265) TAG: Flash Encryption is enabled
I (7265) TAG: Flash Encryption is enabled
I (8265) TAG: Flash Encryption is enabled
I (9265) TAG: Flash Encryption is enabled
動画 D
$ espefuse.py --port /dev/ttyUSB0 summary
espefuse.py v2.3.1
Connecting.....
Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 1 R/W (0x1)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 1 R/W (0x1)
ABS_DONE_0 secure boot enabled for bootloader = 0 R/W (0x0)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
JTAG_DISABLE Disable JTAG = 1 R/W (0x1)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 1 R/W (0x1)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 1 R/W (0x1)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 1 R/W (0x1)
BLK1 Flash encryption key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -/-
BLK2 Secure boot key
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLK3 Variable Block 3
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
Efuse fuses:
WR_DIS Efuse write disable mask = 128 R/W (0x80)
RD_DIS Efuse read disablemask = 1 R/W (0x1)
CODING_SCHEME Efuse variable block length scheme = 0 R/W (0x0)
KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0)
Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0)
SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0)
SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0)
SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0)
DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0)
Identity fuses:
MAC MAC Address
= 30:ae:a4:02:59:c0 (CRC 9b OK) R/W
CHIP_VER_REV1 Silicon Revision 1 = 0 -/W (0x0)
CHIP_VERSION Reserved for future chip versions = 0 -/W (0x0)
CHIP_PACKAGE Chip package identifier = 0 -/W (0x0)
Calibration fuses:
BLK3_PART_RESERVE BLOCK3 partially served for ADC calibration data = 0 -/W (0x0)
ADC_VREF Voltage reference calibration = 1100 -/W (0x0)
Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).
$ espefuse.py --port /dev/ttyUSB0 dump espefuse.py v2.3.1
Connecting......
EFUSE block 0:
00110080 a40259c0 009b30ae 00000000 00000036 f0000000 000003c4
EFUSE block 1:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 2:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
EFUSE block 3:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
$ esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0x10000 build/mySimpleApp.bin; make monitor
esptool.py v2.3.1
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 140160 bytes to 68713...
Wrote 140160 bytes (68713 compressed) at 0x00010000 in 1.5 seconds (effective 730.5 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (31) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (31) boot: compile time 16:28:39
I (31) boot: Enabling RNG early entropy source...
I (37) boot: SPI Speed : 40MHz
I (41) boot: SPI Mode : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label Usage Type ST Offset Length
I (60) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (67) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (75) boot: 2 factory factory app 00 00 00010000 00100000
I (82) boot: End of partition table
E (86) esp_image: image at 0x10000 has invalid magic byte
W (92) esp_image: image at 0x10000 has invalid SPI mode 255
E (99) boot: Factory app partition is not bootable
E (104) boot: No bootable app partitions in the partition table
user code done
前掲のドキュメント記述のように「flash read err, 1000」のエラー出力とリブートのループを予想したがここではこのように「boot: Factory app partition is not bootable」の表示で停止した。このあたりの事情はまだよくわからない
動画 E
変更前
ESP_LOGI(TAG, "Flash Encryption is enabled");
変更後
ESP_LOGI(TAG, "Flash Encryption is enabled!!!!");
$ make
CC build/main/mySimpleApp.o
AR build/main/libmain.a
LD build/mySimpleApp.elf
esptool.py v2.3.1
To flash all build output, run 'make flash' or:
python /home/t/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/bootloader/bootloader.bin 0x10000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/mySimpleApp.bin 0x8000 /home/t/Arduino/my/for_ESP-IDF/mySimpleApp/build/partitions_singleapp.bin
$ espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o build/mySimpleApp_encrypted.bin build/mySimpleApp.bin
espsecure.py v2.3.1
$ esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0x10000 build/mySimpleApp_encrypted.bin; make monitor
esptool.py v2.3.1
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 140176 bytes to 138083...
Wrote 140176 bytes (138083 compressed) at 0x00010000 in 2.2 seconds (effective 509.0 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
MONITOR
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:7400
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:17796
entry 0x40078724
I (31) boot: ESP-IDF v3.1-dev-1171-g358c822 2nd stage bootloader
I (31) boot: compile time 16:28:39
I (31) boot: Enabling RNG early entropy source...
I (37) boot: SPI Speed : 40MHz
I (41) boot: SPI Mode : DIO
I (45) boot: SPI Flash Size : 4MB
I (49) boot: Partition Table:
I (52) boot: ## Label Usage Type ST Offset Length
I (60) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (67) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (75) boot: 2 factory factory app 00 00 00010000 00100000
I (82) boot: End of partition table
I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x0588c ( 22668) map
I (103) esp_image: segment 1: paddr=0x000158b4 vaddr=0x3ffb0000 size=0x02284 ( 8836) load
I (108) esp_image: segment 2: paddr=0x00017b40 vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _iram_start at /home/t/esp/esp-idf/components/freertos/xtensa_vectors.S:1685
I (113) esp_image: segment 3: paddr=0x00017f48 vaddr=0x40080400 size=0x080c8 ( 32968) load
I (136) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x11ccc ( 72908) map
0x400d0018: _flash_cache_start at ??:?
I (163) esp_image: segment 5: paddr=0x00031cec vaddr=0x400884c8 size=0x0066c ( 1644) load
0x400884c8: esp_rom_spiflash_program_page_internal at /home/t/esp/esp-idf/components/spi_flash/spi_flash_rom_patch.c:412
I (164) esp_image: segment 6: paddr=0x00032360 vaddr=0x400c0000 size=0x00000 ( 0) load
I (175) boot: Loaded app from partition at offset 0x10000
I (175) boot: Checking flash encryption...
I (180) flash_encrypt: flash encryption is enabled (3 plaintext flashes left)
I (188) boot: Disabling RNG early entropy source...
I (194) cpu_start: Pro cpu up.
I (197) cpu_start: Starting app cpu, entry point is 0x40080e4c
0x40080e4c: call_start_cpu1 at /home/t/esp/esp-idf/components/esp32/cpu_start.c:225
I (0) cpu_start: App cpu up.
I (208) heap_init: Initializing. RAM available for dynamic allocation:
I (215) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (221) heap_init: At 3FFB32C0 len 0002CD40 (179 KiB): DRAM
I (227) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (233) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (240) heap_init: At 40088B34 len 000174CC (93 KiB): IRAM
I (246) cpu_start: Pro cpu start user code
I (264) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (266) TAG: **** this is secret data ****
I (266) TAG: Flash Encryption is enabled!!!!
I (1266) TAG: Flash Encryption is enabled!!!!
I (2266) TAG: Flash Encryption is enabled!!!!
I (3266) TAG: Flash Encryption is enabled!!!!
I (4266) TAG: Flash Encryption is enabled!!!!
I (5266) TAG: Flash Encryption is enabled!!!!
I (6266) TAG: Flash Encryption is enabled!!!!
I (7266) TAG: Flash Encryption is enabled!!!!
I (8266) TAG: Flash Encryption is enabled!!!!
I (9266) TAG: Flash Encryption is enabled!!!!
動画 F
Arduino core for ESP32 環境ではどうする？等の実験と結果
ここまでは公式ドキュメントの記述を解釈しながら事前生成暗号化キーを使い ESP-IDF ベースで Flash Encryption の操作を行ってきました。より利用者の多い Arduino core for ESP32 環境での事情が気になります。現時点ではこの点に関する的確な情報が見当たらないため手元で調査と実験を行いました。
実験 1: Flash Encryption 有効状態でのバックアップ・レストアは可能？
前項までの確認の結果、現在手元には FLASH_CRYPT_CNT efuse の値が 0x01 の ESP32 ボードがある。ここにはアプリ「mySimpleApp」の本体のイメージをはじめ暗号化された一式が格納されている。
まず素朴に、この状態でフラッシュメモリ全領域のバックアップとレストアが可能であるか否かに関心を持った。 さっそく esptool を使い下記要領でバックアップとレストアを試したところ、Flash Encryption 不使用時と同様に問題なく処理できることを確認した。物理的な読み書きの際に間で細工をしたりはしないらしい。まずはひと安心。
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0 0x400000 flash4MB.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash 0 flash4MB.bin
実験 2: パーティションイメージを復号してみる
次に、esptool で読み出した所定の暗号化ずみパーティションを espsecure ユーティリティ の decrypt_flash_data コマンドで正しく復号可能であることを確認した。こういった整合性は一連の文脈の中で適切に保たれている。 以下は暗号化されたパーティションテーブルをホスト PC 上に読み出して復号する例。decrypt_flash_data コマンドにおいても --address 指定が必須であることに注意が必要。
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x8000 0xc00 partition_table_Encrypted.bin
espsecure.py decrypt_flash_data --keyfile ./mykey.bin --address 0x8000 -o partition_table_plain.bin partiiion_table_Encrypted.bin
なお、サイズ不定のブートローダーについては、プロジェクトのビルド時に build/bootloader/ 下に生成された暗号化前の bootloader.bin のファイルサイズ（ここでは 25,296 バイト）を指定して暗号化イメージを採取。上記と同じ要領で復号可能だった。
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x1000 25296 bootloader_Encrypted.bin
espsecure.py decrypt_flash_data --keyfile ./mykey.bin --address 0x1000 -o bootloader_plain.bin bootloader_Encrypted.bin
実験 3: 全パーティションのイメージを採取・復号・再暗号化して書き戻すと？
上のようにパーティションテーブルとブートローダのイメージの取得と復号の確認を終えたところで、他のパーティションイメージもすべて採取し、適宜復号と再暗号化を行った上で ESP32 へ書き戻してやれば普通にプログラムが動作するのではないかと考え実際に手を動かして試してみた。
まずパーティション定義を参照し各パーティションイメージを個別に採取する。
# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 1M,
前掲のように nvs は暗号化されておらず、読み出し不可の phy は中身がすべて 0xFF だった。後者はいずれにせよ mySimpleApp では使用していないためひとまずこのままにしておく。Type = app の factory パーティションについてのみ復号を行った。実行したコマンドを以下に控える。
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x9000 0x6000 nvs.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0xf000 0x1000 phy_init.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x10000 0x100000 factory_Encrypted.bin
espsecure.py decrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o factory_plain.bin factory_Encrypted.bin
次に、復号したブートローダ, パーティションテーブル, factory パーティションをあらためて暗号化する。
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x1000 -o bootloader_reEncrypted.bin bootloader_plain.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x8000 -o partition_table_reEncrypted.bin partition_table_plain.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o factory_reEncrypted.bin factory_plain.bin
準備を終えた一式を下記コマンドでフラッシュメモリへ書き戻した。
esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash \
0x1000 bootloader_reEncrypted.bin \
0x8000 partition_table_reEncrypted.bin \
0x9000 nvs.bin \
0xf000 phy_init.bin \
0x10000 factory_reEncrypted.bin
この結果、アプリケーション mySimpleApp は問題なく動作した。当初複雑に感じられた Flash Encryption は案外素直な構造らしい。
実験 4: Arduino core for ESP32 環境で開発したアプリ一式を移行してみる
ここまでの結果に続けて、ESP-IDF ではなく Arduino core for ESP32 環境でビルドしたアプリケーションイメージ一式について Flash Encryption 環境での取り回しを試みた。
実験用の題材として Arduino IDE 環境で直近に作成した Google Home に発話させるエージェントプログラムを使った。アプリ内で SPIFFS を利用していることも実験を行う上で何となく好都合。パーティションテーブルは以下の内容。
# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x5000, otadata, data, ota, 0xe000, 0x2000, app0, app, ota_0, 0x10000, 0x140000, app1, app, ota_1, 0x150000,0x140000, eeprom, data, 0x99, 0x290000,0x1000, spiffs, data, spiffs, 0x291000,0x16F000,
手元では同アプリを Flash Encryption を適用していない素の ESP32 ボードで運用中。
まず、この非 Flash Encryption なボード A をホスト PC へ接続し、フラッシュメモリからパーティションイメージ一式を採取する。
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x9000 0x5000 nvs.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0xe000 0x2000 otadata.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x10000 0x140000 app0.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x150000 0x140000 app1.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x290000 0x1000 eeprom.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x291000 0x16F000 spiffs.bin
esptool.py --port /dev/ttyUSB0 --baud 921600 read_flash 0x8000 0xC00 partition_table.bin
ブートローダはサイズ不定だが、Arduino core for ESP32 の場合、[arduino]/hardware/espressif/esp32/tools/sdk/bin/ ディレクトリ下に SPI モード + Flash Frequency 別に用意されているためこれを利用できる。
$ pwd /home/t/app/arduino-1.8.5/hardware/espressif/esp32/tools/sdk/bin $ ls -l 合計 128 -rw-rw-r-- 1 t t 15088 7月 30 21:42 bootloader_dio_40m.bin -rw-rw-r-- 1 t t 13696 7月 30 21:42 bootloader_dio_80m.bin -rw-rw-r-- 1 t t 13696 7月 30 21:42 bootloader_dout_40m.bin -rw-rw-r-- 1 t t 13696 7月 30 21:42 bootloader_dout_80m.bin -rw-rw-r-- 1 t t 15088 7月 30 21:42 bootloader_qio_40m.bin -rw-rw-r-- 1 t t 15072 7月 30 21:42 bootloader_qio_80m.bin -rw-rw-r-- 1 t t 15088 7月 30 21:42 bootloader_qout_40m.bin -rw-rw-r-- 1 t t 15072 7月 30 21:42 bootloader_qout_80m.bin
本アプリは "QIO" + "80MHz" の指定でビルドしているため「bootloader_qio_80m.bin」をコピーして使う。
暗号化の対象であるブートローダー, パーティションテーブル および app0, app1 パーティションのイメージを Flash Encryption 適用ずみの ESP32 ボード B のキーを使って暗号化する。
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x1000 -o bootloader_Encrypted.bin bootloader_qio_80m.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x8000 -o partition_table_Encrypted.bin partition_table.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x10000 -o app0_Encrypted.bin app0.bin
espsecure.py encrypt_flash_data --keyfile ./mykey.bin --address 0x150000 -o app1_Encrypted.bin app1.bin
ここで Flash Encryption 適用ずみの ESP32 ボード B をホスト PC につなぎ替えてから、以下の要領で各パーティションイメージを書き込む。
esptool.py --port /dev/ttyUSB0 --baud 921600 write_flash \
0x1000 bootloader_Encrypted.bin \
0x8000 partition_table_Encrypted.bin \
0x9000 nvs.bin \
0xe000 otadata.bin \
0x10000 app0_Encrypted.bin \
0x150000 app1_Encrypted.bin \
0x290000 eeprom.bin \
0x291000 spiffs.bin
以上の手順により、Arduino core for ESP32 環境でビルドを行い素の ESP32 ボード A 上で稼働中の当該アプリが、Flash Encryption 適用ずみのボード B 上で正常に動作した。
Flash Encryption を道具として普段使いするために
上の結果を受けて、Flash Encryption を道具として日常的に利用する上でのポイントを想定した。
- あらかじめ「初回の暗号化」を経て FLASH_CRYPT_CNT ＝ 0x01 状態となったボードを資材として用意しておく
- 普段は素のボートを使って Arduino IDE 環境なり ESP-IDF 環境なりで普通にプログラム開発を行う
- 自分の手を離れた場所にボードを設置する場合は上の要領で素のボードから Flash Encryption 有効化ずみボードへイメージを移行して利用する
ESP32 Board A ESP32 Board B +------------------+ copy & encrypt +------------------+ | Flash Encryption | partition images | Flash Encryption | | DISABLED | ===============> | ENABLED | +------------------+ +------------------+
理屈がわかってしまえば移行方法そのものは単純だが、手順が面倒なので適切に一括操作を行うために Python スクリプトを用意した。Linux, MacOSX, Windows の各環境に対応。なお、前項の実験ではブートローダのイメージを SDK ディレクトリからコピーして利用したが、ブートローダコードは固定長ではないもののサイズの上限は 0x7000 バイトであり、素のボードのフラッシュメモリオフセット 0x1000 から 0x7000 バイト分を読み出して処理したところ問題なく動作したためこの方法を採った。これなら元アプリの開発環境が何であるかにかかわらず対応できる。
- Esp32PlainImageToFlashEncBoard - github.com/mkttanabe
- Flash Encryption の無効なボード A のフラッシュメモリからブートローダイメージをホスト PC へ採取
- 同じくパーティションテーブルイメージを採取
- 上のパーティションテーブルの内容に基づき各パーティションイメージを採取
- 暗号化の必要なイメージを Flash Encryption の有効なボード B 用のキーで暗号化する
- イメージ一式をボード B のフラッシュメモリへ書き込む
以下の動画はこのスクリプトを使って前掲の「Google Home に発話させるエージェントプログラム」を稼働させている素のボード A のフラッシュメモリパーティションイメージ一式を暗号化有効なボード B へ移行した様子。
前半： 素のボード A のフラッシュメモリからの各パーティションイメージ採取と暗号化完了まで
後半： 上のイメージを Flash Encryption の有効なボード B に書き込んで当該アプリの稼働を確認
残っている疑問
今回、所定のボードで Flash Encryption を有効化するまでの過程ではドキュメントの内容どおりに ESP-IDF 環境で make menuconfig での暗号化オプション有効化を経て make && make flash を実行する手順を踏んだが、ボード側のお膳立てとしては FLASH_CRYPT_CNT efuse の値を 0x01 にするだけで事足りる可能性も想像される。
もし仮にそうであれば、素の状態のボードに対し事前生成暗号化キーを書き込んだ上で 前掲のように「espefuse.py --port [PORT] burn_efuse FLASH_CRYPT_CNT」コマンドを一度発行するだけで準備 OK かもしれない。手元ではまだ試せていないが関心はある。この件もおって確認したい。
以上、長いメモでした。いろいろ興味深い機構です。
(tanabe)
Google Home でローカルの MP3 ファイルをプレイリスト再生する方法
前回の記事では ほりひろ 様による esp8266-google-home-notifier ライブラリと ESP32 ボードを使って構成した Google Home 用キャストエージェントとその利用例を紹介しました。記事ではあわせて同ライブラリをプライベートにカスタマイズした内容として以下を挙げました。
- 元の google-home-notifier に存在する ip 関数を追加
- 元の google-home-notifier に存在する play 関数 （public）を追加
- play 関数による Google Home での MP3 データ再生終了を検知するためのコールバック機構を追加
今回はみっつめの話題について紹介します。
話のきっかけ
Google Home Mini で Spotify など試しているうちに、昔買った音楽 CD をこういう手軽さで聴くことができればと思うようになりました。そのためには楽曲データを MP3 形式等に変換して Google Play Music へアップロードすれば無料で実現できると随所で紹介されています。なかなか魅力的なサービスではありますが、その一方で Google 側の利用規約とのかねあいが気になりました。
手元では日常的に Google の多くの優れたサービスの便宜を享受しており、ひとりのユーザとして同社には敬意と信頼感を持っています。しかし、自分にすべての権利のあるデータであればともかく、自分には所有権しかない楽曲のデータを丸ごとこの規約のもとへ預けることには個人的にためらいがありました。そこで注目したのが google-home-notifier の MP3 データ再生機能です。
google-home-notifier には URL で指定された MP3 データを Google Home へキャストすることのできる play 関数が用意されています。そのため、LAN 上にローカル Web サーバをを立ててそこへ所定の MP3 データを配置し、そのアドレスをこの関数へ渡せば手元の環境からデータを持ち出すことなく Google Home で再生することが可能です。このやり方なら市販の楽曲に対する自分の権利の範囲を踏み越える心配はないでしょう。
ただ、play 関数は一件のデータをワンショットでキャストすることを前提とするもので複数データの連続再生には対応していません。そのため何曲かを順番に流すといったことはできないのが残念です。そこで、この部分に手を加え、所定のプレイリストを参照して複数の MP3 データの順次再生・シャッフル再生ができるようにしてみました。
まずその動作の様子を動画で紹介します。自宅では向かって左側の Raspberry Pi Zero W をローカル Web サーバとして運用しています。このデモでは soundorbis 様によるフリーのジングル曲を使用させて頂いています。
動画：1分15秒
ちなみにここでは以下の IFTTT アプレット （クリックで可読大表示） 経由でローカル Web サーバから再生リスト「demo.txt」（内容）を読み込んで処理を行っています。
トリガー
|
アクション
|
再生リストとその周辺の話題は末尾の「エージェントプログラム」の項に記述しています。
以下、実現に至るまでの経緯を控えます。
対応方法の調査
google-home-notifier の処理内容
まず google-home-notifier の処理を追うことから始めました。以下はそのまとめです。esp8266-google-home-notifier はオリジナルの google-home-notifier が堅実に移植されたライブラリであるためここでは後者をターゲットとしています。
初期設定
- 呼び出し側から ip() 関数により対象とする Google Home デバイスの IP アドレスと言語が指定されればそれを設定
- 呼び出し側から device() 関数により対象 Google Home デバイスのデバイス名と言語が指定されればそれを保持
主処理
- notify() 関数は渡されたテキストを所定の言語で TTS 処理した結果の MP3 ファイルの URL を対象 Google Home デバイスへキャストする
- ここでの音声合成には getSpeechUrl() 関数経由で 「Google 翻訳」の TTS 機能が利用される => GitHub: google-tts
- play() 関数は指定された MP3 ファイルの URL をを対象 Google Home デバイスへキャストする
- notify(), play() はいずれも呼び出された時点で対象 Google Home デバイスの IP アドレスが未設定状態であれば前出 device() 関数経由で保持しているデバイス名で mDNS 照会により対象 Google Home デバイスの IP アドレスを得る => GitHub: mdns
キャストの手順
- notify(), play() はキャスト処理を onDeviceUp() 関数へ投げる。この短い関数が内部で以下の Google Cast v2 処理を呼び出している
- キャスト対象デバイスの 8009 番ポートへ TLS 接続
- Cast v2 プロトコルにそって次のみっつの名前空間の仮想チャネルをコネクション上に作成
- urn:x-cast:com.google.cast.tp.connection - 接続管理用
- urn:x-cast:com.google.cast.tp.heartbeat - 接続維持用
- urn:x-cast:com.google.cast.receiver - デバイスのプレイヤー起動/ 終了/ 音量設定/ 状態確認等
- キャスト対象デバイス標準のプレイヤーである DefaultMediaReceiver （AppID "CC1AD845"） を launch() 、ここで仮想チャネル urn:x-cast:com.google.cast.media （コンテンツのロード/ 再生/ 停止/ 状態確認等） が作成される。このチャネル経由で対象 MP3 の URL を、バッファリング・自動再生指定つきで load() することにより Google Home デバイスでキャスト再生が実行される
- load() が終わったら各仮想チャネルを close してコネクションを切断
注目すべき点と考え方
ポイントは、上記「キャストの手順」の最後の「load() が終わったら各仮想チャネルを close してコネクションを切断」という部分にあります。該当箇所のソースコードを引用します。
- google-home-notifier.js （#L88-L96）
:
var onDeviceUp = function(host, url, callback) {
var client = new Client();
client.connect(host, function() {
client.launch(DefaultMediaReceiver, function(err, player) {
var media = {
contentId: url,
contentType: 'audio/MP3',
streamType: 'BUFFERED' // or LIVE
};
player.load(media, { autoplay: true }, function(err, status) {
client.close();
callback('Device notified');
});
:
このように、Google Home 側の DefaultMediaReceiver へ再生対象データの引き渡し（player.load()）を終えるとプログラムは直ちにデバイスとの接続を閉じそのまま終了しています。あとは Google Home まかせということになりますが、Google Home はデータ再生中に別のデータのキャストが指示されると現在の再生の終了を待つことなくあっさり新しいデータの再生を開始します。そのため、単に google-home-notifier を繰り返し実行しても、その都度データ再生が中断され別データの再生に移るだけで、プレイリスト再生のように「一件の再生が終了〜次のデータを再生」という動きにはなりません。
一方、手元で上記の player.load() 後も接続を維持した状態で観察したところ、Google Home 側でデータ再生が終了すると前掲の仮想チャネル「urn:x-cast:com.google.cast.media」経由でデバイス側からプログラムへ下記要領のメッセージが送出されることを確認しました。
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"IDLE","currentTime":0,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"currentItemId":1,"idleReason":"FINISHED"}],"requestId":0}
このように、接続を維持していればプログラムはデバイス側の再生終了の捕捉が可能であることがわかりました。
この件を含めここまでの一連の事情を踏まえると、google-home-notifier でデータの連続再生を実現するために必要な措置は大きく次のふたつであることがわかります。
なお、Google Cast の仕様にはデータの連続再生を行うためのネイティブの機構が存在するのではないかとも思うのですが、手元では今のところその方面の具体的な情報に行き着いておらず、いずれにせよここではあくまでも現行の google-home-notifier の機能を拡張することにしました。
実装まわりの話題
方針
実装にあたっては次の方針を基本としました。
処理のイメージ
左側のフローは手元での p8266-google-home-notifier とエージェントプログラムによる処理内容を要約したものです。右側はそこに調査から得られた情報を加味して MP3 データのリスト再生機能を追加したイメージで、ざっくり、赤文字の「キャスト処理」「再生監視タスク」の部分をライブラリ側の処理要素と想定しています。なお灰色のブロックは右フローとの共通部分です。 （クリックで可読大表示）
Google Home からのメッセージについて
上記右フローの「再生監視タスク」パート内の条件分岐部分でも触れていますが、データ再生の監視中には Google Home デバイスから仮想チャネル経由でさまざまなメッセージが送られてきます。手元での観察結果から、今回の実装では以下のメッセージを利用しています。
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"IDLE","currentTime":0,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"currentItemId":1,"idleReason":"FINISHED"}],"requestId":0}
{"type":"CLOSE"}
{"type":"PING"}
{"type":"PONG"}
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PAUSED","currentTime":1.880214,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":388729138}
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":15.665338,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":388729139}
なお「"requestId":0」のメッセージがデータの再生開始時点で一度発行されるため上記と混同しないよう注意
{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":1.384362,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}
ソースコード
カスタマイズした esp8266-google-home-notifier
オリジナルの esp8266-google-home-notifier ライブラリのコードへプライベートに手を加えています。変更箇所は「#ifdef TANABE」部分で、fork した GitHub リポジトリへ反映しています。変更内容はこの記事の冒頭、および前回の記事で触れたとおりです。
$ git clone -b private https://github.com/mkttanabe/esp8266-google-home-notifier.git
また、同リポジトリの examples/esp32/SimpleUsage/ 下に play 関数用のサンプルスケッチを加えました。どちらもオリジナルの SimpleUsage.ino のコピーを小さく書き替えたものです。
play 関数を再生終了通知用コールバック関数指定なしで呼び出すもの
play 関数を再生終了通知用コールバック関数指定つきで呼び出すもの
このふたつの追加サンプルを実行した様子の動画です。
エージェントプログラム
Arduino core for the ESP32 環境で作成したエージェントの Adruino スケッチです。前回分と互換性のある機能拡張版です。
- GoogleHomeNotifierESP32AgentEx - github.com/mkttanabe
GoogleHomeNotifierESP32Agent.ino の 以下の箇所を環境にあわせて書き替える
//------- ユーザ定義 ------------------
// Google Home デバイスの IP アドレス, デバイス名
// 有効にすれば指定 IP アドレスを直接使用
// 無効にすれば指定デバイス名で mDNS 照会
//#define USE_GH_IPADRESS
IPAddress myGoogleHomeIPAddress(192,168,0,110);
#define myGoogleHomeDeviceName "room02"
// WiFi アクセスポイント
#define ssid "ssid"
#define password "pass"
// Beebotte 情報
#define mqtt_host "mqtt.beebotte.com"
#define mqtt_port 8883
#define mqtt_topic "test01/msg"
#define mqtt_pass "token:" "token_************"
// MP3 データを配置する Web サーバ
#define dataServer "192.168.0.127"
#define dataServerPort 80
// MP3 データの URL
#define MP3DataFmt "http://" dataServer "/sound/%s.mp3"
// MP3 再生リストのパス
#define MP3ListFmt "/sound/list/%s.txt"
//-------------------------------------
上の記述の場合、自分の Beebotte アカウントの Channel "test01", Resource "msg" のメッセージの data キーの値に応じて以下が行われる- data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
- 例） {"data":"*こんにちは"} => 「こんにちは」と発話
- data 値の先頭文字がアスタリスクまたは "@" でなければ MP3 ファイル名とみなし所定の Web サーバの URL に編集して再生
- 例） {"data":"file01"} => "http://192.168.0.127/sound/file01.mp3" をキャスト
- data 値の先頭文字が "@" であれば MP3 データ再生リスト名とみなし所定の Web サーバの URL に編集して読み込み、記述されている各 MP3 データエントリを再生
- 例） {"data":"@demo"} => "http://192.168.0.127/sound/list/demo.txt" を再生リストとして読み込んで処理
- 下記の指定があればシャッフル再生を行う
{"data":"@demo,1"} , {"data":"@list01,ランダム"}
- 上記以外ならリスト上の記述順に再生
- 下記の指定があればシャッフル再生を行う
- 再生リストの記述例
demo.txt# 各行の '#' 以降はコメントとして扱われる
# 空行は無視、有効行先頭末尾のスペース・タブは除去される
# soundorbis 様によるフリー BGM 作品より
#
# 【フリーBGM】リコーダージングル【01〜05】
# https://www.youtube.com/watch?v=ztm1CSZEpY8
#
# 利用規約
# https://www.soundorbis.net/license
#
demo/[1]nc150689
demo/[2]nc150690
demo/[3]nc150691
demo/[4]nc150692
demo/[5]nc150693
- 例） {"data":"@demo"} => "http://192.168.0.127/sound/list/demo.txt" を再生リストとして読み込んで処理
なお、上の「ユーザ定義」箇所において「#define USE_GH_IPADRESS」が無効な場合は前回版と同様に mDNS 照会によりデバイス名から IP アドレスを取得するが、このやや時間のかかる照会のコストを軽減するために、今回の拡張版においては一旦取得した IP アドレスを ESP32 のフラッシュメモリ領域 （SPIFFS） へ記録し次回はまずそれを参照する処理を加えている。当該アドレスへアクセスできない場合や当該アドレスのデバイスを Google Home と識別できない場合はあらためて照会と記録を行う。詳細は DeviceAddress.cpp を参照のこと - data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
こういった経緯を経て形になったのが冒頭のデモ動画で稼働しているエージェントです。Raspberry Pi Zero W のローカル Web サーバとペアでとても快適に利用しています。
(tanabe)
Google Home を拠点間の双方向コミュニケーションに利用する
ESP32 版 google-home-notifier のこと
google-home-notifier の ESP8266 移植版「esp8266-google-home-notifier」の作者である ほりひろ 様が、今年（2018年）6月に ESP32 への対応を実施されました。node.js プログラムであるオリジナルの google-home-notifier を実行可能なもっとも小振りなプラットフォームはラズベリーパイですが、さらにコンパクトで消費電力の少ない ESP32 ボードで自由に Google Home へのキャストを実現できることには大きな魅力があります。自宅ではこの素晴らしいライブラリを使って MQTT メッセージをトリガーにキャスティングを行う内容のエージェントを構成し様々な要件で利用させて頂いています。
「声のアバター」によるやりとり？
そんな中で先日ふと、google-home-notifier の「Google Home で任意の音を出せる機能」と、Google Home 側の「音声で所定の処理を実行できる機能」の組み合わせを、離れた拠点間での定型的なコミュニケーションに利用できるのではないか？ と思い立ちました。図のようなイメージです。
双方のエージェントがそれぞれ MQTT ブローカー上の別のトピックを Subscribe しておき、必要に応じて相手のトピックへメッセージを Publish することで現地の Goole Home が所定のアナウンスを行います。その内容に対する所定のフレーズでの応答で相手へ向けての処理を発動する形にしておけば、いわば「声のアバター」を通じて両者間のやりとりが成立すると考えました。同じく音声による連絡方法であっても電話とは異なりこのやり方には直接的な拘束感やある種の重さがないため双方ともより手軽により淡々と利用できるでしょう。
試作のシナリオ
いろいろ使途がありそうですが、手元ではまず個人的に現在もっとも身近なテーマである「高齢者世帯の安否確認」を想定したシナリオを形にしてみました。以下の内容です。
A：見守り側
B：高齢者世帯側
- A => Google Home A：「ねえ Google、安否を確認」
- Google Home A => A：『はい、これから声をかけてみます』
- Google Home B => B：『身のまわりは大丈夫ですか？問題がない場合は "ねえ Google、順調です" と話しかけて下さい。もし何かご相談があれば、"ねえ Google、コールして" と話しかけて下さい』
- パターン 1： B => Google Home B：「ねえ Google、順調です」
- Google Home B => B：『それはよかったです。さっそく大丈夫と伝えておきますね』
- Google Home A => A：『先方から "元気です"と音声連絡がありました。メールを確認して下さい』
- A あてにメールが届く
- パターン 2： B => Google Home B：「ねえ Google、コールして」
- Google Home B => B：『はい、すぐに電話をするようにと伝えます』
- Google Home A => A：『先方から "電話してほしい"と音声連絡がありました。メールを確認して下さい』
- A あてにメールが届き携帯電話が数回コールされる
相手が高齢者でもあるため Google Home からのアナウンスにはとりわけ「聞き取りやすさ」が求められます。定型の文言なので毎回音声合成を行う必然性もなく、ここでは、google-home-notifier の notify 関数から呼び出される Google 翻訳 TTS を使うのではなく、複数のオンライン TTS サービスを試した中で個人的にもっとも自然に感じられた音声を収録した MP3 データを play 関数で再生することにしました。
動作の様子
後出のプログラムリソース一式を使って二組の「Google Home Mini + エージェント」間でやりとりを行った様子の動画です。
（パターン 1： 「安否を確認」 〜 「順調です」 1分17秒
（パターン 2： 「安否を確認」 〜 「コールして」） 1分16秒
リソース
esp8266-google-home-notifier のカスタマイズ
前述のように手元では作成したエージェントをさまざまな要件で利用しており、この間にオリジナルの esp8266-google-home-notifier ライブラリのコードへ何点かプライベートに手を加えています。変更箇所は「#ifdef TANABE」部分で、fork した GitHub リポジトリへ反映しています。
$ git clone -b private https://github.com/mkttanabe/esp8266-google-home-notifier.git
変更内容
エージェントプログラム
Arduino core for the ESP32 環境で作成したエージェントの Adruino スケッチです。MQTT ブローカーに Beebotte を使用しています。
- GoogleHomeNotifierESP32Agent - github.com/mkttanabe
GoogleHomeNotifierESP32Agent.ino の 以下の箇所を環境にあわせて書き替える
//------- ユーザ定義 ------------------
// Google Home デバイスの IP アドレス, デバイス名
// 有効にすれば指定 IP アドレスを直接使用
// 無効にすれば指定デバイス名で mDNS 照会
#define USE_GH_IPADRESS
IPAddress myGoogleHomeIPAddress(192,168,0,121);
#define myGoogleHomeDeviceName "room01"
// WiFi アクセスポイント
#define ssid "ssid"
#define password "pass"
// Beebotte 情報
#define mqtt_host "mqtt.beebotte.com"
#define mqtt_port 8883
#define mqtt_topic "test01/msg"
#define mqtt_pass "token:" "token_************"
// MP3 データを配置する Web サーバとデータパス
#define dataServer "192.168.0.126"
#define dataServerPort 80
#define MP3DataFmt "http://" dataServer "/sound/%s.mp3"
//-------------------------------------
上の記述の場合、自分の Beebotte アカウントの Channel "test01", Resource "msg" のメッセージの data キーの値に応じて以下が行われる.- data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
- 例） {"data":"*こんにちは"} => 「こんにちは」と発話
- data 値の先頭文字がアスタリスクでなければ MP3 ファイル名とみなし所定の Web サーバスペースの URL を編集して再生
- 例） {"data":"file01"} => "http://192.168.0.126/sound/file01.mp3" をキャスト
- data 値の先頭文字がアスタリスクであれば音声合成用のテキストとみなして google-home-notifier の TTS 処理にかける
用意した IFTTT アプレット
今回の試作では、トリガーに Google Assistant サービス、アクションに WebHooks サービスをアサインしたみっつの IFTTT アプレットを使っています。 ※ いずれもクリックで可読大表示
-
問い合わせフレーズ「安否を確認」対向のアプレット
アクションで Beebotte 上の相手側 "test02/msg" トピックへ "AnpiQuery.mp3" のキャスト再生を指示するメッセージを Publish
トリガー
アクション
-
応答フレーズ「順調です」および「コールして」に対向のアプレット
アクションで次項の Google Apps Script による Web アプリコードを所定のパラメータを添えて実行
トリガー
アクション
トリガー
アクション
Google Apps Script による Web アプリコード
上のふたつの応答用アプレットから呼び出している GAS コードです。
アプレットから渡される res パラメータの値は「safe」。
Beebotte 上の相手側 "test01/msg" トピックへ "AnpiSafe.mp3" のキャスト再生を指示するメッセージを Publish して「元気です」と Gmail を送信
アプレットから渡される res パラメータの値は「doCall」。まず Twillio 経由で相手の携帯電話を数回コールしてから Beebotte 上の相手側 "test01/msg" トピックへ "AnpiDoCall.mp3" のキャスト再生を指示するメッセージを Publish して「電話がほしい」と Gmail を送信
/*
AnpiResponse
2018-07
*/
var ADMIN = "***********@gmail.com";
function doGet(e) {
return ContentService.createTextOutput("??");
}
function doPost(e) {
return doIt(e);
}
function doIt(e) {
var msg, mp3Name;
var res = e.parameter.res;
var where = e.parameter.where;
if (res == "safe") {
msg = "元気です";
mp3Name = "AnpiSafe";
} else if (res == "doCall") {
msg = "電話がほしい";
mp3Name = "AnpiDoCall";
doPhoneCall(); // twilio
} else {
return ContentService.createTextOutput("res not found");
}
doPublish(mp3Name); // MQTT
// gmail
doSendMail(ADMIN, "Anpi", ADMIN, ADMIN,
"安否連絡 [" + res + "]",
curDate() + " " + curTime() + "\n" +
where + " より 「" + msg + "」と連絡がありました");
return ContentService.createTextOutput("OK");
}
function curDate() {
var d = new Date();
return d.getFullYear() + '-' +
('00' + (d.getMonth()+1)).slice(-2) + '-' + ('00' + d.getDate()).slice(-2);
}
function curTime() {
var d = new Date();
return ('00' + d.getHours()).slice(-2) + ':' +
('00' + d.getMinutes()).slice(-2) + ':' + ('00' + d.getSeconds()).slice(-2);
}
function doPhoneCall() {
var url = "https://api.twilio.com/2010-04-01/Accounts/****************/Calls";
var data = "To=%2B************&From=%2B***********0&Url=http://demo.twilio.com/docs/voice.xml&Timeout=10";
var options = {
method: "POST",
headers: {
"Authorization":"Basic QUMxZjdhYTIzZWM2YTdkNWM*************************",
"Content-Type":"application/x-www-form-urlencoded"
},
payload: data,
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch(url, options);
}
function doPublish(mp3Name) {
var url = "https://api.beebotte.com/v1/data/publish/test01/msg";
var data = '{"data":"' + mp3Name + '"}';
var options = {
method: "POST",
headers: {
"X-Auth-Token":"token_****************",
"Content-Type":"application/json"
},
payload: data,
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch(url, options);
}
function doSendMail(from, fromName, to, cc, subject, body) {
GmailApp.sendEmail(
to,
subject,
body,
{
from: from,
name: fromName,
cc: cc
}
);
}
現行の Google Home ではサポートされていない「能動的な発話」を擬似的に実現する google-home-notifier を利用しなければできないことであり、こういった使い方も同プログラムの実用的な応用例のひとつではないかと思います。さらに発展させることもできるでしょう。面白い時代になりました。
余談：「うるさいアラーム」機能を DIY した話
手元での google-home-notifier の利用例をもうひとつ紹介します。 Google Home のアラーム機能は手軽で何かと便利なので目覚まし用に使ったりしていました。ところがプリセットのアラーム音がいささか上品すぎるため手元では音量を最大にしても目覚めにつながらないケースが何度かありました。同じ経験をした方はおそらく少なくないのではないかと思います。
ちなみに、Google は 2018-02-01 のアップデートで Google アシスタントのアラーム音を変更可能としたようですが、この機能を利用できるのは現時点では言語設定が英語の場合のみで日本語環境では利用できません。
後日の対応に期待しつつ、前掲のエージェントを利用して耳障りでうるさいアラームを鳴らす機能を自作してみました。
まず、アラーム設定用・解除用の下のふたつの IFTTT アプレットを用意しました。所定のシートの A1 セルを使って音を鳴らす時刻の設定・解除を行う内容です。設定用のアプレットでは Google Assistant トリガーのオプション "Say a phrase with both a number and a text ingredient" での "a number" と "a text" を使って時・分のふたつの音声指示要素を受け入れています。
トリガー
|
アクション
|
トリガー
|
アクション
|
あわせて当該シートに以下の GAS コードを付与、スクリプト実行のトリガー「時間主導型」の「分タイマー」で「1分ごと」に doNotify() 関数の呼び出しを設定しました。シートに記録された時刻と現在の時刻が一致すると、Beebotte 上の "test01/msg" トピックへ "noise01.mp3" のキャスト再生を指示するメッセージが Publish されます。
// Beebotte へ MQTT メッセージを Publish
function doPublish(mp3Name) {
var url = "https://api.beebotte.com/v1/data/publish/test01/msg";
var data = '{"data": "' + mp3Name + '"}';
var options = {
method: "POST",
headers: {
"X-Auth-Token":"token_*************",
"Content-Type":"application/json"
},
payload: data,
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch(url, options);
}
function doNotify() {
// シートをチェック。A1 に時刻が設定されていれば騒音を鳴らす
var spreadSheet = SpreadsheetApp.getActiveSpreadsheet();
var sheet = spreadSheet.getSheets()[0];
var val = sheet.getRange("A1").getValue();
Logger.log(val);
if (val == 0) {
return;
}
var hm = val.split("_");
Logger.log("set => " + hm[0] + ":" + hm[1]);
if (hm[0] >= 24 || hm[1] >= 60){
//Logger.log("invalid");
return;
}
var dt = new Date();
var min = dt.getMinutes();
var h = dt.getHours();
if (String(h) == hm[0] && String(min) == hm[1]) {
sheet.getRange("A1").setValue("0");
doPublish("noise01");
}
}
動作の様子： 動画 32秒
このように単機能でごくシンプルなものですが、手元では結構役に立っています。
(tanabe)
SwitchBot を ESP32 で遠隔操作してみた
SwitchBot と公開 API
物理的なスイッチやボタンを人に代わって操作してくれる BLE デバイス SwitchBot （by Wonderlabs,Inc.）が人気です。有線/無線通信や赤外線等によるコントロールに対応していない機器をいわば強引に IoT 方面へ引き込もうという発想が面白いですね。
|
技適マークと番号はパッケージに印刷されている |
これは同じくクラウドファンディングを経て 2016年に商品化された MicroBot Push （by Naran Inc.： 工事設計認証番号 R208-160099） の後追い製品ではありますが、手元にある両者を比べてみると SwitchBot には後発であることのアドバンテージが随所に活かされているように見受けられます。とりわけ嬉しいのは本体のアームを制御するための API が公開されていることです。
Open API
APIs will be released to let DIYers integrate Switch Bot to your own home automation system. Swich Bot and Link are friendly to Ardunio, Raspberry Pi and OpenWRT.
この公約のとおり Wonderlabs,Inc. は Apache License 2.0 のもとに次のリソースを公開しています。
SwitchBot のアーム操作に必要な手順が次のシンプルな内容であることがわかります。
以下は以前紹介した手順で採取した GATT 管理下の UUID の一覧です。
onServicesDiscovered: serviceList.size=4 onServicesDiscovered: svc uuid=00001800-0000-1000-8000-00805f9b34fb // Generic Access onServicesDiscovered: chrlist.size=3 onServicesDiscovered: chr uuid=00002a00-0000-1000-8000-00805f9b34fb // Device Name onServicesDiscovered: desclist.size=0 onServicesDiscovered: chr uuid=00002a01-0000-1000-8000-00805f9b34fb // Appearance onServicesDiscovered: desclist.size=0 onServicesDiscovered: chr uuid=00002a04-0000-1000-8000-00805f9b34fb // Peripheral Preferred Connection Parameters onServicesDiscovered: desclist.size=0 onServicesDiscovered: svc uuid=00001801-0000-1000-8000-00805f9b34fb // Generic Attribute onServicesDiscovered: chrlist.size=0 onServicesDiscovered: svc uuid=0000fee7-0000-1000-8000-00805f9b34fb // Custom UUID of Tencent Holdings Limited onServicesDiscovered: chrlist.size=3 onServicesDiscovered: chr uuid=0000fec8-0000-1000-8000-00805f9b34fb // Custom UUID of Apple, Inc. onServicesDiscovered: desclist.size=1 onServicesDiscovered: desc uuid=00002902-0000-1000-8000-00805f9b34fb // Client Characteristic Configuration Descriptor onServicesDiscovered: chr uuid=0000fec7-0000-1000-8000-00805f9b34fb // Custom UUID of Apple, Inc. onServicesDiscovered: desclist.size=0 onServicesDiscovered: chr uuid=0000fec9-0000-1000-8000-00805f9b34fb // Custom UUID of Apple, Inc. onServicesDiscovered: desclist.size=0 onServicesDiscovered: svc uuid=cba20d00-224d-11e6-9fb8-0002a5d5c51b // User defined service onServicesDiscovered: chrlist.size=2 onServicesDiscovered: chr uuid=cba20003-224d-11e6-9fb8-0002a5d5c51b // User defined characteristic onServicesDiscovered: desclist.size=1 onServicesDiscovered: desc uuid=00002902-0000-1000-8000-00805f9b34fb // // Client Characteristic Configuration Descriptor onServicesDiscovered: chr uuid=cba20002-224d-11e6-9fb8-0002a5d5c51b // User defined characteristic onServicesDiscovered: desclist.size=0
ちなみに、手元の SwithiBot 個体の MAC アドレスは「C0:65:9A:7D:61:E1」でした。
自作の Android アプリで操作してみる
上記の手順にそってまず Android アプリをざっくり書いてみました。以下は動作の様子を収めた動画とソースコードです。
動画：40秒 音量注意
SwitchBot01 - MainActivity.java
/**
*
* SwitchBot01
*
* SwitchBot を操作する
*
* メーカーが公式に公開しているプログラムをベースに作成
*
* https://github.com/OpenWonderLabs/python-host/
*
*/
package jp.klab.SwitchBot01;
import android.Manifest;
import android.app.Activity;
import android.app.AlertDialog;
import android.app.ProgressDialog;
import android.bluetooth.BluetoothAdapter;
import android.bluetooth.BluetoothDevice;
import android.bluetooth.BluetoothGatt;
import android.bluetooth.BluetoothGattCallback;
import android.bluetooth.BluetoothGattCharacteristic;
import android.bluetooth.BluetoothGattDescriptor;
import android.bluetooth.BluetoothGattService;
import android.bluetooth.BluetoothManager;
import android.bluetooth.BluetoothProfile;
import android.bluetooth.le.BluetoothLeScanner;
import android.bluetooth.le.ScanCallback;
import android.bluetooth.le.ScanRecord;
import android.bluetooth.le.ScanResult;
import android.bluetooth.le.ScanSettings;
import android.content.Context;
import android.content.DialogInterface;
import android.content.Intent;
import android.content.pm.PackageManager;
import android.graphics.Color;
import android.net.Uri;
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v4.app.ActivityCompat;
import android.support.v4.content.ContextCompat;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.Toolbar;
import android.util.Log;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
import com.google.android.gms.appindexing.Action;
import java.util.List;
import java.util.UUID;
public class MainActivity extends AppCompatActivity
implements Runnable, View.OnClickListener, Handler.Callback {
private static final String TAG = "SB01";
private static final String TARGET_ADDR = "C0:65:9A:7D:61:E1"; // 手元の SwitchBot
private static final int SCAN_MODE = ScanSettings.SCAN_MODE_LOW_LATENCY;
private static final int MSG_DOSCAN = 100;
private static final int MSG_FOUNDDEVICE = 110;
private static final int MSG_STOPSCAN = 120;
private static final int MSG_GATTCONNECT = 200;
private static final int MSG_GATTCONNECTED = 210;
private static final int MSG_GATTDISCONNECT = 300;
private static final int MSG_GATTDISCONNECTED = 310;
private static final int MSG_GATTGOTSERVICE = 400;
private static final int MSG_SW_ON = 500;
private static final int MSG_SW_OFF = 510;
private static final int MSG_SW_PRESS = 520;
private static final int MSG_ERROR = 10;
private static final int REQ_ENABLE_BT = 0;
private BluetoothAdapter mBtAdapter = null;
private BluetoothLeScanner mBtScanner = null;
private BluetoothGatt mBtGatt = null;
private BluetoothDevice mBtDevice;
private Handler mHandler;
private Context mCtx;
private ProgressDialog mProgressDlg = null;
private TextView mTvAddr;
private TextView mTvRssi;
private Button mButtonDisconn;
private Button mButtonConn;
private Button mButtonTurnOn;
private Button mButtonTurnOff;
private Button mButtonPress;
private BluetoothGattCharacteristic mChUser2 = null;
private BluetoothGattDescriptor mDescUser1 = null;
// SwitchBot の提供するサービス・キャラクタリスティック群の UUID より
private UUID mUuidSvcUser1 = UUID.fromString("cba20d00-224d-11e6-9fb8-0002a5d5c51b");
private UUID mUuidChUser2 = UUID.fromString("cba20002-224d-11e6-9fb8-0002a5d5c51b");
// SwitchBot の 3 コマンド
private byte[] mCmdSwPress = new byte[] {(byte)0x57, (byte)0x01, (byte)0x00};
private byte[] mCmdSwOn = new byte[] {(byte)0x57, (byte)0x01, (byte)0x01};
private byte[] mCmdSwOff = new byte[] {(byte)0x57, (byte)0x01, (byte)0x02};
private ScanCallback mScanCallback = new bleScanCallback();
private BluetoothGattCallback mGattCallback = new bleGattCallback();
// GATT イベントコールバック
private class bleGattCallback extends BluetoothGattCallback {
@Override
public void onDescriptorWrite(BluetoothGatt gatt,
BluetoothGattDescriptor desc,
int status) { // writeDescriptor() 結果
super.onDescriptorWrite(gatt, desc, status);
}
@Override
public void onCharacteristicRead(BluetoothGatt gatt,
BluetoothGattCharacteristic ch,
int status) { // readCharacteristic() 結果
super.onCharacteristicRead(gatt, ch, status);
Log.d(TAG, "onCharacteristicRead: sts=" + status);
}
@Override
public void onCharacteristicWrite(BluetoothGatt gatt,
BluetoothGattCharacteristic ch,
int status) { // writeCharacteristic 結果
super.onCharacteristicWrite(gatt, ch, status);
Log.d(TAG, "onCharacteristicWrite: sts=" + status);
}
@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status,
int newState) {
super.onConnectionStateChange(gatt, status, newState);
if (newState == BluetoothProfile.STATE_CONNECTED) { // 接続完了
mHandler.sendEmptyMessage(MSG_GATTCONNECTED);
} else if (newState == BluetoothProfile.STATE_DISCONNECTED) { // 切断完了
mHandler.sendEmptyMessage(MSG_GATTDISCONNECTED);
}
}
@Override
public void onCharacteristicChanged (BluetoothGatt gatt,
BluetoothGattCharacteristic ch) {
Log.d(TAG, "onCharacteristicChanged");
}
@Override
public void onServicesDiscovered(BluetoothGatt gatt, int status) { // GATT サービス一覧取得完了
super.onServicesDiscovered(gatt, status);
// SwitchBot のユーザ定義サービス のユーザ定義キャラクタリスティック 2 のオブジェクトを取得
BluetoothGattService svc = gatt.getService(mUuidSvcUser1);
mChUser2 = svc.getCharacteristic(mUuidChUser2);
/** すべての Services - Characteristics - Descriptors をログへ**
List<BluetoothGattService> serviceList = gatt.getServices();
Log.d(TAG, "onServicesDiscovered: serviceList.size=" + serviceList.size());
for (BluetoothGattService s : serviceList) {
Log.d(TAG, "onServicesDiscovered: svc uuid=" + s.getUuid().toString());
List<BluetoothGattCharacteristic> chlist = s.getCharacteristics();
Log.d(TAG, "onServicesDiscovered: chrlist.size=" + chlist.size());
for (BluetoothGattCharacteristic c : chlist) {
UUID uuid = c.getUuid();
Log.d(TAG, "onServicesDiscovered: chr uuid=" + uuid.toString());
List<BluetoothGattDescriptor> dlist = c.getDescriptors();
Log.d(TAG, "onServicesDiscovered: desclist.size=" + dlist.size());
for (BluetoothGattDescriptor d : dlist) {
Log.d(TAG, "onServicesDiscovered: desc uuid=" + d.getUuid());
}
}
}
**/
mHandler.sendEmptyMessage(MSG_GATTGOTSERVICE);
}
};
// SCAN イベントコールバック
private class bleScanCallback extends ScanCallback {
@Override
public void onBatchScanResults(List<ScanResult> results) {
super.onBatchScanResults(results);
Log.d(TAG, "onBatchScanResults");
}
@Override
public void onScanResult(int callbackType, ScanResult result) {
super.onScanResult(callbackType, result);
int rssi = result.getRssi();
mBtDevice = result.getDevice();
ScanRecord rec = result.getScanRecord();
String addr = mBtDevice.getAddress();
if (!addr.equals(TARGET_ADDR)) {
return;
}
mTvAddr.setText("ADDRESS\n" + TARGET_ADDR);
mTvRssi.setText("RSSI\n" + rssi);
mHandler.sendEmptyMessage(MSG_FOUNDDEVICE);
}
@Override
public void onScanFailed(int errorCode) {
super.onScanFailed(errorCode);
Log.e(TAG, "onScanFailed: err=" + errorCode);
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.d(TAG, "onCreate");
mCtx = this;
setContentView(R.layout.activity_main);
Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);
mTvAddr = (TextView) findViewById(R.id.tvAddr);
mTvRssi = (TextView) findViewById(R.id.tvRssi);
mButtonDisconn = (Button)findViewById(R.id.buttonDisconn);
mButtonConn = (Button)findViewById(R.id.buttonConn);
mButtonTurnOn = (Button)findViewById(R.id.buttonTurnOn);
mButtonTurnOff = (Button)findViewById(R.id.buttonTurnOff);
mButtonPress = (Button)findViewById(R.id.buttonPress);
mButtonDisconn.setOnClickListener(this);
mButtonConn.setOnClickListener(this);
mButtonTurnOn.setOnClickListener(this);
mButtonTurnOff.setOnClickListener(this);
mButtonPress.setOnClickListener(this);
setButtonsVisibility(false);
setButtonsEnabled(false);
setTvColor(Color.LTGRAY);
mHandler = new Handler(this);
/***** add for Android 6.0 or later ****/
// https://developer.android.com/training/permissions/requesting.html
// https://developer.android.com/topic/libraries/support-library/index.html#backward
if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_COARSE_LOCATION) !=
PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(this,
new String[]{Manifest.permission.ACCESS_COARSE_LOCATION}, 1);
}
// 端末の Bluetooth アダプタへの参照を取得
mBtAdapter = ((BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE)).getAdapter();
if (mBtAdapter == null) {
// Bluetooth サポートなし
showDialogMessage(this, "Device does not support Bluetooth.", true); // finish
} else if (!mBtAdapter.isEnabled()) {
// Bluetooth 無効状態
Log.d(TAG, "Bluetooth is not enabled.");
// 有効化する
Intent it = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(it, REQ_ENABLE_BT);
} else {
mBtScanner = mBtAdapter.getBluetoothLeScanner();
if (!mBtAdapter.isMultipleAdvertisementSupported()) {
showDialogMessage(this, "isMultipleAdvertisementSupported NG.", true); // finish
} else {
// スキャン開始
mHandler.sendEmptyMessage(MSG_DOSCAN);
}
}
}
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
super.onActivityResult(requestCode, resultCode, data);
Log.d(TAG, "onActivityResult");
switch (requestCode) {
case REQ_ENABLE_BT:
// Bluetooth 有効化 OK
if (resultCode == Activity.RESULT_OK) {
Log.d(TAG, "REQ_ENABLE_BT OK");
// スキャン開始
mHandler.sendEmptyMessage(MSG_DOSCAN);
} else {
Log.d(TAG, "REQ_ENABLE_BT Failed");
mHandler.sendEmptyMessage(MSG_ERROR); // finish
}
break;
}
}
@Override
public void onStart() {
super.onStart();
Log.d(TAG, "onStart");
Action viewAction = Action.newAction(
Action.TYPE_VIEW, // TODO: choose an action type.
"Main Page", // TODO: Define a title for the content shown.
// TODO: If you have web page content that matches this app activity's content,
// make sure this auto-generated web page URL is correct.
// Otherwise, set the URL to null.
Uri.parse("http://host/path"),
// TODO: Make sure this auto-generated app deep link URI is correct.
Uri.parse("android-app://jp.klab.SwitchBot01/http/host/path")
);
}
@Override
public void onStop() {
super.onStop();
Log.d(TAG, "onStop");
}
@Override
public void onDestroy() {
super.onDestroy();
Log.d(TAG, "onDestroy");
// GATT 接続終了
if (mBtGatt != null) {
mBtGatt.disconnect();
mBtGatt.close();
mBtGatt = null;
}
// スキャン停止
if (mBtScanner != null) {
mBtScanner.stopScan(mScanCallback);
mBtScanner = null;
}
}
@Override
public void onClick(View v) {
if (v == (View)mButtonConn) {
mHandler.sendEmptyMessage(MSG_GATTCONNECT);
} else if (v == (View)mButtonTurnOn) {
mHandler.sendEmptyMessage(MSG_SW_ON);
} else if (v == (View)mButtonTurnOff) {
mHandler.sendEmptyMessage(MSG_SW_OFF);
} else if (v == (View)mButtonPress) {
mHandler.sendEmptyMessage(MSG_SW_PRESS);
} else if (v == (View)mButtonDisconn) {
mHandler.sendEmptyMessage(MSG_GATTDISCONNECT);
}
return;
}
@Override
public boolean handleMessage(Message msg) {
switch (msg.what) {
case MSG_DOSCAN: // スキャン開始
Log.d(TAG, "msg: MSG_DOSCAN");
ScanSettings scanSettings = new ScanSettings.Builder().
setScanMode(SCAN_MODE).build();
mBtScanner.startScan(null, scanSettings, mScanCallback);
break;
case MSG_STOPSCAN: // スキャン停止
Log.d(TAG, "msg: MSG_STOPSCAN");
mBtScanner.stopScan(mScanCallback);
break;
case MSG_FOUNDDEVICE: // ペリフェラルのアドバタイズパケットを検出
Log.d(TAG, "msg: MSG_FOUNDDEVICE");
mHandler.sendEmptyMessage(MSG_STOPSCAN);
setTvColor(Color.BLACK);
setButtonsVisibility(true);
break;
case MSG_GATTCONNECT: // デバイスへの接続を開始
Log.d(TAG, "msg: MSG_GATTCONNECT");
showProgressMessage(getString(R.string.app_name), "デバイスへ接続中・・・");
mBtGatt = mBtDevice.connectGatt(mCtx, false, mGattCallback);
mBtGatt.connect();
break;
case MSG_GATTCONNECTED: // デバイスへの接続が完了
Log.d(TAG, "msg: MSG_GATTCONNECTED");
setTvColor(Color.LTGRAY);
// デバイスの GATT サービス一覧の取得へ
mBtGatt.discoverServices();
break;
case MSG_GATTGOTSERVICE: // デバイスの GATT サービス一覧取得完了
Log.d(TAG, "msg: MSG_GATTGOTSERVICE");
if (mProgressDlg != null) {
mProgressDlg.cancel();
mProgressDlg = null;
}
setButtonsEnabled(true);
break;
case MSG_GATTDISCONNECT: // デバイスとの切断
Log.d(TAG, "msg: MSG_GATTDISCONNECT");
mBtGatt.disconnect();
break;
case MSG_GATTDISCONNECTED: // デバイスとの切断完了
Log.d(TAG, "msg: MSG_GATTDISCONNECTED");
setButtonsEnabled(false);
if (mBtGatt != null) {
mBtGatt.close();
mBtGatt = null;
}
showDialogMessage(mCtx, "デバイスとの接続が切断されました", false);
mHandler.sendEmptyMessage(MSG_DOSCAN);
break;
case MSG_SW_ON: // Turn On
Log.d(TAG, "msg: MSG_SW_ON");
mChUser2.setValue(mCmdSwOn);
mBtGatt.writeCharacteristic(mChUser2);
break;
case MSG_SW_OFF: // Turn Off
Log.d(TAG, "msg: MSG_SW_OFF");
mChUser2.setValue(mCmdSwOff);
mBtGatt.writeCharacteristic(mChUser2);
break;
case MSG_SW_PRESS: // PRESS
Log.d(TAG, "msg: MSG_SW_PRESS");
mChUser2.setValue(mCmdSwPress);
mBtGatt.writeCharacteristic(mChUser2);
break;
case MSG_ERROR:
showDialogMessage(this, "処理を継続できないため終了します", true);
break;
}
return true;
}
@Override
public void run() {
}
// ダイアログメッセージ
private void showDialogMessage(Context ctx, String msg, final boolean bFinish) {
new AlertDialog.Builder(ctx).setTitle(R.string.app_name)
.setMessage(msg)
.setPositiveButton("OK", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int whichButton) {
if (bFinish) {
finish();
}
}
}).show();
}
// プログレスメッセージ
private void showProgressMessage(String title, String msg) {
if (mProgressDlg != null) {
return;
}
mProgressDlg = new ProgressDialog(this);
mProgressDlg.setTitle(title);
mProgressDlg.setMessage(msg);
mProgressDlg.setProgressStyle(ProgressDialog.STYLE_SPINNER);
mProgressDlg.show();
}
private void setButtonsEnabled(boolean isConnected) {
mButtonConn.setEnabled(!isConnected);
mButtonTurnOn.setEnabled(isConnected);
mButtonTurnOff.setEnabled(isConnected);
mButtonPress.setEnabled(isConnected);
mButtonDisconn.setEnabled(isConnected);
}
private void setButtonsVisibility(boolean visible) {
int v = (visible)? View.VISIBLE : View.INVISIBLE;
mButtonConn.setVisibility(v);
mButtonTurnOn.setVisibility(v);
mButtonTurnOff.setVisibility(v);
mButtonPress.setVisibility(v);
mButtonDisconn.setVisibility(v);
}
private void setTvColor(int color) {
mTvRssi.setTextColor(color);
mTvAddr.setTextColor(color);
}
}
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="jp.klab.SwitchBot01">
<uses-permission android:name="android.permission.BLUETOOTH"></uses-permission>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"></uses-permission>
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"></uses-permission>
<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity
android:name=".MainActivity"
android:label="@string/app_name"
android:configChanges="orientation|screenSize"
android:screenOrientation="portrait"
android:theme="@style/AppTheme.NoActionBar">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<!-- ATTENTION: This was auto-generated to add Google Play services to your project for
App Indexing. See https://g.co/AppIndexing/AndroidStudio for more information. -->
<meta-data
android:name="com.google.android.gms.version"
android:value="@integer/google_play_services_version" />
</application>
</manifest>
ESP32 ボードで操作してみる
Android アプリからの操作を確認したところで、次にマイコン方面からのコントロールを試すことにしました。 手元にある BLE モジュールの中で BLE セントラル機能に対応しているのは ESP32 ボードの ESP32-DevKitC だけなので選択の余地なくこれを使います。
ESP32 用の BLE セントラルコードは以前 ESP-IDF ベースで何度か作成したことがありますが、生産性は Arduino IDE + Arduino core for the ESP32 環境のほうが高いためできれば後者を利用したいと考えました。
幸い、ESP 界隈で著名な Neil Kolban さんが ESP32 Adruino core 用の高機能な BLE ライブラリ「ESP32 BLE for Arduino」を 2017年9月より公開していることを知り、さっそく examples ディレクトリ下の BLE_client.ino のコードを下敷きにプログラムを実装してみました。
プログラム起動時に BLE ペリフェラルからのアドバタイズパケットをスキャンし、自分の SwitchBot を見つけたら接続を確立して「Press」コマンドを一度発行する簡潔な内容としました。
動作の様子とソースコードです。動画ではボード上のリセットボタンを三度押下しています。
動画：22秒 音量注意
BLE_SwitchBot01_BLE.ino
/**
*
* BLE_SwitchBot01_BLE.ino (for ESP32)
*
* BLE セントラル. SwitchBot からのアドバタイジングを検出したら
* 一度だけ同 GATT サーバへ接続〜所定のキャラクタリスティックへ
* Press コマンドを書き込んでアームを動かす.
*
* Arduino core for ESP32 向けの Neil Kolban 氏による
* 下記 BLE ライブラリを使用
* https://github.com/nkolban/ESP32_BLE_Arduino
*
*/
#include "BLEDevice.h"
#include <HardwareSerial.h>
// 手元の SwitchBot のアドレス
static String addrSwitchBot = "c0:65:9a:7d:61:e1";
// SwitchBot のユーザ定義サービス
static BLEUUID serviceUUID("cba20d00-224d-11e6-9fb8-0002a5d5c51b");
// 上記サービス内の対象キャラクタリスティック
static BLEUUID charUUID("cba20002-224d-11e6-9fb8-0002a5d5c51b");
// SwitchBot の Press コマンド
static uint8_t cmdPress[3] = {0x57, 0x01, 0x00};
static BLEAddress *pGattServerAddress;
static BLERemoteCharacteristic* pRemoteCharacteristic;
static BLEClient* pClient = NULL;
static boolean doSendCommand = false;
// BLEDevice::init() でのシリアルポート混乱対策
static HardwareSerial hs2(2);
void dbg(const char *format, ...) {
char b[512];
va_list va;
va_start(va, format);
vsnprintf(b, sizeof(b), format, va);
va_end(va);
hs2.print(b);
}
// アドバタイズ検出時のコールバック
class advdCallback: public BLEAdvertisedDeviceCallbacks {
void onResult(BLEAdvertisedDevice advertisedDevice) {
dbg("BLE device found: ");
String addr = advertisedDevice.getAddress().toString().c_str();
dbg("addr=[%s]\r\n", addr.c_str());
// SwitchBot を発見
if (addr.equalsIgnoreCase(addrSwitchBot)) {
dbg("found SwitchBot\r\n");
advertisedDevice.getScan()->stop();
pGattServerAddress = new BLEAddress(advertisedDevice.getAddress());
doSendCommand = true;
}
}
};
void setup() {
hs2.begin(115200, SERIAL_8N1, 16, 17);
Serial.begin(115200);
dbg("start");
// BLE 初期化
BLEDevice::init("");
// デバイスからのアドバタイズをスキャン
BLEScan* pBLEScan = BLEDevice::getScan();
pBLEScan->setAdvertisedDeviceCallbacks(new advdCallback());
pBLEScan->setActiveScan(true);
pBLEScan->start(30);
}
void loop() {
if (doSendCommand == true) {
if (connectAndSendCommand(*pGattServerAddress)) {
} else {
dbg("connectAndSendCommand failed");
}
doSendCommand = false;
dbg("done");
}
delay(1000);
}
// SwitchBot の GATT サーバへ接続 〜 Press コマンド送信
static bool connectAndSendCommand(BLEAddress pAddress) {
dbg("start connectAndSendCommand");
pClient = BLEDevice::createClient();
pClient->connect(pAddress);
dbg("connected\r\n");
// 対象サービスを得る
BLERemoteService* pRemoteService = pClient->getService(serviceUUID);
if (pRemoteService == nullptr) {
dbg("target service not found\r\n");
return false;
}
dbg("found target service\r\n");
// 対象キャラクタリスティックを得る
pRemoteCharacteristic = pRemoteService->getCharacteristic(charUUID);
if (pRemoteCharacteristic == nullptr) {
dbg("target characteristic not found");
return false;
}
dbg("found target characteristic\r\n");
// キャラクタリスティックに Press コマンドを書き込む
pRemoteCharacteristic->writeValue(cmdPress, sizeof(cmdPress), false);
delay(3000);
if (pClient) {
pClient->disconnect();
pClient = NULL;
}
return true;
}
SwitchBot をインターネットごしに操作する
ESP32 といえば・・
上記のように ESP32 ボードで適切に SwitchBot を操作可能であることが確認できました。そこでふと、ここにインターネットアクセスの要素を絡めることを思いつきました。 ESP32 が備えている BLE 機能と WiFi 機能をパラレルに利用できることは以前の試みを通じて確認ずみです。そのため「インターネットごしに所定のメッセージを受信したら SwitchBot を作動させる」ことができるのではないかと考えました。もちろん SwitchBot 公式のインターネットハブ製品である「SwitchBot Hub」のように高機能なものには到底及ばないにしても、ESP32 ボードを使えば最低限の遠隔操作は実現できそうです。
道具立て
インターネット経由での ESP32 へのメッセージングには MQTT を利用することにしました。
CloudMQTT
MQTT ブローカーは最近 Beebotte が流行っているようですが、いくつかのサービスを試し今回はもっとも手に馴染んだ「CloudMQTT」を選びました。無料枠も手元の要件には十分です。
- CloudMQTT - A globally distributed MQTT broker - www.cloudmqtt.com
- 5 users/acl rules/connections
- 10 Kbit/s
設定
|
Web コンソール
|
Pricing
FREE |
HTTP to MQTT bridge
ノーマルな HTTP リクエストの体裁でメッセージを Publish できれば何かと便利です。Beebotte とは違い現時点で CloudMQTT に用意されている REST API は管理用のもののみですが、petkov さんによる「HTTP to MQTT bridge」の存在とこれを Heroku から利用できることを知りました。ちなみに、Heroku には CloudMQTT 用のアドオンも用意されていますが、ざっと説明を読んだところでは単に CloudMQTT 上のインスタンスを呼び出す内容のようで HTTP to MQTT bridge の利用と比べ際立ったメリットが見えないことと、また、Heroku でアドオンを利用するにはクレジットカード登録が必要である点が若干微妙でもあり今回は利用を見合わせました。
- HTTP to MQTT bridge - www.home-assistant.io
- http_to_mqtt - github.com/petkov
- Deploy your own HTTP to MQTT bridge - heroku.com
設定
|
価格体系
|
"認証済みアカウントで 1 月あたり 1,000 時間分の無料 dyno 時間を使えます。未認証アカウントの場合は 550 時間分です。無料の dyno がアクティブになるとプールから dyno が取り出され、dyno 時間がプールに残っている限り、無料でアプリケーションを実行できます。" 「Dyno」を徹底的に理解する CodeZine |
IFTTT
HTTP クライアントから ESP32 へメッセージを送る分には以上の準備で事足ります。一方、SwitchBot のメインのキーワードである「スマートホーム」にはこのところ「スマートスピーカー」がぴたりと寄り添っている感がありますね。なので、お約束どおり（？）手元の Google Home Mini 用に IFTTT アプレットを用意しました。トリガーには Google Assistant サービスを、アクションには Webhooks サービス（旧 Maker チャネル）を割り当て、後者へ上のブリッジへのリクエストを設定します。
- IFTTT helps your apps and devices work together - ifttt.com
トリガー
|
アクション
|
コードサイズの超過と対処
引き続き Nick O'Leary さんによる Arduino Client for MQTT ライブラリを利用して CloudMQTT に対向しメッセージの Publish / Subscribe を行うシンプルなスケッチを作成、ESP32 上で問題なく動作することを確認しました。 これと前掲の BLE セントラルプログラムのふたつを軸として結合し細かい処理を書き加えれば完成でしょう。
まずはラフに結合してみました。すると、コンパイルは通ったものの ESP-WROOM-32 のフラッシュメモリへの書き込みでエラーが発生しました。コードサイズの超過です。
最大1310720バイトのフラッシュメモリのうち、スケッチが1568826バイト（119%）を使っています。
最大294912バイトのRAMのうち、グローバル変数が70452バイト（23%）を使っていて、ローカル変数で224460バイト使うことができます。
スケッチが大きすぎます。http://www.arduino.cc/en/Guide/Troubleshooting#size には、小さくするコツが書いてあります。
ボードESP32 Dev Moduleに対するコンパイル時にエラーが発生しました。
あらためて元のふたつのスケッチのコードサイズを確認してみると、内容的にはシンプルな BLE プログラム側が単体で書き込み可能容量の 94%にも及んでいました。ESP32 BLE for Arduino ライブラリのボリュームの大きさが窺えます。
最大1310720バイトのフラッシュメモリのうち、スケッチが1237529バイト（94%）を使っています。
以下を試しました。
現時点では他にこれといった対策も見当たらず Arduino IDE 環境での開発はここで一旦断念しました。
ESP-IDF 環境への移行 〜 完成
こういった経緯を経てネイティブの ESP-IDF 環境へ移行しプログラムを書き直しました。 Espressif はコアライブラリを頻繁に更新しており API の後方互換性が必ずしも維持されないケースのあることが気がかりではありますが、その点は現在もなお活火山状態にある ESP32 向けの開発の宿命と割り切るべきでしょう。
準備
まず ESP-IDF をこの時点での最新版へアップデートしました。
~/esp/esp-idf$ git describe
v3.0-dev-2561-g358c822
MQTT ライブラリは Tuan さんによる「ESP32 MQTT Library」を使用することに。README の記述にそって <ESPIDF>/components/espmqtt へ Git サブモジュールとして一式を追加しました。
- ESP32 MQTT Library - github.com/tuanpmt
処理の流れ
プログラムは以下の内容としました。
動作の様子
動画：34秒 音量注意 （※ ウェイクワード「ねえ, グーグル」の発声もあります）
ソースコード
- SwitchBotMqtt01 - github.com/mkttanabe
(tanabe)
電波法適合の NFC モジュールで安価な NFC タグを利用する
はじめに
当ブログの記事「NFC タグで秘密情報を安全に携行する試み」では MIFARE Ultralight 準拠の NXP 製「NTAG21x」シリーズに目を向けました。そこでは市場で現在主流のこの NFC タグ製品の機能面での奥の深さを Android デバイスを使って試してみましたが、値段も安くすっかり気に入った NTAG21x を自作の装置でも利用したいと考えました。携帯端末の可搬性、据え置き型装置の拡張性、どちらも日常生活での NFC の実用性を支えている土台的な要素ですね。
NFC リーダ/ライタモジュール製品を探す
そんなわけでまずは電子工作向きの NFC リーダ/ライタモジュールを探すことから始めました。ネットを見渡してみると様々なものが出回っており、以下の製品などが目にとまりました。いずれもなかなか良さそうです。
国外のメーカーによるこれらのモジュールは個人でも簡単に購入することができます。一方、国内メーカーの製品情報を探したところでは、いくつもの企業が NFC リーダ/ライタモジュールの製造・販売を行ってはいるもののそのほとんどが法人向けの組み込み用であることを知りました。
その中で、私自身が今回調べた範囲では、2018年3月時点で個人が一般のディストリビュータから入手可能な国内製品はソニー株式会社様による「RC-S620/S」のみでした。もし他にも入手しやすい国内製品があればぜひご教示下さい。
さて、ここで気になるのがこれらの製品と電波法との関係です。
電波法と NFC モジュールとの関係について
ご承知のように、日本国内で「技適マーク」のない無線機を使用すると電波法違反となる可能性があり、外国製の機器を使いたい場合などにはこのことが最初に確認すべきポイントとなります。では、やはり電磁波を発生させる NFC リーダ/ライタは電波法においてどのように扱われているのでしょう。技適証明が必要なのか、それとも周囲への影響が微弱であるため特に規定されていないのか。この点について調べてみました。
まとめ
結論として、電波法には NFC リーダ/ライタに関する明確な規定があり、それに適合しない製品の日本国内での使用は NG であることを知りました。要点を整理してみます。
- いわゆる技適証明は特定無線設備を対象とするものだが、NFC リーダ/ライタは電波法において特定無線設備にはあたらず「高周波利用設備」に該当し、そこに含まれる「誘導式読み書き通信設備」に分類される
- つまり NFC リーダ/ライタは技適マークとは関係がない
- 誘導式読み書き通信設備は、その電界強度が所定の条件を満たしている場合、または、総務大臣による型式指定を受けている場合には個別の許可なしに設置することができる
- 型式指定の申請者は日本人または日本国内の法人でありかつ製造業者または輸入業者でなければならない
- 電界強度条件との整合性の確認にも型式指定を受けるにも適正な方法での性能試験が必須
詳細
型式指定表示の実例
手元にあるふたつの製品での型式指定表示と公式サイトからの引用を示します。前掲の RC-S620/S にもしっかり印刷されています。
※クリックで大きく表示
RC-S620/S について
貴重な選択肢として
今回手元で調べた範囲では、日本の電波法に準じた型式指定表示のある国外メーカーの NFC モジュールは見当たりませんでした、また、「３mの距離において電界強度が500μV/m」などという性能情報を目にすることもありません。 そのため、いまの時点で手近な実験や電子工作を適法に行うためには入手が容易で電波法適合の RC-S620/S は貴重な選択肢ということになります。
個人的には、電波法の必然性と重要性を十分に理解・納得しながらも、一方で、とりわけ IoT 方面での国外メーカーによる国際的にメジャーな製品を公然と試すことのできないケースが発生することをもどかしく思うこともあります。手近な実験や試作のためにわざわざ電波暗室を借りたり渡航したりするわけにもいきませんしね。。 （^^；さっそくスイッチサイエンス様のサイトから RC-S620/S を購入しました。 本来組み込み用途のこのモジュールの入出力端子は FFC コネクタで一般的な電子工作では何かと取り回しにくいのですが、同社オリジナルのブレークアウト基板と専用ケーブルのセットがあわせて販売されているためとても助かります。
- FeliCa リーダー・ライター RC-S620S ￥3,600 （2018年3月時点の販売価格）
- FeliCa RC-S620S/RC-S730 ピッチ変換基板のセット(フラットケーブル付き) ￥540 （2018年3月時点の販売価格）
（商品ページの図を加工したものです）
※「FFCを差し込むときは黒い部分を引き出してください。黒い部分を戻すことで固定できます」という説明に注意。手元では当初これを見落としていたためしばらく悩みました ><
- FeliCa RC-S620S/RC-S730 ピッチ変換基板のセット(フラットケーブル付き) ￥540 （2018年3月時点の販売価格）
利用者向けの公式リソース
利用者向けに以下のリソースが公式サイトで公開されています。各ダウンロードページに記載された規約・使用許諾契約の内容を十分に確認した上でこれらを利用します。
規約
:
第3条（使用権）
1. ソニーは、利用者に対して、利用者が対象文書を使用目的のために本ウェブサイトから複製することができる非独占的な権利を無償にて利用者に許諾します。
2. 利用者は、対象文書の全部または一部を、さらに複製したり、これに対する修正、追加等の改変をすることはできません。また、対象文書およびその複製物を、第三者に頒布したり、ウェブサイトにアップロードするなどして第三者が取得可能な状態にしないものとします。
:
RC-S620/S制御ライブラリ 使用許諾契約
:
第1条（総則）
1.ソニーは、本規約に定める各条項に従い、本ソフトウェアおよび関連資料に関する非独占的かつ譲渡不能な次の権利（但し特許権は除く。以下「使用権」とします）を、お客様に許諾します。
(1)お客様が、ソフトウェア使用者をして、本ソフトウェアおよび関連資料の全部もしくは一部を使用、複製、複写または改変してアプリケーションソフトウェアを開発する権利。 なお、本規約において、ソフトウェア使用者およびアプリケーションソフトウェアとは、それぞれ、次の意味を有します。
�．愁侫肇ΕД∋藩兌圈�本ソフトウェアを入手頂いたお客様1名の方。
�▲▲廛螢院璽轡腑鵐愁侫肇ΕД◆Д愁法疾夙鸚椰�ICカードリーダ／ライター製品「RC-S620/S」を制御するためのソフトウェアプログラム。
(2)お客様が、本項第1号に基づき開発されたアプリケーションソフトウェアを複製したうえ、ソースコード形式またはバイナリ形式にて、第三者に頒布する権利。
2.お客様は、前項で定める場合を除き、本ソフトウェアおよび関連資料の全部もしくは一部を使用、複製、複写または改変してはならないものとします。
:
公式リソースのカバーする範囲
このようにドキュメントに加えサンプルコードが公式に提供されていることは利用者にとってとても嬉しい配慮ですが、これらの参照・使用に際しては以下の事情をあらかじめ理解しておく必要があるでしょう。
思いがけない援軍の存在
さて、冒頭で触れたように手元で実現したいのは MIFARE Ultralight NTAG21x へのアクセスです。RC-S620/S が ISO/IEC 14443 Type A（MIFARE）に対応していることは上記の通り仕様書に明記されているものの、公式のリソースではそのための具体的な方法や手順がわかりません。
まずそもそも MIFARE の近接を検知するにはどうすればいいのか。「Arduino向けRC-S620/S制御ライブラリ」の polling() 関数は FeliCa を検知するために「コマンドリファレンスマニュアル＜簡易版＞」に記載されている「InListPassiveTarget」というコマンドを呼び出しています。
ためしに「InListPassiveTarget ISO/IEC 14443 Type A」のキーワードで情報を検索したところ次の興味深い資料が目にとまりました。
「PN532」は NXP による NFC モジュールです。この資料の中の InListPassiveTarget の記述箇所を探すと Page 115 （上図）にそのものずばりのコマンド説明がありました。
クリックで可読大表示
「RC-S620/Sコマンドリファレンスマニュアル＜簡易版＞ Version 2.11」 Page 80 の InListPassiveTarget の説明と読み合わせてみると、ターゲットが FeliCa の場合のパラメータ説明は一致しており、さらに「簡易版」には記載されていない ISO/IEC 14443 Type A, B への対応方法を含め 7 ページに渡り詳しい説明が掲載されています。その他のコマンドについても同様で、CommunicateThruEx など RC-S620/S 側のみに存在するいくつかのコマンドはあるものの、全体としてはいわばスーパーセットのマニュアルのように見受けられました。実際にこのマニュアルに添って「Arduino向けRC-S620/S制御ライブラリ」の polling() 関数を以下の要領で書き換えてみると ISO/IEC 14443 Type A の近接を検知することができました。
FeliCa 対応のオリジナルコード
/* InListPassiveTarget */ memcpy(buf, "\xd4\x4a\x01\x01\x00\xff\xff\x00\x00", 9); buf[5] = (uint8_t)((systemCode >> 8) & 0xff); buf[6] = (uint8_t)((systemCode >> 0) & 0xff); ret = rwCommand(buf, 9, response, &responseLen);
ISO/IEC 14443 Type A 用
ret = rwCommand((const uint8_t *)"\xd4\x4a\x01\x00", 4,
response, &responseLen);
このように、メーカーの異なる RC-S620/S と PN532 との間にコマンドレベルでの共通性がある理由は NFC フォーラム仕様のどこかにあるのかも知れませんが手元では今のところ該当する情報の特定に至っていません。 あるいは、両社がともに「デバイスやサービス間の新機能と互換性を実現するための規格策定」をミッションのひとつとする NFC フォーラムのコアメンバーであることに関係があるのかも知れません。いずれにせよ PN532 のマニュアルのおかげで先が見えてきました。
NTAG21x ネイティブコマンドの発行について
先般の記事では、NTAG21x のメモリアクセスに必要な次のよっつのネイティブコマンドを挙げました。
NTAG 製品のバージョン,ストレージサイズ等を得る
所定のページアドレスから始まる 4 ページ分（16 バイト）のデータを得る
所定のページアドレスへ 1 ページ分（4 バイト）のデータを書き込む
パスワードで保護された領域へのアクセス要求に先行してパスワード認証を要求する
これらを RC-S620/S 経由でターゲットへ送出してやれば NTAG21x のメモリを自由に操作できるはずです。
RC-S620/S にはこのようにターゲットとする PICC 固有のコマンドを発行するための CommunicateThruEX コマンドが用意されています。ただし、「コマンドリファレンスマニュアル＜簡易版＞ Version 2.11」 Page 71 の「本コマンドは 212/424 kbps の RF パケットの送受信を行います」の記述のとおりこのコマンドは FeliCa 専用で、通信速度 106 kbps の ISO/IEC 14443 向けには使えません。
一方、「PN532 User Manual Rev.02」にはそれと同様の機能で汎用性のある InDataExchange, InCommunicateThru のふたつのコマンドの情報が掲載されています。同マニュアルの InListPassiveTarget コマンドのページには MaxTg フィールドについて「The PN532 is capable of handling 2 targets maximum at once, so this field should not exceed 0x02.」と記述されており、InDataExchange においては target （Tg） を明示的に指定するのに対し、InCommunicateThruでは「it is assumed that a target has been first activated.」という違いがあります。
ふたたび RC-S620/S 側に目を向けると、「コマンドリファレンスマニュアル＜簡易版＞ Version 2.11」 Page 50 の InListPassiveTarget コマンド説明で MaxTg フィールドについては「Target ID を取得する Target の最大数. 01h を指定してください」と記述されています。つまりこの部分の仕様は PN532 と異なる様子であり、この要素の影響を受ける InDataExchange, InCommunicateThru の挙動は、両コマンドの存在有無の確認を含め RC-S620/S 上で実際に試してみる必要がありそうです。
前掲のよっつの NTAG21x ネイティブコマンドの発行を RC-S620/S 経由で試みたところ、InListPassiveTarget によるターゲットの捕捉後に以下の組み合わせが有効であることを手元で確認しました。また、この結果から RC-S620/S においても InDataExchange, InCommunicateThru の両コマンドを利用可能であることが明らかになりました。
ライブラリへの加筆とテストプログラムの作成
ここまでの経緯でおおむね材料が揃ったところで、「Arduino向けRC-S620/S制御ライブラリ」へ自分のほしかった機能を追加し、あわせて動作確認用にテストプログラムの作成を行います。
想定した内容
以下の内容を想定しました。NDEF メッセージの解釈や ISO/IEC 14443 Type B の ID 取得など若干の要素を追加しています。さしあたり手元で用途のなかった NTAG21x ネイティブの WRITE, PWD_AUTH コマンドは今回は利用していません。今後必要になったときに実装を追加しようと思います。
機器の接続
手元ではこれまで Arduino IDE を利用する機会はありましたが Arduino 実機を扱うのは今回が初めてでした。
RC-S620/S と Arduino UNO をシリアル接続して制御を行い、上記のように処理状況を UNO から USB 経由で PC 上のシリアルターミナルへ随時出力することを想定していたのですが、UNO のハードウェアシリアルが一系統のみであることを知り、別立ての USB シリアル変換モジュール（FT231X）と Arduino 標準の SoftwareSerial ライブラリを併用することにしました。
同じ理由で、Arduino IDE から UNO 本体の USB シリアル経由でプログラムを書き込む際には [RC-S620/S 側 TXD] <--> [RX ピン] の結線を外して排他する必要があります。このあたりの事情は Arduino ユーザには当然のことなのでしょうがビギナーにはちょっと新鮮でした。
ソースコード
- mkttanabe/NFC/RCS620S/Arduino - GitHub
動作の様子
動画：3分19秒
(tanabe)
micro:bit と ESP32 でインターネットボタンを作る
http://www.bbc.com/ |
http://www.kitronik.co.uk/
|
私が micro:bit に関心を持ったのは最近扱っていた話題にちょうどぴったりのデバイスだったことがきっかけでした。今回はその内容と手元での試作を順をおって紹介します。
BLE ボタンデバイスをインターネットボタンとして使うこと
Amazon Dash Button の成功がひとつの契機にもなり この数年の間にインターネットボタンの利用と普及が進みました。手軽さといえば何かとスマホが引き合いに出されることの多い状況あってより単純な操作でより簡単に所定の処理を呼び出せることが専用の機器であることの最大の強みでしょう。
ただその一方で、機器の性質上ボタンデバイスの多くが電池駆動式であることが今後の用途・要件の拡大に伴いより悩ましい要素となる可能性も考えられます。限られた貴重な電力を使って自力でインターネット上の所定のサービスを叩きに行くのは必ずしも効率の良いやり方でありませんから、この点への対処が今後の課題となるかもしれません。
初代の Amazon Dash Button に高容量ではあるものの傍目にもコストバランスの危なげな米エナジャイザー社製の高価なリチウム一次電池が内蔵されていたことは象徴的です
一案として、省電性に優れた BLE ボタンデバイスと仲介役のエージェントデバイスを組み合わせてインターネットボタンを構成する形を想定しました。図にしてみます。
このように考え方はとてもシンプルです。ボタンデバイスは電池駆動、据え置きのエージェントデバイスは AC 電源からの給電を想定しています。 ボタン側は BLE 通信で必要最小限の通知をエージェントへ送り、エージェント側はそれをトリガーに所定のインターネットサービスを呼び出します。インターネットボタンは通常屋内空間での利用が前提ですから、BLE と WiFi の通信距離の違いに留意して機器の設置・運用を行えばこの構成には相応の合理性があります。また、小さなボタンデバイスひとつに複雑な処理を入れ込むことに比べ、機器の組み合わせによって必要な機能を実現するやり方には柔軟性が見込まれるでしょう。
通知の方法と道具立て
通知方法について
通常、BLE ペリフェラルからセントラルへの通知はデバイス間の接続確立後に所定の手続きによりセットアップを行うことで実施可能となります。この設定は両者の接続が維持されている間のみ有効です。
もちろんそれは BLE の仕様上のまっとうな規約なのですが、前掲の案への適用にはあまり気が進まずにいました。理由は以下の三点です。
代わりに デバイスからのアドバタイジングパケットを合図として利用することを考えました。この方法ならよりコストが低くデバイス間の接続に拘束されることもありません。また、アドバタイズの内容は文字通りオープンなので一般的なツールで普通に読めるという間口の広さも利点です。
注意の必要な点としては、連続して発生するアドバタイジングパケットにエージェント側が過剰に反応しないようにすることと、当該デバイスを本件専用として扱うべきであることが挙げられるでしょう。
エージェントについて
前掲の案のポイントは BLE 通信とインターネット通信の両方をカバーするエージェントを用意する点にあります。BLE つきの遊んでいるスマホを利用する手もありますが、「据え置き」「常時稼働」を前提とする IoT 装置として利用するにはいささかオーバースペックの感があり、また、視点は異なるもののスマホ系とボタンの連携に関しては「Flic」や「Pochiru」のような先例もあるためもうひとつ食指が動きません。
そこで ESP32 モジュールを使うことにしました。ESP-WROOM-32 は今回の要件を単体ですべて満たしているためまさに適役で価格面での魅力もあります。
ボタンについて
過去にこのブログでピックアップしたもの以外にも手元には複数の BLE ボタンデバイスがあります。それぞれに個性があり並べて使ってみるとなかなか面白いのですが、上述のようにアドバタイジングパケットを利用することを想定すると次のような機能・機構がほしいと考えました。
（「ひとつのデバイスでひとつの処理」ではちょっと寂しい。アドバタイズを合図とする以上、ボタンデバイスが本来の通知機能においてダブルプッシュや長押しといったボタンアクションの区別に対応していてもそれを利用することができないという事情もある）
残念ながらこれらの要件を満たすものは手元にありませんでしたが、プロトタイピングであれこれ試したところではどのボタンもそれなりに使えるのでまあこれはこれで・・とも思っていました。そこでたまたま目にしたのが micro:bit 国内販売のニュースです。
それまでこの製品のことは名前しか知らずにいました。あらためて写真をみてふたつのタクトスイッチが目にとまり、さらに記事中の「技適」の文字が気になって情報を調べたところ実は上のみっつの要件をすべて満たしていることがわかったため迷わずこれを利用することにしました。
ちなみにスイッチサイエンスさんが去年 12月にリリースした chibi:bit のこともこの時に知りました。ショップにはよくお世話になっているのですが、一見あまり関係のなさそうなところにしっかり良いものがあったりするものですね。
micro:bit 用に追加購入したパーツ
micro:bit ボードをボタンデバイスとして扱うために欠かせないふたつのパーツを調達しました。 いずれも英 Kitronik 社の製品で、ボタン電池から給電するためのオプションボード「MI:power」（直販価格 £4.16）と、同ボードを装着した状態の全体をすっぽり覆うことのできる「MI:pro Protective Case」（直販価格 £4.10）です。写真はケースに収めた状態の外観です。
前面 |
背面
|
余談ながら Kitronik 社は直販を行ってはいるものの日本への送料が最安でも £30.95 と高いため、送料の安いショップを探して英国内の Pimoroni にたどり着き、そこで「MI:power」と「Edge Connector Breakout Board」を購入しました。送料は £5.50。8月7日に発注し 1週間で到着しました。なお、このふたつの製品はスイッチサイエンスさんのサイトにも掲載されており 8月21日に同社から「ご注文いただけるようになりました」メールが届きました。
どうしても欲しかった「MI:pro Protective Case」は Pimoroni にも見当たらず、しつこい検索を経て結局その時点で送料を含め最も安く販売していた ebay 出品企業から買いました。それでも総額が日本国内での micro:bit 本体価格よりも高額ではありましたが、ちょうど 2週間後の 8月25日に届き嬉々として使っています。
スイッチサイエンスさん、ぜひこの「MI:pro Protective Case」も扱って下さい！Pimoroni さんも今のところ扱っていないようですが、もし入荷されたら少なくとも私は確実に買います！（^^;
（追記）2017年10月11日にスイッチサイエンスさんサイトでの販売が開始されました。
MI:電源ボード用 MI:proケース - コード番号 KITRONIK-5611
- MI:pro Protective Case for the MI:power board - www.kitronik.co.uk
実装
micro:bit 側
micro:bit 側のプログラムは Microsoft MakeCode で手早く作成しました。以下の内容としています。
アドバタイズに Eddystone-URL パケットを使用しているのは MakeCode 上の「Bluetooth」の項に他の選択肢が見当たらなかったためです。これと言って弊害も想定されず、また、どのような形式であれデータの内容で A, B ボタンを区別できれば事足りるのでこれはこれでよしとしました。図はエディタ画面のスクリーンショットです。すでにこういう時代なのですね。 （クリックで可読大表示）
ESP-WROOM-32 側
ESP32 モジュール側のプログラムは ESP-IDF 環境で作成しました。
処理の概要
〜 下記 3. での要求発生時にリクエスト送出とレスポンス受信を行い終われば再び待機状態へ
〜 対象とする MAC アドレスのデバイスからの対象とする符丁を含む Eddystone-URL パケットを検知すると上記 2. のタスクへ所定の URL へのリクエストを要求
ソースコード
※ この試作ではサーバ証明書の検証を行っていません
※ 次の公式のサンプルコードを下敷きにして記述しています
※ ESP-IDF 環境のセットアップ手順やプログラムのビルド方法については当ブログの次の記事に詳しい説明があります
ここでは一台の micro:bit のみを対象としていますが、ソースコード中の Entries テーブルへ適宜エントリを追加することで複数の micro:bit を対象とすることが可能です。
A, B ボタンの押下に呼応するアクションのサンプルとして Gmail 発信, 携帯電話のコールのふたつの処理を紐付けています。これらはいずれも Microsoft Flow 上に作成したフローの URL への GET 要求によって実現しています。ふたつのフローのスクリーンショットを以下に示します。 （クリックで可読大表示）
|
|
動作の様子
動画：1分18秒 （途中で電話着信音が鳴ります。音量に注意して下さい）
(tanabe)
音を利用する 5 〜mbed マイコンでの応用：実装編〜 （終）
- 音を利用する 1
- 音を利用する 2 〜Android デバイスでの音波通信：準備編〜
- 音を利用する 3 〜Android デバイスでの音波通信：実装編〜
- 音を利用する 4 〜mbed マイコンでの応用：準備編〜
この記事の内容
前回の記事では mbed LPC1768 を使って音声信号の入出力と分析を試みました。今回はその内容をもとに実用性の見込めるものを作ってみます。
1. 音をトリガーに通知を行うしくみを作る
まず、所定の音を鳴らすとそれに反応して所定の連絡先へ通知を行うしくみを想定しました。装置が屋内で常時集音と分析を行い、所定の周波数の連続性のある音声信号を検知するとインターネット経由で所定の対象へ通知を送るイメージです。次のように考えました。
- 音は電磁波に比べより小さなエネルギーで発生させることができるため何らかの処理を指示するためのトリガーとしての有用性が見込まれる
- 音は人間の官能に直結しており扱いが比較的容易であるため他の選択肢が閉ざされた状況において意思を伝えるための最後の手段となり得る
- マイコンは常時稼働を前提とする情報処理装置の構成要素として好適でありこうした使い方は「IoT」そのものでもある
使途はいろいろ考えられそうですが、たとえば日常的に危険の潜在する高齢者世帯や独居世帯において非常時に SOS を発信するための用心棒としても有用でしょう。
どのような音を使うか
通知のトリガーとする音には所定の周波数と振幅の維持が求められます。もっとも簡単にそのような音を出せる身近な道具として「笛」に目を向け 5 種類の製品を試してみました。それぞれに特長がありこれらの笛製品の音をすべてトリガーとして利用したいと考えました。
A&F 社製 サイレントホイッスル 犬笛
-
A&F エイアンドエフ サイレントホイッスル - www.aandfstore.com
人に聞こえる可聴領域の低音と犬にしか聞こえない超音波領域(16000〜22000Hz以上)の 高音を出すことができる軽量なアルミ合金から削り出して作った、たった7gの犬笛です
- A&F エイアンドエフ サイレント ホイッスル - www.yodobashi.com
- 長所
- 日常的な環境音とはほとんど競合しない高周波の音を簡単に出力できる
- 振幅の大きな音を「静か」に鳴らすことが可能
- 少ない息で大きく長く音を出せる
- 今回の中ではもっとも遠くまで音が伝わる
- 備考
- 価格が高め（実売￥2,000前後）
- 犬笛は音が人間に聞こえにくい性質上一般的な防災・避難用途には適さない ※この製品自体は可聴音域へ切り替えが可能
- 長所
|
|
|
|
コクヨ社製 防災用救助笛
-
防災用救助笛ツインウェーブ - 救助・避難用品 - www.kokuyo-st.co.jp
ツインウェーブは人の耳に最も良く聞こえる約3000Hz〜5000Hzの周波数の中で、2種類の波長を出すため、より広範囲な人への注意喚起が可能となります。 小さな息でも大きな音を出すことができます。
- コクヨ 防災用救助笛 防災の達人 ツインウェーブ オレンジ DRK-WS1YR - www.amazon.co.jp
-
特別対談 山村武彦氏×鈴木松美氏（提供：コクヨ Ｓ＆Ｔ 株式会社） - www.webside.jp
山村氏 この「ツインウェーブ」ですが、一見、笛とはわかりませんね。・・・
いつでも、どこでも、誰でもが持ち歩けるというのは、非常に大きなポイントだと思います。・・・
鈴木氏 ひとつの音だけではなく、２種類、３種類の音が出せれば、より助けを求めやすいのではないかと思います。 ツインウェーブは、3200ヘルツと4800ヘルツの音を同時に出します。・・・
鈴木氏 ツインウェーブは、通常で700〜800メートル先までは音が届きますから、エレベータで閉じ込められた場合なども有効です。 さらに、軽い息で大きな音を鳴らせるので、お年寄りにも最適です。力がなくても同じ周波数が出せるように、ずいぶん苦労しました。息のエネルギーをほとんど音に変換して、非常に効率がいいんです。 山村氏 この笛の効果は、これからの防災対策に欠かせないように思います。高齢者でも、 寝たきりの人でも、笛さえ吹ければ自らの居場所を知らせることができます。- 長所
- 少ない息でより大きな音を出せる
- プラスティック製かつ蓋つきで小さく携帯性に優れる
- コストパフォーマンスが高い（実売￥400前後）
- 備考
- 手元での確認では製品名の由来でもある「2種類の波長」はあまりはっきりと観察できなかった。吹き方の影響？
- 長所
|
|
|
|
モルテン社製 電子ホイッスル
-
電子ホイッスル RA0010-Y | molten モルテンスポーツ事業本部 - www.molten.co.jp
：
乾電池単3形2本使用（別売）
電池寿命：約16ヶ月（1回2秒、1日20回使用時）
：
- molten モルテン RA0010Y 電子ホイッスル 黄 - www.yodobashi.com
- 長所
- 電気製品につき体力を消耗せずスイッチ押下で厚みのある大きな音（「10cm 120dB」）を出せる
- 電池の持ちが良い
- 目立つ外観であり要所への常置に適する
- 備考
- 電池が消耗すれば使えない
- 価格が高め（実売￥2,700前後）
- 長所
|
|
|
|
レモン社製 緊急用呼子笛
- 緊急用呼子笛 - lemon.gr.jp
-
緊急用 呼子笛 885800 - www.amazon.co.jp
携帯に便利なペンダントタイプの緊急用呼子笛です。 身元確認のためのIDカードが付いています。
- 長所
- 少ない息で大きく長く音を出せる
- スリムで軽く携帯しやすい
- コストパフォーマンスがきわめて高い（実売￥100〜200程度）
- 備考
- 「アルミ製」だが剛性に若干の不安あり
- 長所
|
|
|
|
一般的なホイッスル（メーカー不明）
- 長所
- 百均店で買えるなど入手性がよく紛失してもダメージが少ない
- スタンダードであるため一見して笛と認識でき誰でも簡単に扱える
- 備考
- 音量の確保と持続に多くの息が必要
|
|
|
|
どのように通知を行うか
緊急連絡用途を想定すると通知は複数の方法を併用することが好ましいと考えました。今回は以下のみっつの方法を想定しサービスの選定を行いました。
電話機への通知
電話はもっとも手早い通知手段でしょう。電話連絡を手近に扱えるサービスとして米国発の「Twilio」を知りこれを利用することにしました。所定の相手に対し所定の音声メッセージを流すことも簡単に実現できますが、ここでは電話機をコールするだけで受け手は何ごとかの発生を察知できるためコストのかかる音声通話機能を利用する必要はないかもしれません。
Twilio
- Twilio - APIs for Text Messaging, VoIP & Voice in the Cloud - www.twilio.com
- Twilio for KDDI Web Communications | クラウド電話API - twilio.kddi-web.com
Twilio は開発者向けのプラットフォームサービス、たった数行のコードを書くだけでネットと電話・SMS をつなぎます。ネット上の仕組みを電話から操作したり、ネット上の情報を電話や SMS に通知することができるようになります。
- API リファレンス - 全Twilio APIおよびSDKの詳細リファレンス - jp.twilio.com
Twilio の REST API を使って、ユーザー アカウント、電話番号、通話、 テキスト メッセージ、録音のメタデータにクエリを送信することができます。 発信通話を開始したりテキスト メッセージを送信したりすることができます。
: - 料金 - twilio.kddi-web.com
電話番号料 1ヶ月あたり
050 番号 100 円（税別） 108 円（税込）
:
発信料 1 分あたり
:
携帯電話宛（070 / 080 / 090 番号） 15 円（税別） 16.2 円（税込）
:
サインアップするとトライアルアカウントとして試用ポイントが提供され（額は非公開）、同ポイントが尽きるとフルアカウントへのアップグレードとクレジットカード番号の登録を促されるしくみです。このポイントで 050 番号を一件取得しました。プログラムから簡単に電話連絡を扱えるのは便利なのでトライアル終了後も利用を継続したいと考えています。ちなみにコールだけなら上記の「発信料」は発生しません。
メッセージプッシュによる通知
スマホ・デスクトップ（ブラウザ）へのプッシュ通知も行います。メジャーな Pushover や Pushbullet はそれぞれ IFTTT に専用チャネルを持っていることもあり便利に扱えます。Pushover は専用アドレスへのメール送信によって通知処理をキックすることもできます。
メールでの通知
手元で使い慣れた SendGrid を利用してメールでの通知を行います。
試作 1
以下の要領で試作を行いました。
- 使用したソフトウェア資産
- インターネット接続の利用に伴い装置に以下のアダプタを追加
-
mbed LPC1768用イーサネット接続キット - www.switch-science.com
-
mbed LPC1768用イーサネット接続キット - www.switch-science.com
- 処理の流れ
- サンプリングレート 33330Hz, FFT サイズ 1024 で集音と周波数分析をループ実行する
- FFT 処理において次の帯域のピーク周波数が検知されれば 1. を中断し 3. へ移行する
ただしノイズによる影響を抑えるため所定の回数以上の連続検知を条件とする- 9800Hz〜16000Hz（犬笛系）
- 2000Hz〜4500Hz（ホイッスル全般）
- 前回の通知から所定の時間が経過していれば 4. へ。
経過していなければ 1. へ（通知の頻発を回避） - Google ドライブ上の所定のエントリに対する GET リクエストを試行。
レスポンスコードが 200 なら 5. へ
それ以外なら 1. へ（通知の無効化をリモートから可能とするための措置）- 所定のアカウントの Google ドライブ上のエントリへの第三者からのアクセスにおいては、当該エントリの共有がオンの状態なら 200 が返され、共有オフの状態なら 302 が返される。この仕様を低コストで取り回せる簡易フラグとして利用
- Twilio へ手持ちの電話のコールをリクエスト
- 今回はコールのみを目的とし短時間でタイムアウトさせる
- SendGrid へ手持ち Gmail アドレスへのメール通知をリクエスト
- Gmail のフィルタ設定により当該メールは Pushover 通知キック用のアドレスへ転送
- ふたたび 1. へ
動作の様子
動画：2分31秒 ※音量注意
ソースコード
Sonic06_FFT3
- main.cpp
// 所定の周波数信号を所定の回数以上連続検知すると通知を行う #include "mbed.h" #include "rtos.h" #include "EthernetInterface.h" #include "HTTPClient.h" #include "FastAnalogIn.h" #define DEVELOP #ifdef DEVELOP #define dbg(...) printf(__VA_ARGS__) #else #define dbg(...) #endif //#define USE_DHCP #if !defined(USE_DHCP) #define IP "192.168.0.113" #define GATEWAY "192.168.0.1" #define MASK "255.255.255.0" #endif #define SAMPLE_RATE 33330 // n >= 2, n = power of 2 #define FFTSIZE 1024 // length of ip >= 2+sqrt(n/2) const int IP_LEN = 4 + sqrt((double)(FFTSIZE/2)); // 当該サンプリングレートでのサンプリング間隔 const float SEC_PER_SAMPLEPOINT = 1.0 / SAMPLE_RATE; // 通知の最短間隔秒 #define INTERVAL_NOTIFICATION 180 // 犬笛系周波数帯 #define FREQ_LOW1 9800 #define FREQ_HIGH1 16000 // ホイッスル系周波数帯 #define FREQ_LOW2 2000 #define FREQ_HIGH2 4500 // 対象周波数連続検知回数閾値 #define MAXHITCOUNT 20 // for Twilio #define TWILIO_SID "AC1f7aa23e****************" #define TWILIO_AUTH "ef3638ca7*****************" #define URL_POSTDATA_TWILIO \ "https://api.twilio.com/2010-04-01/Accounts/" TWILIO_SID "/Calls" #define REQUEST_HEADER_FOR_TWILIO \ "Content-Type: " "application/x-www-form-urlencoded" "\r\n" #define POSTDATA_TWILIO \ "To=%2B8190********" "&" \ "From=%2B8150********" "&" \ "Url=http://demo.twilio.com/docs/voice.xml" "&" \ "Timeout=5" // for SendGrid #define SENDGRID_APIKEY "SG.UNFbQr_DQRmu8J********" #define REQUEST_HEADER_FOR_SENDGRID \ "Authorization: Bearer " SENDGRID_APIKEY "\r\n" \ "Content-Type: application/x-www-form-urlencoded\r\n" #define URL_POSTDATA_SENDGRID "https://api.sendgrid.com/api/mail.send.json" #define MAILTO "********@gmail.com" #define MAILFROM "mkttanabe2012@gmail.com" #define MAILSUBJECT "** ALERT [%s] **" #define MAILBODY "%dHz" // Google ドライブ上のフラグエントリ URL #define URL_FLAGFILE \ "https://docs.google.com/spreadsheets/d/1FR_RaR_AsyPAsIYU****************" Ticker tick; double *recBufp = NULL; int countTick = 0; FastAnalogIn mic(p20); AnalogOut speaker(p18); DigitalOut led(LED4); osThreadId mainThreadID; EthernetInterface eth; HTTPClient http; void rdft(int n, int isgn, double *a, int *ip, double *w); void setDummyTime() { struct tm t; t.tm_sec = t.tm_min = t.tm_hour = t.tm_mday = t.tm_mon = 1; t.tm_year = 100; time_t seconds = mktime(&t); set_time(seconds); } int initNetwork() { int sts; led = 1; dbg("start eth.init\r\n" ); #ifdef USE_DHCP sts = eth.init(); #else sts = eth.init(IP, MASK, GATEWAY); #endif if (sts != 0) { dbg("ech.init error!\r\n" ); return -1; } dbg("start eth.connect\r\n" ); sts = eth.connect(); if (sts != 0) { dbg("eth.connect error!\r\n" ); return -2; } dbg("my IP Address = %s\r\n", eth.getIPAddress()); led = 0; return 0; } // Googleドライブ上の所定のフラグエントリをチェック int checkFlagFile() { char buf[8]; for (int i = 0; i < 6; i++) { int sts = http.get(URL_FLAGFILE, buf, sizeof(buf), HTTP_CLIENT_DEFAULT_TIMEOUT); if (sts == HTTP_OK) { int rc = http.getHTTPResponseCode(); // 共有オンなら 200, オフなら 302 dbg("Flag is %s\r\n", (rc == 200) ? "enabled" : (rc == 302) ? "disabled" : "?????"); return rc; } dbg("sts=%d retrying..\r\n", sts); wait(5); } return -1; } int httpsPost(const char *targetUrl, const char *postData, const char *optHeader, const char *authId, const char *authPass) { int sts; char buf[64]; HTTPText dataToPost((char*)postData); HTTPText resData(buf, sizeof(buf)); http.setHeader(optHeader); for (int i = 0; i < 3; i++) { dbg("request to [%s]..\r\n", targetUrl); http.basicAuth(authId, authPass); sts = http.post(targetUrl, dataToPost, &resData, HTTP_CLIENT_DEFAULT_TIMEOUT); if (sts == HTTP_OK) { dbg("received HTTPS response OK\r\n"); dbg("head of data [%s]\r\n", buf); dbg("done\r\n\r\n"); break; } else { dbg("HTTPS request error=%d, status=%d\r\n", sts, http.getHTTPResponseCode()); dbg("head of data [%s]\r\n", buf); dbg("sts=%d retrying..\r\n", sts); wait(5); } } return sts; } int doFFT(double *FFTBuffer) { int ip[IP_LEN]; double *w = (double*)malloc(sizeof(double) * (FFTSIZE / 2)); ip[0] = 0; rdft(FFTSIZE, 1, FFTBuffer, ip, w); double maxAmp = 0; int index = 0; int endIdx = FFTSIZE/2; for (int i = 0; i < endIdx ; i++) { double a = FFTBuffer[i*2]; // 実部 double b = FFTBuffer[i*2 + 1]; // 虚部 // a+ib の絶対値 √ a^2 + b^2 = r が振幅値 double r = sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } float freq = index * SAMPLE_RATE / FFTSIZE; free(w); return (int)freq; } // サンプリング void flip() { // AnalogIn.read() の値範囲は 0〜1.0 につき中心値を 0 に recBufp[countTick++] = mic.read() - 0.5; if (countTick == FFTSIZE) { tick.detach(); countTick = 0; osSignalSet(mainThreadID, 1); // 集音完了通知 } } // 通知 int checkAndNotify(int freq, time_t *lastNotificationTime) { int pastSeconds = time(NULL) - *lastNotificationTime; // 前回の通知から所定の時間が経過の場合のみ次処理へ if (pastSeconds > INTERVAL_NOTIFICATION) { // 通信処理のために 集音・FFT用バッファを一旦開放 free(recBufp); recBufp = NULL; // Google ドライブ上の所定のフラグエントリをチェック // 共有がオンなら 200 が返り オフなら が返る dbg("checking flagFile..\r\n"); int rc = checkFlagFile(); dbg("rc=%d\r\n", rc); if (rc == 200) { for (int i = 0; i < 8; i++) { led = !led; wait_ms(200); } // Twilio で携帯電話をコール httpsPost(URL_POSTDATA_TWILIO, POSTDATA_TWILIO, REQUEST_HEADER_FOR_TWILIO, TWILIO_SID, TWILIO_AUTH); // SendGrid でメール送信 char b[256]; snprintf(b, sizeof(b), "from=" MAILFROM "&to=" MAILTO "&subject=" MAILSUBJECT "&text=" MAILBODY, eth.getIPAddress(), freq); dbg("mes=[%s]\r\n", b); httpsPost(URL_POSTDATA_SENDGRID, b, REQUEST_HEADER_FOR_SENDGRID, NULL, NULL); // 今回通知時刻を保持 *lastNotificationTime = time(NULL); } recBufp = (double*)malloc(sizeof(double) * FFTSIZE); return 1; } // 前回の発呼から所定の時間が経過していない dbg("pastSeconds=%d..\r\n", pastSeconds); return 0; } int main() { mainThreadID = osThreadGetId(); setDummyTime(); initNetwork(); // 集音用兼FFT用バッファ recBufp = (double*)malloc(sizeof(double) * FFTSIZE); time_t lastNotificationTime = 0; dbg("sampleRate=%dHz interval=%fsec\r\n", SAMPLE_RATE, SEC_PER_SAMPLEPOINT); tick.attach(&flip, SEC_PER_SAMPLEPOINT); // 対象周波数信号検出数 int hitCount = 0; while (1) { // サンプリング完了まで待機 osSignalWait(1, osWaitForever); // ピーク周波数を得る int freq = doFFT(recBufp); if (freq > FREQ_LOW1 && freq <= FREQ_HIGH1 || freq > FREQ_LOW2 && freq <= FREQ_HIGH2) { dbg("detected! %dHz\r\n", freq); led = 1; // 所定回数以上連続検知の場合のみ通知処理へ if (hitCount++ > MAXHITCOUNT) { hitCount = 0; checkAndNotify(freq, &lastNotificationTime); } } else { if (hitCount > 0) { dbg("ignored..\r\n"); } hitCount = 0; led = 0; } tick.attach(&flip, SEC_PER_SAMPLEPOINT); } if (recBufp) { free(recBufp); } return 0; }
試作 1 の問題点について
試作 1 では集音した信号の中でもっとも振幅の大きい周波数（ピーク周波数）を評価しており、また、対象範囲の周波数が FFT 処理において所定の回数以上 "連続して" 検知されることを判定条件としています。そのため周辺音の大きな環境では対象音を取りこぼす可能性があり、装置・音源間の距離が判定に影響を及ぼす度合いも少なくありません。この点の改善が必要と考えました。
下の動画には静かな状況と騒がしい状況での装置の反応を確認した様子を収めています。このように周囲の音が大きいと負けてしまいます。
動画：41秒 ※音量注意！
（似た話：Amazon Echo が反応しないので大声で怒鳴る人：Youtube より）
試作 2
以下の内容でプログラムの修正を行いました。
- ピーク周波数ベースの判定を変更
- ピーク周波数の参照に代え信号に含まれる対象範囲の周波数成分を能動的にチェックする。これにより周辺音による干渉を抑えられる
- 検知の考え方
- 上記のチェックにおいて所定のレベル以上の振幅値を伴うものの発見をもって検知とみなす。これにより対象音が微弱でもピックアップが可能となる
- 連続性の判定方法
- 音の連続性の判定は「対象周波数が所定の回数以上続けてピーク検出されること」を条件としていたが、これを「前回の検出から所定時間内の再検出が所定の回数以上繰り返されること」に変更する。これにより対象音が途切れがちでも切り捨ての可能性を抑えられる
- 対象周波数範囲の見直し
- 従来は 2000Hz〜4500Hz（ホイッスル全般）および 9800Hz〜16000Hz（犬笛系）のふたつのレンジを対象としていたが、前者は 基音として日常生活に登場する機会が少なくないため混乱につながるケースも想定される。そこで「上音」の存在に注目した
- 倍音 - wikipedia
上音 音を正弦波に分解したときに、最も低い周波数である基音以外の成分を 上音（じょうおん、overtone）という。この上音には倍音でない音も含まれる。 倍音は、基音の（2以上の）整数倍の周波数の上音であると言い換えることができる。
- 「どのような音を使うか」項に掲載の各音源の周波数分布（スペクトル）図を参照すると倍音を含む上音が高周波領域まで豊かに鳴っている様子が見てとれる。抜粋を以下に示す。※図の縦軸最大値は 15kHz
- 上記 1, 2 の措置により振幅の小さな成分であっても細かく検知可能となる背景もあり、実験的に 10000Hz 以上の音を対象とする改訂を加えた。サンプリングレート 33330Hz で集音しているため理論上 16600Hz 付近まで拾うことが可能 →サンプリング定理
（使用しているマイクモジュールのカバーする音域は公称「100Hz〜15kHz」 →データシート） - むろん周囲の生活音等が 10000Hz 以上の上音を発生させることもあるが、意図的なものでない限り上記 3 の連続性チェックをすり抜ける可能性は実用上低いと考えられる
- 倍音 - wikipedia
- 従来は 2000Hz〜4500Hz（ホイッスル全般）および 9800Hz〜16000Hz（犬笛系）のふたつのレンジを対象としていたが、前者は 基音として日常生活に登場する機会が少なくないため混乱につながるケースも想定される。そこで「上音」の存在に注目した
動作の様子
動画：2分3秒 ※音量注意！
ソースコード
（利用するプッシュ通知サービスを Pushover から Pushbullet に変更しています）
Sonic06_FFT3
- main.cpp
// 所定の周波数信号を所定の回数以上連続検知すると通知を行う // 改訂版：連続性のある 10kHz 以上の周波数成分をターゲットとする #include "mbed.h" #include "rtos.h" #include "EthernetInterface.h" #include "HTTPClient.h" #include "FastAnalogIn.h" #define DEVELOP #ifdef DEVELOP #define dbg(...) printf(__VA_ARGS__) #else #define dbg(...) #endif //#define USE_DHCP #if !defined(USE_DHCP) #define IP "192.168.0.113" #define GATEWAY "192.168.0.1" #define MASK "255.255.255.0" #endif #define SAMPLE_RATE 33330 // n >= 2, n = power of 2 #define FFTSIZE 1024 // length of ip >= 2+sqrt(n/2) const int IP_LEN = 4 + sqrt((double)(FFTSIZE/2)); // 当該サンプリングレートでのサンプリング間隔 const float SEC_PER_SAMPLEPOINT = 1.0 / SAMPLE_RATE; // 通知の最短間隔秒 #define INTERVAL_NOTIFICATION 180 #define MAXHITCOUNT 30 short indexOf10000Hz; // for Twilio #define TWILIO_SID "AC1f7aa23e****************"" #define TWILIO_AUTH "ef3638ca7****************"" #define URL_POSTDATA_TWILIO \ "https://api.twilio.com/2010-04-01/Accounts/" TWILIO_SID "/Calls" #define REQUEST_HEADER_FOR_TWILIO \ "Content-Type: " "application/x-www-form-urlencoded" "\r\n" #define POSTDATA_TWILIO \ "To=%2B8190********"" "&" \ "From=%2B8150********"" "&" \ "Url=http://demo.twilio.com/docs/voice.xml" "&" \ "Timeout=5" // for SendGrid #define SENDGRID_APIKEY "SG.UNFbQr_DQRmu8J********" #define REQUEST_HEADER_FOR_SENDGRID \ "Authorization: Bearer " SENDGRID_APIKEY "\r\n" \ "Content-Type: application/x-www-form-urlencoded\r\n" #define URL_POSTDATA_SENDGRID "https://api.sendgrid.com/api/mail.send.json" #define MAILTO "********@gmail.com" #define MAILFROM "mkttanabe2012@gmail.com" #define MAILSUBJECT "** ALERT [%s] **" #define MAILBODY "%dHz" // for IFTTT #define IFTTT_KEY "dSIwDguVEYfZ1SgiISL"********@" #define IFTTT_EVENT_NAME "ALERT" #define REQUEST_HEADER_FOR_IFTTT \ "Content-Type: application/json\r\n" #define URL_POSTDATA_IFTTT "https://maker.ifttt.com/trigger/" \ IFTTT_EVENT_NAME "/with/key/" IFTTT_KEY // Google ドライブ上のフラグエントリ URL #define URL_FLAGFILE \ "https://docs.google.com/spreadsheets/d/1FR_RaR_AsyPAsIYU****************" Ticker tick; double *recBufp = NULL; int countTick = 0; FastAnalogIn mic(p20); AnalogOut speaker(p18); DigitalOut led(LED4); osThreadId mainThreadID; EthernetInterface eth; HTTPClient http; void rdft(int n, int isgn, double *a, int *ip, double *w); void setDummyTime() { struct tm t; t.tm_sec = t.tm_min = t.tm_hour = t.tm_mday = t.tm_mon = 1; t.tm_year = 100; time_t seconds = mktime(&t); set_time(seconds); } int initNetwork() { int sts; led = 1; dbg("start eth.init\r\n" ); #ifdef USE_DHCP sts = eth.init(); #else sts = eth.init(IP, MASK, GATEWAY); #endif if (sts != 0) { dbg("ech.init error!\r\n" ); return -1; } dbg("start eth.connect\r\n" ); sts = eth.connect(); if (sts != 0) { dbg("eth.connect error!\r\n" ); return -2; } dbg("my IP Address = %s\r\n", eth.getIPAddress()); led = 0; return 0; } // Googleドライブ上の所定のフラグエントリをチェック int checkFlagFile() { char buf[8]; for (int i = 0; i < 6; i++) { int sts = http.get(URL_FLAGFILE, buf, sizeof(buf), HTTP_CLIENT_DEFAULT_TIMEOUT); if (sts == HTTP_OK) { int rc = http.getHTTPResponseCode(); // 共有オンなら 200, オフなら 302 dbg("Flag is %s\r\n", (rc == 200) ? "enabled" : (rc == 302) ? "disabled" : "?????"); return rc; } dbg("sts=%d retrying..\r\n", sts); wait(5); } return -1; } int httpsPost(const char *targetUrl, const char *postData, const char *optHeader, const char *authId, const char *authPass) { int sts; char buf[64]; HTTPText dataToPost((char*)postData); HTTPText resData(buf, sizeof(buf)); http.setHeader(optHeader); for (int i = 0; i < 3; i++) { //dbg("postData=[%s]\r\n", postData); dbg("request to [%s]..\r\n", targetUrl); http.basicAuth(authId, authPass); sts = http.post(targetUrl, dataToPost, &resData, HTTP_CLIENT_DEFAULT_TIMEOUT); if (sts == HTTP_OK) { dbg("received HTTPS response OK\r\n"); dbg("head of data [%s]\r\n", buf); dbg("done\r\n\r\n"); break; } else { dbg("HTTPS request error=%d, status=%d\r\n", sts, http.getHTTPResponseCode()); dbg("head of data [%s]\r\n", buf); dbg("sts=%d retrying..\r\n", sts); wait(5); } } return sts; } int doFFT(double *FFTBuffer) { int ip[IP_LEN]; double *w = (double*)malloc(sizeof(double) * (FFTSIZE / 2)); ip[0] = 0; rdft(FFTSIZE, 1, FFTBuffer, ip, w); bool found = false; float freq; int endIdx = FFTSIZE/2; for (int i = endIdx - 1; i >= indexOf10000Hz; i--) { freq = i * SAMPLE_RATE / FFTSIZE; double a = FFTBuffer[i*2]; double b = FFTBuffer[i*2 + 1]; double mag = sqrt(a*a + b*b); if (mag > 0.2) { dbg("freq=%f mag=%f\r\n", freq, mag); found = true; break; } } free(w); return (found) ? (int)freq : 0; } // サンプリング void flip() { // AnalogIn.read() の値範囲は 0〜1.0 につき中心値を 0 に recBufp[countTick++] = mic.read() - 0.5; if (countTick == FFTSIZE) { tick.detach(); countTick = 0; osSignalSet(mainThreadID, 1); // 集音完了通知 } } // 通知 int checkAndNotify(int freq, time_t *lastNotificationTime) { int pastSeconds = time(NULL) - *lastNotificationTime; // 前回の通知から所定の時間が経過の場合のみ次処理へ if (pastSeconds > INTERVAL_NOTIFICATION) { // 通信処理のために 集音・FFT用バッファを一旦開放 free(recBufp); recBufp = NULL; // Google ドライブ上の所定のフラグエントリをチェック // 共有がオンなら 200 が返り オフなら が返る dbg("checking flagFile..\r\n"); int rc = checkFlagFile(); dbg("rc=%d\r\n", rc); if (rc == 200) { for (int i = 0; i < 8; i++) { led = !led; wait_ms(200); } // Twilio で携帯電話をコール httpsPost(URL_POSTDATA_TWILIO, POSTDATA_TWILIO, REQUEST_HEADER_FOR_TWILIO, TWILIO_SID, TWILIO_AUTH); // SendGrid でメール送信 char b[256]; snprintf(b, sizeof(b), "from=" MAILFROM "&to=" MAILTO "&subject=" MAILSUBJECT "&text=" MAILBODY, eth.getIPAddress(), freq); dbg("mes=[%s]\r\n", b); httpsPost(URL_POSTDATA_SENDGRID, b, REQUEST_HEADER_FOR_SENDGRID, NULL, NULL); // IFTTT 経由で Pushbullet 通知をキック snprintf(b, sizeof(b), "{\"value1\":\"ALERT [%s]\", \"value2\":\"%dHz\", \"value3\":\"\"}\r\n", eth.getIPAddress(), freq); httpsPost(URL_POSTDATA_IFTTT, b, REQUEST_HEADER_FOR_IFTTT, NULL, NULL); // 今回通知時刻を保持 *lastNotificationTime = time(NULL); } recBufp = (double*)malloc(sizeof(double) * FFTSIZE); return 1; } // 前回の発呼から所定の時間が経過していない dbg("pastSeconds=%d..\r\n", pastSeconds); return 0; } int main() { dbg("**** TARGET FREQUENCY MODE ****\r\n"); int endIdx = FFTSIZE/2 - 1; for (int i = 0; i <= endIdx; i++) { float freq0 = i * SAMPLE_RATE / FFTSIZE; // 10kHz 以上の高周波音をターゲットとする if (freq0 >= 10000) { indexOf10000Hz = i; float freq1 = endIdx * SAMPLE_RATE / FFTSIZE; dbg("idx0=%d freq=%f\r\nidx1=%d freq=%f\r\n", i, freq0, endIdx, freq1); break; } } mainThreadID = osThreadGetId(); setDummyTime(); initNetwork(); // 集音用兼FFT用バッファ recBufp = (double*)malloc(sizeof(double) * FFTSIZE); time_t lastNotificationTime = 0; dbg("sampleRate=%dHz interval=%fsec\r\n", SAMPLE_RATE, SEC_PER_SAMPLEPOINT); tick.attach(&flip, SEC_PER_SAMPLEPOINT); // 対象周波数信号検出数 int hitCount = 0; time_t prevHitTime = 0; while (1) { osSignalWait(1, osWaitForever); // 監視対象とする周波数領域の成分が所定レベル以上の振幅ならその周波数、 // そうでなければ 0 が返る int freq = doFFT(recBufp); if (freq != 0) { // 前回検出から1秒以内の再検出ならカウントアップ if (time(NULL) - prevHitTime <= 1) { // 所定の回数以上検知の場合は通知処理へ if (++hitCount >= MAXHITCOUNT) { dbg("checkAndNotify\r\n"); checkAndNotify(freq, &lastNotificationTime); hitCount = 0; } } else { hitCount = 1; dbg("restart\r\n"); } prevHitTime = time(NULL); } tick.attach(&flip, SEC_PER_SAMPLEPOINT); } if (recBufp) { free(recBufp); } return 0; }
2. 着信音で遠隔操作を行うしくみを作る
自宅の固定電話機の着信音をトリガーに処理を行うしくみを考えました。次のイメージです。
- 手持ちの携帯電話など所定の電話番号からのコールに対する固有の着信音を自宅固定電話へ設定しておく
- 電話機の側に設置した装置は当該着信音によるコールを待ち続ける
- 装置は所定回数のコールを連続して検知すると所定の機器への通電をオン／オフする
過去の試みとの比較
手元で過去に何度か同様の遠隔操作を試みたことがあります。いずれもインターネット上のサービスを利用して装置へ通知を行い、それをトリガーに処理を行うものです。
これらはいずれもおおむね期待通りに動きましたが、一方で次のようなジレンマもありました。
- 外部サービス側処理の遅延発生や一時停止の可能性を回避することはできない：問題 大
- 遠隔操作にはインターネット接続環境が必須：問題 中
- クライアントアプリ（Webブラウザを含む）の操作に手間がかかる：問題 小
それに対して、装置への通知に「音」を利用することには次のメリットが挙げられます。
- 災害時等の特殊な状況以外での発着信上のトラブルの可能性はほぼ度外視できる
- 発着信にはネット接続環境も特別なアプリケーションも不要
- 発信電話番号にこだわらなければ携帯電話機を携行する必要もない
こういった特長を活かしうまく使えば有用なツールとなりそうです。
準備
現在自宅では固定電話機としてユニデン社製の「UCT-002」を使っています。
トリガーとする着信音として、この UCT-002 の「パターン2」を選びました。次のような音です。
- 音の様子
- 波形の概観（Audacity による）
- 周波数分布
- 1秒間発振 〜 2秒間無音 を繰り返す
- 複数の周波数の音を小刻みに発振
- mbed 上で前出のプログラムを使ってピーク周波数を確認すると以下の成分が検出された
- 1204Hz
- 1009Hz
- 976Hz
- 813Hz
- 781Hz
試作
以上の内容をもとに次の要領で試作を行いました。
- この電話機は装置への密接が可能であるためここでは常にピーク周波数に注目する
- 上に挙げた 5種類の周波数成分を監視対象とする
- 「対象周波数を所定回数以上連続検知すること」と「その後に 2秒程度の非検知が続くこと」をもって一回のコールと判断する
- コールを 3回連続して認識した後にもう一度対象周波数を検知するとアクションを実行する
- アクションの内容は AC電源機器への通電。前に作ったリレーつき電源ケーブルを mbed LPC1768 の p10 に接続し Hi / Low で機器への通電有無を切り替える
- アクション発生時にはメールで通知する
動作の様子
動画：1分40秒 ※音量注意！
この動画では携帯電話から自宅固定電話をコールして照明の ON/OFF を行っています。
動画：1分24秒 ※音量注意！
PC 上で対象着信音をサンプリング〜改変したものを数種類鳴らし、装置がそれらには応じない様子を収めています。
ソースコード
Sonic09_FFT4
- main.cpp
// 所定パターンの電話着信音に反応してアクションを起こす // ユニデン社製 UCT-002 の着信音「パターン2」への対応版 // 1秒発振〜2秒無音 の繰り返し #include "mbed.h" #include "rtos.h" #include "EthernetInterface.h" #include "HTTPClient.h" #define DEVELOP #ifdef DEVELOP #define dbg(...) printf(__VA_ARGS__) #else #define dbg(...) #endif //#define USE_DHCP #if !defined(USE_DHCP) #define IP "192.168.0.113" #define GATEWAY "192.168.0.1" #define MASK "255.255.255.0" #endif #define SAMPLE_RATE 33330 // n >= 2, n = power of 2 #define FFTSIZE 1024 // length of ip >= 2+sqrt(n/2) const int IP_LEN = 4 + sqrt((double)(FFTSIZE/2)); // 発振音に含まれる周波数成分（監視対象） int tgtF[] = {1204, 1009, 976, 813, 781}; #define isTargetFreq(F) \ (F == tgtF[0] || F == tgtF[1] || F == tgtF[2] || F == tgtF[3] || F == tgtF[4]) // for SendGrid #define SENDGRID_APIKEY "SG.UNFbQr_DQRmu8J********" #define REQUEST_HEADER_FOR_SENDGRID \ "Authorization: Bearer " SENDGRID_APIKEY "\r\n" \ "Content-Type: application/x-www-form-urlencoded\r\n" #define URL_POSTDATA_SENDGRID "https://api.sendgrid.com/api/mail.send.json" #define MAILTO "********@gmail.com" #define MAILFROM "mkttanabe2012@gmail.com" #define MAILSUBJECT "** Power %s **" #define MAILBODY "callCount:%d" Ticker tick; double *recBufp = NULL; int countTick; Timer timer; bool recDone; AnalogIn mic(p20); DigitalOut led(LED4); DigitalOut relay(p10); // リレーつき電源ケーブルを接続 EthernetInterface eth; HTTPClient http; osThreadId mainThreadID; // 当該サンプリングレートでのサンプリング間隔 const float SEC_PER_SAMPLEPOINT = 1.0 / SAMPLE_RATE; // 音声信号は実数データにつき実離散フーリエ変換（Real DFT）関数を使う void rdft(int n, int isgn, double *a, int *ip, double *w); void setDummyTime() { struct tm t; t.tm_sec = t.tm_min = t.tm_hour = t.tm_mday = t.tm_mon = 1; t.tm_year = 100; time_t seconds = mktime(&t); set_time(seconds); } int initNetwork() { int sts; led = 1; dbg("start eth.init\r\n" ); #ifdef USE_DHCP sts = eth.init(); #else sts = eth.init(IP, MASK, GATEWAY); #endif if (sts != 0) { dbg("ech.init error!\r\n" ); return -1; } dbg("start eth.connect\r\n" ); sts = eth.connect(); if (sts != 0) { dbg("eth.connect error!\r\n" ); return -2; } dbg("my IP Address = %s\r\n", eth.getIPAddress()); led = 0; return 0; } int httpsPost(const char *targetUrl, const char *postData, const char *optHeader, const char *authId, const char *authPass) { int sts; char buf[64]; HTTPText dataToPost((char*)postData); HTTPText resData(buf, sizeof(buf)); http.setHeader(optHeader); for (int i = 0; i < 3; i++) { //dbg("postData=[%s]\r\n", postData); dbg("request to [%s]..\r\n", targetUrl); http.basicAuth(authId, authPass); sts = http.post(targetUrl, dataToPost, &resData, HTTP_CLIENT_DEFAULT_TIMEOUT); if (sts == HTTP_OK) { dbg("received HTTPS response OK\r\n"); dbg("head of data [%s]\r\n", buf); dbg("done\r\n\r\n"); break; } else { dbg("HTTPS request error=%d, status=%d\r\n", sts, http.getHTTPResponseCode()); dbg("head of data [%s]\r\n", buf); dbg("sts=%d retrying..\r\n", sts); wait(5); } } return sts; } int doFFT(double *FFTBuffer) { int ip[IP_LEN]; double *w = (double*)malloc(sizeof(double) * (FFTSIZE/2)); ip[0] = 0; rdft(FFTSIZE, 1, FFTBuffer, ip, w); double maxAmp = 0; int index; for (int i = 0; i < FFTSIZE/2; i++) { double a = FFTBuffer[i*2]; // 実部 double b = FFTBuffer[i*2 + 1]; // 虚部 double r = sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } double freq = index * SAMPLE_RATE / FFTSIZE; if (freq > 0 && maxAmp > 1.0) { //dbg("freq=%d mag=%f\r\n", (int)freq, maxAmp); } free(w); return (int)freq; } // サンプリング void flip() { // AnalogIn.read() の値範囲は 0〜1.0 につき中心値を 0 に recBufp[countTick++] = mic.read() - 0.5; if (countTick == FFTSIZE) { tick.detach(); osSignalSet(mainThreadID, 1); // 集音完了通知 } } // メール送信 void sendMail(int callCount) { char b[128]; snprintf(b, sizeof(b), "from=" MAILFROM "&to=" MAILTO "&subject=" MAILSUBJECT "&text=" MAILBODY, (relay == 1) ? "ON" : "OFF", callCount+1); httpsPost(URL_POSTDATA_SENDGRID, b, REQUEST_HEADER_FOR_SENDGRID, NULL, NULL); } int main() { time_t lastDetectedTime = 0, lastActionTime = 0; time_t lastNonDetectedTime = 0; int blankPeriod = 0, ringCount = 0, callCount = 0; relay = 0; setDummyTime(); mainThreadID = osThreadGetId(); initNetwork(); recBufp = (double*)malloc(sizeof(double) * FFTSIZE); dbg("start\r\n"); while (1) { countTick = 0; tick.attach(&flip, SEC_PER_SAMPLEPOINT); osSignalWait(1, osWaitForever); if (time(NULL) - lastDetectedTime >= 4) { // 4秒以上対象音を非検知ならコールカウンタをリセット callCount = 0; } int freq = doFFT(recBufp); if (isTargetFreq(freq)) { // 前回のアクションから所定の時間が経過していなければ受け流す if (lastActionTime > 0) { int w = time(NULL) - lastActionTime; if (w < 30) { dbg("pending.. %dsec\r\n", w); continue; } } ringCount++; if (callCount >= 3) { // アクション実行 relay = !relay; dbg("Power %s\r\n", (relay == 1) ? "On" : "Off"); free(recBufp); sendMail(callCount); recBufp = (double*)malloc(sizeof(double) * FFTSIZE); callCount = ringCount = 0; lastActionTime = time(NULL); } lastDetectedTime = time(NULL); } else { // 非対象音 blankPeriod += (time(NULL) - lastNonDetectedTime); if (blankPeriod > 30) { blankPeriod = 0; } lastNonDetectedTime = time(NULL); if (ringCount > 7) { if (callCount == 0 || blankPeriod >= 2 && blankPeriod < 4) { callCount++; dbg("call count=%d\r\n", callCount); blankPeriod = 0; } } ringCount = 0; } } if (recBufp) { free(recBufp); } return 0; }
おわりに
音を題材に手元で行ってきた実験と試作の内容を 5 回に分けて紹介しました。音を媒体とする手法は旧くて新しい奥の深い世界です。新たな製品やサービス・アプリケーションを構築する際の道具立てのひとつとして、あるいは、他の方法がすべて利用できない場合の伏兵としても有用でしょう。とても興味深い経験でした。
(tanabe)
音を利用する 4 〜mbed マイコンでの応用：準備編〜
この記事の内容
IoT 方面での応用を想定しマイコン系でも音に関する実験と試作を行いました。今回はその準備編です。ここではプラットフォームとして mbed LPC1768 ボードを使用しています。基本的な考え方は環境に依存しないため要素の多くは他の製品向けに読み替えることも可能でしょう。
準備 1. 部品を用意する
音声データの入出力用に以下の部品を用意しました。
オペアンプ内蔵
マイクモジュールを mbed LPC1768 の p20（AnalogIn）に、オーディオアンプを p18（AnalogOut）に接続しました。これを実験に使います。
準備 2. mbed マイコンでの音声入出力処理を覚える
何はともあれ音声データの入出力方法からです。リファレンスを確認します。
- AnalogIn - アナログ入力 - developer.mbed.org
- AN10974 LPC176x/175x 12-bit ADC design guidelines（PDF） - www.nxp.com
Page 3 of 19 より - AnalogOut - アナログ出力 - developer.mbed.org
val = name.read();
valには0(0V)〜1.0(3.3V)の数値（float）が代入されます。
val = name.read_u16();
valには0(0V)〜65535(0xffff, 3.3V)の数値が代入されます。（上位12ビットが有効）
The LPC175x/6x family is based on the ARM Cortex M3 core, and includes a 12-bit Analog-to-Digital (ADC) module with input multiplexing among eight pins, conversion rates up to 200 kHz, and multiple result registers.
name = 0.5;
0(0V)〜1(3.3V)の数値（float）で出力を指定します。
name.write_u16 = 1000;
0(0V)〜65535(0xffff, 3.3V)の数値（unsigned short）で出力を指定します。（上位10ビットが有効）
試作 1
まず、ごく素朴な録音・再生プログラムを書いてみました。次の内容です。
- サンプリングレートは 4000Hz
- 入力信号を 4000Hz でサンプリングするための時間間隔 w を計算
w = 1sec / 4000Hz = 0.00025sec = 0.25msec = 250μsec - アナログ入力から w 間隔で読み取った値をサンプリング用バッファの終端まで順次格納する
- サンプリング用バッファに格納した値を w 間隔で順次アナログ出力へ書き込む 〜無限ループ
動作の様子
動画：20秒 ※音量注意
ソースコード
sonic01_mic
- main.cpp
#include "mbed.h" #define SAMPLE_RATE 4000 #define BUFSIZE 7680 AnalogIn mic(p20); AnalogOut speaker(p18); DigitalOut led(LED4); float recBuf[BUFSIZE]; int main() { // 当該サンプリングレートでのサンプリング間隔 float w = 1.0 / SAMPLE_RATE; // 録音開始までに LED を 3回点滅させる led = 1; for (int i = 0; i < 6; i++) { wait(0.5); led = !led; } // 録音 for (int i = 0; i < BUFSIZE; i++) { recBuf[i] = mic.read(); wait(w); } led = 0; // 再生 while (1) { for (int i = 0; i < BUFSIZE; i++) { speaker = recBuf[i] ; wait(w); } } return 0; }
試作 1 の問題点について
このようにとても短いコードで簡単に音声データの入出力を実現できました。しかし、録音と再生を試していると微妙な違和感がありました。録音した音と再生される音の高さが違うような気がしたのです。このことを楽器を使って確認してみました。
再生音の高さがおかしい？
動画：21秒 ※音量注意
この動画では楽器の音を録音し再生時に合わせ弾きなどを行っています。なお、前掲の安価なスピーカーではやはり音質が貧弱なので、この動画以降ではアンプ内蔵のスピーカー（PHILIPS 社製 BT50）を AnalogOut ポートにつないで再生に使用しています。
問題の原因と対処方法
このおかしな現象の原因は試作 1 のコードにおいてサンプリング間隔を制御している wait() 関数にあります。mbed プログラミングにおいてきわめてカジュアルに使用されるこの関数のリファレンスをあらためて確認したところ「When you call wait your board's CPU will be busy in a loop waiting for the required time to pass」との記述があり、とりあえず以下の内容で精度の確認を行いました。
インターバル 250μ秒での結果は次の通りです。
このように wait() + AnalogIn.read() で大幅な遅延が発生しています。一方、wait() + AnalogOut.write() では相対的に遅延が小さいため試作 1 のプログラムは結果として「低いレートでサンプリング」したデータを「高いレートで再生」する所作となっていました。上の検証でのインターバル 10〜250μ秒を横軸、所要時間の誤差の割合を縦軸にプロットしたグラフを以下に示します。
（クリックで可読大表示）
サンプリング間隔のコントロールに mbed 標準のタイマ割込み機構である Ticker を使って同じ検証を行いました。
インターバル 250μ秒での結果は次の通りです。
（クリックで可読大表示）
このように結果は wait() 使用時よりも圧倒的に良好です。その一方で、AnalogIn.read() 併用時のインターバル 25μ秒付近の「壁」の存在が目に止まります。手元の検証ではこの結果には明確な再現性がみられました。25μ秒以下の割込みを必要としないサンプリングレートを利用すれば大きな支障はなさそうですが、広く用いられるレート 44100Hz の場合には 1sec / 44100Hz ≒ 23μsec とサンプリング間隔が 25μ秒を割り込むことが微妙に残念でもあります。
一連の調査の過程で Erik Olieman 氏による FastAnalogIn ライブラリの存在を知りました。
所定のアナログ入力ポートに対する mbed 標準の AnalogIn.read() が、呼び出しの都度、当該ポートに対応する ADC チャネル経由で AD 変換を行う仕様（そのため遅い）であるのに対し、FastAnalogIn は ADC の BURST mode を利用して変換をバックグラウンドで最大 200kHzで繰り返し実行し read() が呼び出されると「最後にサンプリングした値」を直ちに返す内容で実装されています。 （※ 前掲の ADC ドキュメント中の "conversion rates up to 200 kHz" のくだりは BURST mode 下のこの所作を指すものと考えられる）
- FastAnalogIn - a mercurial repository | mbed - developer.mbed.org
- FastAnalogIn Class Reference - developer.mbed.org
- ADC_LPC1768 - John Kneen: Microcontrollers - 6. Selecting and triggering the analogue to digital conversion. - sites.google.com
When you read an AnalogIn object it will enable the corresponding ADC channel, depending on the implementation do either one or multiple measurements for more accuracy, and return that value to your program. This way the ADC is only active when it is required, and it is fairly straightforward. However the downside is, is that an ADC is relatively slow.
:
This library uses the 'burst' feature of the microcontroller. This allows the ADC on the background to perform the AD conversions without requiring intervention from the microcontroller's core. Also there are no interrupts used, so also your time-sensitive code is not affected.
:
AnalogIn does a single conversion when you read a value (actually several conversions and it takes the median of that). This library runns the ADC conversion automatically in the background. When read is called, it immediatly returns the last sampled value.
:
Bit 16 : BURST
1 The AD converter does repeated conversions at up to 200 kHz, scanning (if necessary) through the pins selected by bits set to ones in the SEL field.
:
計測用コードの中の AnalogIn をこの FastAnalogIn に変更して同様の計測を行ったところ 25μ秒以下のインターバルでの成績が劇的に改善されました。前掲のふたつのグラフの縦軸最大値が「100%」であったのに対し、下のグラフでは「1.00%」であることに要注目です。
（クリックで可読大表示）
試作 2
上の「対処方法」を反映した形で録音・再生プログラムを書き直しました。検証上の便宜を兼ねて次の内容としています。
- 録音・再生に要素数 14000 の unsigned short 型配列を使用する
- サンプリングレート 8000Hz, 16000Hz, 22000Hz, 30720Hz, 44100Hz の順に録音と再生を行う
- レートが高くなるほど録音可能時間は短くなるが、再生はいずれも 8秒間程度繰り返し行う
動作の様子
動画：1分28秒 ※音量注意
この動画では各サンプリングレートにおいてキーボードの「ファ」の音（F5：698.456Hz）を録音し、その再生音を以前作成したピーク周波数表示プログラムと楽器用のチューナー（KORG 社製 AW-2G）で確認しています。
ソースコード
sonic07_mic3
- main.cpp
// サンプリングと再生 // レート 8000,16000,22000,30720,44100Hz の順にサンプリングを行い // それぞれ 8秒程度ループ再生する // FastAnalogIn ライブラリを使用 #include "mbed.h" #include "FastAnalogIn.h" #define DEVELOP #ifdef DEVELOP #define dbg(...) printf(__VA_ARGS__) #else #define dbg(...) #endif #define BUFSIZE 14000 Ticker tick; Timer timer; int countTick,interval_us, sampleTime; bool recDone; unsigned short *recBufp = NULL; AnalogOut speaker(p18); FastAnalogIn mic(p20); DigitalOut led(LED4); // サンプリング void flipRec() { recBufp[countTick++] = mic.read_u16() & 0xFFFC; if (countTick == BUFSIZE) { tick.detach(); recDone = true; } } // 再生 void flipPlay() { speaker.write_u16(recBufp[countTick++]); if (countTick == BUFSIZE) { countTick = 0; } } void recAndPlay(int sampleRate) { // 当該サンプリングレートでのサンプリング間隔 usec interval_us = 1.0 / sampleRate * 1000000; // 当該サンプリングレートでのサンプリング時間 usec sampleTime = BUFSIZE * interval_us / sizeof(short); dbg("rate=%5dHz irq=%dus time=%dms\r\n", sampleRate, interval_us, sampleTime/1000); // サンプリング開始までに LED を 3回点滅させる led = 1; for (int i = 0; i < 6; i++) { wait(0.4); led =! led; } // サンプリング countTick = 0; recDone = false; tick.attach_us(&flipRec, interval_us); while (!recDone) { wait(0.2); } led = 0; wait(1); // 8秒程度ループ再生 countTick = 0; tick.attach_us(&flipPlay, interval_us); wait(8); tick.detach(); } int main() { recBufp = (unsigned short*)malloc(BUFSIZE); recAndPlay(8000); recAndPlay(16000); recAndPlay(22000); recAndPlay(30720); recAndPlay(44100); dbg("done\r\n"); if (recBufp) { free(recBufp); } return 0; }
準備 3. 任意の周波数の音波を生成・出力する
先般のAndroid 環境での試みと同様に手元の mbed マイコンでサイン波信号を生成・出力してみます。Android 版での到達点を踏襲できるのであまり手はかかりませんでした。
試作
以下の要領でプログラムを作成しました。
- 400Hz〜14000Hz の範囲の 10種類の周波数のサイン波信号を順次生成する
- サンプリングレートは 33330Hz（サンプリング間隔 30μ秒）とし、バッファ上に各周波数 100ミリ秒分の信号データを構築してそれぞれ 4秒間程度 AnalogOut ポートへ出力する
- unsigned short 型配列を引数にとる AnalogOut.write_u16() の引数範囲は 0〜65535 であるため信号生成時に直流成分として 65535 / 2 を加える
動作の様子
動画：1分15秒 ※音量注意
この動画では二台のタブレット上のふたつのプログラムを使って信号の確認を行っています。
- 左側：手元で以前作成したプログラムでピーク周波数を表示
- 右側：Google Play ストアで公開されている AudioUtil Spectrum Analyzer で波形を表示
ソースコード
sonic08_sine2
- main.cpp
// サイン波音声信号を生成・出力する #include "mbed.h" #define DEVELOP #ifdef DEVELOP #define dbg(...) printf(__VA_ARGS__) #else #define dbg(...) #endif #define SAMPLE_RATE 33330 #define PI 3.141592653589793238462 #define MAG 3000 Ticker tick; int count = 0; const int BUFSIZE = SAMPLE_RATE / 10; // バッファサイズ 100ミリ秒分 unsigned short waveBuf[BUFSIZE]; // 当該サンプリングレートでのサンプリング間隔 秒 const float SEC_PER_SAMPLEPOINT = 1.0 / SAMPLE_RATE; const float a0 = 65535 / 2; AnalogOut speaker(p18); // 出力 void flip() { speaker.write_u16(waveBuf[count++]); (count >= BUFSIZE) ? count = 0 : 1; } void outputSineWave(int freq) { for (int i = 0; i < BUFSIZE; i++) { float currentSec = i * SEC_PER_SAMPLEPOINT; double val = a0 + MAG * sin(2.0*PI * freq * currentSec); waveBuf[i] = (unsigned short)val; } count = 0; tick.attach(&flip, SEC_PER_SAMPLEPOINT; wait(4); // 4秒程度出力 tick.detach(); } int main() { dbg("interval=%fs\r\n", SEC_PER_SAMPLEPOINT); outputSineWave(400); outputSineWave(800); outputSineWave(1200); outputSineWave(1600); outputSineWave(2000); outputSineWave(4000); outputSineWave(8000); outputSineWave(10000); outputSineWave(12000); outputSineWave(14000); return 0; }
準備 4. 集音したデータの周波数分析を行う
準備編の最後に入力信号の分析を試みます。
大浦版 FFT について
ここでは高性能かつコンパクトな FFT ライブラリとして広く利用（NASA の例）されている大浦拓哉様（京都大学数理解析研究所 助教）によるライセンスフリーの汎用 FFT パッケージ（通称 大浦版 FFT）を使ってみることにしました。先般 Android 環境下で利用した JTransforms はこのパッケージを母体とするソフトウェアです。
- 大浦 拓哉 (Ooura, Takuya) - 京都大学数理解析研究所 - www.kurims.kyoto-u.ac.jp
- 音声信号は実数データにつき実離散フーリエ変換関数 rdft() を使用する。使い方はシンプル。FFT サイズを 2のべき乗の値とすることに注意。
-------- Real DFT / Inverse of Real DFT --------
[usage]
<case1>
ip[0] = 0; // first time only
rdft(n, 1, a, ip, w);
<case2>
ip[0] = 0; // first time only
rdft(n, -1, a, ip, w);
[parameters]
n :data length (int)
n >= 2, n = power of 2
a[0...n-1] :input/output data (double *)
<case1>
output data
a[2*k] = R[k], 0<=k<n/2
a[2*k+1] = I[k], 0<k<n/2
a[1] = R[n/2]
<case2>
input data
a[2*j] = R[j], 0<=j<n/2
a[2*j+1] = I[j], 0<j<n/2
a[1] = R[n/2]
ip[0...*] :work area for bit reversal (int *)
length of ip >= 2+sqrt(n/2)
strictly,
length of ip >=
2+(1<<(int)(log(n/2+0.5)/log(2))/2).
ip[0],ip[1] are pointers of the cos/sin table.
w[0...n/2-1] :cos/sin table (double *)
w[],ip[] are initialized if ip[0] == 0.
[remark]
Inverse of
rdft(n, 1, a, ip, w);
is
rdft(n, -1, a, ip, w);
for (j = 0; j <= n - 1; j++) {
a[j] *= 2.0 / n;
}
一次元 DFT / DCT / DST
詳細
一次元，２の整数乗個のデータの離散 Fourier 変換， コサイン変換，サイン変換等を行います．このパッケージには C と Fortran の FFT コードが含まれます．
:
内容
fft4g.c : FFT パッケージ in C - 高速版 (基数 4, 2)
:
ファイルの違い
簡易版は作業用配列を一切使いません．高速版は三角関数表などの作業用配列を使います．高速版は簡易版に比べて高速かつ高精度．高速版の仕様はすべて同じ．
パッケージ内のルーチン
cdft() : 複素離散 Fourier 変換 rdft() : 実離散 Fourier 変換
:
ライセンス
Copyright Takuya OOURA, 1996-2001
このソースコードはフリーソフトです．商用目的を含め，このコードの使用， コピー，修正及び配布は自由に行って結構です．ただし，このコードの修正を 行った場合は，そのことを明記してください．
試作
レート 33330Hz でサンプリングした音声信号を mbed マイコン上の FFT 処理にかけてピーク周波数を求めコンソールへ連続出力する内容で試作を行いました。手元の確認では mbed LPC1768 のメモリ容量上 FFT サイズは 210 = 1024 が限界でありその影響らしきものが若干窺えるものの十分に実用水準にあると考えられます。
動作の様子
動画：1分33秒 ※音量注意
この動画では二台のタブレット上のふたつのプログラムを使ってテストを行っています。
- 左側：以前作成したピーク周波数表示プログラム
- 右側：以前作成したサイン波信号出力プログラム
ソースコード
sonic05_FFT2
- main.cpp
// 大浦版 FFT ライブラリで入力音声信号のピーク周波数を得る #include "mbed.h" #define DEVELOP #ifdef DEVELOP #define dbg(...) printf(__VA_ARGS__) #else #define dbg(...) #endif #define PI = 3.141592653589793238462; #define SAMPLE_RATE 33330 // n >= 2, n = power of 2 #define FFTSIZE 1024 // length of ip >= 2+sqrt(n/2) const int IP_LEN = 4 + sqrt((double)(FFTSIZE/2)); Ticker tick; double *recBufp = NULL; int countTick; Timer timer; bool recDone; AnalogIn mic(p20); DigitalOut led(LED4); // 当該サンプリングレートでのサンプリング間隔 秒 const float SEC_PER_SAMPLEPOINT = 1.0 / SAMPLE_RATE; void rdft(int n, int isgn, double *a, int *ip, double *w); int doFFT(double *FFTBuffer) { int ip[IP_LEN]; double *w = (double*)malloc(sizeof(double) * (FFTSIZE/2)); ip[0] = 0; rdft(FFTSIZE, 1, FFTBuffer, ip, w); double maxAmp = 0; int index; for (int i = 0; i < FFTSIZE/2; i++) { double a = FFTBuffer[i*2]; // 実部 double b = FFTBuffer[i*2 + 1]; // 虚部 // a+ib の絶対値 √ a^2 + b^2 = r が振幅値 double r = sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } double freq = index * SAMPLE_RATE / FFTSIZE; if (freq > 0 && maxAmp > 1.0) { dbg("freq=%d mag=%f\r\n", (int)freq, maxAmp); } free(w); return (int)freq; } // サンプリング void flip() { // AnalogIn.read() の値範囲は 0〜1.0 につき中心値を 0 に recBufp[countTick++] = mic.read() - 0.5; if (countTick == FFTSIZE) { tick.detach(); recDone = true; } } int main() { recBufp = (double*)malloc(sizeof(double) * FFTSIZE); while (1) { countTick = 0; recDone = false; tick.attach(&flip, SEC_PER_SAMPLEPOINT); while (!recDone) { wait_ms(100); } doFFT(recBufp); } if (recBufp) { free(recBufp); } return 0; }
(tanabe)
音を利用する 3 〜Android デバイスでの音波通信：実装編〜
この記事の内容
前回の記事では Android デバイス間で音波通信を行うための準備として次のみっつの要素に目を向けました。
今回はこれらを素材として音声信号でビットデータを送受信してみます。四段階に分け順次機能を加えながら試作を行います。
2017-11-29 追記：本記事に掲載のコードは開発時に Android 5.x 環境を使用しており、Android 6.0 以降では android.permission.RECORD_AUDIO について実行時パーミッション取得が必要です。
- 実行時のパーミッション リクエスト - developer.android.com
- Support Library - 下位互換性 - developer.android.com
他のプロジェクトについても適宜加味して下さい。
1. ビットデータを音声信号で送受信する 1
想定した内容
まず最初の試作に際し次の内容を想定しました。
- 送信側は送信専用、受信側は受信専用とする
- 送信側は任意の文字列を所定の規則に添ってサイン波信号に変換しオーディオ出力する
- 受信側は集音中に所定の規則に添った音声信号を検知するとそこから文字列情報を復元し画面に表示する
- 開発上の便宜のために可聴音を使用する
以下についてはとりあえず後まわしです。
- 伝送効率
- 誤りへの対策
周波数変調（FSK）について
所定のデータを音声信号に変換するために周波数変調方式を利用することにしました。次の考え方です。
- ふたつの周波数 A, B に 0 と 1 を割り当てる
- 元データのビット並びを上記 A, B に置き換えそれらを所定の時間間隔で切り替える
- FSK - 「通信用語の基礎知識」より
正弦波に対してディジタル信号で変調を行なういわゆるディジタル変調の方式の一つで、ディジタル値を正弦波の周波数に対応させて伝送する方式のこと。具体的にはディジタル値の1/0に対応させて2つの周波数を決め、入力されるディジタル信号に応じてそれぞれの周波数の正弦波を交互に送出することで実現させる。
試作
処理のイメージ
ざっくり以下の要領で実装を試みました。
- 周波数変調においては 8000Hz を 0, 10000Hz を 1 として扱い 1 ビットあたりの発振持続時間を 100ミリ秒とする
（よって伝送速度は 10bps）
- 信号出力に際しては単一バッファ上に終始の完結したデータを構築するのではなく生成済みの 8000Hz, 10000Hz 信号を再生バッファに順次直接書き込む
- 今回は参照していないが末尾に終端の符丁として 12000Hz の信号を 1秒間付与する
- 左：送信側 右：受信側
動作の様子
動画： 1分30秒 ※音量注意！
ソースコード
送信側： sonic05
- MainActivity.java
/** * * sonic05 * * 文字列をサイン波信号に置き換えて出力する * Lo -> 8000Hz, Hi -> 10000Hz * 対向の受信プログラムは sonic06 * */ package jp.klab.sonic05; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.AudioManager; import android.media.AudioTrack; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.EditText; import android.widget.ToggleButton; import java.io.UnsupportedEncodingException; import java.util.Arrays; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final float SEC_PER_SAMPLEPOINT = 1.0f / SAMPLE_RATE; private static final int AMP = 4000; private static final int ELMS_1SEC = SAMPLE_RATE; private static final int ELMS_100MSEC = SAMPLE_RATE/10; private static final int FREQ_LOW = 8000; private static final int FREQ_HI = 10000; private static final int FREQ_END = 12000; private static final int MSG_PLAY_START = 120; private static final int MSG_PLAY_END = 130; private static final byte [] BITS = new byte [] { (byte)0x80, (byte)0x40, (byte)0x20, (byte)0x10, (byte)0x08, (byte)0x04, (byte)0x02, (byte)0x01}; private Handler mHandler; private AudioTrack mAudioTrack = null; private ToggleButton mButton01; private EditText mEditText01; private short mPlayBuf1[]; private short mPlayBuf2[]; private short mPlayBuf3[]; private String mText; // サイン波データを生成 private void createSineWave(short[] buf, int freq, int amplitude, boolean doClear) { if (doClear) { Arrays.fill(buf, (short) 0); } for (int i = 0; i < ELMS_1SEC; i++) { float currentSec = i * SEC_PER_SAMPLEPOINT; // 現在位置の経過秒数 double val = amplitude * Math.sin(2.0 * Math.PI * freq * currentSec); buf[i] += (short)val; } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (ToggleButton)findViewById(R.id.button01); mButton01.setOnClickListener(this); mEditText01 = (EditText)findViewById(R.id.editText01); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mPlayBuf1 = new short[ELMS_1SEC]; mPlayBuf2 = new short[ELMS_1SEC]; mPlayBuf3 = new short[ELMS_1SEC]; createSineWave(mPlayBuf1, FREQ_LOW, AMP, true); // Low createSineWave(mPlayBuf2, FREQ_HI, AMP, true); // Hi createSineWave(mPlayBuf3, FREQ_END, AMP, true); // END // 再生用 mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLE_RATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes, AudioTrack.MODE_STREAM); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioTrack != null) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioTrack"); mAudioTrack.stop(); mAudioTrack.flush(); } mAudioTrack = null; } } @Override public void onClick(View v) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { mAudioTrack.stop(); mAudioTrack.flush(); } if (mButton01.isChecked()) { mText = mEditText01.getText().toString(); if (mText.length() > 0) { new Thread(this).start(); } else { mButton01.setChecked(false); } } } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_PLAY_START: Log.d(TAG, "MSG_PLAY_START"); break; case MSG_PLAY_END: Log.d(TAG, "MSG_PLAY_END"); mButton01.setChecked(false); break; } return true; } @Override public void run() { mHandler.sendEmptyMessage(MSG_PLAY_START); byte[] strByte = null; try { strByte = mText.getBytes("UTF-8"); } catch (UnsupportedEncodingException e) { } mAudioTrack.play(); for (int i = 0; i < strByte.length; i++) { valueToWave(strByte[i]); } valueToWave((byte) 0x20); // ダミー mAudioTrack.write(mPlayBuf3, 0, ELMS_1SEC); // 終端 mAudioTrack.stop(); mAudioTrack.flush(); mHandler.sendEmptyMessage(MSG_PLAY_END); } // 指定されたバイト値を音声信号に置き換えて再生する private void valueToWave(byte val) { for (int i = 0; i < BITS.length; i++) { // ビットごとに Hi, Low を出力 mAudioTrack.write(((val & BITS[i]) != 0) ? mPlayBuf2 : mPlayBuf1, 0, ELMS_100MSEC); } } }
受信側： sonic06
- MainActivity.java
/** * * sonic06 * * 端末のマイクから集音した信号をバイトデータに変換する * Lo -> 8000Hz, Hi -> 10000Hz * FFT 処理に JTransforms ライブラリを利用 * 対向の送信プログラムは sonic05 * */ package jp.klab.sonic06; import org.jtransforms.fft.DoubleFFT_1D; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.MediaRecorder; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.TextView; import java.io.UnsupportedEncodingException; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final short THRESHOLD_SILENCE = 0x00ff; private static final int FREQ_LOW = 8000; private static final int FREQ_HI = 10000; private static final int MSG_RECORD_START = 100; private static final int MSG_RECORD_END = 110; private static final int MSG_DATA_RECV = 130; private static final byte [] BITS = new byte [] { (byte)0x80, (byte)0x40, (byte)0x20, (byte)0x10, (byte)0x08, (byte)0x04, (byte)0x02, (byte)0x01}; private Handler mHandler; private AudioRecord mAudioRecord = null; private Button mButton01; private TextView mTextView02; private boolean mInRecording = false; private boolean mStop = false; private int mBufferSizeInShort; private short mRecordBuf[]; private short mTestBuf[]; private DoubleFFT_1D mFFT; private double mFFTBuffer[]; private int mFFTSize; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (Button)findViewById(R.id.button01); mButton01.setOnClickListener(this); mTextView02 = (TextView)findViewById(R.id.textView02); mTextView02.setOnClickListener(this); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mBufferSizeInShort = bufferSizeInBytes / 2; // 録音用バッファ mRecordBuf = new short[mBufferSizeInShort]; // FFT 処理用 mTestBuf = new short[SAMPLE_RATE/10]; // 100msec mFFTSize = mBufferSizeInShort; mFFT = new DoubleFFT_1D(mFFTSize); mFFTBuffer = new double[mFFTSize]; mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); mStop = true; try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioRecord != null) { if (mAudioRecord.getRecordingState() != AudioRecord.RECORDSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioRecord"); mAudioRecord.stop(); } mAudioRecord = null; } } @Override public void onClick(View v) { if (v == (View)mButton01) { // 集音開始 or 終了 if (!mInRecording) { mInRecording = true; new Thread(this).start(); } else { mInRecording = false; } } else if (v == (View)mTextView02) { // 表示データをクリア mTextView02.setText(""); } return; } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_RECORD_START: Log.d(TAG, "MSG_RECORD_START"); mButton01.setText("STOP"); break; case MSG_RECORD_END: Log.d(TAG, "MSG_RECORD_END"); mButton01.setText("START"); break; case MSG_DATA_RECV: //Log.d(TAG, "MSG_DATA_RECV"); byte[] ch = new byte[] {(byte)msg.arg1}; try { // 受信データを表示 String s = new String(ch, "UTF-8"); s = mTextView02.getText() + s; mTextView02.setText(s); } catch (UnsupportedEncodingException e) { } break; } return true; } @Override public void run() { int dataCount = 0; int bitCount = 0; byte val = 0; boolean bSilence = false; mHandler.sendEmptyMessage(MSG_RECORD_START); // 集音開始 mAudioRecord.startRecording(); while (mInRecording && !mStop) { // 音声データ読み込み mAudioRecord.read(mRecordBuf, 0, mBufferSizeInShort); bSilence = true; for (int i = 0; i < mBufferSizeInShort; i++) { short s = mRecordBuf[i]; if (s > THRESHOLD_SILENCE) { bSilence = false; } } if (bSilence) { // 静寂 dataCount = bitCount = 0; continue; } int copyLength = 0; // データを mTestBuf へ順次アペンド if (dataCount < mTestBuf.length) { // mTestBuf の残領域に応じてコピーするサイズを決定 int remain = mTestBuf.length - dataCount; if (remain > mBufferSizeInShort) { copyLength = mBufferSizeInShort; } else { copyLength = remain; } System.arraycopy(mRecordBuf, 0, mTestBuf, dataCount, copyLength); dataCount += copyLength; } if (dataCount >= mTestBuf.length) { byte ret = doFFT(mTestBuf); //Log.d(TAG, "ret=" + ret); if (ret == -1) { // FREQ_LOW, FREQ_HI 以外の周波数の場合 dataCount = bitCount = 0; continue; } else { // バイトデータを順次構成 if (bitCount == 0) { val = 0; } val |= (ret == 1) ? BITS[bitCount] : 0; if (bitCount < 7) { bitCount++; } else { // 1バイト分完了 bitCount = 0; Message msg = new Message(); msg.what = MSG_DATA_RECV; msg.arg1 = (int) val; mHandler.sendMessage(msg); } } dataCount = 0; // mRecordBuf の途中までを mTestBuf へコピーして FFT した場合は // mRecordBuf の残データを mTestBuf 先頭へコピーした上で継続 if (copyLength < mBufferSizeInShort) { int startPos = copyLength; copyLength = mBufferSizeInShort - copyLength; System.arraycopy(mRecordBuf, startPos, mTestBuf, 0, copyLength); dataCount += copyLength; } } } // 録音終了 mAudioRecord.stop(); mHandler.sendEmptyMessage(MSG_RECORD_END); } private byte doFFT(short[] data) { for (int i = 0; i < mFFTSize; i++) { mFFTBuffer[i] = (double)data[i]; } mFFT.realForward(mFFTBuffer); // 処理結果の複素数配列からピーク周波数成分の要素番号を得る double maxAmp = 0; int index = 0; for (int i = 0; i < mFFTSize/2; i++) { double a = mFFTBuffer[i*2]; // 実部 double b = mFFTBuffer[i*2 + 1]; // 虚部 // a+ib の絶対値 √ a^2 + b^2 = r が振幅値 double r = Math.sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } // ピーク周波数を求める int freq = index * SAMPLE_RATE / mFFTSize; return (byte)((freq == FREQ_LOW) ? 0 : (freq == FREQ_HI) ? 1 : -1); } }
周波数切り替え箇所の波形を見る
信号中の Lo（8000Hz）から Hi（10000Hz）、Hi から Lo への切り替え部分の波形の確認を行いました。
Lo, Hi ともに 10 で割り切れる周波数なので、先頭から 100ミリ秒後の位置での運動円上の Y 座標は 1秒後の位置と等しく 0 であり、そこに同じく Y=0 始まりの別の周期のサイン波を接合しても位相の不連続は発生しないはずです。 （ただし周期の違いが継ぎ目前後のカーブの形状の違いとして表れるため波形として完璧ではないでしょう）
以下は送信側アプリからの信号出力を PC に接続したマイクから取り込んだ Audacity のスクリーンショットです。
Lo -> Hi 部分のズーム
後続の Hi -> Lo 部分を同様にズーム
2. ビットデータを音声信号で送受信する 2
上の最初の試作ではまず音によるデータの送受信自体が可能であることを確認しましたが、動作が不安定で何より通信の遅さが目につきます。この点について考えてみます。
伝送効率改善の考え方
効率を改善するために伝達する情報の内容に手を加えることにしました。1バイト分のキャラクタデータをビットごとに 0,1 を表わすふたつの周波数の波の羅列で表現するのではなく、256種類の周波数を用いて直接 0x00 〜 0xFF を表現する形にすれば理論上伝送効率が 8倍向上するはずです。これを具体化してみることにします。
試作
処理のイメージ
以下の要領で実装を行いました。
- 送信側はバイト値 0x00 〜 0xFF を 400Hz 〜 5500Hz の 20Hz 刻みの 256 パターンの周波数から成る音声信号に変調する
- 受信側は「（検知したピーク周波数 - 400）/ 20」の平易な計算で元のバイト値へ復号する
- アプリの UI は最初の試作と同じ
動作の様子
動画： 1分 ※音量注意！
ソースコード
送信側： sonic07 GitHub
- MainActivity.java
/** * sonic07 * * 文字列をサイン波信号に置き換えて出力する * 伝送効率改善版 * 対向の受信プログラムは sonic08 * */ package jp.klab.sonic07; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.AudioManager; import android.media.AudioTrack; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.EditText; import android.widget.ToggleButton; import java.io.UnsupportedEncodingException; import java.util.Arrays; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final float SEC_PER_SAMPLEPOINT = 1.0f / SAMPLE_RATE; private static final int AMP = 4000; private static final int FREQ_BASE = 400; private static final int FREQ_STEP = 20; private static final int FREQ_KEY = 300; private static final int ELMS_1SEC = SAMPLE_RATE; private static final int ELMS_100MSEC = SAMPLE_RATE/10; private static final int ELMS_MAX = 256; private static final int MSG_PLAY_START = 120; private static final int MSG_PLAY_END = 130; private Handler mHandler; private AudioTrack mAudioTrack = null; private ToggleButton mButton01; private EditText mEditText01; private short mPlayBuf[] = new short[SAMPLE_RATE]; private short mSignals[][] = new short[ELMS_MAX][SAMPLE_RATE/10]; private String mText; // サイン波データを生成 private void createSineWave(short[] buf, int freq, int amplitude, boolean doClear) { if (doClear) { Arrays.fill(buf, (short) 0); } for (int i = 0; i < buf.length; i++) { float currentSec = i * SEC_PER_SAMPLEPOINT; // 現在位置の経過秒数 double val = amplitude * Math.sin(2.0 * Math.PI * freq * currentSec); buf[i] += (short)val; } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (ToggleButton)findViewById(R.id.button01); mButton01.setOnClickListener(this); mEditText01 = (EditText)findViewById(R.id.editText01); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); // 先頭・終端の目印用信号データ createSineWave(mPlayBuf, FREQ_KEY, AMP, true); // 256種類の信号データを生成 for (int i = 0; i < ELMS_MAX; i++) { createSineWave(mSignals[i], (short) (FREQ_BASE + FREQ_STEP*i), AMP, true); } // 再生用 mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLE_RATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes, AudioTrack.MODE_STREAM); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioTrack != null) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioTrack"); mAudioTrack.stop(); mAudioTrack.flush(); } mAudioTrack = null; } } @Override public void onClick(View v) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { mAudioTrack.stop(); mAudioTrack.flush(); } if (mButton01.isChecked()) { mText = mEditText01.getText().toString(); if (mText.length() > 0) { new Thread(this).start(); } else { mButton01.setChecked(false); } } } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_PLAY_START: Log.d(TAG, "MSG_PLAY_START"); break; case MSG_PLAY_END: Log.d(TAG, "MSG_PLAY_END"); mButton01.setChecked(false); break; } return true; } @Override public void run() { mHandler.sendEmptyMessage(MSG_PLAY_START); byte[] strByte = null; try { strByte = mText.getBytes("UTF-8"); } catch (UnsupportedEncodingException e) { } mAudioTrack.play(); mAudioTrack.write(mPlayBuf, 0, ELMS_1SEC); // 開始 for (int i = 0; i < strByte.length; i++) { valueToWave(strByte[i]); } mAudioTrack.write(mPlayBuf, 0, ELMS_1SEC); // 終端 mAudioTrack.stop(); mAudioTrack.flush(); mHandler.sendEmptyMessage(MSG_PLAY_END); } // 指定されたバイト値を音声信号に置き換えて再生する private void valueToWave(byte val) { mAudioTrack.write(mSignals[val], 0, ELMS_100MSEC); } }
受信側： sonic08 GitHub
- MainActivity.java
/** * sonic08 * * 端末のマイクから集音した信号をバイトデータに変換する * 伝送効率改善版 * FFT 処理に JTransforms ライブラリを利用 * 対向の送信プログラムは sonic07 * */ package jp.klab.sonic08; import org.jtransforms.fft.DoubleFFT_1D; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.MediaRecorder; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.TextView; import java.io.UnsupportedEncodingException; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final short THRESHOLD_SILENCE = 0x00ff; private static final int FREQ_BASE = 400; private static final int FREQ_STEP = 20; private static final int FREQ_MAX = 400 + 255 * 20; private static final int UNITSIZE = SAMPLE_RATE/10; // 100msec分 private static final int MSG_RECORD_START = 100; private static final int MSG_RECORD_END = 110; private static final int MSG_DATA_RECV = 120; private Handler mHandler; private AudioRecord mAudioRecord = null; private Button mButton01; private TextView mTextView02; private boolean mInRecording = false; private boolean mStop = false; private int mBufferSizeInShort; private short mRecordBuf[]; private short mTestBuf[]; private DoubleFFT_1D mFFT; private double mFFTBuffer[]; private int mFFTSize; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (Button)findViewById(R.id.button01); mButton01.setOnClickListener(this); mTextView02 = (TextView)findViewById(R.id.textView02); mTextView02.setOnClickListener(this); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mBufferSizeInShort = bufferSizeInBytes / 2; // 集音用バッファ mRecordBuf = new short[mBufferSizeInShort]; // FFT 処理用 mTestBuf = new short[UNITSIZE]; mFFTSize = UNITSIZE; mFFT = new DoubleFFT_1D(mFFTSize); mFFTBuffer = new double[mFFTSize]; mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); mStop = true; try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioRecord != null) { if (mAudioRecord.getRecordingState() != AudioRecord.RECORDSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioRecord"); mAudioRecord.stop(); } mAudioRecord = null; } } @Override public void onClick(View v) { if (v == (View)mButton01) { // 集音開始 or 終了 if (!mInRecording) { mInRecording = true; new Thread(this).start(); } else { mInRecording = false; } } else if (v == (View)mTextView02) { // 表示データをクリア mTextView02.setText(""); } return; } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_RECORD_START: Log.d(TAG, "MSG_RECORD_START"); mButton01.setText("STOP"); break; case MSG_RECORD_END: Log.d(TAG, "MSG_RECORD_END"); mButton01.setText("START"); break; case MSG_DATA_RECV: //Log.d(TAG, "MSG_DATA_RECV"); byte[] ch = new byte[] {(byte)msg.arg1}; try { // 受信データを表示 String s = new String(ch, "UTF-8"); s = mTextView02.getText() + s; mTextView02.setText(s); } catch (UnsupportedEncodingException e) { } break; } return true; } @Override public void run() { int dataCount = 0; boolean bSilence = false; mHandler.sendEmptyMessage(MSG_RECORD_START); // 集音開始 mAudioRecord.startRecording(); while (mInRecording && !mStop) { // 音声データ読み込み mAudioRecord.read(mRecordBuf, 0, mBufferSizeInShort); bSilence = true; for (int i = 0; i < mBufferSizeInShort; i++) { short s = mRecordBuf[i]; if (s > THRESHOLD_SILENCE) { bSilence = false; } } if (bSilence) { // 静寂 dataCount = 0; continue; } int copyLength = 0; // データを mTestBuf へ順次アペンド if (dataCount < mTestBuf.length) { // mTestBuf の残領域に応じてコピーするサイズを決定 int remain = mTestBuf.length - dataCount; if (remain > mBufferSizeInShort) { copyLength = mBufferSizeInShort; } else { copyLength = remain; } System.arraycopy(mRecordBuf, 0, mTestBuf, dataCount, copyLength); dataCount += copyLength; } if (dataCount >= mTestBuf.length) { // 100ms 分溜まったら FFT にかける int freq = doFFT(mTestBuf); // 待ってた範囲の周波数かチェック if (freq >= FREQ_BASE && freq <= FREQ_MAX) { int val = (int) ((freq - FREQ_BASE) / FREQ_STEP); if (val >= 0 && val <= 255) { Message msg = new Message(); msg.what = MSG_DATA_RECV; msg.arg1 = val; mHandler.sendMessage(msg); } else { freq = -1; } } else { freq = -1; } dataCount = 0; if (freq == -1) { continue; } // mRecordBuf の途中までを mTestBuf へコピーして FFT した場合は // mRecordBuf の残データを mTestBuf 先頭へコピーした上で継続 if (copyLength < mBufferSizeInShort) { int startPos = copyLength; copyLength = mBufferSizeInShort - copyLength; System.arraycopy(mRecordBuf, startPos, mTestBuf, 0, copyLength); dataCount += copyLength; } } } // 集音終了 mAudioRecord.stop(); mHandler.sendEmptyMessage(MSG_RECORD_END); } private int doFFT(short[] data) { for (int i = 0; i < mFFTSize; i++) { mFFTBuffer[i] = (double)data[i]; } // FFT 実行 mFFT.realForward(mFFTBuffer); // 処理結果の複素数配列からピーク周波数成分の要素番号を得る double maxAmp = 0; int index = 0; for (int i = 0; i < mFFTSize/2; i++) { double a = mFFTBuffer[i*2]; // 実部 double b = mFFTBuffer[i*2 + 1]; // 虚部 // a+ib の絶対値 √ a^2 + b^2 = r が振幅値 double r = Math.sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } // ピーク周波数を求める int freq = index * SAMPLE_RATE / mFFTSize; //Log.d(TAG, "peak=" + freq + "Hz"); return freq; } }
3. ビットデータを音声信号で送受信する 3
伝送効率の改善に続き、次の要素に目を向けてみます。
- 誤り発生への対処
- 超音波の利用
誤り発生への対処について
他の通信方法と同様に、音波による通信においても送受信の際に何らかの理由でデータに誤りが発生する可能性があります。この問題への対処について考えてみます。
まず誤りを検出可能であること、さらに、自動的にデータを訂正することができれば理想的でしょう。しかしながら、誤り訂正を実現するためには何らかの形でデータの冗長化が必須となり必然的に伝送効率とのトレードオフとなります。冗長化されたより大きなデータを授受することで自動訂正実現の可能性向上を選択すべきか？あるいは、誤り有無判定のみを可能とするスリムなデータを短時間で授受することを旨とするか？
たとえば、プライベートな環境での音波通信の応用を想定すると、エラー発生に気づいた利用者が自発的に送受信を再試行するのはごく普通の自然な流れです。この場面では訂正機能よりもすみやかに通信が行われることのほうが求められるでしょう。また、パブリックな空間でのビーコン系サービスにおいては送り手が同一の情報を所定の期間何度も繰り返し発信する（それもまた単方向通信であることに起因）ことが一般的なので受け手には情報取得に成功するまで何度もチャンスが提供されます。
このように考えると、ここでは誤り訂正のための機構は現在の話題に不可欠の要素ではなく、むしろ誤りの検出までが重要であることが見えてきます。
超音波の利用について
ここまでの試作では開発上の便宜から可聴音域の信号で通信を行ってきました。
「音を利用する 1」冒頭の「はじめに」の項でも触れたように、音声信号を利用する際の音域の選定は環境や使途とのかねあいによって単に適材適所で判断されるべきはずのものですが、そのこととはあまり関係なく洋の東西を問わず「超音波」「Ultrasonic」は人気がありますね。そろそろこのあたりで従来の可聴音に加え超音波も扱ってみることにします。
試作
処理のイメージ
以下の要領で実装を行いました。
「超音波モード」を追加。
- 送信側は所定のバイト値 0x00 〜 0xFF を以下の周波数域で構成される音声信号に変調する
（前項のふたつめの試作では 20Hz刻みとしたが 10Hz刻みでも性能上の支障が見られないため帯域幅を節約）- 可聴音モード：500Hz 〜 3050Hz（10Hz 刻み）
- 超音波モード：14000Hz 〜 16550Hz（10Hz 刻み）
- 可聴音モード：500Hz 〜 3050Hz（10Hz 刻み）
発信する音声信号の先頭と終端に目印として上図の範囲に含まれない所定の周波数の信号を 1秒間付与する。
- 先端符丁：各モードで使用する音域の先頭周波数 − 80Hz（＝420Hz,13920Hz）
- 終端符丁：各モードで使用する音域の先頭周波数 − 100Hz（＝400Hz, 13900Hz）
次の内容で誤り検出機構を追加。
- 送信側は先端符丁とデータ本体の間にデータの 32ビット CRC 計算結果（java.util.zip.CRC32 使用）を 4 * 100ミリ秒間発信する
- 受信側は先端符丁を検知すると上記 CRC 値を取得・復号して保持。終端符丁検出時に復号ずみデータ本体の CRC を計算し両者を比較することで誤りの可能性の有無を判定する
- データ本体の受け渡しに失敗したケースのみならず CRC 値の受け渡しに失敗のケースもありえるが、現時点では CRC 値情報授受の冗長化は考えず一律に「エラー」とみなす
- 左：送信側 右：受信側
両者とも「Ultrasonic」スイッチで超音波モードへ移行
動作の様子
動画： 1分19秒 ※音量注意！
ソースコード
送信側： sonic09 GitHub
- MainActivity.java
/** * sonic09 * * 文字列をサイン波信号に置き換えて出力する * 32ビットCRC付与, 超音波モード追加 * 対向の受信プログラムは sonic10 * */ package jp.klab.sonic09; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.AudioManager; import android.media.AudioTrack; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.CompoundButton; import android.widget.EditText; import android.widget.Switch; import android.widget.ToggleButton; import java.io.UnsupportedEncodingException; import java.util.Arrays; import java.util.zip.CRC32; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Switch.OnCheckedChangeListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final float SEC_PER_SAMPLEPOINT = 1.0f / SAMPLE_RATE; private static final int FREQ_BASE_LOW = 500; private static final int FREQ_BASE_HIGH = 14000; private static final int AMP_SMALL = 5000; private static final int AMP_LARGE = 28000; private static final int ELMS_1SEC = SAMPLE_RATE; private static final int ELMS_UNITSEC = SAMPLE_RATE/10; private static final int ELMS_MAX = 256; private static final int MSG_PLAY_START = 120; private static final int MSG_PLAY_END = 130; private int FREQ_STEP = 10; private int AMP; private int FREQ_BASE; private int FREQ_OUT; private int FREQ_IN; private Handler mHandler; private AudioTrack mAudioTrack = null; private ToggleButton mButton01; private EditText mEditText01; private Switch mSwitch01; private short mSigIn[] = new short[SAMPLE_RATE]; private short mSigOut[] = new short[SAMPLE_RATE]; private short mSignals[][] = new short[ELMS_MAX][ELMS_UNITSEC]; private String mText; // サイン波データを生成 private void createSineWave(short[] buf, int freq, int amplitude, boolean doClear) { if (doClear) { Arrays.fill(buf, (short) 0); } for (int i = 0; i < buf.length; i++) { float currentSec = i * SEC_PER_SAMPLEPOINT; // 現在位置の経過秒数 double val = amplitude * Math.sin(2.0 * Math.PI * freq * currentSec); buf[i] += (short)val; } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (ToggleButton)findViewById(R.id.button01); mButton01.setOnClickListener(this); mEditText01 = (EditText)findViewById(R.id.editText01); mSwitch01 = (Switch)findViewById(R.id.switch01); mSwitch01.setOnCheckedChangeListener(this); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); setParams(false); mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLE_RATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes, AudioTrack.MODE_STREAM); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioTrack != null) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioTrack"); mAudioTrack.stop(); mAudioTrack.flush(); } mAudioTrack = null; } } @Override public void onClick(View v) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { mAudioTrack.stop(); mAudioTrack.flush(); } if (mButton01.isChecked()) { mText = mEditText01.getText().toString(); if (mText.length() > 0) { new Thread(this).start(); } else { mButton01.setChecked(false); } } } @Override public void onCheckedChanged(CompoundButton b, boolean isChecked) { setParams(isChecked); } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_PLAY_START: Log.d(TAG, "MSG_PLAY_START"); break; case MSG_PLAY_END: Log.d(TAG, "MSG_PLAY_END"); mButton01.setChecked(false); break; } return true; } @Override public void run() { mHandler.sendEmptyMessage(MSG_PLAY_START); byte[] strByte = null; try { strByte = mText.getBytes("UTF-8"); } catch (UnsupportedEncodingException e) { } mAudioTrack.play(); mAudioTrack.write(mSigIn, 0, ELMS_1SEC); // 先端符丁 // データ本体の CRC32 を計算して発信 CRC32 crc = new CRC32(); crc.reset(); crc.update(strByte, 0, strByte.length); long crcVal = crc.getValue(); //Log.d(TAG, "crc=" + Long.toHexString(crcVal)); byte crcData[] = new byte[4]; for (int i = 0; i < 4; i++) { crcData[i] = (byte)(crcVal >> (24-i*8)); valueToWave((short) (crcData[i] & 0xFF)); } // データ本体 for (int i = 0; i < strByte.length; i++) { valueToWave(strByte[i]); } mAudioTrack.write(mSigOut, 0, ELMS_1SEC); // 終端符丁 mAudioTrack.stop(); mAudioTrack.flush(); mHandler.sendEmptyMessage(MSG_PLAY_END); } // 指定されたバイト値を音声信号に置き換えて再生する private void valueToWave(short val) { //Log.d(TAG, "val=" + val); mAudioTrack.write(mSignals[val], 0, ELMS_UNITSEC); } private void setParams(boolean useUltrasonic) { AMP = (useUltrasonic) ? AMP_LARGE : AMP_SMALL; FREQ_BASE = (useUltrasonic) ? FREQ_BASE_HIGH : FREQ_BASE_LOW; FREQ_OUT = FREQ_BASE - 100; FREQ_IN = FREQ_OUT + 20; // 先端・終端符丁の信号データを生成 createSineWave(mSigIn, FREQ_IN, AMP, true); createSineWave(mSigOut, FREQ_OUT, AMP, true); // 256種類の信号データを生成 for (int i = 0; i < ELMS_MAX; i++) { createSineWave(mSignals[i], (short) (FREQ_BASE + FREQ_STEP * i), AMP, true); } } }
受信側： sonic10 GitHub
- MainActivity.java
/** * sonic10 * * 端末のマイクから集音した信号をバイトデータに変換する * CRC32による誤り検出, 超音波モードへ対応 * FFT 処理に JTransforms ライブラリを利用 * 対向の送信プログラムは sonic09 * */ package jp.klab.sonic10; import org.jtransforms.fft.DoubleFFT_1D; import android.graphics.Color; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.MediaRecorder; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.CompoundButton; import android.widget.Switch; import android.widget.TextView; import java.io.UnsupportedEncodingException; import java.util.ArrayList; import java.util.zip.CRC32; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Switch.OnCheckedChangeListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final short THRESHOLD_SILENCE = 0x00ff; private static final int FREQ_BASE_LOW = 500; private static final int FREQ_BASE_HIGH = 14000; private static final int FREQ_STEP = 10; private static final int UNITSIZE = SAMPLE_RATE/10; // 100msec分 private static final int MSG_RECORD_START = 100; private static final int MSG_RECORD_END = 110; private static final int MSG_DATA_RECV = 120; private static final int MSG_RECV_OK = 200; private static final int MSG_RECV_NG = 210; private int FREQ_BASE = FREQ_BASE_LOW; private int FREQ_OUT = FREQ_BASE - 100; private int FREQ_IN = FREQ_OUT + 20; private int FREQ_MAX = FREQ_BASE + FREQ_STEP * 255; private Handler mHandler; private AudioRecord mAudioRecord = null; private Button mButton01; private TextView mTextView02; private TextView mTextView03; private Switch mSwitch01; private boolean mInRecording = false; private boolean mStop = false; private int mBufferSizeInShort; private short mRecordBuf[]; private short mTestBuf[]; private DoubleFFT_1D mFFT; private double mFFTBuffer[]; private int mFFTSize; private byte mValueCount = -1; private long mCrc32Val = 0; private String mRecvStr; private ArrayList<Byte> mDataArrayList = new ArrayList<Byte>(); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (Button)findViewById(R.id.button01); mButton01.setOnClickListener(this); mTextView02 = (TextView)findViewById(R.id.textView02); mTextView02.setOnClickListener(this); mTextView03 = (TextView)findViewById(R.id.textView03); mTextView03.setTextColor(Color.RED); mSwitch01 = (Switch)findViewById(R.id.switch01); mSwitch01.setOnCheckedChangeListener(this); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mBufferSizeInShort = bufferSizeInBytes / 2; // 集音用バッファ mRecordBuf = new short[mBufferSizeInShort]; // FFT 処理用 mTestBuf = new short[UNITSIZE]; mFFTSize = UNITSIZE; mFFT = new DoubleFFT_1D(mFFTSize); mFFTBuffer = new double[mFFTSize]; mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); mStop = true; try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioRecord != null) { if (mAudioRecord.getRecordingState() != AudioRecord.RECORDSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioRecord"); mAudioRecord.stop(); } mAudioRecord = null; } } @Override public void onClick(View v) { if (v == (View)mButton01) { // 集音開始 or 終了 if (!mInRecording) { mInRecording = true; new Thread(this).start(); } else { mInRecording = false; } } else if (v == (View)mTextView02) { // 表示データをクリア mTextView02.setText(""); mTextView03.setText(""); } return; } @Override public void onCheckedChanged(CompoundButton b, boolean isChecked) { if (b == (CompoundButton)mSwitch01) { FREQ_BASE = (isChecked) ? FREQ_BASE_HIGH : FREQ_BASE_LOW; FREQ_OUT = FREQ_BASE - 100; FREQ_IN = FREQ_OUT + 20; FREQ_MAX = FREQ_BASE + FREQ_STEP * 255; } } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_RECORD_START: Log.d(TAG, "MSG_RECORD_START"); mButton01.setText("STOP"); mSwitch01.setEnabled(false); break; case MSG_RECORD_END: Log.d(TAG, "MSG_RECORD_END"); mButton01.setText("START"); mSwitch01.setEnabled(true); break; case MSG_DATA_RECV: //Log.d(TAG, "MSG_DATA_RECV"); byte[] ch = new byte[] {(byte)msg.arg1}; try { // 受信データを表示 String s = new String(ch, "UTF-8"); s = mTextView02.getText() + s; mTextView02.setText(s); } catch (UnsupportedEncodingException e) { } mTextView03.setText(""); break; case MSG_RECV_OK: mTextView03.setText("OK!"); break; case MSG_RECV_NG: mTextView03.setText("NG!"); break; } return true; } @Override public void run() { int dataCount = 0; boolean bSilence = false; mHandler.sendEmptyMessage(MSG_RECORD_START); // 集音開始 mAudioRecord.startRecording(); while (mInRecording && !mStop) { // 音声データ読み込み mAudioRecord.read(mRecordBuf, 0, mBufferSizeInShort); bSilence = true; for (int i = 0; i < mBufferSizeInShort; i++) { short s = mRecordBuf[i]; if (s > THRESHOLD_SILENCE) { bSilence = false; } } if (bSilence) { // 静寂 dataCount = 0; continue; } int copyLength = 0; // データを mTestBuf へ順次アペンド if (dataCount < UNITSIZE) {//mTestBuf.length) { // mTestBuf の残領域に応じてコピーするサイズを決定 int remain = UNITSIZE - dataCount; if (remain > mBufferSizeInShort) { copyLength = mBufferSizeInShort; } else { copyLength = remain; } System.arraycopy(mRecordBuf, 0, mTestBuf, dataCount, copyLength); dataCount += copyLength; } if (dataCount >= UNITSIZE) {//mTestBuf.length) { // 100ms 分溜まったら FFT にかける int freq = doFFT(mTestBuf); if (mValueCount < 0) { // データ終了 if (freq == FREQ_OUT && mCrc32Val != 0) { byte check [] = new byte[mDataArrayList.size()]; for (int i = 0; i < check.length; i++) { check[i] = mDataArrayList.get(i); } CRC32 crc = new CRC32(); crc.reset(); crc.update(check, 0, check.length); long crcVal = crc.getValue(); Log.d(TAG, "crc check=" + Long.toHexString(crcVal)); if (crcVal == mCrc32Val) { mHandler.sendEmptyMessage(MSG_RECV_OK); } else { mHandler.sendEmptyMessage(MSG_RECV_NG); } mCrc32Val = 0; } } // 待ってた範囲の周波数かチェック if (freq >= FREQ_BASE && freq <= FREQ_MAX) { int val = (int) ((freq - FREQ_BASE) / FREQ_STEP); if (val >= 0 && val <= 255) { if (mValueCount > 4) { mDataArrayList.add((byte)val); Message msg = new Message(); msg.what = MSG_DATA_RECV; msg.arg1 = val; mHandler.sendMessage(msg); } } else { freq = -1; } } else { freq = -1; } dataCount = 0; if (freq == -1) { continue; } // mRecordBuf の途中までを mTestBuf へコピーして FFT した場合は // mRecordBuf の残データを mTestBuf 先頭へコピーした上で継続 if (copyLength < mBufferSizeInShort) { int startPos = copyLength; copyLength = mBufferSizeInShort - copyLength; System.arraycopy(mRecordBuf, startPos, mTestBuf, 0, copyLength); dataCount += copyLength; } } } // 集音終了 mAudioRecord.stop(); mHandler.sendEmptyMessage(MSG_RECORD_END); } private int doFFT(short[] data) { for (int i = 0; i < mFFTSize; i++) { mFFTBuffer[i] = (double)data[i]; } // FFT 実行 mFFT.realForward(mFFTBuffer); // 処理結果の複素数配列からピーク周波数成分の要素番号を得る double maxAmp = 0; int index = 0; for (int i = 0; i < mFFTSize/2; i++) { double a = mFFTBuffer[i*2]; // 実部 double b = mFFTBuffer[i*2 + 1]; // 虚部 // a+ib の絶対値 √ a^2 + b^2 = r が振幅値 double r = Math.sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } // ピーク周波数を求める int freq = index * SAMPLE_RATE / mFFTSize; byte val = (byte)((freq-FREQ_BASE)/FREQ_STEP); if (freq == FREQ_IN) { // 先端符丁 mValueCount = 0; mCrc32Val = 0; if (!mDataArrayList.isEmpty()) { mDataArrayList.clear(); } return freq; } else if (freq == FREQ_OUT) { // 終端符丁 mValueCount = -1; return freq; } // 先端符丁直後の 4バイトは32ビットCRC if (mValueCount >= 0 && mValueCount < 4) { mCrc32Val |= (val & 0xFF); if (mValueCount != 3) { mCrc32Val <<= 8; } else { Log.d(TAG, "mCrc32Val=" + Long.toHexString(mCrc32Val)); } } mValueCount++; return freq; } }
4. ビットデータを音声信号で送受信する 4
ここまでの試作では単方向の通信のみを扱ってきました。これは以下の理由によるものです。
- 集音・発音の両機能を混在させると自機の発した信号音による混乱が起こり得る
- 伝送が基本的に低速であるため機器間で相互に通信を行うなら双方の拘束時間が長くなることになり実用性を想定しにくい
- 双方向通信に伴いプロトコルが煩雑化することよりも単方向通信であることを活かせる用途を選ぶべき
これらはおそらく考え方として間違っていないように思いますが、一方で、二台の機器が相互に音で情報をやりとりする光景を想像すると理由のない好奇心をくすぐられます。そこで、実験の一環として最後にデバイス間の双方向通信を試すことにしました。
双方向通信を考える
双方向通信の方法として以下の内容を想定しました。
- 二台の機器間での相互通信を前提とする
- 双方とも同一のプログラムを使用する
- 上記 1. に挙げた混乱への懸念は半二重方式での実装により回避可能と考えられる
- 相互に先端符丁と終端符丁の検知によりデータを識別。それに呼応する内容で返信を行う
試作
処理のイメージ
以下の要領で実装を行いました。
- 機器間で自律的にある程度意味のある応酬を行わせるために英単語のしりとりを題材とした
ability -> yellow -> warn -> national .... の要領 - 機器間の応酬は自動化し最初の単語を発信するために初回のみ UI を操作する形とした
- 集音状態での待機中に先端符丁の信号音を検知したらデータ到着とみなし後続処理を開始。その後終端符丁を検知したら所定の時間間隔をおいて発信を行う。発信が完了したら集音状態での待機に戻る
- 受信・復号したデータの内容に誤りを検出した場合、「?」文字を発信することで相手に再送を要求する
- タイトル部分をタップすると最初の単語を発信。あとはエンドレス
動作の様子
動画： 1分29秒 ※音量注意！
ソースコード
sonic11 GitHub
- MainActivity.java
/** * * sonic11 * * サイン波音声信号による半二重式での双方向通信のしくみの試作 * 二台の機器間で「しりとり」を行う * FFT 処理に JTransforms ライブラリを利用 * */ package jp.klab.sonic11; import org.jtransforms.fft.DoubleFFT_1D; import android.graphics.Color; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.AudioManager; import android.media.AudioTrack; import android.media.MediaRecorder; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.CompoundButton; import android.widget.Switch; import android.widget.TextView; import java.io.UnsupportedEncodingException; import java.util.ArrayList; import java.util.Arrays; import java.util.zip.CRC32; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Switch.OnCheckedChangeListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final float SEC_PER_SAMPLEPOINT = 1.0f / SAMPLE_RATE; private static final short THRESHOLD_SILENCE = 0x00ff; private static final int THRESHOLD_COUNT_SILENCE = 25; // 無音区間判定用 private static final int FREQ_BASE_LOW = 500; private static final int FREQ_BASE_HIGH = 14000; private static final int AMP_SMALL = 28000; private static final int AMP_LARGE = 28000; private static final int ELMS_1SEC = SAMPLE_RATE; private static final int ELMS_UNITSEC = SAMPLE_RATE/10; private static final int ELMS_MAX = 256; private static final int FREQ_STEP = 10; private static final int UNITSIZE = SAMPLE_RATE/10; // 100msec分 private static final int MSG_RECORD_START = 100; private static final int MSG_RECORD_END = 110; private static final int MSG_DATA_RECV = 130; private static final int MSG_DATA_SEND_START = 140; private static final int MSG_RECV_OK = 200; private static final int MSG_RECV_NG = 210; private int AMP; private int FREQ_BASE; private int FREQ_OUT; private int FREQ_IN; private int FREQ_MAX = FREQ_BASE + FREQ_STEP * 255; private Handler mHandler; private AudioRecord mAudioRecord = null; private AudioTrack mAudioTrack = null; private Button mButton01; private TextView mTextView01; private TextView mTextView02; private TextView mTextView03; private TextView mTextView04; private Switch mSwitch01; private short mSigIn[] = new short[SAMPLE_RATE]; private short mSigOut[] = new short[SAMPLE_RATE]; private short mSignals[][] = new short[ELMS_MAX][SAMPLE_RATE/10]; private boolean mInRecording = false; private boolean mStop = false; private int mBufferSizeInShort; private short mRecordBuf[]; private short mTestBuf[]; private DoubleFFT_1D mFFT; private double mFFTBuffer[]; private int mFFTSize; private byte mValueCount = -1; private long mCrc32Val = 0; private ArrayList<Byte> mDataArrayList = new ArrayList<Byte>(); private int mLastFreq; private String mRecvWord = ""; private String mSendWord = ""; private boolean mRecvOK; // サイン波データを生成 private void createSineWave(short[] buf, int freq, int amplitude, boolean doClear) { if (doClear) { Arrays.fill(buf, (short) 0); } for (int i = 0; i < buf.length; i++) { float currentSec = i * SEC_PER_SAMPLEPOINT; // 現在位置の経過秒数 double val = amplitude * Math.sin(2.0 * Math.PI * freq * currentSec); buf[i] += (short)val; } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (Button)findViewById(R.id.button01); mButton01.setOnClickListener(this); mTextView01 = (TextView)findViewById(R.id.textView01); mTextView01.setOnClickListener(this); mTextView02 = (TextView)findViewById(R.id.textView02); mTextView02.setOnClickListener(this); mTextView03 = (TextView)findViewById(R.id.textView03); mTextView03.setTextColor(Color.RED); mTextView04 = (TextView)findViewById(R.id.textView04); mSwitch01 = (Switch)findViewById(R.id.switch01); mSwitch01.setOnCheckedChangeListener(this); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mBufferSizeInShort = bufferSizeInBytes / 2; // 集音用バッファ mRecordBuf = new short[mBufferSizeInShort]; // FFT 処理用 mTestBuf = new short[UNITSIZE]; mFFTSize = UNITSIZE; mFFT = new DoubleFFT_1D(mFFTSize); mFFTBuffer = new double[mFFTSize]; mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes); mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLE_RATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes, AudioTrack.MODE_STREAM); setParams(false); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); mStop = true; try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioRecord != null) { if (mAudioRecord.getRecordingState() != AudioRecord.RECORDSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioRecord"); mAudioRecord.stop(); } mAudioRecord = null; } if (mAudioTrack != null) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioTrack"); mAudioTrack.stop(); mAudioTrack.flush(); } mAudioTrack = null; } } @Override public void onClick(View v) { if (v == (View)mButton01) { // 集音開始 or 終了 if (!mInRecording) { mInRecording = true; new Thread(this).start(); } else { mInRecording = false; } } else if (v == (View)mTextView01) { // しりとりの開始・再開 // すでに集音中なら自分で自分の音を拾わないように // スレッドを一旦終了 boolean running = mInRecording; if (mInRecording) { mStop = true; try { while (mInRecording) { Thread.sleep(100); } } catch (InterruptedException e) { } } // ランダムに選んだ英単語を音で発信 mSendWord = words.getWord(); doSendWord(mSendWord); if (running) { // 集音スレッド再稼働 mInRecording = true; mStop = false; new Thread(this).start(); } } else if (v == (View)mTextView02) { mTextView02.setText(""); mTextView03.setText(""); } return; } @Override public void onCheckedChanged(CompoundButton b, boolean isChecked) { if (b == (CompoundButton)mSwitch01) { setParams(isChecked); } } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_RECORD_START: Log.d(TAG, "MSG_RECORD_START"); mButton01.setText("STOP"); mSwitch01.setEnabled(false); break; case MSG_RECORD_END: Log.d(TAG, "MSG_RECORD_END"); mButton01.setText("START"); mSwitch01.setEnabled(true); break; case MSG_DATA_RECV: //Log.d(TAG, "MSG_DATA_RECV"); if (mRecvWord.length() <= 0) { mTextView02.setText("RECV: "); } byte[] ch = new byte[] {(byte)msg.arg1}; try { // 受信データを表示 String s = new String(ch, "UTF-8"); mRecvWord += s; s = mTextView02.getText() + s; mTextView02.setText(s); } catch (UnsupportedEncodingException e) { } mTextView03.setText(""); break; case MSG_DATA_SEND_START: mTextView04.setText("SEND: " + mSendWord); break; case MSG_RECV_OK: mTextView03.setText("OK!"); break; case MSG_RECV_NG: mTextView03.setText("NG!"); break; } return true; } @Override public void run() { int dataCount = 0; boolean bSilence = false; long countSilence = 0; mHandler.sendEmptyMessage(MSG_RECORD_START); // 集音開始 mAudioRecord.startRecording(); while (mInRecording && !mStop) { // 音声信号読み込み mAudioRecord.read(mRecordBuf, 0, mBufferSizeInShort); bSilence = true; for (int i = 0; i < mBufferSizeInShort; i++) { short s = mRecordBuf[i]; if (s > THRESHOLD_SILENCE) { bSilence = false; break; } } if (bSilence) { // 静寂 dataCount = 0; countSilence++; } else { countSilence = 0; } // 単語を受信ずみかつ一定期間以上静寂が続いたら送信にまわる if (countSilence > THRESHOLD_COUNT_SILENCE && mLastFreq == FREQ_OUT && mRecvWord.length() > 0) { if (mRecvOK) { // 直前の受信・復号結果が正常だった if (!mRecvWord.equals("?")) { // 受信した単語のしりとり語を取得 mSendWord = words.getWord(mRecvWord); } } else { // 再送要求 mSendWord = "?"; } Log.d(TAG, "mSendWord=" + mSendWord); // 単語を発信 doSendWord(mSendWord); continue; } int copyLength = 0; // データを mTestBuf へ順次アペンド if (dataCount < UNITSIZE) { // mTestBuf の残領域に応じてコピーするサイズを決定 int remain = UNITSIZE - dataCount; if (remain > mBufferSizeInShort) { copyLength = mBufferSizeInShort; } else { copyLength = remain; } System.arraycopy(mRecordBuf, 0, mTestBuf, dataCount, copyLength); dataCount += copyLength; } if (dataCount >= UNITSIZE) { // 100ms 分溜まったら FFT にかける int freq = doFFT(mTestBuf); mLastFreq = freq; if (mValueCount < 0) { // データ終了 if (freq == FREQ_OUT && mCrc32Val != 0) { byte check [] = new byte[mDataArrayList.size()]; for (int i = 0; i < check.length; i++) { check[i] = mDataArrayList.get(i); } //Log.d(TAG, "mRecvWord=" + mRecvWord); CRC32 crc = new CRC32(); crc.reset(); crc.update(check, 0, check.length); long crcVal = crc.getValue(); //Log.d(TAG, "crc check=" + Long.toHexString(crcVal)); mRecvOK = false; if (crcVal == mCrc32Val) { mRecvOK = true; mHandler.sendEmptyMessage(MSG_RECV_OK); } else { mHandler.sendEmptyMessage(MSG_RECV_NG); } mCrc32Val = 0; } } // 待ってた範囲の周波数かチェック if (freq >= FREQ_BASE && freq <= FREQ_MAX) { int val = (int) ((freq - FREQ_BASE) / FREQ_STEP); if (val >= 0 && val <= 255) { if (mValueCount > 4) { mDataArrayList.add((byte)val); Message msg = new Message(); msg.what = MSG_DATA_RECV; msg.arg1 = val; mHandler.sendMessage(msg); } } else { freq = -1; } } else { freq = -1; } dataCount = 0; if (freq == -1) { continue; } // mRecordBuf の途中までを mTestBuf へコピーして FFT した場合は // mRecordBuf の残データを mTestBuf 先頭へコピーした上で継続 if (copyLength < mBufferSizeInShort) { int startPos = copyLength; copyLength = mBufferSizeInShort - copyLength; System.arraycopy(mRecordBuf, startPos, mTestBuf, 0, copyLength); dataCount += copyLength; } } } // 集音終了 mAudioRecord.stop(); mInRecording = false; mHandler.sendEmptyMessage(MSG_RECORD_END); } private int doFFT(short[] data) { for (int i = 0; i < mFFTSize; i++) { mFFTBuffer[i] = (double)data[i]; } // FFT 実行 mFFT.realForward(mFFTBuffer); // 処理結果の複素数配列からピーク周波数成分の要素番号を得る double maxAmp = 0; int index = 0; for (int i = 0; i < mFFTSize/2; i++) { double a = mFFTBuffer[i*2]; // 実部 double b = mFFTBuffer[i*2 + 1]; // 虚部 // a+ib の絶対値 √ a^2 + b^2 = r が振幅値 double r = Math.sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } // ピーク周波数を求める int freq = index * SAMPLE_RATE / mFFTSize; byte val = (byte)((freq-FREQ_BASE)/FREQ_STEP); if (freq == FREQ_IN) { // 先端符丁 mValueCount = 0; mCrc32Val = 0; if (!mDataArrayList.isEmpty()) { mDataArrayList.clear(); } mRecvWord = ""; return freq; } else if (freq == FREQ_OUT) { // 終端符丁 mValueCount = -1; return freq; } // 先端符丁直後の 4バイトは32ビットCRC if (mValueCount >= 0 && mValueCount < 4) { mCrc32Val |= (val & 0xFF); if (mValueCount != 3) { mCrc32Val <<= 8; } else { Log.d(TAG, "mCrc32Val=" + Long.toHexString(mCrc32Val)); } } mValueCount++; return freq; } // 指定されたバイト値を音声信号に置き換えて再生する private void valueToWave(short val) { //Log.d(TAG, "val=" + val); mAudioTrack.write(mSignals[val], 0, ELMS_UNITSEC); } private void doSendWord(String str) { mSendWord = str; mHandler.sendEmptyMessage(MSG_DATA_SEND_START); Log.d(TAG, "mSendWord=" + mSendWord); byte[] strByte = null; try { strByte = mSendWord.getBytes("UTF-8"); } catch (UnsupportedEncodingException e) { } mAudioTrack.play(); mAudioTrack.write(mSigIn, 0, ELMS_1SEC); // 先端符丁 // データ本体の CRC32 を計算して発信 CRC32 crc = new CRC32(); crc.reset(); crc.update(strByte, 0, strByte.length); long crcVal = crc.getValue(); //Log.d(TAG, "crc=" + Long.toHexString(crcVal)); byte crcData[] = new byte[4]; for (int i = 0; i < 4; i++) { crcData[i] = (byte)(crcVal >> (24-i*8)); valueToWave((short) (crcData[i] & 0xFF)); } // データ本体 for (int i = 0; i < strByte.length; i++) { valueToWave(strByte[i]); } mAudioTrack.write(mSigOut, 0, ELMS_1SEC); // 終端符丁 mAudioTrack.stop(); mAudioTrack.flush(); mLastFreq = -1; mRecvWord = ""; } private void setParams(boolean useUltrasonic) { AMP = (useUltrasonic) ? AMP_LARGE : AMP_SMALL; FREQ_BASE = (useUltrasonic) ? FREQ_BASE_HIGH : FREQ_BASE_LOW; FREQ_OUT = FREQ_BASE - 100; FREQ_IN = FREQ_OUT + 20; // 先端・終端符丁の信号データを生成 createSineWave(mSigIn, FREQ_IN, AMP, true); createSineWave(mSigOut, FREQ_OUT, AMP, true); // 256種類の信号データを生成 for (int i = 0; i < ELMS_MAX; i++) { createSineWave(mSignals[i], (short) (FREQ_BASE + FREQ_STEP * i), AMP, true); } FREQ_MAX = FREQ_BASE + FREQ_STEP * 255; } }
(tanabe)
音を利用する 2 〜Android デバイスでの音波通信：準備編〜
この記事の内容
前回の記事では音を媒体とする機器間の情報通信が近年ふたたび注目されていることに触れ複数の具体的な事例を挙げました。近距離通信手段としての音波の利用には技術的好奇心をそそられますが、それをどのように形にすればよいのかは案外ピンと来ません。そこで、Android デバイスを題材に手元で行った音波通信の実験と試作の内容をこれから何回かに分けて紹介します。今回は準備編として実装に必要な要素の整理を行います。
2017-11-29 追記：本記事に掲載のコードは開発時に Android 5.x 環境を使用しており、Android 6.0 以降では android.permission.RECORD_AUDIO について実行時パーミッション取得が必要です。
- 実行時のパーミッション リクエスト - developer.android.com
- Support Library - 下位互換性 - developer.android.com
他のプロジェクトについても適宜加味して下さい。
準備 1. Andorid での音声入出力処理を覚える
プラットフォームにより開発環境や API に違いはあっても音を扱う処理の本質は変わりません。手元でターゲットとして Android を選んだのは以下の理由によるものです。
- メジャーである
- サウンド I/O を標準で利用できる（マイコン系と比べての利点）
- ポータブルであるため応用が利きやすく IoT 方面との連携性も良い（PC と比べての利点）
- 開発環境の制約ごとが相対的に少ない（他のスマホ系と比べての利点）
まず、今回使用した音声入出力 API の情報をリファレンスより引用します。特に難しい要素もなく分かりやすい内容でした。
入力：AudioRecord クラス
- AudioRecord
The AudioRecord class manages the audio resources for Java applications to record audio from the audio input hardware of the platform.
:
Upon creation, an AudioRecord object initializes its associated audio buffer that it will fill with the new audio data.
:
Data should be read from the audio hardware in chunks of sizes inferior to the total recording buffer size.- AudioRecord (constructor)
AudioRecord (int audioSource,
int sampleRateInHz,
int channelConfig,
int audioFormat,
int bufferSizeInBytes)
:
Parameters
:
bufferSizeInBytes
int: the total size (in bytes) of the buffer where audio data is written to during the recording. New audio data can be read from this buffer in smaller chunks than this size. See getMinBufferSize(int, int, int) to determine the minimum required buffer size for the successful creation of an AudioRecord instance. Using values smaller than getMinBufferSize() will result in an initialization failure. - getMinBufferSize
int getMinBufferSize (
int sampleRateInHz,
int channelConfig,
int audioFormat)
Returns the minimum buffer size required for the successful creation of an AudioRecord object, in byte units.
:
- startRecording
void startRecording ()
Starts recording from the AudioRecord instance. - read
int read (short[] audioData,
int offsetInShorts,
int sizeInShorts)
Reads audio data from the audio hardware for recording into a short array. The format specified in the AudioRecord constructor should be ENCODING_PCM_16BIT to correspond to the data in the array.
:
- getRecordingState
int getRecordingState ()
Returns the recording state of the AudioRecord instance.
See also:
RECORDSTATE_STOPPED
RECORDSTATE_RECORDING
- stop
void stop ()
Stops recording.
- AudioRecord (constructor)
出力：AudioTrack クラス
- AudioTrack
The AudioTrack class manages and plays a single audio resource for Java applications. It allows streaming of PCM audio buffers to the audio sink for playback.
:
An AudioTrack instance can operate under two modes: static or streaming. In Streaming mode, the application writes a continuous stream of data to the AudioTrack, using one of the write() methods.
:
The static mode should be chosen when dealing with short sounds that fit in memory and that need to be played with the smallest latency possible.
:
- AudioTrack (constructor)
AudioTrack (
int streamType,
int sampleRateInHz,
int channelConfig,
int audioFormat,
int bufferSizeInBytes,
int mode)
:
Parameters
:
int: the total size (in bytes) of the internal buffer where audio data is read from for playback. This should be a nonzero multiple of the frame size in bytes.
:
If the track's creation mode is MODE_STREAM, this should be the desired buffer size for the AudioTrack to satisfy the application's latency requirements. If bufferSizeInBytes is less than the minimum buffer size for the output sink, it is increased to the minimum buffer size.
:
See getMinBufferSize(int, int, int) to determine the estimated minimum buffer size for an AudioTrack instance in streaming mode. - play
void play ()
Starts playing an AudioTrack.
If track's creation mode is MODE_STATIC, you must have called one of the write methods（中略）prior to play().
If the mode is MODE_STREAM, you can optionally prime the data path prior to calling play(), by writing up to bufferSizeInBytes (from constructor). If you don't call write() first, or if you call write() but with an insufficient amount of data, then the track will be in underrun state at play(). In this case, playback will not actually start playing until the data path is filled to a device-specific minimum level.
:
- write
int write (
short[] audioData,
int offsetInShorts,
int sizeInShorts)
Writes the audio data to the audio sink for playback (streaming mode), or copies audio data for later playback (static buffer mode). The format specified in the AudioTrack constructor should be ENCODING_PCM_16BIT to correspond to the data in the array.
:
- getPlayState
int getPlayState ()
Returns the playback state of the AudioTrack instance.
See also:
PLAYSTATE_STOPPED
PLAYSTATE_PAUSED
PLAYSTATE_PLAYING
- pause
void pause ()
Pauses the playback of the audio data. Data that has not been played back will not be discarded. Subsequent calls to play() will play this data back. See flush() to discard this data.
:
- stop
void stop ()
Stops playing the audio data.
:
- flush
void flush ()
Flushes the audio data currently queued for playback. Any data that has been written but not yet presented will be discarded. No-op if not stopped or paused, or if the track's creation mode is not MODE_STREAM.
:
- AudioTrack (constructor)
試作
Android 環境での音声入出力の基本的な作法を覚えるために最初にごくシンプルなアプリを書いてみました。 入力側と出力側は多くの場合機能的に分けられますが、ここではその両方の要素を次の内容で単一のプログラムに組み入れています。
- UI 上のボタンを押下するとマイクロフォンからの録音を開始する
- 再度ボタンを押下すると録音を終了しその内容を再生する
- 音声データはメモリ上で扱いファイルは使用しない
処理のイメージ
動作の様子
動画：33秒 ※音量注意！
ソースコード
sonic01 GitHub
- MainActivity.java
/** * * sonic01 * * 端末のマイクから音声を録音しスピーカーで再生する * Android 標準の AudioRecord, AudioTrack を使用 * * サンプリング周波数 44.1kHz * 量子化ビット数 16 * モノラル * */ package jp.klab.sonic01; import android.Manifest; import android.content.pm.PackageManager; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.AudioManager; import android.media.AudioTrack; import android.media.MediaRecorder; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v4.app.ActivityCompat; import android.support.v4.content.ContextCompat; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.ProgressBar; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final int BLOCK_NUMBER = 300; private static final int MSG_RECORD_START = 100; private static final int MSG_RECORD_END = 110; private static final int MSG_PLAY_END = 130; private Handler mHandler; private AudioRecord mAudioRecord = null; private AudioTrack mAudioTrack = null; private Button mButton01; private ProgressBar mProgressBar; private boolean mInRecording = false; private boolean mStop = false; private int mBufferSizeInShort; private short mPlayBuf[]; private short mRecordBuf[]; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (Button)findViewById(R.id.button01); mButton01.setOnClickListener(this); mProgressBar = (ProgressBar)findViewById(R.id.progressBar); mProgressBar.setMax(BLOCK_NUMBER); mProgressBar.setProgress(0); /***** add for Android 6.0 or later ****/ // https://developer.android.com/training/permissions/requesting.html // https://developer.android.com/topic/libraries/support-library/index.html#backward if (ContextCompat.checkSelfPermission(this, Manifest.permission.RECORD_AUDIO) != PackageManager.PERMISSION_GRANTED) { // RECORD_AUDIO の実行時パーミッションを要求 ActivityCompat.requestPermissions(this, new String[]{Manifest.permission.RECORD_AUDIO}, 1); } initAudio(); /**** add end ****/ /***** move to initAudio() **** int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mBufferSizeInShort = bufferSizeInBytes / 2; // 録音用バッファ mRecordBuf = new short[mBufferSizeInShort]; // 再生用バッファ mPlayBuf = new short[mBufferSizeInShort * BLOCK_NUMBER]; // 録音用 mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes); // 再生用 mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLE_RATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes, AudioTrack.MODE_STREAM); ****/ } /**** add for Android 6.0 or later ****/ // https://developer.android.com/training/permissions/requesting.html @Override public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) { switch (requestCode) { case 1: { if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) { initAudio(); } else { finish(); } return; } } } private void initAudio() { int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mBufferSizeInShort = bufferSizeInBytes / 2; // 録音用バッファ mRecordBuf = new short[mBufferSizeInShort]; // 再生用バッファ mPlayBuf = new short[mBufferSizeInShort * BLOCK_NUMBER]; // 録音用 mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes); // 再生用 mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLE_RATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes, AudioTrack.MODE_STREAM); } /**** add end ****/ @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); mStop = true; try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioRecord != null) { if (mAudioRecord.getRecordingState() != AudioRecord.RECORDSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioRecord"); mAudioRecord.stop(); } mAudioRecord = null; } if (mAudioTrack != null) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioTrack"); mAudioTrack.stop(); mAudioTrack.flush(); } mAudioTrack = null; } } @Override public void onClick(View v) { if (v == (View)mButton01) { // 集音開始 or 終了 if (!mInRecording) { mInRecording = true; new Thread(this).start(); } else { mInRecording = false; } } return; } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_RECORD_START: Log.d(TAG, "MSG_RECORD_START"); mButton01.setText("STOP"); break; case MSG_RECORD_END: Log.d(TAG, "MSG_RECORD_END"); mButton01.setEnabled(false); break; case MSG_PLAY_END: Log.d(TAG, "MSG_PLAY_END"); mButton01.setEnabled(true); mButton01.setText("START"); break; } return true; } @Override public void run() { mHandler.sendEmptyMessage(MSG_RECORD_START); // 集音開始 mAudioRecord.startRecording(); int count = 0; while (mInRecording && !mStop) { mAudioRecord.read(mRecordBuf, 0, mBufferSizeInShort); // 再生用バッファはリングバッファとして扱う if (count * mBufferSizeInShort >= mPlayBuf.length) { count = 0; mProgressBar.setProgress(0); } // 再生用バッファへ集音したデータをアペンド System.arraycopy(mRecordBuf, 0, mPlayBuf, count * mBufferSizeInShort, mBufferSizeInShort); mProgressBar.setProgress(++count); } // 集音終了 mAudioRecord.stop(); mProgressBar.setProgress(0); mHandler.sendEmptyMessage(MSG_RECORD_END); if (mStop) { return; } // 再生 mAudioTrack.setPlaybackRate(SAMPLE_RATE); mAudioTrack.play(); mAudioTrack.write(mPlayBuf, 0, count * mBufferSizeInShort); mAudioTrack.stop(); mAudioTrack.flush(); mHandler.sendEmptyMessage(MSG_PLAY_END); } }
- AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.klab.sonic01"> <uses-permission android:name="android.permission.RECORD_AUDIO"/> <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:supportsRtl="true" android:theme="@style/AppTheme"> <activity android:name=".MainActivity" android:label="@string/app_name" android:configChanges="orientation|screenSize" android:screenOrientation="unspecified" android:theme="@style/AppTheme.NoActionBar"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <!-- ATTENTION: This was auto-generated to add Google Play services to your project for App Indexing. See https://g.co/AppIndexing/AndroidStudio for more information. --> <meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version" /> </application> </manifest>
準備 2. 任意の周波数の音波を生成・出力する
音による情報伝達（言語音を除く）においては、伝えたい内容の意味を構成する要素として「音の高さ（周波数）」と「音の大きさ（振幅）」が挙げられます。これらを所定の規則に基づいて組み合わせることで送り手と受け手の間でのやりとりが可能となるでしょう。送り手側にはそこで任意の周波数・振幅の音を作る処理が必要となります。これがふたつめの課題です。
サイン波について
音の波形には種類がありますが、ここでは基本波形のひとつであるサイン波を使うことにしました。サイン波をプログラムで生成するためにその性質・特徴と関連する情報を整理してみます。
- 正弦波 - wikipedia より
正弦波（せいげんは、sine wave、sinusoidal wave）は、正弦関数として観測可能な周期的変化を示す波動のことである。その波形は正弦曲線（せいげんきょくせん、sine curve）もしくはシヌソイド (Sinusoid) と呼ばれ、数学、信号処理、電気工学およびその他の分野において重要な働きをする。 :
- 正弦波交流って、実は円運動なんです - manapo.com 様のサイトより
ある点を中心に回転する運動は「円運動」と言われ、 物理の世界ではよく出てくる言葉でもある。この円運動の軌跡を回転角度を横軸にしてグラフにすると、このように正弦波の形になる。
角度が90°のところで山になり、180°のところで出発点と同じになり、270°のところで谷になり、360°のところで元に戻る。
図では回転角度ではなく、少しでも理解しやすいように時間としてある。言い換えると、円運動で１回転するのに必要な時間を周期と呼ぶのである。そして、１秒間の回転数が即ち周波数である。 - https://www.youtube.com/embed/ij0K2tUVEGs - surikenclub 様による Youtube 動画
- 第5章 フーリエ級数 - Masasi.Sanae 様のサイトより
・1秒間に描かれる波の回数を「周波数」といい，単位はヘルツ(Hz)を用います。
・1秒間に進む角度のことを「角速度」といいω（オメガ）で表します。
・横軸からの波の振れ具合を「振幅」といいます。
sin波，cos波の1つの波が現れる角度（周期といいます）は360°ですから
角速度＝周波数×360°
が成り立ちます。次の例では周波数が3，角速度1080°，振幅1のsin波を表しています。
周波数k，振幅aのsin波はy=a sin kωtで表されます。（ω=360°）
y=sin 1080°t=sin 3ωt
- ラジアン（弧度法） - wikipedia より
ラジアン（radian, 単位記号: [rad]）は、国際単位系 (SI) における角度（平面角）の単位である。円周上でその円の半径と同じ長さの弧を切り取る2本の半径が成す角の値と定義される。
1ラジアンは度数法では (180/π)° で、およそ 57.29578° に相当する。180°は弧度法においては π rad であり、360° は 2π rad である。
:
数学で三角関数を扱う時は、角度にラジアンを用いるのが普通である。その理由は、それが「自然」だからであり、多くの公式が簡潔に書けるようになる。（※半径 r の円の円周は 2 π r であるため 円（＝360°）を弧度法で表すと「2 π r ÷ r」。よって 360° ＝ 2π ラジアン）
以上のことから、振幅が A、角速度 ω のサイン波信号のある時点 t 秒における値 y は次の式によって得られます。
y = A * sin ( ω * t )
ここで、角速度 ＝ 周波数（ f Hz ）× 360° であり 360° ＝ 2π ラジアン であるため角速度は「周波数（ f Hz ） × 2π」と表せるためこの式は次のようにも書けます。
サンプリングレートについて
所定の周波数の信号を出力するためには相応のサンプリング（標本化）レートが必要となります。
- サンプリング定理／エイリアシング - DSP の基礎・トレーニング - TI - Texas Instruments 様のサイトより
サンプリング定理
:
取り扱う信号が周波数 fc より高い周波数成分を持たないとき、サンプリング周波数 fs は
fs≧2fc
であれば、サンプリングされた信号から元の信号は完全に再現される。
オーディオ CD の規格で採用されているサンプリングレート 44,100Hz であれば理論上 22,000Hz 付近までの再現が可能であるため実用上の不足はないでしょう。また、十分なダイナミックレンジを確保するために振幅情報の量子化にはこれもオーディオ CD と同様に 16ビットを用いることとします。（ちなみに DVD は 24ビットだそうです）
計算してみると、「サンプリングレート 44,100Hz・量子化ビット数 16・モノラル」で 1秒間の信号を構成するには、44,100点 * 2バイト * 1チャネル = 88,200バイトのメモリ空間が必要ということになります。
関連情報
- サンプリング周波数と量子化ビット - Soraotoブログ様のサイトより
- ビット数とダイナミックレンジの関係 - boo*a*ken*o 様による記事
- サンプリングレートはなぜ44,100Hzなのか - かもん！様による記事
試作
以上の情報をもとにプログラムを試作しました。200Hz 〜 14,000Hz の範囲の 10種類の周波数のサイン波信号を生成・出力するものです。ここでは要素数 44,100 の short 型配列に 1秒分のサイン波データを格納しループ再生を行っています。
動作の様子
動画：2分13秒 ※音量注意！
分析に使用しているアプリ： AudioUtil Spectrum Analyzer - play.google.com
ソースコード
sonic03 GitHub
- MainActivity.java
/** * * sonic03 * * サイン波信号を生成して鳴らす * * サンプリング周波数 44.1kHz * 量子化ビット数 16 * モノラル * */ package jp.klab.sonic03; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.AudioManager; import android.media.AudioTrack; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.ToggleButton; import java.util.Arrays; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final float SEC_PER_SAMPLEPOINT = 1.0f / SAMPLE_RATE; private static final int AMP = 4000; private static final int [] FREQS = new int[] {200, 400, 800, 1600, 2000, 4000, 8000, 10000, 12000, 14000}; private static final int DO = 262 * 2; private static final int RE = 294 * 2; private static final int MI = 330 * 2; private static final int FA = 349 * 2; private static final int SO = 392 * 2; private static final int RA = 440 * 2; private static final int SI = 494 * 2; private static final int MSG_PLAY_START = 120; private static final int MSG_PLAY_END = 130; private Handler mHandler; private AudioTrack mAudioTrack = null; private ToggleButton mButtons[]; private int mIdxButtonPushed = -1; private int mBufferSizeInShort; private short mPlayBuf[]; // 1秒分のサイン波データを生成 private void createSineWave(int freq, int amplitude, boolean doClear) { if (doClear) { Arrays.fill(mPlayBuf, (short) 0); } for (int i = 0; i < SAMPLE_RATE; i++) { float currentSec = i * SEC_PER_SAMPLEPOINT; // 現在位置の経過秒数 // y(t) = A * sin(2π * f * t) double val = amplitude * Math.sin(2.0 * Math.PI * freq * currentSec); mPlayBuf[i] += (short)val; } } @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButtons = new ToggleButton[11]; (mButtons[0] = (ToggleButton)findViewById(R.id.button01)).setOnClickListener(this); (mButtons[1] = (ToggleButton)findViewById(R.id.button02)).setOnClickListener(this); (mButtons[2] = (ToggleButton)findViewById(R.id.button03)).setOnClickListener(this); (mButtons[3] = (ToggleButton)findViewById(R.id.button04)).setOnClickListener(this); (mButtons[4] = (ToggleButton)findViewById(R.id.button05)).setOnClickListener(this); (mButtons[5] = (ToggleButton)findViewById(R.id.button06)).setOnClickListener(this); (mButtons[6] = (ToggleButton)findViewById(R.id.button07)).setOnClickListener(this); (mButtons[7] = (ToggleButton)findViewById(R.id.button08)).setOnClickListener(this); (mButtons[8] = (ToggleButton)findViewById(R.id.button09)).setOnClickListener(this); (mButtons[9] = (ToggleButton)findViewById(R.id.button10)).setOnClickListener(this); (mButtons[10] = (ToggleButton)findViewById(R.id.button11)).setOnClickListener(this); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); // 再生用バッファ mPlayBuf = new short[SAMPLE_RATE]; // 1秒分のバッファを確保 // 再生用 mAudioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLE_RATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes, AudioTrack.MODE_STREAM); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioTrack != null) { if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioTrack"); mAudioTrack.stop(); mAudioTrack.flush(); } mAudioTrack = null; } } @Override public void onClick(View v) { for (int i = 0; i < mButtons.length; i++) { if (mButtons[i] == (ToggleButton)v) { mIdxButtonPushed = i; break; } } if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { mAudioTrack.stop(); mAudioTrack.flush(); } if (mButtons[mIdxButtonPushed].isChecked()) { new Thread(this).start(); } } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_PLAY_START: Log.d(TAG, "MSG_PLAY_START"); break; case MSG_PLAY_END: Log.d(TAG, "MSG_PLAY_END"); mButtons[mIdxButtonPushed].setChecked(false); break; } return true; } @Override public void run() { mHandler.sendEmptyMessage(MSG_PLAY_START); if (mAudioTrack.getPlayState() != AudioTrack.PLAYSTATE_STOPPED) { mAudioTrack.stop(); mAudioTrack.flush(); } mAudioTrack.play(); if (mIdxButtonPushed != 10) { createSineWave(FREQS[mIdxButtonPushed], AMP, true); for (int i = 0; i < 5; i++) { // 5秒程度鳴らす mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE); } } else { // SONG for (int i = 0; i < 2; i++) { mAudioTrack.play(); createSineWave(DO, AMP, true); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(RE, AMP, true); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(MI, AMP, true); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(FA, AMP, true); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(MI, AMP, true); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(RE, AMP, true); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(DO, AMP, true); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE); // 和音 createSineWave(DO, AMP, true); createSineWave(MI, AMP, false); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(RE, AMP, true); createSineWave(FA, AMP, false); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(MI, AMP, true); createSineWave(SO, AMP, false); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(FA, AMP, true); createSineWave(RA, AMP, false); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(MI, AMP, true); createSineWave(SO, AMP, false); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(RE, AMP, true); createSineWave(FA, AMP, false); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE / 2); createSineWave(DO, AMP, true); createSineWave(MI, AMP, false); mAudioTrack.write(mPlayBuf, 0, SAMPLE_RATE); } } mAudioTrack.stop(); mAudioTrack.flush(); mHandler.sendEmptyMessage(MSG_PLAY_END); } }
- AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.klab.sonic03"> <uses-permission android:name="android.permission.RECORD_AUDIO"/> <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:supportsRtl="true" android:theme="@style/AppTheme"> <activity android:name=".MainActivity" android:label="@string/app_name" android:configChanges="orientation|screenSize" android:screenOrientation="unspecified" android:theme="@style/AppTheme.NoActionBar"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <!-- ATTENTION: This was auto-generated to add Google Play services to your project for App Indexing. See https://g.co/AppIndexing/AndroidStudio for more information. --> <meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version" /> </application> </manifest>
スプレッドシートを使っての検証
前述のように上のコードの createSineWave 関数は要素数 44,100 の short 型配列に 44,100Hz・16ビット・モノラル 1秒分のサイン波データを生成しています。
この配列の先頭 441 要素分、つまり 1/100 秒分のデータとそれをグラフ化したものを以下に示します。それぞれ期待通りの波形が生成されていることが見てとれます。
- 周波数 400Hz を指定した場合：400Hz/100 につき 4 周期分の出力
element,value 0,0 1,227 2,454 3,680 4,903 5,1124 6,1341 7,1553 8,1761 9,1962 10,2158 11,2346 12,2527 13,2699 14,2863 15,3017 16,3162 17,3296 18,3420 19,3533 20,3634 21,3723 22,3800 23,3865 24,3917 25,3957 26,3984 27,3997 28,3998 29,3986 30,3961 31,3923 32,3872 33,3809 34,3733 35,3646 36,3546 37,3435 38,3312 39,3179 40,3036 41,2883 42,2720 43,2549 44,2369 45,2182 46,1987 47,1786 48,1579 49,1368 50,1151 51,931 52,708 53,483 54,256 55,28 56,-199 57,-426 58,-652 59,-876 60,-1097 61,-1314 62,-1527 63,-1735 64,-1937 65,-2134 66,-2323 67,-2505 68,-2678 69,-2843 70,-2999 71,-3145 72,-3280 73,-3405 74,-3519 75,-3622 76,-3712 77,-3791 78,-3858 79,-3911 80,-3953 81,-3981 82,-3996 83,-3999 84,-3988 85,-3965 86,-3928 87,-3879 88,-3818 89,-3743 90,-3657 91,-3559 92,-3449 93,-3328 94,-3197 95,-3055 96,-2902 97,-2741 98,-2571 99,-2392 100,-2205 101,-2012 102,-1812 103,-1606 104,-1394 105,-1179 106,-959 107,-736 108,-511 109,-284 110,-56 111,170 112,398 113,624 114,848 115,1069 116,1287 117,1501 118,1709 119,1913 120,2110 121,2300 122,2482 123,2657 124,2823 125,2980 126,3127 127,3264 128,3390 129,3506 130,3610 131,3702 132,3782 133,3850 134,3905 135,3948 136,3978 137,3995 138,3999 139,3990 140,3968 141,3934 142,3886 143,3826 144,3753 145,3669 146,3572 147,3464 148,3344 149,3214 150,3073 151,2922 152,2762 153,2592 154,2415 155,2229 156,2036 157,1837 158,1632 159,1421 160,1206 161,987 162,764 163,539 164,313 165,85 166,-142 167,-369 168,-596 169,-820 170,-1042 171,-1260 172,-1474 173,-1684 174,-1887 175,-2085 176,-2276 177,-2460 178,-2636 179,-2803 180,-2961 181,-3109 182,-3247 183,-3375 184,-3492 185,-3597 186,-3691 187,-3773 188,-3842 189,-3899 190,-3944 191,-3975 192,-3994 193,-3999 194,-3992 195,-3972 196,-3939 197,-3893 198,-3834 199,-3763 200,-3680 201,-3585 202,-3478 203,-3360 204,-3231 205,-3091 206,-2941 207,-2782 208,-2614 209,-2437 210,-2253 211,-2061 212,-1862 213,-1658 214,-1448 215,-1233 216,-1014 217,-792 218,-567 219,-341 220,-113 221,113 222,341 223,567 224,792 225,1014 226,1233 227,1448 228,1658 229,1862 230,2061 231,2253 232,2437 233,2614 234,2782 235,2941 236,3091 237,3231 238,3360 239,3478 240,3585 241,3680 242,3763 243,3834 244,3893 245,3939 246,3972 247,3992 248,3999 249,3994 250,3975 251,3944 252,3899 253,3842 254,3773 255,3691 256,3597 257,3492 258,3375 259,3247 260,3109 261,2961 262,2803 263,2636 264,2460 265,2276 266,2085 267,1887 268,1684 269,1474 270,1260 271,1042 272,820 273,596 274,369 275,142 276,-85 277,-313 278,-539 279,-764 280,-987 281,-1206 282,-1421 283,-1632 284,-1837 285,-2036 286,-2229 287,-2415 288,-2592 289,-2762 290,-2922 291,-3073 292,-3214 293,-3344 294,-3464 295,-3572 296,-3669 297,-3753 298,-3826 299,-3886 300,-3934 301,-3968 302,-3990 303,-3999 304,-3995 305,-3978 306,-3948 307,-3905 308,-3850 309,-3782 310,-3702 311,-3610 312,-3506 313,-3390 314,-3264 315,-3127 316,-2980 317,-2823 318,-2657 319,-2482 320,-2300 321,-2110 322,-1913 323,-1709 324,-1501 325,-1287 326,-1069 327,-848 328,-624 329,-398 330,-170 331,56 332,284 333,511 334,736 335,959 336,1179 337,1394 338,1606 339,1812 340,2012 341,2205 342,2392 343,2571 344,2741 345,2902 346,3055 347,3197 348,3328 349,3449 350,3559 351,3657 352,3743 353,3818 354,3879 355,3928 356,3965 357,3988 358,3999 359,3996 360,3981 361,3953 362,3911 363,3858 364,3791 365,3712 366,3622 367,3519 368,3405 369,3280 370,3145 371,2999 372,2843 373,2678 374,2505 375,2323 376,2134 377,1937 378,1735 379,1527 380,1314 381,1097 382,876 383,652 384,426 385,199 386,-28 387,-256 388,-483 389,-708 390,-931 391,-1151 392,-1368 393,-1579 394,-1786 395,-1987 396,-2182 397,-2369 398,-2549 399,-2720 400,-2883 401,-3036 402,-3179 403,-3312 404,-3435 405,-3546 406,-3646 407,-3733 408,-3809 409,-3872 410,-3923 411,-3961 412,-3986 413,-3998 414,-3997 415,-3984 416,-3957 417,-3917 418,-3865 419,-3800 420,-3723 421,-3634 422,-3533 423,-3420 424,-3296 425,-3162 426,-3017 427,-2863 428,-2699 429,-2527 430,-2346 431,-2158 432,-1962 433,-1761 434,-1553 435,-1341 436,-1124 437,-903 438,-680 439,-454 440,-227
- 周波数 1,600Hz を指定した場合：1,600Hz/100 につき 16 周期分の出力
element,value 0,0 1,903 2,1761 3,2527 4,3162 5,3634 6,3917 7,3998 8,3872 9,3546 10,3036 11,2369 12,1579 13,708 14,-199 15,-1097 16,-1937 17,-2678 18,-3280 19,-3712 20,-3953 21,-3988 22,-3818 23,-3449 24,-2902 25,-2205 26,-1394 27,-511 28,398 29,1287 30,2110 31,2823 32,3390 33,3782 34,3978 35,3968 36,3753 37,3344 38,2762 39,2036 40,1206 41,313 42,-596 43,-1474 44,-2276 45,-2961 46,-3492 47,-3842 48,-3994 49,-3939 50,-3680 51,-3231 52,-2614 53,-1862 54,-1014 55,-113 56,792 57,1658 58,2437 59,3091 60,3585 61,3893 62,3999 63,3899 64,3597 65,3109 66,2460 67,1684 68,820 69,-85 70,-987 71,-1837 72,-2592 73,-3214 74,-3669 75,-3934 76,-3995 77,-3850 78,-3506 79,-2980 80,-2300 81,-1501 82,-624 83,284 84,1179 85,2012 86,2741 87,3328 88,3743 89,3965 90,3981 91,3791 92,3405 93,2843 94,2134 95,1314 96,426 97,-483 98,-1368 99,-2182 100,-2883 101,-3435 102,-3809 103,-3986 104,-3957 105,-3723 106,-3296 107,-2699 108,-1962 109,-1124 110,-227 111,680 112,1553 113,2346 114,3017 115,3533 116,3865 117,3997 118,3923 119,3646 120,3179 121,2549 122,1786 123,931 124,28 125,-876 126,-1735 127,-2505 128,-3145 129,-3622 130,-3911 131,-3999 132,-3879 133,-3559 134,-3055 135,-2392 136,-1606 137,-736 138,170 139,1069 140,1913 141,2657 142,3264 143,3702 144,3948 145,3990 146,3826 147,3464 148,2922 149,2229 150,1421 151,539 152,-369 153,-1260 154,-2085 155,-2803 156,-3375 157,-3773 158,-3975 159,-3972 160,-3763 161,-3360 162,-2782 163,-2061 164,-1233 165,-341 166,567 167,1448 168,2253 169,2941 170,3478 171,3834 172,3992 173,3944 174,3691 175,3247 176,2636 177,1887 178,1042 179,142 180,-764 181,-1632 182,-2415 183,-3073 184,-3572 185,-3886 186,-3999 187,-3905 188,-3610 189,-3127 190,-2482 191,-1709 192,-848 193,56 194,959 195,1812 196,2571 197,3197 198,3657 199,3928 200,3996 201,3858 202,3519 203,2999 204,2323 205,1527 206,652 207,-256 208,-1151 209,-1987 210,-2720 211,-3312 212,-3733 213,-3961 214,-3984 215,-3800 216,-3420 217,-2863 218,-2158 219,-1341 220,-454 221,454 222,1341 223,2158 224,2863 225,3420 226,3800 227,3984 228,3961 229,3733 230,3312 231,2720 232,1987 234,256 235,-652 236,-1527 237,-2323 238,-2999 239,-3519 240,-3858 241,-3996 242,-3928 243,-3657 244,-3197 245,-2571 246,-1812 247,-959 248,-56 249,848 250,1709 251,2482 252,3127 253,3610 254,3905 255,3999 256,3886 257,3572 258,3073 259,2415 260,1632 261,764 262,-142 263,-1042 264,-1887 265,-2636 266,-3247 267,-3691 268,-3944 269,-3992 270,-3834 271,-3478 272,-2941 273,-2253 274,-1448 275,-567 276,341 277,1233 278,2061 279,2782 280,3360 281,3763 282,3972 283,3975 284,3773 285,3375 286,2803 287,2085 288,1260 289,369 290,-539 291,-1421 292,-2229 293,-2922 294,-3464 295,-3826 296,-3990 297,-3948 298,-3702 299,-3264 300,-2657 302,-1069 303,-170 304,736 305,1606 306,2392 307,3055 308,3559 309,3879 310,3999 311,3911 312,3622 313,3145 314,2505 315,1735 316,876 317,-28 318,-931 319,-1786 320,-2549 321,-3179 322,-3646 323,-3923 324,-3997 325,-3865 326,-3533 327,-3017 328,-2346 329,-1553 330,-680 331,227 332,1124 333,1962 334,2699 335,3296 336,3723 337,3957 338,3986 339,3809 340,3435 341,2883 342,2182 343,1368 344,483 345,-426 346,-1314 347,-2134 348,-2843 349,-3405 350,-3791 351,-3981 352,-3965 353,-3743 354,-3328 355,-2741 356,-2012 357,-1179 358,-284 359,624 360,1501 361,2300 362,2980 363,3506 364,3850 365,3995 366,3934 367,3669 368,3214 369,2592 370,1837 371,987 372,85 373,-820 374,-1684 375,-2460 376,-3109 377,-3597 378,-3899 379,-3999 380,-3893 381,-3585 382,-3091 383,-2437 384,-1658 385,-792 386,113 387,1014 388,1862 389,2614 390,3231 391,3680 392,3939 393,3994 394,3842 395,3492 396,2961 397,2276 398,1474 399,596 400,-313 401,-1206 402,-2036 403,-2762 404,-3344 405,-3753 406,-3968 407,-3978 408,-3782 409,-3390 410,-2823 411,-2110 412,-1287 413,-398 414,511 415,1394 416,2205 417,2902 418,3449 419,3818 420,3988 421,3953 422,3712 423,3280 424,2678 425,1937 426,1097 427,199 428,-708 429,-1579 430,-2369 431,-3036 432,-3546 433,-3872 434,-3998 435,-3917 436,-3634 437,-3162 438,-2527 439,-1761 440,-903
準備 3. 集音したデータの周波数分析を行う
FFT（Fast Fourier Transform 高速フーリエ変換）について
無響室のように人為的な特殊環境を除き世界は雑多な音で満ちています。人間の脳は自身が無意識のうちに複数の音の中から必要な音を選り分けており（カクテルパーティー効果）、静かに感じられる室内であってもレコーダーでの録音内容を再生すると意外なノイズに気づくといった経験は一般的なものですね。そのため、受け手側の装置が特定の音を検知するためには必要なものだけを明示的にピックアップする必要があります。これがみっつめの課題です。広く知られるフーリエ変換を音声信号に適用すれば音の塊を周波数成分ごとに分析できます。
フーリエ変換とは
- フーリエ変換の本質 - apphokuson 様のサイトより
（※引用に際し表記に一部手を加えさせて頂きました tanabe）
全ての信号は、上図のように波の足しあわせで表現することが出来ます。
具体的には、周波数が1の波1と周波数が2の波2と周波数が3の波3と・・・周波数が nの波nを足し合わせることで、あらゆる信号を表現することが出来るのです。
:
周波数を横軸に、振幅の大きさ（パワー値）を縦軸にとってグラフを書きなおしてみます。
:
この結果は、左図の信号に周波数１の波が大きさ４で含まれていること、周波数２の 波が大きさ0.5で含まれていること、周波数３の波が・・・ということを意味しています。
:
フーリエ変換を行えば、「信号に含まれる周波数の成分比」を得ることが出来ます。
:- 統計的音声認識の基本原理 - 篠崎隆宏様のサイトより
音声信号は,一次元の時系列データです．横軸を時間,縦軸を音の大きさとしてグラフを作成すると,以下のような図が得られます．
- 統計的音声認識の基本原理 - 篠崎隆宏様のサイトより
高速フーリエ変換とは
- 高速フーリエ変換 - wikipedia より
高速フーリエ変換（こうそくフーリエへんかん、英: Fast Fourier Transform、FFT） とは、離散フーリエ変換 (Discrete Fourier Transform、DFT) を計算機上で高速に 計算するアルゴリズム。FFTの逆変換をIFFT (Inverse FFT) と呼ぶ。
- 離散フーリエ変換入門 - EnergyChord 様のサイトより
コンピュータで行われるフーリエ変換は基本的に離散フーリエ変換である．なぜなら，電子計算機は連続量をそのまま扱うことができないため，コンピュータが処理するデータは必ず離散化される必要があるからである．つまり，コンピュータによるデータ処理が当たり前となった現代技術においては，フーリエ変換と言えば離散フーリエ変換を指すと言っても過言ではない．
- 離散化とは - IT用語辞典バイナリより
離散化とは、ある連続した情報を、非連続の値に分割することである。
連続した値を持った情報を解析することは非常に困難であるが、離散化を行い非連続な数値に置き換えることで、近似的な計算結果を比較的容易に算出することが可能となる。
- 離散化とは - IT用語辞典バイナリより
- フーリエ変換と離散フーリエ変換 - 岩本真裕子様のサイトより
:
フーリエ変換では、波y(t)を構成する三角関数とその周波数・振幅・初期位相などを知ることができるため、波の特徴を明確に捉えることができる。
離散フーリエ変換
これまでは、連続関数に対するフーリエ変換およびフーリエ積分（逆フーリエ変換）について考えてきた。実際、音声や音楽などは、連続的な波として出力される。しかし、コンピュータは離散値でしか扱えないため、Analog-Didital (AD) 変換器を使って、一定間隔でサンプリングし、コンピュータが直接扱える離散的な波に変換される。
:
連続的な波と離散的な波の関係
フーリエ変換は、連続的な波を三角関数を重ね合わせることで表そうとするものであった。例えば、下図のように、８個の周期関数を重ね合わせたものが実際の音であったとする。
次に、AD変換によって、１秒間に４個のサンプリング数（４等分）で連続的な波が離散化されたとする（黒丸）。よく見てみると、cos 3t の離散の４点は cos t の離散の４点と全く同じである。実は sin 3t と sin t についても同様である。
つまり、離散化された波においては、高周波数の波は低周波数の波に吸収されてしまう。今の場合は、重ね合わせられた複雑な波が、k=0,1,2 の三角関数のみで表せるということになってしまう。
しかし、容易に予想できるように、サンプリング数を 増やすと、この問題は解消する。
:
離散フーリエ変換を用いた音などの解析や加工には、サンプリングは非常に重要な要素であり、扱う波についてある程度特徴や性質を知っている必要がある。例えば、人間が聞くことができる音の周波数は、20 Hzから20 kHzと言われている（一般的には15 kHzくらいまで）ので、人間が聞くことができるすべての周波数をカバーしようとすると、サンプリング数は１秒間あたり、20000(Hz)×2=40000 回必要となる。
:
- 離散フーリエ変換入門 - EnergyChord 様のサイトより
FFT ライブラリ「JTransforms」
Android には標準の Visualizer クラスに FFT 用の API getFft() が用意されています。ただし、あくまでも「The Visualizer class enables application to retrieve part of the currently playing audio for visualization purpose.」であり、「Frequency data: 8-bit magnitude FFT by using the getFft(byte[]) method」と機能的にも控えめな内容となっています。 Android で使える FFT ライブラリには複数の選択肢がありますが、Piotr Wendykier 氏による JTransforms が高性能かつメジャーであることを知りこれを利用することにしました。
- JTransforms - Piotr Wendykier - sites.google.com
JTransforms is the first, open source, multithreaded FFT library written in pure Java. Currently, four types of transforms are available: Discrete Fourier Transform (DFT), Discrete Cosine Transform (DCT), Discrete Sine Transform (DST) and Discrete Hartley Transform (DHT). The code is derived from General Purpose FFT Package written by Takuya Ooura and from Java FFTPack written by Baoshe Zhang.
（Google 訳）
JTransformsは、純粋なJavaで書かれた最初のオープンソースのマルチスレッド FFTライブラリです。現在、離散フーリエ変換（DFT）、離散コサイン変換（DCT）、 離散サイン変換（DST）および離散ハートレー変換（DHT）の4種類の変換が利用可能 である。このコードは、Takuya Ooura が書いた汎用FFTパッケージと、Baoshe Zhangが 書いたJava FFTPackから得られたものです。
:
License
JTransforms is distributed under the terms of the BSD-2-Clause license.- Ooura's Mathematical Software Packages - 大浦拓哉様のサイト
- 2条項BSDライセンス - 通信用語の基礎知識
- wendykierp/JTransforms - GitHub
- Documentation | Overview (JTransforms 3.1 API) - wendykierp.github.io
JTransforms 3.1 API
Packages
Package Description
org.jtransforms.dct Discrete Cosine Transforms.
org.jtransforms.dht Discrete Hartley Transforms.
org.jtransforms.dst Discrete Sine Transforms.
org.jtransforms.fft Discrete Fourier Transforms.
org.jtransforms.utils Utility classes.
- Class DoubleFFT_1D
org.jtransforms.fft
Class DoubleFFT_1D
Computes 1D Discrete Fourier Transform (DFT) of complex and real,double precision data. The size of the data can be an arbitrary number.
（Google 訳）
複素数と実数の倍精度データの一次元離散フーリエ変換（DFT）を計算します。データのサイズは任意の数にすることができます。
- Class DoubleFFT_1D
- Documentation | Overview (JTransforms 3.1 API) - wendykierp.github.io
- JTransforms FFT in Android from PCM data - stackoverflow.com
System.arraycopy(applyWindow(sampleData), 0, a, 0, sampleData.length);
fft.realForward(a);
/* find the peak magnitude and it's index */
double maxMag = Double.NEGATIVE_INFINITY;
int maxInd = -1;
for(int i = 0; i < a.length / 2; ++i) {
double re = a[2*i];
double im = a[2*i+1];
double mag = Math.sqrt(re * re + im * im);
if(mag > maxMag) {
maxMag = mag;
maxInd = i;
}
}
- How to get frequency from fft result? - stackoverflow.com
The complex data is interleaved, with real components at even indices and imaginary components at odd indices, i.e. the real components are at index 2*i, the imaginary components are at index 2*i+1.
To get the magnitude of the spectrum at index i, you want:
re = fft[2*i];
im = fft[2*i+1];
magnitude[i] = sqrt(re*re+im*im);
Then you can plot magnitude[i] for i = 0 to N / 2 to get the power spectrum. Depending on the nature of your audio input you should see one or more peaks in the spectrum.
To get the approximate frequency of any given peak you can convert the index of the peak as follows:
freq = i * Fs / N;
where:
freq = frequency in Hz
i = index of peak
Fs = sample rate (e.g. 44100 Hz or whatever you are using)
N = size of FFT (e.g. 1024 in your case)
なるほど、使い方は難しくないようです。整理してみます。
- 音声情報（＝実数のみで構成される）を FFT にかける場合は信号データの配列を引数として realForward メソッドを呼び出す
- 実行結果は配列に複素数で上書きされ偶数インデックスには実部、ひとつ後の奇数インデックスには虚部、というペアが続く
- 各周波数成分の振幅値は当該複素数の絶対値 で得られる
- 複素平面 - KIT数学ナビゲーション様のサイトより
xy 平面において， x 軸に実数， y 軸に虚数を対応させて，複素数を表したものを複素平面という．または，複素数平面，ガウス平面ともいう．
複素数 z=a+ⅈb を複素平面上に表したものが，右の図である．
複素数z の絶対値の定義：
すなわち，複素平面上の原点Oから
- 複素平面 - KIT数学ナビゲーション様のサイトより
- 周波数は「配列要素のインデックス * サンプリングレート / 信号データの要素数（＝「FFT サイズ」）」の式で得られる
- つまり、もっとも振幅の大きい周波数（ピーク周波数）を得るには最大振幅値を持つ配列要素のインデックスを上の式に突っ込めばよい
試作
上記の JTransforms ライブラリを利用して集音データ中のピーク周波数を画面に表示するアプリを作成。期待どおりの結果が得られました。
動作の様子
動画：1分7秒 ※音量注意！
ソースコード
sonic04 GitHub
- MainActivity.java
/** * * sonic04 * * 端末のマイクから音声を受信しピーク周波数を表示する * FFT 処理に JTransforms ライブラリを利用 * * サンプリング周波数 44.1kHz * 量子化ビット数 16 * モノラル * */ package jp.klab.sonic04; import org.jtransforms.fft.DoubleFFT_1D; import android.media.AudioFormat; import android.media.AudioRecord; import android.media.MediaRecorder; import android.os.Bundle; import android.os.Handler; import android.os.Message; import android.support.v7.app.AppCompatActivity; import android.support.v7.widget.Toolbar; import android.util.Log; import android.view.View; import android.widget.Button; import android.widget.TextView; public class MainActivity extends AppCompatActivity implements Runnable, View.OnClickListener, Handler.Callback { private static final String TAG = "SNC"; private static final int SAMPLE_RATE = 44100; private static final short THRESHOLD_AMP = 0x00ff; private static final int MSG_RECORD_START = 100; private static final int MSG_RECORD_END = 110; private static final int MSG_FREQ_PEAK = 120; private static final int MSG_SILENCE = 130; private Handler mHandler; private AudioRecord mAudioRecord = null; private Button mButton01; private TextView mTextView02; private boolean mInRecording = false; private boolean mStop = false; private int mBufferSizeInShort; private short mRecordBuf[]; private DoubleFFT_1D mFFT; private double mFFTBuffer[]; private int mFFTSize; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.d(TAG, "onCreate"); mHandler = new Handler(this); setContentView(R.layout.activity_main); Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); setSupportActionBar(toolbar); mButton01 = (Button)findViewById(R.id.button01); mButton01.setOnClickListener(this); mTextView02 = (TextView)findViewById(R.id.textView02); int bufferSizeInBytes = AudioRecord.getMinBufferSize(SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); mBufferSizeInShort = bufferSizeInBytes / 2; // 録音用バッファ mRecordBuf = new short[mBufferSizeInShort]; // FFT 処理用 mFFTSize = mBufferSizeInShort; mFFT = new DoubleFFT_1D(mFFTSize); mFFTBuffer = new double[mFFTSize]; mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC, SAMPLE_RATE, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSizeInBytes); } @Override public void onStop() { super.onStop(); Log.d(TAG, "onStop"); } @Override public void onDestroy() { super.onDestroy(); Log.d(TAG, "onDestroy"); mStop = true; try { Thread.sleep(2000); } catch (InterruptedException e) { } if (mAudioRecord != null) { if (mAudioRecord.getRecordingState() != AudioRecord.RECORDSTATE_STOPPED) { Log.d(TAG, "cleanup mAudioRecord"); mAudioRecord.stop(); } mAudioRecord = null; } } @Override public void onClick(View v) { if (v == (View)mButton01) { // 集音開始 or 終了 if (!mInRecording) { mInRecording = true; new Thread(this).start(); } else { mInRecording = false; } } return; } @Override public boolean handleMessage(Message msg) { switch (msg.what) { case MSG_RECORD_START: Log.d(TAG, "MSG_RECORD_START"); mButton01.setText("STOP"); break; case MSG_RECORD_END: Log.d(TAG, "MSG_RECORD_END"); mButton01.setText("START"); break; case MSG_FREQ_PEAK: mTextView02.setText(Integer.toString(msg.arg1) + " Hz"); break; case MSG_SILENCE: mTextView02.setText(""); break; } return true; } @Override public void run() { boolean bSilence = false; mHandler.sendEmptyMessage(MSG_RECORD_START); // 集音開始 mAudioRecord.startRecording(); while (mInRecording && !mStop) { mAudioRecord.read(mRecordBuf, 0, mBufferSizeInShort); bSilence = true; for (int i = 0; i < mBufferSizeInShort; i++) { short s = mRecordBuf[i]; if (s > THRESHOLD_AMP) { bSilence = false; } } if (bSilence) { // 静寂 mHandler.sendEmptyMessage(MSG_SILENCE); continue; } int freq = doFFT(mRecordBuf); Message msg = new Message(); msg.what = MSG_FREQ_PEAK; msg.arg1 = freq; mHandler.sendMessage(msg); } // 集音終了 mAudioRecord.stop(); mHandler.sendEmptyMessage(MSG_RECORD_END); } private int doFFT(short[] data) { for (int i = 0; i < mFFTSize; i++) { mFFTBuffer[i] = (double)data[i]; } // FFT 実行 mFFT.realForward(mFFTBuffer); // 処理結果の複素数配列から各周波数成分の振幅値を求めピーク分の要素番号を得る double maxAmp = 0; int index = 0; for (int i = 0; i < mFFTSize/2; i++) { double a = mFFTBuffer[i*2]; // 実部 double b = mFFTBuffer[i*2 + 1]; // 虚部 // a+ib の絶対値 √ a^2 + b^2 = r が振幅値 double r = Math.sqrt(a*a + b*b); if (r > maxAmp) { maxAmp = r; index = i; } } // 要素番号・サンプリングレート・FFT サイズからピーク周波数を求める return index * SAMPLE_RATE / mFFTSize; } }
- AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="jp.klab.sonic04"> <uses-permission android:name="android.permission.RECORD_AUDIO"/> <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:supportsRtl="true" android:theme="@style/AppTheme"> <activity android:name=".MainActivity" android:label="@string/app_name" android:configChanges="orientation|screenSize" android:screenOrientation="unspecified" android:theme="@style/AppTheme.NoActionBar"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <!-- ATTENTION: This was auto-generated to add Google Play services to your project for App Indexing. See https://g.co/AppIndexing/AndroidStudio for more information. --> <meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version" /> </application> </manifest>
次回の予定
以上の内容により Android デバイスで「任意の周波数・振幅の音を出すこと」と「拾った音に含まれる周波数を検知すること」ができるようになりました。音を使ってデバイス間で通信を行うための素材がこれで揃ったことになります。次回はここまでの到達点を応用してビットデータの送受信を試みます。
(tanabe)
音を利用する 1
はじめに
技術・インフラの進化とともに情報通信の効率が加速を続ける状況にあって、「音」を利用した往年の通信手法が近年あらためて注目されています。関連する話題をいくつか以下にピックアップしてみます。これらはいずれも最新の技術や文化に密着した要件での応用という点で共通しており、懐古的なモチーフとはまったく無縁であることが興味深く感じられます。
（※各引用文中の青字表示は筆者によるものです）
- お買い物体験をあたらしく
（株式会社スポットライト様サイトより）スポットライトの技術
(1) 位置検出技術
独自の超音波技術により、Andorid/iOS双方に対応した、正確でセキュアな来店検知が実現できます - 『SSC』Smart Sonic Communication 超音波通信のご案内
（ドリームニュース様サイトより： 2012-06-20）SINGAPORE SDI PTE LTD（本社：シンガポール）は、超音波を利用した機器間通信技術として『SSC(Smart Sonic Communication)』を開発いたしました。 iPhone、Androidなどのスマートフォンはもとより、マイクとスピーカーを備えている機器であれば特別なハードウェアを追加することなく、ソフトウェアの導入のみで通信が可能です。
- 店舗にチェックインすればポイントが貯まる「楽天チェック」はO2Oの本命となるか
（TechCrunch Japan 様サイトより： 2014-04-02）超音波を利用した来店検知ポイントアプリ「スマポ」を提供するスポットライト。 2013年10月に楽天が買収して完全子会社となった同社が、4月2日より楽天と連携した来店ポイントアプリ「楽天チェック」の提供を開始した。
- 楽天チェック - 来店でポイントが貯まる！お得な無料アプリ！
（Google Play ストア上の株式会社スポットライト様によるアプリケーション説明より： 当記事時点での更新日付表示は 2017-04-23）1.楽天チェックでポイントが貯まるお店を探す
2.好きなお店や気になったお店に行く
3.お店に着いたらアプリに記載された指定のエリアでボタンをタップするだけ！ - LINEの「友だち追加」で超音波が使用可能に！ネタかと思ったらほんとに出来た！
（「デジさる」様サイトより： 2015-09-06）LINEを起動して左下の「その他」から「友だち追加」をタップします。
「QRコード」をタップします。
するとQRコードリーダーが起動します。友だち追加をする一方はこの状態で待機します。
もう一方は、「自分のQRコードを表示」をタップしてQRコードを画面に出します。
すると音量がこの時だけ大きくなります。人間の耳には聞こえませんがこの時既に超音波が出ているようです。 - Radon - Share using Ultrasound
（Google Play ストア上の Nam Nghiem 様によるアプリケーション説明より： 当記事時点での更新日付表示は 2016-03-29）NO NFC? NO PROBLEM.
Radon uses sensors you already have, and everyone else has including Wi-Fi, Bluetooth and Ultrasound. It does everything automatically, so all you have to do is tap share. - 新しい Amazon Dash Button にマイクが残されている理由
（当ブログの記事より： 2016-12-22）旧 Button が iOS 端末でのセットアップ時に音声信号を利用するためにマイクロフォンを内蔵していたことは理解できます。では、なぜ BLE 通信を利用する新 Button にもマイクが残されているのでしょう？
使わない部品であれば製造コスト削減のためにも撤去するほうが合理的なはずです。まさか Amazon が何か良からぬことを企んでいるのでしょうか？
・ Amazon Dashからマイクが見つかる、これ盗聴器だろ - jisaka.blog.jp - 新ThinkPadではエラービープ音をAndroidアプリに聞かせるとエラー内容の特定が可能
（PC Watch 様サイトより： 2017-02-09）2017年モデルの新機能の1つとして、エラービープ音の進化が挙げられる。 これまでのPCのエラービープ音と言えば、長い音と短い音を組み合わせたモールス信号のようなもので、ユーザーはその音を聞いて、マニュアルと照らし合わせてエラーを特定するといった煩雑な作業が必要だった。
一方、2017年モデルでは、個別の音階を持ったエラー音でエラーコードを発信し、スマートフォン対応の「Lenovo PC Diagnostics」(リンク先は Android版)というアプリに聞かせると、エラーコードとともに、機種名、エラーの原因、タイムスタンプ、そしてモデル名やシリアルナンバーに至るまでを特定できるようになった。これによって管理の利便性を大幅に 向上させた。
事例では人間の可聴域を離れた超音波を利用するケースがしばしば見受けられます。実際、「超音波通信」は人気のあるキーワードですね。もっとも、かつて電話回線ごしの音響カプラや旧世代のファクシミリでの応酬に可聴音が用いられてきたように、使用する音域を決定づけるのは利用環境等の条件の組み合わせにすぎませんから、技術者にとって一番の関心事はあくまでも「音を媒体としてどのように情報をやりとりするか」という本質的な話題でしょう。
電磁波に比べ音波には伝送上の距離や効率により多くの制約があります。その一方で、法規制の影響がほぼ皆無であることに加え、機器に必要な I/F は音声入出力（役割によっては片方でよい）のみであり自由度が高いという大きな特長があります。このような事情に関心を持ち、近距離通信手段の選択肢のひとつとして「音」を利用するノウハウに触れておきたいと考えました。
そんなわけでここしばらく手元では Android デバイスと mbed マイコンをプラットフォームとしてそれぞれの環境で音（超音波を含む）による情報通信の実験を行ってきました。実践的な情報が比較的乏しい状況も相まって興味深い経験でしたが、全体のボリュームがやや大きいこともあり今後中身を整理しながら数回に分け順を追ってこのブログに記事を書きたいと考えています。
今回は予告をかねて試作の一部を紹介します。以下の二本の動画をご覧下さい。
次回は Android 環境での取り組みと実装まわりの話題を掲載する予定です。
雑記：最初の最初に試したこと 〜 所定の音に反応する機器
2004年ごろ、東京駅八重洲地下街にまだ存在していたアイディアグッズの店「王様のアイディア」で「リモコン発見器」というネーミングの商品を購入した。付属の笛を吹くと小さな本体が音と光で反応するというもの。
何度か使ってずっと忘れていたが今回ふと思い出しネットで探したところ現在も販売されていることを知った。音に関する予備知識がほとんどない状態なりに一連の取り組みの皮切りとしてこのデバイスを使って観察を試みた。
（旭電機化成株式会社様サイトより）
リモコンに装着し笛又は口笛を吹けばピッピッと音と光でリモコンがお知らせします。
特徴
よく使うリモコンに、付属テープで発信機をセット。
笛又は、口笛を吹けばピッピッと音と光でリモコンがお知らせします。
「本製品は、約1600〜2000ヘルツの音に反応するよう作られていますので、笛以外の音でも周波数が合えば反応します」
写真左：下の丸い圧電素子がスピーカーとマイクを兼ねておりメーカーへ尋ねたところ「特定の音域のみへの反応はフィルタ処理ではなく圧電素子の周波数特性によるもの」とのこと。
付属の笛・音楽キーボード・口笛を使い、反応する周波数帯を確認しながらこのデバイスを操作した様子。
動画：1分26秒 ※38秒あたりから耳に障る音が鳴るので音量に注意
使用アプリ： AudioUtil Spectrum Analyzer - play.google.com
以下は動画撮影後にあらためて採取した上記アプリのスクリーンショット。環境音も含まれるがもっとも振幅の大きい周波数成分が近いため三者の波形の周期は大体似ている。
(tanabe)
さよなら Parse
はじめに
世界中の利用者の指先と視線を凝固させた突然の発表からまもなく 1年、Parse.com の全サービスが いよいよ 2017年1月28日（土）に終了します。拡張性が高く高機能でありながら使い勝手の良い優れたサービスだったので終息が惜しまれます。
https://parse.com/
手元では 2年ほど前に IoT の実験として試作した以下のしくみ「Anpi」で Parse.com を採り入れました。
- mbed と Parse で作る高齢者世帯安否確認システム - 当ブログ
一般に BaaS の主な目的はアプリケーションの対向サーバ側機能を代替・補完することにあり、サーバの管理運用やサーバ側コード開発に踏み込むコストを抑制しアプリ本体の開発に注力可能となることが利用者にとってのメリットですが、Parse にはサーバ上でユーザコードを実行することのできる「Cloud Code」というしくみが用意されています。（中略）今回作った装置は Parse サーバ上に設置した自作コードをそのまま呼び出して必要な処理を行っています。このように目的に応じて柔軟に利用できることが Parse の魅力のひとつと言ってよいでしょう。
※文中の記述はいずれも 2016年11月から12月の時点の状況に基づくものであり現在の事情とは異なる可能性があります。あらかじめご了承下さい。
手元の要件と移行先選定基準
「Anpi」において Parse.com サイドで行っていた処理は以下の内容です。
- 屋内に設置ずみの装置が人感センサ反応時に最短 30 分間隔で送信してくる情報をデータストアへ保存
- 定刻に直近 60 レコード分をレポートとして所定のアドレスへメール送信
- 装置につないだボタンが長押しされたら所定のアドレスへメールで通知（緊急メール）
- メール配信には Parse.com が 公式 API で連携している Mailgun サービスを利用
|
 |
|
要件に特に煩雑なものはなくこれらを吸収可能なサービスはいくつも存在するでしょう。その上で、今回は次の三点を移行先選定の基準とすることにしました。
- 運用に手がかからないこと
- 柔軟性があること
- 費用がかからないこと
なお、要件のうち「緊急メール」の発信については以前「今、ワンボタンの IoT デバイスが面白い」でも利用した SendGrid サービスの API を装置側のコードから直接叩くことにしました。メールの内容は決め打ちなので各サービスに仲介させるよりもそのほうが合理的と考えたためです。
- V3 Mail Send API Overview - SendGrid Documentation - sendgrid.com
移行先候補 1： IFTTT + Google Drive + Google Apps Script
もっともシンプルに要件を満たす道具立てとしてまず IFTTT と Google サービスの組み合わせを考えました。IFTTT 経由で Google Drive 上の Spreadsheet をデータストアとして利用し Google Apps Script でサーバサイドの処理を実行する内容です。
仮移行を通じての * 個人的な * 印象
GOOD !
- シンプルかつ柔軟
- Google, IFTTT ともに今後課金の発生する可能性がきわめて低い
- Google, IFTTT ともに今後サービスが終息する可能性がきわめて低い
- コードを含めすべてをブラウザ上で操作できるため運用上の自由度が高い
- 今回の要件には十分だが規模の大きいデータを扱うには不向き
- あくまでも SaaS とハブサービスの組み合わせであるため当然ながらプッシュ通知など一般的な IoT プラットフォームの提供する機能は代替できない
移行先候補 2： Kii Cloud
Kii Cloud は Kii 株式会社様の提供する日本発の BaaS です。
仮移行を通じての * 個人的な * 印象
GOOD !
- 多機能かつ無料枠が広い
- Parse.com と同様に BaaS でありながらサーバ機能拡張が可能
- サーバのリージョンを自由に選択可能であり特に中国リージョンの存在は大きい
- キーバリュー形式のデータは使用容量にカウントされないため他のサービスとの併用にも好適か
- アクセス制御機能が充実
- 日本語のリソースが充実している
! GOOD ？
- ドキュメントの情報量は豊かだが通読性がもうひとつ？リンクの張り方にも改善の余地がありそうな印象（このあたりが改善されればより利用しやすくなるかも）
- 開発者ポータルは UI・機能ともに今後の進化が期待される
- 開発用のコマンドラインツールが Node.js ベースなのは利点と欠点が半々くらい？ バッチジョブのスケジュール変更といった操作はブラウザ上でできると嬉しい・・
移行先候補 3： back4app（+ AWS Lambda）
back4app は BACK4APP SERVICOS DIGITAIS LTDA（本社 米カリフォルニア）の提供する BaaS です。
仮移行を通じての * 個人的な * 印象
GOOD !
- 無料枠が広い
- 最初から Parse.com の代替用として起ち上げられた純度の高い Parse Alternative であるため Parse.com との親和性が高く移行が相対的に容易
- UI, ドキュメントがわかりやすい
! GOOD ？
- 記事中のジョブ設定の問題など現時点では荒削りな側面も見られる
- Parse.com を継承するサービスとしては良好だが、逆にそのことが独立した BaaS としての新鮮味や個性の発露を削いでいる印象も？
移行先候補 4： Backand
Backand は ModuBiz Ltd（本社イスラエル Tel Aviv）の提供する BaaS です。
仮移行を通じての * 個人的な * 印象
GOOD !
- 多機能かつ拡張性に優れている上に非常に使いやすい
- テスト・デバッグ機能も充実しており UI もわかり易い
- ファイルホスティングまわりの操作以外はすべてブラウザ上で完結できるため機動性が高い
- ユーザビリティは今回の中で一番。あとは可用性とスケーラビリティ次第か
! GOOD ？
- 無料枠の狭さが残念。また、Prototype Plan $0 -> Hobby Plan $19/月 -> Work Plan $49/月 ... といった大きめの料金差に比して待遇差が小さめ
- 運営側の内部的な指標である「Cache Memory」「Compute Units」のように利用者が主体的にコントロールすることの難しい指標がプランの基準に含まれているため利用目処を立てにくい（むしろ、利用するならはじめから UNLIMITED な料金プランを選ぶべき）
- 日本のみならず国外でもまだあまりメジャーではなく情報がとても少ない。優れたサービスであるにもかかわらず世間への浸透圧が低い一因は上の料金体系にもあるのではないか？
（2018-01-19 追記）
2018年1月18日、Backand より 2月28日にサービスを終了する旨のメールが届きました。その後手元では利用していませんでしたが、品質の高いサービスであっただけに残念です。
-
メール原文と Gmail 自動翻訳結果
- 公式サイトでの表示
おわりに
手元要件の Parse.com からの移行にあたり以上よっつの環境を試してみました。最終的にこの中のひとつを「Anpi」の乗り換え先に決定して現在に至ります。当初はどれを選んだのかを書くつもりでしたが無粋にも思いやめておくことにしました。いずれも質の高いサービスでそれぞれに十分なメリットがあります。
ほんの10年ほど前には影もなかったものが日進月歩で進化していく状況にリアルタイムで向き合っていると10年後の世界への想像が膨らみます。この時代の傍らを去っていく Parse.com をユーザのひとりとして敬意と感謝の念をもって見送りたいと思います。
(tanabe)
新しい Amazon Dash Button に「マイク」が残されている理由
- 今、ワンボタンの IoT デバイスが面白い (2015-11-06) - dsas.blog.klab.org
新旧 Dash Button の違い
現在提供されている Dash Button は 2015年に米国でデビューしたオリジナルとは異なるものです。上のブログ記事でも触れた Matthew Petroff 氏のサイトには新旧 Button それぞれについて詳細かつ網羅的な興味ぶかい記事が掲載されています。
- （旧） Amazon Dash Button Teardown (2015-05-24) - mpetroff.net
The Amazon Dash Button it an Internet connected button that allows ordering a single product from Amazon.
:
Others have already posted about disassembling it, so I’ll focus mostly on the electronics, since the aforementioned blog posts are missing high-resolution images of thecircuit board and don’t quite get some details correct.
- （新） New Amazon Dash Button Teardown (JK29LP) (2016-07-12) - mpetroff.net
Amazon updated the Dash Button’s hardware to revision two earlier this year, so I decided it was time for a new teardown (here’s last year’s teardown). The new product number is JK29LP; the old product number is JK76PL. While the form factor and case remained much the same, the internals changed substantially. The major highlights are a switch from Broadcom to Atmel chips, a switch from an Energizer lithium battery to a Duracell alkaline battery, and the addition of Bluetooth Low Energy.同氏の記事を参考にしながらまず新旧 Button の主な違いを整理してみます。
:
Overall, the new Dash Button appears to be a revision designed to reduce production cost, centered around a reduction in energy usage, which allows for use of a considerably cheaper, alkaline battery.
（※余談ながら、同じ記事に注目した数日前の GIGAZINE さんの記事に先ほど気がつきましたが、特にぶつかるものでもないため草稿の内容のまま書くことにします）
電源がリチウム一次乾電池からアルカリ乾電池に
旧 Dash Button には単四型リチウム一次乾電池が内蔵されていました。
http://dsas.blog.klab.org/archives/52233150.html現在の Dash Button ではこの高価な電池に代えて米デュラセル社の単四型アルカリ乾電池が使用されています。ちなみに Amazon Dash Button は 米エナジャイザー社の Ultimate Lithium 乾電池 単4形 （二次電池ではない）1本を内蔵している。アルカリ電池に比べ「最大 9倍長持ち」を惹句とする 現時点でおそらく最強の乾電池。
データシートによると Ultimate Lithium AAA は「Max Discharge: 1.5 Amps Continuous, 2.0Amps Pulse (2 sec on / 8 sec off)」と高容量
|
|
|
|
|
- Energizer L92BP-Energizer Ultimate Lithium AAA Battery (4-Pack) - www.amazon.com
＄6.09 (一本あたり $1.52) - エナジャイザー リチウム乾電池単4形 4本パック - www.amazon.co.jp
￥1,340 (一本あたり 335円) - Duracell BATTERY,ALKALINE,AAA,16PK - www.amazon.com
＄17.99 (一本あたり $1.12) - DURACELL 【デュラセル】 アルカリ 単四 乾電池 16本パック - www.amazon.co.jp
￥2,530 (一本あたり 158円)
|
|
|
|
|
マイクロコントローラ / Wi-Fi チップの変更, BLE チップ追加, Flash メモリ容量増加
新 Button では、以前の ST マイクロエレクトロニクス社製マイクロコントローラ STM32F205 が Atmel 社（2016年4月より Microchip Technology 傘下）製 ATSAMG55J19A-MU に、Broadcom 社製の Wi-Fi モジュール BCM943362WCD4 WICED が Atmel 社製 ATWINC1500B に変更されています。一方で 新 Button の Flash メモリは倍容量の 32Mビットに増強されており、また、旧 Button には存在しなかった BLE チップがセットアップ用に追加されています。これら一連の構成要素の変更は性能強化とコストダウンの両立を目的とした判断の結果と考えられます。
U5) マイクロコントローラ：ST STM32F205 U9) Wi-Fi モジュール： Broadcom BCM943362WCD4 WICED U6) フラッシュメモリ: Micron M25P16 (16Mbit) マイクあり |
U1) マイクロコントローラ：Atmel ATSAMG55J19A-MU U19) Wi-Fi チップ：Atmel ATWINC1500B U22) BLE チップ：Cypress CYBL10563-68FNXI U15) フラッシュメモリ: Micron N25Q032 (32Mbit) マイクあり |
|
|
|
セットアップ方法の変更
新旧 Button はセットアップの方法が異なります。Android または iOS 端末と公式ショッピングアプリを利用する点は共通ですが、新版が同アプリと Button との応酬に BLE 通信を使う内容であるのに対し、旧版では Android 環境では Wi-Fi 通信、iOS 環境では超音波通信を利用する仕様でした。ちなみに、旧版では Fire Phone もセットアップに利用することが可能でした。
旧 Dash Button のセットアップ
web.archive.org に旧 Button のセットアップ手順説明ページのキャッシュが残っています。 この内容から、ボタン長押しにより移行するセットアップモードにおいて旧 Button がダミー Wi-Fi アクセスポイント 兼 音声情報のリスナーとして振る舞っていたことがわかります。
- Set Up Your Dash Button (2015-09-06 時点の記事) - www.amazon.com
（スクリーンショット）
※下の図は上記キャッシュの iOS 端末向けの説明箇所からの抜粋
※動画は旧版のセットアップの様子（Youtube 2015ｰ08-06 投稿, iPhone）3分20秒あたりから
|
|
新 Dash Button のセットアップ
BLE チップが搭載された新 Button ではセットアップ時の公式アプリとの応酬に BLE 通信が利用されています。
この変更によって Android / iOS プラットフォームでの手順が統一されシンプルでスマートになった反面、旧版では特に言及されていなかった対象 OS バージョンが「iOS 8.3 or higher, Android 4.1 or higher」に限定される形となりました。また、BLE 非対応の Fire Phone（2015年下期販売終了）も手順説明から消えています。
現在の Dash Button セットアップ手順説明ページ
- Set Up Your Dash Button - www.amazon.com
（2016-12-14 時点のスクリーンショット）- Dash Buttonをセットアップする - www.amazon.co.jp
（2016-12-14 時点のスクリーンショット）
- Dash Buttonをセットアップする - www.amazon.co.jp
画面遷移
|
|
|
|
|
|
|
|
|
|
新 Dash Button にマイクが残されている理由
旧 Button が iOS 端末でのセットアップ時に音声信号を利用するためにマイクロフォンを内蔵していたことは理解できます。では、なぜ BLE 通信を利用する新 Button にもマイクが残されているのでしょう？使わない部品であれば製造コスト削減のためにも撤去するほうが合理的なはずです。まさか Amazon が何か良からぬことを企んでいるのでしょうか？
- Amazon Dashからマイクが見つかる、これ盗聴器だろ - jisaka.blog.jp
- Set Up Your Dash Button - www.amazon.com
Note: Some Dash Buttons and phones do not support Bluetooth connections. If your phone does not connect to your button, select Skip Bluetooth Setup. Then, follow the instructions in the app. Your phone then uses other connection options.
- Dash Buttonをセットアップする - www.amazon.co.jp
注: スマートフォンとDash Buttonが接続されない場合は、 Bluetoothをスキップを選択します。次に、アプリの画面に 表示される手順に従います。
公式アプリが Button と BLE 接続を確立できない場合はどのような所作となるのでしょう？興味を感じ試してみることにしました。
BLE 接続不可の状況を再現するもっとも簡単な方法は「Button からの BLE アドバタイジングを発生させない」ことです。つまり、アプリに求められたタイミングでわざと Button のセットアップモードを起動せずそのまま放置しておけばよいでしょう。
結論として、アプリは BLE 接続をしばらく試行した後に自動的に旧 Button でのセットアップシーケンスへ移行することがわかりました。 BLE 接続を諦めると、Android 版アプリは Button のダミー AP へ Wi-Fi 接続の切り替えを試み、iOS 版アプリは端末のスピーカーへ Button を接近させることを利用者へ促します。そのタイミングで新 Button をセットアップモードで起動すると旧スタイルでのセットアップ処理が滞りなく行われます。
つまり、新 Button のセットアップモードは旧 Button でのそれと同一の I/F を備えています。この実装は、BLE の利便性を取り入れつつも間口の広い旧版での機構を温存することによりセットアップ段階でのトラブルを可能な限り吸収することに加え、旧 Button - 新アプリ間の互換性をシンプルに保つことを目的とするものと考えられます。
Android, iOS 端末それぞれでこの操作を行った様子の動画を以下に示します。
- 新 Button を旧スタイルでセットアップ - Android 版（2分9秒 環境音あり）
- 新 Button を旧スタイルでセットアップ - iOS 版（1分33秒 環境音あり）
|
|
図のように iOS 版に関しては本項の冒頭に引用した英語版の説明記事とほぼ整合しますが、日本語版記事は翻訳が十分ではなく（意図的なもの？）、また、Android ユーザが記事中のメッセージを目にする機会はありません。
米国内にのみ存在する旧 Button は電池寿命で徐々に消えていく過程にあります。また、BLE 非対応の端末も次第に世間から姿を消していくことでしょう。上に掲げた現 Dash Button の二段構えのセットアップ I/F はあるいは過渡的なものかもしれません。
(tanabe)
既成の BLE デバイスを自作プログラムから利用する試み
- BLE デバイス間の通信内容をパケットレベルで読み解いてみる
題材には低価格で出回っているありふれた Anti-Lost 系 BLE デバイス A を選びました。この小さなデバイスには LED・ブザーと押しボタンスイッチが 実装されており、対向スマホアプリとの間で双方向のやりとりが可能なつくりになっています。
デバイス A の UI
デバイス A とアプリの連携に必要な処理
前回の記事から、デバイス A とアプリの連携に関する要素をピックアップしてみます。
- アプリからデバイス A の LED・ブザーをコントロール
- 「Scene 6: アプリからデバイス A の LED・ブザーを操作」
Frame 616
対向アプリ上の所定のボタンを押下すると、Frame 345, Frame 238 の示す、 "「Immediate Alert」サービス配下の「Alert Level」キャラクタリスティック" の Value Handle 0x0025 に値「2（High Alert）」が書き込まれる
デバイス A の LED・ブザーはファームウェアレベルでこの Alert Level キャラクタリスティックに紐づけられている模様。High Alert 値が書き込まれるとそれに反応して短時間 LED とブザーが ON になる
- 「Scene 6: アプリからデバイス A の LED・ブザーを操作」
- デバイス A のボタン押下をアプリへ通知
- 「Scene 5: デバイス A ボタン押下時のアプリへの通知を設定」
Frame 491
Frame 453、Frame 439、Frame 453 の示す通り、ハンドル 0x0036 は、 "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）配下の Client Characteristic Configuration Descriptor (CCCD)" である
当該ユーザ定義キャラクタリスティック（UUID = 0xFFE1）のプロパティには Notify が設定されており、クライアントである対向アプリから CCCD 0x0036 に Notification bit (0x0001) を書き込んでおくことで、このキャラクタリスティックの値が更新された時に Value Handle である 0x0035 経由でアプリ側へ通知（Notification）が行われるようになる
- 「Scene 7: デバイス A のボタンを押すとアプリへ通知」
Frame 711
デバイス A の物理ボタンはファームウェアレベルで Frame 439 の示す "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）" に紐づけられている模様。このボタンを押すと当該キャラクタリスティックの値がデバイス内部で更新され Frame 491 での仕込みに基づきアプリ側へ通知が行われる
- 「Scene 5: デバイス A ボタン押下時のアプリへの通知を設定」
サービス・キャラクタリスティック・デスクリプタの UUID について
BLE ネイティブの世界では所定のキャラクタリスティックやデスクリプタの I/O には各エントリに紐づけられたハンドルが使用されますが、抽象化された Android API での処理対象はオブジェクトです。所定のキャラクタリスティックやデスクリプタのオブジェクトの取得にはそれぞれの UUID が必要であるため、プログラムの記述に際しては、パケットログ上に記録された所定のハンドルがどの UUID のエントリのものであるかを正確に把握する必要があります。
また、サービス - キャラクタリスティック - デスクリプタは階層関係にあるため、所定のエントリのオブジェクトを取得する手続きは最上位にあるサービスのオブジェクトが常に起点となります。
以下に、パケットログから所定のサービス以下の各エントリの UUID を見つける方法と、各 UUID からそれぞれのエントリのオブジェクトを取得する Android コードの例を示します。
パケットログから所定のサービス以下の各エントリの UUID を拾う
- 前回記事中のパケットログ Frame 229 では 0x0001 - 0xffff のハンドル空間を対象に Read By Group Type Request で GATT Primary Service Declaration を照会、そのレスポンスが Frame 231 です
（クリックで大きく表示）
ここではレスポンスに含まれる 3件のレコードのうち 2件めに注目してみます
Opcode: Read By Group Type Response (0x11) : Attribute Data, Handle: 0x000c, Group End Handle: 0x000f Handle: 0x000c Group End Handle: 0x000f Value: 0118 :- Primary Service Declaration の照会に対する Read By Group Type Response の「Value」には当該サービスの UUID が格納される
- この例では 16ビット UUID = 0x1801 であり、これは、BLE 既定の Generic Attribute サービスを示す
- 当該サービスはハンドルグループ 0x000c - 0x000f を占有する
- Frame 287 では上記のハンドルグループ 0x000c - 0x000f を対象に Read By Type Request で GATT Characteristic Declaration を照会、そのレスポンスが Frame 289 です
（クリックで大きく表示）
レスポンスに注目します
Opcode: Read By Type Response (0x09) : Attribute Data, Handle: 0x000d Handle: 0x000d Value: 200e00052a- Characteristic Declaration の照会に対する Read By Type Response の「Value」には当該キャラクタリスティックのプロパティ・Value Handle・UUID が格納される（詳細：1a, 2a, 1b）
（※表は BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part G] page 532 より） - ここでは「value: 200e00052a」につき、プロパティ = 0x20 (Indicate), Characteristic Value Handle = 0x000e, 16ビット UUID = 0x2A52
- 16ビット UUID = 0x2A52 は、BLE 既定の Service Changed キャラクタリスティックを示す
- Characteristic Declaration の照会に対する Read By Type Response の「Value」には当該キャラクタリスティックのプロパティ・Value Handle・UUID が格納される（詳細：1a, 2a, 1b）
- Frame 302 では残りのハンドル 0x000f についての情報を GATT へ Find Information Request で照会、そのレスポンスが Frame 305 です
（クリックで大きく表示）
レスポンスに注目します
Opcode: Find Information Response (0x05) UUID Format: 16-bit UUIDs (0x01) Handle: 0x000f UUID: Client Characteristic Configuration (0x2902)
- ハンドル 0x000f は Client Characteristic Configuration Descriptor (CCCD) であり、この CCCD は直前の Indicate プロパティを持つ Service Changed キャラクタリスティックに属する
（※CCCD の 16ビット UUID は 0x2902 固定）
- ハンドル 0x000f は Client Characteristic Configuration Descriptor (CCCD) であり、この CCCD は直前の Indicate プロパティを持つ Service Changed キャラクタリスティックに属する
以上のことから、デバイス A 上の Generic Attribute サービスの構成は以下の内容であることがわかります。
Generic Attribute サービス（UUID = 0x1801）
| Handle Group = 0x000c - 0x000f
|
+-- Service Changed キャラクタリスティック（UUID = 0x2A52）
| Handle = 0x000d, Value Handle = 0x000e
|
+-- Client Characteristic Configuration Descriptor (UUID = 0x2902）
Handle = 0x000f
所定の UUID のエントリのオブジェクトを取得する
ここまでに登場した UUID はすべて 16ビット値でしたが、16 ビット UUID は Bluetooth 用にアサインされている本来の 128ビット UUID の固定部分（BASE_UUID）を省略した表現です。
- BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part B] page 227
2.5 SEARCHING FOR SERVICES : 2.5.1 UUID : To reduce the burden of storing and transferring 128-bit UUID values, a range of UUID values has been pre-allocated for assignment to often-used, registered purposes. The first UUID in this pre-allocated range is known as the Bluetooth Base UUID and has the value 00000000-0000-1000-8000-00805F9B34FB, :
Android API を用いて前出の Generic Attribute サービスと Service Changed キャラクタリスティック、およびその配下の Client Characteristic Configuration Descriptor のオブジェクトを取得するコードのイメージを示します。
private BluetoothGatt mBtGatt;
private BluetoothGattCharacteristic mChServiceChanged;
private BluetoothGattDescriptor mCCCD;
// Generic Attribute サービス の UUID
private UUID mUuidSvcGenericAttribute = UUID.fromString("00001801-0000-1000-8000-00805f9b34fb");
// Service Changed キャラクタリスティックの UUID
private UUID mUuidChServiceChanged = UUID.fromString("00002a52-0000-1000-8000-00805f9b34fb");
// Client Characteristic Configuration Descriptor の UUID （固定値）
private UUID mUuidCCCD = UUID.fromString("00002902-0000-1000-8000-00805f9b34fb");
:
private BluetoothGattCallback mGattCallback = new bleGattCallback();
:
// デバイス A へ接続後、GATT の提供する各サービス以下の一覧を取得
mBtGatt.discoverServices();(mCtx, false, mGattCallback);
:
// GATT イベントハンドラ
private class bleGattCallback extends BluetoothGattCallback {
@Override
// GATT サービス一覧取得完了
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
super.onServicesDiscovered(gatt, status);
// デバイス A の Generic Attribute サービスの
// Service Changed キャラクタリスティックオブジェクトを取得
BluetoothGattService svc = gatt.getService(mUuidSvcGenericAttribute);
mChServiceChanged = svc.getCharacteristic(mUuidChServiceChanged);
// Service Changed キャラクタリスティックの
// Client Characteristic Configulation Descriptor を取得
mCCCD = mChServiceChanged.getDescriptor(mUuidCCCD);
:
}
ちなみに、アプリ開発の初期に BluetoothGattCallback の onServicesDiscovered() に次の要領のコードを挿入して 各 GATT サービス配下の全エントリの UUID を階層的に出力し保存しておくと何かと便利です。
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
super.onServicesDiscovered(gatt, status);
List<BluetoothGattService> serviceList = gatt.getServices();
Log.d(TAG, "onServicesDiscovered: serviceList.size=" + serviceList.size());
for (BluetoothGattService s : serviceList) {
Log.d(TAG, "onServicesDiscovered: svc uuid=" + s.getUuid().toString());
List<BluetoothGattCharacteristic> chlist = s.getCharacteristics();
Log.d(TAG, "onServicesDiscovered: chrlist.size=" + chlist.size());
for (BluetoothGattCharacteristic c : chlist) {
UUID uuid = c.getUuid();
Log.d(TAG, "onServicesDiscovered: chr uuid=" + uuid.toString());
List<BluetoothGattDescriptor> dlist = c.getDescriptors();
Log.d(TAG, "onServicesDiscovered: desclist.size=" + dlist.size());
for (BluetoothGattDescriptor d : dlist) {
Log.d(TAG, "onServicesDiscovered: desc uuid=" + d.getUuid());
}
}
}
デバイス A への接続後に上のコードを実行した際のログです。（※見やすさのためにサービスごとに改行を挿入）
当然ながら、この内容は前回採取したパケットログ内の各エントリの情報と符合しています。
作成したアプリ
以上の内容にもとづいてアプリを作成しました。ごくシンプルなものですが期待通りに動いています。
ソースコード一式
動画：動作の様子
作成した Android アプリとデバイス A の連携の様子を収めた動画です。デバイス A は UI 部分のみを露出しています。
（34秒 アラーム音あり 音量注意）
メモ：実装手順など
private BluetoothAdapter mBtAdapter; private BluetoothLeScanner mBtScanner; private BluetoothDevice mBtDevice; private BluetoothGatt mBtGatt;
1. BluetoothAdapter 〜 BluetoothLeScanner を取得
- BluetoothAdapter - developer.android.com
Represents the local device Bluetooth adapter. The BluetoothAdapter lets you perform fundamental Bluetooth tasks, such as initiate device discovery, query a list of bonded (paired) devices, instantiate a BluetoothDevice using a known MAC address, and create a BluetoothServerSocket to listen for connection requests from other devices, and start a scan for Bluetooth LE devices. : static BluetoothAdapter getDefaultAdapter() Get a handle to the default local Bluetooth adapter. - BluetoothAdapter - getBluetoothLeScanner - developer.android.com
BluetoothLeScanner getBluetoothLeScanner () Returns a BluetoothLeScanner object for Bluetooth LE scan operations.
- BluetoothLeScanner - developer.android.com
BluetoothLeScanner This class provides methods to perform scan related operations for Bluetooth LE devices. An application can scan for a particular type of Bluetooth LE devices using ScanFilter. It can also request different types of callbacks for delivering the result.
- BluetoothLeScanner - developer.android.com
mBtAdapter = BluetoothAdapter.getDefaultAdapter(); mBtScanner = mBtAdapter.getBluetoothLeScanner();
2. アドバタイジングパケットのスキャン 〜 対象とする BluetoothDevice を取得
- BluetoothLeScanner - startScan - developer.android.com
startScan void startScan (ScanCallback callback) Start Bluetooth LE scan with default parameters and no filters. The scan results will be delivered through callback. Requires BLUETOOTH_ADMIN permission. An app must hold ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission in order to get results. Parameters callback ScanCallback: Callback used to deliver scan results. :
- ScanCallback - developer.android.com
- onScanResult - developer.android.com
onScanResult void onScanResult (int callbackType, ScanResult result) Callback when a BLE advertisement has been found. Parameters callbackType int: Determines how this callback was triggered. Could be one of CALLBACK_TYPE_ALL_MATCHES, CALLBACK_TYPE_FIRST_MATCH or CALLBACK_TYPE_MATCH_LOST result ScanResult: A Bluetooth LE scan result.- ScanResult - getDevice - developer.android.com
getDevice BluetoothDevice getDevice () Returns the remote bluetooth device identified by the bluetooth device address.
- ScanResult - getDevice - developer.android.com
- onScanResult - developer.android.com
private ScanCallback mScanCallback = new bleScanCallback();
:
mBtScanner.startScan(mScanCallback);
:
private class bleScanCallback extends ScanCallback {
@Override
public void onScanResult(int callbackType, ScanResult result) {
super.onScanResult(callbackType, result);
if (.......) {
mBtDevice = result.getDevice();
}
}
@Override
public void onScanFailed(int errorCode) {
super.onScanFailed(errorCode);
Log.e(TAG, "onScanFailed: err=" + errorCode);
}
}
3. デバイスへの接続
- BluetoothDevice - connectGatt - developer.android.com
BluetoothGatt connectGatt (Context context, boolean autoConnect, BluetoothGattCallback callback) Connect to GATT Server hosted by this device. Caller acts as GATT client. The callback is used to deliver results to Caller, such as connection status as well as any further GATT client operations. The method returns a BluetoothGatt instance. You can use BluetoothGatt to conduct GATT client operations. : callback BluetoothGattCallback: GATT callback handler that will receive asynchronous callbacks. :
- BluetoothGattCallback - developer.android.com
- onConnectionStateChange - developer.android.com
void onConnectionStateChange (BluetoothGatt gatt, int status, int newState) Callback indicating when GATT client has connected/disconnected to/from a remote GATT server. : newState int: Returns the new connection state. Can be one of STATE_DISCONNECTED or STATE_CONNECTED :
- onConnectionStateChange - developer.android.com
private BluetoothGattCallback mGattCallback = new bleGattCallback();
:
mBtGatt = mBtDevice.connectGatt(mCtx, false, mGattCallback);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
public void onConnectionStateChange(BluetoothGatt gatt, int status,
int newState) {
super.onConnectionStateChange(gatt, status, newState);
if (newState == BluetoothProfile.STATE_CONNECTED) {
// 接続確立 - デバイスの GATT サービス一覧の取得へ
} else if (newState == BluetoothProfile.STATE_DISCONNECTED) {
// 切断完了の処理
}
}
:
4. GATT サービス - キャラクタリスティック - デスクリプタを探索 〜 必要なオブジェクトを取得
- BluetoothGatt - discoverServices - developer.android.com
boolean discoverServices () Discovers services offered by a remote device as well as their characteristics and descriptors. This is an asynchronous operation. Once service discovery is completed, the onServicesDiscovered(BluetoothGatt, int) callback is triggered. If the discovery was successful, the remote services can be retrieved using the getServices() function. :
- BluetoothGattCallback - onServicesDiscovered - developer.android.com
void onServicesDiscovered (BluetoothGatt gatt, int status) Callback invoked when the list of remote services, characteristics and descriptors for the remote device have been updated, ie new services have been discovered. :
- BluetoothGatt - getService - developer.android.com
getService BluetoothGattService getService (UUID uuid) Returns a BluetoothGattService, if the requested UUID is supported by the remote device. This function requires that service discovery has been completed for the given device. If multiple instances of the same service (as identified by UUID) exist, the first instance of the service is returned. Requires BLUETOOTH permission. Parameters uuid UUID: UUID of the requested service Returns BluetoothGattService BluetoothGattService if supported, or null if the requested service is not offered by the remote device.
- BluetoothGattService - getCharacteristic - developer.android.com
getCharacteristic BluetoothGattCharacteristic getCharacteristic (UUID uuid) Returns a characteristic with a given UUID out of the list of characteristics offered by this service. This is a convenience function to allow access to a given characteristic without enumerating over the list returned by getCharacteristics() manually. If a remote service offers multiple characteristics with the same UUID, the first instance of a characteristic with the given UUID is returned. Parameters uuid UUID Returns BluetoothGattCharacteristic GATT characteristic object or null if no characteristic with the given UUID was found.
- BluetoothGattCharacteristic - getDescriptor - developer.android.com
getDescriptor BluetoothGattDescriptor getDescriptor (UUID uuid) Returns a descriptor with a given UUID out of the list of descriptors for this characteristic. Parameters uuid UUID Returns BluetoothGattDescriptor GATT descriptor object or null if no descriptor with the given UUID was found.
- BluetoothGattCharacteristic - getDescriptor - developer.android.com
- BluetoothGattService - getCharacteristic - developer.android.com
private BluetoothGattCharacteristic mChAlertLevel = null;
private BluetoothGattCharacteristic mChUser1 = null;
private BluetoothGattDescriptor mDescUser1 = null;
// デバイス A の提供するサービス・キャラクタリスティック群の UUID より
private UUID mUuidSvcImAlert = UUID.fromString("00001802-0000-1000-8000-00805f9b34fb");
private UUID mUuidChAlertLevel = UUID.fromString("00002a06-0000-1000-8000-00805f9b34fb");
private UUID mUuidSvcUser1 = UUID.fromString("0000ffe0-0000-1000-8000-00805f9b34fb");
private UUID mUuidChUser1 = UUID.fromString("0000ffe1-0000-1000-8000-00805f9b34fb");
// UUID for Client Characteristic Configuration Descriptor
// - BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part G] page 537
private UUID mUuidCCCD = UUID.fromString("00002902-0000-1000-8000-00805f9b34fb");
:
private BluetoothGattCallback mGattCallback = new bleGattCallback();
:
mBtGatt.discoverServices();(mCtx, false, mGattCallback);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
// GATT サービス一覧取得完了
public void onServicesDiscovered(BluetoothGatt gatt, int status) {
super.onServicesDiscovered(gatt, status);
// デバイス A の Immediate Alert サービスの
// Alert Level キャラクタリスティックオブジェクトを取得
BluetoothGattService svc = gatt.getService(mUuidSvcImAlert);
mChAlertLevel = svc.getCharacteristic(mUuidChAlertLevel);
// デバイス A のユーザ定義サービス 1 の ユーザ定義キャラクタリスティックの
// Client Characteristic Configulation Descriptor を取得
svc = gatt.getService(mUuidSvcUser1);
mChUser1 = svc.getCharacteristic(mUuidChUser1);
mDescUser1 = mChUser1.getDescriptor(mUuidCCCD);
:
}
5. 所定のキャラクタリスティックからの通知を有効に
- BluetoothGatt - setCharacteristicNotification - developer.android.com
boolean setCharacteristicNotification ( BluetoothGattCharacteristic characteristic, boolean enable) Enable or disable notifications/indications for a given characteristic. Once notifications are enabled for a characteristic, a onCharacteristicChanged(BluetoothGatt, BluetoothGattCharacteristic) callback will be triggered if the remote device indicates that the given characteristic has changed. Requires BLUETOOTH permission. Parameters characteristic BluetoothGattCharacteristic: The characteristic for which to enable notifications enable boolean: Set to true to enable notifications/ indications : - BluetoothGattDescriptor - setValue - developer.android.com
boolean discoverServices () setValue boolean setValue (byte[] value) Updates the locally stored value of this descriptor. This function modifies the locally stored cached value of this descriptor. To send the value to the remote device, call writeDescriptor(BluetoothGattDescriptor) to send the value to the remote device. Parameters value byte: New value for this descriptor :
- BluetoothGatt - writeDescriptor - developer.android.com
writeDescriptor boolean writeDescriptor (BluetoothGattDescriptor descriptor) Write the value of a given descriptor to the associated remote device. A onDescriptorWrite(BluetoothGatt, BluetoothGattDescriptor, int) callback is triggered to report the result of the write operation. Requires BLUETOOTH permission. Parameters descriptor BluetoothGattDescriptor: Descriptor to write to the associated remote device :
- BluetoothGatt - writeDescriptor - developer.android.com
// デバイス A への Alert 指示用
private byte[] mCmdAlertOff = new byte[] {(byte)0x00}; // OFF (No Alert)
private byte[] mCmdAlertOn = new byte[] {(byte)0x02}; // ON (High Alert)
:
// デバイス A のユーザ定義サービス 1 の ユーザ定義キャラクタリスティックの
// Client Characteristic Configulation Descriptor を取得
svc = gatt.getService(mUuidSvcUser1);
mChUser1 = svc.getCharacteristic(mUuidChUser1);
mDescUser1 = mChUser1.getDescriptor(mUuidCCCD);
// 同キャラクタリスティックの値変更時の通知を有功にして
// 同 CCCD へ ENABLE_NOTIFICATION_VALUE を書き込んで通知へ待機
mBtGatt.setCharacteristicNotification(mChUser1, true);
byte[] val = new byte[] {(byte)0x01, (byte)0x00};
mDescUser1.setValue(val);
mBtGatt.writeDescriptor(mDescUser1);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
public void onCharacteristicChanged (BluetoothGatt gatt,
BluetoothGattCharacteristic ch) {
Log.d(TAG, "onCharacteristicChanged");
// デバイス A のユーザ定義キャラクタリスティック 1 からの通知を受信
if (ch == mChUser1) {
Toast.makeText(mCtx, "* P U S H E D *", Toast.LENGTH_SHORT).show();
}
}
@Override
public void onDescriptorWrite (BluetoothGatt gatt,
BluetoothGattDescriptor desc,
int status) { // writeDescriptor() 結果
super.onDescriptorWrite(gatt, desc, status);
Log.d(TAG, "onDescriptorWrite: sts=" + status);
if (desc == mDescUser1) {
// デバイス A のユーザ定義サービス 1 の ユーザ定義キャラクタリスティックの
// Client Characteristic Configulation Descriptor への書き込みが完了
}
}
:
6. 所定のキャラクタリスティックへの書き込み
- BluetoothGattCharacteristic - setValue - developer.android.com
setValue boolean setValue (byte[] value) Updates the locally stored value of this characteristic. This function modifies the locally stored cached value of this characteristic. To send the value to the remote device, call writeCharacteristic(BluetoothGattCharacteristic) to send the value to the remote device. Parameters value byte: New value for this characteristic :
- BluetoothGatt - writeCharacteristic - developer.android.com
boolean writeCharacteristic ( BluetoothGattCharacteristic characteristic) Writes a given characteristic and its values to the associated remote device. Once the write operation has been completed, the onCharacteristicWrite(BluetoothGatt, BluetoothGattCharacteristic, int) callback is invoked, reporting the result of the operation. Requires BLUETOOTH permission. Parameters characteristic BluetoothGattCharacteristic: Characteristic to write on the remote device
- BluetoothGatt - writeCharacteristic - developer.android.com
// デバイス A への Alert 指示用
private byte[] mCmdAlertOff = new byte[] {(byte)0x00}; // OFF (No Alert)
private byte[] mCmdAlertOn = new byte[] {(byte)0x02}; // ON (High Alert)
:
mChAlertLevel.setValue(mCmdAlertOn);
mBtGatt.writeCharacteristic(mChAlertLevel);
:
private class bleGattCallback extends BluetoothGattCallback {
@Override
public void onCharacteristicWrite(BluetoothGatt gatt,
BluetoothGattCharacteristic ch,
int status) { // writeCharacteristic 結果
super.onCharacteristicWrite(gatt, ch, status);
if (ch == mChAlertLevel) {
Log.d(TAG, "mChAlertLevel: onCharacteristicWrite: sts=" + status);
}
}
:
(tanabe)
BLE デバイス間の通信内容をパケットレベルで読み解いてみる
- 技適マークつき BLE パケットスニファを入手する
BLE の通信プロトコルは複雑ですが、パケットの内容を適宜精査すれば 座学的な情報の向こう側にある実像を捉えることが可能となるでしょう。
デバイス A の UI
操作内容
デバイス A と Android 端末を使って以下の操作を行いスニファで BLE パケットのログを採取しました。
- デバイス A の電源を入れる
- Android 端末上の対向アプリからデバイスを探索しデバイス A との接続を確立
- アプリからデバイス A の LED＋ブザーを ON にする
- デバイス A のボタンを押しアプリへ通知を送る
- アプリ上でデバイス A との接続を切断
応酬の全体像
スニファの Wireshark ログより
上の操作時に収集したパケットログの全体図です。 （クリックで大きく表示）
要約
パケットログの内容の要約を以下に示します。 （クリックで大きく表示）
- デバイス A の電源を入れる
- デバイス A がアドバタイジングを開始 (ADV_IND)
- スマホ上の対向アプリからデバイスを探索しデバイス A との接続を確立
- デバイスのスキャン (SCAN_REQ / SCAN_RSP) を経て接続要求 (CONNECT_REQ) 〜接続が確立するとデバイス A はアドバタイジングを停止
- 機能情報を交換 (LL_FEATURE_REQ / LL_FEATURE_RSP)
- デバイス A の提供する GATT プライマリサービス一覧を取得
- 各サービス配下のエントリ（Included Service, キャラクタリスティック）一覧を取得
- 各キャラクタリスティック配下のデスクリプタを取得
- デバイス A のボタンが押された時に通知されるよう所定の Client Characteristic Configuration descriptor へアプリから Notification Bit 0x0001 を書き込む
- アプリからデバイス A の LED＋ブザーを ON にする
- アプリ上の所定のボタンが押されたタイミングでアプリはデバイス A の Immediate Alert サービス配下の Alert Level キャラクタリスティックへ値 2 (High Alert)を書き込む。これにより一定時間 A の LED とブザーが ON になる
- デバイス A のボタンを押しアプリへ通知を送る
- デバイス A のボタンが押されたタイミングでデバイス A は自機のユーザ定義サービス 1 (UUID=0xFFE0) 配下のユーザ定義キャラクタリスティック (UUID=0xFFE1) へ値 1 を書き込む。当該キャラクタリスティック配下の Client Characteristic Configuration descriptor にはアプリ側から予め Notification Bit がセットされているためアプリへ通知される
- アプリ上でデバイス A との接続を切断
- アプリからデバイス A へ LL_TERMINATE_IND を送る
応酬の詳細
全体の流れを見渡したところで次に個々のパケットデータを読み進めていきます。
- 以下の記事には Wireshark のスクリーンショットをログとして添えています （それぞれクリックで大きく表示）
- ログには BLE パケットデータ本体に加え nRF Sniffer が解析の便宜のためにログへ出力する「Nordic BLE sniffer meta」ヘッダが含まれています
- nRF Sniffer User Guide v1.1 (PDF) - www.nordicsemi.com Page 8 より
4 Using Wireshark All BLE packets detected by the Sniffer are passed to Wireshark and are wrapped in a header which contains useful meta-information not present in the BLE packet itself. Wireshark dissects the packets and separates the actual packet from the meta-information. :
- nRF Sniffer User Guide v1.1 (PDF) - www.nordicsemi.com Page 8 より
- 記事には下記資料からの抜粋へのリンクを参照用に適宜挿入しています
- BLUETOOTH SPECIFICATION Version 4.2 (PDF) - www.bluetooth.org
- 随所に「https://developer.bluetooth.org/gatt/」下のサービス・キャラクタリスティックの記事へのリンクを張っていますが、2016年7月頃までは参照可能だった各記事が現在はリンク切れになっており（再構成中？）、さらに現時点では代替ページが見当たらないためリンク先はやむなく http://web.archive.org/ 上のキャッシュとしています。ただし web.archive.org 上にも保存履歴のない記事については一階層上のページへのリンクを張っています
例：「Link Loss」サービスの単独ページのキャッシュは web.archive.org にも見当たらないため、上位のサービス一覧ページのキャッシュをターゲットに
局面
- Scene 1: デバイス A のアドバタイジングと SCAN_REQ / SCAN_RSP
- Scene 2: 接続の確立と情報交換
- Scene 3: デバイス A の GATT サービス群の取得
- Scene 4: デバイス A 各サービス配下のキャラクタリスティック - デスクリプタの取得
- Scene 5: デバイス A ボタン押下時のアプリへの通知を設定
- Scene 6: アプリからデバイス A の LED・ブザーを操作
- Scene 7: デバイス A のボタンを押すとアプリへ通知
- Scene 8: アプリ側からデバイス A との接続を切断
Scene 1: デバイス A のアドバタイジングと SCAN_REQ / SCAN_RSP
Frame 124 - 126 はデバイス A 発のアドバタイジングパケット
- 全 40 チャネルのうちアドバタイジングパケット用の 37, 38, 39 の 3 チャネルが順次使用されていることが見てとれる
- 「0x8e89bed6」の Access Address はアドバタイジングチャネルパケットで使用される固定値
- デバイス A のアドバタイジングのタイプは Connectable Undirected（詳細： 1, 2, 3, 4） であることを示す一般的な「ADV_IND」である
- 「Advertising Data: 020106020a000702031802180418」に含まれる不完全 16ビットサービスクラス UUID は次の内容
- 16 bit uuid: 0x1803 --> 既定の「Link Loss」サービス
- 16 bit uuid: 0x1802 --> 既定の「Immediate Alert」サービス
- 16 bit uuid: 0x1804 --> 既定の「Tx Power」サービス
|
Frame 124
|
Frame 125
|
Frame 126
|
接続に際し対向アプリがデバイス A に対して SCAN_REQ を発行
デバイス A が対向アプリからの SCAN_REQ に対し SCAN_RSP を返信。ここでは ScanRspData としてデバイスのローカルネームが渡されている
Scene 2: 接続の確立と情報交換
対向アプリがデバイス A に対して CONNECT_REQ（詳細：1a, 2a, 1b, 2b）を発行して接続を試みる
- 「Connection Request」中の「Connection Access Address」には、接続確立後のデータ通信において Access Address として双方が一意に使用する任意のアドレスが含まれる。ここでは「0xa6a188c8」
- 「Connection Request」中の「Channel map」には接続確立後のデータ通信で使用するチャネル番号のリストが提示される。ここでは 0 - 36 の全データチャネルが指定されている
- その他のパラメータについては上のリンクの資料を参照のこと
- CONNECT_REQ に対する直接のレスポンスは発生しない。接続が確立するとデータ通信アイドル時にスレーブ - マスタ間で空パケット（Empty PDU）の応酬が始まるためこれが接続成否の判定に用いられる
Frame 218, 224 は接続確立後の最初の応酬。接続が確立すると対向アプリはマスタ、デバイス A はスレーブの位置づけとなる。ここでは リンク層制御 PDU の LL_FEATURE_REQ および LL_FEATURE_RSP によりマスタ - スレーブ間で Feature Exchange を行っている。ここでは双方とも「Supported feature: LE Encryption (0)」のみを提示（ただしここでは以降の通信において暗号化は行われていない）
|
Frame 218
|
Frame 224
|
Frame 222 ではアプリ側が「Device Name」を要求し Frame 226 でデバイス A 側がそれに応えている。
「Device Name」は、既定の Generic Access（GAP）サービス配下の既定のキャラクタリスティック（UUID = 0x2A00）であり、GATT サーバは必ず GAP サービスを含んでいる（詳細：1, 2）
（GAP サービスおよび Device Name キャラクタリスティックは後続の Frame 231, Frame 266 であらためて表に現れる）
Scene 3: デバイス A の GATT サービス群の取得
（Scene 3, Scene 4 共通の基礎知識）
BLUETOOTH SPECIFICATION Version 4.2(PDF) [Vol 3, Part G] より
2.6 GATT PROFILE HIERARCHY
2.6.1 Overview, 2.6.2 Service, 2.6.3 Included Services, 2.6.4 Characteristic
3 SERVICE INTEROPERABILITY REQUIREMENTS
3.1 SERVICE DEFINITION, 3.2 INCLUDE DEFINITION, 3.3 CHARACTERISTIC DEFINITION
3.3.1 Characteristic Declaration
3.3.1.1 Characteristic Properties, 3.3.1.2 Characteristic Value Attribute Handle, 3.3.1.3 Characteristic UUID
3.3.2 Characteristic Value Declaration
初期処理として、マスタはスレーブの提供するサービス一覧を取得する （詳細：1, 2, 3）
- アプリ側が、デバイス A の GATT サーバの提供する公開サービス（プライマリサービス）の問合せを開始。 以降、GATT サーバ上の所定のサービスへアクセスするためのハンドルのアドレスと当該サービスの種類を識別する UUID を順次取得する
- ハンドルのアドレス空間は 0x0000 - 0xFFFF であり GATT サーバ側の応答に応じて照会範囲を絞っていく
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用）
まずハンドル 0x0001 - 0xffff 全範囲についてプライマリサービスを照会
Opcode: Read By Group Type Request (0x10)
Starting Handle: 0x0001
Ending Handle: 0xffff
UUID: GATT Primary Service Declaration (0x2800)
以下のみっつのサービスの情報が得られた
- ハンドルグループ 0x0001 - 0x000b：既定の「Generic Access」サービス（UUID = 0x1800）が使用
- ハンドルグループ 0x000c - 0x000f：既定の「Generic Attribute」サービス（UUID = 0x1801）が使用
- ハンドルグループ 0x0010 - 0x0022：既定の「Device Information」サービス（UUID = 0x180A）が使用
Opcode: Read By Group Type Response (0x11)
Length: 6
Attribute Data, Handle: 0x0001, Group End Handle: 0x000b
Handle: 0x0001
Group End Handle: 0x000b
Value: 0018
Attribute Data, Handle: 0x000c, Group End Handle: 0x000f
Handle: 0x000c
Group End Handle: 0x000f
Value: 0118
Attribute Data, Handle: 0x0010, Group End Handle: 0x0022
Handle: 0x0010
Group End Handle: 0x0022
Value: 0a18
続けてハンドル 0x0023 - 0xffff 範囲のプライマリサービスを照会
以下のみっつのサービスの情報が得られた
- ハンドルグループ 0x0023 - 0x0025：既定の「Immediate Alert」サービス（UUID = 0x1802）が使用
- ハンドルグループ 0x0026 - 0x002a：既定の「Tx Power」サービス（UUID = 0x1804）が使用
- ハンドルグループ 0x002b - 0x002d：既定の「Link Loss」サービス（UUID = 0x1803）が使用
続けてハンドル 0x002e - 0xffff 範囲のプライマリサービスを照会
以下のみっつのサービスの情報が得られた
- ハンドルグループ 0x002e - 0x0032：既定の「Battery Service」サービス（UUID = 0x180F）が使用
- ハンドルグループ 0x0033 - 0x0037：ユーザ定義のサービス 1（UUID = 0xFFE0）が使用
- ハンドルグループ 0x0038 - 0x003a：ユーザ定義のサービス 2（UUID = 0xFFF0）が使用
続けてハンドル 0x003b - 0xffff 範囲のプライマリサービスを照会
「Attribute Not Found (0x0a)」のエラーが返る。これ以上プライマリサービスが存在しないことを意味する。サービスの照会はここまで
Opcode: Error Response (0x01)
Request Opcode in Error: Read By Group Type Request (0x10)
Handle in Error: 0x003b
Error Code: Attribute Not Found (0x0a)
Scene 4: デバイス A 各サービス配下のキャラクタリスティック - デスクリプタの取得
（Scene 3, Scene 4 共通の基礎知識）
BLUETOOTH SPECIFICATION Version 4.2(PDF) [Vol 3, Part G] より
2.6 GATT PROFILE HIERARCHY
2.6.1 Overview, 2.6.2 Service, 2.6.3 Included Services, 2.6.4 Characteristic
3 SERVICE INTEROPERABILITY REQUIREMENTS
3.1 SERVICE DEFINITION, 3.2 INCLUDE DEFINITION, 3.3 CHARACTERISTIC DEFINITION
3.3.1 Characteristic Declaration
3.3.1.1 Characteristic Properties, 3.3.1.2 Characteristic Value Attribute Handle, 3.3.1.3 Characteristic UUID
3.3.2 Characteristic Value Declaration
次に、収集ずみの各プライマリサービスのハンドルグループごとに以下を行う （詳細：1, 2, 3, 4, 5, 6）
- 所定のサービスに含まれる Included Service の照会
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用） - 所定のサービスに含まれるキャラクタリスティックの照会
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用）- 所定のキャラクタリスティックに含まれるデスクリプタの照会
（図は 「BLUETOOTH SPECIFICATION Version 4.2」 より引用）
- 所定のキャラクタリスティックに含まれるデスクリプタの照会
前掲の Frame 231 の示すハンドルグループ 0x0001 - 0x000b の「Generic Access」サービス内の Included Service を照会
Opcode: Read By Type Request (0x08)
Starting Handle: 0x0001
Ending Handle: 0x000b
UUID: GATT Include Declaration (0x2802)
当該サービス内に Included Service は存在しない（注：図のログではスニファがパケットデータを取りこぼしている）
ハンドルグループ 0x0001 - 0x000b の「Generic Access」サービス内のキャラクタリスティックを照会
Opcode: Read By Type Request (0x08)
Starting Handle: 0x0001
Ending Handle: 0x000b
UUID: GATT Characteristic Declaration (0x2803)
以下のみっつのキャラクタリスティックの情報が得られた
（※キャラクタリスティック の Value フィールドの構成は前掲の「BLUETOOTH SPECIFICATION Version 4.2] - [Vol 3, Part G] p.532 「3.3.1 Characteristic Declaration」 に、プロパティ値の意味は同じく p.533 「3.3.1.1 Characteristic Properties」 に説明あり）
- ハンドル：0x0002
「value: 080300002a」より、プロパティ = 0x08 (Write), Characteristic Value Handle = 0x0003
UUID = 0x2A00 = 既定の「Device Name」 - ハンドル：0x0004
「value: 020500012a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0005
UUID = 0x2A01 = 既定の「Appearance」 - ハンドル：0x0006
「value: 020700042a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0007
UUID = 0x2A04 = 既定の「Peripheral Preferred Connection Parameters」
Opcode: Read By Type Response (0x09)
Length: 7
Attribute Data, Handle: 0x0002
Handle: 0x0002
Value: 080300002a
Attribute Data, Handle: 0x0004
Handle: 0x0004
Value: 020500012a
Attribute Data, Handle: 0x0006
Handle: 0x0006
Value: 020700042a
続けてハンドル 0x0007 - 0x000b 範囲のキャラクタリスティックを照会
以下のふたつのキャラクタリスティックの情報が得られた
- ハンドル：0x0008
「value: 020900022a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0009
UUID = 0x2A02 = 既定の「Peripheral Privacy Flag」 - ハンドル：0x000a
「value: 020b00032a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x000b
UUID = 0x2A03 = 既定の「Reconnection Address」
前掲の Frame 231 の示すハンドルグループ 0x000c - 0x000f の「Generic Attribute」サービス内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x000c - 0x000f の「Generic Attribute」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x000d
「value: 200e00052a」より、プロパティ = 0x20 (Indicate), Characteristic Value Handle = 0x000e
UUID = 0x2A52 = 既定の「Service Changed」
続けてハンドル 0x000e - 0x000f 範囲のキャラクタリスティックを照会
当該サービス内にはこれ以上キャラクタリスティックは存在しない
Frame 289 の示す通り 0x0000e は Service Changed キャラクタリスティックの Value Handle であり、残る0x000f に関する情報を GATT に問い合わせてみる （詳細：1, 2）
Opcode: Find Information Request (0x04)
Starting Handle: 0x000f
Ending Handle: 0x000f
0x000f は Service Changed キャラクタリスティックの Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
Opcode: Find Information Response (0x05)
UUID Format: 16-bit UUIDs (0x01)
Handle: 0x000f
UUID: Client Characteristic Configuration (0x2902)
前掲の Frame 231 の示すハンドルグループ 0x0010 - 0x0022 の「Device Information」サービス内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x0010 - 0x0022 の「Device Information」サービス内のキャラクタリスティックを照会
以下のみっつのキャラクタリスティックの情報が得られた
- ハンドル：0x00011
「value: 021200292a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0012
UUID = 0x2A29 = 既定の「Manufacturer Name String」 - ハンドル：0x00013
「value: 021400242a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0014
UUID = 0x2A24 = 既定の「Model Number String」 - ハンドル：0x00015
「value: 021600252a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0014
UUID = 0x2A25 = 既定の「Serial Number String」
続けてハンドル 0x0016 - 0x0022 範囲のキャラクタリスティックを照会
以下のみっつのキャラクタリスティックの情報が得られた
- ハンドル：0x00017
「value: 021800262a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0018
UUID = 0x2A26 = 既定の「Firmware Revision String」 - ハンドル：0x00019
「value: 021a00272a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x001a
UUID = 0x2A27 = 既定の「Hardware Revision String」 - ハンドル：0x0001b
「value: 021c00282a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x001c
UUID = 0x2A28 = 既定の「Software Revision String」
続けてハンドル 0x001c - 0x0022 範囲のキャラクタリスティックを照会
以下のみっつのキャラクタリスティックの情報が得られた
- ハンドル：0x0001d
「value: 021e00232a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x001e
UUID = 0x2A23 = 既定の「System ID」 - ハンドル：0x0001f
「value: 0220002a2a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0020
UUID = 0x2A2A = 既定の「IEEE 11073-20601 Regulatory Certification Data List」 - ハンドル：0x00021
「value: 022200502a」より、プロパティ = 0x02 (Read), Characteristic Value Handle = 0x0022
UUID = 0x2A50 = 既定の「PnP ID」
前掲の Frame 238 の示すハンドルグループ 0x0023 - 0x0025 の「Immediate Alert」サービス内の Included Service を照会
（注：このリクエストに対する正しいレスポンスは「Attribute Not Found (0x0a)」だが、スニファ取りこぼしのためログが欠落している）
ハンドルグループ 0x0023 - 0x0025 の「Immediate Alert」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0024
「value: 042500062a」より、
プロパティ = 0x04 (Write without Response),
Characteristic Value Handle = 0x0025
UUID = 0x2A06 = 既定の「Alert Level」
前掲の Frame 238 の示すハンドルグループ 0x0026 - 0x002a の「Tx Power」サービス内の Included Service を照会
（注：このリクエストに対する正しいレスポンスは「Attribute Not Found (0x0a)」だが、スニファ取りこぼしのためログが欠落している）
ハンドルグループ 0x0026 - 0x002a の「Tx Power」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0027
「value: 122800072a」より、プロパティ = 0x12 (Read | Notify), Characteristic Value Handle = 0x0028
UUID = 0x2A07 = 既定の「Tx Power Level」
続けてハンドル 0x0028 - 0x002a 範囲のキャラクタリスティックを照会
当該サービス内にはこれ以上キャラクタリスティックは存在しない
Frame 359 の示す通り 0x00028 は Tx Power Level キャラクタリスティックの Value Handle であり後続の 0x0029 - 0x002a に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0029 は Tx Power Level キャラクタリスティックの Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
残る0x002a に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x002a は Tx Power Level キャラクタリスティックの Characteristic Presentation Format Descriptor (UUID = 0x2904） （詳細：1, 2, 3, 4） である旨の情報が得られた
Opcode: Find Information Response (0x05)
UUID Format: 16-bit UUIDs (0x01)
Handle: 0x002a
UUID: Characteristic Presentation Format (0x2904)
前掲の Frame 238 の示すハンドルグループ 0x002b - 0x002d の「Link Loss」サービス内の Included Service を照会
（注：このリクエストに対する正しいレスポンスは「Attribute Not Found (0x0a)」だが、スニファ取りこぼしのためログが欠落している）
ハンドルグループ 0x002b - 0x002d の「Link Loss」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x002c
「value: 0a2d00062a」より、プロパティ = 0x0a (Read | Write), Characteristic Value Handle = 0x002d
UUID = 0x2A06 = 既定の「Alert Level」
前掲の Frame 247 の示すハンドルグループ 0x002e - 0x0032 の「Battery Service」サービス内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x002e - 0x0032 の「Battery Service」サービス内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x002f
「value: 123000192a」より、プロパティ = 0x12 (Read | Notify), Characteristic Value Handle = 0x0030
UUID = 0x2A19 = 既定の「Battery Level」
続けてハンドル 0x0030 - 0x0032 範囲のキャラクタリスティックを照会
当該サービス内にこれ以上キャラクタリスティックは存在しない
Frame 404 の示す通り 0x00030 は Battery Level キャラクタリスティックの Value Handle であり後続の 0x0031 - 0x0032 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0031 は Battery Level キャラクタリスティックの Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
残る0x0032 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0032 は Battery Level キャラクタリスティックの Characteristic Presentation Format Descriptor (UUID = 0x2904） （詳細：1, 2, 3, 4） である旨の情報が得られた
前掲の Frame 247 の示すハンドルグループ 0x0033 - 0x0037 のユーザ定義サービス 1（UUID = 0xFFE0）内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x0033 - 0x0037 のユーザ定義サービス 1 内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0034
「value: 103500e1ff」より、
プロパティ = 0x10 (Notify),
Characteristic Value Handle = 0x0035
UUID = 0xFFE1 : ユーザ定義のキャラクタリスティック
続けてハンドル 0x0035 - 0x0037 範囲のキャラクタリスティックを照会
当該サービス内にこれ以上キャラクタリスティックは存在しない
Frame 439 の示す通り 0x00035 はユーザ定義キャラクタリスティック（UUID = 0xFFE1）の Value Handle であり後続の 0x0036 - 0x0037 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0036 はユーザ定義キャラクタリスティック（UUID = 0xFFE1）の Client Characteristic Configuration Descriptor (UUID = 0x2902） （詳細：1, 2） である旨の情報が得られた
残る0x0037 に関する情報を GATT に問い合わせてみる （詳細：1, 2）
0x0037 はユーザ定義キャラクタリスティック（UUID = 0xFFE1）の Characteristic User Description Descriptor (UUID = 0x2901）である旨の情報が得られた
前掲の Frame 247 の示すハンドルグループ 0x0038- 0x003a のユーザ定義サービス 2（UUID = 0xFFF0）内の Included Service を照会
当該サービス内に Included Service は存在しない
ハンドルグループ 0x0038 - 0x003a のユーザ定義サービス 2 内のキャラクタリスティックを照会
以下のキャラクタリスティックの情報が得られた
- ハンドル：0x0039
「value: 043a00f1ff」より、プロパティ = 0x04 (Write without Response), Characteristic Value Handle = 0x003a
UUID = 0xFFF1 : ユーザ定義のキャラクタリスティック
Scene 5: デバイス A ボタン押下時のアプリへの通知を設定
Frame 453、Frame 439、Frame 453 の示す通り、ハンドル 0x0036 は、 "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）配下の Client Characteristic Configuration Descriptor (CCCD)" である
当該ユーザ定義キャラクタリスティック（UUID = 0xFFE1）のプロパティには Notify が設定されており、クライアントである対向アプリから CCCD 0x0036 に Notification bit (0x0001) を書き込んでおくことで、このキャラクタリスティックの値が更新された時に Value Handle である 0x0035 経由でアプリ側へ通知（Notification）が行われるようになる
（詳細：
1a,
2a,
1b,
2b）
Opcode: Write Request (0x12)
Handle: 0x0026
Value: 0100
Opcode: Write Response (0x13)
Scene 6: アプリからデバイス A の LED・ブザーを操作
対向アプリ上の所定のボタンを押下すると、Frame 345, Frame 238 の示す、 "「Immediate Alert」サービス配下の「Alert Level」キャラクタリスティック" の Value Handle 0x0025 に値「2（High Alert）」が書き込まれる
デバイス A の LED・ブザーはファームウェアレベルでこの Alert Level キャラクタリスティックに紐づけられている模様。High Alert 値が書き込まれるとそれに反応して短時間 LED とブザーが ON になる
なお、Frame 345 の示すように Alert Level キャラクタリスティックのプロパティには「Write without Response」(0x04) が設定されているため、アプリから値を書き込んでもデバイス A からのレスポンスは発生しない
Opcode: Write Command (0x52)
Handle: 0x0025
Value: 02
Scene 7: デバイス A のボタンを押すとアプリへ通知
デバイス A の物理ボタンはファームウェアレベルで Frame 439 の示す "ユーザ定義サービス 1（UUID = 0xFFE0）配下のユーザ定義キャラクタリスティック（UUID = 0xFFE1）" に紐づけられている模様。このボタンを押すと当該キャラクタリスティックの値がデバイス内部で更新され Frame 491 での仕込みに基づきアプリ側へ通知が行われる
Opcode: Handle Value Notification (0x1b)
Handle: 0x0035
Value: 01
Scene 8: アプリ側からデバイス A との接続を切断
対向アプリ上の所定のボタンを押下するとリンク層制御 PDU の LL_TERMINATE_IND (0x02) がデバイス A 側に送出され両者間の接続が終了する（詳細：1, 2）
(tanabe)
技適マークつき BLE パケットスニファを入手する
国内では次のような BLE プロトコルアナライザが販売されています。もっともこういった数百万円オーダーの専用機にはなかなか手を出せません。
もっと手軽な方法として、BLE チップ・モジュールベンダの提供するパケットスニファを利用する選択があります。代表的な製品をピックアップしてみます。
- nRF Sniffer - Nordic Semiconductor 社
- nRF51 Dongle （参考価格：$49.00）
-
nRF51 DK （参考価格：$39.00）
- nRF51 Dongle （参考価格：$49.00）
- CC2540 USB Evaluation Module Kit - Texas Instruments 社 （参考価格：$49.00）
パケットスニファと技適
たとえば、前掲の Nordic Semiconductor 社製「nRF51 Dongle」は技適証明を受けていないためディストリビュータが次のように注意を促しています。
- nRF51 USB dongle for emulator,firmware - jp.rs-online.com
警告 本開発キットは技術基準適合証明を受けておりません。本製品のご使用に際しては、 電波法遵守のため、以下のいずれかの措置を取っていただく必要がありますので ご注意ください。 - 電波法施行規則第 6 条第 1 項第 1 号に基づく平成 18 年 3 月 28 日総務省告示 第 173 号で定められた電波暗室等の試験設備内で使用する。 - 実験局の免許を取得したのち使用する。 - 技術基準適合証明を取得したのち使用する。
- 電波法 （最終改正：平成二七年五月二二日法律第二六号） - law.e-gov.go.jp
第一章 総則 : 第二条 この法律及びこの法律に基づく命令の規定の解釈に関しては、次の定義に 従うものとする。 : 五 「無線局」とは、無線設備及び無線設備の操作を行う者の総体をいう。 但し、受信のみを目的とするものを含まない。 :
- Nordic nRF51-Dongle | mbed - developer.mbed.org
以下の例のように、技適マークつきの製品においてさえ「ファームウェアの書き換え」との整合性を一意に判断できない事情を考え合わせると、技適マークなしのこれらのスニファ製品の日本国内での使用の是非はやはり微妙かもしれません。
- ESP-WROOM-02のファームウェアを書き換えた場合、技適はどうなるのか - スイッチサイエンス
ユーザーによるファームウェアの書き換えが、ESP-WROOM-02の工事設計認証を 無効にする可能性について、メーカーのEspressif Systemsに確認をしました。 同社は登録認証機関に確認した上で、Arduino core for ESP8266 WiFi chip または同社製SDKを使っている限りにおいては、認証には影響を与えないという 回答を下さいました。他の開発環境など、ファームウェアを書き換える部分に よっては、認証に影響を及ぼし得るとのことですので、ご注意ください。
- モノワイヤレス製品情報 - MONO-WIRELESS.COM - mono-wireless.com
電波法規（技適）について : 更にファームウエアを書き換えると認証の範囲を外れてしまう無線モジュール も存在しています。弊社製品は全て技適認証に適合した無線モジュールですので コンプライアンスに背くことなく安心してご使用していただけます。併せて 「電波法についての考慮事項」を参照ください。
- DD-WRT - wikipedia
電波法による規制 日本においては無線機器に対してメーカー側が想定していない非公式ファーム ウェアへの書き換えを行った時点で技適マークが無効となり、無線LANを利用する 場合は電波法に違反する[要出典]。 :
Adafruit 社製「Bluefruit LE Sniffer」
そんなわけで前掲のスニファの導入は一旦保留していましたが、情報を探しているうちにふとある製品のスペックに目がとまりました。
-
Bluefruit LE Sniffer - Bluetooth Low Energy (BLE 4.0) - nRF51822 - yeint.ee
Tehnilised andmed : - MDBT Datasheet - 18mm x 61mm x 7mm - Weight: 6.5g
- 技術基準適合証明等を受けた機器の検索 - 204-420020 - www.tele.soumu.go.jp
- Adafruit Feather 32u4 Bluefruit LE - スイッチサイエンス
BLE(Bluetooth Low Energy)機能付きの小型Arduino互換ボードです。 Adafruit Bluefruit LE Microの後継品です。 : Arduino Leonardoなどに搭載されているATmega 32u4を搭載。 BLEモジュールであるMDBT40は、総務省の工事設計認証（いわゆる技適）を 取得済みなので、日本国内で使用することができます。 :
このスニファであれば技適関連のジレンマなしに利用できそうです。本体価格は直販で $29.95。以下、Adafruit 社公式サイトより。
- Bluefruit LE Sniffer - Bluetooth Low Energy (BLE 4.0) - nRF51822 - v1.0 - www.adafruit.com
- Introducing the Adafruit Bluefruit LE Sniffer - learn.adafruit.com
- ホスト PC との接続が身近な FTDI ドライバで完結する
- Nordic Semiconductor が自社製品用に公開している「nRF Sniffer」プログラム（Windows 専用）＋ Wireshark のコンビネーションに対応しており扱いやすい
- Nordic nRF Sniffer - learn.adafruit.com
- nRF Sniffer - www.nordicsemi.com
- nRF Sniffer User Guide - www.nordicsemi.com
- nRF-Sniffer Download - www.nordicsemi.com
- nRF Sniffer は暗号化された BLE 通信の復号に対応
- Is nRF Sniffer doing decryption? - devzone.nordicsemi.com
- nRF Sniffer User Guide v1.1 (PDF) - www.nordicsemi.com p.10 - 11
- Mac OS X 10.9 (Mavericks) 以降では Roland King 氏による非公式の代替ソフトウェアを利用可能（手元では未検証）
- nrf-ble-sniffer-osx - sourceforge.net
- マルチプラットフォームで利用可能な独自の Python API セットが Adafruit より提供されている
- Python API - learn.adafruit.com
- GitHub: adafruit/Adafruit_BLESniffer_Python - github.com/adafruit
発送連絡後に USPS サイトで配送状況を確認すると経由地に「JAMAICA」の表記あり。さては Japan -> Jamaica のミスか？ と疑いましたがこれはカリブ海域にある国の名前ではなく JFK 空港そばの「JAMAICA, NY 11430」でした。物流の要衝のようですが恥ずかしながらニューヨークにジャマイカという地名があることを初めて知りました。Adafruit さん疑ってごめんなさい（^^；
使ってみる
Windows PC で Bluefruit LE Sniffer を使用する最短の手順を示します。詳細は nRF Sniffer アーカイブ内の「nRF Sniffer User Guide」に記載されています。
- FTDI 社の仮想 COM ポートドライバを未導入ならインストール
- Virtual COM Port Drivers - www.ftdichip.com
- 最新の nRF Sniffer の zip アーカイブをダウンロードし適当なフォルダ A へ展開
- nRF-Sniffer Download - www.nordicsemi.com
- Wireshark（v1.10.1 以降）を未導入ならインストール
- Download Wireshark - www.wireshark.org
- Bluefruit LE Sniffer を USB ポートへ接続し Sniffing の対象とするデバイスを近接させておく
図は「nRF Sniffer User Guide v1.2」より
- フォルダ A 直下の「ble-sniffer_win_<version>_Sniffer.exe」を実行
- コンソールが開きアドバタイジング中の BLE デバイスが一覧表示される
- カーソルキー＋ENTER または「＃」番号で対象とするデバイスを選択
- デバイスを選択した状態で「w」キーを押下すると Wireshark が起動。あとはデバイス側で必要な操作を行えばよい
付記：デュアルユース品と輸出規制
ご存知の方も多いと思いますが、Mouser や RS，Digi-key といった一般のディストリビュータから所定の電子部品を購入しようとすると、その製品の内容と在庫元・出荷元の国や地域によっては軍事転用の可能な「デュアルユース品目」として輸出規制に引っかかり、所定の書類一式の提出を求められ審査のために数週間程度待たされる場合があります。
今回、某ディストリビュータへ所定の商品が輸出規制の対象が否かを事前に判別する方法の有無を尋ねたところ「注文を受け実際に輸出手続きを開始しなければわからない」との回答でした。 輸出規制に関する注意書きの有無はまちまちですが、以下に一例を引用します。
-
nRF51-Dongle Nordic Semiconductor | Mouser - www.mouser.jp
This product may require additional documentation to export from the United States. この製品をアメリカから配送するには、追加の書類が必要になる ことがあります。
-
Adafruit's export process - overview - www.adafruit.com
Export Controls - Adafruit makes efforts to follow the Export Administration Regulations (EAR) and Bureau of Industry and Security (BIS) guidelines. - What is the jurisdiction of item (BIS, DDTC, ITAR) Is it subject to EAR? Does it require a license? - Adafruit makes best efforts to Export using appropriate ECCN and authorization. - Adafruit has a process for self-assigning ECCNs for its products. - Adafruit has a process for requesting ECCNs for third party products. - Most Adafruit products are subject only to AT controls or are EAR99.- 「AT」= Anti-Terrorism
- 「EAR99」= CCL（規制品目リスト）に記載のない規制対象品のカテゴリ。商務省のライセンスなしで輸出可能な場合がある
- 米国輸出規則 - Export Administration Regulations (EAR) - 在日米国大使館商務部
- スマホアプリと米国輸出規制に関するメモ - 当ブログ
- スマホアプリと米国輸出規制に関するメモの続き - 当ブログ
(tanabe)
Tomoru と Pochiru と Linking
Tomoru
Tomoru は、昨年（2015年）11月より国内のクラウドファンディングサービス Makuake で支援募集の行われた Bluetooth Low Energy（BLE）デバイスです。「Project Linking」の立ち上げとともに当時話題になったためご存知の方も多いことでしょう。2016年8月現在は製造元である株式会社 Braveridge の公式ストアや Amazon から入手することができます。以前このブログで「blink(1)」という製品をピックアップしたことがありますが、個人的に「光りもの」は好物で、この Tomoru も支援募集への応募によって届いた個体を持っています。
www.products.braveridge.com
現時点では対応アプリが全体的にやや大人しめで Linking 自体も本格的な普及はこれからのようですが、手元では BLE の勉強がてらにこの可愛いデバイスを楽しんでいます。
Pochiru
Braveridge 社はその後も活発に Linking 対応製品をリリースしています。最近目にとまった「Pochiru」というデバイスを買ってみました。Pochiru には LED に加えネーミングどおり押しボタンが実装されています。そのため通信先の機器との双方向のやりとりが可能です。
www.products.braveridge.com
プログラムを書く
Tomoru や Pochiru のような Linking 対応デバイス用のアプリは Project Linking が無償で公開している SDK を利用して作成します。BLE まわりのハンドリングはすべて Linking 本体が仲介するため、抽象化された Linking API を呼び出すだけでデバイスとの連携が可能です。
Project Linking の開発者向けページの中ほどの「API guide」項の利用規約を確認の上 SDK をダウンロードし、「API 仕様書」の「ポーティング」ページの説明に添って開発環境をセットアップします。後は「API 仕様書」と SDK アーカイブに含まれる「LinkingIFDemo」のコードを読み合わせれば要領を理解しやすいでしょう。
手元では Android 版 SDK を利用しています。上記のサンプルを元に作成した簡単なアプリのコードを以下に示します。アプリの「LED」ボタンを押すと連携ずみデバイスの LED が点灯し、連携ずみデバイス側のボタン押下等のイベントによってアプリが通知を受けるとその旨を画面に表示する内容です。
試作：Linking01
MainActivity.java
/**
*
* Linking01
*
* - 連携ずみ Linking デバイスの LED を点灯させる
* - Linking デバイスからの通知を受け取る
*
*/
package jp.klab.Linking01;
import android.content.Context;
import android.content.SharedPreferences;
import android.media.AudioManager;
import android.media.ToneGenerator;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.Toolbar;
import android.view.View;
import android.widget.Button;
import android.widget.Toast;
import com.nttdocomo.android.sdaiflib.Define;
import com.nttdocomo.android.sdaiflib.NotifyNotification;
import com.nttdocomo.android.sdaiflib.SendOther;
public class MainActivity extends AppCompatActivity
implements View.OnClickListener {
private Context mCtx;
private Button mButtonLED;
private static final byte LINKING_IF_PATTERN_ID = 0x20; //LEDパターンの設定項目ID（固定値）
private static final byte LINKING_IF_COLOR_ID = 0x30; //LED色の設定項目ID（固定値）
private static final byte COLOR_ID_RED = 0x01; // 点灯色
private static final byte BLINK_PATTERN = 0x22; // 点灯パターン
private NotifyNotification mNotifyNotification;
private MyNotificationInterface mMyNotificationInterface;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mCtx = this;
setContentView(R.layout.activity_main);
Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);
mButtonLED = (Button)findViewById(R.id.buttonLED);
mButtonLED.setOnClickListener(this);
// Linking デバイスからの通知受信用
mMyNotificationInterface = new MyNotificationInterface();
mNotifyNotification = new NotifyNotification(this, mMyNotificationInterface);
}
@Override
public void onClick(View v) {
// LED ボタン押下で連携ずみデバイスあてに LED 点灯指示を送る
if (v == (View)mButtonLED) {
SendOther sendOther = new SendOther(this);
sendOther.setIllumination(
new byte[] {
LINKING_IF_PATTERN_ID,
BLINK_PATTERN,
LINKING_IF_COLOR_ID,
COLOR_ID_RED
});
sendOther.send();
}
}
@Override
protected void onDestroy() {
super.onDestroy();
mNotifyNotification.release();
}
private class MyNotificationInterface implements NotifyNotification.NotificationInterface {
@Override
public void onNotify() { // 通知を受信した
// Linking デバイスからの通知内容は SharedPreferences に記録される
SharedPreferences preference =
getSharedPreferences(Define.NotificationInfo, Context.MODE_PRIVATE);
int DEVICE_ID = preference.getInt("DEVICE_ID", -1);
int DEVICE_BUTTON_ID = preference.getInt("DEVICE_BUTTON_ID", -1);
// Toast 表示
Toast.makeText(mCtx, "onNotify: DEVICE_ID=" + DEVICE_ID +
" DEVICE_BUTTON_ID=" + DEVICE_BUTTON_ID, Toast.LENGTH_SHORT).show();
// 音も鳴らす
ToneGenerator toneGenerator
= new ToneGenerator(AudioManager.STREAM_SYSTEM, ToneGenerator.MAX_VOLUME);
toneGenerator.startTone(ToneGenerator.TONE_CDMA_CALL_SIGNAL_ISDN_PING_RING);
}
}
}
試作の動作の様子
Linking でのデバイス・アプリの設定手順
Linking 対応デバイスと Linking アプリを連携させるためには事前に設定が必要です。手順は以下の要領です。
- 端末に「Linking」をインストールする（未インストールの場合のみ）
Linking（Android 版）- play.google.com
- 連携させるアプリ（ここでは自作の「Linking01」）のインストールを行い Linking を実行する
- 「デバイスの検索」を行い連携対象のデバイスを Linking に接続する（当該デバイスを未登録の場合のみ）
- デバイスの登録・接続が完了したら「デバイス詳細画面」へ移動し当該デバイスと連携させるアプリケーション（複数可。ここでは「Linking01」）を設定する
-
Linking を抜け上の手順で設定したアプリを起動してデバイスとの連携を確認する
備考： デバイスの Linking への再接続について
手元の Android 5.1 端末の環境では以下の現象が見られます。Linking のバージョンは 2016年8月現在最新の「03.10.00000」です。
- Linking に接続ずみのデバイスを Linking 上で「切断」すると再接続できなくなる
- Android の Bluetooth 設定において当該デバイスとのペアを解除してから Linking 上で再接続を行う
- Tomoruの接続トラブルシューティング (PDF) - www.products.braveridge.com
(tanabe)
「入院者と外部とのコミュニケーション」への IoT の応用
フェイススケールのこと
先日身内が入院した折にこういう顔の絵の入ったクリアファイルを病棟で見かけました。
- フェイススケール - ja.wikipedia.org
フェイススケール（英: Face scale）とは、現在」の痛みを「にっこり笑った顔」から普通の顔、 そして「しかめっ面」そして「泣き顔」までの様々な段階の顔を用意して、神経痛などの痛みを 訴えている患者にどのぐらい痛むのかを示してもらうことで、その痛み度を客観的に知るために、 ペインクリニック・麻酔科などで用いられる用具・用紙のことである。看護師さんがベッドに横になったままのご高齢者にこれを見せながら大きな明るい声で尋ねている様子が印象に残りました。たった一枚の印刷物ですが、自由に話したり体を動かしたりすることのむずかしい状態の入院者とのやりとりには特に有用なツールであることが想像されます。
入院者と外部とのコミュニケーションへの IoT の応用
携帯端末での電子メール利用の普及により入院者と外部との連絡はメール以前の時代に比べ格段に便利になりました。病室内での通話は無理でもメールの送受信は多くの場合認められており、おそらくは施設側が伝言を取り次ぐ頻度も昔よりもずっと少なくなったことでしょう。
その一方で、症状や状況によっては小さなキーを操作することが困難であったり、あるいは携帯端末やメールとの接点を想像しにくい雰囲気の入院者も少なくないことを連日の病棟内の光景であらためて実感しました。残念なことに、現実にはそういう人たちにこそ関係者との日常的なつながりがより必要なケースが多いようにも感じられます。たとえ最小限の内容であっても当事者間で手軽にコミュニケーションをとることができれば双方の不安が確実に軽くなることを考えあわせると、社会の高齢化が進行する状況にあってこの話題は潜在的な必要性の高いテーマのひとつと言えるのではないでしょうか。
試みに、フェイススケールをヒントに病室内での使用を想定してごく簡単な操作で離れた相手とメッセージを交わすしくみを形にしてみました。身近な場面での実用性のある IoT のアイディアとして紹介します。
試作装置の外観と概要
下の写真の装置のいずれかのボタンを押すと相手側の装置の同じ絵の下の緑の LED が点滅し、併せてその絵柄を添えたメールが所定のアドレスへ届きます。
親しい間柄の人や自分自身が病室のベッドで苦しんだ経験のある方にはわかるのではないかと思いますが、いま入院者に「ボタンを押すだけの余力」と「絵柄を選択する意識」があるということを情報として伝えられることには、離れて案ずる側にとっても入院者自身にとってもそれ自体に大きな意味があります。また、一方通行ではなく相手からの反応が手元に届くことは双方の精神的な支えとなるでしょう。写真のとおり、互いに言葉や意味ではなく気持ちや意識を伝えることに主眼を置いてそれぞれのボタンの絵柄はあえて解釈の余地の広いものを選んでいます。
※クリックで大きく表示
装置を病室に設置したイメージ |
メールには押したボタンの画像がインラインで表示されリンクのクリックで返信用のページが開く |
- インターネット接続環境を備えた入院施設が少ないことを考慮し装置は現在もっとも低コストでモバイル通信のハンドリングが可能な Raspberry Pi ＋ 3G モデムの構成で MVNO SIM を使用しておりコンセントひとつで稼働可能
- 自分が押したボタンは赤 LED の点灯、相手の押したボタンは緑の LED の緩やかな点滅で示される
- 装置間のメッセージングには Milkcocoa 、メール送信には SendGrid を利用
- 赤ボタンの押下で各 LED を消灯、5秒以上の長押しで装置をシャットダウン
- 右端の LED は装置の稼働を示すパイロットランプ
動作の様子（動画：2分20秒 音声なし）
このデモ動画は入院者側が実装置を使用し相手側がインターネット接続環境のもとで Web 版の仮想装置を使用することを想定した内容です。もちろん二台の実装置間での応酬も可能です。
画像について
今回の試作では画像がコミュニケーションの仲介者として大きな役割を担っており、これらは病室という気持ちの沈みがちな空間に小さな癒しを灯すシンボルでもあります。一連の画像は Beeboo.SLI（ビブースライ）様が運用される画像素材サイト 「イラスト無料素材 イラストボックス」へ I＜アイ＞さん が掲載された作品を加工して使用させて頂いています。I＜アイ＞さんの素敵なイラストと素晴らしいサイトに謹んで御礼申し上げます。
装置づくり
メインの要素
これらに説明は要らないでしょう。いずれも「持っていると便利」な道具です。
Raspberry Pi 2 Model B
アマゾンで 5,000円前後 |
3G USB モデム：
L-05A
2015年10月に「イオシス」で 1,180円で購入（中古） |
MVNO SIM：0 SIM
（デジモノステーション 2016年02月号付属版） 
手元の SORACOM Air とどちらを使うか迷ったが今回は 0 SIM を使用 |
筐体の材料と加工
今回の装置では操作用のボタンの選定が大きなポイントでした。小さすぎず大きすぎないものを探し以下の製品を選びました。
- ゲームスイッチ - 秋月電子通商 ￥150（税込）
パネル取付用押しボタンスイッチ（緑色）です。過酷な使用に耐えられるヘビーデューティー 仕様です。プッシュ機構部（樹脂製）とマイクロスイッチで構成されています。
このボタンは取りつけ時の占有直径がおよそ 34mm で、これを 5mm 程度の間隔で 7つ設置するには最低 28cm ほどの長さが必要です。100円ショップをいくつか見てまわり筐体として写真のパスタケースを選びました（長さ：30.6cm 幅：8.5cm 高さ：7.6cm）。
蓋の方が少し広めの台形で、固い底のほうを上にすれば安定感があります。
このケースの底にボタンを取りつけるには厚さ 3mm のポリプロピレン板に 30mm 程度のまるい穴が 7つ必要です。今の自分の工作力ではこのように硬く厚みのある素材に綺麗なまるい穴をあけることが難しく、練習用の予備であれこれやってみましたがなかなかうまくいきません。店先でたまたま野菜調理用の金属製の抜き型が目にとまりました。下の写真の大2 + 小2 セットの「小」の持ち手側の外径が 3cm に近く、試しにこれを熱してケースに押し当てるとちょうどよいサイズの綺麗な穴が得られました。ケースの両端には 1cm のマージンを設け、シャットダウンボタン用の一番右の穴は隣りと 1cm 離してあとは 5mm 間隔で穴をあけました。
野菜の抜き型 （金属製） |
穴をあけ終えたケース |
パーツの取りつけ
実際にボタンを取りつけてみると全体の印象は当初のイメージどおりでした。ただ、ボタン 7個、LED 13個分の計 40本の配線を内部の残りのスペースの四方へめぐらせるには電子工作用の一般的なワイヤでは固すぎて取り回しに融通が利かず、柔らかい導線を加工して筐体内の隙間へ這わせることにしました。スペース節約のため GND への繋ぎ込みにはメスのピンソケットのオス側をスズメッキ線で連結したものを使いました。
ざっくり結線。ワイヤが固い |
導線にLEDと抵抗とハンダづけして末端をオス・メス化 |
裁断した色画用紙を加工 |
ケースへ一式を収納して動作確認 |
ソフトウェア要素
作成したプログラム類一式を以下の場所で公開しています。
https://github.com/mkttanabe/iot_hospital
使用しているソフトウェア資産とサービス
土台の Raspberry Pi 2 Model B には標準ディストリビューションの Raspbian をインストールずみで今回は以下のソフトウェア資産を使用しています。
また、ふたつの優れたサービスを利用しています。メインプログラム
実装置用のプログラム本体は Node.js スクリプトとして記述しています。
Web 版仮想装置のページは以下の URL から参照できます。
http://dsas.blog.klab.org/data/iot_hospital/index.html?ID02&ID01
注：Web 版の動作には Milkcocoa アカウントを取得し 22行めに正しい APP ID を指定する必要があります
モデムまわり
L-05A ＋ 0 SIM の組み合わせでのインターネットへの接続には wvdial ユーティリティを使用しています。/etc/wvdial.conf は以下の内容。"sudo wvdial" の実行で接続を開始します。
[Dialer Defaults] init1 = ATZ init2 = AT+CGDCONT=1,"IP","so-net.jp" Password = nuro Username = nuro Dial Attempts = 3 Stupid Mode = 1 Modem Type = Analog Modem Dial Command = ATD Stupid Mode = yes Baud = 115200 New PPPD = yes Modem = /dev/ttyACM0 ISDN = 0 Phone = *99***1# Carrier Check = no
※L-05A はゼロインストール機能を内蔵しており出荷時の設定により USB 接続時にはデフォルトで CD-ROM デバイスとして認識されます。eject コマンドで毎回これを解除するのが煩わしいため手元ではデフォルトで USB モデムとして認識されるように設定を変更しています。
- L-02Cを最初からUSBモデムで認識させる／手動でAPN登録する
- stkinosh (id:trtr) 様のブログ「/dev/stkinosh」より
モデムモードに設定した L-05A は lsusb コマンドで以下の要領で表示されます。
Bus 001 Device 004: ID 1004:6124 LG Electronics, Inc.
スタートアップまわり
システム起動時に今回の一式を自動実行するために /etc/rc.local に iot_hospital.sh の呼び出しを記述しています。 iot_hospital.sh は L-05A が装着されていれば wvdial でインターネット接続を試行し、接続に成功すれば前掲の iot_hospital.js を実行します。
#!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. # Print the IP address _IP=$(hostname -I) || true if [ "$_IP" ]; then printf "My IP address is %s\n" "$_IP" fi # run app sudo /bin/bash /home/pi/node/iot_hospital.sh & exit 0
(tanabe)
ネットワーク対応の光通知デバイスを自作してみる
「blink(1)」のこと
コードネームのような製品名ですが、「blink(1)」は KickStarter 発のカスタマイズ可能な USB デバイスです。接続先の機器やネットワークから所定の情報を受けとると LED 光の色や明滅により人間への通知を行うもので、2012年に製品化され 2013年には IFTTT との連携機能を強化した blink(1) mk2 がリリースされています。
文字の情報は人間が意識的にそこに向き合わなければ伝わらず、音の情報は状況により場の環境を乱す可能性があります。一方、「光」による情報はそれが適度な明るさであれば他の何かを妨げることなく人間の視界へ届き自然に認識され得ます。そのことを応用した例は他にも見られますが、blink(1) もまた光の特性を活かした機器のひとつです。
|
|
|
| www.kickstarter.com | gigazine.net | gigazine.net |
- 新着ツイートやネットワーク速度などをUSB接続のLEDライトが光って教えてくれる「blink(1)」 (2012-07-23)
- PCでのイベントを光で通知するUSBライト「blink(1)」が届いたので使ってみた (2012-12-24)
- メールやSNSから近所の天気まで、ウェブサービスと連携して光で通知するUSBライト「blink(1)」を「IFTTT」と一緒に使ってみた (2013-02-05)
- 各種サービスやアプリと連動した通知やアクションをカラフルなUSB接続のLEDで光って伝えてくれる「blink(1) mk2」 (2013-07-22)
- アプリ・各種サービスの通知やPCの状況をカラフルにお知らせするUSBライト「blink(1) mk2」を使ってみた (2014-08-04)
- Buy blink(1) - blink1.thingm.com
- Blink(1) mk2 USD $30.00 - www.seeedstudio.com
- Blink (1) mk2 - www.ebay.com
- blink(1) mk2 紹介とunboxing - 「 いずみはら あつし (id:AMANE)」様のブログ「自習室」より
PubNub のこと / ESP8266 との関係
PubNub は Pub/Sub モデルのリアルタイムメッセージング機能を主軸とする BaaS です。
2010年のローンチ以来スマホや Web アプリ向けのプッシュ通知サービス等を展開、近年は IoT 方面にも注力しており対応言語・環境の広い有用なプラットフォームのひとつです。サポート対象は現在も拡大中、ちなみに無料枠もなかなかの太っ腹です。
また、GET リクエストベースの REST API セットが用意されており（HTTPS, HTTP）、これを利用すれば他のシステムやデバイスからも PubNub の所定の Channel へ柔軟にメッセージを送ることが可能です。
（2015年12月現在 80超の言語・環境に対応 ｰｰ クリックで可読大表示）
このように便宜の大きい PubNub ですが、この記事を書いている 2015年12月時点では実は肝心の ESP8266 がまだサポートされていません。でも幸い非公式のクライアントライブラリが公開されていることを知りました。本家の GitHub リポジトリにも fork されていることから非公式ながらも公認の位置づけのようです。
上の記事のとおりこの非公式ライブラリは任意のタイミングでの双方向通信には対応していない（subscribe() 呼び出し後の受信完了前には publish() 不可）ものの、今回想定している装置はもっぱら受信側であるため特に支障はなさそうです。作者の Kurt Clothier さん自身が「can be adjusted for a particular need」と書いているようにライブラリコードは用途に応じ適宜手を加えて利用すれば良いでしょう。
なお、このライブラリは Espressif 社による純正の ESP8266 SDK 向けに記述されています。より扱いやすい Arduino IDE for ESP8266 環境でも利用できるように併せて手を加えることにしました。
試作の動作の様子 （動画：1分11秒 環境音・操作音あり）
下の動画は、作成した装置へ PubNub の Web コンソールからメッセージを送り動作を確認している様子です。各メッセージはそれぞれ一行の REST API 記述に置き換えることができます。
手元での現在の使途
手元ではこの試作を下記の要領で使用中。「光による通知」が想像以上に便利で実用的であることを実感しています。スマートさや表現性は blink(1) に及ばないものの必要になれば好きなようにいじれることが手作りの利点ですね。
- 黄点灯：明日の予報が雨の場合
（IFTTT レシピを利用）
クリックで可読大表示
ありがちなテーマだが実際に使ってみると手放せなくなる。好天続きで何となく油断している折に不意に点灯を目にしたら直ちに予報をチェック。 - 青点滅：高齢者世帯の安否確認装置に反応があった場合
（Parse.com サーバサイドの Cloud Code を利用）
クリックで可読大表示
人を検知すると最短 30分間隔で Parse.com へレポートを送出する自作装置を実家で稼働中。対向するサーバ側コードに試作への通知処理を追加。光れば安心、メールによる通知よりも即時性が高く煩雑感が小さい。 - 赤点滅：特定のユーザからのツイートがあった場合
（IFTTT レシピを利用）
クリックで可読大表示
件数は少ないがいつも非常に有用な情報を提供してくれる某氏のツイートを見落とさないために。
- 緑点滅：所定のブログが更新された場合
（IFTTT レシピを利用）
クリックで可読大表示
とりあえず昨年末 「KLab Advent Calendar 2015」のチェック用に使ってみたらとても快適。
- 管理用 HTML フォーム
クリックで可読大表示
PC・スマホの Web ブラウザから装置へメッセージを手早く簡単に送るために用意。 [ソース]
装置について
外観と構成
材料
- ESP8266 モジュール CDP-ESP8266 - Cerevo ￥842（税別）
- ブレッドボード EIC-15010 - スイッチサイエンス ￥216（税込）
- ケーブル取付用ＵＳＢコネクタ（Ａタイプ オス） - 秋月 ￥70（税込）
- 低損失三端子レギュレーター ３．３Ｖ５００ｍＡ ＴＡ４８Ｍ０３３Ｆ（Ｓ Ｑ） - 秋月 ￥100（税込）
※ノイズ除去用・電圧安定用のコンデンサ 2個が同梱 - ＬＥＤ光拡散キャップ（３ｍｍ） 白 （２０個入） - 秋月 ￥100（税込）
- ハイパワー青色ＬＥＤ ３ｍｍ ＯＳＵＢ３１３１Ｐ １０個入 - 秋月 ￥250（税込）
- ３ｍｍ 緑色ＬＥＤ ＥＢＧ３４０２Ｓ （２０個入） - 秋月 ￥100（税込）
- ３ｍｍ黄色ＬＥＤ ５９０ｎｍ ＯＳＹ５ＣＡ３１３１Ｐ（１０個入） - 秋月 ￥200（税込）
- 赤色ＬＥＤ ３ｍｍ ＯＳＤＲ３１３３Ａ ５００ｍｃｄ ３０度１００個入 - 秋月 ￥350（税込）
- カーボン抵抗・ジャンプワイヤ・タクトスイッチ・熱収縮チューブ
- タッパ・輪ゴム・エアキャップ
メモ
- blink(1) は PC など対応機器の機能を利用するが今回の装置はネットワーク専用であり通信機能を内蔵しているため USB AC アダプタでも使える
- USB 端子は規格上両端の2本が 5V (500mA) OUT と GND
- フルカラー LED ではなく赤・緑・青・黄の 4つの単色 LED を使用。LED 用の抵抗は現物の発色をみながら「赤 75Ω 緑 75Ω 青 470Ω 黄 390Ω」に
- LED の表示は各色「点灯・点滅」の二種類で合計 8パターン。これは手元での実利用を想定し妥当と判断した数
（複数 LED の点滅時は明滅のタイミングが重ならないようプログラム側で管理） - 輪ゴムは USB コネクタ外抜け防止用
- エアキャップはタッパ蓋の下に中敷き。LED 光拡散、外観柔和化、USB コネクタとタクトスイッチの圧迫用
- タッパ蓋の上からタクトスイッチを押すと装置がリセットされる。電源接続時と LED 消灯用に使う
プログラムについて
ESP8266 用 PubNub ライブラリ
前述のように現時点では PubNub は ESP8266 を正式にサポートしておらず Espressif 社純正 SDK 向けの非公式ライブラリが公開されているのみです。これに以下の要領で手を加えて使用しています。
以下にソースコードを掲載します。ライブラリ「pubnub-esp8266」はファイル一式をローカルの Arduino ライブラリフォルダ下の pubnub-esp8266/ 下へコピーして使います。
（キーワード "DSAS" 部分がオリジナルからの変更箇所）
pubnub.h - GitHub
pubnub.cpp - GitHub
Arduino スケッチ
アプリ側のコードです。Arduino の SimpleTimer ライブラリを併用しています。
LEDMessage.ino - GitHub
作るのは簡単、アイディア次第でとても便利に使えます。
(tanabe)
今、ワンボタンの IoT デバイスが面白い
なお、今のところこのサービスの日本での開始はスケジュールされておらず、米アマゾンから Dash Button 単体を購入することもできません。
2016-12-22 追記：
Amazon.co.jp は 2016年12月5日に日本国内で Dash Button サービスを開始しました。これに伴い関連する以下の記事を当ブログに追加しています。
ワンボタンデバイスのメリットと応用例
Amazon Dash Button は事業形態としても面白そうですがこの記事ではデバイス本体に注目します。Dash Button の実体はマイコンと無線 LAN モジュールを主要素とする乾電池駆動の IoT デバイスです。
http://mpetroff.net/
Dash Button は独立した装置なので必要な折にスマートフォンアプリ等よりも素早く使用することが可能。ボタンひとつの単機能であることが手軽さと即応性をさらに高めています。 この迷いようのないユーザインターフェイスは、その素朴さとは裏腹に、関係者が消費者への効果的なアプローチを模索する過程において綿密に戦略を練った結果と想像されます。一見「誰でも思いつきそうなこと」はそれが本当に実現されればしばしば斬新です。手軽さといえばスマホばかりに目が向けられる現状においてあえて専用ハードの形態を選んだ発想には学ぶべき要素があるように思います。
このデバイスのアイディアはビジネス用途以外の IoT においても広く活用することが可能でしょう。「物理ボタンの押下」という手間がかからず誰にでもできる簡単な操作をトリガーにどのような処理を行うかはアイディア次第であり、その便宜と魅力に気づいた向きがこの安価な Dash Button を本来の目的以外のことに利用し始めています。以下にいくつか例を挙げます。
- How I Hacked Amazon’s $5 WiFi Button to track Baby Data （2015ｰ08ｰ10） - medium.com
おそらくこれが最初の Dash Button 転用例。Edward Benson 氏は自宅で乳児の排泄日時を手早く記録・管理する手段を探す中で、夜中にスマホを操作する煩わしさもなくボタン押下のみで完結する Dash Button の長所に着目した。
"using your smart phone at night disrupts sleep. I want a simple button I can stick to the wall and push to record"Amazon へのオーダーを行う上で本来必要な初期設定を意図的に保留。デバイス本体をハックするのではなく、ボタン押下〜デバイス起床時に LAN 上に流れる ARP パケットに注目し、当該デバイスの MAC アドレスを検出すればそれをトリガーに PC で処理を実行する手法によって要件を実現した。
https://medium.com/ -
Amazon Dash — It’s Dinner Time! （2015ｰ08ｰ27） - theappslab.com
Raymond Xie 氏は Dash Button のコストパフォーマンスの高さに大喜び。稼働中に熱を持つ PiTFT をコードを抜かず簡単に ON/OFF する目的にさっそく利用していたところ奥方からもっと実用的なことはできないの？と聞かれ、ヘッドホン装着率の高い二階の子供たちを夕食時にいちいち呼びに行く代わりに Dash Button で子供部屋の フィリップス ヒュー を点滅させることを思いつく。Button は台所の奥方の手に。 -
PizzaDash （2015ｰ09ｰ12） - github.com/bhberson
前出の Benson 氏の記事に触発された、と Brody Berson 氏は Dash Button をドミノピザの宅配オーダーに利用（無論アマゾンとは無関係）。ボタン押下をトリガーに Raspberry Pi が ドミノピザ公式 API を叩いて注文成立。
2015-11-25 追記：
英国ドミノピザが公式にワンボタンのオーダーサービスを開始する旨の情報あり （2015-11-23)- Domino's makes ordering pizza dangerous with 'Easy Order' button - www.engadget.com
- 押すだけでドミノ・ピザが届く「Easy Order ボタン」発表。12月に英国で争奪イベント実施 - japanese.engadget.com
- Praise pizza: Domino's 'Easy Order' button gets you a pie super fast - mashable.com
-
Amazon dash button automation silliness. （2015ｰ09ｰ26） - www.youtube.com
Michael Donnelly 氏による Youtube への投稿動画。玄関の照明を点灯／消灯したり、ガレージの車の内部が一定の温度になったらクラクションを鳴らしたり。 -
Dash Hacking: Bare-Metal STM32 Programming - learn.adafruit.com
Adafruit 社 の TONY DICOLA 氏による正面からの Dash Button ハックの試み。ファームウェアを書き換え本体の LED を自作のコードで制御。"this guide didn't touch on the Dash's WiFi module yet" とのこと。
また、米アマゾンウェブサービス（AWS）は 2015年10月の AWS IoT ベータ公開にあわせ、Amazon Dash Button と同一のハードを使った AWS IoT Button (beta)を発表しました。10月6〜9日にラスベガスで開催された「AWS re:Invent 2015」の会場では参加者へ AWS IoT 体験用に配布されています。ボタンを押すと AWS IoT サービスへ通知され利用者の記述した処理を実行できるしくみです。
さらに、クラウドファンディング発の次のようなオリジナルのボタン製品も登場しています。またこれからも新しいものが出てくることでしょう。
このように「ボタンひとつ」の IoT デバイスの有用性がいま注目されています。
工作と実験
こういった事情を背景にワンボタンデバイスを自作する向きもあり（例 1・例 2）、試みに手元でも手近な材料を使って作ってみることにしました。装置が形になればそこにどのような処理を絡めるかは自由ですが、まずもっとも身近な題材のひとつとして自分あてのメール送信機能を組み込みました。
試作の動作の様子 （動画：30秒）
装置について
試作した装置の材料と構成は以下の通りです。Arduino IDE for ESP8266 プロジェクトのリソースを使用し ESP8266 Wi-Fi モジュールをスタンドアロンのマイコンとして制御しています。
（価格は 2015年10月時点）
※説明欄の「単三電池三本の形状」の記述は「単四電池三本」が正しい
メモ
ESP8266EX Datasheet Version 4.4 (2015-08-01) Page 8
（クリックで可読大表示）
条件として、使用者が 1日に 2回、起床時と就寝時にボタンを押すものとする。この場合、前掲の値を当てはめると 1日のうち 2 × 10秒間が 80mA、残りの 86380秒間が 11μA（0.011mA）であり、平均をとるとおよそ 0.03mA。
自然放電特性を加味せず www.digikey.jp の 電池寿命カリキュレータで単純計算すると今回のロワの 800mAh のバッテリーの場合は次の結果となる
800mAh / 0.03mA * 0.7 ≒ 18666.67 時間 ≒ 777.78 日 ≒ 25.1 月 ≒ 2.1 年
Amazon Dash Button Teardown - mpetroff.net
AWS IoT Buttonを分解してみた - Developers.IO
※プラス極側の黒地に白文字の「12-2034」「12-2035」等の表記は未使用時の品質保持期限を示す。20年！
http://mpetroff.net/
"The Dash Button operates at 3.3 V boosted from the battery’s nominal 1.5 V, drawing 200–300 mA from the battery when on and 2.3 μA when in sleep."
現時点では Dash Button の battery life に関する公式の記述は見当たらず
Energizer L92BP-Energizer Ultimate Lithium AAA Battery (4-Pack) - www.amazon.com ＄7.99
エナジャイザー リチウム乾電池単4形 4本パック - www.amazon.co.jp ￥1250
プログラムについて
メールの送信には「SendGrid」を利用しています。その方面ではメジャーなサービスであり、国内に正規代理店（株式会社 構造計画研究所）があり日本版の公式サイトも運営されています。濫用防止のためサインアップの際には使用目的等の詳細説明が求められアカウント発行可否は人間によって審査されます。
フリープランで 400通／日の送信が可能であり手元での利用にはまず十分そうです。ドキュメント・API も充実しています。
今回は単純明快でくみしやすい初版のほうの Web API を利用することにしました。
ところで、多くのクラウドサービスがそうであるように SendGrid Web API の利用にも HTTPS が必須です。
Arduino IDE for ESP8266 プロジェクトは 2015-08-31 より TLS 1.0/1.1 への対応を始めており利用者の一人として大いに期待しているのですが、この記事を書いている 2015年11月初旬の時点ではなお活発に開発が進行中で、stable になるまでにはまだ多少時間がかかりそうです。
※「最新情報については、SendGrid公式ドキュメント(英語)をご覧ください」との注釈あり
そうした事情もあり、先だって「ESP8266 モジュールの AT コマンドに SSL クライアント機能を追加する」の試みで Espressif 社によるサンプルプログラムをもとに構成した HTTPS クライアントコードに手を加え、当面 Arduino IDE でライブラリとして使うことにしました。もちろんメールサービス以外の用途にも利用できるでしょう。
※手元の Arduino IDE for ESP8266 のバージョンは現時点で stable な 2015-07-23 リリースの「1.6.5-947-g39819f0」なのですが、この版に 同梱されている Espressif ライブラリを使ってスケッチをビルドすると SendGrid の API サーバ である https://api.sendgrid.com/ への接続 要求時に異常終了の発生を確認しました。同ライブラリ群の配置された packages/esp8266/hardware/esp8266/1.6.5-947-g39819f0/tools/sdk/lib/ 配下の *.a を現時点で最新の esp_iot_sdk_v1.4.0_15_09_18 に 含まれる一式に差し替えたところ問題の解消が見られました。
以下にソースコードを掲載します。ライブラリ「EspHttpsClient」はファイル一式をローカルのライブラリフォルダ下の EspHttpsClient/ 下へコピーして使います。
ライブラリ：EspHttpClient
EspHttpClient.h - GitHub
EspHttpClient.cpp - GitHub
スケッチ：OneButtonMailer
OneButtonMailer.h - GitHub
また、多少遅延が発生する可能性はあるものの、専用のサービスの代わりに手近に IFTTT の Maker Channel を利用する選択肢もあるでしょう。目的がメール送信であれば下図の例の要領でレシピを作成しておきます。 （クリックで可読大表示）
このレシピを呼び出すスケッチです。
OneButtonMailer_IFTTT.h - GitHub
付録
Espressif 社のドキュメントより ESP8266 のスリープモードに関する記述箇所を以下に抜粋します。
（クリックで可読大表示）
「ESP8266EX Datasheet Version 4.4 (2015-08-01) 」より
「ESP8266 SDK API Guide Version 1.4 (2015-09-18)」中の system_deep_sleep() および system_deep_sleep_set_option() のリファレンス
(tanabe)
ESP8266 モジュール + Blynk でさらりと Wake On Wan
- （※）公式サイトの「FAQ」より
+ I backed Blynk on Kickstarter. Where are my widgets and why the app is free? - App is free becasuse otherwise you would have to pay to download it. This is how AppStore and Google Play works. - Current Blynk release has a limited amount of widgets. We decided to make them free for everyone until we implement store. After that,every widget will be paid. However every backer will get them for free (according to their pledge).
準備
まず Blynk の利用を構成するみっつの要素を整理しておきます。
- Blynk アプリ
Google Play / AppStore で公開中の専用アプリを使ってユーザが構成した制御用のアプリ - IoT デバイス
専用の Blynk ライブラリを使ってユーザが作成したプログラムを導入ずみの制御対象の装置 - Blynk サーバ
Blynk アプリと IoT デバイスの連係を仲介するクラウドサービス（※オープンソースであり自前での構築も可能）
Android / iOS 端末にはそれぞれの公式ストア上で配布されている専用のアプリ「Blynk」をインストールします。利用者はこのアプリを使って独自の Blynk アプリを構成することができます。
Blynk アプリに対向する IoT デバイスのためのプログラム開発には Arduino IDE を使用します。あらかじめ IDE に ESP8266 用ライブラリモジュールを導入しておき、そこへ Blynk の提供するライブラリ群をインストールします。
Blynk の公式ドキュメントには Blynk を利用する上で必要となるこういった情報・手順がわかりやすく記述されています。また、ネットを検索すれば多くの有用な記事を参照することができます。
試作の題材について
手元のニーズに基き、Blynk を使った遠隔制御の身近な応用例として次の内容を想定しました。IoT デバイスは対象の PC と同じ LAN 環境へ設置します。
- 所定の PC を Wake On Wan する
- 所定の PC へ ping を打つ
- 所定の AC 機器への給電を ON / OFF する
- 制御対象の IoT デバイスをリセットする
外出中に自宅の PC を利用したくなる場合があります。PC をずっと起ち上げたままにしておくのは好ましくないので、これまでは遊んでいる Android 端末を自宅で待機させておき GCM 経由で所定の PC を Wake On Lan するという方法をとっていました。それはそれで問題なく機能しているのですが、必要な手順を踏むのがだんだん面倒になってきたことに加え、その場で手早く PC の起床状況を確認できないことに不便を感じていました。確認方法は所定の IP アドレスに対する ping テストで十分でしょう。
上記 3.は拡張用です。手元では留守の夜の防犯用に自宅の部屋の電灯を任意のタイミングで点灯／消灯するために使っています。これまでは上の PC に接続した USB 赤外線リモコンで操作を行っていましたが、それも面倒なので別の手段がほしいと思っていました。
実装方法について
Wake On Lan マジックパケットの送出と所定の PC への ping 打ちは Blynk の「Virtual Pin」機能を使って IoT デバイス側と連携すれば簡単に実現できると考えました。Blynk アプリ上に配置したボタンの設定において「OUTPUT」に物理ピンではなく適当な仮想ピンの番号を割り当てて、受け側の IoT デバイス側のコードに "BLYNK_WRITE(仮想ピン番号）" ハンドラを定義してそこに必要な処理を記述すればよいはずです。
-
Send data from app to hardware - Blynk 公式ドキュメント - blynkkk.github.io
Send data from app to hardware You can send any data from Widgets in the app to your hardware. All Controller Widgets can send data to Virtual Pins on your hardware. For instance, code below shows how to get values from the Button Widget in the App BLYNK_WRITE(V1) //Button Widget is writing to pin V1 { int pinData = param.asInt(); } When you press Button, Blynk App sends 1 On second click - it sends 0 This is how Button Widget is set up:
- Wake On Lan マジックパケットの仕様に関する記事
- WakeOnLAN - The Wireshark Wiki - wiki.wireshark.org
- Magic Packet Technology White Paper (PDF) - support.amd.com
- Espressif 社公式フォーラムの以下の記事の末尾に ESP8266 で ping を実行するサンプルコードあり
- Ping_start function - bbs.espressif.com
-
Virtual Pins - Blynk 公式ドキュメント - blynkkk.github.io
Virtual Pins Virtual Pins are designed to send any data from your microcontroller to the Blynk App and back. Think about Virtual Pins as channels for sending any data. Make sure you differentiate Virtual Pins from physical pins on your hardware. Virtual Pins have no physical representation. Virtual Pins can be used to interface with libraries (Servo, LCD and others) and implement custom functionality. The device may send data to the Widget to the Virtual Pin like this: Blynk.virtualWrite(pin, "abc"); Blynk.virtualWrite(pin, 123); Blynk.virtualWrite(pin, 12.34);
- ソリッド・ステート・リレー（ＳＳＲ）キット ２５Ａ（２０Ａ）タイプ
- akizukidenshi.com ￥250 （2015年10月8日時点）
「出力制御電圧：ＡＣ１００Ｖ，２５Ａ（十分に放熱した場合） 放熱しない場合は２Ａぐらい（２００Ｗ）までです」と注意書きが添えられています。
※余談ながら、個人的にはこのように高電圧を扱うものは本当はあまり自作したくないです。その方面に素養がなくても部品を揃えれば作るのは簡単ですが、「手作りの楽しさ」などよりも安全性がもっとも重要ですから、手頃な価格で堅牢な完成品を入手できるならそれを使いたいというのが正直なところです。残念ながら今のところそういう商品は見当たらないようですが（需要はあると思うのですが・・）、上のキットを使ってリレーつき電源ケーブルを作る方法が下記の書籍にわかりやすく記載されています。
動作の様子
ひと通り形になったものが動作している様子を以下の動画に収めています。（1分56秒 環境音あり）
内容：
- IoT デバイス稼働中は死活確認用の LED が 2秒間隔で点滅、そのタイミングでアプリの TICK フィールド（デバイス稼働秒数）が更新される
- アプリの BOOT PC ボタン押下で IoT デバイスが所定の PC を Wake On Lan する
- アプリの PING ボタン押下で IoT デバイスが所定の PC へ ping を投げアプリの OK / NG フィールドへ結果をカウント
- アプリの AC DEVICE ボタン押下で IoT デバイスへ接続した AC 機器への給電を ON / OFF
- アプリの RESTART ボタンを長押し（3秒以上）してリリースすると IoT デバイスは再始動する
リソース一式
今回の Blynk アプリおよび IoT デバイスを構成する要素は以下のとおりです。
※各画像はクリックで実寸表示
Blynk アプリ側
Android / iPhone での当該 Blynk アプリの画面表示
IoT デバイス側
装置全体の様子
※ESP-WROOM-02 モジュールは Cerevo 社製のブレイクアウト基板「CDP-ESP8266」とともに使用
※稼働状況確認用に IO4 に赤色 LED を、AC 機器制御用に IO12 にリレーつきケーブルを装着しているが不要ならどちらも省略可
リレーつき電源ケーブル
ソースコード
（SimpleTimer ライブラリのインストールが必要です）
ESP8266_WakeOnWan.ino - github.com/mkttanabe
留意すべき事項など
Blynk は便利で有用ですが現在進行形で開発中であるため利用時に若干注意しなければならない点もあります。今回手元で気づいた話題をメモしておきます。
Blynk ライブラリ旧バージョンでの不具合について（重要）
2015-08-06 にリリースされた v0.3.0 までのBlynk ライブラリには ESP8266 モジュールのハンドリングに大きな不具合があります。同モジュール − Blynk サーバ間の持続接続に不意に切断が発生した場合に無限ループに陥りデバイスをリセットしない限り再接続不能となる問題です。この不具合は 2015-09-24 にリリースされた v0.3.1 では修正されており、切断が発生した場合に接続を自動復旧する機構が正常に機能するようになっています。この修正により連続稼働が安定するようになりました。Blynk で ESP8266 を使う場合は必ずこの v0.3.1 以降のライブラリを使うべきです。公式フォーラム上の以下の記事に関連する応酬があります。
- ESP8266 Freeze - community.blynk.cc
Android - iOS 端末間の Blynk アプリの互換性について
Blynk は Android と iOS に対応していますが、両方のプラットフォームで等しく動作する Blynk アプリを構成するためには以下の点への注意が必要です。
- 2015年10月8日時点の Android 版 Blynk の最新バージョンは "1.0RC7 fix"、iOS 版 Blynk の最新バージョンは "1.3" です。バージョン番号は iOS 版のほうが上ですが、Android 版で利用可能なウィジェットうち iOS 版ではまだ実装されていないものがいくつかあります。下図左は Android 版 "1.0RC7 fix、右は iOS 版 "1.3" でのウィジェット一覧です。
iOS 版未実装のウィジェットを Android 版で配置して保存したアプリを iOS 版で開くとその部分が空白となります。それだけではなく、そのアプリを iOS 版で保存すると当該ウィジェットは失われます。要注意です。
- Using same blynk project on two different phones - community.blynk.cc
- Android 版では LED ウィジェットが正常に機能しません
- Android app virtual LED bug? - community.blynk.cc
最後に
Prepare to Blynk! - www.kickstarter.com に掲載されているイラスト
がんばれ Blynk！
(tanabe)
ESP8266 モジュールの AT コマンドに SSL クライアント機能を追加する
ただ、この AT コマンドセットで HTTPS リクエストを処理する方法が見当たらないことを不思議に思っていました。あらためてドキュメントを確認するとどうやら AT コマンドで SSL 通信を扱うことはできないようです。プログラマブルであることがこの製品の魅力のひとつであるとは言え 出荷時の状態で SSL を利用できないのはそのこと自体が残念に思われます。AT コマンドのインターフェイスそのものは何かと便利なのでこれを拡張する形で SSL への対応を試みました。
最終的にはサーバ証明書の検証も含め期待通りに動作しましたが、その過程で意外な曲折もあり、手元で経験したことを備忘をかねてほぼ順番どおりに記録しておくことにします。興味のある方は追ってみて下さい。
AT コマンド拡張について
メーカーは次のページで ESP8266 用の SDK を公開しています。
- http://espressif.com/new-sdk-release/ - espressif.com
2015-08-21 時点の最新版は以下の通りです。
- esp_iot_sdk_v1.3.0_15_08_08 - bbs.espressif.com
- esp_iot_sdk_v1.3.0 patch for SSL issue - bbs.espressif.com
SDK アーカイブを覗いてみると examples/at/ ディレクトリ下に AT コマンドセットを拡張するためのサンプルコードが収録されており「AT+CIUPDATE」コマンドは他のコマンド群とは別にここで定義されていることが見てとれます。
examples/at/user/user_main.c
コードの末尾付近の at_custom_cmd[] テーブルには「AT+CIUPDATE」に加え「AT+TEST」という拡張コマンドが記述されています。拡張コマンドの定義の方法は次の記事に説明があります。
In the example of \esp_iot_sdk\examples\at\user\user_main.c, ways are delivered on how to implement a self-defined AT Command, AT+TEST”. The structure, at_funcationType, is used to define four types of a command, e.g., “AT+TEST”. "at_testCmd" is a testing command and it’s formatted as AT+TEST=?. In the example of AT, the registered callback is “at_testCmdTest”; the testing demand could be designed as the value range of the return parameter. If registered as NULL, there will be no testing command. "at_queryCmd" is a query command and it’s formatted as AT+TEST?. In the example of AT, the registered callback is “at_queryCmdTest” ; the query command could be designed as returning the current value. If registered as NULL, there will be no query command. "at_setupCmd" is a setup command and it’s formatted as AT+TEST=parameter1,parameter2,........ In the example of AT, the registered callback is "at_setupCmdTest"; the setup command could be designed as the value of the parameter; if registered as NULL, there will be no setup command. "at_exeCmd" is an execution command and it’s formatted as AT+TEST. In the example of AT, the registered callback is “at_exeCmdTest”; if registered as NULL, there will be no execution command.一連の書式は他のコマンドでも見かけるものです。一読したところでは既存のコマンドセットにオリジナルの AT コマンドを追加することはあまり難しくないようです。
SDK に同梱のビルドずみファームを書き込んでみる
SDK の bin/ ディレクトリにはメーカー側がビルドしたファームウェアバイナリ群が格納されています。
ESP-WROOM-02 出荷時の標準ファーム（AT コマンドセット）は以下のバイナリから構成されます。
- bin/boot_v1.2.bin ---- ブートローダ
- bin/at/user1.1024.new.2.bin ---- AT コマンドプログラム本体
- bin/blank.bin ---- 領域初期化用 中身は 0xFF * 4096バイト
- bin/esp_init_data_default.bin --- "Stores default RF parameter values"
自作のファームをビルドして書き込む前に、まずこれらを練習台として内蔵フラッシュメモリに書き込んでみることにしました。 正しく書き込めるようになっておけばいざと言うときの切り戻しも楽でしょう。
「bin/at/readme.txt」冒頭に次の記述があります。
download: boot_v1.2+.bin 0x00000 user1.1024.new.2.bin 0x01000 blank.bin 0x7e000 & 0xfe000
※「user1.1024.new.2.bin」の「1024」は 1024KB（8Mbit）容量のフラッシュメモリ使用を想定してビルドされたバイナリであることを意味する。ESP-WROOM-02 は 32Mbit のフラッシュメモリを内蔵しているが、以下の記事においてはこのバイナリの仕様に準じ 8Mbit 空間範囲の使用を前提とする。
※「esp_init_data_default.bin」には RF（Radio Frequency）パラメータのデフォルト値が保持されている旨の説明が SDK の「ESP8266 IOT SDK User Manual」に記載されている。次の記事にも説明あり。
- PURPOSE OF ESP_INIT_DATA_DEFAULT.BIN - www.esp8266.com
- Flash Download Tool - bbs.espressif.com
（図は Windows 版）
※1024KB フラッシュ使用時のメモリマップ
- SDK の「Espressif IOT SDK User Manual」より
Note
• System param (system parameter area) is the last 16KB offlash.
• User param is the user parameter area used by Espressif demo code
( IOT_Demo or AT ). If users develop their own application,
user data can be saved in any available flash area.
• User Data area ( green area in pictures below ) means the flash
area that may be available, if program area doesn’t reach the
maximum size, remaining area can be used to save user data.
動作確認
AATTEE00 OK AT+GMR AT version:0.40.0.0(Aug 8 2015 14:45:58) SDK version:1.3.0 compile time:Aug 8 2015 17:19:38 OK AT+CWMODE=1 OK AT+CWLAP +CWLAP:(1,"GPMAP",-93,"10:6f:3f:XX:XX:XX",1,-47) +CWLAP:(0,"000D0BF6C164_G",-91,"00:16:01:XX:XX:XX",5,-32) +CWLAP:(3,"hogehogeSSID",-72,"00:22:cf:XX:XX:XX",10,-91) +CWLAP:(2,"STWEBKAIGI",-88,"4c:e6:76:XX:XX:XX",10,-27) +CWLAP:(4,"elecom2g-DE8564",-90,"00:90:fe:XX:XX:XX",10,-26) +CWLAP:(3,"e-timer-DE8564",-90,"02:90:fe:XX:XX:XX",10,-26) +CWLAP:(3,"auhome_acyCYh",-92,"8c:4c:dc:XX:XX:XX",1,-31) OK
開発環境の導入
ESP8266 モジュールのファームウェア開発には現在 Arduino 向けの IDE・言語を用いることも可能ですが SDK に含まれるコードはいずれもネイティブの開発環境を前提としているため今回はそれを使います。
メーカーは必要な一式をインストールずみの開発環境（Linux）の VirtualBox 仮想マシンイメージを配布しており、導入手順・方法は以下の記事で説明されています。
- Step 1. Setup Linux Compile Environment - bbs.espressif.com
- SDK の一式を配置した PC 上のディレクトリを "share" の名前で VirtualBox 仮想マシンの共有フォルダとして設定しておく
- 仮想マシンのデスクトップ上の "LXTerminal" を起動するとアカウント esp8266 でターミナルが開く
- アカウント esp8266 ホームディレクトリの ./mount.sh を実行すると PC 上の共有フォルダが ~/Share にマウントされる
- アカウント esp8266 のパスワードは "espressif"
※仮想マシンのタイムゾーンは CST 北京時間に設定されているため変更が必要です
ファームウェアをビルドしてみる
SDK の examples/ 下には複数のサンプルプロジェクトが配置されており、利用するプロジェクトのファイル群をそこから app/ 下へ丸ごとコピーして使います。今回は前述のとおり examples/at/* を使用します。
仮想マシン側で app/ へ移動し gen_misc.sh スクリプトを実行するとバイナリがビルドされます。 以下のビルド開始時のオプション指定はメーカー側ビルドでの内容に準じています。
$ pwd
/home/esp8266/Share/esp_iot_sdk_v1.3.0_15_08_08_build/esp_iot_sdk_v1.3.0/app
$ make clean
make -C user clean;
make[1]: Entering directory `/mnt/Share/esp_iot_sdk_v1.3.0_15_08_08_build/esp_iot_sdk_v1.3.0/app/user'
rm -f -r .output/eagle/debug
make[1]: Leaving directory `/mnt/Share/esp_iot_sdk_v1.3.0_15_08_08_build/esp_iot_sdk_v1.3.0/app/user'
rm -f -r .output/eagle/debug
$./gen_misc.sh
gen_misc.sh version 20150511
Please follow below steps(1-5) to generate specific bin(s):
STEP 1: choose boot version(0=boot_v1.1, 1=boot_v1.2+, 2=none)
enter(0/1/2, default 2):
1
boot mode: new
STEP 2: choose bin generate(0=eagle.flash.bin+eagle.irom0text.bin, 1=user1.bin, 2=user2.bin)
enter (0/1/2, default 0):
1
generate bin: user1.bin
STEP 3: choose spi speed(0=20MHz, 1=26.7MHz, 2=40MHz, 3=80MHz)
enter (0/1/2/3, default 2):
spi speed: 40 MHz
STEP 4: choose spi mode(0=QIO, 1=QOUT, 2=DIO, 3=DOUT)
enter (0/1/2/3, default 0):
spi mode: QIO
STEP 5: choose spi size and map
0= 512KB( 256KB+ 256KB)
2=1024KB( 512KB+ 512KB)
3=2048KB( 512KB+ 512KB)
4=4096KB( 512KB+ 512KB)
5=2048KB(1024KB+1024KB)
6=4096KB(1024KB+1024KB)
enter (0/2/3/4/5/6, default 0):
2
spi size: 1024KB
spi ota map: 512KB + 512KB
start...
make[1]: Entering directory `/mnt/Share/esp_iot_sdk_v1.3.0_15_08_08_build/esp_iot_sdk_v1.3.0/app/user'
DEPEND: xtensa-lx106-elf-gcc -M -Os -g -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions
-nostdlib -mlongcalls -mtext-section-literals -ffunction-sections -fdata-
（中略）
!!!
Support boot_v1.2 and +
Generate user1.1024.new.2.bin successully in folder bin/upgrade.
boot.bin------------>0x00000
user1.1024.new.2.bin--->0x01000
!!!
以上の手順で bin/upgrade/ 下に生成される user1.1024.new.2.bin を前出の bin/at/user1.1024.new.2.bin の代わりにフラッシュメモリの 0x01000 番地を起点に書き込めば完了です。
なお、boot*.bin, blank.bin はユーザによるビルドの対象ではありません。これらは SDK に含まれているものをそのまま使います。
HTTPS クライアント処理はどのように書けばいいの？
SDK にはドキュメントとして「ESP8266 SSL User Manual」が同梱されています。しかし、現時点では ESP8266 モジュールでの SSL 利用に関する情報は少ないのが実状です。
ちなみに、IBM 所属の Neil Kolban 氏が 2015年8月1日に公開した「Kolban's book on the ESP8266」は技術情報が詳細に記述された貴重な資料ですが、同著においても SSL 処理については API の紹介のみに留まっています。
- ANNOUNCE: FREE BOOK ON THE ESP8266 - www.esp8266.com
- Kolban’s book on the ESP8266 - Neil Kolban Tech - neilkolban.com
各国の利用者も手探りの途中といった印象で次のような応酬が随所で見受けられます。
- DOES ESP8266 SUPPORT SSL TO RETRIEVE DATA FROM HTTPS SITES? - www.esp8266.com
By helpme - Tue Jun 30, 2015 5:14 am Can the ESP8266 support HTTPS websites? Does the Espressif SDK support SSL function?
By Angelo Santagata - Tue Jun 30, 2015 4:51 pm Alas I no, but I happened to see this ESP8266 SSL Example on their website! http://bbs.espressif.com/viewtopic.php?f=21&t=389 hopefully someone can port it to the SDKというわけで、メーカー側は下記ページに HTTPS クライアント処理のサンプルコードを掲載しています。
- ESP8266 as TCP SSL client - bbs.espressif.com
Here is a demo code of ESP8266 as TCP SSL client. It is based on ESP8266 SDK without OS. It just like ESP8266 to be normal TCP client except change espconn_xxx to be espconn_secure_xxx If your SSL packet is larger than 2048 bytes, please try to call espconn_secure_set_size to enlarge SSL buffer size (max:8192 )
このコードを下敷きに AT コマンドを拡張すればよいと考えました。
AT コマンド拡張では SSL 処理が正常動作しない？？ (SDK v1.2.0)
さっそく自作の +GETTEST コマンドを書いてみました。
ちなみにこの実験の時点で使用していた SDK は 2015年8月初旬当時の最新版だった v1.2.0 です。
- esp_iot_sdk_v1.2.0_15_07_03 - bbs.espressif.com
- SDK v1.2.0 Patch for SSL - bbs.espressif.com
試作した +GETTEST コマンドは次の内容です。
AT+GETTEST="hostname" で当該ホストへ "GET /" リクエストを送る
AT+GETTEST --- 引数がなければ www.example.com:80 へ HTTP リクエスト
AT+GETTEST="www.example.com",0 --- 2nd arg が 0 なら
80番ポートへ HTTP リクエスト
AT+GETTEST="www.example.com",1 --- 2nd arg が 1 なら
443番ポートへ HTTPS リクエスト
AT+GETTEST="www.example.com",1,0 --- 3rd arg が 0 ならサーバ証明書検証なしで
443番ポートへ HTTPS リクエスト
AT+GETTEST="www.example.com",1,1 --- 3rd arg が 1 ならサーバ証明書検証ありで
443番ポートへ HTTPS リクエスト
ソースコードを以下に示します。
（注：これらはその後の調査結果も反映したものです。最初の実験の段階ではずっとラフな内容でした） ところがこの AT+GETTEST コマンドは期待通りには動作しませんでした。HTTP リクエストは正しく処理されるものの HTTPS リクエストではエラーが発生するのです。
AATTEE00 OK AT+GMR AT version:0.30.0.0(Jul 3 2015 19:35:49) SDK version:1.2.0 compile time:Aug 11 2015 14:09:10 OK AT+GETTEST="www.example.com",1 mode : sta(18:fe:34:a4:0f:a0) + softAP(1a:fe:34:a4:0f:a0) add if0 11 f 0, 221 scandone add 0 aid 4 connected with hogehogeSSID, channel 10 WIFI CONNECTED dhcp client start... WIFI GOT IP ip:10.10.0.19,mask:255.255.255.0,gw:10.10.0.1 got ip !!! start connect to server client handshake start. client handshake failed reconnect callback, error code -28 !!!エラーコード -28 は SDK の include/espconn.h に定義されています
/* Definitions for error constants. */ #define ESPCONN_OK 0 /* No error, everything OK. */ #define ESPCONN_MEM -1 /* Out of memory error. */ #define ESPCONN_TIMEOUT -3 /* Timeout. */ #define ESPCONN_RTE -4 /* Routing problem. */ #define ESPCONN_INPROGRESS -5 /* Operation in progress */ #define ESPCONN_ABRT -8 /* Connection aborted. */ #define ESPCONN_RST -9 /* Connection reset. */ #define ESPCONN_CLSD -10 /* Connection closed. */ #define ESPCONN_CONN -11 /* Not connected. */ #define ESPCONN_ARG -12 /* Illegal argument. */ #define ESPCONN_ISCONN -15 /* Already connected. */ #define ESPCONN_HANDSHAKE -28 /* ssl handshake failed */ #define ESPCONN_SSL_INVALID_DATA -61 /* ssl application invalid */ハンドシェイクに失敗しているようですがこれでは何もわかりません。さて？
SDK v1.2.0 での AT コマンド拡張内で SSL が機能しない理由
不審に思い情報を探したところ同じ問題に遭遇したユーザとスタッフの応酬に気づきました。
- SSL connection via AT commands - bbs.espressif.com
Re: SSL connection via AT commands Postby doughboy ≫ Tue Apr 21, 2015 11:59 pm I am writing AT command to support SSL, but it seems none of the espconn_secure_* api works. At least when I connect to real ssl servers using real cerfificates. (and yes, I have set buffer size to 8196 and use the patched ssl library) esp module will reset (I think due to wdt timeout). I already reported this via email.
Re: SSL connection via AT commands Postby Espressif_Faye ≫ Mon Apr 27, 2015 10:22 am Hi, doughboy, We debugged on your problem, it's the RAM limitation cause that. AT commands has only 17KBytes available heap now， SSL need 12KBytes free heap size, if you espconn_secure_set_size to set 5KBytes，it is not enough.. So SSL can not be used in AT commands because RAM is limited. Sorry for the inconvenience.
AT コマンドプログラム実行時には残ヒープが 17KB 程度だが、SSL 処理には 12KB のヒープが必要で、そこに espconn_secure_set_size() で数 KB の SSL バッファ確保を指定すると完全に枯渇してしまう。そのため、AT コマンドで SSL を扱うことはできない、という話です。
ホストへの接続要求の前に system_print_meminfo() および system_get_free_heap_size() を呼び出してみると次の結果でした。
data : 0x3ffe8000 ~ 0x3ffe89d8, len: 2520 rodata: 0x3ffe89e0 ~ 0x3ffeabd4, len: 8692 bss : 0x3ffeabd8 ~ 0x3fff5010, len: 42040 heap : 0x3fff5010 ~ 0x3fffc000, len: 28656 system_get_free_heap_size=16592
なるほど。なお、AT コマンドセットは SDK においてはライブラリ形式で供給されており、自作コマンドを追加することはできても既存のものを変更することはできません。
さて？
冒頭に書いたように、ESP-WROOM-02 を通信モジュールとして扱う状況においてはシリアル経由でのコマンド渡しで簡単に通信処理を利用できることには便宜があります。
しかし、そこで SSL を利用できないことは大きなマイナスであり実用を想定すると使途が限定されることになるでしょう。そのため既存の AT コマンドセットに代わるインターフェイス込みでの SSL 処理の実装が必要であり、その方法はいろいろ考えられるもののどうも遠まわりな印象があります。
それはそれとして、一方では ESP-WROOM-02 は自立したマイコンとしての側面も持ち合わせているため、要件によっては単体で処理をまかなうことが可能であるわけで、とどのつまり製品出荷時の AT コマンドセットは「おまけ」程度のものと割り切るべきなのかも？
そんなことを考えながら、SSL 処理そのものが正常に動作することを確認するために前掲のプログラムを AT コマンドセットと切り離し単体で起動する形に変更して動作を試してみました。
ホストへの接続要求前のヒープ状況は以下の通りで、HTTPS リクエストは問題なく処理されました。やはりメモリ不足の問題のようです。
data : 0x3ffe8000 ~ 0x3ffe8560, len: 1376 rodata: 0x3ffe8560 ~ 0x3ffe9764, len: 4612 bss : 0x3ffe9768 ~ 0x3fff2b30, len: 37832 heap : 0x3fff2b30 ~ 0x3fffc000, len: 38096 system_get_free_heap_size=34856
サーバ証明書の検証について
立ち止まっていても仕方がないので、いずれにしても必要となる SSL サーバ証明書の検証に手をつけてみることにしました。
SDK に同梱の「ESP8266 SSL User Manual」には HTTPS クライアント処理においてサーバ証明書を検証する方法が次のように記述されています。
（クリックで実寸表示）
上記ドキュメントからの抜粋
CA verify function default to be disabled, user can enable it
by espconn_secure_ca_enable.
3.1. Generate CA Certificate
(1) Put script “make_cert.py”and CA certificate into
the same folder.
(2) Run script “make_cert.py” to generate esp_ca_cert.bin
which contains all CA certificates
(2 CA certificates at most) in the same folder.
Download address of esp_ca_cert.bin depends on
espconn_secure_ca_enable.
3.2. CA Verify
STEP 1: ESP8266 connects to server, read esp_ca_cert.bin
from flash, get the corresponding SSL
ctx. Only 2 CA certificates is allowed at most.
STEP 2: ESP8266 starts TLS handshake, get certificate from
SSL server, check with the CA in step 1：
• if CA check fail, connection break；
• if succeed, CA verify pass.
4.2. espconn_secure_ca_enable
Function:
Enable SSL CA (certificate authenticate) function
Note：
• CA function is disabled by default
• If user want to call this API, please call it before
espconn_secure_accept
(ESP8266 as TCP SSL server) or
espconn_secure_connect
(ESP8266 as TCP SSL client)
Prototype:
bool espconn_secure_ca_enable (uint8 level, uint16 flash_sector)
Parameter:
uint8 level : set configuration forESP8266
SSL server/client：
0x01 SSL client；
0x02 SSL server；
0x03 both SSL client and SSL server
uint16 flash_sector : flash sector in which CA
(esp_ca_cert.bin) is downloaded. For example,
flash_sector is 0x3B, then esp_ca_cert.bin need to
download into flash 0x3B000
Return:
true : succeed
false : fail
「make_cert.py」は SDK には含まれません。下記ページにダウンロードリンクが掲載されています。
- where can I get make_cert.py - bbs.espressif.com
以下の手順で「https://www.example.com/」のサーバ証明書の検証を試みました。
- DigiCert のルート証明書をブラウザから X509 形式（DER エンコード）でエクスポートし拡張子を .cer とする
- *.cer を置いたディレクトリで上記の make_cert.py を実行し「esp_ca_cert.bin」を生成する
- espconn_secure_connect() の前に下記行を記述しuser1.bin をフラッシュメモリサイズ 1024KB の指定でビルド
espconn_secure_ca_enable(0x01, 0x65)); // 0x01 = client - 他の *.bin ファイルと一緒に、esp_ca_cert.bin をフラッシュメモリの 0x65000 番地（User Data area）を起点に書き込む
※ビルドした user1.bin のサイズは 300KB ほどであり余裕をみて 400KB として
ブート領域の 4KB と合算すると 404KB につき 404 * 1024 = 413696 = 0x65000
- 下のメモリマップ（再掲）を参照のこと※1024KB フラッシュ使用時のメモリマップ - SDK の「Espressif IOT SDK User Manual」より Note • System param (system parameter area) is the last 16KB offlash. • User param is the user parameter area used by Espressif demo code ( IOT_Demo or AT ). If users develop their own application, user data can be saved in any available flash area. • User Data area ( green area in pictures below ) means the flash area that may be available, if program area doesn’t reach the maximum size, remaining area can be used to save user data.
- 期待通りにサーバ証明書の検証が行われ www.example.com への HTTPS リクエストは正常に処理され、ルート CA が DigiCert ではないサイトへの HTTPS リクエストにおいてはハンドシェイクの時点でエラーとなることを確認
解決：SDK v1.3.0 なら AT コマンド拡張内で SSL 処理が動く！
そうこうしている内に、2015-08-08 に公開された esp_iot_sdk_v1.3.0_15_08_08 のリリースノートの次の記述が目に飛び込んできました。
Optimization:
1.Memory optimization to save 12KBytes.
:
前述のとおり、SDK v1.2.0 を使ってビルドした AT コマンド拡張版で SSL が機能しなかったのはメモリ不足が原因だったため、v1.3.0 で 12KB 余裕が出来たのであればあるいは動作可能ではないかと考えました。 実際に v1.3.0 でビルドした user1.bin で AT+GETTEST コマンドを試したところ HTTPS リクエストが正常に処理されることを確認、ホストへの接続要求前のヒープ状況は以下の通りでした。まずはめでたし、です。
data : 0x3ffe8000 ~ 0x3ffe83ac, len: 940 rodata: 0x3ffe83b0 ~ 0x3ffe9d40, len: 6544 bss : 0x3ffe9d40 ~ 0x3fff18b8, len: 31608 heap : 0x3fff18b8 ~ 0x3fffc000, len: 42824 system_get_free_heap_size=31376
動作の様子 （動画：2分19秒）
今回試作した GETTEST コマンドは所定のホストに対し "GET /" を行うのみの内容ですが、以上のように大枠での動作を確認できたため今後は任意の URI の指定や POST メソッドへの対応など実用上必要な肉付けを手元で行うことになるでしょう。楽しみです。
上の動画で使用している現時点のファーム一式のうち user1.bin 以外のバイナリを以下のアーカイブに収めています。 自分の環境の AP の SSID とパスワードをソースに記述して user1.bin をビルドし、図の要領でこれらのバイナリ一式を ESP-WROOM-02 のフラッシュメモリに書き込めば AT+GETTEST コマンドが動作するはずです。興味のある方は自己責任でお試し下さい。
![BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part B] page 227](http://livedoor.blogimg.jp/klab_gijutsu2/imgs/b/8/b8ada218.png){kind=link}
(tanabe)
「TWE-LITE」ファームウェアプログラミングの試み
TWE-LITE（旧表記「TWE-Lite」）のメーカーが変わり同社からのリクエストに基づいて関連箇所の改訂を行いました。結果として、2015年4月に公開した元の記事に2017年1月現在の新しい情報やキーワードが部分的に反映された内容となっています。念のため要所に注釈を加えており混乱につながる要素は特に含まれていないと判断していますが、記事参照の際にはご注意下さい。
モノワイヤレス株式会社様の ZigBee 無線マイコンモジュール「TWE-LITE DIP」はコストパフォーマンスが高く人気のある製品です。手軽にノード間の無線通信を実現できるため IoT を構成する要素としても所定の圏内に閉じた機器間ネットワークのための道具立てとしても有用でしょう。
標準のものに加え複数の典型的な用途に即したファームウェア群とそのソースコードが開発環境とともに無償で公開されていることも興味深く、製品はホスト PC から専用の USB アダプタ （TWE-LITE R） または市販の USB シリアル変換モジュール／ケーブル経由で自由にファームを書き換えられるようにデザインされています。
- TWE-APPS（アプリ各種） （各種ファームウェア）
- TWE-NET SDK （開発環境等）
- TWE-LITE 専用プログラマ （Windows 専用書き込みツール）
- jenprog フラッシュプログラマ
（Linux/ Mac OS X/ Windows 対応の書き込みツール）
このように単なる通信モジュールではなくプログラマブルなマイコンとしての側面を持ち合わせながら価格が低廉であることが TWE-LITE DIP の大きな魅力です。また、「超簡単！」の惹句の通り出荷時の標準ファームでは扱いやすさが特に重視されており、そういった間口の広さと奥の深さがこの製品の特長と言ってよいでしょう。
試みのきっかけ
TWE-LITE ユーザはメーカーの提示するソフトウェア使用許諾契約書に基づいて TWE-NET SDK を利用することができます。また、規約の認める範囲で公式ファームのソースコードを改変したりその内容を公開することも可能です。
- モノワイヤレスソフトウェア使用許諾契約書
- TWE-NET SDKマニュアル（2016-12.1） PDF
※上記 SDK マニュアルからの抜粋 クリックで大きく表示
ネットを参照すると現時点では実際に公式ファームに手を加えて TWE-LITE DIP を使っている利用者は製品の人気に比べまだあまり多くないように見受けられます（注：2015年04月時点の記述）。その背景には、まず公式のファームウェア群が充実しているため改変の不要なケースの多いことが想像されますが、それに加えて、精密に記述されている各ファームのボリュームのあるソースコードはその内容を適切に理解しなければ手を触れにくいという事情もあるように思われます。メーカーが公開しているこれらのファームは基本的に実用を目的とするものであって教育用ではありませんから、利用する側はコードの世界をじっくり楽しみながらノウハウを覚えるスタンスに立つことが好ましいでしょう。
ただ、ここしばらく TWE-LITE に触れた印象では、そこに「ちょっとした足がかり」があれば公式ファームのコードをより見渡しやすくなり、そのことがこの優れた製品を手元で活用する機会を拡げることにもつながるように感じました。思い浮かべたのは "Hello, world!" のようにもっとも単純で簡潔な内容からはじまり徐々に処理が肉付けされていくイメージの小さなサンプルファームコード群です。でも残念ながら今のところそういうものは見当たりません（注：2015年04月時点の記述）。そこで、実験と勉強をかねて現時点での自分の到達点なりにそういうコードを書いてみることにしました。一連の過程での疑問点・不明点の解決には言うまでもなく公式ファームのソースと上記の SDK マニュアルが非常に参考になりました。この試みは今後も継続するかもしれませんが、まずはここまでのソースコードと動作の様子を公開します。興味のある方は覗いてみて下さい。
※本記事に掲載のソースコードには公式ファームウェアのソースからの 引用が含まれます。取り扱いに際しては著作権表記を確認の上、前掲の 「モノワイヤレスソフトウェア使用許諾契約書」の内容を遵守して下さい。 なお、本記事での各ソースコードの掲載ならびにメーカー公式サイト上の 個々のページへの直接のリンク・公式文書からの情報の抜粋については いずれも事前にモノワイヤレス様より承諾を得ています。 ※本記事の本文および本記事に掲載のソースコードには誤りが含まれて いる可能性があります。そのことがいかなる損害に繋がったとしても 筆者および KLab は一切の責任を負いません。あらかじめご了承下さい。
技術情報について
TWE-LITE 用プログラミングに必要な情報は多岐に渡り、メーカー公式サイトの情報や前掲の TWE-NET SDK マニュアル、また、NXP 社製 JN5164 用のペリフェラル （TWE-LITE の I/O ポートまわり） API のマニュアル等が主な情報源となります。後続のソースコードを参照する上で最小限必要なもっとも基本的な資料三点を以下に抜粋します。
※図はクリックで大きく表示されます
TWE-LITE DIP のピン配置
（メーカー公式サイトの「超簡単！TWE標準アプリ」ページより）
TWE-LITE ファームウェアコードの動作フロー
（前掲の SDK マニュアルより）
Test01： LED を点滅させる
まずはマイコン・電子工作の世界での「Hello, world!」にあたる LED の点滅、いわゆる「L チカ」を行います。ネットワーク通信は行いません。
動作の様子
装置の写真と構成図（クリックで大きく表示）
ソースコード GitHub
ユーザ定義のイベントハンドラ内で 1秒周期の E_EVENT_TICK_SECOND 通知に呼応し出力ポートの Lo, Hi をトグルする
Test02： スイッチ操作に LED の状態を連動させる
上の Test01 は全自動かつエンドレスですが、今度は人間の操作に反応させてみます。タクトスイッチの ON/OFF に LED の点灯/消灯 が連動します。ネットワーク通信は行いません。
動作の様子
装置の写真と構成図（クリックで大きく表示）
ソースコード GitHub
既定のイベントハンドラ cbToCoNet_vMain() 内でタクトスイッチの状態に応じて LED の状態を変化させる
Test03： シリアル経由でデバッグメッセージを出力
プログラミングにはデバッグのための手段が不可欠です。Test02 のコードに、シリアル接続経由で PC 上のターミナルアプリへトレース文を出力する処理を加えてみます。PC との接続には専用の USB アダプタ 「TWE-LITE R」を使用しています。 （市販の USB シリアル変換モジュール／ケーブルも利用できます） ネットワーク通信は行いません。
動作の様子
装置の写真と構成図（クリックで大きく表示）
ソースコード GitHub
起動時に UART とデバッグ出力用の初期化を行い vfPrintf() 関数を使ってシリアルへトレース文を出力
Test04： スイッチ押下でメッセージを送信 〜 受信側は LED で反応
無線送受信を行います。Test02 の装置と同じものをもうひとつ用意します。タクトスイッチが押下されるとメッセージをブロードキャストし、受信した側は LED を一定時間点灯させます。
動作の様子
装置の写真と構成図（クリックで大きく表示）
ソースコード GitHub
スイッチ押下時に ToCoNet_bMacTxReq() によりブロードキャストを実行。既定のイベントハンドラ cbToCoNet_vTxEvent() および cbToCoNet_vRxEvent() 内で送受信通知への対応を行う
Test05： 電力消費を抑制した送信専用コードと装置
上記 Test04 での送信処理を独立させ、消費電力を抑えることを目的にメーカー公式の「無線タグアプリ（App_Tag）」（注：2015年04月時点での名称は「Samp_Monitor」）の押しボタン・磁気スイッチ対応機能における子機処理（EndDevice_Input）での以下の要所を取り入れた内容です。
（典型的には平時が導通状態の磁気リードスイッチが磁界から離れ切断された状況）
（典型的には平時が非導通状態のタクトスイッチが押下された状況）
受信側は Test04 のものをそのまま使います。以下の動画・写真では送信側の装置は磁気リードスイッチを使っており立ち上がり検出を行っています。 ちなみにこの装置の待機（Sleep）状態の消費電流を測ったところ 3μA（0.003mA）でした。一般に CR2032 の放電容量はおよそ 225mAh であることから、下記のサイトを利用して単純計算すると待機継続可能期間は 225mAh / 0.003mA * 0.7 ＝ 52500時間 ＝ 2187.5日 ≒ 5.99年となります。実際の電池寿命は送信頻度によって大きく変わるでしょう。
動作の様子
装置の写真と構成図（クリックで大きく表示）
ソースコード GitHub
電源投入直後やリセット後はまずそのまま Sleep 状態へ移行。DI1 の状態が変化すると起床して送信を行いふたたび Sleep へ。DI1 の立ち上がり／立ち下がりのどちらで送信を行うかは M1 の Lo / Hi 状態で決定する