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

Update on iOS Beacon Monitoring in the Background

By Emma Hobday & Blake Middleton

One of the most fundamental uses of beacons is their ability to interface with an app and wake up a sleeping mobile device. If the mobile device doesn’t wake up, however, the beacons and the apps that utilize them are next to useless. This post is an update of our 2013 post on Beacon Monitoring in the Background and Foreground. For this update, we tested the time delay between entering or exiting a beacon region and when a local notification was displayed on the lock screen of various Apple iOS mobile devices.

We tested an iPhone 6, an iPhone 5, two iPhone 4S’s, and an iPod Touch 3rd generation, all of which were running on iOS 8.3, as well as an iPhone 4S that was running on iOS 8.1. All the devices had bluetooth turned on, as necessary to interface with beacons, and both wifi and cellular data turned off. Testing was done using the Radius Networks Locate Beacon app for iOS. All devices were tested in the locked state with the screen off, so that any notifications would appear on the lock screen. None of the devices were plugged in.

All mobile devices tested generated local notifications representing a beacon region enter event similarly within a range of 1 to 10 seconds. Notifications representing a beacon region exit event were slower, in the 35 second range, and happened less reliably.

Device Avg. Wakeup Time Range in Wakeup Times Avg. Exit Time . Frequency
of No Exit
Notification
(# none/#trials)

4S 1 s 1-2 s 36 s 5/7

5 4 s 1-7 s 42 s 1/6

6 5 s 1-12 s 35 s 7/10

iPod 3 7 s 1-10 s (1:41 outlier) 42 s 5/10

Exit time is a measure of how long it took for the device to generate a local notification that a beacon region exit event occured after it has stopped receiving advertisements from a test beacon. In some instances no exit notification occurred, but those trials were not used in calculating the averages. The cutoff time for a trial counting as no notification was usually 2 minutes, though a few trials of a 5 minute were also used, yielding no additional results. Additional investigation is warranted to understand why our test setup failed, in some cases, to result in consistent region exit notifications.

Interestingly, notifications representing region enter events were faster on the iOS 8.1 iPhone 4S, while at the same time battery drain on this iPhoe 4S device appeared to be much higher. One explanation for this may be due to power optimizations in later versions of iOS or more optimized hardware in the later models.

Being plugged in improves the wakeup times of both the iPhone 6 and the iTouch 3 to average around one second, indicating the power management optimizations may play a role in the detection times for iOS devices.

Troubleshooting Notes

  • Sometimes if a device isn’t sending notifications in the lock screen, this can be solved by opening the app and waiting for information to update in the foreground, turning back on notifications.

  • Sometimes devices just won’t recognize when they’ve left the zone of an active beacon.

  • As discussed in a previous post Background Monitoring of Beacon Regions on iOS, beacon apps notify about entering beacon zones much more slowly on devices that already have a lot of beacon-using apps installed, in the realm of ten to twenty minutes instead of 3 seconds.

Campaign Kit on Android Wearables

By Christopher Harper

Smartwatches have grown in popularity in the past year, originating with the Pebble smartwatch on Kickstarter. Then Android followed suit over this summer with Android Wear. These devices with their portable and quick nature lend themselves well to CampaignKit, displaying a nice little chunk of information in a manner similar to a push notification. The following will show you how to pop campaign information on Android Wear devices and the Pebble.

Campaign Kit is a cloud based service coupled with mobile SDKs that allow one to deliver targeted messaging - campaigns to mobile devices within proximity of any place and time of your choosing. Campaign Kit provides an advanced interface to create or upload rich content to be be delivered to your customer’s mobile devices around specific campaign criteria such as proximity far (geofence), near (beacon), time, schedule, etc.

It is assumed you are familiar with Android Studio, and you have an active campaign to display.

##Setup

First you are going to need the Android Studio CampaignKit reference app provided here. Follow the instructions there and make sure that your campaign triggers in the app before continuing.

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


##Android Wear

Requires Android 4.3

Unless you already have an Android Wear device you are going to need to set up an emulator to receive the CampaignKit message. Documentation for setting up an emulator can be found here.

The following code builds a notification to send to the Android Wear device and then sends it. This is most naturally placed in your didFindCampaign(Campaign c) method.

Intent viewIntent = new Intent(this, MainActivity.class);
PendingIntent viewPendingIntent = PendingIntent.getActivity(this, 0, viewIntent, 0);
NotificationCompat.Builder notificationBuilder = new NotificationCompat.Builder(getApplicationContext())
        .setSmallIcon(R.drawable.ic_launcher)
        .setContentTitle(c.getTitle())
        .setContentText(c.getMessage())
        .setContentIntent(viewPendingIntent);
NotificationManagerCompat notificationManager = getSystemService(Context.NOTIFICATION_SERVICE);
notificationManager.notify(001, notificationBuilder.build());

The viewIntent used in viewPendingIntent is where you can decide what kind of interaction you want the user to be able to have with the notification. Perhaps you would like a promotion to be opened on the phone? In this case we reopen the reference app. If you simply want the notification to be dismissed upon reading, the intent is unnecessary.

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



##Pebble

Requires Android 4.0

Because Pebble is not specific to Android it has a separate framework. More documentation can be found at developer.getpebble.com. In order to get a notification to the Pebble we need the following.

In build.gradle we need to add the pebble dependencies and repositories.

    dependencies {
		compile 'com.getpebble:pebblekit:2.6.0'
	}
	repositories {
		mavenCentral()
		maven { url "https://oss.sonatype.org/content/groups/public/"}
	}

It is very important that you resync your project at this point. It may take a while as it downloads pebblekit.

Pebble uses JSON structures to communicate packets of data between the watch and companion app so the following imports must be included.

import org.json.JSONArray;
import org.json.JSONObject;

Finally we need to build our notification to send. This should be included in didFindCampaign(Campaign c) just like the Android Wear notification.

final Intent i = new Intent("com.getpebble.action.SEND_NOTIFICATION");
    final Map data = new HashMap();
    data.put("title", c.getTitle());
    data.put("body", c.getMessage());
    final JSONObject jsonData = new JSONObject(data);
    final String notificationData = new JSONArray().put(jsonData).toString();
    i.putExtra("messageType", "PEBBLE_ALERT");
    i.putExtra("sender", "MyApplication");
    i.putExtra("notificationData", notificationData);
    sendBroadcast(i);

This type of notification can only be dismissed. The recent Pebble Beta supports Android Wear style notifications following the same procedure as for the Android Wear device. Keep in mind when testing that Pebble does not display duplicate messages. So everytime you send a test notification to the Pebble make sure to change the ContentText in order for the notification to actually appear.

Proximity Kit and PhoneGap/Cordova

By James Nebeker

Developing Cross-platform Beacon Enabled Apps With PhoneGap/Cordova and Proximity Kit

PhoneGap and its open source counterpart, Cordova, are powerful tools for easily developing mobile apps for multiple platforms. Rather than having to build and maintain separate projects for different operating systems, you can concentrate on a single project and let PhoneGap/Cordova build the native iOS/Android code almost instantly. With the extensive integration with native components (e.g., camera, device motion) it’s easy to seamlessly build Cordova/PhoneGap apps that appear identical to native apps without having to learn a snippet of native code. It was with this in mind that we developed the Proximity Kit Cordova Plugin, which brings Proximity Kit’s powerful location features to the PhoneGap/Cordova platform. With the plugin it’s easy to add proximity beacon capabilities to your project, and it works with both iOS and Android. This post will outline the steps needed to add the Proximity Kit Plugin to your PhoneGap/Cordova project and get you up and running with beacon enabled apps in no time.

Getting Started With Proximity Kit

First things first, you’ll need to make sure you sign up for Proximity Kit (it’s free) and create your first kit. If you haven’t already, go to the Proximity Kit page and create an account, then go to your kits page and create your first kit. Add at least one beacon to your kit, you can choose any identifiers you’d like but you will need a way to transmit those identifiers later on when testing your app (either with beacon hardware or with another mobile device that has BLE transmit capabilities). Once your kit is set up, download its config files for Android and iOS (the download links are on the left side of the kit page) and stash them in a safe place for later.

Installing the Plugin

From here on out I’m going to assume you’re developing with Cordova to avoid having to write each command twice. But have no fear, all of these steps will work just the same if you’re using PhoneGap. I’ll also assume you already have a Cordova project set up, if not you can also clone the reference project for the plugin or start from scratch by running the cordova create command:

$ cordova create hello com.example.hello HelloWorld

The Proximity Kit Plugin is distributed via Github, to add it to your Cordova project run the following command:

$ cordova plugin add https://github.com/RadiusNetworks/proximitykit-plugin-cordova

This will add the plugin to your project’s config.xml file and will copy various files into the native src directory for your platforms.

For this demo we’ll also need the Cordova console plugin so we might as well install that now:

$ cordova plugin add org.apache.cordova.console

Now that the Proximity Kit plugin is installed we can start to incorporate it into your project’s JavaScript.

Triggering Beacon Events in Your Cordova App

After adding the Proximity Kit plugin to your project, there is no need to explicitly require any Proximity Kit JavaScript files in your own code. The plugin manifests itself in JavaScript as radiusnetworks.plugins.proximitykit. There are two methods on this object: watchProximity and clearWatch. The first, watchProximity, takes two handler functions upon initialization and returns a watchId as a way to cancel Proximity Kit callbacks later if desired (using the clearWatch method). The first handler, successHandler, is a function that receives a message object from Proximity Kit on a periodic basis. The message object always has an eventType associated with it, stored as a String. The second handler function, failureHandler, is a function that receives a message containing the failure message as a String. To see a full list of the different Proximity Kit event types and the data associated with these events, check out the plugin’s README on GitHub.

To start receiving Proximity Kit event callbacks, we just need to set up the two handler functions in your project’s index.js file and then call watchProximity in the app function of the same file. To keep things simple for this demo we’ll just set up the handlers to log the event, here’s what the JavaScript for the two handlers will look like:

var proximityKitSuccessHandler = function(message) {
    // Obtain event type from message object
    var pkEventType = message[radiusnetworks.plugins.proximitykit.constants.keys.eventType];
    var beacon = null;

    // Log beacon information if receiving a ranging callback
    if (pkEventType == radiusnetworks.plugins.proximitykit.constants.eventTypes.rangedBeacon) {
      beacon = message[radiusnetworks.plugins.proximitykit.constants.keys.beacon];
      if (beacon != null) {
        console.log("Proximity Kit Event: " + pkEventType + " " + JSON.stringify(beacon));
      }
    }
    // Log event type if receiving another type of callback
    else {
      console.log("Proximity Kit Event: " + pkEventType);
    }
};

var proximityKitFailureHandler = function(message) {
    console.log("Failure: Response from plugin is " + message);
};

Now just add the watchProximity call inside onDeviceReady and that’s it, you’re ready to build the project:

onDeviceReady: function() {

    watchId = radiusnetworks.plugins.proximitykit.watchProximity(proximityKitSuccessHandler, proximityKitFailureHandler);
},

Integrating Proximity Kit

If you haven’t already, add the desired platforms to your Cordova project:

$ cordova platform add android
$ cordova platform add ios

Next, remember those config files we downloaded earlier when setting up our kit on Proximity Kit? You should have a ProximityKit.plist file (for iOS) and a ProximityKit.properties file (for Android). Copy these files into the following locations depending on your platform:

PlatformLocation of Proximity Kit configuration fileiOS./platforms/ios/Your App’s Name/ProximityKit.plistAndroid./platforms/android/src/ProximityKit.properties

Now there are a couple more steps for each platform to add Proximity Kit dependencies to the app.

iOS

In addition to placing the ProximityKit.plist file inside the iOS project’s directory structure, you need to add the file to the Xcode project and to the appropriate target:

  1. Open the project in Xcode (platforms/ios/Your App’s Name.xcodeproj)

  2. Select your app’s target and select “Add Files to ‘Your App’s Name’” from the File menu.

  3. Locate your ProximityKit.plist file and click “Add”

For iOS, Proximity Kit uses SQLite internally so you need to link to it in the project in Xcode manually after the app is built in Cordova/PhoneGap.

  1. Select the App’s target in Xcode

  2. Choose “Build Phases”

  3. Under the “Link Binary With Libraries” section click the ‘+’ to add another library

  4. Choose libsqlite3.dylib and click “Add”

Lastly, in order to use Location Services you will need to add a ‘NSLocationAlwaysUsageDescription’ string to the ‘Info.plist’ file in your iOS app. Without this, your device will not send beacon information to your app. The screenshot below shows an example of this:


Android

To allow background triggering of beacon events on Android the plugin has a custom application subclass (which can’t be setup automatically by Cordova). To implement this in the app edit the AndroidManifest.xml file (platforms/android/AndroidManifest.xml) to include the proper android:name tag under application for the ProximityKitCordovaAppication class. For example, here is the application header for the Proximity Kit plugin reference app:

<application android:name="com.radiusnetworks.cordova.proximitykit.ProximityKitCordovaApplication" android:hardwareAccelerated="true" android:icon="@drawable/icon" android:label="@string/app_name">

Running the App

Note: You need to run your app on a Bluetooth LE-enabled device in order to detect beacons, Android and iOS emulators currently do not have the ability to test beacon functionality.

Running From the Command Line

To build, install, and run the app on your Android device, execute the following command in the project directory:

$ cordova run --device android

Similarly for iOS:

$ cordova run --device ios

Note that running the app from the command line for iOS can be extremely slow. Running the app from Xcode for iOS is recommended.

Running From Xcode

  1. Open the following project in Xcode if you have not already done so.

  2. Select the “Hello Beacon” scheme and your iOS device.

  3. Run the app by choosing “Run” from the “Product” menu.

Testing With a Beacon

Now that the app is up and running, fire up a beacon that matches the identifiers you configured in your kit. You should see the Proximity Kit events being logged in the debug console. Note that on Android your device will only be able to detect beacons following the AltBeacon specification by default. If you wish to detect other proprietary beacons on Android, you can set a BeaconParser supplying the proprietary beacon format (you can search Google for BeaconParser formats) in the onCreate method inside the ‘ProximityKitCordovaApplication.java’ file located in the Android app source code:

@Override
public void onCreate()
{
  super.onCreate();
  Log.d(TAG, "onCreate");
  pkManager = ProximityKitManager.getInstanceForApplication(this);
  pkManager.setProximityKitSyncNotifier(this);
  pkManager.setProximityKitMonitorNotifier(this);
  pkManager.setProximityKitRangeNotifier(this);
  pkManager.getBeaconManager().setDebug(true);

  // Replace the beaconLayoutString with your custom format and uncomment the two lines below
  //String beaconLayoutString = "m:2-3=BEAC,i:4-19,i:20-21,i:22-23,p:24-24";
  //pkManager.getBeaconManager().getBeaconParsers().add(new BeaconParser().setBeaconLayout(beaconLayoutString));

  pkManager.start();
}

You’ll also need to import BeaconParser at the top of ‘ProximityKitCordovaApplication.java’:

import org.altbeacon.beacon.BeaconParser;

Now you’ve successfully built a beacon-enabled Cordova/PhoneGap app!

What’s Next?

Now that you’re receiving Proximity Kit callbacks in your app’s JavaScript, you’re ready to build an awesome app that can trigger content or notifications based on proximity (and works seamlessly on both Android and iOS). Be sure to checkout the Proximity Kit plugin’s README for the complete list of event types and their associated data. If you have any questions or comments drop us a line at support@radiusnetworks.com.



Background Monitoring of Beacon Regions on iOS

By Christopher Sexton

At Radius Networks, we’ve had our SDKs added to a ton of beacon apps, and we’ve tested a large percentage of them.

One of the most frustrating things about working with beacon-enabled apps is testing background triggering. Usually, iPhone 5 and later trigger in the background within a second of seeing a beacon. But sometimes it takes longer. Much longer.

In many cases, we have observed iOS devices behaving as if some sort of beacon region monitoring resource limit had been exceeded. So we had a question…

What is the maximum number of beacon regions you can monitor in the background on iOS?

Apple’s documentation states that each app has a limit of 20 beacon regions, but the documentation doesn’t say anything about a global limit for a device. We decided to investigate if such a limit exists and how exceeding that limit may affect beacon region monitoring behavior.

The results of our investigation are that a global beacon region monitoring limit does exist. The regions are registered first-in-last-out, so that the first regions registered are in the “priority” group, and the latter ones will get bumped to the “best effort” group.

The priority group can contain up to 30 beacon regions. Applications will receive almost immediate region monitoring call backs (ie didEnter Region & didExit Region) for priority group beacon regions regardless of the state of the iOS device, including the black screen state, lock screen state, springboard state and all application states.

The best effort group contains beacon regions registered beyond the 30 beacon region limit. Applications may experience significantly delayed region monitoring call backs based on the state of the mobile device. For example, if a mobile device is in the black screen state, meaning the screen is not illuminated at all, applications may never receive region monitoring call backs for best effort group beacon regions until the user or some event like a push notification, calendar reminder or text message causes the device to wakeup.

Limiting the priority group to the first 30 registered beacon regions seems fairly small given that each app can register up to 20 regions, so we believe this is a very significant finding.

What might be happening?

Apple’s iOS CoreLocation framework is closed source, so this is just speculation, but our best guess is that there is hardware support for monitoring a limited number of beacon regions. After those slots are taken, iOS falls back to software monitoring and makes a best effort to monitor for beacon regions. However in an effort to save battery life iOS may suspend beacon region monitoring by device power management.

What does this mean for you?

What does this mean to you as a developer of beacon-enabled apps on iOS? If your app is not one of the first ones to be installed on an iOS device, your app may be ineligible for fast background detection and relegated to the slow lane. It is therefore important to design your app to take this possibility into account. You must set expectations appropriately when telling clients and app testers how quickly background detections will take place. Since testers are especially likely to have multiple beacon-enabled apps on their devices, and therefore most likely to experience the delays described here. To speed up detection during testing, uninstall other beacon-enabled apps and reboot your phone before installing your app for testing.

The Experiment

Baseline Configuration and Procedure

Since there are so many different permutations and testing can take so long, I decided to come up with a baseline configuration to test under. Obviously, this is not necessarily the conditions always seen in the wild, but was the best way to characterize the behavior I’d been noticing.

The experiments were run with the following devices:

  • iPhone 6, iOS 8.3

  • iPhone 5s, iOS 8.3

  • iPad Air 2, iOS 8.3

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

I executed the following procedure to establish a baseline configuration:

  1. Uninstall any app with location (or set the location permission to “Never” in settings)

  2. Reboot the phone

  3. Turn off WiFi in settings

  4. Turn off Cellular Data in settings



On each subsequent run I followed this procedure:

  1. Reboot the phone

  2. Deploy App to phone via Xcode

  3. Accept core location permission

  4. Accept notification permission

  5. Stop the app with “stop” button in Xcode

  6. Disconnect from tether

  7. Put phone to sleep with shoulder button

  8. Wait 1 minute

  9. Enable beacon

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

After test is run, update and redeploy any apps and repeat the steps above.

Running the Experiment

I created an Xcode project with 10 targets that will deploy the same code as 10 different apps. This lets you make minor changes to region settings and redeploy all the apps to the device.

The main approach I took was to install all 10 apps to the device, starting at 1 and going in order. Make sure that each starts up and can see it register the regions in the logs. This would be done with different numbers of regions. For example I might do a run where each app has 5 regions, deploy them all to the phone and run the experiment.

The most predictable way I found to see where this limit is:

  1. Install all 10 apps starting at 1 and going in order

  2. Lock the phone and let the screen go dark

  3. Start at 10 and work backwards to find which beacon triggers the notification

An example run might look like:

10 apps @ 7 regions

App UUID Region Time till notification

10 7 None (5 min wait)

10 6 None (5 min wait)

10 5 None (5 min wait)

10 4 None (5 min wait)

10 3 None (5 min wait)

10 2 None (5 min wait)

10 1 None (5 min wait)

9 7 None (5 min wait)

9 6 None (5 min wait)

9 5 None (5 min wait)

9 4 None (5 min wait)

9 3 None (5 min wait)

9 2 None (5 min wait)

9 1 None (5 min wait)

8 7 None (5 min wait)

8 6 None (5 min wait)

8 5 None (5 min wait)

8 4 None (5 min wait)

8 3 None (5 min wait)

8 2 None (5 min wait)

8 1 None (5 min wait)

7 7 None (5 min wait)

7 6 None (5 min wait)

7 5 None (5 min wait)

7 4 None (5 min wait)

7 3 None (5 min wait)

7 2 None (5 min wait)

7 1 None (5 min wait)

6 7 None (5 min wait)

6 6 None (5 min wait)

6 5 None (5 min wait)

6 4 None (5 min wait)

6 2 None (5 min wait)

6 1 None (5 min wait)

5 7 None (5 min wait)

5 6 None (5 min wait)

5 5 None (5 min wait)

5 4 None (5 min wait)

5 3 None (5 min wait)

5 2 1 second

5 1 1 second

4 7 1 second

4 6 1 second

4 5 1 second

4 4 1 second

4 3 1 second

4 2 1 second

4 1 1 second

3 7 1 second

3 6 1 second

3 5 1 second

3 4 1 second

3 3 1 second

3 2 1 second

3 1 1 second

2 7 1 second

2 6 1 second

2 5 1 second

2 4 1 second

2 3 1 second

2 2 1 second

2 1 1 second

1 7 1 second

1 6 1 second

1 5 1 second

1 4 1 second

1 3 1 second

1 2 1 second

1 1 1 second

Other Variants

I ran this test under many configurations with similar results. I always found the limit to be 29-30 regions. I assume something is going on that registers something in the hardware layer. I am not sure how best to control the configuration, but believe the inconsistency to be a lack of clean baseline.

Other configuration I tried:

  • 10 apps @ 10 regions

  • 10 apps @ 5 regions

  • 10 apps @ 7 regions

  • 1 app @ 20 regions; 9 apps @ 5 regions

  • 1 app @ 20 regions; 9 apps @ 7 regions

Other Experiments

I also ran a number of ad-hoc experiments to see what would happen under other circumstances, but those were often run on just one device and not repeated.

Reboot

Rebooting the device and waiting. The regions were still registered in the same order.

Uninstall

Uninstalling an app does not re-register any best effort regions. So if I removed the app #1, it didn’t free up the “priority” region slots. Most likely this will be freed up as the apps are re-registering or the device is rebooted. But I didn’t try that.

Best Effort Behavior

I spent a fair amount of time trying to characterize region monitoring behavior for beacons in the best effort group. I would often turn on a beacon and wait for up to 30 minutes to see if it would wake up the app and send a notification. Sometimes it would, most of the time it wouldn’t. But then again, I didn’t wait for 30 minutes that often.

Older Models

This research does not characterize the amount of time it takes to detect in the background when the fast background detection slots are exhausted. However, previous research shows that iPhone 4S devices (which apparently do not have fast background detection at all) may take as long as 15 minutes to trigger in the background.

In closing

This was a very interesting couple of days worth of work. I certainly learned quite a bit about how iOS registers beacon regions. I would be curious what your experience is, in particular if you wanted to run controlled tests using the code above.

I also want to note that this is likely to change as Apple makes updates to iOS and their hardware. We already know that there are innate differences in the older iPhone 4 models, and I am sure they will continue to tweak things going forward.

If you run similar experiments let us know, we’d love to compare notes.

Star Wars Celebration

By Michael Harper

R2-D2 Builders Club Launch Beacon-Powered Interactive Droid Experiences at Star Wars Celebration 2015

Today in Anaheim, California, Star Wars Celebration 2015 kicks off four days of Star Wars fan festivities. In addition to a sneak preview ahead of the December release of Star Wars: The Force Awakens, fans will get the chance to finally find the droids they are looking for and participate in special “Jawa Scavenger Hunts” using free mobile apps developed by the R2-D2 Builders Club and using proximity beacon technology from Radius Networks.

The R2-D2 Builders Club has developed two proximity-aware mobile apps for the Star Wars Celebration event. The first of these, the R2FID Scanner app, detects RadBeacon Tags installed on certain droids and displays information specific to the associated droid. The R2FID Scanner app also detects and displays information for vendors, convention-related items, and Rancho Obi-Wan items. The second of these, the R2FID Scavenger Hunt app, detects several special RadBeacon USBs that are installed throughout the convention center. Users who successfully unlock all of these locations in the Scavenger Hunt app can receive prizes from staff in the Droid Builders Room.

Scanner

Using the free Droid Scanner mobile app, developed by the R2-D2 Builders Club, visitors will be able to detect droids equipped with RadBeacon proximity beacons from Radius Networks. Once identified, users of the Droid Scanner mobile app can interrogate each droid and uncover details of its maker, its service history and its role in the Star Wars universe.

The R2FID Scanner app takes advantage of the metadata feature in ProximityKit to attach character name, character type, alliance, real name, location, and other attributes to each beacon attached to a droid. When a beacon is scanned that has not yet been seen by the app, it is displayed in the scan list:




The user can tap on the specific list item to see more information:

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





Scavenger Hunt

Using the free R2FID Scavenger Hunt mobile app, visitors will be able to participate in a special “Jawa Scavenger Hunt” hosted by the R2-D2 Builders Club. Based on the open-source scavenger hunt app from Radius Networks, this customized version of the Scavenger Hunt app detects beacons installed throughout the convention center and unlocks the associated location in the app.

Each of the four days of Star Wars Celebration 2015, R2 Builders running the Scavenger Hunt will place several Radius Networks RadBeacon proximity beacons throughout the Anaheim convention center. When a user approaches within 1 meter of a beacon, the R2FID Scavenger Hunt mobile app will notify them that they have discovered a hidden “Jawa.” Users who find all of the “Jawas” and successfully complete the Scavenger Hunt can win special prizes including special Star Wars Celebration trading cards, bookmarks, pins, and more. The first participant to complete the Scavenger Hunt each day will receive a special poster designed by renowned artist Jamie Snell.





Announcing QuickBeacon for Windows

By Marc Wallace

We are really excited to let you know that we just released our latest proximity beacon product: QuickBeacon for Windows

With QuickBeacon for Windows, any Windows PC or Surface Pro tablet running Microsoft Windows 7 or higher, with an available USB port, can be turned into a fully-configurable, proximity beacon platform.

Set It and Forget It

QuickBeacon is the no hassle solution for deploying iBeacon™ and AltBeacon technology in enterprise environments, for home automation, in point-of-sale solutions, and for so many other applications.

Set it and forget it. No batteries to run down, and it goes wherever you take your PC or Surface Pro tablet.

Beacons at Your Fingertips

QuickBeacon for Windows is going to change how people think about beacon technology. QuickBeacon expands beacon technology beyond standalone devices using specialized hardware. It puts a proximity beacon with iBeacon and AltBeacon technology anywhere you’ve got a PC or Surface Pro tablet. QuickBeacon for Windows is available today from the Radius Networks store. We can’t wait to see what you do with it!

Screen Shot 2018-11-19 at 4.30.50 PM.png

Beacon Navigation at the Consumer Electronics Show

By David G. Young

It’s hard not to get lost at the Consumer Electronics Show. The event is simply huge. My colleague logged over 20,000 steps on his fitness tracker wandering around the show in a single day. The space spans three different halls at the Las Vegas Convention Center, another at the Sands Expo Convention Center, as well as more exhibit and meeting spaces in the Venetian and Westgate hotels. As if that’s not enough, the show spills out into tents scattered over two huge parking lots near the convention center.

This leads everybody to ask the same questions: Where am I? How do I get to booth 26002?

Screen Shot 2018-11-19 at 4.25.21 PM.png



This year, Radius Networks had the answers. We built an indoor navigation system covering 4 million square feet of exhibit and meeting space. Simply opening the maps section of the CES Mobile app for iOS and Android showed which hall you were currently in.

Tapping on the hall name displayed a map centered on your current location marked with a blue dot. And booth 26002? Entering that into the search box (or the name of the exhibitor) highlighted its location, and if not in the same hall, told you where you needed to go.

Building and deploying this system was a big job, partly because of the huge physical space. What’s more, keeping costs down meant abandoning the cookie-cutter solutions of traditional indoor navigation systems.

Because CES is a temporary show, we didn’t have the luxury of using carefully placed permanent wireless access points as reference signals. Because of the huge square footage, we couldn’t spend the time and money it would take to gather RSSI fingerprint samples over 4 million square feet.

What we did do was deploy nearly 1000 low-cost Bluetooth Low Energy beacons on an 18-meter grid around the show. Because access to power supplies was limited, we did this largely with tiny coin-cell powered beacons, although we also used USB-powered beacons with AC adapters where wall power was available. The beacons had to be set to a relatively high advertising rate of 10 Hz in order to get good distance estimates, but this was OK, because even coin cells could power this advertising frequency for the short duration of the show.

Once beacons were deployed, showing the user’s location was a matter of plotting the location of the nearest beacon, with some special logic added to keep the dot from bouncing around. For the tents in outdoor parking lots, we saved money by not deploying beacons at all – we just piggybacked on mobile phones’ GPS capabilities to plot the user’s location the old-fashioned way.

Setting this up quickly was only possible because of lots of preparation and a fine-tuned configuration app that let our team of six mark the locations of placed beacons before moving on to the next one. With less than 48 hours to set up the entire show across four million sqare feet, there was little time to waste. The map below shows the locations of some of the 143 beacons placed around the CES Central Hall.




This image shows just a subset of the huge Central Hall, which is four football fields long and one and a half football fields wide.

Even with all the advanced planning, there were challenges, requiring us to think on our feet. Many exhibitors blocked access to their space with burly security guards, forcing us to find creative places to put our beacons around the perimeter. Some beacons placed near the boundary of two different halls had signals that bled onto the adjacent hall, requiring us to rethink placement. The massive load of tens of thousands of CES attendees arriving and downloading the mobile app all at once required our team back at home to fine tune our servers in real time. And as with any project involving a large amount of mundane, repetitive manual work, there was some human error. Finding and correcting these errors could be time consuming.




Deployment was not even the biggest challenge. Long before we arrived in Las Vegas, we did a huge amount of work to prepare 18 different maps, precisely align them with a reference coordinate system, and update the booth locations as they chenged along with the show. Being able to search for a booth and highlight its location required that a dynamic database be kept up to date as new exhibitors joined the show and changed their booth locations.

While still in our home offices in Washington, DC, we deployed the system at other venues like the Verizon Center, where we tried it out successfully during a crowded Washington Capitals game. Having good venues for testing was critical, due to the tight deadlines on the project. Often engineering deadlines are artificial. In the case of the Consumer Electronics show, there was no way they were going to delay the event if the indoor navigation system wasn’t ready.

The only way this was possible was because we could construct the system on top of other services we’d already built at Radius Networks: our Proximity Kit service (proximitykit.radiusnetworks.com) for managing beacons in the cloud, our Android Beacon Libraryfor bringing beacon detection and ranging capabilities to the Android platform, the AltBeacon standard which brought an open beacon standard to mobile devices, and our new Director service for alerting us if any of these hundreds of beacons went down.


One critical function was to check to see if any beacons were not being detected. On the first day of the show, Director told us a few beacons in the South Hall hadn’t been seen. We used our configuration app to show these beacons’ locations on a map, letting us find them super fast. In one case, the beacon was turned off. In another, the beacon’s identifier was misconfigured, and in yet another, the beacon had gone missing – requiring a replacement.

In the end, all this work paid off. Even though I had spent weeks staring at the maps, I found that even I got lost at CES, too. Finding my way back to the taxi line after two days of setup, I was confused by seeing a Panasonic booth. Wasn’t that in another hall? Where am I? Fortunately, after a few taps on my mobile phone, I saw a friendly blue dot showing me the way.

Screen Shot 2018-11-19 at 4.27.33 PM.png

Fundamentals of Beacon Ranging

By David G. Young

The most basic use of beacon technology is to determine how far a mobile device is from a beacon, but as anybody who has played with beacon ranging knows, these distance estimates can have a significant degree of uncertainty. For a beacon that is 5 meters away, distance estimates might fluctuate between 2 meters and 10 meters.

The reasons for these distance estimate variations and the steps that can be taken to reduce them are some of the most frequent questions we get about beacons. Factors that influence the error in the estimate include reflections of the radio signal, obstructions that attenuate the radio signal, and orientation of both the phone and the beacon.

By far the biggest factor affecting error in distance estimates is radio noise. Background radio noise exists everywhere (it’s what causes the static seen on an old analog TV). For strong radio signals (a high signal-to-noise ratio), noise is far less of an issue than with weak signals (a low signal to noise ratio). For this reason, a device that is within a few meters of a beacon can provide much more accurate distance estimates than a device that is 10 meters or more away.

Apple’s Recommendations

When Apple introduced iBeacon technology in iOS 7, their documentation recommended against direct use of distance estimates. The CLBeacon class that provides access to beacon ranging information has a field that provides an estimate of the distance to the beacon in meters. But instead of calling this property distance, Apple called it accuracy, probably in an effort to discourage its use as a raw distance indicator. The recommended approach is to use it only for comparison between beacons to see which is closest. The CLBeacon class also provides a second property called proximity which bucketizes the distance estimate into “immediate”, “near” and “far” groupings. Apple is vague at the definitions of these buckets, but experimentation shows that “immediate” means about 0.5 meters or less, “near” means about three meters or less, and “far” means more than three meters.

This doesn’t mean that you can’t use beacon distance estimates directly — it just means you first need to understand the fundamentals of how they work and the limitations on the quality of information they can provide.

Reference Transmitter Power

A beacon transmission includes a transmitter power field that indicates how strong the signal should be at a known distance. As an example, when using iBeacon technology, the standard measurement is the signal level that an iPhone 5s (the latest model available when iOS 7 was released) will measure for a beacon at a distance of one meter. Beacons must be calibrated by measuring the signal level (known as Received Signal Strength Indicator or RSSI) at this reference distance and then configuring the beacon to transmit reference value. Values of RSSI are measured in dBm, and a typical one meter calibration value for a beacon transmitter will be -59 dBm. The actual calibration value for different beacons varies because each may have a transmitter and antenna that puts out a different amount of radio power. Some beacons, such as Radius Networks’ RadBeacon products, have configurable transmitter output power.

How Distance Estimates Work

Mobile devices can estimate the distance to the beacon by comparing the signal level they see with the reference signal level. Each time beacon advertisement packet is received, the bluetooth chipset provides a measurement of the beacon’s signal level as RSSI. Because every single beacon transmission also includes the calibration value mentioned above, it is possible to compare the actual signal level with the expected signal level at one meter and then estimate the distance. For example, let’s say the beacon advertisement packet was received with a signal level of -65 dBm and the transmitter power calibration value sent inside the transmission was -59 dBm. Because -65 dBm represents a weaker signal level than -59 dBm (greater negative numbers represent weaker signals) this means the beacon is probably more than one meter away.

You can plug these two numbers into a formula to calculate a distance estimate. Below, you can see the formula we created in the Android Beacon Library. The three constants in the formula (0.89976, 7.7095 and 0.111) are based on a best fit curve based on a number of measured signal strengths at various known distances from a Nexus 4.

protected static double calculateDistance(int txPower, double rssi) {
  if (rssi == 0) {
    return -1.0; // if we cannot determine distance, return -1.
  }

  double ratio = rssi*1.0/txPower;
  if (ratio < 1.0) {
    return Math.pow(ratio,10);
  }
  else {
    double accuracy =  (0.89976)*Math.pow(ratio,7.7095) + 0.111;
    return accuracy;
  }
}

With our examples above, if you plug in -65 for txPower and -59 for rssi, the formula above returns a distance estimate of 2.0 meters.

Filtering for noise

Because of the signal noise, it is usually not a good idea to do a distance estimate based on a single RSSI measurement. If you look at the raw RSSI of beacon packets, the signal level jumps all over the place. The simplest way to filter out this noise is to use a running average of RSSI measurements — e.g. the most recent 20 seconds worth — to help smooth out the noise. It is also common to throw out particularly high or particularly low numbers in these data sets. The algorithm we use in the Android Beacon Library discards the top and bottom 10% of measurements over the 20 second sample period and averages the rest.

The advantage of this approach is that the distance estimates are much more accurate and stable. The disadvantage is that as a mobile device moves relative to the beacon, it will take 20 seconds for the distance estimate to catch up with where the device moved relative to the beacon.

A 20 second sampling period is similar to what is done by iOS. The graph below shows how the CLBeacon accuracy field changes over time when an iPhone 4S is quickly moved from a distance of 0.5 meters to 3 meters away (red line). As you can see, it takes about 20 seconds for the distance estimate (blue line) to stabilize after the device is moved.

Screen Shot 2018-11-19 at 4.23.38 PM.png


Device Variations

Beacon distance estimates behave consistently across most iOS devices because there is not much variation in the bluetooth radios, antennas, and case designs between the iPhone 4S, iPhone 5 and iPhone 6 models, but this is not universally true. Distance estimates from iPod Touch devices will generally underestimate the distance to beacons, most likely because their antennas are placed differently to provide a bit more gain in receiving the Bluetooth radio signals.

Device variation is a far greater problem for Android. Each Android model may have a completely different bluetooth chipset, antenna, and case design. All of these factors affect the received signal level and therefore the distance estimates. Nexus 4, Nexus 5 and Samsung Galaxy S4 models receive significantly different signal levels from the same beacon at the same distance. For this reason, Radius Networks has started building a database of distance formula coefficients for various Android devices.

Setting Expectations

While it is possible to estimate the distance to a beacon, it must be stressed that these are just estimates. As devices get further away from the beacon, the estimates get progressively less accurate. A device that is 20 meters away from a beacon might get a distance estimate with an error of +/- 10 meters. Depending on whether a phone is in a pocket, oriented in a different direction, behind a sales display, or blocked by a crowd of people, the estimate of the distance to a beacon may be affected.

It is therefore important to realize what you can’t do:

  • While you can easily tell if a beacon is one meter away or 10 meters away, don’t expect to be able to tell for sure if one is 10 meters away or 20 meters away.

  • Because running averages are used to filter out noise, don’t expect the distance estimates to change in near real-time as a user moves around.

  • Don’t expect to be able to determine the direction to a beacon. Because beacons are typically omnidirectional transmitters, although you can estimate distance, you cannot estimate direction.

  • Realize that being able to estimate the distance to a beacon does not tell you exactly where a mobile device is in a room. While beacons can be used as a building block within an indoor location system, beacon distance estimates do not by themselves solve this problem.

  • Don’t expect to be able to use trilateration with a few beacons to create a simple indoor location system. Because accuracy of distance estimates gets worse at greater distances, using trilateration to determine position within a room cannot provide accurate estimates of position.

That said, there are still useful things you can do with beacon distance estimates. Here are some examples:

  • Trigger an action to happen when a beacon is very close by, ie., 5 meters or less.

  • Determine which of several visible beacon is significantly closer, provided that the closest beacon is within a few meters.

  • Provide distance feedback to a user who is looking for a particular location, e.g. in a scavenger hunt.

Best Practices

In order to get the best possible distance estimates, Radius Networks recommends the following:

  • Use the strongest transmitter power level supported by your beacon if possible and if the use case allows for it. Stronger signal levels mean higher signal to noise ratios and better distance estimates.

  • Use the highest transmission frequency supported by your beacon. The more advertising packets received by a mobile device, the more samples it will have to average to filter out noise.

  • Use powered beacons where possible, like Radius Networks’ RadBeacon USB, so that you can transmit at high power and high frequency without worrying about battery life.

  • Calibrate your beacons properly.

  • Place beacons in locations with a clear line of sight to where the signals will be received. If in a crowded location, placements overhead work better than those at ground level.

  • If you are planning on deploying an app for a specific Android model, make sure that you have a distance estimation formula optimized for that model. Radius Networks’ Android Beacon Library supports an expandable database of distance calculations for various Android models.

Beacon Transmission with Android 5.0

By David G. Young

One of the most exciting new features of Android 5.0 is the support for Bluetooth LE peripheral mode, which makes it possible to turn an Android device to a beacon transmitter. Radius Networks is proud to release the new QuickBeacon app for Android 5.0, which creates a configurable beacon supporting both the AltBeacon and Apple iBeacon™ formats. This app is available for free for a limited time only in the Google Play Store, and works with the new Nexus 6 phone and Nexus 9 tablet.

Screen Shot 2018-11-19 at 4.20.47 PM.png


QuickBeacon for Android makes for an extremely versatile software beacon transmitter, because unlike iOS-based transmitters, it allows you to keep transmitting even when the app is no longer in the foreground. This makes it suitable for production use on tablets used as point-of-sale (POS) devices where the transmitter app will not always be in the foreground.

The app also allows you to configure the transmitter power, allowing you to adjust how far away the beacon transmission will be detected. Similarly, you can adjust the transmission frequency of the beacon, allowing you to save battery power if frequent transmissions are not needed. Neither of these adjustments are available on iOS or OS X-based transmitters.

It is important to note that not all devices with Android 5.0 can send beacon transmissions. The Android device must have Bluetooth LE hardware and it must have peripheral mode enabled by the device manufacturer. Google surprised many people when it disabled peripheral mode for their Nexus 5 and Nexus 7 devices, meaning these devices cannot transmit beacon advertisements using QuickBeacon or other software. This can be confusing for folks using the Google Play store, because it does not have a capabilities filter for BLE peripheral mode. As a result, QuickBeacon must be installed and tested on each Android 5.0 model before it is known whether or not the app is compatible with that model. If the Android model does not support BLE peripheral mode, the app will tell you right away.

EDIT: The following list shows which Android 5.0 builds are known to support or not support BLE advertising and QuickBeacon:

Nexus 6 build LRX21O - YES
Nexus 9 build LRX21R - YES
Nexus 9 build LRX21L - YES
Nexus 5 build LPX13 - NO
Nexus 7 build LRX21P - NO
Samsung Galaxy S3 build LRX21T - NO
OnePlus A0001 build LRX21V - NO

The engine that supports transmitting as a beacon is included in the open source Android Beacon Library 2.0. This library allows for configuring flexible beacon formats using the BeaconParser class. The library version that powers beacon transmission is still in pre-release form on the android-l-apis branch here. Using this software, setting up a beacon transmitter is as simple as:

Beacon beacon = new Beacon.Builder()
       	.setId1(“2f234454-cf6d-4a0f-adf2-f4911ba9ffa6”)
       	.setId2(“1”)
       	.setId3(“2”)
        .setManufacturer(0x0118)
        .setTxPower(-59)
        .setDataFields(Arrays.asList(new Long[] {0l}))
        .build();
BeaconParser beaconParser = new BeaconParser()
        .setBeaconLayout("m:2-3=beac,i:4-19,i:20-21,i:22-23,p:24-24,d:25-25");
BeaconTransmitter beaconTransmitter = new BeaconTransmitter(getApplicationContext(), beaconParser);	
beaconTransmitter.startAdvertising(beacon);

We encourage developers to try this out and send feedback on Github.

Since the release of our Android Beacon Library last year, Radius Networks has been leading the way on providing beacon support for the Android platform. Now that peripheral mode support is available on Android 5.0, we’re pleased to be able to bring beacon transmission tools and apps to Android.

Extending Background Ranging on iOS

By David G. Young

One of the most common use cases for beacon-enabled applications is to perform an action when a user gets close to a specific location. Since beacons typically have a transmitting range of up to 50 meters, it’s often not appropriate to trigger that far away. A gas station app, for example, shouldn’t prompt a user to pay at the pump when the user’s phone detects the beacon from across the street.

There are a couple of strategies to solve this. One involves turning down the transmitter power of the beacon so it can’t be detected until the user is only a few meters away. The RadBeacon models sold by Radius Networks allow adjusting the transmitter power for this exact reason. But when very close triggering is desired, this approach can sometimes lead to actions not being triggered at all. Received signal levels can vary depending on mobile device model, and where the device is placed.

A second approach involves tracking the beacon in the background, noting its estimated distance, and only triggering an action when the beacon is estimated to be within a specific range. This approach is problematic on iOS, because CoreLocation generally allows only 10 seconds of ranging time when an app is in the background. If a beacon is first detected at 50 meters, and a person is approaching the beacon at one meter per second, the mobile device will still be 40 meters away when iOS suspends the app and stops it from ranging.

The good news is that it is possible to extend background ranging time on iOS. If your app is a navigation app, you can specify location updates in the “Required background modes” in your Info.plist. But this approach makes it harder to get AppStore approval – you have to convince reviewers that your app is providing navigation services to the user. This probably isn’t true for many apps that simply want to use beacons to trigger at a specific distance.

Fortunately, you can still extend background ranging time without requesting special background modes. The time you can get is limited – only three minutes. But this clock restarts each time your app is woken up in the background, meaning you can get an extra three minutes of ranging time each time your app detects a beacon (enters a beacon region) or stops seeing beacons (exits a beacon region.)

How to Get Extra Ranging Time

Any app can request extra background processing time by calling UIApplication beginBackgroundTaskWithName: expirationHandler:. Once this call is made, the app can check to see how much running time is available by checking the backgroundTimeRemaining property on UIApplication. If your app is in the foreground, or if already has normal permission from the operating system to run (e.g. for the first 10 seconds after detecting a beacon), this method will return a very large number (max double), effectively telling you that you can run forever.

If normal permission to run in the background has ended, this method will return a value in seconds that starts counting down from 180. Until it reaches zero, your app can continue ranging for beacons, at which time the app will be suspended by the operating system.

You can see an example of how to set this up in the code block below. The method extendBackgroundRunningTime will request extra background time and then set up a dummy background task that doesn’t do anything besides sleep and log information to note what it is doing. Once the time is about to expire, the code gets an expirationHandler callback from the operating system, and kills the dummy background task. In the example below, the extra time is requested whenever the app enters the background, or whenever a beacon region transition occurs (e.g. whenever the app starts seeing or stops seeing beacons.)

- (void)locationManager:(CLLocationManager *)manager didDetermineState:(CLRegionState)state forRegion:(CLRegion *)region
{
    if (_inBackground) {
        [self extendBackgroundRunningTime];
    }
}

- (void)applicationDidEnterBackground:(UIApplication *)application
{
    [self extendBackgroundRunningTime];
    _inBackground = YES;
}

- (void)applicationDidBecomeActive:(UIApplication *)application
{
    _inBackground = NO;
}

- (void)extendBackgroundRunningTime {
    if (_backgroundTask != UIBackgroundTaskInvalid) {
        // if we are in here, that means the background task is already running.         // don't restart it.         return;
    }
    NSLog(@"Attempting to extend background running time");

    __block Boolean self_terminate = YES;

    _backgroundTask = [[UIApplication sharedApplication] beginBackgroundTaskWithName:@"DummyTask" expirationHandler:^{
        NSLog(@"Background task expired by iOS");
        if (self_terminate) {
            [[UIApplication sharedApplication] endBackgroundTask:_backgroundTask];
            _backgroundTask = UIBackgroundTaskInvalid;
        }
    }];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        NSLog(@"Background task started");

        while (true) {
            NSLog(@"background time remaining: %8.2f", [UIApplication sharedApplication].backgroundTimeRemaining);
            [NSThread sleepForTimeInterval:1];
        }

    });
}

