mbed Blog

Understanding the different types of BLE Beacons

Bluetooth Low Energy (BLE) Beacons - there are several types available (URIBeacon, AltBeacon, iBeacon), each with their own standards and advantages. Some are open and free, some are closed and cost money. This article will cover the three main types of beacons available, their advantages, disadvantages, derivatives and some low level implementation details on how beacons work. Make sure to check out all the mbed enabled BLE platforms that can be used as BLE Beacons.


Bluetooth Low Energy (BLE) has the ability to exchange data in one of two states: connected and advertising modes. Connected mode uses the Generic Attribute (GATT) layer to transfer data in a one-to-one connection. Advertising mode uses the Generic Access Profile (GAP) layer to broadcast data out to anyone who is listening. Advertising mode is a one-to-many transfer and has no guarantees about data coherence.

BLE Beacons take advantage of the GAP advertising mode to broadcast data out in periodic, specially formatted advertising packets. Each type of beacon uses a custom specification to partition up the advertising data, giving it meaning. I'm going to take a look at the three existing types of beacons, URI Beacons, iBeacons, and AltBeacons. All beacon types are supported on the mbed BLE team page and have example projects with documentation if you would like to try them out.


Apple’s iBeacon was the first BLE Beacon technology to come out, so most beacons take inspiration from the iBeacon data format. iBeacons are enabled in several of the Apple SDKs and can be read and broadcast from any BLE-enabled iDevice. The iBeacon is a proprietary, closed standard. There is a large ecosystem around iBeacons and a large pool of resources for developers, but you have to be part of Apple’s developer community.

Data Spec

iBeacons broadcast four pieces of information:

  1. A UUID that identifies the beacon.
  2. A Major number identifying a subset of beacons within a large group.
  3. A Minor number identifying a specific beacon.
  4. A TX power level in 2's compliment, indicating the signal strength one meter from the device. This number must be calibrated for each device by the user or manufacturer.

A scanning application reads the UUID, major number and minor number and references them against a database to get information about the beacon; the beacon itself carries no descriptive information - it requires this external database to be useful. The TX power field is used with the measured signal strength to determine how far away the beacon is from the smart phone. Please note that TxPower must be calibrated on a beacon-by-beacon basis by the user to be accurate.


The iBeacon Prefix contains the hex data : 0x0201061AFF004C0215. This breaks down as follows:

  • 0x020106 defines the advertising packet as BLE General Discoverable and BR/EDR high-speed incompatible. Effectively it says this is only broadcasting, not connecting.
  • 0x1AFF says the following data is 26 bytes long and is Manufacturer Specific Data.
  • 0x004C is Apple’s Bluetooth Sig ID and is the part of this spec that makes it Apple-dependent.
  • 0x02 is a secondary ID that denotes a proximity beacon, which is used by all iBeacons.
  • 0x15 defines the remaining length to be 21 bytes (16+2+2+1).

The remaining fields are rather self explanatory. The proximity UUID is a standard 16byte/128bit BLE UUID and is typically unique to a company. The major and minor numbers are used to denote assets within that UUID; common uses are major numbers being stores (so 65,536 stores possible) with minor numbers being individual tags within the stores (again 65,536 possible tags per store).


  1. A coffee shop has iBeacons on a rack of coffee and by a register. When a customer walks in and gets close enough their coffee shop, a smartphone app sees the iBeacon, searches the coffee shop’s iBeacon database, recognizes the iBeacon as belonging to coffeeShop X, then sees there is a valid coupon for ground coffee, and notifies the user of the coupon.
  2. iDevices can broadcast an iBeacon. This can be used to automate check-ins at events and track movements throughout venues.
  3. See embedded device code on the mbed iBeacon device page.

This is an example of how to set up an iBeacon device to broadcast a UUID with major and minor numbers using the mbed BLE_API. Please note the tx power level should be user calibrated to the measurement as measured 1meter from the device.


