BLEビーコンを紐解く2 | ITフリーランスエンジニアの案件・求人はＰＥ－ＢＡＮＫ

「BLEビーコンを紐解く」の第2回目です。
 
今回は、iBeaconフレームが本題です。ですが、その前に、まだ触れていないAdvertiser’s Addressフィールド(以下 AdvA)とAdvertiser’s Dataフィールド(以下 AdvData)、およびその構成単位であるADストラクチャ(以下 AD Structure)について紹介します。
 

AdvA
デバイスを識別するためのアドレスとして、6 オクテット長が割り当てられています。PDU Header内にあるTxAddフィールド値が0の場合、機器固有のパブリックアドレスとなり、1の場合、不定値なランダムアドレスになります。
 
パブリックアドレスの場合は、LANでおなじみのMACアドレスに相当し、24オクテットのベンダ識別子(OUI) と24オクテットのベンダ定義値で構成されています。ですので、AdvA値を読み解くとビーコンの製造メーカが判別することもできます。
ちなみに、巷のiBeaconを観測すると、ランダムアドレスのものもある様です。
 
AdvData
AdvDataフィールドは、１つのフィールドに、複数のデータを詰め込むことができる様、長さ(Length)、データ種別(AD Type)、データ本体(AD Data)といった3つのパートで構成されるAD Structureによって、組み立てられています。
 
前回記事で触れた アドバタイジングチャネルPDU図に、AD Structureの構成の組み入れたものを図１に示します。
 

 
Lengthフィールドは、１オクテット長で、AD Typeフィールドとデータフィールドの長さの和を示します。AD typeフィールドの長さは、1オクテットですので、AD Dataフィールドの長さは、Length-1となります。
 
AD Structureに、長さ情報をもつフィールドを用意することで、任意の長さのデータを交換できる様になりますが、アドバタイジングチャネルにおけるPDU長は、39オクテットと決まっていて、PDU HeaderフィールドとAdvAフィールドで8オクテット占めているので、31オクテットを超えるデータを一度にやり取りすることはできません。
 
AD Typeは、AD Dataのデータ種別を表すもので、Bluetooth SIGにて決められています。代表的なものを表１にリストアップします。
 
なお、すべてのAD Type定義値は、Buletooth SIGのサイトで確認できます。
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile
 
 

やっと、iBeaonフレームにたどりつきました。
iBeacon、実は、２つのADストラクチャで構成されているのです。
 
1つは AD Type値が0x01である、フラグ情報をもつストラクチャ。もう一つは、AD Type値が0xffであり、任意のデータをもつことができるストラクチャです。
 

フラグ情報の定義は、Buletooth Core仕様書で決めれています。
該当部分のみを抽出したものを表2 に示します。
 
iBeaconの場合、Flag値が0x06を示すことが多い様です。
 

続く、2番目のストラクチャ。データ本体の最初の２オクテットにCompanyID を置くという定めはありますが、その他は自由に書式できます。iBeaconの場合、Appleがその仕様を策定し、公開 しています。
 
iBeaonの場合、CompanyID値は、0x004cとなります。
そして、CompanyID続くフィールドをBeaconType(2 Oct)・UUID（16 Oct）/Major(2 Oct)/Mino(Oct)/TxPower(1 Oct)と定めています。
 
UUID/Majro/Minorフィールドとも、ビーコンの識別子として利用できます。UUIDは、サービス内容によって一定になっている事が多いです。
なお、UUID値が０は許容されていません。
 
TxPowerフィールドは、オブザーバー側での距離算出のための基準値として、ビーコンから1m離れたれたところから実測した電波強度[dBm]を送出することになっています。
 

ⅰ．ランダムアドレスには３タイプあります。興味がある方は、BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B] (https://www.bluetooth.com/specifications/bluetooth-core-specification) の「1.3.2 Random Device Address」をご覧ください。
 
ⅱ．OUI: Organizationally Unique Identifierの略。IEEEで管理されていて、メジャーなOUIは こちら(http://standards-oui.ieee.org/oui/oui.txt)で確認することができます。
 
ⅲ．データチャネルにおけるPDU長は257octまで可能(Buletooth4.2の場合)
 
ⅳ．詳細は、Core Specification Supplement (CSS)( https://www.bluetooth.com/specifications/bluetooth-core-specification) のPartA 「1.3 Flags」をご覧ください。
 
ⅴ．AdvAフィールドにおけるOUIとは異なり、BluetoothSIGが策定している企業識別子（https://www.bluetooth.com/ja-jp/specifications/assigned-numbers/company-identifiers）を使います。
 
ⅵ．https://developer.apple.com/ibeacon/より入手可能です。以前は、入手に際し、契約が必要でしたが、2017.10月現在不要です。英語表記ですが、僅か10ページ程度ですので一度目を通してみるのもいいかもです。
 

 
またまた、間が空いてしまいましたが、IoT研究会５月会のレポートをお届けまします。今回のテーマは、SPI。担当は、齋藤さんです。

 
今回はSPI（Serial Peripheral Interface）のワークショップが開催されました。
 

＜SPI座学＞
・マスタ→スレーブ、スレーブ→マスタで別々の専用線を持つ
・スレーブデバイスが複数接続されている場合は、SSラインのアサーションで選択する。一対一通信の場合は、スレーブデバイスのSS端子をアサート側に固定することで、SSラインは省略できる。
・4つの動作モードがある。SCLKの極性（正･負極性）と位相（サンプリングの際のタイミング。クロックの立ち上がり or 立ち下がり）の組合せによる４通り
・送信データサイズは任意に設定できる（H/Wが対応していれば可）
・LSB/MSB Firstどちらも対応可
 
【用語】
SCLK: Serial Clock （マスター・スレーブ間同期信号）
MISO: Master In Slave Out　（スレーブからマスタへの信号）
MOSI: Master Out Slave In　（マスタからスレーブへの信号）
SS: Slave Select　（マスタがスレーブを選択するための信号）
 

通信手順としては、まずデータを準備し、SSでスレーブを指定して、SCLKをトリガにデータのシフトとラッチをします。
 
【I2Cとの違い】
質疑応答では、すでに学習したI2Cとの違いについて活発に議論が交わされました。
大きな違いは、送信データサイズがI2C は8bit長であるが、SPIはH/Wが対応していれば自由に設定可能なこと。I2CはMSB Firstだが、SPIはLSB/MSB Firstのどちらも選択できること。SPIは送受信が同時のため、たとえば送信のみでも受信側にダミーデータが必要なことです。
 

＜SPI実習＞
実習では9軸センサの加速度の値をSPIで読み取るサンプルを実行しました。
 
SPIマスタと回路を設定します。
 

【加速度の取得】
今回利用した9軸センサで加速度を取得するためには、Writeの場合はアドレス(0x3b)のMSB(最上位bit)に1を立て(0x80)、読み込み長さ分のダミーデータを用意する必要があります。加速度データは2番目から入ってきます。
 

これでSPIを利用して加速度が取得できました。
 

＜最後に＞
今回のIoT研究会のレポートは斉藤が担当しました。
 
私はフリーランスとなって2年ほどですが、一貫してiOS開発に携わって来ました。
現在は社内SDK(iOS)の保守・開発を行っています。
 
IoTに関しては、組み込みの経験もなく初めてでしたが、IoT研究会の先輩方のフォローを受けて、なんとかついていけています。研究会では活発に情報交換がされています。下図のような拡張ボード紹介もあり、初心者の自分にとっては助かっています。
 

次回から、いよいよBLEに入って行きます。BLEが使えると開発の幅が広がり、アイデアを形に出来るようになるため楽しみです。