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
Introduction We are thrilled to announce that THESIS has entered into a partnership with DesignRush, a leading agency directory that connects brands with top full-service agencies, web design companies, digital marketing firms, and top technology companies. This exciting collaboration aims to combine THESIS’s expertise in UI/UX, Software and Mobile app development with Design Rush‘s extensive […]
Introduction The advent of embedded camera solutions stands as a defining achievement within the domain of contemporary electronics engineering. This convergence of hardware and software proficiency epitomizes the seamless amalgamation of imaging technology into an array of devices and systems. Ranging from handheld gadgets like smartphones to the sophisticated realms of industrial machinery and automotive […]
Openearable [https://open-earable.teco.edu/] is a state-of-the-art open-source “earable” platform using the Arduino Nano 33 BLE Sense ecosystem. It offers a flexible and modular approach to building “earable” devices, allowing developers to customize the device to their preferences effortlessly. The core module of the platform is based on the Arduino Nano 33 BLE Sense board, equipped with […]
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.
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:
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.
