Beacon Apps on Android 6 Update

By Aaron Kromer

We’ve previously discussed how to prepare your beacon-aware app to continue to function by complying with important changes on Android 6. Now that Android 6 has been generally available for several months we’ve learned a few more things. This covers some extremely important beacon-related behavior you need to know.

Location Services

You’re probably already aware that you need Location Services runtime permissions on Android 6. What you may not realize is that Location Services must also be ON.

If the service is OFF the logs will continue to show successful scans. However, you won’t see it find any beacons and your registered callbacks will sit idle. Our understanding is that this is the intended behavior for Android 6+ and is here to stay.

Additionally, you may have noticed a new Bluetooth scanning option under the new Scanning settings for your device’s Location Services. This setting currently has no effect on the general BLE scanning available to applications. So even with this setting ON if Location Services is OFF beacons will not be detected.

Foreground vs Background Scanning

There are some additional subtleties with foreground and background scanning. These revolve around whether your app is targeting API 23 or attempting to leverage the older permission model by targeting API 22 or lower.

The short answer is if you target API 22 or lower you can perform foreground scanning while Location Services is OFF. However, background scanning will not work. Background scanning will always require Location Services to be ON with Android 6+.

Location Services State for Scanning on Android 6

Targeting API Foreground Scanning Background Scanning

API 23+ ON ON

API < 23 ON or OFF ON

Why the Change?

Based on responses on the Android issue tracker this is to better protect user privacy. Part of the BLE scan reports the MAC address of the BLE device. It is theoretically possible that someone could create a map of beacon MAC addresses to determine a user’s geographical location.

This brings Android more in-line with how iOS works. Each operation system now views beacon detection as part of Location Services. They each require appropriate service authorization prior to use and both Bluetooth and Locations Services need to be turned on.

Announcing Physical Web Display for Chrome OS

By James Nebeker

Screen Shot 2018-11-20 at 11.47.07 AM.png

We are excited to announce the newest product from Radius Networks, Physical Web Display for Chrome OS. Physical Web Display is a Chrome Kiosk app that combines the advertising and marketing power of digital signage with the user enhancement and engagement of the Physical Web. With this app, you can easily set up an array of custom digital signage displays that not only show content to potential users or customers visually, but also connect with them directly via their mobile devices with the Physical Web.

So what makes this different from every other digital signage app out there? Can’t you just use a QR code to share a URL and let people access it easily on their phones? Or maybe an NFC tag? Well QR codes are great and all, but literally no one has ever scanned one to open a URL. Physical Web is like a QR code that people will actually use. URLs are pushed over-the-air to a user’s phone automatically, so they can check out your site without having to be the one guy that scans a QR code while everyone else around silently judges them. NFC tags are a little better, but they require you to slap one on or around every display you have out there. The Physical Web Display app uses the internal Bluetooth capability of the Chrome OS device to transmit the URL, so everything works out of the box without additional effort.

How can this help your business or organization reach users or customers? Rather than just asking them to check out your website or download your app, you can link them directly to your homepage, webstore, Facebook page, or Twitter feed. You can broadcast the URL to download your app in the App Store or Google Play Store directly, all without the aforementioned clunkiness of QR codes, NFC tags, or manually entering URLs. With deep linking in mobile apps, you can even send users to a specific location inside your app.

The app works by letting you provide custom content to display on-screen, which is then paired with a custom URL that you provide. This URL is transmitted over Bluetooth using Google’s Eddystone URL standard (the backbone of the Physical Web) while the paired content is displayed, reaching nearby users and allowing them to easily access the URL. You can add as many of these content/URL pairs as you want, and configure how long each one is displayed before rotating to the next one in the queue.

The Physical Web Display app runs on any Chrome OS device, from the small yet powerful ASUS Chromebit to the all-in-one AOPEN Chromebase, both of which are perfect for digital signage. To get started, find the right Chrome OS device for your needs and head to our knowledgebase for instructions on installing the app on your device and configuring your first advertisement. You can also check out Physical Web Display in the Chrome Web Store. For more info about the Physical Web and its possibilities check out our blog post and the Physical Web site.

Monitoring the Closest Beacon with Proximity Kit

By Scott Newman

Calculating the closest beacon to a device can be a challenge, but our latest release of ProximityKit makes it very easy to do. We’ve added a new delegate callback method to our library that will tell you when the closest beacon has changed. It’s easy to use right out of the box and it can be configured as needed.

Let’s look at how we solved the challenge so you can focus on writing world-class applications.

Background

If you read through Apple’s iBeacon documentation, you’ll find their recommended approach to distance ranging is to use the proximity property on the CLBeacon class and they discourage developers from trying to detect specific distances. While this is a very good strategy, there are times when it is appropriate to determine the beacon’s distance.

The proximity property of CLBeacon returns a CLProximity enum with one of four values:

  1. CLProximityUnknown

  2. CLProximityImmediate

  3. CLProximityNear

  4. CLProximityFar

These values are calculated by Core Location automatically and take into account factors such as RF signal interference, fluctuation, etc.

Note: In our ProximityKit iOS library, we expose the proximity and accuracy properties from Core Location’s CLBeacon class in our RPKBeacon class. Any tips you find around the web for working with CLBeacon also apply to our RPKBeacon implementation.

When is estimated proximity good enough?

For many use cases, knowing if a device is immediatenear, or far from a beacon is good enough. Ideally, beacons are physically placed far enough apart so that it is not possible to be in immediate or near proximity of two beacons at the same time.

If this is the case for your application, the code can simply use the didRangeBeacons:inRegion:callback from ProximityKit or Core Location to see which beacons, if any, are immediate or near.

In practice, the immediate proximity is approximately 1-2 meters from the beacon, and this might be too close for your needs. You probably don’t want users to crowd around a podium in the middle of a museum exhibit to trigger an immediate proximity event.

In this scenario, it would make more sense to trigger when the proximity is near, but what if two beacons are both reporting near at the same time because they are about ten meters apart?

When to use the accuracy measurement

ProximityKit (and Core Location) also returns an accuracy measurement derived from a calculation using the beacon’s signal strength (RSSI) and the measured power calibration. While it is not strictly a distance measurement, it can be used as a proxy for distance calculations. Apple recommends this property be used “to differentiate between beacons with the same proximity value”.

From the CLBeacon reference discussion for accuracy:

Indicates the one sigma horizontal accuracy in meters. Use this property to differentiate between beacons with the same proximity value. Do not use it to identify a precise location for the beacon. Accuracy values may fluctuate due to RF interference.

Let’s imagine a scenario where three beacons are placed in a room approximately fifteen meters apart. Your user is standing in the room and all three beacons are reporting a proximity of near. We want to tell the user which beacon is the closest, so we can differentiate the three beacons by looking at the accuracy property.

Challenges using accuracy

The challenge of using the accuracy property is that the value can fluctuate wildly in a short amount of time. Perhaps the room is busy and people are walking between the device and the beacon, causing the signal to fluctuate and sporadically disappear.

To combat this, we can create some logic that averages the readings over a few seconds and reports back a running average of the accuracy reading.

The logic would work something like this:

  1. The didRangeBeacons:inRegion: method is called in your delegate

  2. Iterate over each beacon from step #1 and get its accuracy property

  3. Store the accuracy value from step #2 in an array along with its timestamp

  4. Iterate over the array from step #3, purging any readings older than five seconds

  5. Compute the average accuracy value from the array in step #4

  6. Compare the average accuracy value from step #5 for each beacon and determine which is the closest

The logic is straightforward, but there are subtle details that must be taken into consideration to conserve battery life and processing.

We wrote it so you don’t have to!

We felt this was enough of a common use case that we should write an implementation for the developers using our beacons and ProximityKit library. This functionality has been released with version 1.2.1 of our ProximityKit framework.

Using it is very simple. When instantiating RPKManager, provide the monitor_closest_beacon and averaging_secondsvalues in the configuration dictionary:

RPKManager *manager = [RPKManager managerWithDelegate:self andConfig:@{
        @"kit_url": @"<your kit url>",
        @"api_token": @"<your api token>",
        @"monitor_closest_beacon": @"true",
        @"averaging_seconds": @(10.0),
    }];

Note: averaging_seconds has a default threshold of five seconds; you can omit the key/value in the configuration if that value works for you.

How to use it

When you configure RPKManager this way, you’ll get a closestBeaconDidChange:forRegion: delegate callback:

- (void)    proximityKit:(RPKManager *)manager
  closestBeaconDidChange:(RPKBeacon *)beacon
               forRegion:(RPKBeaconRegion *)region

Here’s an example implementation of the delegate method:

- (void)proximityKit:(RPKManager *)manager closestBeaconDidChange:(RPKBeacon *)beacon forRegion:(RPKBeaconRegion *)region {
	if (beacon != nil) {
	    NSLog(@"New closest beacon: %@-%@", beacon.major, beacon.minor);
	}
}

There are three things to know about the callback:

  1. If you go out of range of all beacons, the beacon value will be nil.

  2. The closest beacon will not change more than once every five seconds

  3. When the closest beacon calculation happens behind the scenes, the new closest beacon must be 10% closer than the current closest beacon

