 Hello, my name is Joe T. Arena, Applications Engineer for ST Microelectronics. A common question I get from engineers looking to start developing a Bluetooth Low Energy Application with the STM32WB is, what is the expected range of BLE? Generally speaking, it ranges from one to 100 meters. However, in reality, there are many factors affecting range that need to be considered, like transmitter output power, receive sensitivity, antenna gain, and path loss or environment. To get an idea how each of these factors impact range, you can play around with the range estimator calculator from the Bluetooth SIG website. But for practical purposes, it is important to take the range measurement in the same environment that the device being developed is expected to be used in to make sure it'll meet your range requirements. This video gives an overview of a method to measure the range performance of the STM32WB BLE radio using two NUCLEO WV55RG boards in DTM mode in a custom Android app, which displays RSI and packet error rate in real time. Note that this method does not use a BLE connection, but rather uses the direct test mode or DTM protocol to transmit receive test packets and measure the packet error rate in RSI on the receiver. The custom utility being used is composed of a custom smartphone app called BLE PER test bench, which is used as the main user interface and a custom firmware application that runs on the STM32WB SOC. Both these projects are available on the STM32 hotspot GitHub and a detailed description and instructions for how to install and run the utility can be found under the firmware project repo. After installing the BLE test bench app and the firmware image, the boards need to be pre-configured as a transmitter and a receiver correspondingly per the instructions in the GitHub repo just mentioned. First, I'll launch the app. You should see two devices appear in the scan window named DTMST. This is the device name when they have not yet been configured. Since both boards have the same name, you can use the RSI indicator to help identify the board you want to configure first. Placing the phone in close proximity to the WV board will cause the RSI to a respective device to go higher. Once identified, you can tap the connect button. Once connected, I'll configure the first board as a transmitter using the parameters provided, like TX Power, which I'll set to the max plus 60 B.M. BLE Channel, which I'll set to channel 37. Now leave the test packet length, payload and other parameters set to the default settings. Then tap configure and tap the back arrow button to return to the scan window once again. Notice that the device just configured is now named DTMTX. Now I'll configure the other device as the receiver by tapping the connect button, move the switch to the received position and configure leaving the default settings to match the ones already set on the transmitter unit. Tap configure, then tap the back arrow button to return to the scan window. Now to devices named DTMTX and DTMRX will show in the scan window. So I can now start the test by pressing the switch one button on the TX board to start transmitting the test packets. Now I also need to press switch one on the receiver board to start the DTM receiver mode. Notice in the scan window, a graph button will appear in the place of the connect button on the DTMRX device. As the device is no longer connectable, but rather it is periodically advertising the test results. If I tap the graph button, the graph display appears. This is where I can see the PER in RSSI measurement results coming from the receiver device. For user convenience, there's also a field to enter distance in meters and a save data button to log the enter distance. With the boards configured, I can start taking measurements which I'll be doing outdoors today. I'll place the transmitter somewhere fixed like over this post. With the live measurement now running while the boards are in close proximity to each other, the packet error should be close to zero and RSSI level should be fairly high around minus 40 dBm in this case. I'll log this and other data points coming up at the distances of interest for my records. Then I'll walk away with the receiver board while keeping an eye on the PER and RSSI results from the app. At seven meter distance, the RSSI decreased but the PER still maintained close to zero percent. At 15 meters, the RSSI is around minus 76 dBm and packet error rate is around 0.13 percent. At 30 meters, the RSSI is around minus 78 and PER is around 0.4 percent. At 45 meters, the RSSI is around minus 83 dBm and PER is around 0.47 percent. At 60 meters, the RSSI is around minus 85 and PER is around 0.6 percent. And at 85 meters, the RSSI goes down to minus 91 dBm and we start experiencing some packet errors. As I mentioned at the beginning, the SDM32WB is operating in DTM mode so there's no BLE link layer present, hence no sort of error correction or processing gain features supported. The result obtained is the raw performance of the BLE radio at the physical layer plus the RF front-end hardware implementation. In a normal BLE connection, it is possible to maintain a connection even with high packet errors due to the error correction and built-in tolerances of the BLE protocol with the trade-off of reduced data throughput and increased latency. Since I had been logging my data points, I can go into the phone's file system now under the internal storage documents folder and find the CSV log file with the summary of the recorded measurements which should look something like this. Remember that the PER test bench utility can be easily tailored to run on any custom PCB board to measure the performance of your RF front-end implementation as a firmware source code is made available from the GitHub repo mentioned earlier. I hope you found this overview useful and for more information, please visit st.com forward slash SDM32WB. Thanks for watching.