Thesis Pte Ltd

icon
icon

One thesis

Copyright © 

2025

 Thesis Pte. Ltd. All Rights Reserved

OFFICE

34 Boon Leat Terrace #04-09A Singapore 119866

GET IN TOUCH

contact@onethesis.com
Thesis logo
icon
Thesis logo
icon
Chat with us

One thesis

Copyright © 

2025

 Thesis Pte. Ltd. All Rights Reserved

Tag: ibeacon

Categories
News Tech bites

Intro to Eddystone – Google latest proximity beacon protocol

Eddystone

During the height of iBeacon, google released a similar and more powerful proximity beacon protocol called EddystoneTM in July 2015. The protocol was designed to be platform agnostic and more flexible in the data that can be broadcast. The key features were designed to make it a better platform than the iBeacon protocol. App developers can find more information on the available API here.

However flexible google wishes to design the EddystoneTM to be, they have to keep in mind the space limit of a BLE broadcasting data. Instead of trying to cram all sort of data within the data limit, google overcame the problem by introducing “frames”. A total of 3 different data frames was designed into the EddystoneTM protocol- namely UID, ULR and TLM. Each frame was designed to carry different set of information to fulfill the broadcasting need of most proximity beacon.

UID

The most basic of the EddystoneTM protocol with frame specification that is very similar to the iBeacon’s. In this frame, user will have to indicate the unique ID of the device, the instance ID and the transmission power.  The unique ID is also known as namespace, which is a 10bytes data. User can generate it using an online UUID generator. The instance ID works the same as the Major and Minor ID from iBeacon. Finally, the transmission power, aka ranging data. To calibrate this – “Tx power is the received power at 0 meters measured in dBm. The value may range from -100 dBm to +20 dBm at a resolution of 1 dBm (source)

Note to developers: the best way to determine the precise value to put into this field is to measure the actual output of your beacon from 1 meter away and then add 41 dBm to that. 41dBm is the signal loss that occurs over 1 meter.”

Unlike the iBeacon’s transmission power which was supposed to be measured at 1m range, EddystoneTM requires the transmission power to be measured at 0m instead. However, noting from the calibration information provided by google, the transmission is supposed to be measured at 1m range and you add 41dBm to account for the signal loss over 1 meter. The result is the transmission power at 0m.

URL

This frame is designed to house an URL for your proximity beacon to broadcast. Do make sure to indicate “0x10” in the Frame Type byte, else the EddystoneTM APP API will not recognize the frame properly. Following that is the transmission power, which can be calibrated with the same procedure provided in the above section. The URL scheme indicate which html prefix to be appended to the decoded URL and currently, there are 4 options to choose from:

Finally, it’s the encoded URL. For example, if I wish to broadcast “onethesis.com”, my encoded URL will looks like “0x6f6e6574686573697300” (with padding: onethesis = 6f 6e 65 74 68 65 73 69 73), note that the data is entirely in hexidecimal). The string is ended with the URL with “0x00” which will be decoded as “.com/”. A full list of the ending character is listed below:

TLM

This frame is also known as the telemetry frame. It holds device specific information which could be useful for debugging or data-logging purpose. To start with, user must indicates “0x20” in the Frame type and followed by the TLM version. The subsequent data are device specific information like battery voltage, Beacon temperature, Advertising PDU count (ADV_CNT) and Time since power-on or reboot (SEC_CNT).

Battery voltage is in 1mV per bit resolution. Beacon temperature is in degrees Celsius expressed in 8.8 fixed point representation. ADV_CNT counts the number of advertising frame that has been sent since power-on or reboot. SEC_CNT is a 0.1 second resolution counter. It is not necessary to provide all of the data. User can choose to obscure certain data by simply not updating the values.

One important note about this frame is that it cannot be a standalone frame in the EddystoneTM protocol. It should always be used in conjunction with the UID or URL frame.

Resources

As usual, for firmware developer, Cypress Ez-BLE pioneer kit provides easy access to learning this protocol and Cypress has provided some examples for their users as well (source).

Build the Future

Categories
News Tech bites

Bluetooth Low Energy – iBeacon basics

board