Steps #2 and #3 are designed to prevent “flapping” behavior where two beacons in very close proximity keep fighting each other to become the closest. This is part of the ‘smoothing’ behavior discussed above.

Summary

We hope that this new functionality cuts down the amount of code you need to write as a developer when you need to calculate the closest beacon. Give it a shot, and let us know what you think!

Physical Web with Pre-Configured Eddystone URL Beacons

We are excited to announce the availability of RadBeacon proximity beacons, factory-configured with custom Physical Web URLs to streamline access to the Physical Web and the Internet of Things


Radius Networks today announced the next step forward in promoting and popularizing the Physical Web by enabling customers to order RadBeacon proximity beacons that customers can purchase pre-configured to advertise Google’s Physical Web protocol. Pre-configured Eddystone URL beacons are available for purchase on the company’s website and simplifies deployment and access to the Physical Web, the latest advancement of the Internet of Things.

The Physical Web combines the power of web technology with the explosive growth of the Internet of Things, giving any smart device a web address. Soon, thanks to the power of the Physical Web, walking up to any smart device, be it a rental car, vending machine, a child’s toy, or a city bus stop, will provide immediate access to useful and relevant information and services.

“The Physical Web is a simple, yet powerful, way of leveraging beacon technology,” said Marc Wallace, CEO and Co-Founder of Radius Networks. “We believe that this will make the benefits of beacons more tangible for everyone.”

At CES 2016 in Las Vegas, Radius Networks deployed 1500 beacons throughout the convention show floor to deliver indoor navigation, in-app messaging and gamification to attendees via the CES Mobile App. The beacons also broadcast Physical Web URLs that, when clicked, took attendees directly into the maps section of the CES app. If the attendee did not have the mobile app, they were taken to a web page where they could download it.

Buy Physical Web Beacons

Get started today with Physical Web Beacons. They are available on our store now.



A Few Notes About the CES 2016 Beacon Scavenger Hunt

By Marc Wallace

The folks over at Make Magazine have posted about their efforts to hack the CES 2016 Beacon Scavenger Hunt.

We wanted to share our response with you:

Hey Alasdair and Sandeep, Marc Wallace at Radius Networks here.

A few comments on your post:

1. Hacking the Scavenger Hunt

The purpose of the Scavenger Hunt is to encourage attendees to explore areas of the show floor that they might otherwise have missed. If you complete the scavenger hunt, you get a token that you can present at the CES office and win a prize.

For the top prize winners, we use a procedure to validate that they actually visited the scavenger hunt locations at CES. Simulating the beacons at your desk generates a token in the mobile app, but it doesn’t mean you completed the scavenger hunt. It just means you missed out on seeing some really cool stuff at CES.

2. Tracking of Attendees

Radius Networks and CTA take mobile privacy very seriously. Beacons are used to generate venue foot traffic analytics which do not contain personally identifiable information.

Also, the message that was pictured and described as creepy, and possibly as a result of tracking using beacons, has nothing to do with our beacon implementation.

3. Indoor Navigation Beacon Information

In addition to scavenger hunt beacon information, you also accessed indoor navigation beacon definitions with related lat-long information. These beacons are in support of our extremely successful indoor navigation implementation at CES. As with the scavenger hunt beacons, this information is not considered sensitive, and the identifiers are essentially public information.

As a general approach, it’s important to use the appropriate security mechanisms for the sensitivity of the information involved. We feel we accomplished this for CES, that the integrity of the Scavenger Hunt has been maintained, and that attendees at CES will continue to enjoy the benefits of the beacon network.

Marc and Chris with the CES 2016 Scavenger Hunt Grand Prize Winner, Damien.

Marc and Chris with the CES 2016 Scavenger Hunt Grand Prize Winner, Damien.

Battery-Friendly Beacon Transmission

By David G. Young

While most beacon apps focus on detection of bluetooth beacons, some of the coolest mobile apps you can make involve making the device transmit as a beacon as well. Think about an app that lets friends know they are nearby one another. When two users walk within about 50 meters of each other, presto! The app alerts you that a friend is nearby.

Apple has supported beacon transmission since iOS 6, and most Android devices have done the same starting with Android 5.0. But lots of folks are wary of transmitting all the time. The conventional wisdom is that app developers need to be careful about transmitting because of its impact on battery. We all know that angry users with drained batteries will quickly uninstall your app. Is transmitting as a beacon really that bad?

To test this hypothesis, I used the Locate app for iOS and Android, the first configured to transmit an iBeacon frame and the second configured to transmit an AltBeacon frame. I figured I could run the apps for a long time and see what the battery drain is compared to the same device over the same period of time without the transmitter app running.

Screen Shot 2018-11-20 at 11.34.43 AM.png

Foreground vs. Background Transmission

It is important to note a major difference between iOS and Android when it comes to transmitting when your app is in the Background. On iOS, you essentially can’t do it. While BLE advertisements are allowed in the background, they are only allowed using a proprietary Apple format intended for advertising application services. You can’t send standard iBeacon transmissions unless your app is in the foreground. Android, on the other hand, has no such restrictions — you can transmit in the background all you want.

The fact that you aren’t allowed to transmit in the background on iOS leads many to believe the restriction is in order to save battery. Apple is notoriously stingy about restricting background usage of operations that are battery hungry.

Because of this restriction, the Apple tests had to be run when the app was in the foreground and the screen was on. Obviously, the screen causes a big battery drain itself. So it was important to run both the baseline test and the transmitter test under the same conditions with the same screen pattern on.

Test Setup

In order to test the battery usage of beacon transmitters on iOS and Android I installed the Locate app on an iPod Touch 5th Generation with iOS 8.1 and a Nexus 9 with Android 6.0. I chose non-phone variants of iOS and Android so I could eliminate the cell radio as a source of battery drain — something that is often outside developer control and subject to random variation. In addition, during the tests I put the devices into airplane mode (but with Bluetooth enabled) so that WiFi and GPS radios did not affect the results. Finally, I uninstalled everything but stock apps so I knew there weren’t any other apps draining the devices in the background.

Because iOS can only transmit in the foreground, I configured “AutoLock” to Never and set the screen brightness to a minimum. This kept the screen on and the app in the foreground. For both the baseline and transmitter tests, I kept the same Locate transmitter screen on the display. This is important because different screen patterns can affect battery usage when the display is on.

On Android, I simply hit the shoulder button to turn off the display for both the baseline and transmitter tests. Android also lets you configure the transmitter power level (which I set to low) and the number of advertisements per second (which I set to 1 Hz aka Low Frequency.)

Screen Shot 2018-11-20 at 11.34.47 AM.png


Results

You can see the results of the tests in the tables below:

Android Nexus 9 (6,700 mAh battery)

Baseline Transmitter On Transmitter On (extended)

Test Duration 12:45 hours 22:20 hours 52:36

Battery Start 100% 100% 100%

Battery End 100% 100% 94%

iOS iPod Touch 5th Gen (1030 mAH battery)

Baseline Transmitter On

Test Duration 04:16 hours 04:38 hours

Battery Start 100% 100%

Battery End 36% 43%

The first thing you notice is that the Nexus 9 really does not use much of its battery regardless of whether it is transmitting or not. And even with the beacon transmitter on, the battery was still at 100% after nearly 24 hours. After over two days of transmitting it was still at 94%. Clearly that beacon transmission is not using much battery. It’s so low, it is impossible to calculate how much it is using with any certainty with this test setup.

The iOS results show much higher battery usage 36% over the course of only four hours, but it is undoubtedly due to the screen being on. In fact, when both the screen and the beacon were on the battery usage was lower. There is no reason to think this is actually because the beacon transmission saves battery — it’s probably just that the beacon battery usage was within the margin of error of the test method. Because the screen is using so much battery, it’s hard to conclude that the beacon transmitter battery usage is negligible in this test setup. However, it is clearly negligible compared with the battery usage of the screen. And since iOS requires the screen to be on to transmit a beacon signal, there is no point in worrying about beacon battery usage at all.

Conclusions

These tests show conclusively that beacon transmission on iOS and Android causes an insignificant battery draw compared with other sources of battery drain. There is simply no reason to avoid beacon transmission in order to save battery.

Is this really so surprising? Consider that manufacturers of hardware beacons typically power a transmitter for months using a tiny CR2032 coin cell battery. These batteries have a capacity that is less than a tenth of the energy density of even the small battery in an iPod touch.

The fact that Apple restricts transmission in the background probably has more to do with other design concerns (like limitations on how many apps can transmit full advertisements simultaneously using a single bluetooth chip.) So if you have an app on an Android device that can transmit in the background, and you can get access to the transmitter before all the transmission slots run out, go for it! Your app users will never notice the difference in battery usage.




Hashtag Sports Fest in Brooklyn, NY

By Christopher Sexton

Radius Networks is at the Hashtag Sports Fest today and tomorrow in Brooklyn, NY.

Hashtag Sports Fest is a groundbreaking 3-day expo, conference, and celebration of the convergence of sports, digital media, and technology that will serve as an industry showcase and catalyst for innovation.

Over 30 exhibitors and hundreds of decision makers from global brands, media companies, and disruptive startups will gather with the sports industry in over 60,000 sq. ft. of New York City space on Oct. 20-22 to discuss the critical opportunities and challenges that emerging technologies present to sports content providers and the Millennial / Generation Z fan experience.