You can see a full reference application that demonstrates this functionality here. The README file for this application shows log output from test runs, demonstrating that the app is able to range in the background for thee minutes after each beacon detection.

When setting this up, it is very important that you stop the background task when the expirationHandler is called by iOS, otherwise your app will crash when the background running time reaches zero. If this happens, your app won’t be detecting any more beacons until the user manually launches the app the next time.

Other Uses for beginBackgroundTask

While this technique works well to extend the background ranging period for beacons, it’s worth noting that there are plenty of other uses as well. Any long running task that would fail if interrupted can benefit from this. One example is web-service calls. If the app is sent to the background before the response is received the app may need to re-issue the request once it starts again. Not only will this cause a delay to your functionality that happens after the web service completes, but your web server will now have to handle an extra request once your app starts again.

Is This Allowed by Apple?

It is important to note that this technique does not require any special background modes or any special AppStore approval. There doesn’t appear to be any policy limit on requesting this extra three minutes of background running time, you can do it whenever you want. You just need to understand that iOS enforces limits by only granting a maximum of 180 seconds of extra running time before the app would otherwise have been suspended. For those of us building beacons applications, this means we can range for three minutes after detecting a beacon.

Is this three minutes guaranteed, and is it possible to get more? On iOS 8 and iOS 7, the operating system consistently grants an extra three minutes of background running time. But that doesn’t mean Apple can’t change this policy with a future update. On iOS 6, apps could get 10 minutes of background running time using this technique, but Apple quietly reduced this to three minutes starting with iOS 7. It is quite possible the maximum running time could be reduced in a future operating system update.

