When I use a scanners such as BLE Tool or BLE Scanner on iOS or BeaconScanner on the Mac desktop I can see my estimote stickers, but I see very inconsistent updates from them unless they are moving. Now, I know that the frequency of packets is increased when moving, but… this doesn’t seem to account for it. e.g. I think I see the rate of updates that I expect while moving and then for a few periods after they come to rest, but after that they just seem to disappear. Are Apple’s lower level APIs filtering them out for some reason when the RSSI and data are not changing?
Maybe the scan window of these scanners is simply too short? When still, and with default settings, stickers broadcast every ~ 2.5 s, and accounting for the packet loss, time-to-discovery might be something between 2.5–10 seconds.
Plus, there’s another implementation detail to keep in mind: stickers rotate their MAC address, so to a Bluetooth scanner, they will keep showing up as new devices.
Regarding the broadcast window - In particular with the BeaconScanner I bumped their “time to live” which I believe governs when they clear items from their list up to 60 seconds - unless you are talking about a lower level BT parameter that I’m not familiar with. The behavior I’m seeing is consistent across a couple of iOS and OS X apps - shaking a sticker seems to prompt it to appear in the scanner in a way that does not feel to me warranted by the change in broadcast rate. Based on your response to my other question I am going to write a lower level scanner to see the packets and try to determine myself what is going on.
Regarding the MAC addresses - This is something else I’ve been confused about and could not find documentation on. In third party scanners I sometimes see an endless list of device UUIDs, some of which I assumed were randomly generated. However that is not the case with the estimotes, where depending on the software I either see the real proximity UUID or the beacon UUID. I’m not sure how the MAC address rotating would come into play here… or if my two issues above might be related - i.e. if something is streaming random UUIDs could that be confusing or overwhelming the iOS / OS X bluetooth stack?
thanks.
I have figured this out - I think what I was seeing and what the third party scanners are seeing is the fixed UUID / named packet broadcast by the estimote for its “nudge” gesture. Normally the estimote rotates its UUID but when you move it it briefly broadcasts a real UUID and name.
Normally the estimote rotate their UUID and I can see all of those packets with core bluetooth roughly as expected.