By Mahendra Tailor, Laird
This blog post summarizes some of the new features and benefits that are introduced in the Bluetooth 5 specification.
Bluetooth has been around for about 20 years, of which the first few iterations served as draft versions until the first release of v1.0. Since then the release of versions 1.2, 2.0, 2.1, 3.0, 4.0, 4.1, 4.2, and finally 5 most recently in December 2016, each brought significant enhancements and benefits. Most significantly, version 4.0 introduced Bluetooth Low Energy (BLE) or Bluetooth Smart (it’s worth noting that with the Bluetooth 5 announcement, the Bluetooth SIG has changed their brand guidelines to remove the use of Bluetooth Smart). Originally, BLE was targeted for low power, low bandwidth state information, lacking any audio capability given its prime use case being the wireless transfer of small amounts of data with as little energy expended as possible. These new radios provided a raw data rate of 1M symbols per second, but with the overheads in protocols such as L2CAP and GATT, the effective data rate was a maximum of 250kbps. Along the way, the “Internet of Things” (IoT) also came to prominence, as device OEMs looked to leverage increased short range wireless connectivity for a myriad of battery powered devices, all built around the smartphone / tablet as a remote display or data conduit device to the Cloud.
A couple of points worth noting early on in this piece:
- All the major enhancements in Bluetooth 5 are for the BLE radio and there is nothing new associated with the Bluetooth Classic radio.
- The Bluetooth 5 core specification is now available but there is still a sizable time lag before silicon, stack, and ultimately module vendors like ourselves have all the required hardware, software, and test tools in place to take advantage of the new Bluetooth 5 features.
- The same needs to be noted for the “other end” of your Bluetooth 5 connection – if you are utilizing a smartphone or tablet, there can be anywhere from 6 – 18 months before there is mass market availability of devices that support, and are qualified, to the latest Bluetooth releases.
Bluetooth 5 looks to address these evolving expectations coming from IoT applications in terms of increased range and speed through multiple enhancements to the BLE radio PHY, as well as an increase of maximum transmit power from +10 to +20dBm. In a sense, one new radio PHY gives vastly more range but at the expense of lower data transfer speed, and the other new PHY gives a 2x speed enhancement which provides for more efficient transfer of bulk data as the radio utilization is roughly half the duration of the current PHY. The high speed PHY also lays down the foundation for the potential introduction of audio over BLE (similar to current Bluetooth Classic, defined here as any Bluetooth specification before BTv4.0, audio capability) which will potentially be introduced in a future revision, although Bluetooth 5 already makes provisions for the possibility of broadcasting audio (or synchronous data) over advert channels.
2x Raw Data Rate
Bluetooth 5 introduces a new radio PHY called ‘LE 2M’ which doubles the normal raw BLE data rate to 2M symbols per second meaning that the same data sent over the wireless link will now take half the time in Bluetooth 5, versus any predecessor. This means that the radio will operate for less time in sending that data, providing a further major benefit of reduced power consumption that results in increased battery life. This appeals to the current IoT trend for wirelessly connected devices that are powered by small coin cell batteries. Look out for this feature in both Laird’s BL652 and SaBLE-x modules in the near future.
LE Long Range
Bluetooth 5 also introduces a second new, optional radio PHY called ‘LE Coded’ which is still 1M symbols per second, but uses a combination of lower packet coding of 125kbps or 500kbps (think, bit redundancy using both FEC and spreading factor of 2 or 8), and the increase in maximum TX power to +20dBm, to give a potential 4x increase in range. It can be used for both advertising and data packets.
The benefit of this feature is that in buildings the wireless signals will have better penetration, so product designers will, for example, be able to create better home automation products when coupled with the enhanced security that was introduced in version 4.2 of the specification.
In terms of power consumption, these packets are roughly 2 to 8 times longer duration, the longest being about 16 milliseconds, and so there will be a corresponding increase in power consumption for sending the same amount of data and hence a significant shorter battery life.
LE Advertising Extensions
BLE (BTv4.x onwards) works in the 2.4 GHz band and consists of 40 channels which are each 2 MHz wide. Of the 40 channels, 3 are dedicated for adverts and the rest of the 37 channels are allocated for data connections. On the advert channels an advertiser may not advertise packets at intervals less than 20 milliseconds and it is typical to see 100 milliseconds or more. On data channels, a device can send packets as fast as 7.5 milliseconds, achieving a higher throughput than what can be achieved when broadcast in advert packets. Please keep this in mind for now as it becomes relevant later.
When advertising, the same data is advertised in rapid succession over the three advert channels in what I call the ping/ping/ping fashion. The advert packet (also now called the primary advert packet) contains data that cannot be longer than 31 octets.
The enhancement in Bluetooth 5 now allows advert packets to be transmitted in the data channels (although the specification prefers to label them as “secondary advert channels”). Each packet, in those data channels, can be as long as 255 octets and can be sent with a minimum interval of 7.5 milliseconds, like in data connections.
To ensure that legacy BLE devices which are older than the Bluetooth 5 specification are not confused, a new primary advert has been defined. This primary advert has a header value such that older devices will just discard them when seen in any of the “traditional” primary advert channels. This new primary advert is used as a pointer to a chain of secondary advert packets in the data channels.
In simple terms, think of the payload of the new primary advert packet to contain, not the Advert Data (AD) elements which are defined for existing advert packets, but a new type of payload called the “common extended advertising payload” which contains a data channel number and a time offset from this primary advert packet. Basically a recipient of this advert will be able to know exactly when and where to listen for the linked advert which contains data and optionally pointer information to further linked / chained packets. This is illustrated in the diagram below where the number of chained packets is as many as required to convey the advert data which can be longer than 1500 bytes (keeping in mind that each individual packet cannot have more than 255 bytes of data).
The clever aspect of these chained advert packets in the data channels, is that the application need not worry about how the data is segmented. It is expected that the BLE software stack will offer an API that accepts a single long data buffer, and it is logical to assume that it will decide, to which data channels, and when the data gets sent. On the flip side, it is expected that the receiving device’s BLE stack will collate all the data and present it to the application when fully received.
A variation of this type of enhanced advertising involves the sending of synchronous data, like audio. The use case being, for example, audio broadcasts associated with exhibits in say a museum or even the commentary of a tour guide in a coach. In this case the new primary advert points to an auxiliary packet which in turn specifies a “connectionless” train of packets which hop at a known cadence. The cadence information and the access address code is provided by that auxiliary packet which enables the receiving device to “tune-in” on to the audio stream. This is illustrated in the diagram below, where the orange packets contain compressed audio information.
As you can see, the primary advert channels are repeated at regular interval. This ensures that new listeners will always be able to tune in to the audio (orange packets) by picking up the information in the auxiliary packet (red packets). This, in turn, is located using the primary channels (green) on the main advert channels. The good thing about this Bluetooth 5 feature enhancement is that there is no requirement for changes in the radio hardware. It basically only requires the chipset manufacturer to provide an updated stack to expose this functionality. Modules like the BL652 even have a digital microphone interface which makes for easier integration of audio into the new advertising scheme, when the Bluetooth SIG fully supports audio over BLE at a SIG qualified BLE Service level.
LE Advertising Extensions is a major enhancement which offers all sorts of use cases allowing Laird to engage with our customers to help them understand what can be achieved when using smartBASIC. The enhancements are fairly complex to understand, and a simplified implementation will accelerate its use when something like smartBASIC makes it easy and quick to “try and test”.
In conclusion, Bluetooth 5 offers considerable new features that Laird will be able to offer to customers in existing and future modules. Hopefully this blog equips you with the necessary simplified information to begin testing and deploying the latest standard in your products. Please feel free to reach out to me and discuss any aspects of this blog post: firstname.lastname@example.org
Want to receive the latest blog posts from Laird? Subscribe Below:
- New 60 Series SOM & Summit Software Stack Deliver Superior Enterprise-Class Wi-Fi Connectivity
- New BL651 Module Joins Laird’s Growing Nordic Family of BLE 5 Solutions
- What You Need to Know About Bluetooth SIG Deprecation of BT v4.1 and Older Specs
- Get a First Look at Laird’s BL654 Bluetooth 5 Module
- Webinar Recap: BLE Mesh – A Practical Guide to Simplify Product Development Time
July 2020 M T W T F S S « Nov 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31