Bluetooth 4 vs Bluetooth 5 Range

Mohammad Afaneh has unearthed (LinkedIn) a paper by researchers at Centre for Wireless Communications, University of Oulu Finland and Centre for Wireless Communications, University of Oulu, Finland on Experimental Performance Evaluation of BLE 4 vs BLE 5 in Indoors and Outdoors Scenarios.

Bluetooth 5 promises x4 improvement in range over Bluetooth 4. The researchers set up indoor and outdoor experiments to determine the real-life performance. Tests used the Nordic Semiconductor nRF52840 SoC.

The results showed a x2 improvement in line-of-sight range outdoors and up to 20% improvement in non line-of-sight indoors. For example, for Bluetooth 4, with 0 dBm transmit power, the maximum range was 220m. For Bluetooth 5, with 0 dBm transmit power, the communications range was found to be 490m. A x4 range improvement was not achieved in most scenarios and the only situation where this was achieved was when using Bluetooth 5 coded mode with increased (9dBm) transmit power.

It’s still the case that very few beacons support the Bluetooth 5 features. This is mainly because there are very few smartphones with which they can be used. Another observation is that the +9dBm used in the above tests isn’t practical for most battery-based solutions and instead it’s more normal to run at 0dBm or less power. The range also depends on the sending and receiving hardware and antennas. In the extreme case, we have seen a non-battery powered Bluetooth 4 device achieve 4Km line-of-sight range.

The paper also tests the throughput which we haven’t mentioned in this post. Throughput implies GATT connection which isn’t relevant in the context of using beacons.

The PDF paper is also available at jultika.oulu.fi

Managing Bluetooth LE Advertising Congestion

Bluetooth LE advertising congestion happens when there are too many Bluetooth devices in an area. As we will show, this rarely happens but with new Bluetooth technologies this situation is becoming more likely. We provide some ways to mitigate congestion.

Bluetooth LE advertising transmits periodically the period of which is configurable from typically 100ms to about 10 seconds.

Bluetooth LE advertising (from Bluetooth SIG)

If two Bluetooth devices happen to transmit at the same time, it’s like two people shouting at the same time. The signal is corrupted, the receiver can’t make sense of the signal and it is lost. This usually doesn’t matter because it’s likely the signal is seen the next time it is sent. The random advDelay in the above diagram ensures that the two sends don’t clash again. It’s very unlikely advertisers clash in the first instance because the transmit duration is very small compared to the advertising period. The above diagram isn’t to scale. Here’s an oscilloscope trace showing some real timing:

The advertising duration is very small, of the order of 1 to 2 ms (milliseconds). Advertising is also sent three times, on three different radio frequencies, so that if one is blocked, the radio signal might be heard on one of the others. All this means that advertising collisions rarely occur.

However, there are some newer Bluetooth protocols that as they are starting to roll out, are making collisisons more likely:

  • Bluetooth 5 advertising extensions – This allows advertising of more data, that takes longer than the typical 1 to 2 ms and hence increases congestion.
  • Bluetooth longer range – This transmits further thus effectively increasing the number of beacons advertising in a given area.
  • Bluetooth Mesh – This works by having relay beacons listen and re-transmit advertising, usually several times, to improve reliability.
  • Bluetooth direction finding – This also has longer advertising to send a constant tone extension (CTE) that is received by AoA hardware. However, of more affect is advertising more frequently. While beacons on assets used to advertise typically every second or longer, direction finding tends to use faster advertising to improve latency.

You can check how many devices are advertising by using a scanning app on Android. We recommend Nordic Semiconductor’s nRF Connect because it can decode the latest Bluetooth protocols. Use Android for full visibility because Apple made the poor design decision to obfuscate iBeacon advertising to coerce developers to only use the Apple iBeacon-specific APIs. Apple also hides devices’ MAC addresses making them more difficult to physically identify.

