Platform Basics — Terminology
To get started with the platform, there are some terms that you should become familiar with. Some of these terms are the same or similar to formal Bluetooth terms used in the Bluetooth Core Specification; however, the definitions here are much simpler and more constrained.
The middleware APIs make use of the terms below, so we recommend that you use the guide below as a reference during development and testing.
Components
| Term | Description |
|---|
| Peripheral | This is the embedded device that is running the SwaraLink Embedded Peripheral Middleware (swl_periph) along with its application firmware. This could be, for example, a wearable device or some other kind of connected accessory. |
| Central | This is the mobile device that is running the SwaraLink Mobile Central Middleware (SWLCentral) along with a mobile app. This is typically a smartphone. |
Peripheral and Central Interactions
| Term | Description |
|---|
| Advertising | This is what the peripheral device does to make its presence known to the central device. |
| Discovery | This is the process for the central device to find nearby advertising peripherals. |
| Connections | In order for the central and peripheral to communicate, they must first form a connection. Once a connection is established, either device may send data to the other device. The middleware ensures that all data communications are encrypted with a secure key exchange. |
| Pairing Mode | In order for the central and peripheral to connect for the first time, the user must put the peripheral into pairing mode (typically via a button press or some other action) before the central can discover and connect to the peripheral. |
| Paired Devices | Once the central and peripheral device are paired with each other, the peripheral device will reject any attempted connections from any other central device unless the peripheral is put into pairing mode. The central can be paired with any number of peripherals, and the peripheral can paired with up to 5 central devices at any given time. |
Communication
| Term | Description |
|---|
| P2C Data | Data sent from “peripheral-to-central” while connected |
| C2P Data | Data sent from “central-to-peripheral” while connected |
| Packet Size | For P2C data, the data being sent can be any size between 1 and 65535 bytes per transfer. For C2P data, the data being sent can be any size between 1 and 1024 bytes per transfer. |
| ID Headers | Every data transfer includes a Major and Minor ID header (one byte each) to distinguish between data types when sending and receiving. When developing the application code, these can be defined however you like; there are no restricted values. |
| Acknowledged Transfer | Any data transfer can optionally be sent as an acknowledged transfer. When the peer device has received an acknowledged data transfer, it will automatically send an acknowledgement back to the sender. The sender receives an event when the acknowledgement is received. Note that non-acknowledged packets are still guaranteed to be transmitted in the order that they are queued up. |
Peripheral Priorities
This API feature enables simple priority-setting for the peripheral device. With three different priorities 1 through 3, ranking from highest to lowest respectively.
The same metric/performance indicator can be chosen for all three priority levels. It is worth noting, heavily prioritizing one option will lessen the optimization across the others.
| Term | Description |
|---|
| Data Throughput | The rate at which data is transferred between the central and peripheral. |
| Power Consumption | The amount of current drawn from the power source for data transfers. Transmitting data consumes more than receiving. |
| Communication Range | The omnidirectional range that peripheral can sense to exchange data. |
Additional Features
| Term | Description |
|---|
| Device Firmware Update (DFU) | The peripheral firmware can be updated over-the-air (OTA). The mobile app API SWL.updatePeripheralFirmware handles this OTA DFU in the SWLCentralStateConnected state. |
| Diagnostic Logs | These logs are observed and stored by the peripheral upon running the middleware and track various code events until power is disconnected or the system is reset. They can be sent to the central once in the SWLCentralStateConnected state and saved from the mobile app to your phone. |