BLE Basics

Bluetooth Low Energy (BLE) is a wireless protocol designed for low-power devices that need to transmit small amounts of data intermittently. Unlike classic Bluetooth (used for audio streaming and file transfers), BLE prioritizes battery life over throughput—making it ideal for sensors, trackers, and IoT devices that run for months or years on a coin cell.

This guide covers the core concepts you need to understand before building BLE devices.

Two Ways to Communicate

BLE offers two communication models. Choosing the right one shapes your entire design.

Most IoT devices use advertising exclusively—it’s simpler, uses less power, and scales to unlimited receivers. Connections add complexity but enable features like acknowledgments, larger payloads, and two-way communication.

Advertising and Scanning

Advertising is BLE’s broadcast mode. A device periodically transmits small packets (up to 31 bytes) announcing its presence and optionally including data. Any nearby device can passively scan for these advertisements without establishing a connection.

Advertisement packets typically include:

• Device name
• Service UUIDs (what capabilities the device offers)
• Manufacturer-specific data (sensor readings, identifiers)

Advertising intervals control how often a device broadcasts—typically between 20ms and 10 seconds. Shorter intervals mean faster discovery but higher power consumption. A device advertising every 100ms will be discovered quickly but drain its battery faster than one advertising every 2 seconds.

For Hubble Network, advertising is the primary communication method. Your device broadcasts its payload, and Hubble’s terrestrial network (or satellites) receives it—no pairing or connection required.

But what if you need to send more data, or need the receiver to talk back?

Connections

When advertising isn’t enough—you need bidirectional communication, reliable delivery, or payloads larger than 31 bytes—devices establish a connection.

The connection process works like this:

1. Peripheral advertises its presence (your sensor, wearable, etc.)
2. Central scans and discovers the peripheral (phone, gateway, laptop)
3. Central sends a connection request
4. Devices negotiate connection parameters and establish a link

Once connected, the central coordinates timing by sending regular connection events at a fixed interval. The peripheral wakes up for each event to send or receive data, then sleeps until the next one.

Connection intervals range from 7.5ms to 4 seconds. A 30ms interval means the peripheral wakes ~33 times per second—responsive but power-hungry. A 2-second interval conserves battery but adds latency.

Connections enable reliable delivery with acknowledgments, larger data transfers, and bidirectional communication. The tradeoff is complexity and power—both devices must maintain synchronized timing.

Once connected, how do devices know what data is available and how to access it?

GATT: Organizing Data

The Generic Attribute Profile (GATT) defines how connected devices structure and exchange data. Think of it as the schema for your device’s data.

GATT organizes data into a hierarchy:

• Profile: A collection of services for a use case (e.g., Heart Rate Profile)
• Service: A group of related data (e.g., Heart Rate Service)
• Characteristic: A single data point (e.g., heart rate measurement)
• Descriptor: Metadata about a characteristic (e.g., units, valid range)

Each service and characteristic has a UUID—either a 16-bit ID from the Bluetooth SIG’s assigned numbers or a custom 128-bit UUID you define.

Here’s how a temperature sensor might structure its GATT:

Environmental Sensing Service (UUID: 0x181A)
├── Temperature Characteristic (UUID: 0x2A6E)
│   └── Value: 23.5°C
│   └── Descriptor: Celsius, read-only
└── Humidity Characteristic (UUID: 0x2A6F)
    └── Value: 45%

Characteristics have properties that control access:

Notify is particularly useful for sensors. Rather than the central polling repeatedly (“what’s the temperature now?”), the peripheral pushes updates only when values change—saving power on both sides.

Whether you’re advertising or using connections, every radio transmission costs energy. Understanding power consumption is essential to building devices that last.

Power Management

Every BLE design decision affects battery life. Understanding the power states helps you make informed tradeoffs.

BLE radios cycle through three states:

The key insight: time in active state dominates power consumption. A device drawing 10mA while transmitting but only transmitting for 2ms every second averages just 20µA—enough to run for years on a CR2032 coin cell.

Strategies to minimize power consumption:

Increase advertising interval. Going from 100ms to 1 second cuts advertising power by 90%. Choose the longest interval your use case allows.

Use connection intervals wisely. If you need connections, negotiate the longest interval your latency requirements allow. A 1-second interval uses far less power than 50ms.

Prefer notify over polling. Let the peripheral decide when to send data rather than having the central request it repeatedly.

Minimize payload size. Smaller packets mean shorter transmit times. Pack your data efficiently.

Sleep aggressively. Your MCU should sleep between radio events. Configure your firmware to enter the lowest power state possible.

Building with Hubble Network

Hubble Network uses BLE advertising as its transport. Your device broadcasts its payload, and the network receives it without requiring pairing or connections. The advertising and power management concepts above are exactly what you’ll apply when building with Hubble.

The Hubble SDK is an officially qualified Bluetooth product, certified by the Bluetooth Special Interest Group (SIG). This means devices you build with Hubble meet Bluetooth compliance standards and are ready for commercial deployment.

• Device SDK Overview - Hubble-specific BLE configuration
• Zephyr Quick Start - Flash your first Hubble-enabled firmware
• Browse Supported Boards - Find compatible development hardware