If you have a problem with congestion you might be tempted to increase the transmission power or advertise more often to increase the chances of being seen. However, this is counter-productive because you will be increasing congestion, especially if your devices are the main contributor to the congestion.

Instead:

  • Lower the transmit power so that beacons cover a smaller area. You can fine tune this using nRF Connect to measure the distance you need rather than needlessly advertising further. This will also conserve battery life.
  • Increase the advertising period to make collisions less likely.
  • Increase the receiver scanning period to make detections more likely.
  • Seek out and remove unwanted devices advertising too frequently, such as fitness devices, smartphones, displays and even cars.

Need more help? Consider our consultancy services.

Bluetooth LE in Smart Cities

Researchers from Spain have a recent paper on Experimental Application of Bluetooth Low Energy Connectionless in Smart Cities that considers the increased range and improved robustness provided by Bluetooth 5.x.

The paper describes the various types of communication:

The paper includes a description of Bluetooth LE including advertising and the different physical layer modes.

There’s an experimental evaluation of the new, more-robust, long-range radio mode when used in smart cities scenarios. The I2V scenario is evaluated, where reception is measured against variation in distance and vehicle speed. The I2P scenario is evaluated against interference from WiFi and classic (non LE) Bluetooth.

The researchers found an overall packet loss of 20–30%, regardless of mobility speed, compared to the static scenarios. The classic Bluetooth 4 mode was found to be more immune to coexistence with the WiFi protocol than any BLE 5.x mode. The researchers say this is because Bluetooth 5 extended advertisements 1) make use of more than one channel and 2) have longer data are both can cause more susceptibility to interference. Nevertheless, the updates introduced with Bluetooth 5 allow broadcasting over much longer distances.

The paper concludes the maturity and low cost of the technology could enable fast, easy deployment in smart cities compared to other solutions.

Bluetooth (BLE) vs Ultra-Wideband (UWB) for Locating

We previously mentioned how cost, battery life and second sourcing are the main advantages of Bluetooth over Ultra-Wideband (UWB). An additional, rarely mentioned, advantage is scalability.

Servers that process Bluetooth or Ultra-Wideband support a particular maximum throughout. The rate at which updates reach systems depends on the number of assets, how often they report and the area covered (number of gateways/locators). Each update needs to be processed and compared with very recent updates from other gateways/locators to determine an asset’s position.

For Bluetooth, updates tend to be of the order of 2 to 10 seconds but in some scenarios can be 30 seconds or more for stock checking where assets rarely move. Motion triggered beacons can be used to provide variable update periods depending on an asset’s movement patterns. This allows Bluetooth to support high 10s of thousands of assets without overloading the server.

For Ultra-Wideband, refresh rates tend to be of the order of hundreds of milliseconds (ms) thus stressing the system with more updates/sec. This is why most Ultra-Wideband systems support of the order of single digit thousands of assets and/or smaller areas. More frequent advertising is also the reason why the tags use a lot of battery power.

How does all this change with the new Bluetooth 5.1 direction finding standard? The standard was published in January 2019 but solutions have been slow to come to the market. The products that have so far appeared all have shortcomings that mean we can’t yet recommend them to our customers. Aside from this, in evaluating these products we are seeing compromises compared to traditional Bluetooth locating using received signal strength (RSSI).

Bluetooth 5.1 direction finding needs more complex hardware that, at least in current implementations, are reporting much more often. The server has to do complex processing to convert phase differences to angles and angles to positions thus supporting fewer updates/sec. Bluetooth direction finding is looking more like UWB in that cost, scalability and battery life are sacrificed for increased accuracy. Direction finding locators are currently x6 to x10 more costly than existing Bluetooth/WiFi gateways. Beacon battery life is reduced due to the more frequent and longer advertising. We are seeing Bluetooth 5.1 direction finding being somewhere between traditional Bluetooth RSSI-based locating and Ultra-Wideband in terms of flexibility vs accuracy.

