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.
European Economic Area (EEA) countries have new requirements, the Payment Services Directive 2 (PSD2), for processing online payments. When paying by credit or debit card Strong Customer Authentication (SCA) might be needed that takes extra steps, such as a password, text message or fingerprint.
These requirements are being phased in with some Belgian and Dutch cards holders already using schemes such as 3-D Secure. The rest of Europe, excluding the United Kingdom, France and Switzerland will start to be included from January 1st 2021. France will start 1 April 2021 and the United Kingdom and Switzerland will start on 1 June 2021.
We have upgraded our web site to work with Strong Customer Authentication. You will be asked to perform additional steps if SCA is enabled at your card provider and the purchase is within the parameters that need extra authentication.
As a consequence of this, the payment stage on our web site now looks different:
As credit card payments are using stricter checking, there’s the possibility that a particular card that you previously used might now fail. Please contact us should you have problems as we can also process payments manually.
Ericsson has a recent white paper on Bluetooth Mesh where it’s explained how Bluetooth Mesh extends Bluetooth into IoT usecases.
The paper describes how Bluetooth Mesh works including the publish/subscribe model, two-layer security, managed flooding model, friendship nodes and proxy nodes. It’s explained how, after provisioning, the network ‘simply starts working’ and does not require any centralized operation:
No coordination is required and there is no single point of failure
A building automation usecase is described and modelled to determine the Quality of Service (QoS) which they define as the ratio of transmitted packets that reach the end destination within human perceivable time (300ms in this case).
They conclude that higher relay densities result in higher channel congestion. Bluetooth Mesh systems need to be individually configured in terms of the number of relays, use of acknowledged or unacknowledged transmissions, message repetition schemes and transmission randomization.
While the paper provides a good introduction, it doesn’t address the more pragmatic aspects of implementing Bluetooth Mesh networks. For example, the paper states:
The design of Bluetooth mesh has been driven by a desire to create a simple, efficient and flexible wireless mesh networking solution
In our opinion it is not that simple nor specially efficient. The Mesh standard and implementations are relatively complex leading to the need for complex provisioning and setup. It’s for this reason we only supply our SensorMesh™ component as part of larger solutions where we, as opposed by our clients, provision and setup. Mesh is also not as efficient as we have come to expect from Bluetooth in that devices can’t be battery powered over long periods of time. This is because, unlike most Bluetooth devices, mesh devices are scanning for others for a large proportion of the time.
Also, the paper’s claim that “it works on existing devices after a simple firmware update” isn’t always true as mesh devices need much more memory that’s only available on newer Bluetooth SoCs.
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)