#include "mbed.h"
#include "iBeaconService.h"
BLEDevice ble;
const uint8_t uuid[] = {0xE2, 0x0A, 0x39, 0xF4, 0x73, 0xF5, 0x4B, 0xC4,     // 16Byte UUID
                        0xA1, 0x2F, 0x17, 0xD1, 0xAD, 0x07, 0xA9, 0x61
uint16_t majorNumber = 1122;  // 2 byte major number
uint16_t minorNumber = 3344;  // 2 byte minor number
uint16_t txPower = 0xC8;      // 1 byte tx power level
int main(void){
    iBeaconService ibeacon(ble, uuid, majorNumber, minorNumber, txPower);


iBeacons are cool, widely supported, and because they're an Apple product everyone is working with them and the ecosystem is as robust as possible. The only limitation is that a database is required to give meaning to the iBeacon data. Without a database the UUIDs are meaningless. You can find the mbed iBeacon example here.


A popular derivative is to replace the 0x004C code with a different company code, for example the 0x0059 that is assigned to Nordic Semiconductor. The nRF Beacon application and nrf51822 Bluetooth Smart Beacon Kit are examples of this.

Some companies provide examples that don't explicitly use the iBeacon spec.


AltBeacons is an open-spec, free beacon design provided by Radius Networks. It looks to be gaining some momentum. The AltBeacon spec seems to be a direct response to the closed source iBeacon spec that Apple is using; it covers the same functionality that an iBeacon has but is not company-specific. That said, it is not as widely supported (yet).

It is worth noting that while iBeacons have 20 of 27 bytes available for user data (UUID+Major+Minor) the AltBeacons have 25 of 28 bytes available (MFG ID, BeaconCode, BeaconID, MFG RSVD). This means there can be more data delivered per message.

Data Spec

The AltBeacon spec is 28bytes (26B are user modifiable). The first two bytes of the AltBeacon are not user modifiable but are set by the BLE stack. ADV Length is 0x1B and ADV Type is 0xFF; these will specify the length of the advertising data packet and the type as manufacturing data respectively. After that everything is up to the user and can be shoved into an advertising manufacturer data field. Note that in most cases the MFG ID will correlate to the Bluetooth Sig assigned numbers document.



The same examples that are used for iBeacons apply to AltBeacons, with the following modifications:

  1. The ability to have different Manufacturer IDs.
  2. The ability to have different Beacon codes.
  3. The one byte of reserved data at the end that holds specific manufacturer information.

With AltBeacon it becomes possible to have application-specific UUIDs rather than company-specific, giving the ability to change the company ID instead. While nothing is currently taking advantage of this, I can imagine beacons that broadcast the UUID for a beacon service, say for a temperature service, which would then provide the manufacturing company info and the temperature, in this way providing a temperature value that anyone who walks by can view.

Here is an example of how to program an mbed enabled BLE platform to behave as an AltBeacon.


#include "mbed.h"
#include "AltBeaconService.h"
BLEDevice ble;
uint8_t beaconID[] = {  0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,     // 16B of UUID + 4B subdivided as needed.
                        0x10,0x11,0x12,0x13,0x14,0x15,0x00,0x01,0x00,0x02 };
uint16_t manufacturerID = 0x5900; //Nordic SIG ID
int8_t rssi = -122;
int main(void){
    AltBeaconService altbeacon(ble, manufacturerID, beaconID, rssi); // Add AltBeacon service to BLE object


AltBeacons have great possibilities. They make good use of the space they have, are more or less backwards compatible with iBeacons, and are open source. That said it is a very new spec, almost no one is using it yet, and it has an uphill battle to fight against the iBeacons’ market penetration. In time I think, more and more people will use AltBeacons simply because they can carry more data and have a wider use case - a cherry on the open-spec cake. You can find the mbed AltBeacon example code here.

URIBeacon (pronounced YUR-ee-BEE-kun)

URIBeacons are a Google project that is part of their Physical Web initiative. The project seems to be under heavy development and likely to improve greatly over time. Right now URIBeacons are like iBeacons with a URL in the payload - this makes them very similar to QR codes that operate over BLE. They give short links to the internet via BLE advertising packets. This enables things like a movie poster that directs you to the movie’s website, or promotional codes at a coffee shop that direct you to a webpage with a coupon you can show the cashier.

It is worth noting that unlike iBeacons and AltBeacons, which are used primarily as “set up once and leave running forever”, URIBeacons have a configuration service; they are meant to be updated with new information and change over time. Also, a database is required to give meaning to the data in iBeacons and AltBeacons, whereas with URIBeacons the whole internet is the database.

Data Spec

The URIBeacon spec uses 28B of the 31B available in an advertising packet. Of these 28 bytes,19 are used to encode the URI being sent. The prefix ('www.','http://', etc) and suffix ('.org/','.com/', etc) are each encoded to a single byte. This saves space overhead, but has the unfortunate side effect of limiting what domains can be short-coded to those supported by the official specification. Currently only www addresses (both http and https) and UUIDs can be transmitted via a URIBeacon. Things like ssh: and gopher: are not supported. The suffix is also encoded to a single byte, but only if it is one of the well defined ones. This means a url of 'http://www.google.com' would be encoded down to eight bytes, one for 'http://www.', six for 'google' and one for '.com'. For a full list of supported prefixes and suffixes you should see the official spec. If you use the supported prefixes, it is possible to have a URL of 17 characters (with one byte for the prefix and one byte for the suffix). It is worth noting that the URIBeacons are meant to be used with URL shortening services like goo.gl, bit.ly, tin.ly which will shorten any long URL to eight to ten bytes.



  1. Coupon code: A business has a URIBeacon that broadcasts a link to a coupon on the website. Customers follow the link and show the coupon to the cashier. Because the URIBeacon can be updated, it is possible to enable time-sensitive links. For example the coupons can show up only at a certain time of day.
  2. Interactivity: For interactive things, it is possible to have users follow a URIBeacon link to a webpage where they could control a third party service. For example, lights on an internet-connected display. In this case, the URIBeacons serve as a way to get users to the control webpage. This could also apply to interactive historical markers, or anything that could be enhanced by having web content attached to it.
  3. Games: Because URIBeacons are modifiable, they could be left open so anyone could modify them. Therefore lending an element of community participation or gamifying the experience to see who can control how many beacons.

Here is an example of how to program an mbed enabled BLE platform to behave as a URIBeacon. Notice that the URIBeacon has the ability to load its data from persistant storage, making it possible to update over the air and change the URI it is broadcasting.


#include "mbed.h"
#include "URIBeaconConfigService.h"
int main(void){
    URIBeaconConfigService::Params_t params;
    bool fetchedFromPersistentStorage = loadURIBeaconConfigParams(&params);
    URIBeaconConfigService(ble, params, !fetchedFromPersistentStorage, "http://mbed.org", defaultAdvPowerLevels);


URIBeacons are a cool piece of tech. The fact that they don't rely on an external database to give meaning to the data they carry like iBeacons and AltBeacons dos mean they can be more useful with less overhead. At the moment, they are essentially BLE QR codes: just broadcasting short links to the internet and some other forms of data. However, I think that the future of URIBeacons is even more interesting. The possibility of sending data through GET requests using the BLE IP service (or BLIP, as I like to call it) and opening a bi-directional pipe of information from the URIBeacon to the internet enables using a web page to control the beacon. This means there will be no need for a special smartphone app for each application; just have the URIBeacon point to a website that controls it, and use a smartphone’s native browser to control the URIBeacon. I think this is the most interesting thing about URIBeacons is not what they do, but what they can do: be an enabler for a truly pervasive IoT ecosystem. You can find the mbed URIBeacon example code here.


Beacons are handy pieces of tech. The iBeacon and AltBeacon are very similar, and seem to be designed to be the same thing. The only differences are that iBecaons are closed source and widely supported, whereas AltBeacons are open source and still not widely used. Both broadcast a UUID and a couple of bytes of data specific to the device. iBeacons have slightly less space than AltBeacons and are more heavily regulated, but ultimately both are one-way communication methods, and both require an external database and a smartphone app (or smartphone background service) to be useful.

URIBeacons are a different animal entirely. They broadcast data across the same channel as the other beacons, but that is where the similarity ends. URIBeacons hand out links to the internet. This enables them to link to more relevant content, and possibly context-aware content. In addition, URIBeacons are meant to be easily modifiable. Further, with the adoption of the BLE IP standard, it may be possible for a URIBeacon to talk to the internet through the receiving phone, meaning the URIBeacons can have a two-way communication channel. I believe URIBeacons are already the most useful of the beacon lot, and will become even more useful as the spec continues to evolve.


iBeacons and AltBeacons are almost the same thing: they broadcast a UUID from the beacon itself and use external databases to give beacons meaning. iBeacons are closed source, Apple-branded, and widely used; AltBeacons are open source and provide more data fields to use, but few people use them yet. URI Beacons are different: they don't require an external database, instead they use web links to either link to data directly or, in the future, possibly as a two-way communication method. That said there is a heavier app-side workload to URIBeacons as compared with iBeacons or AltBeacons. iBeacons are currently the most widely used, but I think URIBeacons have a great deal of untapped potentia and will become a driving force of IoT in the future.

ARM mbed at SXSW Create 2015

This last weekend the Austin team spent the weekend at SXSW Create. Create is a part of the SXSW Interactive Festival, where innovators and technology enthusiasts come together to showcase their latest technologies from 3D printers to digital lightsabers.

We had a great time at the event and met some amazing innovators! Below are some of the photos from our booth.

SXSW can be an exhausting conference and attendees were flocking to the free espresso from our ARM mbed-enabled Coffee Machine Tracking System.


Freescale’s Nerfinator that uses the mbed enabled FRDM-K64F was a big hit! We were dogging darts all weekend!


We also setup programing stations for attendees to try out their first 'blinky' program.


Huge thank you to our Partner Sponsors who graciously donated development boards and kits for giveaways to lucky attendees!


Last but certainly not least, Silicon Labs was demonstrating at their booth the new low-power APIs that were announced just before the event.

Silicon Labs & Power Management APIs for mbed

We are excited to announce our collaboration with Silicon Labs to bring power management APIs to mbed. The new APIs will enable mbed developers to optimize their mbed-enabled designs for the utmost energy efficiency and longer battery life.


One major benefit of the power management APIs is the ability to reduce system-level energy consumption by automatically determining and enabling the optimal sleep mode based on the MCU peripherals in use. For developers this is can help to significantly reduce the energy consumption of their IoT applications with minimal effort.

The mbed-enabled EFM32 Gecko starter kits are planned to be released in April of this year. Silicon Labs’ initial platforms supporting mbed will include 4 starter kits (Wonder Gecko, Leopard Gecko, Giant Gecko and Zero Gecko). Developers with existing EFM32 kits will be able to mbed-enable their hardware through a simple software update.

For more information check out this post by Steven Cooreman at Silicon Labs, as he discusses a real-world scenario where using theses APIs can improve current consumption.

Additional information can also be found here: http://www.silabs.com/mbed.

Activity Round Up – March 2015

It is that time again, we have rounded up the updates and news from the first few months of 2015. If you missed the last round up, you can find it here.


Upcoming Events:

This weekend (March 13-15) we will be exhibiting at SXSW Create in Austin, TX. If you haven’t heard of SXSW Create, it is a part of the SXSW Interactive Festival, this event brings together innovators and technology enthusiasts to showcase the disruptive solutions that are shaping our future. At our booth we will be showing how to get started with mbed, and mbed-enabled demo products live in actions. Not to mention we will have the mbed-powered Freescale Nerfinator onsite!

Just before SXSW starts on Tuesday March 10, Austin Blackstone, one of our applications engineers will be leading the third session in his mbed MeetUp Series. This MeetUp will take place at the Austin Capital Factory at 7pm. Find out more information and RSVP here.

Past Events:

The last two weeks the mbed team has been working hard at Embedded World and Mobile World Congress. The best part is we were honored with the Best in Show Award at Embedded World! Check out our round up and videos here.


Also towards the middle of February, KDDI hosted a Firefox OS WoT (Web of Things) Hackathon in Tokyo. Over 70 participants came together to collaborate on web technology and to learn how to develop with mbed. Watarai-san, has created a great write-up of the event here.



We have had a lot to celebrate so far this year from reaching over 100,000 developers on mbed, the release of the IoT Starter Kit – Ethernet Edition that was developed in collaboration with IBM, to the mbed Device Server 2.3 release.


We have recently published some useful tutorial videos on our YouTube channel. Find resources getting started with mbed, troubleshoot problems, etc. Have a suggestion for a video you would like to see, leave us a note at the bottom of this blog and/or on the YouTube channel.

Also is you missed the joint webinar with CSR webinar that discusses how you can use mbed and CSR shields to create Internet of Things (IoT) devices, you can catch the recording here.


New platforms:

Last but not least we have had a number of new components added from sensors, internet connectivity to the new Sparkfun mbed Starter kit.

Have a cool project you want to share? Post it to our http://hackster.io/mbed page!

From Embedded World to Mobile World Congress

The mbed Team has been busy the last few weeks getting ready for Embedded World (EW) in Nuremberg, Germany and now we are looking forward to Mobile World Congress (MWC) in Barcelona, Spain this coming week. There has been much to celebrate from the collaboration with IBM to announce the IoT Starter Kit – Ethernet Edition to the ARM mbed Device Server 2.3 release.

At EW we announced the IoT Starter Kit – Ethernet Edition that was developed jointly with IBM. This kit is intended to help developers build devices that connect to the IBM cloud (IBM BlueMix platform) and further build out the ecosystem of IoT. Additionally, at EW we showcased two demos; our ARM mbed Bluetooth Low Energy solutions and the Thread stack running with mbed OS. Check out the videos below to see the demos in action.

At MWC this coming week, we will be featuring our mbed Device Server. One will be showing our Smart City demo which was developed with wot.io, MultiTech and Stream Technologies. In this demo you will see a real life scenario where delivery vehicles are tracked through London and augmented with real-time traffic information provided by London Open Data and traffic cameras. Not to be missed, we will be measuring many live statistics from the ARM booth (temperature, average height of attendees, noise levels, etc.) to showcase how mbed enabled devices can collect live data from the edge of a network and feed it to an ARM powered server running the mbed Device Server. Be sure to stop by our stand (Hall 6, Stand 6C10) to see both demos in action, if at MWC.

Last by certainly not least, we have released the ARM mbed Device Server 2.3. This release adds more key functionality to allow us to better serve the needs of mbed Device Server users. To find out more, see Neil Jackson’s blog post here.