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 mobil phone), which in turn sends a Scan Request packet to the detected beacon.

nRF52 broadcasting

Introduction of Beacon Pros BP16-3, based on new Nordic Semiconductor nRF52 Series chipset, marks a change of how beacons broadcast their advertising packets. For all nRF52-based devices we divide all possible advertising packets into four groups:

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

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.

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 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 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 Secure Profile packet. 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 Secure Profile packet – it is broadcasted with a separate, fixed interval of 1000 ms. It's possible that the 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 Secure Profile packet or iBeacon/Eddystone packets, making sure there are at least 100 ms between them.


Data Streams

Since there is no way to bind nRF52 beacon's iBeacon or Eddystone advertising packets with each other and with it's Secure Profile (because of different MAC addresses), Data Streams report each packet as a separate sighting of different devices in Presence Data Streams. Since iBeacon and Eddystone packets are non-connectable, so they don't trigger scan requests on Gateways and don't send scan response packets with additional data, they are assigned their own Tracking IDs in form of their virtual BLE broadcasters' MAC addresses. Detections of Secure Profile and Telemetry packets are, on the other hand, reported with Beacon Pro's Unique ID as a Tracking ID. Because all of that a single Beacon Pro can be reported from 2 to 4 times, depending on the number of active packets.

Android SDK

When 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 Secure Profile and iBeacon/Eddystone packets on a nRF52-based beacon, these listeners will report devices only with iBeacon/Eddystone data, but without 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.