How Do You Implement a BLE Beacon: iBeacon vs Eddystone?

Detailed Explanation

A beacon is not a special BLE radio mode — it's a convention for how an ordinary non-connectable BLE advertising packet's payload is structured, so that a scanning app on the receiving end knows how to interpret it without any prior connection or GATT service discovery. The two dominant conventions are iBeacon (defined by Apple, closed specification but widely implemented outside Apple's own ecosystem) and Eddystone (defined by Google, published as an open specification on GitHub).

iBeacon packs its data into a manufacturer-specific advertising data field: a 16-byte Proximity UUID (typically shared across an entire deployment or app to identify "this is our beacon"), a 2-byte Major value (commonly used to identify a location, such as a specific store), a 2-byte Minor value (commonly used to identify a more specific position within that location, such as a particular shelf or entrance), and a calibrated Tx power byte used for the coarse proximity estimate described in the FAQ below.

Eddystone defines several distinct frame types that a beacon can broadcast, either individually or rotated across successive advertising intervals:

• Eddystone-UID — a 10-byte namespace ID plus a 6-byte instance ID, conceptually similar to iBeacon's UUID/Major/Minor split but with different field sizes and no requirement to tie the identifier to a specific app's reverse-lookup table.
• Eddystone-URL — broadcasts a compressed URL directly in the advertising packet (using a scheme/prefix and suffix compression table to fit a real URL into the available advertising payload space), enabling the "Physical Web" pattern where any BLE-scanning device can resolve the beacon straight to a web page with no dedicated app and no beacon-ID-to-content lookup table required at all.
• Eddystone-TLM — telemetry data: battery voltage, device temperature, and advertising/uptime counters, intended for beacon fleet health monitoring rather than end-user proximity detection.

Practical Examples

A retail chain deploying beacons at fixed shelf and entrance locations to trigger an in-app promotional notification is a natural fit for iBeacon (or Eddystone-UID): one Proximity UUID identifies the deploying company across every store, and the Major/Minor pair (or Eddystone namespace/instance pair) narrows down to the specific store and fixture — the app already knows what content to show for each identifier because that mapping is defined in the app's own backend, not broadcast by the beacon itself.

A museum or public wayfinding deployment wanting visitors to get exhibit information without installing a dedicated app first is the textbook Eddystone-URL case: the beacon broadcasts a URL directly, and any phone with beacon-scanning support in its browser or notification system (historically Chrome's Physical Web integration, and various third-party scanner apps) can resolve straight to the content with zero app-side identifier-to-content mapping required.

Design Considerations

• Choose the format based on the actual deployment's app requirement, not developer preference — iBeacon (and Eddystone-UID) require the receiving app to already know how to map a UUID/namespace and Major/Minor identifier to meaningful content, which is fine for a dedicated branded app but adds no value for an app-free public deployment; Eddystone-URL is the better fit when the beacon needs to be useful to a generic scanner with no prior knowledge of the deployment.
• Program the calibrated Tx power value against the beacon's actual measured RSSI at 1 metre, not a generic default copied from a reference design — an inaccurate calibration value degrades every scanning app's proximity estimate for that specific beacon, and the error is easy to overlook since nothing about the advertising packet itself indicates the calibration value is wrong.
• Size the advertising interval as a deliberate power-vs-responsiveness trade-off, exactly as for any other BLE advertising use case — see BLE connection parameters and power optimisation for the underlying advertising-interval power model, which applies to a beacon's continuous advertising just as it does to a connectable peripheral's advertising phase.
• Treat beacon RSSI-based proximity as a coarse zone estimate, not a precise range measurement — see the FAQ above for why, and use a purpose-built ranging technology instead when the application genuinely needs accurate distance rather than a rough near/far classification.
• Rotating multiple Eddystone frame types (UID, URL, TLM) across successive advertising intervals reduces the effective update rate of each individual frame type for a fixed total advertising interval — plan the rotation schedule and interval together rather than treating each frame type as independently available at the full advertising rate.
• Beacon deployment engineering: designing and validating a beacon fleet's format, calibration, and advertising-interval trade-offs for a real deployment is exactly the kind of BLE product engineering Zeus Design's electronics design team handles for proximity, wayfinding, and asset-tracking products.

Common Mistakes

• Choosing iBeacon for an app-free public deployment where Eddystone-URL would have removed the need for any identifier-to-content backend mapping, adding unnecessary app-development scope for a use case that didn't require a dedicated app at all.
• Leaving the Tx power calibration byte at a generic default rather than measuring and programming the beacon's actual RSSI at the 1-metre reference distance, silently degrading proximity accuracy for every scanning app that reads it.
• Treating beacon-based proximity as accurate ranging for an application (indoor navigation, precise asset location) that actually needs the accuracy only Angle of Arrival/Departure or UWB ranging can provide, then being surprised by RSSI's real-world noise from multipath and body shadowing.
• Over-rotating Eddystone frame types on a short total advertising interval budget, unintentionally reducing each individual frame type's effective update rate below what the application actually needs.