BLEビーコンを紐解く2 | ITフリーランスエンジニアの案件・求人はPE-BANK

  • このエントリーをはてなブックマークに追加

IoTモノ語り

BLEビーコンを紐解く2

「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フィールドは、1つのフィールドに、複数のデータを詰め込むことができる様、長さ(Length)、データ種別(AD Type)、データ本体(AD Data)といった3つのパートで構成されるAD Structureによって、組み立てられています。

前回記事で触れた アドバタイジングチャネルPDU図に、AD Structureの構成の組み入れたものを図1に示します。

20171120iida01

図1. AD Structure


Lengthフィールドは、1オクテット長で、AD Typeフィールドとデータフィールドの長さの和を示します。AD typeフィールドの長さは、1オクテットですので、AD Dataフィールドの長さは、Length-1となります。

AD Structureに、長さ情報をもつフィールドを用意することで、任意の長さのデータを交換できる様になりますが、アドバタイジングチャネルにおけるPDU長は、39オクテットと決まっていて、PDU HeaderフィールドとAdvAフィールドで8オクテット占めているので、31オクテットを超えるデータを一度にやり取りすることはできません。

AD Typeは、AD Dataのデータ種別を表すもので、Bluetooth SIGにて決められています。代表的なものを表1にリストアップします。

なお、すべてのAD Type定義値は、Buletooth SIGのサイトで確認できます。
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile

20171120iida02

表1 代表的なADタイプ

iBeaconフレーム

やっと、iBeaonフレームにたどりつきました。
iBeacon、実は、2つのADストラクチャで構成されているのです。

1つは AD Type値が0x01である、フラグ情報をもつストラクチャ。もう一つは、AD Type値が0xffであり、任意のデータをもつことができるストラクチャです。

20171120iida03

図2 iBeaconフォーマット

フラグ情報の定義は、Buletooth Core仕様書で決めれています。
該当部分のみを抽出したものを表2 に示します。

iBeaconの場合、Flag値が0x06を示すことが多い様です。


20171120iida04
表2 Flags定義

続く、2番目のストラクチャ。データ本体の最初の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値が0は許容されていません。

TxPowerフィールドは、オブザーバー側での距離算出のための基準値として、ビーコンから1m離れたれたところから実測した電波強度[dBm]を送出することになっています。

ⅰ.ランダムアドレスには3タイプあります。興味がある方は、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研究会レポート


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


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

<SPI座学>
・マスタ→スレーブ、スレーブ→マスタで別々の専用線を持つ
・スレーブデバイスが複数接続されている場合は、SSラインのアサーションで選択する。一対一通信の場合は、スレーブデバイスのSS端子をアサート側に固定することで、SSラインは省略できる。
・4つの動作モードがある。SCLKの極性(正・負極性)と位相(サンプリングの際のタイミング。クロックの立ち上がり or 立ち下がり)の組合せによる4通り
・送信データサイズは任意に設定できる(H/Wが対応していれば可)
・LSB/MSB Firstどちらも対応可

【用語】
SCLK: Serial Clock (マスター・スレーブ間同期信号)
MISO: Master In Slave Out (スレーブからマスタへの信号)
MOSI: Master Out Slave In (マスタからスレーブへの信号)
SS: Slave Select (マスタがスレーブを選択するための信号)

20171120iida05

図R-1 SPI接続図

通信手順としては、まずデータを準備し、SSでスレーブを指定して、SCLKをトリガにデータのシフトとラッチをします。

【I2Cとの違い】
質疑応答では、すでに学習したI2Cとの違いについて活発に議論が交わされました。
大きな違いは、送信データサイズがI2C は8bit長であるが、SPIはH/Wが対応していれば自由に設定可能なこと。I2CはMSB Firstだが、SPIはLSB/MSB Firstのどちらも選択できること。SPIは送受信が同時のため、たとえば送信のみでも受信側にダミーデータが必要なことです。

<SPI実習>
実習では9軸センサの加速度の値をSPIで読み取るサンプルを実行しました。

SPIマスタと回路を設定します。

20171120iida06

図R-2 SPI マスタ設定

20171120iida07

図R-3 SPI回路図

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

20171120iida08

図R-4 加速度の取得

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

<最後に>
今回のIoT研究会のレポートは斉藤が担当しました。

私はフリーランスとなって2年ほどですが、一貫してiOS開発に携わって来ました。
現在は社内SDK(iOS)の保守・開発を行っています。

IoTに関しては、組み込みの経験もなく初めてでしたが、IoT研究会の先輩方のフォローを受けて、なんとかついていけています。研究会では活発に情報交換がされています。下図のような拡張ボード紹介もあり、初心者の自分にとっては助かっています。

20171120iida09

図R-5 PSoCと拡張ボード

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

飯田 幸孝

飯田 幸孝

ソフトウエアエンジニア。名古屋出身。
計測機器開発メーカ、JAVA VMプロバイダの2社を経て2007年独立。
組込機器用F/W開発に多く従事。2015年より新人技術者育成にも講師として関わる。
モノづくりが好きと宇宙から地球を眺めてみたいという思いが高じて、2009年より宇宙エレベータ開発に手弁当にて加わる。その実現に今後の人生を掛ける。
宇宙エレベータ開発のご縁で静岡大学の衛星プロジェクトStars-Cに参画。2016年秋、担当ユニットが、自身の分身として、一足先に宇宙に行き地球を眺める。

TOP