Stickers / Nearables ranging useless

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 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?

Thanks a lot for sharing, we appreciate your feedback! Really sorry that stickers are giving you trouble.

Any chance for a stack trace from the 3.2.5 crashes? Would help us investigate and fix the problem.

It’s strange ranging doesn’t work for you, does it happen with all your stickers? Is it any better when you’re moving them?

Regarding the ranging. Here’s a log of the didRangeNearable method.

2015-06-05 15:11:16.056 BeaconsDemo[1729:695820] rangedNearable: Fridge
2015-06-05 15:11:16.056 BeaconsDemo[1729:695820] zone: 0
2015-06-05 15:11:17.054 BeaconsDemo[1729:695820] rangedNearable: Car
2015-06-05 15:11:17.055 BeaconsDemo[1729:695820] zone: 0
2015-06-05 15:11:17.055 BeaconsDemo[1729:695820] rangedNearable: Bag
2015-06-05 15:11:17.056 BeaconsDemo[1729:695820] zone: 2
2015-06-05 15:11:17.056 BeaconsDemo[1729:695820] rangedNearable: Fridge
2015-06-05 15:11:17.056 BeaconsDemo[1729:695820] zone: 2
2015-06-05 15:11:18.054 BeaconsDemo[1729:695820] rangedNearable: Car
2015-06-05 15:11:18.055 BeaconsDemo[1729:695820] zone: 0
2015-06-05 15:11:18.055 BeaconsDemo[1729:695820] rangedNearable: Bag
2015-06-05 15:11:18.056 BeaconsDemo[1729:695820] zone: 2
2015-06-05 15:11:18.056 BeaconsDemo[1729:695820] rangedNearable: Fridge
2015-06-05 15:11:18.056 BeaconsDemo[1729:695820] zone: 2
2015-06-05 15:11:19.055 BeaconsDemo[1729:695820] rangedNearable: Car
2015-06-05 15:11:19.055 BeaconsDemo[1729:695820] zone: 0
2015-06-05 15:11:19.055 BeaconsDemo[1729:695820] rangedNearable: Bag
2015-06-05 15:11:19.056 BeaconsDemo[1729:695820] zone: 2
2015-06-05 15:11:19.056 BeaconsDemo[1729:695820] rangedNearable: Fridge
2015-06-05 15:11:19.056 BeaconsDemo[1729:695820] zone: 2
2015-06-05 15:11:20.054 BeaconsDemo[1729:695820] rangedNearable: Car
2015-06-05 15:11:20.055 BeaconsDemo[1729:695820] zone: 0

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.

Managed to catch the crash again…

2015-06-05 16:21:09.073 TempTest[534:188644] -[__NSDictionaryI setObject:forKey:]: unrecognized selector sent to instance 0x15592cb0
2015-06-05 16:21:09.074 TempTest[534:188644] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSDictionaryI setObject:forKey:]: unrecognized selector sent to instance 0x15592cb0'
*** First throw call stack:
(0x27d10fef 0x35fc2c8b 0x27d16409 0x27d14327 0x27c43e78 0xf450f 0xf3dfb 0xe41a3 0xd87f7 0xe1c51 0x27852e29 0x28a3965d 0x289a44d1 0x28996e87 0x28a3bfc7 0x28f15f 0x292e45 0x27cd6609 0x27cd4d09 0x27c21201 0x27c21013 0x2f500201 0x2b3c5a59 0xc5461 0x3654eaaf)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb) po [NSThread callStackSymbols]
<_NSCallStackArray 0x155a1be0>(
0   ???                                 0x023bbcec 0x0 + 37469420,
1   TempTest                            0x000c53f5 main + 0,
2   libsystem_c.dylib                   0x365b4909 abort + 76,
3   libc++abi.dylib                     0x358e09c9 __cxa_bad_cast + 0,
4   libc++abi.dylib                     0x358fa671 <redacted> + 0,
5   libobjc.A.dylib                     0x35fc2f25 <redacted> + 192,
6   libc++abi.dylib                     0x358f7de3 <redacted> + 78,
7   libc++abi.dylib                     0x358f75a9 <redacted> + 0,
8   libobjc.A.dylib                     0x35fc2d5f objc_exception_throw + 250,
9   CoreFoundation                      0x27d16409 <redacted> + 0,
10  CoreFoundation                      0x27d14327 <redacted> + 714,
11  CoreFoundation                      0x27c43e78 _CF_forwarding_prep_0 + 24,
12  TempTest                            0x000f450f -[ESTCacheManager updateNearable:inCache:] + 78,
13  TempTest                            0x000f3dfb -[ESTCacheManager requestManagerDidSendRequest:withResponseData:withError:] + 1834,
14  TempTest                            0x000e41a3 -[ESTRequestManager request:didFinishLoadingWithResposne:] + 166,
15  TempTest                            0x000d87f7 -[ESTRequestNearableInfo parseRespondedData:] + 350,
16  TempTest                            0x000e1c51 -[ESTRequestGetJSON connectionDidFinishLoading:] + 284,
17  CFNetwork                           0x27852e29 <redacted> + 56,
18  Foundation                          0x28a3965d <redacted> + 8,
19  Foundation                          0x289a44d1 <redacted> + 148,
20  Foundation                          0x28996e87 <redacted> + 774,
21  Foundation                          0x28a3bfc7 <redacted> + 186,
22  libdispatch.dylib                   0x0028f15f _dispatch_client_callout + 22,
23  libdispatch.dylib                   0x00292e45 _dispatch_main_queue_callback_4CF + 1512,
24  CoreFoundation                      0x27cd6609 <redacted> + 8,
25  CoreFoundation                      0x27cd4d09 <redacted> + 1512,
26  CoreFoundation                      0x27c21201 CFRunLoopRunSpecific + 476,
27  CoreFoundation                      0x27c21013 CFRunLoopRunInMode + 106,
28  GraphicsServices                    0x2f500201 GSEventRunModal + 136,
29  UIKit                               0x2b3c5a59 UIApplicationMain + 1440,
30  TempTest                            0x000c5461 main + 108,
31  libdyld.dylib                       0x3654eaaf <redacted> + 2

Hope this helps …

Awesome, thanks :confetti_ball:, we’ll look into it!

Maybe related:

We’ve done two bugfix releases that bring some improvements to the nearables APIs, could you guys check if these are still crashing for you in 3.2.7?

Didn’t crash in the few minutes I was testing it. Seems like the nearables caching fix did the trick.

But one question still remains. Is it possible at all to get ESTNearableZoneImmediate zone while ranging stickers? Has anyone else tried this?

Do you observe this for all your stickers or just a single one?

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.

I moved 3 posts to a new topic: Are stickers good to trigger videos/photos within 3 feet?

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.