 Welcome to part 3 of the LoRaWAN with STM32 getting started series. My name is Jilti Arena, Applications Engineer for ST Microelectronics, and in this video I'll demonstrate how to set up the WOL Nuclear Board as a Class A LoRaWAN N-Node device and connect it to the ThinkStack Network Server. This is a continuation of the preceding part 2 video of the series, so please make sure to watch that if you haven't already. At this point I have my WOL Nuclear Board handy. Previously in part 1 I mentioned that the N-Device firmware was included in the QWOL firmware package, so I'll go to the LoRaWAN N-Node project and open it with Q by DE. The first thing that I need to set up is the device EOI for my N-Node. I have two options for this. Option 1 is to use the device EOI that is automatically created from the UID64 register, or option 2, use a static device EOI that I can manually set from the LoRaWAN device EOI pound-define. For this demonstration I'll use option 1, so I'll leave the static device EOI set to zero. I'll go ahead and find and open the files that I'll be talking about now, which are seidentity.h and loRa underscore app.h. Again, no changes are needed in seidentity.h. With this option the program creates the device EOI automatically in GetUniqueID. The GetUniqueID is a simple function that reads the UID64 register and creates the device EOI from it. This is the breakdown of how the device EOI is created. Taking my board's 8-byte address as an example, the first three bytes are the company ID for ST Microelectronics, the fourth byte is the device ID code for the STM32WL, and the last four bytes represent a 32-bit unique device number that is sequential and different for each individual device. This is what makes the address unique. From loRa app.h I have to change the active region pound-define to US 915, and this is an optional step but I still recommend doing it. From sysconf.h change pound-define debugger on to 1 in order to enable the debugger so I can run the program within the debug session if needed. Once all changes have been implemented, I'll make sure to save all files that were modified, then build the project by clicking the hammer icon, and the build should complete with zero errors. Now I'll connect the WO nuclear board to my PC so I can load the program on it and start a debug session. Once in a debug session, I'll hold from running the program for now. I'll run it after I have registered my end device on the ThinkStack network server. From the ThinkStack console, I'll click on applications, then click on add application. Once in this page, I'll be prompted for a unique application ID which I'll enter. The application name and description are optional. Once finished, I'll click the add application button. From here, I'll click on the add end device, register my device. From the registration page, I'll select the manual registration option. I'll leave the activation mode set to OTAA, set the lower WAN version ID to MAC version 1.0.3, and click start. Then I'll enter the end device ID, the app UI which must match the one specified in the WO firmware in se-identity.h, the dev UI which I can read from the sticker on the WO nuclear board. This is the same that is extracted from the UID64 register I mentioned earlier. I'll click on the network layer settings to proceed. I'll set the frequency plan to US902 to 928 MHz FSB2. Finally, I'll set the network key. In this case, I'll just use the default one to find the device firmware in se-identity.h, and click add end device. My end device is now registered with the network server, so I can proceed to run the end device firmware and see I joined the network. But before that, I'm going to connect the WO nuclear board to a serial terminal to see what's happening. At this point, the WO nuclear board should be enumerated as a virtual COM port on my Windows PC. From Windows Device Manager, it should show up like this. Take a note of the COM port number assigned, and select this from Terra Term. Then configure the serial port as shown with the bottom rate set to 115200, data set to 8 bits, parity none, stop bits 1, and no flow control. Select auto for the new line receive option. Now I can go back to my code project that I left stalled at the beginning of main, and run by clicking the run button. From the serial terminal log window, I can see that the end node device boots up and that it joins the network successfully. The LoRaWAN end node firmware is set up to transmit a data payload every 10 seconds, and I can see these uplink packets received on the network server console. If I look under data, I can see a log of the packets being received from there. This payload sent by the end node actually contains dummy pressure, temperature, and humidity data. An upcoming video of this video series will demonstrate how to integrate and use our ex-nucleo IKS01A3 motion MEMS and environmental sensor expansion board so we can report real sensor data up to the network server. By protocol definition, a Class A LoRaWAN device can also handle receiving downlink data packets. The protocol specifies two available downlink slots after each uplink event that can be used to send data down to the end node. I can demonstrate the downlink feature by sending a downlink packet from the network server console to command the end node to blink in LED. Under messaging, in the downlink section, set the F port to 2 and send a payload of 01. This is the code to turn on the red LED3 on the nucleoboard. I can then send a payload with 00 to turn off the LED. I hope you've enjoyed this video. I'll see you in the next one where I demonstrate how to forward the data from the application server, like my device is Cayenne, to help visualize and manage the data received from the end node. Thanks for watching.