And while there doesn’t appear to be any official way to get more than three extra minutes of background running time (without declaring background modes), some folks have reported tricks to game the system and extend this further. Just be aware that if you take such an approach, you risk having your app rejected during review – this is probably not a good idea.

Conclusion

By starting a background task, beacon apps can range in the background for up to three minutes each time the app starts or stops seeing a specific beacon region. While this isn’t a perfect solution to the problem of needing to range in the background, it does open up many possibilities. In the gas station use case we mentioned above, if a mobile device that detects the beacon 50 meters away, and approaches the pump at one meter per second, the app will still be ranging in the background when the user is right at the pump. The user can then get the expected experience of being prompted to pay at the pump, instead of awkwardly being prompted to pay when approaching the station from across the street.

Radius Networks is committed to finding solutions for such real-world use cases. By combining well-known technologies with deep experience to make them work, things that initially seem impossible can actually become reality.

Debugging iOS Apps in the Background

By Chris Sexton

Most mobile developers know that iOS will wake up their app in some cases and notify it of some event, things like geofence or beacon regions can cause this to happen. What’s interesting is that iOS not only notify an app that is sleeping in the background, but also apps that have been explicitly terminated by the user, or never restarted after a reboot of the phone.

This is all good until you need to debug your app in this state. Turns out it is pretty straightforward, but required a little trick or two to get Xcode to attach the debugger to the process.

