SlideShare une entreprise Scribd logo
1  sur  12
Télécharger pour lire hors ligne
Nordic nRF51822 で BLE してみました 2
● 前回は、サンプルを動たところまで。
●
今回は Bluetooth の仕様書も見ながらやっていこう。
●
現在 (2015/05/31) の最新は、コアバージョン 4.2
● https://www.bluetooth.org/ja-jp/specification/adopted-specifications
●
残念ながら、英語版のみです。
プロファイルとサービス
● Bluetooth で「プロファイル」という言葉をよく
使うが、これはデータの構造ややりとりの仕方を
決めたもの。
●
「サービス」もだいたいそんなもの。
●
私の中では、「サービス」を組み合わせたりしたのが
「プロファイル」になってる。
●
例えば「 Alert Notification Profile 」 (ANP) というプロ
ファイルがあるのだが、それは「 Alert Notification
Service 」 (ANS) を使っている。
● Bluetooth SIG ではみんな使いそうなプロファイ
ルやサービスを定義しているが、自分で機器を作
るならサービスを自作することも多々ある。
役割 (GATT)
● サービスは、だいたい「機能を提供する方」と「受ける方」に役
割が分かれる。
●
「 role 」という言葉が仕様書によく出てくる。
●
こちらは、 Alert Notification Profile の Role
●
ここは GATT レベルでの役割
●
「 Client 」と「 Server 」と呼んでいるようだ
役割 (GAP)
●
GAP というものがある
●
ここでの Role は、 BLE として果たす役目みたいなイメージ
●
Broadcaster
●
SoftDevice のS110/S130
●
いわゆる「ビーコン専用端末」がこれになる。 Advertising するだけ。
●
Observer
●
SoftDevice のS120/S130
●
無線を受信するだけで、送信しない。
●
Peripheral
● SoftDevice のS110/S130
●
Broadcaster の機能に、接続する機能がある。 Profile やService を持つなら、これ。
●
Central
●
SoftDevice のS120/S130
●
Peripheral の接続先がCentral になる。
役割 (L2CAP)
● BLE の接続管理というところか
●
接続してしまえば、 GATT とかの話になる
●
接続前は、 GAP とか L2CAP とかの話になる
●
ここでの Role は 2 つ
● Slave
● GAP の "Broadcaster" や "Peripheral" にあたる
● 無線を聞く方
● Master
● GAP の "Central" にあたる
●
無線を出し始める方
接続前の状態
●
接続するまでは、 GAP や L2CAP が主役
●
これは、 L2CAP の状態遷移図
●
Master と Slave で経路が違う
接続まで - Master
● Master が接続するまでは、こういう経路になる
● Scanning で Peripheral を探す
●
見つかったら Initiating で
接続するかどうか試す
● OK なら接続する
接続まで - Slave
● Slave が接続するまでは、こういう経路になる
● Advertising して、 Master に
見つけてもらう
● Master から接続要求が来て、
OK なら接続する
Advertising PDU(Packet Data Unit)
●
Advertising は 4 タイプある
● Core_V4.2 - Vol.6 - Part B – 2.3.1 Advertising PDUs
● ADV_IND : 「接続可能」「相手不特定」「 SCAN_REQ 可能」
●
接続する場合はこれを使う
● ADV_DIRECT_IND : 「接続可能」「相手特定」「 SCAN_REQ 不可」
●
どこかで推奨しないという記述を見た気がするのだが、見つけられなかった。。
● ADV_NONCONN_IND : 「接続不可」「相手不特定」「 SCAN_REQ 不可」
●
ビーコン端末などは、これだろう。
● ADV_SCAN_IND : 「接続不可」「相手不特定」「 SCAN_REQ 可能」
●
SCAN_REQ コマンドを受信すると、 SCAN_RSP 応答で情報を返す。
●
使い道がわからない・・・。
●
データ部として 31byte まで使える。
● ADV_DIRECT_IND は違うが、普通使わなさそうなので省略
Advertising のデータ
● 左がヘッダ、右がデータ部の構造
● PDU Type : 前ページの xxx_IND
● TxAdd : AdvA のアドレス種別
● 0...public address / 1...random address
● RxAdd : 未使用?
●
実際に送信されているデータ例 (TI SensorTag)
AdvData
●
AdvData は、 [Length][AD Type][Data] 、という構造
●
AD Type はネットにしかなさそうだ
● https://www.bluetooth.org/en-us/specification/assigned-numbers/generic-access-profile
●
上のデータは、 0x01 、つまり「 Flags 」というデータタイプ
●
参照先: Core Specification Supplement, Part A, section 1.3
●
iBeacon は 0xFF(Manufacturer Specific) にして、あとは好きに使っている
●
データタイプの説明は「コア仕様補完 (CSS) 」にある
●
現在 (2015/05/31) の最新は、 v5
●
0x05 の意味
●
bit0 : LE Limited Discoverable Mode
●
bit 2 : BR/EDR Not Supported
S110 で Advertising
● ble_advdata_set() で AdvData を設定する
● ble_advdata_t 構造体
● sd_ble_gap_adv_start() を呼ぶと Advertising を開始する
● ble_gap_adv_params_t 構造体
●
Advertising PDU の種類 (xxx_IND)
●
送信間隔
●
タイムアウト時間
● Advertising だけしたいなら、 ble_app_beacon サンプルがよい

