Why do we need MAC rotating if we broadcast the ID and the UUID directly in the visible packet?
The reason I’m asking it is a crash of bluetooth I got recently.
It’s an implementation detail we decided to go for in order to enhance iOS background detection. On iOS, in the background, advertising packets from a specific device are delivered only once per Bluetooth scan—e.g., if iOS decides to scan for 10 seconds, it’ll only report the first packet for each device it detects. However, if we rotate the MAC addresses with each packet, we’ll get all the packets instead (because we trick iOS into thinking that these are all different devices, and we later “merge” them into a single Nearable in our SDK), and thus can do much better proximity estimation, and also access more fine-grained sensors readings.
What device and Android version have you experienced the crash on? It was supposedly fixed in Android 4.4.4 (https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/aefcb18) and in 5.0, there’s a completely new Bluetooth LE API that also doesn’t have this issue. The original bug report (https://code.google.com/p/android/issues/detail?id=67272) was obsoleted.
Thanks for such a good explanation!
I have a Nexus 5 with the latest Android on it.
It is possible that I met another bug… I was playing with Wearable.DataApi … maybe I sent to many dataItems from the phone to the watch… I don’t know. But I had same symptoms. Bluetooth service didn’t respond anymore. I had no error message. It just stopped to work. If I tried to put it on, it didn’t respond, no reaction.
The only solution was the reset the phone.
Interestingly, the bluetooth service on the Watch behaved the same. I was not able to discover new bluetooth devices.
So, probably, it was another bug.
Aha, I think I know this bug! I think I experienced the same one on my Nexus 5 w/ Android M. In my case, Bluetooth went off without any error message and I couldn’t enable it anymore (tapping on the Bluetooth icon wasn’t doing anything). I had to do a factory reset to fix that. It’s a known bug: https://code.google.com/p/android/issues/detail?id=191831. The latest update from an Android team member is “The development team has fixed the issue that you have reported and it will be available in a future build.”, from 7th of January. But it hasn’t been released yet AFAIK. (The comments seem to confirm that.)
1 Like
Hi there,
My customers have reported the same issue regarding android and rotating MAC Addresses on Nearables.
Is there some way to make the Nearable to stop rotating the MAC? We are about to deploy our beacons to a large facility, with lots of people and I’m afraid that older versions of android still have the issue, so it can be a real problem for us.
Thanks
Thanks for your feedback @joaortk. No such option at this moment I’m afraid, so I’m not sure how we could help in the very short term ):
Sad to hear that.
I will encourage my customers to try and return the Stickers to Estimote, in exchange for another kind of Beacon, so at least they don’t end up with a bunch of useless hardware (for them, anyway).
Is there any way you guys could help in this matter? It would really set us back in the project if they don’t get to exchange the Stickers they bought, and it is not their fault.
thanks
Sorry to hear that 
Just let them know to email us to contact@estimote.com, and we’ll do our best to help.
hi,
we trying to track acceleration-data out of the broadcasted advertisment-data. we are able to parse the advertisment data, followed by your javascript-spec files on github. the problem is we want to track the beacon data. it would be an huge overhead to parse everysignal and check the nearableID (which should be unique to identify it).
is there maybe the feature to disable the mac-address switching now or do you know another possibility to identify the beacon?
another following question: is there a pattern of the switching itself? e.g. how often does it switch, is there a list of mac-addresses it uses, or does it generate random mac-addresses, etc.
There’s no way to disable the rotation I’m afraid. As far as I remember, it rotates on every single packet, in a random manner.
I personally don’t think parsing a few extra bytes is too much of an overhead. What device are you scanning with?
If this is a major problem, and form factor doesn’t matter for your project, you could try our Proximity Beacons instead. They also broadcast telemetry data similar to the Nearable packet, and they don’t rotate their MAC address.
Computers have come a long way, but this orientation remains the same. You may wind up with a lot of tasks that are better suited for a long vertical, like long runs of text that you’re writing, lots of lengthy menus or a huge array of palettes, or material that stacks well in wide rectangles from top to bottom for reference, like resized windows.