From the creators of the industry leading #SportsConf virtual thought leadership series with over 125 speakers and 20,000 viewers to date, the inaugural Hashtag Sports Fest will take the conversation offline for an unmatched, immersive educational experience and networking opportunity in the heart of Brooklyn.

Come see Radius Networks and a lot more innovations, where sports and technology meet to make marketing and fan experiences better.

For more details and to visit the free expo check out hashtagsportsfest.com.

Screen Shot 2018-11-20 at 11.33.09 AM.png

Proximal Push Notifications

By Scott Yoder and Christopher Sexton

Push notifications are a great feature on iOS, but they are a pretty blunt instrument. When you send them, they get delivered to recipients no matter where they are. What if you want to send a notification only to people that are in a specific location?

One option is to report their location to the server, and then only notifications to the people in the desired location. But this has privacy implications. It involves tracking users locations all the time, and that’s a little creepy. We were not willing to do that.

For Campaign Kit and came up with a solution that is both reliable, quick, and treats customer’s privacy with respect. This works by having our SDK in an App on the phone. The phone knows where it is and can use that information. The important part is to not report up those details unnecessary.

How do we do this? The solution we follow is:

  1. Send a silent Push Notification

  2. Check Recent Places

  3. Sync with the Server

  4. Range for Beacons

  5. Show Notification

Lets go over those steps in more detail.

1. Send a silent Push Notification

Screen Shot 2018-11-20 at 11.30.04 AM.png



On iOS, Apple supports a “Silent” push notification, where the app will receive a callback in the background. You just have to implement the didReceiveRemoteNotification in your app delegate and set the remote-notification Background Mode in the plist.

- (void)         application:(UIApplication *)application
didReceiveRemoteNotification:(NSDictionary *)userInfo
      fetchCompletionHandler:(void(^)(UIBackgroundFetchResult))completionHandler
{
  // Handle the callback }

2. Check Recent Places

Screen Shot 2018-11-20 at 11.30.08 AM.png




This is important to not overwhelm the back end and to have a low impact on devices not in proximity to a beacon. Check the internal list of places and make sure that the phone has been near one recently, perhaps within the last hour.

If we find that there was a recent and relevant location we will continue; otherwise, stop here.

3. Sync with the Server





Now that we know this phone is likely to be in proximity to a beacon we want to sync with the server. This will fetch any content as well as a list of beacons that will trigger the notification.

4. Range for Beacons

Screen Shot 2018-11-20 at 11.30.14 AM.png






Now that we have updated data, range for a few seconds. If there is a beacon within range, you have found a match. The method we use for doing that looks something like this:

- (void)handleRemoteNotification:(NSDictionary *)userInfo
          fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
{
  NSLog(@"CampaignKit: handling remote notification.");
  if ([proximityKitDelegate placeDetectedRecently]) {
    // we've seen beacons/geofences recently, so we better sync and check campaigns     [self syncWithCompletionHandler:completionHandler];

    // range for 5 seconds in the background     __block UIBackgroundTaskIdentifier backgroundTask = \
    [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:
      ^{
        // if iOS tells us our task has expired, let's quit before we are killed         [[UIApplication sharedApplication] endBackgroundTask:backgroundTask];
        backgroundTask = UIBackgroundTaskInvalid;
      }
    ];

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, FIVE_SECONDS)), dispatch_get_main_queue(),
      ^{
        if (backgroundTask != UIBackgroundTaskInvalid) {
          [[UIApplication sharedApplication] endBackgroundTask:backgroundTask];
          backgroundTask = UIBackgroundTaskInvalid;
        }
      }
    );
  } else {
    // haven't seen any places recently, so let's assume this push isn't for us     completionHandler(UIBackgroundFetchResultNoData);
  }
}

5. Show Notification

Screen Shot 2018-11-20 at 11.30.18 AM.png







The fun part: notify the user. Send the local notification, display the content, whatever your app needs to do to inform the end-user. And only the people who would care about that information.

Campaign Kit: Engagement where it counts

Want this functionality in your app? Check out Campaign Kit, and we take care of these details for you. It’s an SDK that you can drop in to take advantage of beacon and geofence capabilities to deliver targeted campaigns to mobile devices within proximity of any place. Complete with simple content editor, campaign analytics, smart caching, and more.








How to Pop a Pass Using iBeacon Technology

By Michael Harper

Using iBeacon Technology to Display a Pass in iOS

PassKit was introduced in iOS 6 and brought us coupons, boarding passes, store cards, and event tickets directly on our iPhones. I remember adding an Alaska Air boarding pass to Passbook several years ago (now known as “Wallet” in iOS 9) and being pleasantly surprised to see it magically available on my phone’s lock screen when I was at the airport.

How’d they do that?

I’m guessing they used a geofence in the pass to cause it to be front-and-center when I was at the airport where I’d board the plane. It turns out you can do the same thing when a pass is installed on a device that is in proximity to a specific beacon!

Different types of passes can be added to Wallet: airplane boarding passes, store cards, discount coupons, and payment methods for Apple Pay, just to name a few. In this tutorial, we are going to build a membership card pass for a fictional fitness club named “RadBeacon Athletic Club”. The idea is that the pass should pop onto the iOS lock screen when in the vicinity of a beacon at the facility’s front desk in order to be scanned.

Configuration

The RadBeacon Athletic Club (RBAC) has a front desk where members check in as they enter the fitness area. We would like for the member‘s pass to be available from his phone‘s lock screen when he arrives at the front desk. This will make it very easy for the member to have his pass scanned without even breaking stride.

We are going to configure a beacon at the front desk with the following values:

Beacon Identifier Value

UUID 2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6

Major 2

Minor 150

For the purpose of creating a pass, I will pose as member #24601.
The Pass Type ID for this pass is pass.com.radiusnetworks.rbac

Creating a Pass

A pass “package” is comprised of a directory containing a pass.json file and a few image files:

  • icon.png — displayed in the pass notification on the lock screen

  • logo.png — appears in the upper-left-hand corner of the pass

There are additional images that may be specified for a pass, but we‘re keeping it simple.

The pass.json file is where the magic happens. It is simply a dictionary of keys and values that define the pass. There are a bunch of different keys available, including pass identifiers, description, styling, and “relevance” which specifies where the pass is likely to be used. The beacons key is the one we’re interested in.

I started with the “generic” pass sample provided by Apple and stripped it down to the bare minimum and then added the beacons entry.

"beacons" : [
  {
    "major" : 2,
    "minor" : 150,
    "proximityUUID" : "2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6",
    "relevantText" : "RadBeacon Athletic Club Front Desk"
  }
]

This is the complete pass.json file (with the teamIdentifier elided):

{
  "description" : "RadBeacon Athletic Club Membership Card",
  "formatVersion" : 1,
  "organizationName" : "RadBeacon Athletic Club",
  "passTypeIdentifier" : "pass.com.radiusnetworks.rbac",
  "serialNumber" : "2460124601",
  "teamIdentifier" : "your_team_identifier_here",
  "beacons" : [
    {
      "major" : 2,
      "minor" : 150,
      "proximityUUID" : "2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6",
      "relevantText" : "RadBeacon Athletic Club Front Desk"
    }
  ],
  "barcode" : {
    "message" : "24601",
    "format" : "PKBarcodeFormatPDF417",
    "messageEncoding" : "iso-8859-1"
  },
  "foregroundColor" : "rgb(255, 255, 255)",
  "backgroundColor" : "rgb(0, 0, 0)",
  "generic" : {
    "primaryFields" : [
      {
        "key" : "member",
        "value" : "Brian Johnson"
      }
    ],
    "secondaryFields" : [
      {
        "key" : "subtitle",
        "label" : "MEMBER SINCE",
        "value" : "2007"
      }
    ],
    "auxiliaryFields" : [
      {
        "key" : "favorite",
        "label" : "FAVORITE EQUIPMENT",
        "value" : "TRX Suspension Trainer",
        "textAlignment" : "PKTextAlignmentRight"
      }
    ]
  }
}

Once you‘ve assembled the contents of your pass, you need to sign the pass directory with a certificate obtained from the Apple Developer Member Center. This generates a .pkpasspackage which is the actual pass that needs to be distributed. I used the Apple-provided signpass executable (see Passbook Support Materials) in conjunction with my certificate to generate the signed pass package. These steps are all covered in detail at the Apple Developer site.

The completed pass directory can be found here.

Installing the Pass

After signing the pass, I previewed the pass on OS X.



Because iCloud is configured on my Mac and on my iPhone, I am able to add the pass to my wallet directly from my Mac by double-clicking the pass and clicking Add to Wallet. You can send the pass to your phone any way you like — email, Message, AirDrop, web site — as long as you can tap on the attached pass to install it into Wallet.

Testing

Note that Location Services need to be enabled for the Wallet app on iOS in order for the pass to become available in the vicinity of a beacon.

I used RadBeacon to configure a RadBeacon Dot with the UUID, major, and minor specified for the front desk.

Screen Shot 2018-11-20 at 11.22.13 AM.png




Once the pass is installed and the beacon is enabled, whenever my phone is in the vicinity of the front desk beacon, the pass becomes available on my lock screen.