Contenu connexe

Tendances

Tendances (20)

AndroidとPCのみでスマート電球BLEハッキング
AndroidとPCのみでスマート電球BLEハッキングAndroidとPCのみでスマート電球BLEハッキング
AndroidとPCのみでスマート電球BLEハッキング
 
月刊NDEF 2013年8月号
月刊NDEF 2013年8月号月刊NDEF 2013年8月号
月刊NDEF 2013年8月号
 
大規模DCのネットワークデザイン
大規模DCのネットワークデザイン大規模DCのネットワークデザイン
大規模DCのネットワークデザイン
 
BGP Unnumbered で遊んでみた
BGP Unnumbered で遊んでみたBGP Unnumbered で遊んでみた
BGP Unnumbered で遊んでみた
 
月刊NDEF 2013年2月号(臨時号)
月刊NDEF 2013年2月号(臨時号)月刊NDEF 2013年2月号(臨時号)
月刊NDEF 2013年2月号(臨時号)
 
Multi Chassis LAG for Cloud builders
Multi Chassis LAG for Cloud buildersMulti Chassis LAG for Cloud builders
Multi Chassis LAG for Cloud builders
 
ネットワーク機器のAPIあれこれ入門 (NetOpsCoding#2)
ネットワーク機器のAPIあれこれ入門(NetOpsCoding#2)ネットワーク機器のAPIあれこれ入門(NetOpsCoding#2)
ネットワーク機器のAPIあれこれ入門 (NetOpsCoding#2)
 
[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?[Node-RED] ファンクションノードのデバッグどうしてる?
[Node-RED] ファンクションノードのデバッグどうしてる?
 
とある小型の青歯規格(ブルートゥース)
とある小型の青歯規格(ブルートゥース)とある小型の青歯規格(ブルートゥース)
とある小型の青歯規格(ブルートゥース)
 
ConfD で Linux にNetconfを喋らせてみた
ConfD で Linux にNetconfを喋らせてみたConfD で Linux にNetconfを喋らせてみた
ConfD で Linux にNetconfを喋らせてみた
 
IIJmio meeting #2 IIJmioとIPv6の話
IIJmio meeting #2 IIJmioとIPv6の話IIJmio meeting #2 IIJmioとIPv6の話
IIJmio meeting #2 IIJmioとIPv6の話
 
IRR Toolset, RPSL
IRR Toolset, RPSL IRR Toolset, RPSL
IRR Toolset, RPSL
 
libpgenでパケット操作
libpgenでパケット操作libpgenでパケット操作
libpgenでパケット操作
 
VPP事始め
VPP事始めVPP事始め
VPP事始め
 
NETCONFとYANGの話
NETCONFとYANGの話NETCONFとYANGの話
NETCONFとYANGの話
 
SDCCオープンネットワークのご紹介【2021/01版】
SDCCオープンネットワークのご紹介【2021/01版】SDCCオープンネットワークのご紹介【2021/01版】
SDCCオープンネットワークのご紹介【2021/01版】
 
3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめ3GPP TS 38.300-100まとめ
3GPP TS 38.300-100まとめ
 
IIJmio meeting #1 MVNOのネットワークインフラについて
IIJmio meeting #1 MVNOのネットワークインフラについてIIJmio meeting #1 MVNOのネットワークインフラについて
IIJmio meeting #1 MVNOのネットワークインフラについて
 
10GbE時代のネットワークI/O高速化
10GbE時代のネットワークI/O高速化10GbE時代のネットワークI/O高速化
10GbE時代のネットワークI/O高速化
 
Pythonではじめるソフトウェア無線
Pythonではじめるソフトウェア無線Pythonではじめるソフトウェア無線
Pythonではじめるソフトウェア無線
 

Plus de Hirokuma Ueno

MIFARE ClassicのAccess Conditions
MIFARE ClassicのAccess ConditionsMIFARE ClassicのAccess Conditions
MIFARE ClassicのAccess Conditions
Hirokuma Ueno
 
FeliCa Liteの片側認証
FeliCa Liteの片側認証FeliCa Liteの片側認証
FeliCa Liteの片側認証
Hirokuma Ueno
 
SNEPは大変だった
SNEPは大変だったSNEPは大変だった
SNEPは大変だった
Hirokuma Ueno
 
一人でもSNEP開発
一人でもSNEP開発一人でもSNEP開発
一人でもSNEP開発
Hirokuma Ueno
 
NFCIP-1を斜め読み
NFCIP-1を斜め読みNFCIP-1を斜め読み
NFCIP-1を斜め読み
Hirokuma Ueno
 
SDK for NFC Starter Kit(2) 使ってみる
SDK for NFC Starter Kit(2) 使ってみるSDK for NFC Starter Kit(2) 使ってみる
SDK for NFC Starter Kit(2) 使ってみる
Hirokuma Ueno
 
財布を忘れると困る
財布を忘れると困る財布を忘れると困る
財布を忘れると困る
Hirokuma Ueno
 

Plus de Hirokuma Ueno (20)

About FeliCa Lite-S
About FeliCa Lite-SAbout FeliCa Lite-S
About FeliCa Lite-S
 
月刊NDEF 2013年12月号
月刊NDEF 2013年12月号月刊NDEF 2013年12月号
月刊NDEF 2013年12月号
 
月刊NDEF 5月号
月刊NDEF 5月号月刊NDEF 5月号
月刊NDEF 5月号
 
月刊NDEF 2013年 1、2、3月号
月刊NDEF 2013年 1、2、3月号月刊NDEF 2013年 1、2、3月号
月刊NDEF 2013年 1、2、3月号
 
旅行カバンとNFC
旅行カバンとNFC旅行カバンとNFC
旅行カバンとNFC
 
NDEF WriterとOSとPaSoRi
NDEF WriterとOSとPaSoRiNDEF WriterとOSとPaSoRi
NDEF WriterとOSとPaSoRi
 
NDEF Writerを使ってみよう
NDEF Writerを使ってみようNDEF Writerを使ってみよう
NDEF Writerを使ってみよう
 
月刊NDEF 2013年3月号(卒業号)
月刊NDEF 2013年3月号(卒業号)月刊NDEF 2013年3月号(卒業号)
月刊NDEF 2013年3月号(卒業号)
 
月刊NDEF 2013年1月号
月刊NDEF 2013年1月号月刊NDEF 2013年1月号
月刊NDEF 2013年1月号
 
MIFARE ClassicのAccess Conditions
MIFARE ClassicのAccess ConditionsMIFARE ClassicのAccess Conditions
MIFARE ClassicのAccess Conditions
 
FeliCa Liteの片側認証
FeliCa Liteの片側認証FeliCa Liteの片側認証
FeliCa Liteの片側認証
 
SNEPは大変だった
SNEPは大変だったSNEPは大変だった
SNEPは大変だった
 
NFC切手
NFC切手NFC切手
NFC切手
 
NFCの汎化
NFCの汎化NFCの汎化
NFCの汎化
 
一人でもSNEP開発
一人でもSNEP開発一人でもSNEP開発
一人でもSNEP開発
 
NFCIP-1を斜め読み
NFCIP-1を斜め読みNFCIP-1を斜め読み
NFCIP-1を斜め読み
 
らくがき
らくがきらくがき
らくがき
 
NFCテルミン
NFCテルミンNFCテルミン
NFCテルミン
 
SDK for NFC Starter Kit(2) 使ってみる
SDK for NFC Starter Kit(2) 使ってみるSDK for NFC Starter Kit(2) 使ってみる
SDK for NFC Starter Kit(2) 使ってみる
 
財布を忘れると困る
財布を忘れると困る財布を忘れると困る
財布を忘れると困る
 

Nordic nRF51822でBLEしてみました 2

  • 1. Nordic nRF51822 で BLE してみました 2 ● 前回は、サンプルを動たところまで。 ● 今回は Bluetooth の仕様書も見ながらやっていこう。 ● 現在 (2015/05/31) の最新は、コアバージョン 4.2 ● https://www.bluetooth.org/ja-jp/specification/adopted-specifications ● 残念ながら、英語版のみです。
  • 2. プロファイルとサービス ● Bluetooth で「プロファイル」という言葉をよく 使うが、これはデータの構造ややりとりの仕方を 決めたもの。 ● 「サービス」もだいたいそんなもの。 ● 私の中では、「サービス」を組み合わせたりしたのが 「プロファイル」になってる。 ● 例えば「 Alert Notification Profile 」 (ANP) というプロ ファイルがあるのだが、それは「 Alert Notification Service 」 (ANS) を使っている。 ● Bluetooth SIG ではみんな使いそうなプロファイ ルやサービスを定義しているが、自分で機器を作 るならサービスを自作することも多々ある。
  • 3. 役割 (GATT) ● サービスは、だいたい「機能を提供する方」と「受ける方」に役 割が分かれる。 ● 「 role 」という言葉が仕様書によく出てくる。 ● こちらは、 Alert Notification Profile の Role ● ここは GATT レベルでの役割 ● 「 Client 」と「 Server 」と呼んでいるようだ
  • 4. 役割 (GAP) ● GAP というものがある ● ここでの Role は、 BLE として果たす役目みたいなイメージ ● Broadcaster ● SoftDevice のS110/S130 ● いわゆる「ビーコン専用端末」がこれになる。 Advertising するだけ。 ● Observer ● SoftDevice のS120/S130 ● 無線を受信するだけで、送信しない。 ● Peripheral ● SoftDevice のS110/S130 ● Broadcaster の機能に、接続する機能がある。 Profile やService を持つなら、これ。 ● Central ● SoftDevice のS120/S130 ● Peripheral の接続先がCentral になる。
  • 5. 役割 (L2CAP) ● BLE の接続管理というところか ● 接続してしまえば、 GATT とかの話になる ● 接続前は、 GAP とか L2CAP とかの話になる ● ここでの Role は 2 つ ● Slave ● GAP の "Broadcaster" や "Peripheral" にあたる ● 無線を聞く方 ● Master ● GAP の "Central" にあたる ● 無線を出し始める方
  • 6. 接続前の状態 ● 接続するまでは、 GAP や L2CAP が主役 ● これは、 L2CAP の状態遷移図 ● Master と Slave で経路が違う
  • 7. 接続まで - Master ● Master が接続するまでは、こういう経路になる ● Scanning で Peripheral を探す ● 見つかったら Initiating で 接続するかどうか試す ● OK なら接続する
  • 8. 接続まで - Slave ● Slave が接続するまでは、こういう経路になる ● Advertising して、 Master に 見つけてもらう ● Master から接続要求が来て、 OK なら接続する
  • 9. Advertising PDU(Packet Data Unit) ● Advertising は 4 タイプある ● Core_V4.2 - Vol.6 - Part B – 2.3.1 Advertising PDUs ● ADV_IND : 「接続可能」「相手不特定」「 SCAN_REQ 可能」 ● 接続する場合はこれを使う ● ADV_DIRECT_IND : 「接続可能」「相手特定」「 SCAN_REQ 不可」 ● どこかで推奨しないという記述を見た気がするのだが、見つけられなかった。。 ● ADV_NONCONN_IND : 「接続不可」「相手不特定」「 SCAN_REQ 不可」 ● ビーコン端末などは、これだろう。 ● ADV_SCAN_IND : 「接続不可」「相手不特定」「 SCAN_REQ 可能」 ● SCAN_REQ コマンドを受信すると、 SCAN_RSP 応答で情報を返す。 ● 使い道がわからない・・・。 ● データ部として 31byte まで使える。 ● ADV_DIRECT_IND は違うが、普通使わなさそうなので省略
  • 10. Advertising のデータ ● 左がヘッダ、右がデータ部の構造 ● PDU Type : 前ページの xxx_IND ● TxAdd : AdvA のアドレス種別 ● 0...public address / 1...random address ● RxAdd : 未使用? ● 実際に送信されているデータ例 (TI SensorTag)
  • 11. AdvData ● AdvData は、 [Length][AD Type][Data] 、という構造 ● AD Type はネットにしかなさそうだ ● https://www.bluetooth.org/en-us/specification/assigned-numbers/generic-access-profile ● 上のデータは、 0x01 、つまり「 Flags 」というデータタイプ ● 参照先: Core Specification Supplement, Part A, section 1.3 ● iBeacon は 0xFF(Manufacturer Specific) にして、あとは好きに使っている ● データタイプの説明は「コア仕様補完 (CSS) 」にある ● 現在 (2015/05/31) の最新は、 v5 ● 0x05 の意味 ● bit0 : LE Limited Discoverable Mode ● bit 2 : BR/EDR Not Supported
  • 12. S110 で Advertising ● ble_advdata_set() で AdvData を設定する ● ble_advdata_t 構造体 ● sd_ble_gap_adv_start() を呼ぶと Advertising を開始する ● ble_gap_adv_params_t 構造体 ● Advertising PDU の種類 (xxx_IND) ● 送信間隔 ● タイムアウト時間 ● Advertising だけしたいなら、 ble_app_beacon サンプルがよい