Here’s how to debug this in Xcode. First you need an app that is setup to get a callback from iOS that can happen while it is in the background. In this case I am using ProximityKit and an iBeacon to trigger that behavior.

Step 1: Get the process name.

This is printed out in the log any time you call NSLog().

I just dropped that line in the did finish launching delegate:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  NSLog(@"Starting Up...");
  // ...
}

Then you can run that app and grab the Process Name.

Screen Shot 2018-11-19 at 4.14.20 PM.png



Step 2: Stop your app

Stop it in Xcode. I also tend to manually re-launch it on the phone and then quit the app by swiping it off in the app switcher, just to be sure.

Step 3: Set the breakpoint

Create the breakpoint in the delegate that iOS will call when it wakes your app.

Screen Shot 2018-11-19 at 4.15.12 PM.png


Step 4: Attach to the Process

Now for the tricky part. You need to attach to the process, but the process isn’t running yet. So, we will use the process name. On the menu bar choose Debug > Attach to Process > By Process Identifier (PID) or Name... and enter the process name you found in Step 1.

Screen Shot 2018-11-19 at 4.15.48 PM.png


Step 5: Fire the event

For this app I just turned on the iBeacon which caused iOS to wake my app and Xcode attached to the process and enabled the debugger at the break point.

Once I enabled the beacon, waited a couple seconds and iOS dutifully started the app and called the delegate.


