Some manufacturers offer SDKs to allow programmatic access to their beacons from iOS and Android.
Most SDKs tend to be poorly implemented/documented, tie your code into using that particular beacon and rarely get updated to use newer mobile platform APIs. They also tend to be thin abstractions over the Android and iOS Bluetooth APIs.
If you rely on a beacon manufacturer that doesn’t update their SDK, it’s eventually the case that the underlying Android and/or iOS API changes such that your solution becomes non-optimal and, in the worse case, breaks.
Instead, when you can, we recommend you use the iOS and Android Bluetooth APIs directly to make your code independent of the beacon type. In this way you don’t end up depending on intermediate code and this has the benefit that you can more easily change beacon providers.
However, there are some cases where you must use the manufacturer library. This is usually in cases where there the app needs to connect with the beacon (as opposed to only view advertising scans) to perform beacon specific things. The Sensoro SDK is an example where their private protocol (to prevent squatters) and sensor information can only be obtained via their SDK.
We get asked a lot which beacons are the most compatible. All beacons, whether iBeacon or Eddystone, are compatible with iOS and Android. There are a few ‘tracker’ type Bluetooth devices around that don’t transmit the right Bluetooth header and can’t be seen on iOS but we don’t sell those.
Almost all beacons are slight derivations of a few standard circuit designs and firmware provided by Texas Instruments, Dialog and Nordic who produce the System On a Chip (SoC) inside beacons. Hence, they all transmit to Bluetooth standards.
The main areas where beacons differ is not in compatibility but in physical characteristics such as battery size and waterproofing that are to be found as categories at the left hand side of our store.
One thing people don’t realise is that problems occur with phone compatibility rather than beacon compatibility. Over time, we have discovered about 5% of our customers have problems getting the Manufacturer’s configuration to app connect to beacons on Android. To be clear, this is only when apps need to connect (to change settings) as opposed to only scan for beacons so this doesn’t tend to be a problem (for end users) once everything is set up.
To answer the question, Bluetooth standards are such that all beacons can be seen on all phones and compatibility isn’t an issue. Problems we have seen have been related to phones rather than beacons. We have never had a beacon returned to us because it’s incompatible.
“Where Can I Find a Beacon Solution that Does xyz?”
Where xyz could be one of many things. Unfortunately, we don’t have a full knowledge of what’s out there, particularly because it’s continually changing.
We maintain a BeaconZone Solutions Directory where we list solutions we have found in the categories of marketing/retail, industry/logistics, buildings/staff, visitor spaces, transportation, education and personal.
You might wonder whether USB beacons can be used to enable desktops/laptops or any USB device to receive beacon transmissions.
USB beacons don’t work this way and only use the USB connection for power. A few such as the Minew U1 have UART USB serial support that can be used to control the beacon but it still doesn’t detect beacons. It beacon only sends and doesn’t receive.
What you need is a ‘Sniffer’ such as the ABSniffer 528. It scans for Bluetooth devices and sends the data via USB to the device powering it.
Alternatively, look for a standard Bluetooth dongle that that supports Bluetooth Low Energy (LE) and an associated programming API for ESP32, Raspberry Pi, Windows or Linux.
Beacons with an on off button are popular for product/app development because they allow testing of going into and out of range without actually physically doing so. They also allow the battery to be turned off to save power when the beacon isn’t being used for testing.
However, don’t solely rely on the button for testing the beacons as they go out of and into range. Actually do some tests at the edge of the detection area. Determine how your app behaves as it continually sees the beacon appear and disappear, particularly on Android where, unlike iOS in background, the OS doesn’t impose a period that a beacon has to be out of range before it’s considered seen again. On iOS, also test at the edge of detection when the app is in background or not.
Another way of hiding beacons is to use a Faraday bag:
We often get asked the question which beacons are compatible with iOS and Android. All beacons, whether iBeacon, Eddystone or sensor beacons can be used with iOS and Android. The compatibility is achieved through the implementation of common Bluetooth standards on these mobile platforms.
However, there are some caveats:
Android only supported Bluetooth LE as of Android 4.3. Older devices can’t see Bluetooth beacons. Over 95% of users are on Android 4.3 or later so most people can see beacons.
Apple iOS doesn’t have background OS support for Eddystone triggering. While iOS apps can scan for, see and act on Eddystone beacons, the iOS operating system won’t create a notification to start up your app when there’s an Eddystone beacon in the vicinity.
Beacons don’t generally need to store data because they are just sending out their unique id. However, sensor beacons do sense values over time that you might want to collect later via, for example, an app coming close to the beacon. Specialist devices such as social distancing beacons need to store close contacts for later collection.
Beacons use a System on a Chip (SoC), such as the Nordic nRF51, that includes memory. Most of the memory is used for the internal functioning of the beacon. Newer versions of SoC, for example the Nordic nRF52, have more memory that allows data to be stored.
There are some sensor logger beacons that store sensor values but this tends to be restricted to temperature logging.
Most beacons’ configuration app have a setting for iBeacon ‘measured power’ or ‘RSSI at 1m’. This doesn’t change the power output by the beacon. Instead, it’s a value that’s put into the advertising data that declares to receiving devices what the power should be at a distance of 1 meter from the beacon. Receiving devices such as smartphones and gateways can use this to help calibrate a calculation to determine the rough distance from the beacon.
You don’t usually change this value and it’s actually rarely used. In most cases the value is irrelevant and can be ignored. However, if your app or receiving device does use this value, it’s best to first do some tests to see what the power level is in your particular situation. Things like the physical environment, blocking and beacon orientation can affect the actual power level at 1m. Set the value according to your particular scenario.
We sometimes get asked if we have a replacement for Estimote beacons. There’s no exact replacement because Estimote manufacture their own custom product and only allow their own beacons on their platform.
However, if your app doesn’t use the Estimote SDK and just detects iBeacon advertising using the standard iOS and Android Bluetooth libraries then you can use any iBeacon. Also see our post regarding compatibility.
TRBOnet is a 2-way radio dispatch system sold and supported by Motorola. It can use iBeacons to provide for locating where the Motorola radio GPS doesn’t work. This allows radios and hence people to be located indoors or undercover areas such as trees.
TRBOnet Plus will work with any iBeacons. The ones with higher battery capacity tend to be used so that batteries don’t have to be replaced for years.
The i3 is popular for use with TRBOnet as it takes AA batteries that can be easily sourced and the unit has screw tags for permanent mounting. Some sites also use USB beacons that can be powered from the mains via USB power supplies.
If you use the i3, or any beacon using AA batteries, we recommend you use lithium AA batteries rather than alkaline. This will not only provide a longer battery life but will also provide better resilience at lower temperatures.