Payload budget
- Legacy advertising: 31 bytes of advertising data, plus 31 bytes in the scan response (only sent to active scanners that ask).
- Each field (AD structure) costs 2 bytes of overhead (length + type). Flags take 3 bytes, a 128-bit service UUID 18 bytes, and what's left is small.
- Extended advertising (Bluetooth 5) moves the payload to secondary channels and can chain packets, up to 1650 bytes of advertising data. Older phones and scanners may not see extended advertisements at all, so keep a legacy advertisement for discovery if you need broad compatibility.
Typical legacy layout for an IoT sensor:
Flags (3) | 16-bit service UUID or short name (4–10) | Manufacturer data: company ID (2) + device ID + status bytes
Interval: discovery time vs battery
The advertising interval ranges from 20 ms to 10.24 s, and the controller adds a random 0–10 ms delay to each event to avoid persistent collisions.
| Situation | Interval |
|---|---|
| Just powered on / pairing button pressed | 20–100 ms for 30–60 s |
| Normal, connectable, phone should find it within seconds | 200 ms – 1 s |
| Broadcast-only sensor, discovery time not critical | 1–10 s |
Use a fast-then-slow pattern: advertise quickly after a user action, then back off.
Privacy and identity
- Devices can use resolvable private addresses that change periodically; bonded peers resolve them with the identity resolving key (IRK). Phones do this by default.
- Therefore don't identify devices by address. Put your own ID into manufacturer data or a characteristic (see the item on iOS and MAC addresses).
- Everything in advertising is public. Don't broadcast secrets, and consider whether a stable ID lets people track the device's owner.
Beacons vs connections
If data is small, frequent and not sensitive (temperature, battery), a broadcast-only design (sensor data in manufacturer data, gateways scanning) avoids connections entirely and scales to many sensors. Use connections when you need reliability, bidirectional control or security.