This little trick has been extremely handy in tracking down some changes in the way iOS 8 handles permissions.

Pro-tip: You need to use NSFileProtectionNone if you have to load a file cache while the phone is locked.

Fast Background Detection with Android 5.0

By David G. Young

It’s common for beacon-enabled apps to want to detect beacons, even when the app is not running in the foreground. Since looking for beacons requires Bluetooth LE scanning, doing this constantly in the background can be a real battery drain.

The good news is that Android 5.0 has implemented new APIs that allow background scanning that is much easier on the battery.

The scanning APIs have been completely redone on Android 5.0, and look like this:

BluetoothLeScanner scanner = getBluetoothAdapter().getBluetoothLeScanner();
ScanSettings settings = new ScanSettings.Builder()
                                        .setScanMode(ScanSettings.SCAN_MODE_LOW_POWER))
                                        .build();
List<ScanFilter> filters = new ArrayList<ScanFilter>();
scanner.startScan(filters, settings, myCallbackMethod);

Note the scan mode above is set to SCAN_MODE_LOW_POWER (also the default), which is suitable for background use. A second mode, SCAN_MODE_LOW_LATENCY, provides faster detection of Bluetooth LE advertisements (and beacons) while expending more power.

In order to see how these two modes behave, we ran tests scanning in each mode. We used a Nexus 5 with Android 5.0 to scan for beacons in our offices in a location where dozens of beacons are active. Doing this over a period of two hours while the phone was in airplane mode (but with bluetooth on), we measured the battery drain in each mode, along with some stats on the maximum time between beacon detections. Here’s what we found:

