I’ve beed testing the nearables and have a few issues with ranging.
I’m using iOS SDK 3.2.3 (3.2.5 was constantly crashing with nearables).
I managed to setup ranging and got the didRangeNearable delegate method calls. However most of the time the nearable.zone was ESTNearableZoneUnknown and even with distances of only a few centimeters couldn’t get ESTNearableZoneImmediate (sometimes did get ESTNearableZoneNear with a lot of ESTNearableZoneUnknown in between).
Does anyone have the same experience with stickers?
Is this the default behavior or are my stickers not functioning properly?
Are stickers even meant to be used for ranging applications?
The stickers are placed in distances from 5 to 15 centimeters from the iPad.
The trouble is that there’s way too many zone: 0 events and however close i place the sticker, I’m unable to get a zone: 1 range. For stickers further away from the device, the zone: 0 events are even more frequent.
I tried moving the stickers but it’s too hard to say if it improves anything.
About 3.2.5 crashing …
I imported the 3.2.5 version again and could not replicate the crash. I did actually get better results for ranging with 3.2.5. Way less ESTNearableZoneUnknown but still no ESTNearableZoneImmediate.
Also couldn’t find any crash logs on the device.
As far as i remember the crash reason, it was something with trying to setObject: forKey: method being called on an immutable NSDictionary. This was triggered by startRangingForIdentifier called on ESTNearableManager (could also be startMonitoringForIdentifier).
Wish I could be more helpful with this. Will try some more again when I find some spare time.
With the 3 stickers I was testing initially I couldn’t get the immediate zone ranged no matter how close I put the sticker. Tried it again with all the stickers in the pack and I could get 1-2 ranged in the immediate zone. They were always the same 2 stickers.
To illustrate I’m attaching an image with a iPhone running the Estimote app next to a pack of stickers.
Not really useful ranging. Especially if you compare it to the beacons.
Edit: a bit later I tried the same with an iPhone 6 and it worked a little bit better (after a while 3-4 stickers were ranged immediate with the phone in the same position).
Hi there. Are you still having problems with getting reliable proximity readings with the stickers?
We’re initiating a research project where the reliability of beacon proximity is an important measurement. We have 6 of the standard estimote beacons that we are testing with but are intending to move to stickers in future as they are a more desirable form-factor (currently on the waiting list I believe).
Just beginning to test the relative signal strengths. The (android) app shows some deviation between beacons in terms of measured distance vs actual but no where near as bad as shown in Matija_Kregar’s picture above! If we can somehow calibrate each beacon then this becomes less of an issue but I’m not aware how to do this…
Is there really that big of a difference between the beacons and the stickers in terms of consistency in proximity readings?
Yes, we’re aware of issues with stickers and proximity zones, that’s something we definitely want to improve in one of the future SDK releases. It’s important to understand though that sticker beacons—due to their lower advertising frequency and transmit power, both in an effort to make the most out of the much smaller battery—won’t be as precise as the regular beacons when it comes to estimating proximity.
Philosophically, we envision our bigger beacons as the ones to use for proximity-based use cases, like detecting if somebody’s close to a certain area, or for our Indoor Location technology. (We even started calling them “location beacons” internally some time ago, to distinguish them in conversations from the “sticker beacons.”)
Stickers on the other hand we currently envision more as something you’d put on moving objects, to keep track of them—both because their packet contains more “state” data (accelerometer readings, orientation, temperature, how long they’ve been in motion/still etc.), and because you probably wouldn’t want to put a regular beacon on your keychain.
Surely, with time they’ll get better at the location part too (as batteries get better, and we continue innovating on the more energy efficient firmware, we’ll be able to transmit more frequently and with greater power), but that’s mostly because we want to get better at being able to tell you if you’re near or far away from your laptop, wallet, etc. For the use cases where you can afford placing a bigger beacon and don’t need all the extra state data (although our next-generation beacons will probably be capable of broadcasting more too), “location beacons” would likely still be the way to go, if only because of the bigger battery = longer lifetime.
@OctanMan
I could go as far as saying that with beacons the proximity readings are not causing any problems. Sometimes there’s a short delay but as far as my tests go it’s quite reliable.
Stickers are another story though. Proximity is all over the place.
Heypiotr’s answer indicates the same. I sure hope they find a way to solve this issue.
In my opinion the “tracking beacons” should be able to calculate distance in a reliable manner as well. This would make stickers way more useful without them competing with beacons.
I’ve been testing ranging with stickers intensively over the past few months, and I keep thinking it will get better, but it hasn’t. I agree with Matija that zone readings are worthless.
However, the RSSI readings I get in the Estimote app for stickers seem to be a lot more useful for ranging. I wonder how we can get this…
We use the ESTNearableManager in our app, and its ranging methods, and this gets us the ESTNearable objects, which include the rssi property.
If you require “precise” distance approximations, the larger beacons will be a better option for the foreseeable future. Stickers simply have too small battery to broadcast with high frequency (without having your stickers run out of battery in a few weeks/months), something that is required for good proximity estimations. We’re hard at work to make it better despite the odds, but I’m afraid I have nothing to share yet at this time.
, we’ll look into it!