Now I can swipe on the pass notification and see the pass.






The pass notification also appears on my Apple Watch.







Tapping through on the notification displays the pass details and QR code.

Announcing Radius Networks Services

Yesterday we released a new offering of managed services for enterprise customers including beacon deployment, network monitoring, maintenance and support.

“At Radius Networks, we’ve helped major, global enterprise brands develop and deploy large, sophisticated proximity networks,” said Ken McInerney, Director of Client Services at Radius Networks, “We are excited to formalize these matured capabilities and offer turnkey managed services that relieve clients of the day-to-day burden of managing and monitoring their proximity services networks.”

Radius Networks Services (RNS) comprise an end-to-end managed solution for proximity beacon networks of all sizes and include network architecture, beacon deployment and optimization as well as ongoing monitoring and maintenance of the entire system.

Key components of the RNS service include continuous monitoring by Radius Networks’ Proximity Network Operations Center (PNOC), located in Washington, DC, and local field maintenance and problem resolution conducted by Radius Networks field engineers and a network of authorized local technical partners.

“Our clients are coming to the table with increasingly more robust business objectives for their proximity networks,” explained Radius Networks CEO, Marc Wallace, “Since we are the technical experts behind the technology, Radius Networks is uniquely positioned to partner with our clients over the long term to ensure that their networks perform flawlessly.”

RNS services will be initially available out of Radius Networks’ North American facilities in the 4th quarter of 2015, and Radius Networks is currently working with partners on a European facility to provide hosting and managed proximity services directly to European clients in the 1st quarter of 2016. Find out more information about Radius Networks Services.


Is Your Beacon App Ready for Android 6.0?

By David G. Young

The new Android 6.0 release has several important changes that affect apps detecting bluetooth beacons. If you have a beacon-based app already in the Play Store, or are planning a new beacon-based app, you’ll need to make updates to keep your app from breaking as users transition to Android 6.0.

While this article focusses largely on the impact for users of the Android Beacon Library and Radius Networks’ ProximityKit and CampaignKit libraries that are built upon it, the same issues described here apply to any app that detects beacons. If you are using a different vendor’s SDK, it is important to make sure they will continue to work on Android 6.0.

Runtime Permissions

The biggest change for beacon apps in Android 6.0, codenamed Marshmallow, and sometimes called just “M”, has to do with permissions. Just like iOS, Android now implements permissions at runtime instead of the traditional way of granting permissions at install time. Apps designed for Marshmallow (SDK 23 and above) must add code to prompt users for some permissions after the app starts up, otherwise they will not be granted.

Not all permissions, however, work this way. Permissions marked as PERMISSION_NORMAL are still granted the old fashioned way: at install time. For beacon apps, two important permissions continue to follow the old model: android.permission.BLUETOOTH and android.permission.BLUETOOTH_ADMIN, both of which is needed to scan for beacons. Because these permissions still use the old behavior, nothing really changes with them in Marshmallow.


While the bluetooth permissions are enough to allow your legacy app to scan for beacons on Android 6.0, these permissions only allow it to do so in the foreground. Background scanning for bluetooth devices in Android 6.0, including beacons, now requires either android.permission.ACCESS_FINE_LOCATION or android.permission.ACCESS_COARSE_LOCATION.

This means that apps to be installed on Android 6.0 devices that want to discover beacons in the background must make changes. Apps must declare one of these location permissions in AndroidManifest.xml. This is true even for legacy apps that don’t target SDK 23 used for Android Marshmallow.

What’s more, these permissions follow the new runtime model. This means that apps that target SDK 23 must also prompt the user for a location permission after the app is launched. If you fail to prompt for and get this permission, you’ll get the following error in LogCat when you try to do a bluetooth scan in the background, and no beacons will be detected:

09-22 22:35:20.152  5158  5254 E BluetoothUtils: Permission denial: Need ACCESS_COARSE_LOCATION or
                                                 ACCESS_FINE_LOCATION permission to get scan results

To avoid your Android Marshmallow users getting this error, you must at least update your legacy AndroidManifest.xml with the following:

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION”/>

And you must also add code like the following to an Activity if your app targets Marshmallow (if you set targetSdkVersion 23):

private static final int PERMISSION_REQUEST_COARSE_LOCATION = 1;
// ...

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // ...

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {

        // Android M Permission check

        if (this.checkSelfPermission(Manifest.permission.ACCESS_COARSE_LOCATION) != PackageManager.PERMISSION_GRANTED) {

            final AlertDialog.Builder builder = new AlertDialog.Builder(this);

            builder.setTitle("This app needs location access");
            builder.setMessage("Please grant location access so this app can detect beacons.");
            builder.setPositiveButton(android.R.string.ok, null);

            builder.setOnDismissListener(new DialogInterface.OnDismissListener() {


                @Override

                public void onDismiss(DialogInterface dialog) {
                    requestPermissions(new String[]{Manifest.permission.ACCESS_COARSE_LOCATION}, PERMISSION_REQUEST_COARSE_LOCATION);

                }


            });

            builder.show();

        }
    }
}

@Override
public void onRequestPermissionsResult(int requestCode,
                                       String permissions[],
                                       int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_COARSE_LOCATION: {
            if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                Log.d(TAG, "coarse location permission granted");
            } else {
                final AlertDialog.Builder builder = new AlertDialog.Builder(this);
                builder.setTitle("Functionality limited");
                builder.setMessage("Since location access has not been granted, this app will not be able to discover beacons when in the background.");
                builder.setPositiveButton(android.R.string.ok, null);
                builder.setOnDismissListener(new DialogInterface.OnDismissListener() {
                    @Override
                    public void onDismiss(DialogInterface dialog) {
                    }
                });
                builder.show();
            }
            return;
        }
    }
}

How Permission Prompting Works

The code above will first check to see if the location permission has already been granted. If not, it will prompt the user with an AlertDialog, “Please grant location access so this app can detect beacons.” This dialog is not strictly required, but it is recommended to first explain to the user why your app needs the permission. While this message is just an example, you should probably fine tune the verbiage to explain in less technical terms what functional benefit users gets from granting this permission. Otherwise, users will likely deny the permission to keep the app from tracking them.

After presenting this dialog, the system then calls the new Android requestPermissions method that actually does the prompting. The dialog screenshot above shows what the user actually sees. Android also provides a callback to the app telling you the result of what the user decided (see the onRequestPermissionResult callback), but it is important to note that users can change their mind later on via settings and turn permissions on or off. In that case, the callback method won’t get notified.

Location Permissions are not Enough

It is important to note that the location permission does not replace the need to request BLUETOOTH and BLUETOOTH_ADMIN permissions – all three are now necessary. And just because you get user to grant the permission doesn’t automatically turn bluetooth on. It still needs to be turned on separately, so you will need to keep prompting your users to do that, too.

Two other supplemental permissions used by the Android Beacon Libraryandroid.permission.RECEIVE_BOOT_COMPLETED (used to start looking for beacons after phone startup) and android.permission.INTERNET (used to download an updated database of device-specific distance estimation formulas) also follow the old model. For beacon apps using the Android Beacon Library, these two supplemental permissions will continue working the same way with Android Marshmallow.

Power Saving Modes

The other big change for beacon apps with Android Marshmallow is that it implements two power saving modes which affect background operations. Fortunately, apps using the Android Beacon Library, and other Radius Networks SDKs built upon it (like ProximityKit and CampaignKit) don’t need to make any changes to their apps as the library handles all the details of keeping beacon scanning going in the background. If you use other code to scan for beacons, or if you are interested in how the Android Beacon Library handles the changes, read on. If you’d rather just take our word for it, skip to the MAC address section below.

Doze Power Saving Mode

Android’s new Doze feature will put your device in a battery saving mode when the screen is off and it is not plugged in, and the operating system detects that it is sitting motionless based on accelerometer input. This is intended to cover cases where it is sitting on a desk, but not when it is in your pocket or purse while you are moving around, or in a moving vehicle.

To understand how this affects background beacon scanning with the Android Beacon Library, it is important to understand how the library handles periodic background scanning. It uses a background Service that uses the Android Handler mechanism to periodically start and stop scanning. It also uses the AlarmManager to restart the scanning service if the app and service are terminated due to low-memory conditions or due to the user closing the app from the task switcher.

Doze does not affect the ability to do bluetooth scans or run Handler-based timers, but it does affect the ability to use the Android AlarmManager system, which some beacon-based systems use to schedule bluetooth scans. For apps based on the Android Beacon Library, the disabling of Alarms does not cause problems in scanning for beacons because it only uses Alarms as a backup should Handler-based timers fail. Tests on a Nexus 9 running the third preview release of Android M (build number MPA44l) show that beacon detection continues normally under Doze.

App Standby Power Saving Mode

App Standby is similar to Doze, but it is triggered under different conditions. If a user doesn’t explicitly launch an app for several hours or several days (Google won’t say specifically how long it takes), the app is put into App Standby mode whenever the device is not connected to a charger. (App Standby also may be avoided if the app sends visible notifications.) Once an App is in App Standby, it generally cannot access the network, something that might prevent calling web services based on beacon detections. That said, App Standby does not specifically affect beacon detection with the Android Beacon Library, because bluetooth scanning service continues to run normally, and the AlarmManager and Handler-based timers continue to work. Again, this has been verified by tests on a Nexus 9 running the third preview release of Android M.