Despite these intrinsic compromises, Bluetooth direction finding is set to provide strong competition to UWB for high accuracy applications. We are already seeing UWB providers seeking to diversify into Bluetooth to provide lower cost, longer battery life and greater scalability.

Bluetooth 5 Support

We are starting to see the first beacons and gateways that truly support Bluetooth 5 even though the standard was released in 2016. Up to recently, some have claimed to support Bluetooth 5 in that the internal hardware and software (SDK) was Bluetooth 5 capable but most, if not all, of the Bluetooth 5 features weren’t available.

Compatibility is dependent on smartphones supporting Bluetooth 5 that has also only come to fruition with recent phone models. Most Android smartphones manufactured in the last few years use Android 10 or Android 11 that has Bluetooth 5 software support. However, the Bluetooth chip inside the smartphone also needs to support Bluetooth 5. On iOS, all including and after iPhone 8/8 Plus/iPhone X support Bluetooth 5.

Furthermore, there’s also the complication that Smartphones claim to be Bluetooth 5 capable but might not support many of the optional features. One way to test which features are supported is to use the Nordic Semiconductor nRF Connect app. Here’s an example from the ‘Device Information’ section of the app running on a Pixel 3a XL:

Download the Bluetooth Core Specification Version 5.0 Feature Overview for explanation of these features.

New iGS03E Bluetooth Ethernet Gateway in Stock

We now have the INGICS iGS03E Bluetooth to Ethernet gateway in stock. This differs to the iGS02E in that it includes Power over Ethernet (PoE) without having to have an external PoE splitter.

Gateways look for Bluetooth LE devices and sends their advertising on to a server via TCP, HTTP(S) or MQTT including AWS IoT. If you use with sensor beacons, this provides a quick and easy way to provide for IoT sensing.

The iGS03E is one of the first gateways to also support Bluetooth 5 in Long Range mode (LE Coded PHY), although very few advertising devices support this yet.

Compatible with BeaconServer™ and BeaconRTLS™.

New Rugged Bluetooth 5 iBeacon

We have a new rugged, UV-resistant, waterproof (IP68) sensor beacon, the AC-BLE-T110G in stock.

This is the first beacon we know of that supports Bluetooth 5 Long Range Coded PHY. While many beacons mention Bluetooth 5 in their specification and a Bluetooth 5 SDK has been used in their development, they only transmit Bluetooth 4.2 advertising. This beacon is the first to support Bluetooth 5 Long Range Coded PHY to achieve a range up to 200m with compatible gateways and smartphones.

Advertising modes

This beacon can also be set to detect motion with a user defined threshold (mg) and duration (ms) which sends an alternative iBeacon id, a configurable number of times, instead of normal advertising.

View Sensor Beacons

Advanced Bluetooth on Android

Martin Woolley of the Bluetooth SIG was a recent speaker at Droidcon EMEA where he spoke about Advanced Bluetooth for Android Developers (slides).

Android Bluetooth LE Stack

Martin covered scanning, GATT, how to maximise data rates, speed vs reliability and using different PHY for enhanced range or data rates. The second part of the talk covers Bluetooth Mesh and proxy nodes.

One thing not mentioned in the slides, to be careful of, is that connection via a proxy node is relatively slow because it’s limited by the GATT connection. Proxy nodes are good for controlling (sending small amounts of data into) a Bluetooth Mesh but poor if you want to use the connected Android device as a gateway for all outgoing data.

Martin also has a blog where you can also learn about his past talks and he will be part of the new Bluetooth Developer Meetup.

Read about Beacons and the Bluetooth Mesh

Bluetooth Developer Meetup

There’s a new (virtual) Bluetooth Developer Meetup group.

Developers will share their knowledge and tell their stories of working with everybody’s favourite low power wireless communication technology

The first event will be on 15th October 2020 at 17:30 UK time (UTC+1) and will include the following speakers:

  • Jacky Cheung, Google
  • Kevin Picchi, Samsung
  • Thea Aldrich, Foundries IO
  • Martin Woolley, Bluetooth SIG