Inside Gimbal: Qualcomm Beacons Tackle Bluetooth LE Challenges

Qualcomm Beacon
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 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!

12 Responses to “Inside Gimbal: Qualcomm Beacons Tackle Bluetooth LE Challenges”

  1. Qualcomm in the beacon business does raise the bar for all of us in this micro location segment (they have test other retail technology in the past). It also validates Micro Location as an emerging industry with big players…

    Reply
  2. Juan Villalba

    Future-present of the “real world” apps, Excellent!… Many thanks to the blogger for the reviews…

    Reply
  3. Chris Laidlaw

    Am I understanding right that if there are 124,000 app users with a Gimbal beacon system the monthly costs would be $7,440. Wow, that seems crazy or am I missing something?

    Reply
  4. I am curious how they define an “active user” and how users are assigned and tracked. There api looks interesting but this a huge lock-in to buy into. I am still waiting to test the devices. Maybe will try to use them in public mode since we have our own backend services and analytics for our app.

    Reply
  5. Actually, you can’t sniff the iBeacon UUID as Gimbal use their own implementation for their beacons. They use BLE to transmit encrypted IDs that change with each broadcast, so it needs to validate with the SDK / API to confirm which beacon ID this ties up to.

    Reply
  6. Robin Jewsbury

    As you say great idea from Qualcomm, but I think they’ve tripped themselves up near the winning post. I suspect its a big company trait of no-one checking the details and creating a something that does not deliver. Great idea to subsidise the costs with future payments but the model they’re using is insane; someone senior needs to go through the numbers properly. Also as a developer I’ve received the beacons and the software looks good but I expect to work out of the box with no tweeks. I am sure some other techy will tell me that setting the framework path correctly is an obvious thing any decent developer can do but I don’t really expect to have to do that sort of thing. Certainly their competitors SDKs work out of the box.

    Reply
  7. Paul Faunik

    Is it possible to determine the UUID of the Gimbal or not? I’ve seen contradicting statements in multiple places. I have not yet seen the proposed means / code to determine the UUID.

    Reply
  8. RIchard Donald

    not, it’s broadcasting “random” UUIDs.
    I dissected one module:
    There isn’t any information about it on the web:
    PCB: BLIP3 1DN14-25-H77740-P1
    Chip: 4248695 2500D0A 2AJ P15X

    Reply
  9. Carlos Angel

    Gimbal looks incredible but I completely agree that they screwed up their pricing model. The types of businesses they are targeting are interested in large scale deployments. The pricing structure that works best for them is upfront fixed costs, they can eventually dilute, and a very very very very low marginal cost. To “fix” this marginal cost at 40 cents is retarded! What a shame, I am now looking at Sonic and Kontakt.

    Reply
  10. We are keeping our options open with beacon integration into our service, but we really like the estimote model of a more open and transparent platform and hopefully estimote keeps that way as they role out enterprise security and cloud. SDK lock-in is big concern, but these Gimbal devices are nifty and cheap.

    Reply
  11. Ernesto Freyre

    The problem with changing UUIDs and the vendor lock on their platform is that totally eliminates many creative ways to use and innovate on bussiness models with proximity based interactions. I will have to move to the next vendor that gives better price and more open devices.

    Reply

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>