SCAN_MODE_LOW_POWER SCAN_MODE_LOW_LATENCY 

Test Duration 134 minutes 152 minutes

Battery Level Change -13% -25%

Battery Drain Rate* 268mA 454mA

Relative Battery Savings 41% –

Typical time between detections 4400 ms 100 ms

Based on the above, you can see that LOW_POWER mode uses a little more than half as much battery per hour than LOW_LATENCY. The tradeoff appears to be in the detection times. Even though a similar number of beacon advertisements were detected per hour, in LOW_POWER mode they were typically delivered only every 4 seconds as compared to near-real-time in LOW_LATENCY mode

The above tests probably understate the battery savings, for two reasons:

  1. They do not account for battery usage by system overhead.

  2. The tests were performed in Radius Networks’ labs where dozens of beacons are typically detectable. This clearly makes the Android system work harder, even in LOW_POWER mode.

This feature is important, because it allows apps wanting to detect beacons in the background to respond within 4 seconds to beacon detections. With scanning APIs available on Android 4.3 and 4.4, background detections must either use lots of battery power, or cycle on and off every few minutes to save battery.

As the final release of Android 5.0 comes closer, Radius Networks is working on adding support to the open source Android Beacon Library for this low power scanning feature. Those who would like to see the details are welcome to check out the Android L APIs branch of the library on GitHub

