 Hello and welcome in TTN conference. My name is Bartosz Boryna. I am a member of ST technical support. I am a member of microcontroller support. And one of my responsibility area, it is LPVAN solutions. I will go with you through the hands-on session, jak dodać data do Lorevan Network. To będzie zainteresowane na naszym nowym soluzjonu STM32WL systemu CIP. Co są długie nauczycielki w tej sesji? Zobaczymy, jak ST, razem z SEMTECH, implementuje Lorevan Protocol Stack. Teraz pokażę ci bardzo ważną solucją implementacji. To jest sekwencja, która pozwala umożliwiać w efektywistycznym sposób aplikacją low-power mode. W tej sesji opowiadamy klas A, Lorevan, i Note. Jak wiesz, to jest najwyższa sytuacja w tej klas A, Lorevan i Note. I z tym, z sekwencją i low-powerm approaches, pokażę ci, jak Lorevan ma aplikację. Widziesz, że to jest typiczna aplikacja drive-in. I potem, kod, zaznaczamy aplikację i zniszczenie transmisji data. Nie tylko zniszczenie, ale także zniszczenie msg. na aplikacji. I do tego używamy stm32 cube IDE environment, fokusując na automatyczny source code generator, tzw. stm32 cube Mx. Myślę, że najlepszych już wiesz o tej podstawie, ale chciałbym pamiętać ci, że Lorevan to nie tylko radia, ale Lorevan network consists of four layers. It is endpoint and this layer is the one we will focus today. Then we have gateway, which acts as a bit pipe, in fact. A network server, which is responsible for network management, for example, selection of the best gateway in terms of quality of service, quality of link. And then on the top application server for network joining process, and it is most important from customer of view to install, to put the end customer application on that. What we will do today? So the plan is to implement, develop the temperature controller in a kind of not typical way, because the architecture of that controller will be spread one. This is not a practical solution, but from the hands-on point of view it is very practical because we will implement both directions of communications, uplink and downlink. So our job will be based on the board provided by ST, the so-called Nukleo board, Nukleo 64 in particular, and STM32WL on the top. So what we have here? We have SMA antenna, the mechanical standard and the electrical standard follows the Arduino standard. So we have Arduino connectors. We have STM32WL. In practice it is under metallic shield because of the regulations. We must sell the modules. So here you can see the metallic shield removed just to give you the full overview. Then we have integrated debugger. It is STlink version 3. Quite practical solution. This STlink implements mass storage device so you can just drag and drop the binary using Windows Explorer and flash the micro. Thanks to that we have four patch buttons including reset. So we have three user buttons and one reset button. Then we have three user LEDs. You can supply this board with USB cable or use external power supply. For the temperature controller we need a temperature sensor. Inside the STM32WL we have temperature sensor. It is junction temperature sensor in fact. We can reuse it. So every period, let's say several seconds, the application will send data to the Lava Network and then application on the top sends back some message. So here you can see the details of the temperature sensor. It is connected to the internal ADC multiplexer. Here. And in order to increase the accuracy of the measurement process we will also use the internal voltage reference which is connected to another channel of the ADC multiplexer. And there is a dedicated macro to evaluate the temperature in Celsius degrees. So I think at this stage there is no need to focus on so much detail. So let's go to the next slide. Some important message for the developers is that our implementation obviously based on the SEMTECH protocol stack. So SEMTECH provides the protocol stack both the higher parts of physical layer and MAC layer. And the ST implementation based on the Loravan specification 1.0.3. And source code is located under this link so you can find the source code of protocol stack provided by SEMTECH on GitHub. And the implementation supports class A, class C, both unicast and multicast, and class B unicast and multicast. That's regarding the protocol stack and here you can see the overview of the implementation. So it is so called STM32QWL version 1.0.0. So this is the library pack. It consists also a lot of examples for STM32WL. So this package provides the approaches of the libraries. It is low layer library and hardware abstraction library. Low layer allows you to save the MCU resources like flash and RAM memory. But it is much more heavy in terms of the portability. Hardware abstraction layer approach is really portable one. It is easy to migrate, but consumes a little bit more resources. So as you can see within the pack there is not only Loravan implementation and sub gigahertz peripheral, but also all the peripherals are supported like ADC, GPIOs, URs, etc. Some middlewares are supported like RTOS, FATFS. Security features are strongly supported. This is a very important message for developers because the security is really main part of the Loravan solution. We support some boards, not only nuclear boards, but also discovery evaluation boards and dedicated boards. There are documents, user manual related application node where you can find details. You can just put the name of user manual or application node within search bar of STWeb page and you can find the links. More details regarding WL. As I said, it covers not only the perferial support, but a set of examples, support of different protocols. But our hands-on is focused on Loravan. So let's focus on Loravan examples provided by QBWL package. So those examples, we have three examples. Pimpong, Endnote and AT-Slave. Those examples are migrated from the previous, or better to say, parallel implementation, so-called IQ Loravan. It has been provided a few years ago for, let's say, discrete solution. I mean by discrete, I mean the separated transceiver like SEMTEX, SEMTEX-SX-1272, 76 and separated estimator controller. So for those who are already familiar with IQ Loravan, it is a well-known set of the applications. Pimpong, it is the implementation of physical layer only, so it is out of our scope today. We'll focus on Endnote application and implement class A. So this is our today job. And there is also quite practical solution AT-Slave application, which implements AT-Slave driven Loravan model. So there is also middleware, so the protocol stack implementation provided by SEMTECH MAC layer, physical layer, utilities like sequencer implementation. I will provide more details later on. Software timers, trace unit, etc. And those utilities are common with another system on chip from ST, STM32WB and then BSP because we have particular board, so considering particular board, for example we have RF switch connected to particular GPIO, so we need to provide board support package. And again, the details of QBWL can be found in related user manual. What is the folder structure of the Endnote examples? I will focus today. So in fact, from the user, from the developer point of view, it is quite simple because there is a need to modify lora underscore app.c file in order to implement application, user application layer of Endnote. This is our file to be modified, located within the lora1 folder and the app sub folder. Then we have core folder, so MCU specific files, for example the main.c, the implementation of the particular peripherals. Then we have drivers, so BSP for the board support package, CMCs, because we are using STM32WL, it is Cortex M4M0 and HAL drivers, so hardware abstraction layer drivers for the peripherals. Then we have part provided both by SEMTECH and ST, so MAC layer implementation, so this is SEMTECH and then we have lora finish state machine, so let's say lower application layer state machine of the Endnote, and this is provided by ST, and this is, I would say, added value you can get from ST, because the finish state machine of lora1 is already pre-certified, so if you would reuse the ST solution, the probability of the successful certification process is very high, and this finish state machine provides both regular mode, regular operation of the lora1 Endnote and the test mode needed for the certifications. And also within the middleware we have support for security and crypto and some utilities. Then we have sub gigahertz, physical layer, it is also part provided by SEMTECH and combined with ST implementations and utilities like low power manager, sequencer, software timers, trace system time. So more details on the following slides. Let's start from the physical layer, so the direction of my explanation is from the bottom to the top in terms of the layers of the protocol stack. So on the bottom we have hardware, we have transceiver and dedicated library for that. It is a part of hardware abstraction layer provided by ST and this is sub gigahertz hull. So really atomic functions to handle the transceiver. Then we have part provided by SEMTECH, this is the physical layer, and the hull layer implements interface to the radio driver, so this is, let's say, lower layer of physical layer and this radio driver, this split is implemented in order to interface to any radio driver. So thanks to this architecture you can easily exchange the transceiver on the bottom. Then we have higher layer of the physical layer, it is radio interface which provides APIs to the higher layer, the Mac layer. Here you can see more details regarding the API of the higher layer of physical layer, so radio interface. So as you can see you have a set of the functions to perform some basic operations like radio init, radio get status, radio send, radio RX, radio receive etc. And this interface is used by Mac layer, medium access layer. So again to highlight the slide regarding the split between the layers of the physical layer. So we have two sub layers, lower and higher. Radio low level functions are located in the radio driver. So interface with hull sub gigahertz, atomic services and interface with BSP services. And then we have radio physical layer high level, so it is radio.c. And this is the interface with higher levels of the protocol stack by higher levels. I mean just the Mac, medium access control layer. And here you can see the example how to configure the transceiver, the application. What is the sequence of the operations in order to send data using physical layer only using radio interface. So as you can see as a first step it is the implementation of some callbacks. This is very important, it is first time you can see this mechanism. As you will see the application is even driver. So we need to have some methods and the equivalent of the methods for the low layer programming for the embedded programming it is the callback. The callback is just a pointer to the particular function from C code point of view. We have callbacks like on TXDAN. So this callback will be trigger after successful transmission on EricsDAN. So this callback will be called after successful reception etc. Some timeouts callback, some errors callback. Then we are configuring the transceiver parameters like modulation type, output power, bandwidth etc. Then we are selecting channel and sending data. And the same sequence for the reception again callbacks, parameterization of the transceiver, selection of the channel and starting the reception mode with timeout value. What about STM32WL transceiver itself? I mean the atomic operations on the transceiver. This transceiver is connected internally to the core, to the system, to the rest of the system on chip through the internal SPI interface. And the pins of this interface are not exposed externally. And the library provides the functions to set and get some comments to and from the transceiver. And here you can see the comments set, some really basic operations like entering the sleep, calibration, transmission, reception. And we have opcodes assigned to the commands. There is dedicated function. We need to put, as a parameter, we need to put the opcode, we need to put the buffer to receive the response from the transceiver. And we need to send some data to transceiver, some, let's say, the body of the command. So this is the atomic operation, set command. And we can define some little bit higher level, for example, to make the code more reliable. For example, can implement function sub gigahertz set sleep. And within this function body, we are switching off the antenna to avoid additional current consumption. And we are sending the radio set sleep command. In fact, this is the same approach, but in the opposite direction, so the get command direction. So for example, we can get the status of the transceiver. We can get the received signal strength indicator. And below the SPI level, we have really basic level, the lowest level, the lowest layer of the abstraction. It is just a set of the registers to control the transceiver. We will use particular board, it is Nucleo STM32WL55JC1 board. This board is populated with dual core version of the WL system on chip. It consists Cortex M0+, core and Cortex M4. But in order to simplify the flow of the hands-on, we will implement single core application. So we will use only Cortex M4 application. So we have particular board and we need to implement some board related functions within the BSP library. So for example, configuration of the antenna switch, configuration of the TCXO, because also TCXO is connected to particular pin in order to control the power supply of the TCXO. We have SMPS power supply, so we can use SMPS mode of the WL system on chip, or we can use linear regulator. So that's why the BSP package is needed. More details regarding the utilities. The utilities are quite important for the applications. So let's start from the trace utility. So we implement the DMA trace in order to log the application behavior. And the output for the trace, it is the UART. And on our board this UART is connected to the virtual comport of the onboard debugger. So it means in practice that you can just use terminal on your PC in order to follow the log of the application, the trace of the application. And what does it mean? DMA trace. It means that the implementation of the trace is not blocking one because of the DMA. So we can print the data in real time, not affecting the radio operation. And the trace feature is really important one in case of the problems of any problems because I think most of the cases you would face some problems with the protocol stack with the application in general. Our technical support will ask for the trace. Then low power manager. So we are implementing now the class A mode. Most of the time the class A node is in low power mode. And the low power manager is a software part, which centralize the low power requirements for the model in order to select the appropriate low power mode. For example, when trace is active, we are printing something, we shall not go in stop mode because otherwise the trace would stop. So this low power manager somehow unloads the developer from this task. The sequencer. It is kind of the framework to safely go in low power mode. It also somehow unloads the developer from this task. The sequencer is really the backbone of the application. And it records and manages the tasks and events, but it is not a real time operation system. It is much more simple in order to save the resources, but we have also tasks and events. Then timer. This is the software timer implementation. And you could ask why we have provided such a solution. It is true, we have a lot of timers on our WL system on chip, hardware timers, but the main reason for that is the low power approach. The lowest consumption we can get for the timer, time base, it is the RTC module and in our particular the alarms of the RTC module. And we can use the alarms of RTC module, just the power consumption, current consumption is the lowest one. We can really use the RTC alarms as a time base for software timer. And software timer and timers in general, it is a key point in terms of the LoraVan and node application flow control, because we have a lot of timings, like reception windows, like delays in between windows. Then we have a few more files like memory operations, system time, low footprint, scanf, low footprint, printf, hex conversions, just companion utilities. Ok, so we have the bricks. And now we can start to implement the application. But before, I will provide you details regarding SD implementation. The application is event driven and in particular time driven, because time event is also kind of event, could be regular. And the behavior of the system can be trigger for such an event. And this event can be a timer or radio event. By radio event, I mean the interrupt from the transceiver, like end of reception or end of transmission, some errors, etc. So what is the flow? After reset, we need to initialize the microcontroller, the libraries, the LoraVan protocol stack. Then application sends the join request to join the network. So it is transmission. Then enters low power mode and waits for the event. And this event can be joined accept, for example, or it can be some regular event from the timer. On this slide, you can see this process providing more details. I skip the MCU initialization, it is obvious. So after LoraVan initialization, we need to register the tasks to the sequencer. And we need to init the LMHunler. The LMHunler, it is the main API of the LoraVan process on node site. It is the part implemented by SD and it is pre-certified. So I will provide you more details about that. And because we have sequencer, we need to register the tasks of the sequencer. And we have two tasks in our case. So the LMHunler package process. So this is the main process of the node. It is just LoraVan process, LoraVan protocol stack process. And we have process to send data. So after registration of the task, the application calls the relevant handler to send join request. Then after successful joining to the network, the callback on join request is called. And now the application is aware that it is joined to the network. Then after joining, after successful joining, the TX timer starts. TX timer triggers periodically. And this event, it is just a callback in our implementation on TX timer event. And the period of TX timer, it is the APP TX duty cycle. It will be 15 seconds in our case. And within this callback, we are increasing the priority of the send TX data task. So for the sequencer, it means that the sequencer must execute this task once, only once. And then go to low power again. After sending data, which is triggered by timer, the callback is triggered on TX data. Of course, after successful sending data. And the LED blinks to confirm TX. And then, because we have up and down implemented, the reception window opens. And after reception of the data, callback on Erics data is triggered, it is called. I on the bottom, we have Lora physical layer and Lora Mac. I know it looks quite complex at first touch. But you will see from the developer point of view, the implementation is quite simple. The LM Handler API. So what is LM Handler? This is the interface between Lora Mac, so medium access layer. And the application layer of the user. So it is kind of intermediate layer. Or we can also call it as a lower application layer. Because it implements the finite state machine of the Lora 1 end node. From developer point of view, it provides API to perform the Lora 1 actions. Like LM Handler send, so send data to the network. LM Handler join request to join to the network. We can change the class of the end node. We can set enable or disable automatic data rate. Feature of the protocol stack. We can set device, EOI, etc., etc. So the basic API for the application layer of the end node. Again, event driven approach. So we have set of callbacks. Like getBatteryLevel, getTemperatureLevel. On Mac process notified. This is really the basic one callback. Because this callback follows every event provided by Mac layer of the protocol stack. On join request, on txdata, on ericdata. So here you can see the implementation of the particular callback. It is the txtimer callback. Just to remind you, we have txtimer, which triggers periodically the sending data process to the network. And this is the implementation. So inside, you can see the only two functions, the first function, increase the priority of the LoraSendOnTX process. And this informs the sequencer to execute only once the send txdata function. And we are starting the timer, because the timer is in one shot mode. Before entering the main loop, we need to register the tasks. I already mentioned this on this slide. So here register sequencer task, LMHunler package process, and send txdata process. So this is the detailed implementation. So we need to register the task, LMHunler process. So this is the main process of the LoraOneEndNote. I mean the protocol stack process. And the user task send txdata. And within the main.c, the main.c, the main loop is very simple one, because we are calling only the process, the main process function. This function MXLoraOne process is located within appLoraOne.c. And the implementation of this function is also very simple, because as you can see, we are running the sequencer. That's all. So in fact, in main loop, we are running the sequencer. I mentioned a few times that the most often state of the LoraOneEndNote class A application is low power state. And this is the implementation, because the application flow is controlled by sequencer. After increasing the priority of the task sequencer executes the task only once. And then enters idle task. And it is up to the user to implement the action inside the idle task. And in our case, it will be just entering the low power mode. Some generic feature of the sub gigahertz band, RF duty cycle limitation. Please do not mix the application duty cycle, so the period of the tx timer will be with the RF duty cycle limitation. So RF duty cycle limitation controls the sub gigahertz, below one gigahertz band occupation. And according to the European regulation, the duty cycle, the RF duty cycle limitation is 1%. It means that considering the period of the integration of the duty cycle limitation, which is one hour, so 3600 seconds, and considering the duty cycle limitation 1%, it means that we can continuously transmit data for 36 seconds because of one hour integration period. And Lore-Avan protocol stack automatically handles the RF duty cycle feature. So there is no need to take care about. There is dedicated define inside the region-related file. Hider file, so the duty cycle is enabled. We have also dedicated L.M. Handler API, said L.M. Handler set duty cycle enabled. But considering the practical point of view, during the development process, it is really practical, believe me, to disable the duty cycle control, automatic control feature because during development the node transmits quite often data in order to speed up the development process. And it is practical solution to disable the duty cycle limitation. Obviously for the certification and for the end product, for the target product, the duty cycle limitation feature must be enabled, must be active. Finally, we can start coding. We have the bricks. We know the expected application flow. So we can start practical part. And because we are limited in time, we will use pre-configured Cubemix project. So the application, the graphical tool will be already pre-configured. So let me start QpyDE. This is the STM32 QpyDE environment. It is free tool. It is Eclipse-based. And it is based on GCC compiler. My version, it is 1.5.1. This is the current version of the environment. And I will start from the pre-configured file. So new STM32 project from an existing STM32 Cubemix configuration file. It will take some time. OK. So we have dialog windows. So let's browse for the file here, laura1endnode.ioc Open. Then I will use my proprietary location for the project. OK. So that's all I think. Now the embedded tool is starting. It is STM32 Cubemix. So this tool is very practical because it allows you to configure your microcontroller in graphical way. As you can see, for example here there is a pinout view. And then generate the source code, the project. As I told you the project is already pre-configured. So we have some pins already active. We have clock 3 configuration ready. The microcontroller clock is set to the maximum 148 MHz. Then we have some parapherniars subsets and middleware. And this middleware is the point interesting for us. So laura1 protocol stack I will change the view a little bit. And we have here some tabs. For example laura1 application tab. Let's modify something. Let's modify transmission duty cycle. By default we have 10,000 milliseconds. Let's modify it to 15,000. So this duty cycle is the it is the duty cycle of software timer which triggers the transmission to the network, uplink direction. So after this modification we have the uplink will be sent every 15 seconds. Then let's modify some middleware. Here you can see the regions. We are at least my site. I'm located in Europe. So the support for the Europe region it is enough for me so I can disable the USA region. Here you can see some BSP parameters but will not touch it. So let's keep the settings as they are now. And we can regenerate project. Ok, so we have the main file is open but as I mentioned on the previous slides we need to modify in fact the app underscore.c application. This is the main application layer source code file. So I can even close the main.c section. Here and the source code generated by QBMX consists of some sections like for example this one. The section starts with the keywords user code begin something and ends with user code end something. And it is very important to include the source code inside such sections otherwise during the regeneration of the source code the code outside the sections will be deleted. Ok, so what is the first step? I plan to use some data format conversion from integer to the ASCII so we will use printf function and for that we need to include the standard IO header file and as you can see I put it inside the section. I will save then practical approach the duty cycle control feature of the protocol stack as you remember from previous slide let's disable the duty cycle control and where we can do it let's go down and try to find some initialization of laura 1 because it is the initialization stage of protocol stack here for example you can see LMHanler init LMHanler configure some timers, software timers start join request and here there is a dedicated section user code begin laura 1 init request so we can disable the duty cycle limitation inside the section and save again. What's next? The next point is to modify the send function so we need to implement the application layer of the sending data do the network and here you can see the relevant function and because we have used the pre-configured project example project the kube mix generated some quite complex body of the send function and my goal is to show you the simplicity of the application layer so I would like to overwrite the previously generated send function body with much more simple one so I will do that I will copy the most simple version and overwrite it and save so as you can see we have only 1, 2, 3, 4, 5, 6, 7 lines and now I will provide you the explanation on that so let's come back to the slides so here we included standard IO, header disable the duty cycle and here it is the new version more simple one version and most simple one I would say as well and here you can see the explanation of the particular lines so inside the first line we need to define the variable to store the temperature because we need to send the temperature to the network then we are defining the variable next takes in it is optional step this variable stores the delay to the next transmission in case when the duty cycle limitation would be exceeded but we disable the error duty cycle control feature so we will not use this variable I will show you close to the end of the hands on how it behaves in practice then we need to call the function to get the temperature and store the temperature in relevant variable and then in fact we have three lines which are strongly laura van related so this is the core of the function we need to assign the port number so the first action the second action is to fill the tx buffer with the data updata dot buffer size and fill the buffer size data for that we will use s and print f function because the data is in teacher format and we need our ASCII data because of the application on the top of the application server so s and print function it is the safe version of s print function we have three parameters instead of two so the buffer for the data the size of the buffer in order to avoid stack overflow and the variable to be converted and then we are calling the LMhuller API LMhuller send to send data to the network so here are the data port number buffer size to be sent here there is a parameter to inform the protocol stack if we need confirmation and here the LMhuller returns the time which maclayer needs to wait for the next transmission in our case it will be always zero because the RFDT cycle is disabled and as an option we can lock the RFDT cycle exit event I think it provides more explanation on that variable so if next takes in than zero so we are logging next tx event in something something seconds the variable the time is return in milliseconds that's why we need to divide by 1000 this is the optional slide because we can modify not always the number of channels or by default the number of channels is 16 we can change this value we will skip this point so after the modification we just done our application is ready to send data so we could finish here but as I mentioned in the beginning we need to implement up link and down link direction so now it's a time to implement our X process so let's come back to the source code and here is a function generated by the cube mix and it is also kind little bit complex so I decided to overwrite it with the most simple more simple maybe not most simple in this case more simple implementation so I will do it now ok and I will come back to slides to explain what is behind so as a first action switching on the blue LED to inform the user about the reception event then I need to start the software timer of this Eric's LED because I need to blink it not to switch on it continuously then I need to validate the port number because as you remember I assign port number 2 to the relevant data structure and then is a time to analyze the received buffer the received payload it is very simple because the payload length is one so we receive only one byte and maybe I will show you the source code so if I receive the letter I it means that the temperature must be increased the letter D decrease the temperature the letter E equalize the temperature so the temperature is as expected and if the letter is different if the byte is different then the received data are inconsistent so now we can build the application ok so application is just built and as you can see we have still resources to be used only 24% of RAM is occupied and only 41% of flash is occupied there is one warning let's see what happens ok not used variable so we can comment it out and now it is a time to flash the binary to the board I connected the nuclear board to my USB cable and I can flash the application ok ok I need to update the firmware I'm upgrading the firmware of the AstaLink it may happen on your site as well then I will close this window reconnect the board and I can start debug process ok so the board is flashed then let's close the debugger view and connect terminal to the board so what should I do now I need to change the serial port data rate to the 115 KB per second and then I can press reset ok, you can see application just started and send the join request the nodes just join to the network and the temperature on my table is 18 degrees so quite cold I would say i this application let's not send those data and receive some downlink as you can see here increase the temperature so the send temperature is lower than the threshold for sure and data and it sends data every 15 seconds so maybe I will provide you more details about higher layers about the infrastructure I have used so in this hands-on I'm using the multi-tech conduit it is practical solution for at least for me because I have all the layers of the Lora 1 infrastructure in one blue box so gateway here network server and application server and also the higher application layer of the user I mean the node thread application on the top so I can design, I can develop very simple flow on the top of the node thread and implement the functionality of the application and also to practical reasons there is no need for commissioning for each new joining node now the workshops are remotes during such a hands-on if we have a lot of attendees it is just a practical approach to implement the application layer without need to commissioning each new joining node of course the application key is the same for all the attendees we have also the equivalent of this solution on the Pinoclo Lora gateway but this is not the scope of today's session this is the configuration of the multi-tech conduit physical layer configuration some application server configuration like application key UI and this is the flow this is the flow which is populated on the top of application server using node thread so we have the reception block Lora Rx then we are comparing the received temperature with the threshold following the result of the comparison the flow performs to actions increase, decrease and equal and all those actions are connected to the Lora Tx block the green one blocks are for debug purpose only the flow is really simple one and consists of 5-6 blocks ok this is the configuration of the terminal so we already tested this this is the screenshot from the terminal for the regular operation so sending data receiving the download from the application server and this is quite interesting I hope because this is the application behavior when duty cycle is enabled so the step number 7 of the send takes data function when duty cycle is exit here mac layer reports the duty cycle control feature reports that the next takes in is possible in 84 seconds in front of the 1% of the duty cycle RF duty cycle limitation then during next attempt to sending data the needed delay is lower and finally the protocol stack is capable to send data the current consumption of the end note of the WL during the laura van operation so we can use quite expensive equipment as you can see on the slide but we have cost effective solution for that it is our ex nuclear lpm 01 so called power shield the bandwidth is 100 kHz 3.2 mega samples per second sampling rate the current range is from 100 nano amps up to 50 mili amps i i will use this tool now to show you the current consumption some modification hardware modification is needed on the nuclear board in order to avoid parasitic leakage current flow just one solder bridge removal SB1 here and because this power shield in fact acts as a digitally controlled power supply with embedded multimeter we need to connect this power supply to the nuclear board and this is the connection here you can see the details how to remove the SB1 solder bridge and this is the screenshot of the join process of the current consumption during join process so transmission stage then 5 seconds delay and reception of join accept here is the regular operation so TX stage one second delay one second window and then reception window and this is the current consumption in low power mode 4 particular conditions so here we have STN32WL dual core RTC is active and RTC is driven by external low speed oscillator 32 kHz so as you can see it is about 1.7 micro amp i will show you live how it is working this is the software for the power shield i am selecting i just connected my hardware i am selecting the board taking control and now i need to configure the parameters of power shield let's set the highest sampling frequency let's set 100 seconds acquisition time and power supply voltage 3.3 volts and i can start acquisition so now joining process is taking place and here you can see some square wave because the implementation due to practical reason we added red LED blinking during joining process and in fact you can observe the current of red LED for the slide i just show you here this red LED has been removed that's why there is no square wave but for the regular operation there is no LED blinking so i can stop the acquisition so joining process here and then regular operation here we have 15 seconds maybe i can magnify this area the regular operation part so TX then 1 second delay then reception window maybe i can open i can magnify the low power state so again and i can show you the report and again the current consumption is about 1.7 micro amp as you have seen on the slide so in my opinion practical solution it's not so expensive ok let's come back to the slides we are close to the end of the hands-on maybe some generic information about the certification the target of the LoRaVan certification is to ensure the interoperability and compilance of any LoRaVan network there are some optional extended RF tests like total radiated power total isotropic sensitivity some of the network service providers needs such a test from marketing point of view you can get the LoRaVan certified logo after successful certification in order to start the certification the device manufacturer must be a member of LoRa Alliance currently the certification program is for class A devices this is important so the regulatory testing can take place before after or at the same time but usually the test house is capable to provide such a test in parallel with the LoRaVan certification and the process details are described including quite useful frequently asked question section on LoRa Alliance web page ok so this is the end of the hands-on thanks a lot for your participation