Network Calls Blocked in App Standby

Being blocked from making network calls can still affect your app. If your app only needs to periodically contact a web service, App Standby can keep it from trying to do so. In theory, an app in App Standby can still make network calls once in awhile. As Google says, “if the device is idle for long periods of time, the system allows idle apps network access around once a day.” Unfortunately, there is no documentation on how this works. If your app uses one or more libraries that require background network access and the app requires background network access in its own code, there is no guarantee which codebase will try background network access first, and which one will actually succeed “around once per day.”

Fortunately, there are two other ways an app in AppStandby can get network access aside from the squishy “around once per day” promise.

  • The app receives a new “high priority” message from Google Cloud Messaging (GCM). Receiving such a push notification amounts to a get out of jail free card. But Google has yet to release details on how to send this new high priority push notification. What’s more, it’s based on Google Play Services, which are not available on many devices like Amazon’s Kindle Fire line, the vast majority of tablets and handsets in China, and a growing number of non-Google Android devices in India and other parts of the world.

  • The phone is charging. Any app that has been put into App Standby temporarily regains network access after charging is connected. An app can therefore register to receive a broadcast message when power is connected and then attempt to make network calls at that time. (It’s probably a good idea to delay for a minute or so to wait for full network access to be restored.) The code below shows how you set this up in the AndroidManifest.xml.

<receiver android:name="com.mycompany.myapp.MyBroadcastReceiver">
  <intent-filter>
    <action android:name="android.intent.action.ACTION_POWER_CONNECTED"/>
  </intent-filter>
</receiver>

While the Android Beacon Library does not require background network access, Radius Networks’ ProximityKit and CampaignKit libraries for Android do make periodic network calls to sync new data with the server. Using techniques like described above, new releases of these libraries for Android 6.0 will continue to sync data even in the background.

Background Scanning and Launching Unchanged

The Android Beacon Library’s scanning service starts up in the background by using a broadcast receiver that listens for the RECEIVE_BOOT_COMPLETED event. This same broadcast receiver also handles alarms that go off after five minutes of the scanning service not being active. These alarms ensure that the service is able to keep looking for beacons even if the operating system had to temporarily evict the app due to a low memory condition. Based on testing with the Nexus 9 and the Android Marshmallow preview release, these capabilities are all unchanged with the new OS update.

As described above, the only limitation with Doze is using Alarms to restart beacon scanning. Because Alarms are disabled in Doze, the Android Beacon Library cannot use Alarms to restart itself if it is manually killed by a user or if memory pressure causes the operating system to terminate the app. However, because interacting with the device will cause it to exit Doze, there is no easy way for a user to kill an app while it is in Doze. Similarly, because a user is not interacting with a device while it is in Doze, it is very unlikely that an app will start using a large amount of memory causing the a beacon-based app to be shut down to free up memory. In the very unlikely event that this does happen, the app would stop scanning for beacons until the next time power is connected or the phone rebooted.

The table below shows the effect of different Marshmallow modes on the scanning and auto-restart techniques used by the Android Beacon Library.

Platform/State Timed BLE scans Low Power Restart Scan Restart Scan
Scan Filter on Alarm on Power Connect

Lollipop Yes Yes Yes Yes

Marshmallow Yes Yes Yes Yes

App Standby Yes Yes Yes Yes

Doze Yes Yes NO N/A*

* Power connection automatically disables Doze

MAC address Spoofing and Read Blocking

Apps on Android 6.0 can no longer read the device’s own bluetooth MAC address, and this bluetooth MAC address is spoofed when sending out packets while doing an active bluetooth scan. The MAC address is randomized each time you start transmitting as a beacon (or doing bluetooth advertising for other purposes.) While transmitting as a beacon using the Android Beacon Library’s BeaconTransmitter class continues to work normally, receiving devices will see that it sends a different spoofed MAC address each time transmission starts.

Interestingly, blocking access to reading bluetooth MAC addresses is part of the rationale behind requiring location permission to scan for beacons. This restriction is already discussed in the permissions section above. But it is worth noting here Google’s justification for this permission change being based on reading MAC addresses:

“The MAC address and the SSID can be used to identify surrounding devices. Knowing the location of these devices can be used to infer the phone location. As we have no way to know if the app would try to infer user’s location via WiFi scans we take a conservative approach to protect the user’s privacy. If an app is targeting pre M SDK does not have ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION it will get scan results only if it is in the foreground. For M SDK apps the location permission is required to get scan results” – Google

Conclusion

While there are big changes in Android Marshmallow that affect beacon apps, users of Radius Networks SDKs like the Android Beacon LibraryProximityKit and CampaignKit are well positioned to make a smooth transition. The libraries already handle most of the details. If you have an existing beacon app that does not yet target SDK 23 and only needs to work in the foreground, no changes are needed. If you have a beacon app that needs to work in the background, you need to update it to request proper location permissions as described in the first section. Users of ProximityKit and CampaignKit will need to upgrade their SDKs to keep background syncs happening on Android 6.0.

Announcing the RadBeacon Smart

Today we have released RadBeacon Smart, the industry’s first software beacon platform.

The RadBeacon Smart software beacon platform by Radius Networks can turn existing hardware with BLE capability into a beacon. The RadBeacon Smart enabled beacon can also be remotely managed and configured using the RadBeacon Smart API and through Radius Networks Director beacon management service. Additionally, the RadBeacon Smart beacon can manage other beacons within range of it, acting as a hub within a fully-managed beacon network.

“We are seeing rapid growth in demand for our more sophisticated, secure and capable proximity products, like the RadBeacon Smart software platform. Enterprises in many different industries - from restaurants to sports stadiums to factories - need a robust, proximity solution that is flexible and can be managed to handle a rapidly evolving environment.” said Marc Wallace, CEO & Co-Founder of Radius Networks, “Furthermore, the ability to remotely install the RadBeacon Smart beacon software to existing devices in the field is a key benefit of our new platform.”

Radius Networks is currently deploying the RadBeacon Smart platform globally and with enterprise customers. Companies interested in learning more about the RadBeacon Smart platform can contact Radius Networks sales engineers for more information.

“Up to now, beacons have been considered to be cheap, battery-powered, throw-away devices. Unfortunately this approach does not meet the operational and management needs of large enterprises with geographically distributed locations. The RadBeacon Smart platform delivers a flexible, fully-managed, connected and customizable beacon solution that provides the industrial strength capabilities that these customers demand,” added David Helms, Chief Product Officer at Radius Networks, “Flexible, connected, software-defined beacons are the next big evolution in proximity solutions.”


Geofence Performance Testing on iOS

By Christopher Sexton

Beacons have been all the buzz around Radius Networks, but sometimes they are not quite the right tool for the job. Sometimes, the problem at hand is better solved with good old geofences. The problem is geofences don’t always work how you’d initially expect. So we did some testing.

Below is a map around Radius Networks HQ. The circle is a 60 meter radius geofence around our building. The blue pins are where the phone was triggered.


This just shows a small sample of the tests we ran. Personally, I preferred the ones conducted around our favorite taco joint.

  • The pins pointing off the lower left of the map were triggered across the river nearly 1000 meters away.

  • All of the pins on M St and off the map were triggered while driving

  • The other pins were triggered while walking

Test configuration

The test was configured using two iPhones (5s and 6) with two apps monitoring location.

  • Campaign Kit based test app monitoring one Place

  • Apple’s Reminders.app configured to trigger a reminder “When Arriving”

  • Location was disabled for all the other apps on the phones

  • All apps were sent to the background

  • The phones were locked and the screen is dark

We ran about 100 test triggers with this configuration. Out of those both apps triggered nearly every time within 30 seconds.

Both Apps Reminders Only Campaign Kit Only

92 2 1

Not bad. We are still not sure why the minor discrepancies occurred, but they happened infrequently enough that it was very difficult to figure out why. In the end, we were satisfied with the consistency of the behavior we were seeing

Conclusions

You don’t really use GPS for Geofences

The best performance and accuracy can be had by using kCLLocationAccuracyBestForNavigation, however Apple is likely to reject the app unless includes functionality that requires that mode. Most geofence use-cases don’t fall under that.

Keep Wi-Fi enabled

Wi-Fi makes a big difference. Disabling Wi-Fi means the phone falls back to using cell towers to detect major location changes. The problem is a typical phone has enough power to reach a cell tower up to 45 miles (72 kilometers) away. That means there is a pretty good chance for your phone to connect to a distant tower giving a false-positive.

This is reinforced by Apple’s Documentation:

The specific threshold distances are determined by the hardware and the location technologies that are currently available. For example, if Wi-Fi is disabled, region monitoring is significantly less accurate. However, for testing purposes, you can assume that the minimum distance is approximately 200 meters.

The radius of the geofence needs to be big enough

Our testing was done with a 60 meter radius, and, honestly, this was probably too small. Geofencing should be used for fairly large areas, normally about 200 meters. Anything less and you are unlikely to get a trigger.

