Bluetooth supports three topologies: star (point-to-point or broadcast for beacons), connected (bidirectional data exchange with security), and mesh (building-scale multi-hop using managed flooding). The choice depends on power budget, range requirements, and network device count.
Bluetooth supports three main topologies: star (point-to-point or broadcast for beacons), connected (bidirectional data exchange with security), and mesh (building-scale multi-hop networks using managed flooding). The choice between them is driven by power budget, range requirements, and the number of devices in the network. Advertising interval is the single largest factor affecting beacon battery life.
By the end of this chapter, you will be able to:
Bluetooth devices can connect in different patterns. A point-to-point connection links two devices directly (like your phone to your earbuds). A star network connects multiple devices to one central hub. Bluetooth Mesh creates a web of interconnected devices that can relay messages across large areas, like smart lighting in an entire building.
“Bluetooth networks come in different shapes, just like how you can arrange desks in a classroom!” Sammy the Sensor said. “A star topology is like desks arranged in a circle around the teacher – everything goes through one central device. That is how most BLE connections work, with your phone in the middle.”
“Broadcast topology is my favorite,” Lila the LED announced. “It is like a lighthouse sending light in all directions. A BLE beacon just broadcasts its signal to anyone listening – no pairing needed, no handshakes, no waiting. That is how stores know when you walk past a display!”
Max the Microcontroller rubbed his chin thoughtfully. “But the real game-changer is Bluetooth Mesh. Imagine a chain of people passing a message across a football field. Each device receives the message and relays it to the next one. That way, even if I cannot reach the gateway directly, my message can hop through other devices until it gets there. It works for entire buildings!”
“Each topology has different power needs,” Bella the Battery explained. “A simple point-to-point connection is the most efficient – just two devices talking. Broadcasting uses a bit more because the beacon never stops. And mesh uses the most energy because every device might need to relay messages for others. Choosing the right shape is key to making me last as long as possible!”
Before diving into this chapter, you should be familiar with:
The simplest BLE topology is the star broadcast pattern, where a beacon advertises to multiple receivers without establishing connections.
Characteristics:
BLE devices can work in two modes:
1. Advertising Mode (Broadcasting):
Examples:
2. Connected Mode (Two-way communication):
Advertising power consumption scales linearly with interval frequency. Given a CR2032 coin cell battery (220 mAh capacity) and typical nRF52 BLE chip specifications:
\[ \begin{aligned} \text{TX events per second} &= \frac{1000 \text{ ms}}{\text{interval (ms)}} \times 3 \text{ channels} \\[0.4em] \text{Active time per event} &= 0.5 \text{ ms (TX)} + 0.1 \text{ ms (setup)} = 0.6 \text{ ms} \\[0.4em] I_{\text{avg}} &= I_{\text{TX}} \times \text{duty cycle} + I_{\text{sleep}} \times (1 - \text{duty cycle}) \\[0.4em] \text{Battery life (hours)} &= \frac{\text{Capacity (mAh)}}{I_{\text{avg}} \text{ (mA)}} \end{aligned} \]
For 20 ms interval (minimum): \[ \begin{aligned} \text{Events/sec} &= \frac{1000}{20} \times 3 = 150 \text{ events/sec} \\[0.4em] \text{Duty cycle} &= \frac{150 \times 0.6}{1000} = 0.09 = 9\% \\[0.4em] I_{\text{avg}} &= 15\text{ mA} \times 0.09 + 0.002\text{ mA} \times 0.91 = 1.35 + 0.002 \approx 1.35\text{ mA} \\[0.4em] \text{Life} &= \frac{220}{1.35} \approx 163 \text{ hours} \approx 7 \text{ days} \end{aligned} \]
For 1000 ms interval (power-optimized): \[ \begin{aligned} \text{Events/sec} &= \frac{1000}{1000} \times 3 = 3 \text{ events/sec} \\[0.4em] \text{Duty cycle} &= \frac{3 \times 0.6}{1000} = 0.0018 = 0.18\% \\[0.4em] I_{\text{avg}} &= 15\text{ mA} \times 0.0018 + 0.002\text{ mA} \times 0.9982 = 0.027 + 0.002 \approx 0.029\text{ mA} \\[0.4em] \text{Life} &= \frac{220}{0.029} \approx 7,586 \text{ hours} \approx 316 \text{ days} \end{aligned} \]
Key insight: Increasing the advertising interval from 20 ms to 1000 ms (50x longer) extends battery life from 7 days to 316 days (45x improvement). The relationship is nearly linear because duty cycle dominates over sleep current at high advertising rates.
Note on TX current: This example uses 15 mA TX current, which corresponds to nRF52 operating at +4 dBm output power. At the more common 0 dBm setting, TX current is approximately 5–7 mA, yielding a longer 20 ms-interval life of roughly 11 days. The relative improvement from interval tuning remains the same regardless of TX power setting.
Adjust the advertising interval and observe how it affects battery life for a CR2032-powered BLE beacon.
viewof advInterval = Inputs.range([20, 10000], {
value: 1000,
step: 10,
label: "Advertising Interval (ms)"
})
viewof txCurrent = Inputs.range([5, 25], {
value: 15,
step: 0.5,
label: "TX Current (mA)"
})
viewof batteryCapacity = Inputs.range([100, 1000], {
value: 220,
step: 10,
label: "Battery Capacity (mAh)"
}){
const channels = 3;
const eventDuration = 0.6; // ms per event (TX + setup)
const sleepCurrent = 0.002; // mA
const eventsPerSec = (1000 / advInterval) * channels;
const dutyCycle = (eventsPerSec * eventDuration) / 1000;
const avgCurrent = txCurrent * dutyCycle + sleepCurrent * (1 - dutyCycle);
const batteryHours = batteryCapacity / avgCurrent;
const batteryDays = batteryHours / 24;
const color1 = "#2C3E50";
const color2 = batteryDays > 180 ? "#16A085" : batteryDays > 30 ? "#E67E22" : "#E74C3C";
return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 1.2rem; font-family: Arial, sans-serif;">
<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(180px, 1fr)); gap: 1rem; margin-bottom: 1rem;">
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
<div style="font-size: 0.85rem; color: #666;">TX Events/sec</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${eventsPerSec.toFixed(1)}</div>
</div>
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
<div style="font-size: 0.85rem; color: #666;">Duty Cycle</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${(dutyCycle * 100).toFixed(2)}%</div>
</div>
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
<div style="font-size: 0.85rem; color: #666;">Avg Current</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${avgCurrent < 1 ? (avgCurrent * 1000).toFixed(0) + " uA" : avgCurrent.toFixed(2) + " mA"}</div>
</div>
<div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color2};">
<div style="font-size: 0.85rem; color: #666;">Battery Life</div>
<div style="font-size: 1.5rem; font-weight: bold; color: ${color2};">${batteryDays < 1 ? (batteryHours).toFixed(0) + " hours" : batteryDays < 365 ? batteryDays.toFixed(0) + " days" : (batteryDays / 365).toFixed(1) + " years"}</div>
</div>
</div>
<div style="font-size: 0.8rem; color: #666;">Assumes CR2032 coin cell, nRF52 BLE chip, 3 advertising channels, ${eventDuration} ms per TX event, ${sleepCurrent} mA sleep current.</div>
</div>`;
}The Mistake: Setting the BLE advertising interval to 20ms (the minimum allowed) for a battery-powered beacon because “faster discovery means better user experience,” then finding batteries drain in weeks instead of months.
Why It Happens: Developers optimize for discovery latency without calculating the power cost. At 20ms intervals, the radio transmits 50 times per second on 3 channels (150 TX events/second). This continuous activity prevents the MCU from entering deep sleep and dominates power consumption.
The Fix: Match advertising interval to your actual discovery latency requirements. For most beacon applications, 100-1000ms intervals provide acceptable discovery time with dramatically better battery life:
Use 100-300ms for consumer devices needing responsive discovery. Use 1-10s for asset tracking where battery life trumps discovery speed.
Bluetooth Mesh extends BLE beyond point-to-point connections to building-scale deployments.
Characteristics:
Mesh Advantages:
Bluetooth Mesh uses managed flooding for message delivery, which eliminates the need for routing tables on resource-constrained devices.
Key node types:
Scenario: A commercial building needs to deploy 200 smart lights across 3 floors using Bluetooth Mesh. The building has concrete floors (high RF attenuation) and requires smartphone control from any location.
Given:
Steps:
Calculate relay density: Each relay node covers ~10m radius indoors. For 2000 m^2 per floor, need approximately 60-70 lights per floor acting as relays. With 200 lights, coverage is adequate.
Design for floor isolation: Concrete attenuates signals significantly. Install 2-3 proxy nodes per floor at stairwells/elevators where some cross-floor signal may exist. These proxy nodes bridge BLE mesh to smartphone GATT connections.
Configure TTL (Time To Live): With average 3-4 hops to reach any light on a floor, set TTL=7 to allow cross-floor commands while preventing excessive flooding. Each hop adds ~10-20ms latency.
Plan provisioning: Use a provisioner app to add all 200 devices to the network. Assign group addresses: Floor1_All (0xC001), Floor2_All (0xC002), Floor3_All (0xC003), Building_All (0xC000).
Calculate worst-case latency: Maximum 6 hops x 50ms per hop = 300ms, well within 500ms requirement.
Result: Building-wide lighting control with smartphone access from any location. Commands propagate via managed flooding through relay nodes, with proxy nodes enabling smartphone connectivity. Group addressing allows “all off” commands for entire floors or building.
Key Insight: Bluetooth Mesh’s managed flooding eliminates the need for routing tables on resource-constrained light bulbs. Every mains-powered light becomes a relay, creating dense coverage. The TTL parameter balances network-wide reach against flooding overhead.
Scenario: A warehouse deploys battery-powered temperature/humidity sensors that must report every 5 minutes while achieving 2+ year battery life on a CR2032 coin cell.
Given:
Analysis:
Configure Friend relationship: Each LPN establishes friendship with a nearby Friend Node. The Friend stores messages destined for the LPN while it sleeps.
Calculate LPN power budget:
Estimate lifetime before derating:
Result: A CR2032-powered Low Power Node can meet the 2-year requirement on paper, but only if Friend polling is tightly controlled and the RF environment is reliable. The mains-powered Friend Nodes carry the always-on mesh burden; the battery sensors should not act as relays.
Key Insight: BLE Mesh Low Power Nodes can work for battery sensors, but the design is sensitive to poll interval, retransmissions, and receive-window duration. For very infrequent telemetry with no downlink commands, advertising-only beacons to mesh-connected gateways may still be simpler and more power-efficient.
Understanding the BLE Link Layer state machine is critical for power optimization. Devices spend most time in Standby (~1 uA) with brief bursts in active states.
States:
State Transitions:
BLE discovery involves the interplay between advertising and scanning timing.
Scanner Parameters:
Discovery Time Calculation:
Discovery time depends on when the scan window overlaps with an advertisement on any of the 3 advertising channels.
For example, a beacon advertising every 100ms and a scanner listening for 50ms every 200ms has a 25% scan duty cycle. Discovery commonly lands in the 100-300ms range: the best case is an advertisement inside the active scan window, while the worst case waits several cycles for timing alignment.
Bluetooth defines power classes for different range requirements:
Use this decision framework to choose the right Bluetooth technology:
Choose BLE Advertising (Beacons) when:
Choose BLE Connected Mode when:
Choose Bluetooth Mesh when:
Choose Classic Bluetooth when:
Large Bluetooth Mesh lighting deployments illustrate both the strengths and engineering constraints of managed flooding. The design pattern is strongest when most luminaires are mains-powered, relay density is high, and user controls need to address rooms, floors, or whole-building groups.
Representative planning numbers:
Why Bluetooth Mesh instead of a gateway-only or wired retrofit?
The decision framework usually comes down to three factors:
Smartphone compatibility: Bluetooth Mesh proxy nodes let phones participate in provisioning or control without every interaction going through a separate coordinator.
Retrofit scope: Wireless control can reuse existing mains wiring and avoid new control cable runs through finished ceilings.
Managed flooding simplicity: each luminaire can relay messages without maintaining full routing tables, which keeps firmware simpler at high node counts.
Engineering Tradeoff – Flooding Bandwidth:
Bluetooth Mesh’s managed flooding means messages are relayed by enabled relay nodes within TTL range. In a dense 1,800-node design with TTL=5, one poorly scoped group command can generate a large burst of relay events. The design must control bandwidth through:
A practical design goal is to keep normal mesh traffic well below theoretical airtime capacity, leaving headroom for bursty group commands during morning arrival, evening departure, or emergency scenes.
This chapter covered Bluetooth network topologies:
Deploying one smartphone per sensor in a point-to-point topology for a 20-sensor building monitoring system requires 20 smartphones or 20 sequential connection cycles from a single gateway. Use BLE star topology (single central, multiple peripherals) or BLE Mesh for multi-sensor deployments. A single ESP32 can maintain 10–20 simultaneous BLE connections, serving as a hub for many sensors.
BLE Mesh adds significant complexity: provisioning, key management, model configuration, and relay node placement. For deployments under 20 devices within a 50 m radius of a gateway, BLE star topology achieves better latency, simpler firmware, and easier debugging. Use BLE Mesh only when you need: range beyond direct gateway reach, no infrastructure (gateway-less operation), or >20 devices.
BLE advertising data is transmitted in cleartext and can be received by any BLE scanner within range. Broadcasting patient vital signs, access control codes, or proprietary sensor data in advertising PDUs exposes it to passive eavesdropping. Use encrypted connection-based GATT for sensitive data; use advertising only for non-sensitive discovery metadata (device name, service UUID, TX power).
BLE Mesh networks with insufficient relay nodes have coverage holes where messages cannot reach their destination. Each relay node increases network delay by one hop latency (~10–50 ms). For reliable coverage, ensure every node is within range of at least 2 relay nodes (for redundancy), and use the mesh provisioner’s network analyzer to map relay coverage before deployment.
Prioritize these follow-up chapters based on your design question: