Inside Gimbal: Qualcomm Beacons Tackle Bluetooth LE Challenges

Qualcomm Beacon

Qualcomm has done a lot right with its new Bluetooth LE beacons. Its devices are low-cost and it offers a full SDK for iOS proximity services, and geofencing support for Android devices.

Gimbal Pricing

Qualcomm is taking a low-cost strategy for the beacons themselves – pricing them as low as $5 for their Series 10 beacon.

It charges on a per user basis for its back-end cloud services with the first 10,000 users per month being supported free of charge and then 6 cents per user per month after that – with prices scaling down to 4 cents per user when you hit the million user mark:

0 – 9,999 Waived
10,000 – 124,999 $0.060 per Active User
125,000 – 999,999 $0.050 per Active User
1,000,000 and up $0.040 per Active User

In theory, because you can set your beacons to ‘public’ mode, you can then scan them to determine their UUID number. This means that you could use the beacons on their own without the Gimbal API or back-end systems and just run them as beacons. This puts them on par with Estimote which has a publicly accessible “out of the box” UUID allowing you to use and test the beacons without back-end services.

So: buy a few of their beacons and build your own back-end. Or use their back-end and you get the first 10,000 users for free.

Bluetooth “Stacks”

This build/buy decision is based on the simple fact that a beacon without a ‘system’ is just a radio transmitter with no listener.

In deploying beacons (in a store, say, or at home) you need some kind of physical device that acts as the ‘beacon’ – transmitting information through Bluetooth Low Energy radio signal that is then scanned by a phone or tablet.

Popular beacons include Estimote, GeLo, Kontakt and others. You can also build your own beacons. Coin, for example, offers an Arduino developer kit.

But putting a beacon on the wall is just half the battle. Because you’ll still need an app on the user’s phone, code inside the app to manage the way that the app detects beacons, and a system (however rough) to manage the beacons themselves.

A lot of developers will want full control of the ‘stack’. This means they want to buy ‘unlocked’ and open beacons, develop a cloud-based system for managing the beacons, and develop the app that goes on a user’s phone. Depending on the use case, this isn’t difficult to do – especially for fairly simple applications.

Using Apple APIs most of the software ‘hooks’ are already built into iOS devices and it’s simply a matter of connecting it all to some kind of content/management back-end system.

Gimbal goes beyond beacon s to include geofences and communication features

Gimbal SDK Features

There are some incredibly appealing reasons, however, to use the Gimbal ‘cloud’. They’ve managed to take a lot of the pain away in developing beacon-based solutions. In some instances, they offer solutions that we haven’t yet seen (but are definitely waiting for) in other beacon solutions:

Private/Public Mode: Gimbal offers an easy way to make beacons “private” locking access to them by unauthorized users. Most beacons are currently transmitting their data in public without a way to toggle into private mode (although the manufacturers promise that the feature is coming). Private mode anonymizes the beacon ID number and only allows its ‘true’ data to be read by authorized apps. Gimbal allows for this with a single click on their dashboard.

Smoothing Out Signal Strength: One of the frustrations in developing with beacons is the tendency of your app to ‘toggle’ between different beacons and proximity zones. This primarily happens because of radio interference in the environment, but can sometimes happen because of small glitches in the operating system on your phone. Gimbal allows you to set “windows” that smooth out fluctuations in signal strength and gives you better control of the user experience:

“This option allows for a window of historic signal strengths to be used for a given device to “smooth” them out to remove quick jumps in signal strength. The larger the window the less the signal strength will jump but the slower it will react to the signal strength changes.”

Finding and Exiting Regions: Like signal strength it can be frustrating to find that your app “finds or exits” a region when your user hasn’t even moved. Gimbal offers more granular control over what it calls “visits” and allows you to set a timer for arrivals. For example, their equivalent for ‘didExitRegion’ allows you to set a number of seconds before the app will confirm an exit.

Gimbal even provides a handy chart that summarizes what you should expect for response times when an app is in background mode. This has been a contentious topic and it’s useful to see them document their findings:

Beacon Transmit Rate	Average Time to Arrival	Standard Deviation
100 milliseconds	7 seconds	10 seconds
645 milliseconds	15 seconds	6 seconds

Gimbal Cloud Features

In addition to the library that they provide to help you develop your app, Gimbal provides a robust back-end to help you manage interactions with the app, the beacons, and analytics. Their system includes support for:

• Geofencing
• Communication to your user’s app (push messages)
• Analytics which include length of visits
• Full management of transmitters, hubs and receivers

These features go well beyond beacon management and offer an end-to-end solution that includes geofencing, push messaging, analytics and a robust hub/transmitter dashboard. Whether you use their beacons on their own or use the back-end system as well, Qualcomm has, if nothing else, raised the game for the ‘becosystem’.

Join Our Mailing List: Once-a-Week

Join our weekly mailing list for ‘BEEKn unplugged’. We share resources and links that don’t always make it to the site. Be the Beacon!