You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by ad...@apache.org on 2016/08/10 00:08:01 UTC
[3/6] incubator-mynewt-site git commit: bletiny update.
bletiny update.
Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/commit/01cda7b9
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/01cda7b9
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/01cda7b9
Branch: refs/heads/develop
Commit: 01cda7b9cbf8fb96dab8892cb8efb30935fcf468
Parents: 6dcda86
Author: Christopher Collins <cc...@apache.org>
Authored: Fri Aug 5 14:44:25 2016 -0700
Committer: Christopher Collins <cc...@apache.org>
Committed: Fri Aug 5 15:56:57 2016 -0700
----------------------------------------------------------------------
docs/network/ble/bletiny/bletiny_GAP.md | 127 +++++++++++++++++------
docs/network/ble/bletiny/bletiny_GATT.md | 54 +++++++---
docs/network/ble/bletiny/bletiny_advdata.md | 28 +++--
docs/network/ble/bletiny/bletiny_api.md | 92 ++++++----------
4 files changed, 185 insertions(+), 116 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/01cda7b9/docs/network/ble/bletiny/bletiny_GAP.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny/bletiny_GAP.md b/docs/network/ble/bletiny/bletiny_GAP.md
index f89664c..73d3aaf 100644
--- a/docs/network/ble/bletiny/bletiny_GAP.md
+++ b/docs/network/ble/bletiny/bletiny_GAP.md
@@ -5,47 +5,106 @@
Generic Access Profile (GAP) defines the generic procedures related to discovery of Bluetooth devices (idle mode procedures) and link management aspects of connecting to Bluetooth devices (connecting mode procedures). It also defines procedures related to use of different security levels.
-Several different modes and procedures may be performed simultaneously over an LE physical transport. The following modes and procedures are defined for use over an LE physical transport:1. **Broadcast mode and observation procedure**
- - These allow two devices to communicate in a unidirectional connectionless manner using the advertising events.2. **Discovery modes and procedures**
+Several different modes and procedures may be performed simultaneously over an LE physical transport. The following modes and procedures are defined for use over an LE physical transport:
+
+1. **Broadcast mode and observation procedure**
+ - These allow two devices to communicate in a unidirectional connectionless manner using the advertising events.
+2. **Discovery modes and procedures**
- All devices shall be in either non-discoverable mode or one of the discoverable modes.
- A device in the discoverable mode shall be in either the general discoverable mode or the limited discoverable mode.
- - A device in non-discoverable mode will not be discovered by any device that is performing either the general discovery procedure or the limited discovery procedure.3. **Connection modes and procedures**
+ - A device in non-discoverable mode will not be discovered by any device that is performing either the general discovery procedure or the limited discovery procedure.
+3. **Connection modes and procedures**
- allow a device to establish a connection to another device.
- allow updating of parameters of the connection
- - allow termination of the connection 4. **Bonding modes and procedures**
+ - allow termination of the connection
+4. **Bonding modes and procedures**
- Bonding allows two connected devices to exchange and store security and identity information to create a trusted relationship.
- - Bonding can occur only between two devices in bondable mode.<br>
-###Usage API
-|**Item No.** | **Modes and Procedures** | **nimBLE command** ||----|---------|---------------|
-| 1 | Broadcast Mode | `b adv conn=non disc=x` || | Observation Procedure | `b scan dur=x disc=x type=x filt=x` |
-| 2 | Non-Discoverable mode | `b adv conn=x disc=non` || | Limited Discoverable mode | `b adv conn=x disc=ltd` |
-| | General Discoverable mode | `b adv conn=x disc=gen` || | Limited Discovery procedure | `b scan dur=x disc=ltd type=active filt=no_wl` |
-| | General Discovery procedure | `b scan dur=x disc=gen type=active filt=no_wl` |
-| | Name Discovery procedure | UNSUPPORTED |
+ - Bonding can occur only between two devices in bondable mode.
+
+
+<br>
+
+
+###Usage API
+
+
+|**Item No.** | **Modes and Procedures** | **nimBLE command** |
+|----|---------|---------------|
+| 1 | Broadcast Mode | `b adv conn=non disc=x` |
+| | Observation Procedure | `b scan dur=x disc=x type=x filt=x` |
+| 2 | Non-Discoverable mode | `b adv conn=x disc=non` |
+| | Limited Discoverable mode | `b adv conn=x disc=ltd` |
+| | General Discoverable mode | `b adv conn=x disc=gen` |
+| | Limited Discovery procedure | `b scan dur=x disc=ltd type=active filt=no_wl` |
+| | General Discovery procedure | `b scan dur=x disc=gen type=active filt=no_wl` |
+| | Name Discovery procedure | `b scan dur=x` <br> `b scan cancel` <br> `b conn peer_addr_type=x peer_addr=x` <br> `b read uuid=0x2a00` |
| 3 | Non-connectable mode | `b adv conn=non disc=x` |
-| | Directed connectable mode | `b adv conn=dir disc=x addr_type=x addr=x` |
-| | Undirected connectable mode | `b adv conn=und disc=x` |
-| | Auto connection establishment procedure | `b wl addr_type=x addr=x` |
-| | Auto connection establishment procedure | `b conn addr_type=wl` |
-| | General connection establishment procedure | AVAILABLE SOON |
-| | Selective connection establishment procedure | AVAILABLE SOON |
-| | Direct connection establishment procedure | `b conn addr_type=x addr=x [params]` |
-| | Connection parameter update procedure | `b update conn=x <params>` |
-| | Terminate connection procedure | `b term conn=x` |
-| 4 | Non-Bondable mode | AVAILABLE SOON |
-| | Bondable mode | AVAILABLE SOON |
-| | Bonding procedure | AVAILABLE SOON |<br>
-### Connection Parameters
-
-The Connection parameter definitions can be found in Section 7.8.12 of the BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E].|**Name** | **Description** | **nimBLE parameter** ||----|---------|---------------|
-| Minimum connection interval | Defines minimum allowed connection interval| itvl_min |
-| Maximum connection interval | Defines maximum allowed connection interval | itvl_max |
+| | Directed connectable mode | `b adv conn=dir [own_addr_type=x] [disc=x] [dur=x]` |
+| | Undirected connectable mode | `b adv conn=und [own_addr_type=x] [disc=x] [dur=x]` |
+| | Auto connection establishment procedure | `b wl addr_type=x addr=x [addr_type=y addr=y] [...]` <br> `b conn addr_type=wl` |
+| | General connection establishment procedure | `b scan dur=x` <br> `b scan cancel` <br> `b conn peer_addr_type=x peer_addr=x` |
+| | Selective connection establishment procedure | `b wl addr_type=x addr=x [addr_type=y addr=y] [...]` <br> `b scan filt=use_wl dur=x` <br> `b scan cancel` <br> `b conn peer_addr_type=x peer_addr=x [own_addr_type=x]` |
+| | Direct connection establishment procedure | `b conn addr_type=x addr=x [params]` |
+| | Connection parameter update procedure | `b update conn=x <params>` |
+| | Terminate connection procedure | `b term conn=x` |
+| 4 | Non-Bondable mode | `b set sm_data bonding=0` [\*] |
+| | Bondable mode | `b set sm_data bonding=1` [\*] |
+| | Bonding procedure | `b sec start conn=x` [\*] |
+
+**[\*]** Security is disabled by default in bletiny. To use the bonding modes and procedures, add the `-DNIMBLE_OPT_SM=1` cflag to your target.
+
+<br>
+
+### Address Types
+
+| *bletiny string* | *Description* | *Notes* |
+|------------------|---------------|
+| public | Public address. | |
+| random | Random static address. | |
+| rpa_pub | Resolvable private address, public identity. | Not available for all commands. |
+| rpa_rnd | Resolvable private address, random static identity. | Not available for all commands. |
+| wl | Use white list; ignore peer_addr parameter. | Only availble for "conn" command. |
+
+### Connection Parameters
+
+The Connection parameter definitions can be found in Section 7.8.12 of the BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E].
+
+| *Name* | *Description* | *bletiny string* |
+|----|---------|---------------|
+| LE_Scan_Interval | Recommendation from the Host on how long the Controller should scan | scan_itvl |
+| LE_Scan_Window | Recommendation from the Host on how frequently the Controller should scan | scan_window |
+| Peer_Address_Type | Whether the peer is using a public or random address (see Address types table). | peer_addr_type |
+| Peer_Address | The 6-byte device address of the peer; ignored if white list is used | peer_addr |
+| Own_Address_Type | The type of address to use when initiating the connection (see Address types table) | own_addr_type |
+| Conn_Interval_Min | Defines minimum allowed connection interval | itvl_min |
+| Conn_Interval_Max | Defines maximum allowed connection interval | itvl_max |
| Conn_Latency | Defines the maximum allowed connection latency | latency |
| Supervision_Timeout | Link supervision timeout for the connection. | timeout |
-|LE_Scan_Interval | Recommendation from the Host on how long the Controller should scan | scan_itvl |
-|LE_Scan_Window |Recommendation from the Host on how frequently the Controller should scan | scan_window |
-|Minimum_CE_Length | Informative parameter providing the Controller with the expected minimum length of the connection event| min_ce_len |
-|Maximum_CE_Length |Informative parameter providing the Controller with the expected maximum length of the connection event | max_ce_len |
+| Minimum_CE_Length | Informative parameter providing the Controller with the expected minimum length of the connection event| min_ce_len |
+| Maximum_CE_Length | Informative parameter providing the Controller with the expected maximum length of the connection event | max_ce_len |
+| Duration | Number of milliseconds before aborting the connect attempt | dur |
+
+### Advertisement Filter Policies
+
+| *bletiny string* |
+| -----------------|
+| none |
+| scan |
+| conn |
+| both |
-### Advertisement data fields
+### Advertisment Parameters
+| *bletiny string* | *Description* | *Notes* | *Default* |
+|------------------|---------------|---------|-----------|
+| conn | Connectable mode | See Connectable Modes table. | und |
+| disc | Discoverable mode | See Discoverable Modes table. | gen |
+| own_addr_type | The type of address to advertise with | See Address Types table. | public |
+| peer_addr_type | The peer's address type | Only used for directed advertising; see Address Types table. | public |
+| peer_addr | The peer's address | Only used for directed advertising | N/A |
+| chan_map | | | 0 |
+| filt | The filter policy | See Advertisement Filter Policies table. | none |
+| itvl_min | | units=0.625ms | non: 100ms; und/dir: 30ms |
+| itvl_max | | units=0.625ms | non: 150ms; und/dir: 60ms |
+| hd | Whether to use high-duty-cycle | 0/1 | 0 |
+| dur | | Milliseconds | Forever |
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/01cda7b9/docs/network/ble/bletiny/bletiny_GATT.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny/bletiny_GATT.md b/docs/network/ble/bletiny/bletiny_GATT.md
index 8476b64..7469eb6 100644
--- a/docs/network/ble/bletiny/bletiny_GATT.md
+++ b/docs/network/ble/bletiny/bletiny_GATT.md
@@ -3,30 +3,52 @@
<br>
GATT(GENERIC ATTRIBUTE PROFILE) describes a service framework using the Attribute Protocol for discovering services, and for reading and writing characteristic values on a peer device. There are 11 features defined in the GATT Profile, and each of the features is mapped to procedures and sub-procedures:
-|**Item No.** | **Feature** | **Sub-Procedure** | **nimBLE command** ||----|---------|---------------|------|| 1 | Server Configuration | Exchange MTU | `b mtu` | | 2 | Primary Service Discovery | Discover All Primary Services | `b disc svc conn=x` |
+
+
+|**Item No.** | **Feature** | **Sub-Procedure** | **nimBLE command** |
+|----|---------|---------------|------|
+| 1 | Server Configuration | Exchange MTU | `b mtu` |
+| 2 | Primary Service Discovery | Discover All Primary Services | `b disc svc conn=x` |
| | | Discover Primary Services By Service UUID | `b disc svc conn=x uuid=x` |
-| 3 | Relationship Discovery | Find Included Services | `b find inc_svcs conn=x start=x end=x` || 4 | Characteristic Discovery | Discover All Characteristic of a Service | `b disc chr conn=x start=x end=x` |
-| | | Discover Characteristic by UUID | `b disc chr conn=x start=x end=x uuid=x` || 5 | Characteristic Descriptor Discovery | Discover All Characteristic Descriptors | `b disc dsc conn=x start=x end=x` || 6 | Reading a Characteristic Value | Read Characteristic Value | `b read conn=x attr=x` |
-| | | Read Using Characteristic UUID | `b read conn=x start=x end=x uuid=x` || | | Read Long Characteristic Values | `b read conn=x attr=x long=1` || | | Read Multiple Characteristic Values | `b read conn=x attr=x attr=y attr=z` |
-| 7 | Writing a Characteristic Value | Write Without Response | `b write conn=x value=0xXX:0xXX no_rsp=1` || | | Signed Write Without Response | NOT SUPPORTED || | | Write Characteristic Value | `b write conn=x attr=x value=0xXX:0xXX` || | | Write Long Characteristic Values | `b write conn=x attr=x value=0xXX:0xXX long=1` || | | Characteristic Value Reliable Writes | `b write conn=x attr=x value=0xXX:0xXX attr=y value=0xYY:0xYY` || 8 | Notification of a Characteristic Value | Notifications | Write CLIENT CONFIGURATION characteristic || 9 | Indication of a Characteristic Value | Indications | Write CLIENT CONFIGURATION characteristic || 10| Reading a Characteristic Descriptor | Read Characteristic Descriptors | `b read conn=x attr=x` |
-| | | Read Long Characteristic Descriptors | `b read conn=x attr=x long=1` || 11 | Writing a Characteristic Descriptor | Write Characteristic Descriptors | `b write conn=x value=0xXX:0xXX` |
-| | | Write Long Characteristic Descriptors | `b write conn=x value=0xXX:0xXX long=1` |<br>
-### Using nimBLE commands
-Assuming you have discovered and established a BLE connection with at least one peer device (as explained earlier in [API for bletiny app](bletiny_api.md), you can find out what characteristics and services are available over these connections. Here is a recap.
-```
-b show conn
-```
-To show discovered services
+| 3 | Relationship Discovery | Find Included Services | `b find inc_svcs conn=x start=x end=x` |
+| 4 | Characteristic Discovery | Discover All Characteristic of a Service | `b disc chr conn=x start=x end=x` |
+| | | Discover Characteristic by UUID | `b disc chr conn=x start=x end=x uuid=x` |
+| 5 | Characteristic Descriptor Discovery | Discover All Characteristic Descriptors | `b disc dsc conn=x start=x end=x` |
+| 6 | Reading a Characteristic Value | Read Characteristic Value | `b read conn=x attr=x` |
+| | | Read Using Characteristic UUID | `b read conn=x start=x end=x uuid=x` |
+| | | Read Long Characteristic Values | `b read conn=x attr=x long=1` |
+| | | Read Multiple Characteristic Values | `b read conn=x attr=x attr=y attr=z` |
+| 7 | Writing a Characteristic Value | Write Without Response | `b write conn=x value=0xXX:0xXX no_rsp=1` |
+| | | Signed Write Without Response | NOT SUPPORTED |
+| | | Write Characteristic Value | `b write conn=x attr=x value=0xXX:0xXX` |
+| | | Write Long Characteristic Values | `b write conn=x attr=x value=0xXX:0xXX long=1` |
+| | | Characteristic Value Reliable Writes | `b write conn=x attr=x value=0xXX:0xXX attr=y value=0xYY:0xYY` |
+| 8 | Notification of a Characteristic Value | Notifications | Write _0x01:0x00_ to CLIENT CONFIGURATION characteristic |
+| 9 | Indication of a Characteristic Value | Indications | Write _0x02:0x00_ to CLIENT CONFIGURATION characteristic |
+| 10| Reading a Characteristic Descriptor | Read Characteristic Descriptors | `b read conn=x attr=x` |
+| | | Read Long Characteristic Descriptors | `b read conn=x attr=x long=1` |
+| 11| Writing a Characteristic Descriptor | Write Characteristic Descriptors | `b write conn=x value=0xXX:0xXX` |
+| | | Write Long Characteristic Descriptors | `b write conn=x value=0xXX:0xXX long=1` |
+
+
+<br>
+
+### Using NimBLE commands
+
+
+Assuming you have discovered and established a BLE connection with at least one peer device (as explained earlier in [API for bletiny app](bletiny_api.md), you can find out what characteristics and services are available over these connections. Here is a recap.
+
+To show established connections:
```
-b show svc
+b show conn
```
-To show discovered characteristics
+To show discovered services, characteristics, and descriptors:
```
b show chr
```
-To show connection RSSI
+To show connection RSSI:
```
b show rssi conn=x
```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/01cda7b9/docs/network/ble/bletiny/bletiny_advdata.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny/bletiny_advdata.md b/docs/network/ble/bletiny/bletiny_advdata.md
index 215232e..d2480bc 100644
--- a/docs/network/ble/bletiny/bletiny_advdata.md
+++ b/docs/network/ble/bletiny/bletiny_advdata.md
@@ -5,12 +5,21 @@
This part defines the advertisement data fields used in the `bletiny` app. For a complete list of all data types and formats used for Extended Inquiry Response (EIR), Advertising Data (AD), and OOB data blocks, refer to the Supplement to the Bluetooth Core Specification, CSSv6, available for download [here](https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=302735&_ga=1.133090766.1368218946.1444779486).
-<br>
-|**Name** | **Definition** | **Details** ||----|---------|---------------|
-| uuids16 |16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 16-bit Service UUIDs available. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. || uuids16_is_complete | 16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
-| uuids32 | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 32-bit Service UUIDs available. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. || uuids32_is_complete | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
-| uuids128 | Global 128-bit Service UUIDs | More 128-bit Service UUIDs available. || uuids128_is_complete | Global 128-bit Service UUIDs | Complete list of 128-bit Service UUIDs |
-| tx_pwr_lvl | TX Power Level | Indicates the transmitted power level of the packet containing the data type. The TX Power Level data type may be used to calculate path loss on a received packet using the following equation: <br> <br> pathloss = Tx Power Level \u2013 RSSI <br> <br> where \u201cRSSI\u201d is the received signal strength, in dBm, of the packet received. |
+
+<br>
+
+
+
+|**Name** | **Definition** | **Details** | **bletiny Notes** |
+|----|---------|---------------|--|
+| flags | Indicates basic information about the advertiser. | Flags used over the LE physical channel are: <br> * Limited Discoverable Mode <br> * General Discoverable Mode <br> * BR/EDR Not Supported <br> * Simultaneous LE and BR/EDR to Same Device Capable (Controller) <br> * Simultaneous LE and BR/EDR to Same Device Capable (Host) | NimBLE will auto-calculate if set to 0. |
+| uuids16 |16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 16-bit Service UUIDs available. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. | Set repeatedly for multiple service UUIDs. |
+| uuids16_is_complete | 16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
+| uuids32 | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 32-bit Service UUIDs available. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. | Set repeatedly for multiple service UUIDs. |
+| uuids32_is_complete | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
+| uuids128 | Global 128-bit Service UUIDs | More 128-bit Service UUIDs available. | Set repeatedly for multiple service UUIDs. |
+| uuids128_is_complete | Global 128-bit Service UUIDs | Complete list of 128-bit Service UUIDs |
+| tx_pwr_lvl | TX Power Level | Indicates the transmitted power level of the packet containing the data type. The TX Power Level data type may be used to calculate path loss on a received packet using the following equation: <br> <br> pathloss = Tx Power Level \u2013 RSSI <br> <br> where \u201cRSSI\u201d is the received signal strength, in dBm, of the packet received. | NimBLE will auto-calculate if set to -128. |
| device_class | Class of device | Size: 3 octets |
| slave_itvl_range | Slave Connection Interval Range | Contains the Peripheral\u2019s preferred connection interval range, for all logical connections. Size: 4 Octets . The first 2 octets defines the minimum value for the connection interval in the following manner: <br> <br> connIntervalmin = Conn_Interval_Min * 1.25 ms <br> <br> Conn_Interval_Min range: 0x0006 to 0x0C80 <br> Value of 0xFFFF indicates no specific minimum. <br> <br> The other 2 octets defines the maximum value for the connection interval in the following manner: <br> <br> connIntervalmax = Conn_Interval_Max * 1.25 ms <br> Conn_Interval_Max range: 0x0006 to 0x0C80 <br> Conn_Interval_Max shall be equal to or greater than the Conn_Interval_Min. <br> Value of 0xFFFF indicates no specific maximum.|
| svc_data_uuid16 | Service Data - 16 bit UUID | Size: 2 or more octets <br> The first 2 octets contain the 16 bit Service UUID followed by additional service data |
@@ -22,5 +31,8 @@ This part defines the advertisement data fields used in the `bletiny` app. For a
| svc_data_uuid32 | Service Data - 32 bit UUID | Size: 4 or more octets <br> The first 4 octets contain the 32 bit Service UUID followed by additional service data |
| svc_data_uuid128 | Service Data - 128 bit UUID | Size: 16 or more octets <br> The first 16 octets contain the 128 bit Service UUID followed by additional service data |
| uri | Uniform Resource Identifier (URI) | Scheme name string and URI as a UTF-8 string |
-| mfg_data | Manufacturer Specific data | Size: 2 or more octets <br> The first 2 octets contain the Company Identifier Code followed by additional manufacturer specific data |<br>
-
\ No newline at end of file
+| mfg_data | Manufacturer Specific data | Size: 2 or more octets <br> The first 2 octets contain the Company Identifier Code followed by additional manufacturer specific data |
+| eddystone_url | | |
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/01cda7b9/docs/network/ble/bletiny/bletiny_api.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny/bletiny_api.md b/docs/network/ble/bletiny/bletiny_api.md
index ce3b5e6..5a48cad 100644
--- a/docs/network/ble/bletiny/bletiny_api.md
+++ b/docs/network/ble/bletiny/bletiny_api.md
@@ -4,11 +4,37 @@
Highlighted below are some of the ways you can use the API to establish connections and discover services and characteristics from peer devices. For descriptions of the full API, go to the next sections on [GAP in bletiny](bletiny_GAP.md) and [GATT in bletiny](bletiny_GATT.md).
+All bletiny commands are prefixed with `b`. This prefix distinguished bletiny commands from other shell commands that are implemented by other Mynewt packages.
+
<br>
-### Set device public address.
+### Set device address.
+
+On startup, bletiny has the following identity address configuration:
+
+* Public address: `0a:0b:0c:0d:0e:0f`
+* Random address: None
+
+The below `set` commands can be used to change the address configuration:
+
+```
+b set addr_type=public addr=<device-address>
+b set addr_type=random addr=<device-address>
+```
+
+For example:
+
+```
+b set addr_type=public addr=01:02:03:04:05:06
+b set addr_type=random addr=c1:aa:bb:cc:dd:ee
+```
+
+The address configuration can be viewed with the `b show addr` command, as follows:
-Currently the device public address is hardcoded to `0a:0b:0c:0d:0e:0f` in `bletiny` app but you can change it by going into its source code and initializing it to the desired value as described in the section on how to [initialize device addr](../ini_stack/ble_devadd.md).
+```
+b show addr
+public_id_addr=01:02:03:04:05:06 random_id_addr=c1:aa:bb:cc:dd:ee
+```
<br>
@@ -17,8 +43,8 @@ Currently the device public address is hardcoded to `0a:0b:0c:0d:0e:0f` in `blet
In this case, your board is acting as a central and initiating a connection with another BLE device. The example assumes you know the address of the peer, either by scanning for available peers or because you have set up the peer yourself.
```hl_lines="1"
-b conn addr_type=public addr=d4:f5:13:53:d2:43
-[ts=118609ssb, mod=64 level=2] connection complete; status=0 handle=1 peer_addr_type=0 peer_addr=0x43:0xd2:0x53:0x13:0xf5:0xd4 conn_itvl=40 conn_latency=0 supervision_timeout=256
+b conn own_addr_type=public peer_addr_type=public peer_addr=d4:f5:13:53:d2:43
+connection established; handle=1 our_ota_addr_type=0 our_ota_addr=0a:0b:0c:0d:0e:0f out_id_addr_type=0 our_id_addr=0a:0b:0c:0d:0e:0f peer_addr_type=0 peer_addr=43:d2:53:13:f5:d4 conn_itvl=40 conn_latency=0 supervision_timeout=256 encrypted=0 authenticated=0 bonded=0
```
The `handle=1` in the output indicates that it is connection-1.
@@ -53,12 +79,12 @@ b show conn
<br>
-### Discover and display peer's services.
+### Discover and display peer's services, characteristics, and descriptors.
This is how you discover and then display the services of the peer you established earlier across connection-1.
```hl_lines="1 2"
-b disc svc conn=1
+b disc full conn=1
b show chr
[ts=132425ssb, mod=64 level=2] CONNECTION: handle=1 addr=d4:f5:13:53:d2:43
[ts=132428ssb, mod=64 level=2] start=1 end=5 uuid=0x1800
@@ -69,58 +95,10 @@ b show chr
<br>
-### Discover characteristics for each service on peer
-
-The following examples show how to find the characteristics for each service available on the peer device across connection-1. The start and end values depend on the specific services discovered using the previous command `b show chr`. Continuing with the example above, you can discover the characteristics of the first service and display it using the following commands.
-
-```hl_lines="1 2"
-b disc chr conn=1 start=1 end=5
-b show chr
-[ts=163063ssb, mod=64 level=2] CONNECTION: handle=1 addr=d4:f5:13:53:d2:43
-[ts=163067ssb, mod=64 level=2] start=1 end=5 uuid=0x1800
-[ts=163071ssb, mod=64 level=2] def_handle=2 val_handle=3 properties=0x02 uuid=0x2a00
-[ts=163078ssb, mod=64 level=2] def_handle=4 val_handle=5 properties=0x02 uuid=0x2a01
-[ts=163085ssb, mod=64 level=2] start=6 end=16 uuid=0x1808
-[ts=163089ssb, mod=64 level=2] start=17 end=31 uuid=0x180a
-[ts=163094ssb, mod=64 level=2] start=32 end=65535 uuid=00000000-0000-1000-1000000000000000
-```
-
-You can next discover characteristics for the second service and display.
-
-```hl_lines="1 2"
-b disc chr conn=1 start=6 end=16
-b show chr
-[ts=180631ssb, mod=64 level=2] CONNECTION: handle=1 addr=d4:f5:13:53:d2:43
-[ts=180634ssb, mod=64 level=2] start=1 end=5 uuid=0x1800
-[ts=180639ssb, mod=64 level=2] def_handle=2 val_handle=3 properties=0x02 uuid=0x2a00
-[ts=180646ssb, mod=64 level=2] def_handle=4 val_handle=5 properties=0x02 uuid=0x2a01
-[ts=180653ssb, mod=64 level=2] start=6 end=16 uuid=0x1808
-[ts=180657ssb, mod=64 level=2] def_handle=7 val_handle=8 properties=0x10 uuid=0x2a18
-[ts=180664ssb, mod=64 level=2] def_handle=10 val_handle=11 properties=0x02 uuid=0x2a51
-[ts=180672ssb, mod=64 level=2] def_handle=12 val_handle=13 properties=0x28 uuid=0x2a52
-[ts=180679ssb, mod=64 level=2] def_handle=15 val_handle=16 properties=0x02 uuid=0x2a08
-[ts=180686ssb, mod=64 level=2] start=17 end=31 uuid=0x180a
-[ts=180691ssb, mod=64 level=2] start=32 end=65535 uuid=00000000-0000-1000-1000000000000000
-```
-
-<br>
-
-### Discover descriptors for each characteristic on peer
-
-Just as before, the start and end values depend on the specific characteristics discovered.
-
-```
-b disc dsc conn=1 start=1 end=5
-b disc dsc conn=1 start=6 end=16
-b disc dsc conn=1 start=17 end=31
-```
-
-<br>
-
### Read an attribute belonging to the peer
```
-b read conn=1 attr=18 attr=21
+b read conn=1 attr=21
```
<br>
@@ -138,7 +116,5 @@ b write conn=1 attr=3 value=0x01:0x02:0x03
This is how you tell your board to listen to all advertisements around it. The duration is specified in ms.
```
-b scan dur=1000 disc=gen type=passive filt=no_wl
+b scan dur=1000 type=passive filt=no_wl
```
-
-<br>