Gluon is a Java-based cross platform tool that creates applications for desktop, Android and iOS devices using the Gluon Scene Builder.
There’s a Beacons code sample that shows how to scan for beacons or broadcast as a beacon.
iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
Gluon is a Java-based cross platform tool that creates applications for desktop, Android and iOS devices using the Gluon Scene Builder.
There’s a Beacons code sample that shows how to scan for beacons or broadcast as a beacon.
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 have a web store category for beacons with an on off button.
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:
Rather than beacons being compatible with iOS/Android, we find that there are more problems with particular Android devices not seeing beacons, when in background, due to some manufacturers killing background services.
There’s new research by Sotirios Kontogiannis and Christodoulos Asiminidis of University of Ioannina, Greece on A Proposed Low-Cost Viticulture Stress Framework for Table Grape Varieties.
The system automatically monitors vine stress to provide real-time surveillance and alerts. It identifies specific areas for irrigation, thereby saving water, energy and time.
The Bluetooth iBeacon protocol is used to relay temperature, humidity, UV levels and soil moisture levels. The authors modified the standard iBeacon protocol, using the existing iBeacon minor and major fields to encode the telemetry data.
You can find the processor chip in the specification section of our beacon descriptions. Most people don’t know what this means or implies. This article will help you make a more informed choice.
There are currently three main chip families from Texas Instruments (CC25xx, CC26xx), Dialog Semiconductor (DAxxxx) and Nordic Semiconductor (nRF51xxx and nRF52xxx). These chip manufacturers publish standard electronic circuits and software SDKs that beacon OEMs use for their beacons. Hence, most beacons, within a chip family, have very similar designs. Small differences in implementation of board layout in areas such as the power supply, grounding, terminations, connectors and the antenna can cause electrical differences that can cause loss of power.
The strength of the beacon radio signal is affected more by the quality of the beacon implementation, particularly the antenna, rather than the choice of chip. This is also evident in real world tests. We have performed RSSI strength and stability tests on the beacons we sell and haven’t yet found any correlation between signal strength and chip family.
The choice of SoC affects battery use. Newer chip families such as the Nordic nRF52 (as opposed to nRF51) and Texas Instruments CC2640 (as opposed to CC2541) are more power efficient.
Most beacon SoCs transmit up to +4dBm output power for a longer range. A few such as the nRF52840 and CC2640RF can be set to higher output power of +8dBm and +5dBM respectively, with a consequent reduction of battery life. If you are looking for longer range, it’s more usual to use a long range beacon with an additional output amplifier chip.
The newer SoCs have much more memory. This isn’t used for most beacons except for those that store data.
The use of standard SoC manufacturer designs and software means that all beacons work well, adhere to Bluetooth standards and compatibility is never a problem.
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.
Read more about transmitted power (as opposed to measured power)
BeaconRTLS™ has a myriad of uses across logistics, manufacturing, healthcare and facilities management. It tracks assets and people to locate them in real time and detect anomalies to improve operational efficiency. This also extends to IoT sensing using sensor beacons that measure temperature, humidity, movement, light, proximity and open/closed.
The system allows you to search for and map the location of beacons. You can set up screen and email alerts based on asset type, location and sensor data. But what if you need more than this?
BeaconRTLS™ stores historical information which provides for industry or scenario specific reporting. For example, recent customers have been asking for Covid specific reports such as room occupancy and who has been in the same room at the same time.
The BeaconRTLS™ API allows your systems or reporting systems to access the data. However, this is of less use for those who want to implement solutions quickly and easily. The tricky part is that we have found every customer tends to need different reporting. Up until now we have been creating ad-hoc reports on a case by case basis.
We have been looking to standardise how custom reports are created with BeaconRTLS™ to reduce effort, time and cost and allow more customers to create reports for themselves. To enable this we have integrated BeaconRTLS™ with Grafana.
Grafana is a free, commonly used open source platform that allows you to show data in custom ways using dashboards and panels. We are creating example Grafana reports for use with BeaconRTLS™ that our customers can use directly or modify for their own use.
Contact us if you are interested in using BeaconRTLS™ and would like to take part in the pilot of BeaconRTLS™ with Grafana.
We have previously written about Bluetooth LE on the Factory Floor and Why Bluetooth LE Scanning Doesn’t Always See Devices (the First Time).
There’s a new informative paper by Martin Woolley of the Bluetooth SIG on How Bluetooth® Technology Makes Wireless Communication Reliable. It describes in detail how radio collisions, multi-path propagation, time-dispersion, transmitter-receiver synchronisation, signal strength, receiver sensitivity and buffer overflow can collude to make radio communications unreliable.
The paper explains how Bluetooth modulation schemes, CRC checks, multiple channels, coded PHY, adaptive frequency hopping, flow control and the ATT protocol work to make Bluetooth LE reliable.
The paper also takes a look how Bluetooth Mesh has been designed to achieve reliable communication.