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.

Programmable Beacons

Many people come to us asking for “programmable beacons” when in fact they want beacons with configurable iBeacon UUID, major and minor. All beacons allow the UUID, major and minor to be changed, usually via an iOS and/or Android app and sometimes via USB/UART for changing the values, over time, via a program.

Truly programmable beacons are those where the internal software can be updated. The beacon contains a system on a chip that’s small computer running code to implement the beacon functionality. In most cases, the software can be updated via pins on the PCB:

Programming pins in the centre

Programming requires use of a programmer:

Segger J-Link Programmer

It can be fiddly to program larger numbers so you use a custom-made jig:

BeaconZone Programming jig

It’s not possible to see and update the existing code in a beacon. Any newly uploaded program has to be created from scratch. This is called emdedded programming, is non-trivial and takes of the order of months. Our SensorMesh™ was created this way.

Read about custom beacons

Lastest Issue of Wireless Q 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.

This issue mentions three ‘smart’ products, a smart cricket ball, a smart luggage tag and a smart bike helmet that are effectively beacons or sensor beacons in different form factors.

The IoT will overtake smartphone centric products as Bluetooth LE tech’s main market by 2024

The World’s first dual Arm Cortex-M33 SoC, the new nRF5340 SoC, is also mentioned. This will allow for more CPU intensive applications such as TCP/IP networking and edge processing of data.

There’s also a feature on asset tracking and locating systems valued at $19 billion last year and expected to reach $128.75 billion by 2027, with a Annual Growth Rate (CAGR) of 24.5%.

The Sogo/MokoSmart VILOG car tracking system is featured and is pertinent as we are a distributor for MokoSmart beacons.

TINY Bluetooth® Low Energy SoC and Module

Inside every Bluetooth sensor beacon is a System on a Chip (SoC) that’s a small computer that runs code. Dialog Semiconductor, the manufacturer of the SoC in some beacons, has just announced the world’s smallest (2.0mm x 1.7mm) and most power-efficient Bluetooth 5.1 SoC the DA14531.

The high level of integration means it only needs six additional electronic components and a power supply to make a complete Bluetooth low energy system. It’s expected to bring SoCs down to $0.50 in high volume.

While beacons tend to be limited by battery size rather than SoC size, the reduced price might bring downward pressure on cost. The small size is of more use in power harvesting/wearable scenarios such as printed Bluetooth sensors, connected injectors, glucose monitors and smart patches.

Latest Nordic Wireless Quarter Magazine Available

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

News from the world of beacons and Bluetooth LE includes:

  • National Instruments (NI) vibration sensor enables condition monitoring of industrial plant and machinery.
  • IDC research that says commercial and consumer adoption of IoT will drive worldwide annual spending to $1.1 trillion by 2023
  • Brain cells controlled using Bluetooth LE
  • Researchers build millimeter scale Bluetooth LE antenna
  • Quuppa’s direction finding technology used for ice hockey

New Wafer Thin Nordic nRF51 SoC

Nordic, the manufacturer of the System on a Chip (SoC) found in most beacons has announced that an ultra thin version will be available from American Semiconductor.

The AS_NRF51 Flex-BLE (pdf) is an ultra-thin version of Nordic’s nRF51822 SoC wafer-level CSP (WL-CSP), employing American Semiconductor’s ‘FleX™ Semiconductor-on-Polymer™’ (FleX SoP) process to reduce package size to approximately 35µm—roughly half the thickness of a human hair.

The largest component of beacons and Bluetooth sensors is usually the battery rather than the SoC. However, the Flex-BLE version will be especially suited to energy harvested and solar solutions where it will be possible to create very thin beacons that can be invisibly manufactured into products or their packaging.

Latest Nordic Wireless Q Magazine Available

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

Read about:

  • The Ruuvi IoT asset tracker
  • Smart rope load sensors
  • Use of SoCs in an insulin monitor device
  • A wearable respiration monitor
  • Bluetooth 5.1 direction finding
  • Tracking shipping containers
  • IoT for farmers
  • Use of SoC for athlete performance wearable
  • Building next generation Bluetooth beacons

What’s the Affect of Changing the Power on the iB003N-PA?

The iB003N-PA has a range up to 300m because it uses the RFAXIS X2401C 2.4GHz amplifier to increase the range.


When you use the manufacturer app to change the power output by a beacon, you are changing the power output by the Nordic nRF51 System on a Chip (SoC) that is usually fed to the antenna. In the case of the iB003N-PA, the RFAXIS X2401C instead receives the signal, amplifies it and sends it to the antenna. The resultant change in output is:

SoC Setting X2401C Output
0dbm 20dBm
4dbm 20dBm
-5dbm 15dBm
-10dbm 10dBm

20dBm is the maximum allowable output for class 1 Bluetooth. There’s no difference whether you set to 0dBm or 4dBm, the output will be 20dBm. Even at a low power setting, -10dbm, the amplified output is 10dBm which is relatively high compared to the nominal 0dBm for most beacons. That’s just over 3x the power (3dBm change is a doubling of power) of a normal beacon. You can see that this beacon is primarily designed for long distance and there’s no need to change the SoC power from the default 0dBm = 20dBm.

View our ultra long range beacons

Inside a Beacon – Part 3 – Programming the SoC

Part 1 Part2

This is part 3 of a 3 part series that explains what’s inside a beacon. In this part we take a look at the System on a Chip (SoC) software and programming for the Nordic nRF range found in the majority of beacons.

Despite the small size and memory, a typical beacon contains lots of code written in the c programming language. The code required to implement Bluetooth, called the Bluetooth stack, is very complex. It also has to pass tests by the Bluetooth SIG, called qualification. To prevent every product vendor using the SoC having to write the Bluetooth part themselves, Nordic supply what’s called a SoftDevice. A SoftDevice is a precompiled and linked binary library implementing a wireless protocol, Bluetooth in our case.

For the nRF52, the S132 SoftDevice provides a qualified Bluetooth® 5 low energy (BLE) Central and Peripheral protocol stack solution. It provides eight connections with an Observer and a Broadcaster role all running concurrently. Use of a softdevice allows developers to concentrate on their own high level product functionality rather than lower level complexities.

Beacon manufacturers or 3rd party developers such as ourselves create a program using either SEGGER Embedded Studio (SES), MDK-ARM Keil µVision, GNU/GCC or IAR Workbench. Most development now uses SEGGER Embedded Studio because Nordic have licensed it to allow Nordic developers to use free of charge. Most Nordic code examples in the nRF52 SDK now include a SEGGER Embedded Studio project file.

There are two ways of programming, either pre-programming the SoC with production code before mounting using socket programming or programming the SoC after mounting in the circuit. The PCB holes mentioned in part 1 are used to program the beacon in the circuit. A jig with pogo pins (pins with springs) can be used to help programming larger number of devices:

Jig in use at BeaconZone

The other end plugs into a nRF52 DK that has a debug out header at the top right:

If you keep the pins connected to your beacon, you can run and debug the code, in situ, via the SEGGER IDE. However, debugging is not that capable because it’s not possible to continue from breakpoints. You have to re-run or rely on lots of logging to the console.

The nRF52 DK also contains a nRF52 which means it can be used in the initial stages of product development prior to moving to actual hardware.