Indication

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

A server-initiated update that requires client acknowledgment, providing reliable delivery at the cost of lower throughput.

Also known as: GATT Indication

What Is a BLE Indication?

An ATT">GATT & ATT">Indication is a server-initiated GATT operation that pushes a characteristic value update to a connected client and waits for an explicit acknowledgment before proceeding. Unlike notifications, indications guarantee that the client has received the data, making them suitable for critical or stateful exchanges.

How Indications Work

The indication flow mirrors notifications with one additional step. The client first enables indications by writing 0x0002 to the CCCD. When the server sends a Handle Value Indication PDU, the client must respond with a Handle Value Confirmation. The server blocks further indications on that ATT bearer until the confirmation arrives or a 30-second timeout expires, at which point the server typically disconnects.

When to Use Indications

Indications are the right choice when data loss is unacceptable and the update rate is low. Common use cases include:

  • Firmware update progress -- losing a progress report could cause the host app to stall.
  • Configuration acknowledgments -- confirming that a written setting has been applied.
  • Alert and alarm state changes -- ensuring the client is aware of safety-critical events.
  • Authentication challenge-response -- exchanging tokens where every step must succeed.

For high-frequency data (sensor readings above 1 Hz), indications are generally too slow because the round-trip confirmation limits throughput to roughly one indication per connection event.

Throughput Comparison

With a 15 ms connection interval, a single indication can be sent and confirmed per event, yielding a maximum of about 66 indications per second. By contrast, notifications can pack multiple PDUs per event, achieving 10 -- 50 times higher throughput. This stark difference is why sensor-streaming applications overwhelmingly use notifications with application-layer sequence numbers for gap detection, reserving indications for occasional control-plane messages.

Implementation Patterns

A robust indication sender should implement a simple state machine: IDLE, PENDING (indication sent, awaiting confirmation), and TIMEOUT (confirmation not received). If the confirmation times out, the server should disconnect because the ATT specification states that no further ATT traffic is permitted after a timeout. Client-side, the BLE stack usually handles the confirmation automatically, but application code must still process the incoming indication payload promptly to avoid delaying the confirmation and causing unnecessary back-pressure.

Mixing Notifications and Indications

A single GATT server can use both mechanisms on different characteristics simultaneously. A heart-rate characteristic might use notifications while a control-point characteristic on the same service uses indications. The two mechanisms operate independently, so notification throughput is unaffected by a pending indication on another characteristic, provided they are on separate ATT bearers or the stack handles interleaving correctly.

Related Terms

Frequently Asked Questions

Our glossary covers 90+ BLE technical terms organized by category. Each term includes a definition, related terms, and links to relevant chips and guides.