We here at Radius Networks are excited to see Android catching up with iOS in this area. Many of our developer-partners and customers have been asking us for this functionality. With Android 5.0, we will be even closer to parity with iOS.

* Based on Nexus 5 battery capacity of 2300mAH

Using Proximity Kit with Swift

By Michael Harper

Swift is the new programming language from Apple announced at WWDC 2014. As of September 9, 2014, you can now submit apps that use Swift to the App Store. In my copious free time, I’ve been getting both my hands dirty and my feet wet with Swift on several projects.

Here I’ll show you how straightforward it is to use ProximityKit for iOS with Swift.

Let’s Get Our Swift On

Swift is the new programming language from Apple announced at WWDC 2014. As of September 9, 2014, you can now submit apps that use Swift to the App Store. In my copious free time, I’ve been getting both my hands dirty and my feet wet with Swift on several projects.

Here I’ll show you how straightforward it is to use ProximityKit for iOS with Swift.

Let’s Get Our Swift On

1- In order to use Swift, you need to install and run Xcode 6 or newer.

2- Create a new iOS Single View Application project.

Screen Shot 2018-11-19 at 3.43.45 PM.png

3- We’ll call ours “SwiftBeacon”. Make sure you select “Swift” in the Language menu.

Screen Shot 2018-11-19 at 3.44.24 PM.png

4- Close the project window as we’re going to use CocoaPods to include ProximityKit in the app.

5- Initialize your project to use CocoaPods by running this command in the root directory of your project:

$ pod init

6- This creates a Podfile in the root directory of your project. For the purposes of this example, I removed the target-specific pod settings. In order to use the ProximityKit, your Podfile should contain the following

source 'https://github.com/CocoaPods/Specs.git'
pod 'ProximityKit', '~> 1.0'

7- Then run

$ pod install

8- Now open the .xcworkspace file for your project going forward so that the ProximityKit CocoaPod is automatically included.

9- Download the ProximityKit configuration file for your kit and copy it into your Xcode project. My project now looks like this:

Screen Shot 2018-11-19 at 3.48.19 PM.png

At this point, you should be able to build and run this app on your phone. It’d be a good idea to do this right now, just to be sure you’ve done everything properly up to this point. On my phone, the app simply displays a white screen.

Bridging Swift and Objective-C

We now have a project containing some Swift code and the ProximityKit framework. But the app is written in Swift and ProximityKit is written in Objective-C! How will we bridge that gap?

Of course, Apple thought about this and provides us with a solution called a “bridging header.”

1- Create a new header file named <project_name>-Bridging-Header.h. In our case, we’re calling it SwiftBeacon-Bridging-Header.h. You need not add this to any target since it’s a simple header file.

Screen Shot 2018-11-19 at 3.49.23 PM.png

2- #import the ProximityKit header file in the bridging header file.

#import <ProximityKit/ProximityKit.h>

You can include any other header files here for Objective-C items you need to access from your Swift code.

3- Set the bridging header file in the build settings for the app target. Do this by selecting the target, then build settings, and search for “bridging”. Set the value for the Objective-C Bridging Header to the name of the bridging header file you just created. I found I had to precede it with the path to the file relative to the root directory of the project, e. g. SwiftBeacon/SwiftBeacon-Bridging-Header.h

Screen Shot 2018-11-19 at 3.50.21 PM.png

Once again, build and run your app to make sure you’ve setup your bridging header file properly.

Connect Swift Code to ProximityKit

All of the puzzle pieces are now in place so that we can hook up the app to ProximityKit.

  1. Start by implementing the RPKManagerDelegate protocol in your AppDelegate

    @UIApplicationMain
    class AppDelegate: UIResponder, UIApplicationDelegate, RPKManagerDelegate ...
    
  2. Add a RPKManager to your AppDelegate

    var proximityKitManager: RPKManager?
    
  3. Initialize and start proximityKitManager in application() method of your AppDelegate

    self.proximityKitManager = RPKManager(delegate: self)
    self.proximityKitManager!.start()
    
  4. Implement the RPKManagerDelegate methods as necessary.

    func proximityKitDidSync(manager : RPKManager) {
      NSLog("didSync")
    }
      
    func proximityKit(manager: RPKManager!, didDetermineState state: RPKRegionState, forRegion region: RPKRegion!) {
      NSLog("didDetermineState \(state) for region \(region)")
    }
      
    func proximityKit(manager : RPKManager, didEnter region:RPKRegion) {
      NSLog("didEnter region %@", region)
    }
      
    func proximityKit(manager : RPKManager, didExit region:RPKRegion) {
      NSLog("didExit region %@", region)
    }
      
    func proximityKit(manager : RPKManager, didRangeBeacons beacons:NSArray, inRegion region:RPKRegion) {
      NSLog("didRangeBeacons %@", beacons)
    }
    
    
  5. CoreLocation in iOS 8 now requires that you request authorization from the user to monitor the device location. In order to do so, you must specify a new key/value pair in your app’s Info.plist file for the key NSLocationAlwaysUsageDescription. The value for this key is the message that will be displayed when iOS asks the user to authorize location monitoring. Here’s what mine looks like (highlighted):

Build and run once again. ProximityKit automatically requests authorization for location monitoring on the behalf of your app but only if the key in your Info.plist file is properly setup. Assuming you are in the vicinity of beacon(s) that are in your kit, you should see log messages in your debug console indicating what’s going on with ProximityKit.

Swift Resources

GitHub repository for this example.

The Swift Programming Language book from Apple.

There are several excellent Swift-related sessions from WWDC 2014. (You must be a registered Apple developer to access these videos.)

Swift forum at devforums.apple.com. (You must be a registered Apple developer to access these forums.)

Announcing Proximity Kit Android SDK

By Aaron Kromer

The Radius Networks team is committed to building the features and services necessary to promote Android as a first-class citizen in the world of beacons and proximity services, so we are thrilled to announce the re-release of our Proximity Kit Android SDK.

This is a major update which not only provides support for geofences through Google Play services, but also leverages the open AltBeacon standard for beacon detection. While we were at it, we made a few other changes to improve the Proximity Kit experience on Android.

The Radius Networks Proximity Kit Android SDK now uses JDK 7. This change allows us to leverage more features of the Java language internally, enabling us to provide a better SDK to you.

If you used our prior version of this SDK you may have felt some pain in how you were required to implement the callback notifiers. With this new release, we are pleased to announce we have improved this process by partitioning the callback notifiers based on their shared behavior. You can now implement just the notification subset(s) you care about.

Feel free to peruse these changes in our updated open source sample application. Or just head on over to Proximity Kit to get started on your app today!


New AltBeacon Standard Allows Cross-Platform Proximity Apps

By Marc Wallace

Recently, we removed our Android beacon tools and related projects from our website. We are happy to announce that we are re-releasing them with a major update that we feel will establish a stronger foundation and ecosystem for proximity solutions and Bluetooth Low Energy (BLE) beacon development.

Our team feels strongly that the huge potential of proximity technology lies not with one platform but across all platforms. With this in mind, Radius Networks has authored and released a new open standard for beacons, AltBeacon.org.