Our test was based on comparing the Apple Reminders.app with Campaign Kit, so we copied the default settings that Reminders uses for geofences. By default, the Reminders app generates a 60 meter radius. This is at odds with their documentation, but we wanted to be consistent with their app behavior.

Geofence performance is affected by user behavior

This test was explicitly run with the app in the background and the phone locked with a dark screen. But as we’ve discovered through many fumbled tests if you wake up the phone it will respond much faster. We believe that the operating system uses this as an opportunity to scan for Wi-Fi and cell towers. Taking advantage of that information will trigger any apps that happen to be monitoring.

There are some unexpected conclusions discovered in this testing. But it appears that most of the caveats are there to help the all-important battery life of the phone.



How to Push Beacon Messages Without an App

By David G. Young

One of most common things businesses want to do with bluetooth beacons is to solicit customers to get their mobile app. This has long been impossible, because beacons can’t be detected without an app already on the phone to look for them. For folks wanting to get visitors to use their app, it’s a classic chicken and egg problem.

As of today, Google is taking steps to change this. The company is updating its Chrome for iOS web browser to automatically integrate with its Physical Web project, which detects beacons transmitting the Eddystone-URL format. When Chrome for iOS detects one of these beacons, it shows information about the website to the user, allowing the user the option of visiting it within the browser.

How it Works

The new Chrome feature works within the Chrome Today widget on the Notification Center Today view. For those unfamiliar with the feature, the Today view is what you see when you swipe down from the top of your iPhone. By default it shows your calendar and stock information, but you can add other App widgets by tapping the Edit button at the bottom of the screen. If you have Chrome for iOS installed, the Chrome Today widget will show up in the list of the ones you can add.

If the Chrome Today widget is activated, the first time a Eddystone-URL beacon is discovered, the website’s title and description will appear in the Chrome Today widget. Tapping on the website launches Chrome to the web page address transmitted by the beacon. This web page can be optimized for mobile, serving a welcome message to the visitor that can solicit a download of a mobile app to further take advantage of beacons.

Screen Shot 2018-11-20 at 11.08.32 AM.png



Baby Steps

Deploying the feature in Chrome for iOS is a baby step for Google, because relatively few iOS users opt for Chrome over the default Safari browser. Good statistics of the percentage of iOS owners using Chrome are nearly two years out of date. Back in the fall of 2013, it was only three percent.

Google’s choice to start with Chrome for iOS allows it to first deploy the system with a relatively small user base. Once it learns from the experience, the next logical step is to roll out a similar feature to Chrome for Android browser. That browser has over a billion downloads, and is the most widely used browser mobile browser on the planet. The chart above shows the rise of Chrome’s mobile market share.


Screen Shot 2018-11-20 at 11.08.41 AM.png

Once Google rolls out this capability to Chrome for Android, a very high percentage of mobile devices will be able to push content to viewers without the presence of a custom app.

Privacy Protection

Google has implemented a number of security features to protect the privacy of Chrome users. When the browser detects an Eddystone-URL transmission, it will contact Google’s own servers to fetch the content at the URL, including the page’s title. This Physical Web Service, as it is called, protects the privacy of the user by not directly contacting the website from the phone until the user gives permission. This prevents the web site from harvesting private information (like IP address, tracking cookies, etc.) unless the user actually agrees to go to the web site.

Chome also requires users to opt-in to use this feature. The first time an Eddystone-URL frame is discovered, the user will be prompted about whether the feature should be enabled.

Another restriction that is important to note is that Chrome will only look for beacons while the Chrome Today widget is loading, or when you refresh it. This means that if you pass by a beacon without looking at the Chrome Today widget, it won’t get detected. While this is not part of the privacy design, it does make it very unlikely that users will be accidentally pestered by beacon detections.

Custom Eddystone-URL usage

It is important to note that the restrictions above apply only to using Eddystone-URL with Chrome for iOS. If you do want to develop your own app that detects Eddystone-URL, you can do so without any of these restrictions. On Android, you can use the open source Android Beacon Library to detect Eddystone-URL frames.

Seeing Chrome in Action

In order to try Chrome’s detection capability yourself, you’ll first need a few things:

  1. An Eddystone-compatible beacon transmitter

  2. An iPhone, iPad, or iPod with iOS 8 or higher

  3. A copy of Chrome 44+ installed on the iOS device

  4. A short website URL

Step 1: Get A Beacon

You can buy an Eddystone Development Kit that includes three bluetooth beacons allowing you to set this up. You can also use the Android Locate app for testing, which allows you to transmit the Eddystone-URL frame needed to make this happen. If you want to use the latter, you’ll also need an Android 5 device that supports transmitter capability.

Step 2: Configure the Beacon

The beacon transmitter above must be set up to transmit an Eddystone-URL frame. The format only has 17 bytes to work with for the URL, so if your URL is long, you will want to use a URL shortening service. Even if you use a shortened URL, Chrome will automatically expand it before it displays it to users by following redirects. For our example, we’ll use http://radiusnetworks.com

If using a hardware beacon from the development kit above, you can use the free RadBeacon Android app to connect to the beacon and configure the URL. You can see a screenshot of how the app configures this above on the near right. Look at the URL field on the bottom of the screenshot.

If using the Locate Android app as a transmitter, you can go to the beacon transmitter screen, select Eddystone-URL, enter the URL, and turn the switch on. See the screenshot above at the far right.

Step 3: Set Up Your Web Site

In order to get the best experience, Google’s Physical Web Service expects the URL linked to by the beacon to be HTML page set up with the following. Because We are using the Radius networks web site, this is already done.

  • Proper title tags like so:

<title>Radius Networks - We Make Proximity Work</title>
  • Proper description tag like so:

<meta name="description" content="Proximity Sevices for Businesses and Developers">

When the above are present, the Physical Web service will use the above pieces of information to display to the user when the beacon is detected. Currently, only the title gets displayed, but because the Physical Web Service fetches the description, there is a good chance it will get added to the display in the future.

Step 4: Install Chrome 44 and its Today Widget

Go to the App Store on your iOS device and install the latest version of the Chrome browser. Then swipe down from the top of your screen to show the Today view, and add the Chrome Today Widget. See the screenshot at the top of this blog post.

Step 5: Turn on the Beacon

Now power up the beacon. Refresh the Chrome Today view by swiping down on the screen and you should see something like shown to the right.

Conclusions

The example above shows that it is now possible to deliver beacon-based content to an app, even without a custom app installed.

While this works, it is important to note that this is a limited first step that doesn’t make it easy for casual iPhone users to receive beacon content without an app. First, it requires an installation of Chrome for iOS. It also requires installing its Today widget and opting-in for it to work. Finally, it only works when Chrome is in the foreground.

This means it is not a game changer – yet. That said, the limited appearance of beacon detection in the mobile Chrome platform – even in such a limited and restricted way – gives a hint of what is to come.

Once this feature is rolled out to Chrome for Android, and done in a way that it is enabled by default, the game changer will finally be here.

Announcing RadBeacon Dot

Radius Networks, Inc., the leading provider of mobile proximity services, today announced the release of its RadBeacon Dot Bluetooth Smart™ proximity beacon which supports iBeacon, AltBeacon and Eddystone. The RadBeacon Dot is powered by a user-replaceable coin-cell battery, has a simple on-off clickable button and is available with consumer-oriented accessories including a silicone wristband and keychain holder. The RadBeacon Dot provides proximity services for iOS and Android mobile applications and other platforms that are compatible with iBeacon, AltBeacon and Eddystone microlocation technology.

Proximity beacons are short range, low power, Bluetooth Smart transmitters that can notify mobile devices when they come within range of a beacon. This micro-location proximity awareness can be leveraged to deliver a wide range of new innovative solutions, such as right-place, right-time customer notifications, precision indoor navigation, automatic ticketing, guided museum tours and location-relevant offers and promotions. The RadBeacon Dot is inexpensive and easy to customize, so it’s the perfect beacon for handing out at conferences and promotional events. The Dot is also small, lightweight and easy to use so it great for consumer applications that require attaching it to a keychain or wearing it on a wristband.

“We’re excited about the Dot because it’s going to enable a whole new range of solutions from our developer partners.” said David Helms, Chief Product Officer at Radius Networks.

“The RadBeacon Dot has been in development for quite a while. In fact, we used it extensively for the first time in January at this year’s Consumer Electronics Show in Las Vegas,” said David Young, Chief Engineer at Radius Networks. “At CES we deployed nearly 1,000 proximity multi-beacons that covered over 4 million square feet to provide indoor navigation and location services – the largest deployment of its kind. The low cost and ease of deployment of the Dot was a major contributor to the success of that project.

“RadBeacon Dot is a great addition to our suite of proximity technologies. There are now over a million users of Radius Networks’ beacon developer kits, developer tools, cloud services and mobile SDKs and libraries for iOS and Android devices. The introduction of the RadBeacon Dot proximity beacon with iBeacon, AltBeacon and Eddystone technology is continued proof that Radius Networks is the market leader in the enabling technologies that are helping developers deliver real mobile proximity solutions to their customers.”

RadBeacon Dot is available for sale and shipment in quantity to customers worldwide.

Radius Networks Announces Support for New Open Beacon Format From Google

