A beacon sends data at given intervals around 1 second, but faster for quicker response or slower for better battery life.
The power level of the BLE radio can usually also be controlled, to provide a trade-off between detection distance/reliability and battery drain.
Not all beacons are battery-powered though. There are USB models available as well, so they could use both a short interval and high power.
In theory BLE can reach 100 meters, but is very sensitive to obstructions, so it’s enough with some metal or water in between the beacon and the detecting device to lower that distance considerably, and also make distance calculations flawed at best. Don’t expect more than 20-30 meters for line of sight in a practical setting, and often less than that.
There are numerous beacon formats being available, essentially differing in what data is being sent:
- iBeacon: Apple’s pioneering variant of beacon, sending UUID, major ID and minor ID, that can all be configured to one’s liking
- Eddystone: Google’s variant of beacon, providing separate packets with different uses: UID (similar to iBeacon), URL (supported by Physical Web), TLM (beacon status)
- AltBeacon: An open-source format, backwards compatible with iBeacon
Almost all deployed beacons use iBeacon. Eddystone comes second, and then mainly for transmitting URLs. There are several providers that have beacons that support either iBeacon or Eddystone in the same device, but usually not at the same time.
As the focus is access and interpretation via mobile phones, use cases are typically in situations where people move around, e.g. in retail, exhibits, conferences, museums etc.
Abiro provides support for iBeacon and Eddystone-URL (as of yet) in CliqTags. On the site is described more about beacons and uses thereof. The Physical Web Association (and to some extent Google) drives future use of Eddystone for marketing.