Chrome 57 has launched, and with it in-browser support for the Physical Web. Now, when a user goes to conduct a search or enter a web URL, any nearby Physical Web addresses will appear just below the address bar as seen in the above graphic.
It adds another piece to the proximity puzzle – allowing your browser to show nearby URLs when you go to enter a Web URL or go to conduct a search.
Use Cases for Chrome URLs
Being able to see nearby Physical Web URLs in your browser suggests some interesting use cases/value propositions:
Closing the Gap on Physical Web Objects – in the world of the Physical Web you walk up to a “thing” and use it. In general, their use case is for that “thing” to include a Physical Web icon. You need to know that the object has a URL attached to it. This is usually accomplished through physical-world icons/signage. You then need to know to “pull down” on a notification tray to see it.
By adding Physical Web URLs to your browser search/address bar, there’s another path to making sure users will more easily be able to “see” that URL.
Show-rooming – Retailers still struggle with ‘show-rooming’ – where users will be shopping, say, for a fridge and go online to compare prices when in the store. By attaching a physical web beacon to the fridge, the retailer has a last chance to catch the user’s attention with a link of their own.
In the Home – This is, perhaps, where beacons can truly start to merge over with the connected home. Device makers (say, the Nest thermostat) can embed a Physical Web broadcast. Now, your thermostat, connected TV or other device can offer up a manual, support hotline or other information as an available link in your browser – and possibly bypass the need for a custom app.
Bluetooth in the Browser
Things start to get really interesting when you take into account the fact that Chrome also supports Bluetooth connections. By allowing Chrome to connect to nearby Bluetooth devices, you can create use cases where a Physical Web signal leads to a web URL. The web URL leads to a page with support for Bluetooth connectivity.
(We should note that Bluetooth proximity and Bluetooth connectivity are two entirely different things!)
We can envision use cases where you approach a fitness machine in a local gym, it has a Physical Web logo, a Physical Web URL shows up when you search in Chrome, and the web page it takes you to can connect to the machine and read out heart rate or other information.
Have you engaged yet with a Physical Web URL via Chrome? What use cases do you think we’ll see? And do you think the Physical Web icon will be a driver of adoption, or will we see other ways to promote these new features?
Drop a comment below, or pop me a note on Twitter.
Content Creator or “Business Builder”? Drop Me a Line
On a side note, we’ve been partnering with content creators, publishers and entrepreneurs of all stripes. We’ve been building out tools to bring proximity channels to new markets. If you’d be interested in learning more, don’t hesitate to drop me a note – doug (at) fidgets.net . Our mission is to help content creators, publishers, entrepreneurs and companies to build new revenue streams on the Internet of Things.
iBeacon has been quite a buzzword since the release of iOS 7 when Apple enabled all their iPhones since the 4S with this new BLE technology.
The iBeacon is simply a protocol that takes advantage of the new Bluetooth Low Energy technologies. It has been easy for companies, aside from Apple, to emulate similar protocols such as estimote or AltBeacon. As a result, we thought iBeacon and PubNub could fit together in some pretty cool ways.
In this article, we will explain how the iBeacon protocol works by taking a closer look at how the emitted data is actually structured. We will move onto how to use the iOS sdk to detect and emit beacons. Finally we will try to see if we can use other protocols on iOS devices.
This Data can be up to 31 bytes. If we create a smaller scan response, the remaining bytes will be filled with as many 0s.
The scan response is divided into what are called AD structures. They are sequences of bytes of various size, with a predefined structure that goes as follows:
The first byte represents the number of bytes left to the end of the AD structure. This allows a receiver of this structure to know when it ends and when a new AD structure starts.
The second byte is the ID of an AD structure type.
The rest of the bytes are data that is structured in a predefined way depending on what AD type was defined by the previous byte.
That’s all there is to it. Just a succession of AD structures.
Most beacon protocols have only 2 AD structures, which are as follows.
The first one has 3 bytes:
The first byte will be: 0x02 because we only count the following bytes.
The second byte is: 0x01 which indicates we have a “Flag” AD type.
The last byte represents theses flags. These flags express whether the emitting device is, in “Limited Discoverable Mode”, “General Discoverable Mode”, etc… The byte is computed the following way:
The 5 flags are represented by the first 5 bits of a byte. The value of these bits defines whether the flag is ON or OFF. The binary number is then written as a hexadecimal value which will be advertised. An example may clear things up:
LE Limited Discoverable Mode
LE General Discoverable Mode
Simultaneous LE and BR/EDR to same Device Capable (controller)
Simultaneous LE and BR/EDR to same Device Capable (host)
The resulting binary value hence becomes: b00011010 Converted into a hex, we get: 0x1A
That’s all there is to the first AD structure! Let’s look into the second one, which contains most of the information we need!
The second structure can be of a different size according to the protocol. Let’s look at the detected scan response emitted by an iPhone.
First byte is 0x1A (26 in hexadecimal).
The next byte is always 0xFF which means we have a “Manufacturer Specific” type of AD structure.
As a result, the 2 following bytes represent the company identifier as defined on bluetooth.org. For an iOS device, the manufacturer is “Apple Inc.” whose company ID is 76. In hexadecimal value, this is equal 0x004C. The ID, written as little endian, takes up 2 bytes. Here it will be 0x04C 0x00 in this order.
The rest is Manufacturer specific data.
For the iBeacon protocol, the 2 first bytes of the manufacturer specific data are always 0x02 0x15. The next 16 bytes are a UUID representing the advertiser’s organizational unit and the 4 following bytes are going to be the major and the minor. They are 2 bytes long numbers.
There is a final byte at the end of the data structure called the TX Power, which represents the device’s signal reference intensity a meter away from it. This value is held into a single byte which is the two’s complement of the signal’s intensity in dB.
Computing the distance to a Beacon
When a scan response is detected by a device, it also determines the intensity of the received signal. Hence the iBeacon protocol uses the reference value held in the TX Power byte and compares it to the intensity of the signal effectively received. This allows iBeacons to compute an estimation of the distance to the emitting beacon. This is a great quality of iBeacons, but note that the intensity of the signal depends vastly on existing obstacles or simply on the geometry of the room. As a result Apple does not recommend to use iBeacons to determine precise locations.
The algorithm used to compute the distance is not open-source, although others have tried to emulate matching ones.
How to Use Apple’s SDK for iBeacon
Emitting or detecting iBeacon data is organized around iBeacon regions.
These regions are instantiated with optional initial values such as the UUID, major or minor. In the case of detecting an iBeacon, this region object defines what type of beacon scan response should be detected. For example, if you provide a UUID, only the beacons with matching UUIDs will be detected, regardless of the major and minor. If you also provide these values, you’ll detect only beacons matching all three of these values.
When emitting an iBeacon signal, the region object based on the values of the UUID, major and minor generates the data structure to be advertised.
As you may have guessed, this makes the iOS SDK very simple to use! For more detailed examples, check out our beacon emitter and beacon detector tutorials.
However, it also makes things much more difficult when you are trying to use a protocol different from iBeacon! Let’s look into that immediately.
Using Apple’s SDK for AltBeacon or Estimote
We have seen how complicated the scan response can be, and how Apple simplified the SDK so that we just need to enter the UUID, major and minor to set it up. However, with other beacon protocols, the scan response has a different structure which Apple makes hard for us to tweak.
Detecting other beacons
When detecting iBeacons, the locationManager:didRangeBeacons:InRegion: method is called on the event of a detected signal. However, this is very specific to iBeacons. When detecting another BLE signal, you must not use a CLLocationManager instance, but a CBPeripheralManager which detects ANY BLE advertisement EXCEPT iBeacons, which will be blocked.
The callback that will be triggered upon detection is centralManager:didDiscoverPeripheral:advertisementData:RSSI: . The advertisement data that is returned is a dictionary holding 2 objects; one for each data structure of the scan response. Here is a sample response from an AltBeacon.
The top element represents the first, three bytes long, “Flag” data structure. The second one represents the manufacturer specific data following the bytes describing the size and type of the data structure.
This is good news for us, and means we can detect any beacon information!
Emitting another beacon
We have found things are much trickier when it comes to advertising custom beacon scan responses. We can try to build an NSDictionnary similar to the one detected and try to advertise it using the startAdvertising method.
So there you have it! We went through apple’s iBeacon protocol, looked at how we could detect other beacons and apple’s restrictions to advertising data. We have some working examples and tutorials to build an iBeacon app on Swift – check out our beacon emitter and beacon detector tutorials, which allow you to get the best out of iBeacons by establishing a two-way communication which beacons aren’t usually capable of. The reason why we think it’s great is that we use PubNub to enhance beacons’ capabilities while still keeping their low energy consumption asset! Sweet, right?