In Bluetooth 4, there was only one PHY. It encoded digital data using Guassian Frequency Shift Keying (GFSK) and transmitted it at a rate of 1 mega symbol per second (ms/s).
Bluetooth 5 continues to support the Bluetooth 4 PHY and calls it LE1M. But it also added a 2 ms/s PHY called LE2M, which doubles the transmission rate at the physical layer and a long range capability, achieved when using the LE Coded PHY which uses Forward Error Correction (FEC) to allow receivers to be more sensitive, extract data from signals at a lower Signal to Noise Ration (SNR) and therefore at a greater distance from the transmitter. Cool.
1. How flexible is this?
2. Can application developers choose the PHY to be used?
3. And in an environment like a smartphone, with multiple applications running, would one application setting the PHY change it for all other applications?
Luckily the answers to these questions are:
2. Yes if their platform provides APIs (because yes, the Bluetooth stack allows this)
3. No it would not.
To elaborate on (3):
You can set a default PHYs to be used in all subsequent connections or connectionless communication events for each of received packets (RX), transmitted packets (TX) or both.
However you can also use a different PHY for each and every packet if you really want to. That's pretty flexible!
When in a connection with another device, the Bluetooth stack lets you use the Host Controller Interface (HCI) Set PHY Command to set the PHY for your connection and you may specify a different PHY for TX and RX use on this connection.
Bluetooth 5 lets you define distinct "advertising sets" which are separate sets of advertising parameters for different applications. So in connectionless scenarios (i.e. advertising and scanning), you can specify the PHY as part of the definition of a particular advertising set. You use the HCI LE Set Extended Advertising Parameters Command to select the PHY to use when advertising and use LE Set Extended Scan Parameters Command to control scanning and the PHY or PHYs to use when handling received advertising packets.
Of course this doesn’t necessarily mean that operating systems like Android give you complete access to all of this. But we're in luck....it seems that Android O does in fact does give you pretty much everything. In summary, here's my interpretation of the revised Android O APIs which give access to Bluetooth 5 capabilities:
1. Android lets you determine which PHYs the local Bluetooth adapter supports.
2. A GATT server application can specify preferred PHYs for each of TX and RX (class: BluetoothGattServer)
3. A GATT client application can specify preferred PHYs for each of TX and RX (class: BluetoothGatt)
4. When scanning you can specify the PHY(s) to use, including “all supported PHYs” (class ScanSettings.Builder)
5. When advertising you can build advertising parameter sets, each with its own primary and secondary PHY (AdvertisingSetParameters.Builder)
Bluetooth 5 offers enormous, packet by packet flexibility and control over PHY selection and it looks like Android APIs put this power right into the hands of the developer.