iBeacon is a protocol developed by Apple Inc. in 2013. In short, iBeacon technology allows mobile applications to understand their position on a micro-local scale, and deliver location-specific contextual content to users based on their proximity. The underlying communication technology is Bluetooth Low Energy (BLE). The protocol takes advantage of the BLE technology to bring about very low-powered broadcasting devices that could alert users of its presence. By adding certain parameters to the advertising data packet, the broadcasting device can be used to transmit location specific information. The most common use case of such iBeacon devices would be in the brick and mortar shops, where business owners want to transmit location-specific promotions or to track their shoppers who have their shop-specific app installed on their smartphones. Of course, privacy is always a running concern for the user tracking implementation but with the latest mobile OS, users can prevent their privacy from being breached. The caveat is that the users have to be tech-savvy enough to know how to do that.

Several development projects that we’ve been involved in are requests for iBeacon-like attributes – implementing similar protocol but with varying levels of modifications. The good news is that you can implement the iBeacon on your own. There will be another article released soon, where we talk about EddystoneTM – Google’s latest beacon protocol. Stay tuned for that.

For those really curious about the type of projects we have done using iBeacon and other Beacon protocols, I will just say that there are various combinations but mostly it boils down to users’ behavioural monitoring based on location. We focused on product development, so our clients could remain focused on their customer’s buy-in and marketing.

iBeacon advertising protocol

iBeacon is a one-way transmitting protocol. You have to set the device to be non-connectable and always stay in advertising mode. The reason for non-connectable should be a no-brainer because if you are connected, BLE will not advertise. To save power, you will want to broadcast in a longer time interval. You can try a 100ms broadcasting interval and slowly fine-tune it from there.

ibeacon-bytes

The above illustration describes the iBeacon protocol in the simplest way possible. All BLE SDKs should have provision to modify the advertising data, so make sure to arrange your advertising data as per the protocol or the iBeacon will not work. To officially work with iBeacon, you will need to license the technology from Apple. You can read Apple’s beginner document for more information (source).

Moving on to the more technical aspect.

The 4 most important components of this protocol are:

1. Proximity UUID
2. Major
3. Minor
4. Measured power

Proximity UUID

This is the unique identifier that separates your device from the hundreds or thousands of iBeacon devices out there. Your app will have to white-list your UUIDs in order to prevent reading from the wrong device. By whitelisting, I mean your app should only read from devices with your authorized UUID. There are multiple avenues to generate UUID but one of the most common sources can be found here.

If you are just testing out iBeacon using the AirLocate sample code located on the Apple Developer site (https://developer.apple.com/ibeacon/), you will need to use their predefined UUIDs

1. E2C56DB5-DFFB-48D2-B060-D0F5A71096E0

2. 5A4BCFCE-174E-4BAC-A814-092E77F6B7E5

3. 74278BDA-B644-4520-8F0C-720EAF059935

4. 112ebb9d-b8c9-4abd-9eb3-43578bf86a41

5. 22a17b43-552a-4482-865f-597d4c10bacc

6. 33d8e127-4e58-485b-bee7-266526d8ecb2

7. 44f506a4-b778-4c4e-8522-157aac0efabd

8. 552452fe-f374-47c4-bfad-9ea4165e1bd9

Major/Minor

To define the location of the device, you declare the major and minor values. An example usage would be in a multi-storied departmental store, you will use major to define the level and minor to define the particular section within the level. Since it is a 2 bytes parameter for each value, you can define up to 65536 unique major locations and 65536 unique minor locations. If you do the sum, that’s a lot of unique locations.

Measured power

Another aspect of the iBeacon is that it can tell how far the user is away from the iBeacon device. However, to achieve that, you need to calibrate the device. The way to calibrate is fairly straightforward. You need a mobile app that can measure RSSI, and you use that to measure the RSSI at a 1m distance from your device. I would also recommend you to do the calibration in multiple directions and compute the average as the measured power. Bear in mind that the measurement is in dBm.

The best time to calibrate is on actual deployment. Laboratory or factory calibration will usually net the best results but it doesn’t reflect your actual environment as there are many factors to consider when it comes to RF, e.g. Fresnel zone, Dead zone and etc…

Surprise

A little surprise to some but you can actually indicate the device’s battery life in the advertising protocol. It is a little more advanced so I wouldn’t recommend it to beginners. The reason why you can do that is that Apple protocol does not use up all of the available advertising bytes for BLE; you can squeeze in 1 more byte right after measured power. However, since it’s only 0-15, you will need to include custom firmware code within your device to digitize the battery level into 16 levels.

Go forth and code away!