No Firmware NanoBeacon SoC

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. The SoCs are general purpose devices that can do a lot more than just advertise as beacons but the beacon manufacturers only provide fixed firmware that performs just this one function, occasionally with additional sensing.

The use of firmware-based SoCs for beacons means there’s a lot of hardware and software (SDKs) that goes into creating a beacon. Much of this isn’t needed if the chip is designed for the single purpose of being a beacon. We previously mentioned the AK1594 but have yet to see any designs making use of this device.

NanoBeacon IN100 SoC

The InPlay NanoBeacon IN100 is a newer device that has recently received Bluetooth 5.3 certification. It’s small (DFN8 is 2.5 x 2.5mm), inexpensive (designs using it are expected to be <$1) and no firmware or SDK is required.

The IN100 uses only 650nA when used with 1 minute advertising intervals that means it will last a very long time under battery power. The range can be up to several hundred meters. It’s configured using a programmer board connected by USB. A smartphone app is used for configuration. InPlay have a video demonstrating configuration:

We expect this SoC will end up being embedded in products rather than being used stand-alone in beacons because beacon manufacturers are already heavily invested into firmware-based beacons.

Which Beacons are the Most Compatible?

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.

Use of standard SoC Chip and firmware libraries ensures Bluetooth compatibility

The main area that can differ is the Antenna and PCB layout that can lead to different radiation patterns. The ability to detect a beacon isn’t affected and differences manifest themselves as differing beacon signal strength (hence range) and stability.

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.

New Nordic Semiconductor Wireless Q Magazine

Nordic Semiconductor, the manufacturer of the System on a Chip (SoC) in many beacons, has published the latest online issue of Wireless Quarter Magazine. It showcases the many uses of Nordic SoCs.

The latest issue of the magazine highlights the increasing use of IoT. Nordic Semiconductor has been known for enabling Bluetooth and cellular solutions and with their recent acquisition of Imagination Technologies this now extends to WiFi.

The magazine covers many usecases including:

  • Bluetooth connected prosthetics
  • CHIP smart home
  • Smart health

There’s also an informative article exploring the usefulness of patents.

Read about Beacon Proximity and Sensing for the Internet of Things (IoT)

Sensor beacons

Gateways

Differences in Beacon System on a Chip (SoC)

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.

nRF51822 in a round beacon

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.

Can Beacons Store Data?

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.

Temperature Logger Sensor
M52-SA Plus Temperature Logger Beacon

There are some sensor logger beacons that store sensor values but this tends to be restricted to temperature logging.

Q3 Nordic Semiconductor Wireless Q Magazine

Nordic Semiconductor, the manufacturer of the System on a Chip (SoC) in many beacons, has published the latest issue of Wireless Quarter Magazine. It showcases the many uses of Nordic SoCs.

It showcases a gym management platform using beacons that analyses equipment and zone use. It also mentions the nRF52 SoC, used in beacons, being used in

  • MEZOO’s ECG monitor that detects heart arrhythmia
  • Xiaomi’s Bluetooth LE smart door lock
  • M Lura Health’s 1000 tooth sensor
  • Escort’s fuel level sensor

Juniper Research reports on how the pandemic is accelerating use of IoT:

IoT connections driven by early industrial deployments and pandemic-driven telemedicine applications are projected to reach 83 billion by 2024, a 130 percent growth rate

There are also articles on using tech to prevent deforestation, wellness tech, smart street lighting and precision positioning.

Bluetooth Standards Pros and Cons

Here at BeaconZone we create solutions based on products that use Bluetooth LE. The Bluetooth standards are created and maintained by the Bluetooth SIG. This post briefly explores the advantages and disadvantages of such standards and the opportunities and risks of going off-piste using 3rd party wireless standards.

The main advantage of the Bluetooth LE standard is interoperability. We can use beacons, sensor beacons, smartphones, gateways, single board computers such as the Raspberry Pi, laptops and desktops in solutions and be sure they can communicate using Bluetooth LE. More specifically, we can use the Bluetooth APIs on these platforms and they speak a common language and ‘just work’. Bluetooth has also recently introduced standards on top of the Bluetooth LE standard that provide for mesh networking and angle based location.

