nRF51 @ Mac - overview

Fig 1. program tool(rknrfgo)

 
Fig 2. Sniffer tools(nrf-ble-sniffer-osx)

 
Fig 3. Wireshark ,need XQuartz

Fig 4.Spectum (iRF Explorer

Fig 6.IDE(Eclipse)nrf51osx
reference :

The J-Link hardware debugging Eclipse plug-in

http://gnuarmeclipse.livius.net/blog/jlink-debugging/
nRF51 tools
http://sourceforge.net/u/rolandking/profile/
iRF Explore
http://micro.arocholl.com/
wireshark
https://www.wireshark.org/download.html
XQuartz
http://xquartz.macosforge.org/landing/

Use BTLE Soc with other Vendor BTLE Compatibility issue

在之前介紹該vendor ble SoC 時, 曾提到感覺它的相容性問題.

那時,指的是它在連接時卡卡的(有時連不上)

而事實上,它的連接方式的確有相容性問題.

AMICCOM -BLE SOC A8105

http://stevenlin08book.blogspot.tw/2014/04/amiccom-ble-soc-a8105.html

 

keywork :

BLE SoC, Central mode and LL(link layer)

 

之前,有個案子原本是想要以這顆 加上 另外可支援Central Mode的SoC 應用.

但那時,實際動作後. 發現有問題(可連接.但不能找到A8105的服務)

因為我那時還沒有ble sniffer的設備,查看它通訊內容

雖然有發信給原廠人員詢問但沒得到回應.

在這次在作Central的前期開發時,隨便將該issue列入.並得到初步的結論.

 

1. normal v.s Abnormal

Fig 1. Normal , iphone and vendor soc

Fig 2.Abnormal, My Central and vendor Ble

 

在上面二MSC(message sequence char)中的不同,

1.告訴對方LL version

2.兩端交換MTU

3.Find By Type value Request

前二項,應不是必要的要求, 但在主要在第3點上的內容

可以看出一方,

find by type value request , device name , handle …..

而另一方則是以

find by type value request ,GATT primary service

 

這是因在Central Mode Ble Soc 定義中,定義了GATT primary service來提供資訊;

而在vendor ble soc, 則並不是由此來提供.

因此, 當Central Mode Ble soc 在連線後, 相vendor ble soc 提出 find the type value request 時,

因它不認得, 所以它也不會去反應. 導致整個系統沒有反應.

 

而另外,我也以第三家(TI CC2541)做為測試

Fig 3.the sendor vendor ble soc with iphone .

由這三家的系統中,可它們在第一個 read by (group) type request , 各有些不同

A. type, name

B.type. value ,primary service

C.group type,primary service

所以,在未來對於在整合不同家的系統時.可能需注意到這點.

BLE central throughput

因為下個案子(ble remoter and multi remoter)會用到central mode,所以我分析central mode timing and state

如下(對於peripheral 也可用相似方式,做分析它的BLE data throughput)

 

keyword :

BLE, central, throughput and behavior

 

Central & peripheral,every radio event trigger gpio .

default parameter:( by the central device)

#define SCAN_INTERVAL 0x00A0 /**< Determines scan interval in units of 0.625 millisecond. */
#define SCAN_WINDOW 0x0050 /**< Determines scan window in units of 0.625 millisecond. */

#define MIN_CONNECTION_INTERVAL MSEC_TO_UNITS(30, UNIT_1_25_MS) /**< Determines maximum connection interval in millisecond. */
#define MAX_CONNECTION_INTERVAL MSEC_TO_UNITS(60, UNIT_1_25_MS) /**< Determines maximum connection interval in millisecond. */
#define SLAVE_LATENCY 0 /**< Determines slave latency in counts of connection events. */
#define SUPERVISION_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Determines supervision time-out in units of 10 millisecond. */

Fig 1. default parameter radio event(0 – peripheral; 1 – Central,one pulse for notification; Square for Scan windows)

drop package(when peripheral pulse & Central Square )

Fig 2. One Second for Measure drop package(when peripheral pulse & Central Square )

Fig 3. Sniffer @ default parameter

Fig 4.Case 1,Measure the timing(60ms) between package .(reference the Fig 3)

Fig 5.Case 2,Measure the timing(0.11) between package .(reference the Fig 3)

Fig 4.Case 3,Measure the timing(0.12s) between package .(reference the Fig 3)

How to configure the parameters which operation without dropped packets .

1. The minimum Central connectionInterval should be ≥ 18.75 ms + scanWindow.
2. All Central connections should have a connectionInterval which can be factored by the smallest
connection interval. For example [50 ms, 100 ms, 150 ms, 200 ms…] or [75 ms, 150 ms, 225 ms] etc.
3. Scanner, Observer, and Initiator roles should haveintervals which can be factored by the smallest
connection interval (as with the Central role) and the window should be ≤ connectionInterval – 20
ms

According to list . re-configure the central parameters:

#define SCAN_INTERVAL 0x004C /**< Determines scan interval in units of 0.625 millisecond. */
//
#define SCAN_WINDOW 0x6 /**< Determines scan window in units of 0.625 millisecond. */
//10
#define MIN_CONNECTION_INTERVAL MSEC_TO_UNITS(10, UNIT_1_25_MS) /**< Determines maximum connection interval in millisecond. */
#define MAX_CONNECTION_INTERVAL MSEC_TO_UNITS(24, UNIT_1_25_MS) /**< Determines maximum connection interval in millisecond. */
#define SLAVE_LATENCY 0 /**< Determines slave latency in counts of connection events. */
#define SUPERVISION_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Determines supervision time-out in units of 10 millisecond. */

Fig 5. no drop package , connect interval ,24ms ; scan interval 48ms(factor connect interval) ; scan size (connect interval – 20ms)

Fig 6. multi peripheral(2)

Ref:

S120 SoftDevice Specification v1.1

Connections action and L2CAP 分析

因在實作BLE Central mode時的筆記, 對於Connection state動作及 L2CAP

並計畫以其它的的RF chip(GFSK) 對實作該動作.(connect interval 及 channel )

(即以master – L2CAP layer)

對於FHSS 無線通訊系統重要參數 如下:

1. connect interval

2. channel increame /number

我藉此來做為初步的分析.

 

Keyword:

Controll , LL(link layer), HCI(host controller interface),

connection parameter and L2CAP(logical layer and Adaptation protocol)

 

A.Init Conection State

剛開始連線時, 它所初始值及所交換的資訊內容. 如下

Fig 1. initial connect

一開始,所交換的資訊有Link layer的version,兩端可接收的MTU 及提供att handle的資訊(由master端發出詢間)

可以看得出來,一開始master 所初始化的connect interval 為30ms , 因此它以每隔30ms為一周期通訊.

 

B. Slave setting connect

接下來是去改變其connect interval的參數, 它是由Slave發起. 並由master 反應

(accept 並反應master所設定的connect interval ; reject ,若它不接收時,則會斷線)

Fig 2, slave send “Connect parameter update request”,這裡設定其min/max connect interval time.(0.5/1.0 s)

 

Fig 3. master 在接收其connect parameter update request後,回應給slave它是由接收及對於connect interval的設定

(需以master 為主).

這裡可以看出它並不是直接反應. 而是在某段時間(由slave設定)後才真正動作.

Fig 4.由slave 所設定的時間後動作.

 

C.

Channel setting

它是由master端去設定該連線的channel map及interval .

除了一開始連線時,設定外. master也會去偵測環境等去update channel map

Fig 5. init channel map

Fig 6. master偵測環境後,可能會去對slave 發出LL_CHANNEL_MPA_REQ

 

D. L2CAP 通訊

在BLE 中, 它的通訊方式可以由 一般經由ATT(GATT)(20 Bytes) 來交換資訊外;

事實上,也可以由L2CAP Layer 來進行. 尤其是大量的資料時(23 Bbytes)

Fig 7. BLE stack

Fig 8.

由Slave 經由L2CAP 來傳送資料.需注意的是它的通訊時間仍然是要依講好的時間去通訊

同等於ATT 的notification .

BLE Protocol Basic Overview

BLE Protocol Basic

The architecture of Bluetooth
Application
Host
    GAP(generic access profile)
    GATT(generic attribute profile)
    L2CAP(Logical Link Control and Adaptation Protocol)
    ATT(Attribute Protocol)
    SM(Security Manager)
    HCI(Host Controller Interface)
Controller
    HCI(host controller interface)
    LL(link layer)
    PHY(physical layer)


LL Layer :
CRC, encryption, data whitening
Roles:
    advertiser,Scanner, Master and Slave
Device Address:
48bits,MAC(Media Access Control Addres)
public device address, no change during the lifetime
random device address, when bonding it can use random device address to attach MITM

Advertising Packet,
Connectable(non-connectable)
Scannable(Non-scannable), scan request 
direct ability, direct(undirected)

Connections,
link layer allow “changing the connection parameter” and Encryption

HCI(host controller interface)
a standard protocol that allow for communication between a host and a controller to take place across a serial interface.

define HCI as a set of commands and events for host and control to interact with each other.

L2CAP(logical layer and Adaptation protocol) :
for as protocol multiplexer and encapsulate into standard BLE packet format(fragmentation and recombination same as TCP).

A. ATT - data exchange in BLE application
    simple client/server protocol , each server contain data organized in the form of attributes, each of which is assigned a 16bit attribute handle, a universally unique identifier(UUID) , a set of permission and a value.

    use attribute handle to identifier used to access an attribute value.
    use UUID to spacifier the type and the data.

Att operations:
    Error Handling, Server Configuration(Exchange MTU request/Respond) , Find Information(find information request/response,by handle range ; Find by Type Value ,by UUID and value),  Read /Write Operations , Queued Write and Server Initiate,asynchronously push attribute value to client

B.SM - Security Manager
     framework to generate and distribute security keys between peer.
    to trust the identity of the remote device to hide the public bluetooth address.

Security Manager support threes procedures:
    i .pairing , for temporary command security encryption key
    ii. bonding, generation and exchange of permanent security key
    iii. encryption re-establishment, how to use key in subsquent connection to re-establish a secure,encrypted connect .

Pairing  ShortTerm Key , STK generation method
    a, Just Work
    b.passkey key display
    c.OOB
security mechanisms level ( for during the connect and  advertising procedure)
    d. Encryption, all packet transmitted over an establish connection.
    e.privacy, allow an advertiser to hide its public bluetooth address
    f. signing,

security keys,
1. Encryption Information(Long Term Key,LTK) and Master Identification(EDIV,Rand)
    128 bit encryption key shared by both sides(LTK) along with two value(EDIV,Rand) acting as its identifier.
2.Identity information(Identity resolving key or IRK) and Identity address information(address type and bluetooth device address) which to implement privacy: to generate and resolve resolvable address.
3.Signing Information

each key is asymmetrical and thus each bond information stored between two device can contain up to two instance of each key.

GATT( generic attribute profile)
 build  on the attribute protocol(ATT ) and add a hierarchy and data abstraction. it defined how data is organized and exchange between application.metadata

GAP(generic Access profile)
dicate how device interact with each other at a lower level ,outside of the actuarial protocol stack.
GAP established difference set of rules and concepts to regulate and standardize the low lovel operation of devices.
1. role and interaction between them
2.operational modes and transitions across those
3.operation procedure to achieve consistent and interoperable communication
4.security aspects,including security modes and procedures
5.additional data formats for non protocol data