Note: This KBA has been marked as deprecated. A more updated KBA can be found here:
Bluetooth 5.0 introduces a new long range PHY (LE Coded PHY) with 125kbps and 500kbps coding which gives range gains of 1.5-2x with improved sensitivity of 4 to 6dB.
The LE Coded PHY uses 1Mbit PHY but payload is coded at 125kbps or 500kbps. It also adds Forward Error Correction and Pattern Mapper.
Note: LE Coded PHY is only supported on EFR32xG13 devices.
Changing to LE Coded PHY can be requested from either slave or master device using the command gecko_cmd_le_connection_set_phy(connection, phy), where the phy value maps as follows:
For compatibility reasons the default PHY is always 1Mbit. This must the PHY used for advertising as well as establishing the connection. Once the connection is formed either side (master or slave) can request a new PHY to be taken into use. The PHY requests can be issued at any point during the connection and the stack takes care of negotiating the new PHY usage and notifying the application of whether the new PHY has been taken into use or not.
When a new PHY is requested it will take a minimum of 6 connection intervals for the device to switch to the new PHY. Once the PHY switch occurs the event le_connection_phy_status is raised by the stack to notify the application of the new PHY setting.
Note: From SDK 2.8.1 onward it's possible to scan and advertise on LE Code PHY and therefore the connections can also be established using over that PHY. Please refer to this KBA for further information and a code example: Advertising and Scanning with LE Coded PHY
In the case of using 2 EFR32xG1x devices the event le_connection_phy_status will be raised on both devices in the following situations (if the new PHY request is accepted by the receiving device):
The event le_connection_phy_status will only be raised on the requesting device when:
An additional note is that the default coding for LE Coded PHY is S=8 (125kbit). This means that when an EFR32BG13 accepts a PHY change request to LE Coded PHY it will default to S=8. It is up for the application to change the coding if desired and the new coding will then be used if the PHY is again changed to 1Mbit/2Mbit and then back to LE Coded PHY.
Here are a few examples of changing between the PHYs using 2 EFR32xG13 devices in NCP mode and controlled with BGTool.
In this example the devices are connected using a 512ms connection interval. After the PHY change command is issued it takes ~5s to get the event which is raised on both devices.
As explained earlier in this article changing the coding is not negotiated over-the-air between the devices and for that reason the event le_connection_phy_status is only raised on the requesting side and very shortly after the command is sent. The receiving device will continue using the same coding.
In the example below a new PHY request is attempted but the other device is an EFR32BG1 which only supports 1Mbit PHY so the event le_connection_phy_status is immediately raised on the requesting device to notify that the PHY has not been changed and no event is raised on the receiving device.
Using LE Coded PHY will lead to higher current consumption due to the longer RX/TX periods. The next images show the current profile of a notification packet with 20 bytes of data payload on all the PHYs. The red blocks are highlighting the duration of the entire wake-up period and the average current consumption for said period.
These measurements were made from the slave device (RX precedes TX) with TX Power of 0dBm and the images are sorted from shortest to longest RX/TX periods: 2Mbit, 1Mbit, LE Coded S=2 (500kpbs) and LE Coded S=8 (125kpbs)
Note: When using LE Coded PHY the packet header is always coded with S=8 but the payload can be S=2 or S=8 coded and that is indicated by a bit in the header. This means that empty packets will not have a significant difference between S=8 and S=2 coding in terms of TX duration.
The image below shows the result of range test in one of our offices. On the top right corner we placed an EFR32BG13 and then we walked around with a second EFR32BG13 kit to check the connection boundary.
Comparing between 1Mbit PHY and LE Coded PHY (125kbps) the range is roughly double due to the sensitivity improvements.
Hi, I'm trying to do the Range test using maximum possible link budget Silabs can offer on BLE5 & Coded PHY, hence I choose BRD4306B. Following this thread, is there any way to use sample Range test project on a pair of BRD4306B? or has it to be using BGTool for this board?
If BGTool is the only one to be used, where can I set maximum TX power?
@Agung Mandala, did you manage to get Bluetooth 5 example working with your BRD4306B ?
We are new to Silicon Labs ecosystem and are also trying to evaluate Bluetooth 5 performance but I can't find Bluetooth 5 examples for this Boards.. I don't know how to start.
Under Simplicity IDE, I've only found Classic GATT example (Temperature Sensor for example).
Is there a Range ou Throughput example please ?
Currentli i am working on BGM13P32 chip, SDK 2.11.0.
I want to increase the BLE range to maximum for that i increase the TX power upto 19dbm but still i am not getting enough range,instead getting same range as in 8dbm.I found that i have use PHY to increase range so i follow this link :https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2018/03/13/advertising_and_scan-Rp26 .
I have tested the example code that was shared on the link but during the testing i found that my smartphone was not able discover the BLE. I have tested with both BLE 4.2 and BLE 5.0 mobile device still no success.
Kindly help me out if i am doing anything wrong.
Currently the LE Coded Phy is only supported in a select few BLE 5 smartphones (Samsung S10, OnePlus 6, Mate 20 pro, Poco F1, Xiaomi Mi 8, TNY-AL00, I don't know if any iPhones currently support it.
For Android phones you can download the Nordic App nRF Connect and navigate to the Device Information page.