Nearables Wearables: Connecting Beacons with Smartwatches for Indoor Positioning
Beacons are great for indoor positioning, but Estimote took them one step further with nearables. One can say the step is towards IoT-ization of simple objects, and we were excited to see how far they can go. This article is all about squeezing the juice out of Estimote Nearables and combining them with mobile & wearable tech to see how they would perform in real life situations.
To share our impressions and showcase the results, we created a short video, featuring our experiment.
Tracking people’s movement. Old problem, new technology
We chose tracking people’s movement as the use case for running our experiment. In reality it’s not as creepy as it sounds. Big offices often face the difficulty of locating and finding employees within the building, especially if they are busy with lots of meetings and rarely stick to their desk. Sure, you can use the magic of mobile phones to find a person, but not everyone carries their phone around (shocking, I know) and interfering in meetings with phone call is plain rude. It would be much easier to just know where you can find the person to solve a critical issue in a brief personal conversation. Even though this case looks more like a traditional beacon one rather than a job for nearables, we chose it simply because we faced a similar problem of finding the necessary people in our five-story office building with 600 employees. We also wanted our experimental app to lay ground for statistical analysis and future optimization of employee location inside a company.
At ELEKS, we don’t think much of hackneyed solutions, so the idea of connecting nearables with phones was rejected at once. Instead, we decided to use smartwatches (both Android Wear and Apple Watch) as target devices for tracking. This basically means that the smartwatch will be disconnected from the phone and the app will be 100% standalone. Another reason for choosing smartwatches is simply to see if it’s actually possible, considering the limitations of smartwatches like Bluetooth Low Energy API, HTTP transport, background services, etc.
The idea is simple: we would stick nearables near the key spots of the office like exits, elevators, kitchens, gym, etc. Every nearable’s UUID would be linked with a certain place. Meanwhile, employees would install the application on their smartwatches and register (which, of course, requires accepting an agreement). That would be the only interaction required from a user.
The application would primarily have the following functions:
- Logging in (on the phone)
- Allowing a background service that would interact with discovered beacons (on the smartwatch)
- Sending UUIDs received from the nearables discovered in range (along with UserID and the current time) (on the smartwatch)
- Displaying recent locations of other employees based on the server’s data (Favorites on both smartwatch and phone, all employees – on the phone)
Additional functionality would include
- Marking certain employees as favorites to keep information about the people you need to catch up with most often separately (on the phone)
- Searching for people by name (on the phone)
How it should work
We didn’t encounter any problems with the SDK when working with samples on smartphones. So we were ambitious to think that everything will work the same way on watches as well. A smartwatch receives data from a nearable, sends it to the server and your current location becomes available for other people. That doesn’t sound difficult right?
Using the same system on the phone and the watch allows using all existing libraries, animations and SDK features on a small screen, so we were expecting to use Estimote SDK on the watch the same way we would on a phone. With the recent Android Wear update’s Wi-Fi support (if it is available on the hardware level), we wanted to use wireless connection to send data from the sticker to the server.
We have already seen nearables monitoring work on iOS when testing Estimote SDK. What we really wanted to find out was if standalone Apple Watch apps could detect Estimote beacons, since watchOS 2 allows access to watch hardware and communicating directly with remembered Wi-Fi hotspots.
How it actually worked
Fortunately, we had no problems with running Estimote SDK on an Android Wear smartwatch. Guys from Estimote prepared exhaustive examples (just don’t forget to add required permissions), so It didn’t take much time to write a simple service for the smartwatch to communicate with nearables in the background.
We did face some problems, though. For example, we couldn’t rely on the SDK to handle events when the device appeared in or fell out of the range of a nearable. It worked with beacons but not stickers. We just didn’t receive events from stickers. As a workaround, we had to use another option: the listener, that handles every event received from a nearable (about 2 sets of events from all stickers per second). And voilà – we managed to receive data from stickers. Now it’s time to share them with the server.
Previously, to send data from the watch to the server, we would use one of DataLayerAPIs to pass data to the phone, and then the phone would send it to the server. But with Wi-Fi on the watch on, can data be sent directly to the server? The answer is yes. But, of course, there are some details you should be aware of:
- The smartwatch should be disconnected from the phone.
- The smartwatch should be connected to a Wi-Fi network.
*Also, keep in mind that Wi-Fi can be automatically disabled when the battery is low (this can be configured in the watch’s settings).
Following these statements, you can use your regular code to send HTTP requests. In our case, we used the OkHttp library. We received data from the server to display locations of other people the same way. One of downsides here is that you can’t debug your app while your watch is disconnected from your phone. Basically, this is how it worked on my table with nearables, wear, phone on it.
When monitoring the area to locate nearables, the existing Estimote WatchKit SDK works only for watchOS 1. The applications run on the iPhone and the Apple Watch is used here only to display the notifications. As far as for OS2 the applications run on the watch directly, we could not use this SDK here. We also tried different workarounds to make Apple Watch detect nearables, but it seems like Apple worked hard to prohibit this feature for the Watch.
The Geeky Part
We found that the native iBeacon SDK CoreLocation works with watchOS 2, and were excited to see if it could detect beacons. Unfortunately, all monitoring APIs are marked with the __WATCHOS_PROHIBITED attributes and are not available for watchOS2. This was shortly mentioned by Apple’s engineer during CoreLocation session at WWDC15, meaning that the smartwatch cannot monitor beacons the same way iOS does, especially in the background.
Another option to detect nearby beacons was to use CoreBluetooth and scan for peripherals when the app is in the foreground. This framework is hidden by default for Apple Watch but it can be added to the watch app extension. We saw that CBCentralManager is not visible in headers but exists in the runtime, so we tried to call scan for peripherals can find beacons on the iOS. Unfortunately none of the
CBCentralManagerDelegate methods is called on Apple Watch.
We came up with several theories to explain why Apple decided to disable monitoring on the Watch:
- Not to consume smartwatch’s energy with monitoring.
- Not to allow third party apps to perform sync or notifying operations when the app remains in background and the watch is locked.
- As monitoring activities can be carried out on iOS, actual cases when users’ Apple Watch is only connected to Wi-Fi, without being paired with an iPhone can be very rare.
We wrote a simple demo app to search for the “known” nearables and send location updates to the server. Background mode had to be allowed for the app to perform background monitoring: “App communicates using CoreBluethooth”
There are 2 APIs that allow searching nearby beacons on iOS using Estimote SDK:
- Ranging. Triggered only when the device finds a nearby beacon. Run approximately 2 times per second if the user stays near a beacon.
- Monitoring. Triggered when a user enters or leaves the beacon region.
There are two options available while working with the APIs:
- to scan the environment, looking for all the beacons available within the area of reach;
- to search only for the beacons that have specific identifiers;
While both these options work great when the app is in the foreground, they behave differently when the phone is locked:
- Ranging. Doesn’t work when the app runs in the background. This was done not to launch application in background very often when user stays near beacon.
- Monitoring. Works only if you subscribe to receiving notifications about entering or leaving the area of beacons with known identifiers. This means that we can’t receive notifications about all the beacons found when the app runs in the background.
And one more thing. If the application was terminated by the user, the system will not launch it even if a monitored beacon was found. By killing the app, users sort of say they don’t want this app to perform any operations, so it’s quite logical that it doesn’t launch on its own. But if the application was killed by the system (e.g. because of memory pressure), iOS will launch and notify the app about the found beacon.
Real Environment Behavior
Certainly, testing our experiment in the real environment gave us more insights and revealed some issues that the theory couldn’t. Nearables turned out to be not that stable, as each of them behaved differently. The signal intensity changed for the same nearable in the same conditions. Moreover, 4 stickers refused to work by the end of the testing.
Two most important findings:
1) What’s the average distance between a beacon and a device to start communicating? According to our research, it’s around 1m. Is it enough? No, not really.
2) How long does it take for a device to discover a beacon? Up to 3 seconds in the best-case scenario. Not too shabby.
It was also fun to explore the impact different obstacles have on nearables. Doors, for example, did not change signal intensity, as opposed to several glasses of water (again, some stickers behaved differently in the same environment).
|The optimal distance between devices||SmartWatch||1 m||With distance increasing, the signal becomes unstable.|
|The maximum distance between devices||SmartWatch||2 m||At this distance the signal is very unstable, often nearable is invisible.|
|Nearable connection time||SmartWatch||3-15 sec||The time of connections depends on the quality of nearable signal.|
|Distance||Nearables to SmartWatch connection time|
|0.2 m||2-3 sec|
|1 m||4-5 sec|
|2 m||6-15 sec|
|Barriers for nearables (interrupt the signal)||SmartWatch||No signal||Smartphones, laptops, monitors, microwaves, refrigerators, ceramic cups filled with water, the human body. If any of these is in the line of sight, the signal is lost or partially interrupted (transmission quality is deteriorated).|
|Not barriers for nearables (do not interrupt the signal)||SmartWatch||Signal present||Doors, clothes, outerwear, bags, backpacks.|
|Connection of several nearables with a single smartwatch||SmartWatch||OK (4 nearables)||Only the information about the last nearable to be discovered is displayed.|
|Connection of 2+ smartwatches with a single nearable||SmartWatch||OK (2 devices)||The number of devices connected does not affect the nearable signal.|
Despite all this, we consider our initial goal reached with Android Wear (the app received data from a beacon in range, sent it to the server and received information about the location of other beacons, being run on a smartwatch that wasn’t connected to the phone) and partly reached with watchOS.
Our experiment with nearables left us with mixed feelings. I mean, we weren’t impressed with the results. Mainly because, even though the nearables were located with no significant delay in time, the distance to the object has to be no longer than 1 meter, otherwise it wouldn’t get recognized. But if you think about it, on the estimote.com website the beacon stickers are in the “Waiting for certificates” status, and we were lucky enough to get them now. We also used early versions of the SDK (the first version for Android) and probably a lot of its issues have already been fixed and features improved in later versions. One thing we can say for sure: beacons are an amazing technology that has all the potential needed to become huge in the future.