Search code examples
androidbluetoothibeacon-androidaltbeaconandroid-ibeacon

How to detect multiple beacons with same identifiers?

I am looking for a way to detect all beacons within a given region with either the same or different identifiers (UUID, Major and Minor). At the moment, I can detect "randomly" one of the beacons with the same identifier, instead of all of them.

Here is the situation at hand:
I have 3 beacons, respectively:

  1. B1(UUID: 1, Major: 1, Minor: 1) - Distance: 1 meter
  2. B2(UUID: 1, Major: 1, Minor: 1) - Distance: 5 meters
  3. B3(UUID: 1, Major: 1, Minor: 2) - Distance: 6 meters

The beacons are all placed in the same region and when given 3 unique identifiers, for instance B2 having a different minor than B1 and B3, I can verify that all 3 beacons are detected. Which means that there is nothing wrong with the beacons at hand, nor for the region I am scanning in.

The problem is that because B1 and B2 have the same identifier I only receive a collection containing either: B1 and B3 or B2 and B3 in the RangeNotifier.didRangeBeaconsInRegion(Collection<Beacon> beacons, Region region) implementation.

When using the app RadBeacon to configure the beacons, I can, in fact, see all beacons even if they have the same identifiers. Can someone maybe explain why this is happening and how to fix this?

Setup:
Device: Android 5.1 LG G4 (This also happens for the Samsung Galaxy S6 edge)
Library: AltBeacon 2.5.1

Solution

  • By default, the Android Beacon Library will treat all advertisements from transmitters sending the same beacon identifiers as a single beacon. As of library version 2.3, you can configure this behavior so it treats each distinct transmitter (identified by Bluetooth MAC address) as a different beacon. Doing so is as simple as this:

    Beacon.setHardwareEqualityEnforced(true);

    Both the default behavior and this configuration have their advantages for different use cases. It is worth noting that on iOS devices, CoreLocation keeps track of beacons by the bluetooth identifier, so setting the configuration as above more closely tracks the way iOS behaves. The library will likely switch to this as the default in a future 3.0 release.