318 West Adams Street, Chicago
IL 60606
Tel: +1 512 999 5796


675 Alpha Dr, Suite E, Highland Heights,
OH – 44143
Cleveland, Ohio
Tel: +1 512 999 5796


#102, First Floor Lulu Cyber Tower
Infopark, Kochi – 682 042
Kerala, India
Tel: +91 484 404 5555






+1 512 999 5796


[fullwidth background_color="" background_image="" background_parallax="none" enable_mobile="no" parallax_speed="0.3" background_repeat="no-repeat" background_position="left top" video_url="" video_aspect_ratio="16:9" video_webm="" video_mp4="" video_ogv="" video_preview_image="" overlay_color="" overlay_opacity="0.5" video_mute="yes" video_loop="yes" fade="no" border_size="0px" border_color="" border_style="" padding_top="0" padding_bottom="20" padding_left="0" padding_right="0" hundred_percent="yes" equal_height_columns="no" hide_on_mobile="no" menu_anchor="" class="" id=""] Common Elements

Every Eddystone frame type must contain the following PDU data types:

    The Service Solicitation data type as defined in The Bluetooth Core Specification Supplement (CSS) v5, Part A, § 1.10. The List of 16 bit Service Solicitation UUIDs must contain the Eddystone Service UUID of 0xFEAA. This is included to allow background scanning on iOS devices. The Service Data data type, Ibid, § 1.11. The Service Data - 16 bit UUID data type must be the Eddystone Service UUID of 0xFEAA.

The specific type of Eddystone frame is encoded in the high-order four bits of the first octet in the Service Data associated with the Service UUID. Permissible values are:

Frame Type High-Order 4 bits Byte Value UID 0000 0x00 URL 0001 0x10 TLM 0010 0x20

The four low-order bits are reserved for future use and must be 0000.

Note: Although the core Bluetooth data type are defined in the standard as little-endian, Eddystone's multi-value bytes defined in the Service Data are all big-endian.

An example frame type may look like:

Byte offset Value Description Data Type 0 0x02 Length Flags. CSS v5, Part A, § 1.3 1 0x01 Flags data type value 2 0x06 Flags data 3 0x03 Length Complete list of 16-bit Service UUIDs.Ibid. § 1.1 4 0x03 Complete list of 16-bit Service UUIDs data type value 5 0xAA 16-bit Eddystone UUID 6 0xFE ... 7 0x?? Length Service Data. Ibid. § 1.11 8 0x16 Service Data type value 9 0xAA 16-bit Eddystone UUID 10 0xFE ...   With subsequent bytes comprising the frame-specific Service Data. The individual frame types are listed below. Eddystone-UID Eddystone-UID contains an identifier of a beacon. An app installed on the phone can use the identifier to trigger desired action, just like with iBeacon. Whereas the iBeacon identifier is composed of three parts: UUID, major number and minor number, and is 20 bytes long, Eddystone-UID is 16 bytes long and split into two parts: Namespace ID and Instance ID. The Eddystone-UID frame broadcasts an opaque, unique 16-byte Beacon ID composed of a 10-byte namespace ID and a 6-byte instance ID. The Beacon ID may be useful in mapping a device to a record in external storage. The namespace ID may be used to group a particular set of beacons, while the instance ID identifies individual devices in the group. The division of namespace and instance IDs may also be used to optimize BLE scanning strategies, e.g. by filtering only on the namespace.
    Namespace (10 bytes), similar in purpose to iBeacon’s UUID. In iBeacon, you’d usually assign a unique UUID to all of your beacons to easily filter them out from other people’s beacons. In Eddystone-UID, you can do the same with the namespace.
Estimote Beacons broadcasting the Eddystone-UID packet have a default namespace set to:EDD1EBEAC04E5DEFA017. For a custom namespace, the Eddystone specification recommends taking the first 10 bytes of an SHA-1 hash of your domain name. Another suggestion is to simply remove the three middle parts of a Version 4 UUID, e.g.: 8B0CA750-E7A7-4E14-BD99-095477CB3E77 becomes 8B0CA750095477CB3E77.
    Instance (6 bytes), similar in purpose to iBeacon’s major and minor numbers, i.e., to differentiate between your individual beacons. With Estimote Beacons broadcasting Eddystone-UID, instance is represented as a string up to 12 characters long (e.g., 0BDB87539B67).
Eddystone-URL The Eddystone-URL frame broadcasts a URL using a compressed encoding format in order to fit more within the limited advertisement packet. Once decoded, the URL can be used by any client with access to the internet. For example, if an Eddystone-URL beacon were to broadcast the URL, then any client that received this packet could choose to visit that URL. The Eddystone-URL frame forms the backbone of the Physical Web, an effort to enable frictionless discovery of web content relating to one’s surroundings. Whereas with iBeacon or Eddystone-UID there’s a need for an app to take the beacon’s identifier and translate that into certain actions, with Eddystone-URL the data is encoded directly in the beacon’s advertising packet. This means that the use can access content—usually in form of a website—without having the appropriate app installed. The URL could be a regular web page providing relevant information—e.g., a beacon next to a movie poster could broadcast a link to a YouTube trailer. It also could be a dynamic web application, with contextual parameters embedded in the URL—e.g., At this time, you need a Physical Web scanner app (available on iOS and Android) to read the URLs encoded in the Eddystone-URL. Estimote iOS and Android SDK also come with full support for discovering Eddystone-URL beacons, which you can add to your own app. Eddystone-URL incorporates all of the learning from the UriBeacon format from which it evolved. Eddystone-TLM Eddystone-TLM packet is designed to be broadcast by the beacon alongside the “data” packets (i.e., UID and/or URL) for the purposes of fleet management. Nearby Bluetooth-capable devices can read these packets and relay them to the fleet management service—like the Estimote Cloud. This service can then notify the owner of the beacon that, e.g., the battery is running out. The telemetry packet consists of:
    battery voltage, which can be used to estimate the battery level of a beacon, beacon temperature, number of packets sent since the beacon was last powered-up or rebooted, beacon uptime, i.e., time since last power-up or reboot.
  [/fullwidth][one_half last="yes" spacing="yes" center_content="no" hide_on_mobile="no" background_color="" background_image="" background_repeat="no-repeat" background_position="left top" border_size="0px" border_color="" border_style="" padding="" margin_top="" margin_bottom="" animation_type="" animation_direction="" animation_speed="0.1" class="" id=""][/one_half]



Subscribe to our newsletter and know all that’s happening at Cabot.