 Thank you for joining me for the presentation on how to perform the RF functional tests on STM32WL. So why should we even talk about this topic? You may find yourself looking for the microcontroller for your application or you are already working on a solution with STM32WL. And then you are wondering if your PCB is working the way it is intended to. So usually you start with the hello world of embedded applications and that is the LED blinking. And after that, since STM32WL is not only a microcontroller, but it has a radio peripheral on the same die. So you want to know if the radio part is also working. To do that, we have a set of functional tests inside the CUBE WL package within the STM32 ecosystem. Our ecosystem provides the firmware package with set of examples for each peripheral tools to program and debug the microcontroller. And the part of the ecosystem is the set of functional tests for the radio. And following one of the software examples or firmware examples for the WL, the LoRa180 slave, acting as LoRa1 modem, it is possible to use subset of relevant AT commands for RF testing. Just to remind you quickly, what is the LoRa1 networks and where is the link we should test if we have a PCB with STM32WL. From top, we have the application server, which is responsible for your application. So for example, you are gathering some data, sensor data, so for example, temperature, and you want to plot it into a graph and see the results over several months. But to get the data from your end device, you need something in between, and that is the network server which provides the infrastructure and communication with the end device. And the network server communicates with the gateway, which is basically a very simple device, only transforms LoRa packets into TCP-IP packets, and basically this whole area communicates over the internet over TCP-IP. And this is the link where we want to test our device, because we need to reliably communicate with the device over even a couple of kilometers, even though speaking about absolute range with radio devices, it is better to use the link budget. So what is the link budget? Link budget is a simple equation where we mostly control only one variable and the other variables can be considered constant. So if we look deeply into the equation, it's power output, which is regulated, for example, in Europe by the EU or in the respective country of operation, they have their own regulations. So for example, in Europe, it's 14 dBm maximum output, so we cannot move with this. Then there is the gain of the antenna. That is a design choice. And again, we can only go with the technology so far and have on a certain PCB a static gain, so we cannot move with this variable either. The last one is the sensitivity, and that is the only variable that can be moved in this equation. So to increase the link budget, we need to increase the sensitivity. Now, what is the sensitivity? Again, it's another equation. In the end, it's only with one variable. We have the signal to noise ratio and noise figure. So for a particular operation between two nodes without changing the position, without changing the environment, we have basically a static signal to noise ratio and noise figure. Then there is the noise power density at 25 degrees Celsius. And the last parameter is the logarithmic function of data rate. And data rate is the only variable in this equation. So to sum this up, we can only change the data rate. So to increase the sensitivity, we need to decrease the data rate. And decreasing the data rate, that means increasing the link budget. If we go back to the STM32 ecosystem, the most important part is the STM32 QWL. It's the package that provides drivers and middlewares with a set of examples to ease the development of your software or firmware on the STM32. From the Loravan perspective, there are three most important examples. That is the ping-pong, which is not strictly speaking Loravan. Then there is the end-node and AT-slave applications, which are backed by the Loravan middleware in our libraries. Then there is the sub-gigahertz middleware. And for the stack and the whole application to run, we have the utilities like the timer server, sequencer, low power manager, etc. And on the bottom, we have the hardware abstraction layer. That's the lowest part that communicates directly with the hardware. And in between, there could be also the board support package, which is responsible for helping you with our hardware evolution tools. For example, for the STM32 WL Nucleo. Because we will practice a little bit the functional tests, what will we need to make one? First of all, there is the STM32 WL Nucleo, which its main feature is, of course, the STM32 WL chip. And since it includes also a radio-fi, we need an antenna. So there is an SMA connector to connect an antenna. Then there is the ST-Link, which is a debugger to load firmware into the WL. And also, it acts as a virtual comport. So you can simply hook the UART from the WL through the ST-Link and connect by USB to your PC, and the UART will act as a virtual comport in your PC. Then with the AT-Slave loaded, you can either use the comport terminal, so for example, termite, terra-term, whatever you are using, or you are used to. And you will see a simple command interface. You send and AT commands the AT-Slave response. Or you can use the STM32 CUBE monitor, which is a graphical interface, basically a graphical wrapper around the AT-Slave. And there is a dedicated flow for the AT-Slave. STM32 CUBE monitor is basically a generic tool that can visualize and monitor data. It has a graphical flow-based editor, so it's not programming strictly speaking, but connecting some blocks. It's based on the famous Node-RED application. It's basically a server then. And it runs on a multi-platform, so it can run on Windows, Linux, or even Mac. Now to get to the AT-Slave, first of all, you want to find the application. So we need the STM32 CUBE WL package that can be downloaded from st.com, or if you have the STM32 CUBE IDE or CUBE MX, it will be located in the repository that is in the user folder. Within this package, then we had two projects where you find all the examples for each evaluation hardware board. So in the case of WL, so far only the Nucleo WL. Then you had two applications. You have also examples and other features. Examples are very simple. And applications contains usually some middleware. So in our case, it's the LoRa1. And for use case of the LoRa1 stack, we have the LoRa1 AT-Slave located there. So first of all, we need to open the project in one of the famous IDEs. We can use IR, we can use Kyle, or we can use STM32 CUBE IDE, which is IDE developed by ST. It's free of charge. So you can just download it, open the project, compile the project, and load it into the microcontroller. You will also find STM32 CUBE monitor folder here. And that is important for the functional test because it contains the JSON file, which can be imported into the CUBE monitor. Now back to the AT-Slave, there are a couple of commands for the functional test and RF tests in general. First of all, we can send simple AT command that will respond with OK. And then the question mark will list all the commands. We chose some of the commands here to describe them more. First of all, we need to AT plus T to configure the radio the way we want it, meaning we want to transmit on a certain frequency, we want a certain spreading factor, power, etc. And then we can perform AT plus T tone or RSSI tests. So basically T tone is a simple unmodulated wave transmitted on the board, and its counterpart is the RSSI tone test, meaning it listens to the wave and measures RSSI. These two commands are also important for the certification because also during the development you want to know how your RF matching performs on the PCB. So this is the test that is usually used in the RF Lab. I would also mention in this case our RF Lab in Prague because not only you need to battle it yourself, we can also help you, and we have nice RF Lab in Prague, but for that it is really important to leave at least one UART, meaning both RX and TX on your PCB at least as a test point so that the AT slave can be loaded during the development and you or my colleagues from the RF Lab can perform the tests. Then we have AT plus TTX and TRX which is only a functional test. So one of the boards is transmitting, the other one is receiving, and the packet error rate is calculated. For the lower one standpoint we have the AT plus certificate, so basically it activates the state machine inside the stack to trigger certification mode and lower one certification can be done and eventually based on this test you receive your Laura Alliance certification. And then any test can be stopped by any time by the AT plus T of simply disables everything. There are some important links to download the cube monitor, etc. I thank you for joining me on this presentation and I hope to see you somewhere someday in real life.