The beacon’s data is sent continuously usually at an interval of 1 second, depending on what responsiveness is needed for a certain situation.
The power level of the BLE radio can usually also be controlled, to provide a trade-off between detection distance and battery drain.
Not all beacons are battery-powered though. There are USB models available as well.
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 in a practical setting.
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 Chrome and soon Android), 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 often 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 are described more about beacons and uses thereof.