Currently, no open, interoperable specification for BLE proximity beacons exists. Only proprietary specifications exist, which favor one vendor over another. We hope that AltBeacon solves this problem. We also believe we have created a specification that is more flexible and can accommodate different types of proximity beacon implementations and solutions that can benefit by not being locked into a specific format, such as rigid identifier lengths and additional payload space for critical information.

The AltBeacon standard, supporting libraries, and reference implementations are available as open source, and all AltBeacon work is open under the Creative Commons license. AltBeacon is available to everybody and for every type of device.

The Radius Networks team has released an update to the Android Beacon library, as well as tools and reference implementations to support AltBeacon. Our plan is to adopt AltBeacon across all of our tools and platforms to complement our support for iBeacon™ technology.

Please check out the new standard and let us know your thoughts. We hope for feedback from the community on how the AltBeacon specification can be enhanced and improved.

A Note from the CEO

By Marc Wallace

You may have noticed some changes to our website and to the products and technologies that we offer. I want to take a moment to give you a little insight and understanding of why these changes have occurred.

Our Proximity Kit SDKs and Android Beacon Pro Libraries are in transition at the moment and we felt the best step was to remove these from further distribution until this transition was complete.

We understand that you, our valued customers and partners, may be impacted by these changes. Please be assured that we also understand and appreciate how important it is to provide proximity solutions for multiple mobile device platforms, so we ask that you stay tuned, as we have additional exciting solutions that we will be introducing very soon. We believe that these new updates will ultimately create stronger and more robust solutions for our customers and our partners.

Sincerely,

Marc Wallace Co-Founder & CEO

Announcing Beacon Development Kit Version 3.0

By James Nebeker

Update 7/8/2014: We’ve released Version 3.1 to address stability issues when scanning for beacons and to add some new features. This update can be downloaded here and you can read more about these features in the updated instructions page.

We’re thrilled to announce a major update to the Beacon Development Kit, now with the ability to scan for nearby beacons!

Beacon Scanning

The Beacon Development Kit has always been a powerful tool in developing beacon compatible apps, with the ability to broadcast as a beacon with custom identifiers and broadcast frequency. Now with the power to sense other beacons, the development kit is the ultimate proximity beacon utility. The Raspberry Pi has output pins that can be used to control external devices. Combining this with beacon scanning, you can control physical devices when a particular beacon is detected. We show a simple example in this blog post, using the development kit to turn on a light when a particular beacon is detected. Following this example, you can integrate beacon proximity technology with the physical world, even with limited programming knowledge. There are countless other more creative uses for this new feature and we’re excited to see what great ideas everyone can come up with.

Download the Update

If you have a previous version of the Beacon Development Kit, we’ve made the latest version available to download here, just follow the instructions and you’ll be up to date in no time.

Note: You may experience some instability when using the new scan feature for extended periods of time in high-traffic areas due to an error where the bluetooth adapter enters a bad state. The only way to recover from this state is to power cycle the adapter or reboot the machine. We are continuing to work to minimize this issue and will be providing additional updates.


How to Make a Raspberry Pi Turn on a Lamp with iBeaconTM Technology

By James Nebeker

Beacon™ proximity technology is an exciting tool already being used by retailers and developers to build location-aware apps to improve user experience and much more. In this post, we’ll show you an easy way to harness iBeacon™ technology in your own home, without having to do any serious programming or developing. In this simple example, we’ll be using a Raspberry Pi to turn on a light whenever it detects a specific beacon.

Screen Shot 2018-11-19 at 3.02.34 PM.png

Parts list:

  1. Beacon Development Kit (alternately, you can supply your own Raspberry Pi, bluetooth LE dongle, and SD card)

  2. Standard micro-USB 5V cell phone charger

  3. PowerSwitch Tail II

  4. Jumper wires (recommended) or household wire

  5. Desk lamp or other light source

Other tools you will need:

  1. Proximity Beacon (compatible with iBeacon™ technology)

  2. USB Keyboard

  3. Computer monitor with HDMI input

  4. HDMI cable

  5. Small flat-head screwdriver

  6. Network cable for internet access (optional)

Before we put this all together let’s go over each part individually, for starters we’ll assume you have your Raspberry Pi already set up (with BlueZ, the Linux bluetooth stack, installed) and have some familiarity with basic Linux command line operations. If not, or if you want a quick introduction to the Raspberry Pi and iBeacon™ technology, check out our blog post, How to Make an Beacon Out of a Raspberry Pi, to get acquainted with Linux, the Raspberry Pi, and iBeacon™ technology.

Scanning for beacons

The ability to scan for nearby proximity beacons is the latest feature of the Beacon Development Kit, new to Version 3.0. In this guide we will be using the newest development kit software to do the scanning. Information on how to download this update can be found here. If you already have your own Raspberry Pi and bluetooth dongle you can create your own beacon scan script using the steps I’ve outlined in this post.

Before we can start scanning we need to make sure we have a beacon nearby to test with. The easiest way to do this is probably to download our free Locate for iBeaconapp for iOS. You can also check out our products page for other beacons to test with. For this tutorial, I will be using a test beacon with the following identifiers:

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

  • MAJOR: 1

  • MINOR: 1

Once you have your test beacon up and running, let’s do a quick test scan. First, make sure the development kit isn’t currently broadcasting using the ibeacon stopcommand, then run the following command to start a scan and you should see the identifiers of your test beacon.

$ ibeacon scan
UUID: 2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 MAJOR: 1 MINOR: 1 POWER: -59
UUID: 2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 MAJOR: 1 MINOR: 1 POWER: -59
UUID: 2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 MAJOR: 1 MINOR: 1 POWER: -59

To exit a scan press control-c.

Note:

You may experience some instability when using the new scan feature for extended periods of time in high-traffic areas due to an error where the bluetooth adapter enters a bad state. The only way to recover from this state is to power cycle the adapter or reboot the machine. We are continuing to work to minimize this issue and will be providing additional updates.

For triggering the light in this example, we’ll be using the -b option for bare output. Go ahead and try it out, and you should see something like this:

$ ibeacon scan -b
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 1 1 -59
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 1 1 -59
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 1 1 -59

Now that we can detect nearby beacons with the Raspberry Pi, the next step is turning the light on and off.

Controlling the light

To control the light we will be taking advantage of the GPIO pins on the Raspberry Pi, which can supply a voltage when commanded, and the PowerSwitch Tail II, which switches power from a wall socket with a small control voltage. The first step is to connect the power switch to the GPIO pins on your Raspberry Pi, we recommend using jumper wires to make things easier. The diagram below shows the wiring configuration, the ground pin on the Raspberry Pi is attached to the negative input on the switch and the GPIO1 pin on the Pi is attached to the positive input on the switch. Use a small flat-head screwdriver to secure the wires into the two slots on the power switch.

Screen Shot 2018-11-19 at 3.03.13 PM.png

Once everything is connected, go ahead and plug the power switch into the wall and plug your light into the switch. Make sure any switches on the light itself are in the on position. Now we’re ready to test the power switch, to control the voltage on the GPIO pins we’ll be using the Wiring Pi library which is installed by default on the Beacon Development Kit. The first step is to change GPIO 1 into OUT mode. Then command the pin to turn on, which will activate the power switch and turn the light on. To do this run the following commands (shouting “Let there be light!” is optional):

$ gpio mode 1 out
 $ gpio write 1 1 

You can turn the light off by switching GPIO 1 off:

$ gpio write 1 0

Now all that’s left is to combine this with beacon scanning and we’ll have an automated beacon lightswitch.

Putting it all together

We’re going to write a little bash script that will read the input from a beacon scan line by line and search for a specific beacon’s identifiers. Once it detects the beacon it will switch on the light, if you exit the script with control-C the light will be switched off. Use your favorite text editor (e.g., vi, nano) to create the welcome_light script seen below:

$ nano welcome_light

Paste in the contents of this block:

#!/bin/bash

 gpio mode 1 out
 trap "gpio write 1 0" exit while read line
 do if [[ `echo $line | grep "2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 1 1" ` ]]; then gpio write 1 1
   fi done

Be sure to change the beacon identifiers in the if statement to the ones you’ll be broadcasting with your test beacon. Save this file and get your beacon ready, make sure it is off for to start the test. Now run the following command to start the scan and light switch sequence, it starts a beacon scan with the bare output option, piping its output into our welcome_light script. If you made your own scan script, just run that script and pipe its output to welcome_light.

$ ibeacon scan -b | ./welcome_light

Once the scan is started, activate your beacon and you should see the light turn on automatically. Check out the video clip below to see the demo in action.

For a homework assignment, you can build on this script to turn off the light when it no longer detects the beacon (i.e., when you leave the room).

That’s it!

We hope this quick tutorial gave you a good example of the power of proximity beacon technology. There are tons of other cool ways to take use beacons with a Raspberry Pi, we look forward to seeing what everyone can come up with.