IoTモノ語り
BLEビーコンを紐解く
まずは森をみる
BLE通信形態(トポロジー)には、ブロードキャスター型とコネクション型の2つの形態があることを本コラム>Vol.5にて紹介させていただきました。今回は、ブロードキャスター型通信の代表例であるBLEビーコンを紐解いて見たいと思います。
なお、最新の仕様は、Bluetooth 5ですが、ここでは Bluetooth4.2をベースとします。
ブロードキャスター型通信(以下ブロードキャスト通信)は、前回Vol6のコラムで紹介しました37-39chに割り当てられているアドバタイジングチャネルのみを利用して行われる通信です。
アドバタイジングチャネルに、BLE通信パケット のひとつであるアドバタイズメントパケット(Packet Data UnitフィールドにアドバタイジングPDUをもつBLE通信パケット)を送信することでブロードキャスト通信を実現しています。
アドバタイジングパケットには、データ領域(最大31オクテット )があり、この領域を送信する側と受信する側で、特定の仕様にあわせた形で利用すれば、情報伝達を行うことができます。この特定の仕様が、公開されていて誰でも利用することができるのであれば、多くの人に利用されるサービスへと展開できます。それがBLEビーコンサービスです。
BLEビーコンサービスの主なものとして、Apple主導のiBeaconと Google主体のEddystoneがあります。
以上が、全体像ですが、文章のみだと、ちょっとややこしいですね。これまでの内容を図式化したのが図1となります。ただし、ビーコンフォーマットは、iBeaconのみに留めています。
BLE通信パケット基本構造
BLE通信パケットは、4つのフィールドから構成されています。
・プリアンブル(Preamble) 1[Oct長]
‘0’と‘1’を繰り返す、“10101010” か “01010101”のいずれかとなります。
・アクセスアドレス(Access Address) 4[Oct長]
アドバタイジングチャネルで利用する場合は、“8E89BED6”(16進表記)固定となります。データチャネルで利用する場合は、ランダムな値となります。
・プロトコルデータユニット(Protorol Data Unit/PDU) 2 – 39[Oct長]
通信パケットが運ぶデータを指定するフィールドです(以下 PDUフィールド)。アドバタイジングチャネルとデータチャネルでフォーマットが異なります。アドバタイジングチャネルの場合について、次節で述べます。2-39オクテットの可変長です。
・巡回検査符号(CRC) 3[Oct長]
受信誤りを検出するためのCRC(巡回検査符号)値を指定するフィールドです。
CRCの計算対象は、PDUのみとなります。
PDUが可変長(2-39Oct)であることから、BLE通信のパケット長は、10-47オクテットとなります。
アドバタイジング チャネル プロトコルデータユニット(Adevertising Channel PDU)
ビーコンを紐解くがテーマですので、アドバタイジングチャネルに送付されるパケットのPDUフィールドに限定します。
アドバタイジング チャネル PDUのフォーマット および ヘッダフィールドの構成は図2の様になります。
2オクテット長のヘッダフィールドと最大37オクテット長までのペイロードフィールドで構成されています。ペイロードフィールドのフォーマットは、ヘッダフィールドに含まれるPDU Type値によって異なります。
表1は、PDU Type値の定義ですが、ブロードキャスト通信の場合、ADV_NONCONN_ID(0010)か、ADV_SCAN_IND(011)が選択されます。
そして、PDU Type値が ADV_NONCONN_IDかADV_SCAN_INDの場合、アドバタイジング チャネルPDUのフォーマットが図3の様になるわけです。図1とつながりましたね。
ビーコンフレーム
続いて、ビーコンフレームの話し。
と進めたいところですが、紙面の関係で、今回はここまでとします。次回、ビーコンの仔細に触れます。しばらくお待ちください。
IoT研究会レポート
少々間があいてしまいましたが、IoT研究会4月会リポートをお届けまします。
第4回目のリポーターは滝野義幸さんです。
今回は前回から引き続き”9軸センサ I2C通信実習”のワークショップが開催された。
<実習構成>
実習での大まかな構成は以下
![iida_20170919_06](https://pe-bank.jp/wp-content/uploads/2017/09/iida_20170919_01-5-1024x654.jpg)
登場人物紹介
以前より使用しているが初心者である筆者が実習内容を整理するために記載
1)PSoc4
・Cypress Semiconductor Corporation.製のICチップ
・PSoc Creatorというツールでプログラミンング可能
・UARTや9軸センサなどを乗せる土台
2)UART
・UARTとは 非同期のシリアル/パラレル信号の変換を行うデバイス。
・今回は USBでPCと接続し、センサからの読み取り情報をTeratermに出力。
3)9軸センサ
・今回の主役
・3軸加速度、3軸ジャイロ、3軸コンパスを検知するセンサ
<9軸センサ I2C通信実習>
実習の内容
9軸センサの検出値を読み取り、検出値はPCに表示
[ 各センサ値の取得 ]
I2Cで、PSoC(マスタ)が9軸センサー(スレーブ)のレジスタの値を読み取るには、前回実習で行った“WHO AM I” 内部レジスタと同様に読み取りたいレジスタのアドレスをWriteでスレーブに書込みした上で、マスタからReadをすることで、スレーブのレジスタの値を取得する
① I2Cアドレス(0x68)に、取得するレジスタアドレスを1byte送信
( 読取りレジスタの指定 )
レジスタアドレスは下記レジスタマップ参照
② 完了ステータス待ち
③ I2Cアドレス(0x68)から、1byte以上受信
( ①で指定したレジスタからの読取り )
④ 完了ステータス待ち
レジスタマップ
(ア) 加速度のX、Y、Zの3軸は連続したレジスタの配置となっているため、読み取りバイトを6とすると、まとめて受信することが可能
(イ) 加速度X軸のようにセンサ値は2bytesで現す為、上位1byteを左シフトさせ、下位1バイトとOR結合する
プログラム例
[ 各センサ検出値の表示 ]
9軸センサの検出値は、UARTにてPCに送り、Teratermや
研究会メンバーから提供されたグラフ描画で表示
<最後に>
今回のIoT研究会のレポートは滝野が担当しました。
日本経済がバブルで衰退していたころ、社会への扉を開き、数年間ソフトハウスでサラリーマンを務め、以後20年以上フリーランスとして今に至ります。
最も有名で契約者数を誇るインターネット生命保険会社の一つである会社のWebアプリケーション開発に5年ほど従事し、この春より心機一転、在宅で各企業のシステム開発を請け負っています。
私のフリーランスとしての強みは、当たり障りのない笑顔。
またシステム開発には集中力を持続させる体力が必要であると考えておりサッカー、フットサル、バスケ、マラソン、登山を趣味としています。
Iot研究会では これまで全く経験の無かったセンサ制御や、今後市場が拡大すると予想されるIotの世界に触れ、正直かなり戸惑っています。
しばらく戸惑いは続きそうですが、この先の未来に何があるか楽しみでもあります。
i パケット/packet。情報の伝送単位。本来の意味は、小包。
ii 今でこそ、1バイトは8ビットですが、1バイトが8ビットと限らない時代もありました。8ビットであることを明確にする場合は、オクテットという表記を使います。通信関係では、よく使われます。
![飯田 幸孝](https://pe-bank.jp/wp-content/uploads/2016/11/columnist_iida.png)
飯田 幸孝
ソフトウエアエンジニア。名古屋出身。
計測機器開発メーカ、JAVA VMプロバイダの2社を経て2007年独立。
組込機器用F/W開発に多く従事。2015年より新人技術者育成にも講師として関わる。
モノづくりが好きと宇宙から地球を眺めてみたいという思いが高じて、2009年より宇宙エレベータ開発に手弁当にて加わる。その実現に今後の人生を掛ける。
宇宙エレベータ開発のご縁で静岡大学の衛星プロジェクトStars-Cに参画。2016年秋、担当ユニットが、自身の分身として、一足先に宇宙に行き地球を眺める。