The Bluetooth LE standard has caused the ecosystem of System on a Chip (SoC) vendors such as Texas Instruments, Nordic Semiconductor and Dialog Semiconductor to create inexpensive sub-systems and SDKs that simplify implementing new products based on the standards. This, in turn, has created a large variety of devices that can talk to each other even though they use hardware from different vendors. The variety of devices has increased competition, keeping device prices down.

The problem with standards is that they evolve very slowly and might not be optimal for specific situations. This creates an opportunity for 3rd parties to create alternative wireless solutions such as Ultra Wideband (UWB) devices, custom mesh networking and custom location schemes that can provide better performance in aspects such as accuracy, physical range and battery life. These custom products cost more because they are more involved to create/manufacture and their unique features can command a higher price. However, there’s the risk that if/when the companies producing these products go out of business, your solution will become end-of-life with no second sourcing. This is a particular risk when the product involves some sort of software as a service (SAAS), irrespective of standards.

Choosing a wireless technology for your solution involves a trade off between performance, cost and risk. It’s wise to first seek a standards-based and stand-alone (not SAAS) approach and only deviate if you find what you need to do isn’t served by available solutions.

Q1 2020 Wireless Q Magazine Available

Nordic, the manufacturer of the System on a Chip (SoC) in many beacons, has published the latest issue of Wireless Quarter Magazine. It showcases the many uses of Nordic SoCs.

In the magazine you can find lots of new products using the same technology found in Bluetooth beacons:

  • Citizen Watch’s solar powered watch
  • Sphero RVR programmable robot
  • F5 Sports smart baseball
  • A wearable canine activity tracker that monitors pet exercise
  • An equine monitoring solution helping farmers monitor horses’ health

Concurrent Transmission (CT) Bluetooth

There’s new research BlueFlood: Concurrent Transmissions for Multi-Hop
Bluetooth 5 — Modeling and Evaluation
(pdf) that looks into using concurrent transmissions (CT) with Bluetooth.

Today’s Bluetooth devices use advertising, GATT connection and mesh. Advertising occurs over three channels to reduce the affects of wireless interference. When more than one device advertises at the same time, the data is lost. However, advertising takes of the order of 1ms so the chance of collision is usually small.

In contrast, BlueFlood uses concurrent transmissions (CT) that purposely synchronise transmissions such that if colliding packets are tightly synchronised and have the same contents, the resulting signal might be distorted, but highly probable that they do not destruct each other. This is used with the Glossy flooding protocol and 40 rather than 3 advertising channels.

CT-based protocols achieve enormous performance gains in terms of end-to-end reliability, latency and energy consumption even under harsh interference conditions

Concurrent transmissions are challenging using Bluetooth because transmissions need to be synchronised down to 250ns. Nevertheless, the researchers show this is possible using standard Bluetooth PHY and commercial Nordic SoCs. They achieved an end-to-end loss rate below 1% and managed to receive the signals on a standard smartphone. While the mechanism was fragile it was found to be viable.

SweynTooth and Beacons

New vulnerabilities, called SweynTooth, have recently been found in Bluetooth LE. The problems aren’t in Bluetooth itself but in software development kits (SDKs) provided by some System on a Chip (SoC) manufacturers.

There are three types of problem that can be triggered by sending particular data to Bluetooth devices: crash, deadlock and security bypass. Only some manufacturer’s SDKs are affected and only some of their SoCs models.

Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics and Telink Semiconductor SDKs are affected. The main manufacturer used in beacons in beacons and gateways is Nordic so the majority of beacons are not affected. Nevertheless, there are a few beacon models that use Texas Instruments and Dialog Semiconductors SoCs. Of these, very few use the specific affected SoC models.

The only affected devices we stock are the ABKey01, TON9128, TON9118, TON9108 that use the Dialog DA14580 SoC. You should avoid using these in critical scenarios because they can be caused to crash or deadlock. No beacons are vulnerable to the security bypass vulnerability.

As with all security issues, you have to put the possible attacks into perspective. The vulnerabilities are difficult to exploit in practice and it’s usually much easier to steal a beacon or remove its battery to make it inoperable.

The vulnerabilities are of more concern for critical medical devices such as pacemakers and blood glucose monitors.