Screen Shot 2018-11-20 at 11.04.03 AM.png

Radius Networks releases proximity software, services and beacons compatible with the Eddystone platform, the new beacon format from Google

Radius Networks, Inc., the leading provider of mobile proximity beacons and services, today released support for the Eddystone platform, the open beacon format from Google.

Eddystone is an open, scalable BLE beacon format for quickly deploying real-world location context for apps. Eddystone supports several formats appropriate for different use cases, including “Eddystone-UID” and “Eddystone-URL,” which succeeds UriBeacon. Radius Networks builds beacons and tools supporting both of these formats in addition to the “Eddystone-TLM” frame that gives extra telemetry data.

“Two years ago, many people didn’t know what a beacon was. Today we are excited to take another step into the future supporting the new Eddystone format from Google,” added Marc Wallace, CEO and Co-Founder, Radius Networks. “This year, we are deploying hundreds of thousands of beacons with companies hustling to take advantage of the benefits that proximity networks can provide to their customers, users and business.”

Radius Networks has been working with Google to include Eddystone, the new open beacon format from Google, and is providing support across its industry-leading beacons, software and services. Developers can purchase development beacon kits directly from the Radius Networks Store. Radius Networks’ Android Beacon Library and Beacon Locate app have been updated to support the new beacon formats, and its Campaign Kit and Director devices are also compatible with the new beacons.

“Radius Networks released the AltBeacon open proximity standard as a solution available across all mobile platforms two years ago. Today, over 150 million app users leverage open source software authored and managed by Radius Networks,” said David Young, Chief Engineer, Radius Networks. “We are excited to see Google contributing to the open proximity community with the Eddystone platform. This will enable consumers and businesses to take advantage of a whole new set of proximity-based experiences leveraging Google services.”

Introducing Eddystone, The New Beacon Format From Google

By David G. Young

With Eddystone™, the new beacon format from Google, developers making beacon-enabled apps now have more options than ever. If you’re looking to build a new beacon-enabled app, or if you already have beacon apps, it’s important to understand what Eddystone can do.

What is Eddystone?

Eddystone has significant differences from the other major standards. The first Bluetooth LE beacon type to gain popularity was the Apple-proprietary iBeacon™ standard starting in late 2013. It has since been joined by the open-source AltBeacon standard and the various, closed proprietary systems. Now Eddystone adds yet another open source standard to the mix.

Eddystone AltBeacon iBeacon Proprietary

Range ~50 meters ~50 meters ~50 meters ~50 meters

Official Android Support YES YES Unofficial YES

Official iOS Support YES YES YES YES

Open standard? YES YES NO NO

Multiple Vendors YES YES YES NO

Identifiers 10 byte namespace 16 byte id1 16 byte UUID single 

6 byte instance 2 byte id2 2 byte major  

 2 byte id3 2 byte minor 

Interoperable with iBeacon? NO YES YES NO

Introduced July 2015 July 2014 June 2013 Various

Since all of these beacon types are based on Bluetooth LE, they all have a similar radio range of up to 50 meters. Where they start to differ is in how you use them. All of these beacon types work on iOS, but Apple provides no official support for iBeacon on the Android platform. The AltBeacon standard adds that official support through a beacon standard that is open source and cross-platform.

The new Eddystone standard doesn’t provide the same iBeacon interoperability, because the identifier layout of Eddystone is incompatible with the iBeacon standard. Where both iBeacon and AltBeacon use a three-part identifier that totals 20 bytes, Eddystone uses a two-part identifier totalling only 16 bytes. This can make it tricky to use Eddystone alongside existing or new iBeacon-based systems. This decision, however, allows Google to put some innovative capabilities into Eddystone.

Multi-Beacon Capability

Eddystone supports the concept of telemetry, a special type of beacon transmission that contains metadata about how the beacon is operating. This includes both battery level and temperature.

Eddystone also supports the multi-beacon concept. This means that a single hardware beacon sends out multiple transmissions that can be used independently. The telemetry packet transmission, separate from the main identifier packet, is one example of this. While Google is not the first company to invent multi-beacons (Radius Networks developed an iBeacon/AltBeacon interleaving model over a year ago), it is the first one to combine multi-beacons into a single standard.

The multi-beacon consists of three separate beacon frames:

  • Eddystone-UID. This is the main transmission and consists of a two part identifier (10 bytes for the namespace and 6 bytes for the instance) as well as a one-byte transmitter power calibration value, which is used for distance estimates.

  • Eddystone-TLM. This contains telemetry information including the packet version (always a one-byte value of 0 for now), the beacon temperature (2 bytes), the beacon battery level (2 bytes), the number of seconds the beacon has been powered (2 bytes) and the number of “PDU” packet transmissions the beacon has sent (2 bytes.)

  • Eddystone-URL. This is an alternative transmission to the Eddystone-UID that sends out a compressed 17 byte URL instead of a numeric identifier. The idea is that an app detecting the beacon can go directly to this URL without the app having to convert a beacon numeric identifier to destination web address. This Eddystone frame is the new replacement for the existing URI Beacon, an open standard also sponsored by Google.

In addition to the above, Eddystone actually uses a fourth frame, which is a standard iBeacon frame. The primary purpose of this frame is so Eddystone can leverage the iBeacon standard’s special ability to wake up iOS apps in the background, at which time they can start consuming the three frames above. That said, there’s nothing stopping you from using the iBeacon frame for your own purposes.

Choosing Which Frames to Use

Not all of these frames have to be used at the same time. In fact, beacons based on Eddystone can be configured to turn off some of these frames to save battery power or reduce noise.

The first choice you probably want to make is whether you want to use the Eddystone-URL capability. The main advantage of Eddystone-URL is that it allows you to build your app and then have completely different people deploy beacons that send your app to specific URLs. If this capability matches your use case, then it is a good choice. For more general beacon use cases you probably want to stick to Eddystone-UID.

With that decision out of the way, you can decide whether you want to use telemetry. Eddystone-TLM typically isn’t transmitted as often as the other frames—about once per second. It therefore has less of an impact on battery and radio noise. If you know you won’t be using telemetry, you can always disable it.

Setting Your Beacon Identifiers

Eddystone has a two part identifier that consists of a 10 byte namespace identifier and a 6 byte instance identifier. You typically use the namespace ID to signify your company or organization, so you know when a beacon is yours.

You can generate a namespace identifier with a UUID generator. But because standard UUIDs are 16 byte identifiers and namespace identifiers are only 10 bytes, you drop the middle six bytes from the UUID. This technique is especially useful if you already have an iBeacon Proximity UUID assigned for your company or organization, allowing you to use an equivalent organizational identifier for both formats. Below is an example of such a conversion.

iBeacon Proximity UUID:  2f234454-cf6d-4a0f-adf2-f4911ba9ffa6
Eddystone Namespace ID:  0x2f234454f4911ba9ffa6

Google also prescribes a second technique for generating a UID out of a URL. So you can algorithmically convert a domain name you own like http://www.radiusnetworks.com into a unique namespace id. Because this technique uses a one way hashing algorithm, there is no way to convert the namespace id back to a URL. You can use tools like RadBeacon Android to generate namespace identifiers from both URLs and UUIDs, and configure the field directly into the beacon.

The instance identifier is meant to uniquely identify a specific beacon. You usually will want to put a serial number in each one of these. If you have two beacons, you can give the first one an instance id of 1, and the second one an instance id of 2. Because the field is 6 bytes long (48 bits), there are 248 = 281 trillion combinations. That’s a lot of beacons.

For the purposes of this example, we will assume that the beacon is using a namespace ID of 0x2f234454f4911ba9ffa6 (the Radius Networks default) and an instance id of 1. These are the same identifiers that are pre-configure into the Beacons with ship with Eddystone support.

Getting Beacons

If you want to get started with Eddystone, you can buy a developer kit that includes hardware beacons from our Radius Networks store. These beacons can be configured with our free Android RadBeacon config app, which allows you to set the identifiers and URL (in case you are using Eddystone-URL) and set transmitter power and other options.

Building Apps

To learn more details about how you can build an app with Eddystone, see our companion post Building Apps With Eddystone.

Visit us here to access to more Radius Networks products that support Eddystone.

Building Apps with Eddystone

By David G. Young

With Eddystone™, the new beacon format from Google, developers have more options than ever in buidling beacon applications. To understand the basics of working with Eddystone, it’s useful to show the process of putting together an app. If you are new to Eddystone, check out our companion blog post, Introducing Eddystone.

This example will focus on making an Android app using the Android Beacon Library, which fully supports Eddystone. If you want to try this yourself, you’ll need an Android device with 4.3+ and a computer with an Android Studio development environment. Of course, if you actually want the app to respond to beacons, you’ll need a beacon that supports Eddystone, too.

Creating Your Project

To begin, create a new project in Android Studio, selecting the “Blank Activity” template and naming your activity “RangingActivity”.

The first thing you need to do is add the Android Beacon Library into your dependencies. To do this, open up your build.gradle (module: app) file, which should look like this:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.1.0'
}

Edit the above to add a line for Android Beacon Library support like this:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.1.0'
    compile 'org.altbeacon:android-beacon-library:2.3.5+'
}

Coding the Activity

