Skip to content

Broadcasting Rules

The way beacons broadcast their Bluetooth advertising packets varies quite significantly depending on whether they are based on nRF51 or DA14580 SoCs, or whether they use a nRF52-series chip. Below is an overview of both of these broadcasting schemas.

nRF51/DA14580 broadcasting

Beacons based on these chipsets broadcast all the advertising packets as connectable (ADV_IND). All packets broadcasted by a single beacon are identified by the same MAC address.

The management data for these devices, like beacon's Unique ID, firmware version, battery level, etc. is a part of Secure Response packets broadcasted when a connectable packet gets detected by a scanning device (e.g. a mobile phone), which in turn sends a Scan Request packet to the detected beacon.

nRF52 broadcasting

For all nRF52-based devices we divide all possible advertising packets into four groups:

  • Kontakt.io packets (Secure Profile, Telemetry and Location)
  • iBeacon
  • Eddystone (UID, URL, TLM)
  • Encrypted Eddystone (EID, ETLM)

These beacons use separate virtual BLE broadcasters to send packets from each group. Because of that, packets from different groups have different MAC addresses, so by 3rd party scanners they are treated as packets sent by unrelated beacons.

However, MAC addresses of Kontakt.io and standard iBeacon and Eddystone packets are sequential and this information can be used to associate various packets with each other. For example, if a given beacon broadcasts Kontakt.io packets with using 12:AB:45:CD:EF:F1 address, then iBeacon packets from that beacon will have 12:AB:45:CD:EF:F2 MAC and Eddystone packets will use 12:AB:45:CD:EF:F3.

Please keep in mind that sequential MAC addresses apply only to standard, unencrypted and not shuffled packets. It means that Eddystone EID and ETLM packets, as well as Kontakt.io Secure iBeacon and Eddystone packets always use random MAC addresses.

Warning

Please be aware that behaviour described above does not relate to beacons shipped before 20.01.2020. Beacons manufactured before that date have MAC addresses that are not related and are completely random.

Having packets that are treated by scanners as coming from different sources allows us to make all iBeacon and Eddystone packets non-connectable (ADV_NONCONN_IND), but at the same time we keep nRF52-based devices easily configureable through Kontakt.io Secure Profile which is a connectable (ADV_IND) packet with management data. This way we increase compatibility and discoverability of standard advertising packets (iBeacon, Eddystone) while maintaining the ability to configure nRF52-based devices at will, just like any other Kontakt.io device. In order to provide compatibility with iOS and Android devices, beacons based on nRF52 Series chipset are capable of responding to Scan Requests with a Scan Response packet that is associated with the connectable Kontakt.io Secure Profile packet.

Kontakt.io Secure Profile is also the only packet that in general can't be disabled on nRF52-based devices during their standard operations. The only exception is possible on button-equipped beacons. It is also the only packet broadcasted when nRF52-based devices are in most of Power Saving modes, although there are some exceptions as well.

The advertising interval on nRF52-based beacons works mostly the same way as on older models – it sets a time period between each broadcasted packet, so the time between the packets of the same type might vary depending on a number of different advertising packets enabled on a beacon. The only exception is the Kontakt.io Secure Profile packet – it is broadcasted with a separate, fixed interval of 1000 ms. It's possible that the Kontakt.io Secure Profile packet's broadcasting schedule might interfere with the schedule of iBeacon and Eddystone packets' advertising interval. In these instances beacons will automatically adjust the broadcasting time of Kontakt.io Secure Profile packet or iBeacon/Eddystone packets, making sure there are at least 100 ms between them.

Implications

Android SDK

When Kontakt.io Android SDK detects an iBeacon or Eddystone packet coming from a nRF51- or DA14580-based beacon it automatically associates it with data from a corresponding scan response packet. Because of that IBeaconListener or EddystoneListener report all possible information about a beacon in IBeaconDevice/IEddystoneDevice object. But since we can't use MAC addresses to link data from Kontakt.io Secure Profile and iBeacon/Eddystone packets on a nRF52-based beacon, these listeners will report devices only with iBeacon/Eddystone data, but without Kontakt.io-specific information like Unique ID, battery level, etc. There is a special listener for Secure Profile-enabled beacons to get this data - SecureProfileListener - but for the same reason it won't be able to get iBeacon/Eddystone identifiers.