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.
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.
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
To celebrate our 6th anniversary, we designed and trademarked a new logo to celebrate our past successes and symbolise the future of Thesis. At Thesis, we pride ourselves on helping shape our customers’ future. Our work helps our customers extend their technological advantage over the competition and opens up new growth opportunities. To illustrate this, […]
Here we show the waveform of a zero-voltage switching (ZVS) inductive heating circuit and the thermal profile in operation. A typical buck regulator DC-DC is challenging to design when there is a significant voltage difference between the input and the output voltages. A significant voltage difference typically increases switching losses and limits the device’s switching […]
In Thesis, we develop products using various MCUs – Cypress PSoC4/5/6, STM32, Nordic nRF, Arduino, and PIC. In the past, we did that because of various client requirements and/or outcomes from our in-depth engineering evaluation. However, we do it nowadays because we aim to make our product design as MCU agnostic as possible to circumvent […]