Now that you have beacon support in your project, you can edit the RangingActivity.java class to add beacon detection code. The boilerplate for the class that was Generated by Android Studio looks like this:

public class RangingActivity extends ActionBarActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_ranging);
    }


    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        // Inflate the menu; this adds items to the action bar if it is present.
        getMenuInflater().inflate(R.menu.menu_ranging, menu);
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        // Handle action bar item clicks here. The action bar will
        // automatically handle clicks on the Home/Up button, so long
        // as you specify a parent activity in AndroidManifest.xml.
        int id = item.getItemId();

        //noinspection SimplifiableIfStatement
        if (id == R.id.action_settings) {
            return true;
        }

        return super.onOptionsItemSelected(item);
    }
}

We need to make our Activity class implement two interfaces needed to range for beacons: BeaconConsumer and RangeNotifier. These define callback methods when the beacon scanning service is ready and when beacons are discovered in range. We also make a class instance variable for the BeaconManager, which is the main entry point for working with the Android Beacon Library. The top of the class definition should now look like this:

    public class RangingActivity extends ActionBarActivity implements BeaconConsumer, RangeNotifier {
        private BeaconManager mBeaconManager;

Next, we override the onResume method:

@Override
public void onResume() {
    super.onResume();
    mBeaconManager = BeaconManager.getInstanceForApplication(this.getApplicationContext());
    // Detect the main Eddystone-UID frame:
    mBeaconManager.getBeaconParsers().add(new BeaconParser().
            setBeaconLayout("s:0-1=feaa,m:2-2=00,p:3-3:-41,i:4-13,i:14-19"));
    mBeaconManager.bind(this);
}

This method gets called when the Activity appears, and is a good place to initialize our beacon logic. Here, we get an instance of the BeaconManager and then configure it to detect Eddystone-UID frames. The setBeaconLayout method will tell the Android Beacon Library how to decode an Eddystone UID frame. You don’t need to understand the layout string – just know that his defines the format of the frame to the beacon parser. The last line of the method binds the app to the library’s beacon scanning service, so it can start looking for beacons. When it is ready to find beacons, it calls back to the onBeaconServiceConnect method, which we will define like this:

@Override
public void onBeaconServiceConnect() {
    Region region = new Region("all-beacons-region", null, null, null);
    try {
        mBeaconManager.startRangingBeaconsInRegion(region);
    } catch (RemoteException e) {
        e.printStackTrace();
    }
    mBeaconManager.setRangeNotifier(this);
}

In this method, we define what’s called a beacon Region, which is a way to set a matching pattern of what beacons you are interested in. By creating an “all-beacons-region” with null values for all identifiers, this tells the library that we want to know about any beacon we see. The startRangingBeaconsInRegion method tells the library to start looking for beacons that match this region definition. The last line sets the rangeNotifier to this class, so our the same RangingActivity class will get callbacks each time a beacon is seen. That callback method can be defined as follows:

@Override
public void didRangeBeaconsInRegion(Collection<Beacon> beacons, Region region) {
    for (Beacon beacon: beacons) {
        if (beacon.getServiceUuid() == 0xfeaa && beacon.getBeaconTypeCode() == 0x00) {
            // This is a Eddystone-UID frame
            Identifier namespaceId = beacon.getId1();
            Identifier instanceId = beacon.getId2();
            Log.d("RangingActivity", "I see a beacon transmitting namespace id: " + namespaceId +
                    " and instance id: " + instanceId +
                    " approximately " + beacon.getDistance() + " meters away.");
            runOnUiThread(new Runnable() {
                public void run() {
                    ((TextView)RangingActivity.this.findViewById(R.id.message)).setText("Hello world, and welcome to Eddystone!");
                }
            });
        }
    }
}

This method gets called about once per second with a list of all beacons that are visible. The method loops through this list of beacons and checks to see if any of them are Eddystone-UID frames. You can tell if a beacon is an Eddystone beacon because it will have a serviceUuid of 0xfeaa, and a beaconTypeCode of x00. (For the Eddystone-TLM frame, the beaconTypeCode will be 0x20 and for Eddystone-URL the beaconType code will be 0x10).

If it is an Eddystone-UID frame, we access the two identifiers (the namespace identifier and the instance identifier) as well as the estimated distance and log them with the Log.d statement above.

Next we adjust the user interface of our app to say “Hello world, and welcome to Eddystone!”

The last thing we need to do to our RangingActivity class is unbind from the BeaconManager when the activity closes. This will tell the library it can stop being active, which will save battery. We put this code in the onPause method:

@Override
public void onPause() {
    super.onPause();
    mBeaconManager.unbind(this);
}

If you have made all of the changes above, your activity class should look like this:

public class RangingActivity extends ActionBarActivity implements BeaconConsumer, RangeNotifier {

    private BeaconManager mBeaconManager;

    @Override
    public void onResume() {
        super.onResume();
        mBeaconManager = BeaconManager.getInstanceForApplication(this.getApplicationContext());
        // Detect the main Eddystone-UID frame:
        mBeaconManager.getBeaconParsers().add(new BeaconParser().
                setBeaconLayout("s:0-1=feaa,m:2-2=00,p:3-3:-41,i:4-13,i:14-19"));
        mBeaconManager.bind(this);
    }

    public void onBeaconServiceConnect() {
        Region region = new Region("all-beacons-region", null, null, null);
        try {
            mBeaconManager.startRangingBeaconsInRegion(region);
        } catch (RemoteException e) {
            e.printStackTrace();
        }
        mBeaconManager.setRangeNotifier(this);
    }

    @Override
    public void didRangeBeaconsInRegion(Collection<Beacon> beacons, Region region) {
        for (Beacon beacon: beacons) {
            if (beacon.getServiceUuid() == 0xfeaa && beacon.getBeaconTypeCode() == 0x00) {
                // This is a Eddystone-UID frame
                Identifier namespaceId = beacon.getId1();
                Identifier instanceId = beacon.getId2();
                Log.d("RangingActivity", "I see a beacon transmitting namespace id: " + namespaceId +
                        " and instance id: " + instanceId +
                        " approximately " + beacon.getDistance() + " meters away.");
                runOnUiThread(new Runnable() {
                    public void run() {
                        ((TextView)RangingActivity.this.findViewById(R.id.message)).setText("Hello world, and welcome to Eddystone!");
                    }
                });
            }
        }
    }

    @Override
    public void onPause() {
        super.onPause();
        mBeaconManager.unbind(this);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_ranging);
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        // Inflate the menu; this adds items to the action bar if it is present.
        getMenuInflater().inflate(R.menu.menu_ranging, menu);
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        // Handle action bar item clicks here. The action bar will
        // automatically handle clicks on the Home/Up button, so long
        // as you specify a parent activity in AndroidManifest.xml.
        int id = item.getItemId();

        //noinspection SimplifiableIfStatement
        if (id == R.id.action_settings) {
            return true;
        }

        return super.onOptionsItemSelected(item);
    }
}

Updating the Layout

If you have the above code in place, you’ll notice there is an undefined symbol error for R.id.message. This is the identifier of the field we want to update on our Activity layout when a beacon appears. To fix this error, we need to modify the layout for the Ranging Activity so this TextView field has an identifier. Edit the file res/activity_ranging.xml and change the TextView definition to look like this:

<TextView android:text="@string/hello_world" android:layout_width="wrap_content"
  android:layout_height="wrap_content" android:id="@+id/message"/>

Running the App

When you run the app without a beacon nearby, it will display a simple “Hello world” message on a white screen. Once it comes in range of a beacon, this screen will change to show you “Hello world, and welcome to Eddystone!”

To try this out, turn off your beacon that supports Eddystone and launch the app. Turn on the beacon, and watch the app react!

If you don’t want to type everything in from above, you can download a working copy of the source code for this example app here.

Next Steps

Obviously, this is a very simple app, but it demonstrates the basics of working with Eddystone. More complex apps that support Eddystone may be built that react differently based on the presence of different beacons, and react with data coming from cloud-based servers. You can even make the apps perform special functions depending on how far you are away from the beacon—one meter, ten meters or more.

While this example just focuses on how to work with the main Eddystone-UID frame, you can see other coding examples of using the Eddystone-TLM and Eddystone-URL frames in the documentation for the Android Beacon Library.

Visit us here to access to more Radius Networks products that support Eddystone.

Announcing Director for Android

By Aaron Kromer

We are delighted to announce the release of our RadBeacon Director app for the Android mobile operating system.

With RadBeacon Director, any Bluetooth LE capable Android phone or tablet can be turned into a proximity beacon network monitor linked to your Director deployments.

RadBeacon Director is the beacon fleet management app for Radius Networks RadBeacon Bluetooth Smart proximity beacons. The RadBeacon Director app, working with the Director cloud service, enables you to:

  • Monitor the health and status of your beacons

  • Review the configuration of your beacons

  • Validate the proximity performance of your beacons

With the RadBeacon Director app, you’ve got beacon fleet management under control.

The Radius Networks team remains committed to building the features and services necessary to promote Android as a first-class citizen in the world of beacons and proximity services.

If you are new to proximity beacon network management head on over to Director to get started for free today!

Screen Shot 2018-11-20 at 10.55.54 AM.png