 Okay, so now we're going to have a look at the software stack itself. So this is based on the example we did this morning. So it's the 80 slave example, and we're now going to have a look at how all the software works that allows us to do the Laura protocol. So what we're going to see in this section, we're going to have a look at the gateway we're using. We're going to have a look at our multi-tech gateway and network server, application server. Remember it's a combined three-in-one box. We're then going to have a look at the software stack, which you can download from the st.com website. So i-cube-lr1, and in particular we're going to look at the 80 slave project file. So this is our Class A node firmware that we programmed in using the drag-and-drop principles this morning. Then we're going to have a quick look at the IEEE 802 standard. So Laura-1 actually uses some of the basics of the IEEE standard. So it's the same as Zigbee and Wi-Fi and that the protocol and message handling starts off in the same way. Then we're going to have a look at our operational model, so our finite state machine that we've got controlling our Laura stack. And then we're going to have a look at some of the other functions that make up the Laura stack itself, so timers, low power modes, things like that. So this is the multi-tech gateway, so this is my blue box here at the front of the room. This is providing us with our gateway, network server, and application server. So all the items are in this one box that we have here at the front of the room. So the configuration for the network server side, so we can select our frequency band, so we're in the 868EU. You can use it in the US as well, so you can change that around. So that we can get immediate responses, we've set our queue size to be one for our example. So this is just so that we can get the response back so that you can get your replies within the time frames. Over on the right-hand side, we've got our unique ID for our network server and our particular network key that we're using. So this is so that we can identify our network server. Laura, if you remember, can be a public network. So there are one or two public ones out there. But it can also be a private network. So this is where your network key will be unique so that you can have your own private network within your site, your facility. And you can still have the local council's Laura network broadcasting in the general area of where your site or facility is located. So these keys would be different at this point. We've also, for development purposes, we're telling our gateway to disable the duty cycle. So this is the regulation side. So for development purposes, you can set your gateway here to ignore the EU regulations of 1% duty cycle. As I say, we're disabling it just purely because we're only doing it for development purposes and these workshops. In reality, if you were using this multi-tech module for a proper application, then you would not have that ticked in the application. So that was the network side. So also, the application server is inside our blue box here. And this particular one is a Linux machine inside the multi-tech. So we have Node-RED as our application server, providing the functionality of what we do when we receive a Laura message on our network. So this is the screenshot of what we've got programmed inside our multi-tech gateway. For the example we were doing this morning, we were receiving our Laura message. We were changing the payload. So if you remember, our payload had to be a structure that had the word moat inside it. And in our change payload, we are replacing moat with gateway response, or GWRESP. And then we are transmitting that information back out over our Laura network. So that's what we were doing in this morning's example. Also, we have the ability in the Node-RED software to put in debug blocks. So we've got in the green elements there, we have a debug block so we can see exactly what we're receiving as our Laura message. And then outside, or the outputs of the change payload block, we have another debug block so we can see what we're then sending to the output on our Laura system. So we can actually see what we receive and what we're then sending out based on the inbound messages. The items in the middle, the compare and the increase, decrease and equal, that's for this afternoon's hands-on. So this is where we're going to compare for our secret number or our temperature. And then depending on what the compare block says, we'll either send a message out that says increase, a message out that says decrease, or a message out to say correct, we're equal. So we don't need to do any actual changes at the other end. So this is all done graphically, so there's no writing of code. You just create all the blocks on your screen and then link all the blocks together to generate your application server. So this is the debug window that we've got on our application server. So in here you can see my nice messages. So this was the inbound messages that contain the word, mote, and we have John Smith as our inbound message. And then our gateway response for the change payload will send the name out again, but it will change the word, mote, to gateway response. So as well as programming the application, you can also look at the debug of what's going on in your application in live terms, so you can see exactly what's going on inside there. So all this is happening inside our blue box that we've got. So on your desk you had the node, so you've got the law of discovery board there. There is a user manual for this software package that we've programmed in our discovery board, so um2073. Really good document tells you everything that you need to know about the software package that we're using inside the Laura Murata module. So when you open the project in your Kail environment or your chosen environment, this is the structure that you will see. So remember we only dragged and dropped the binary file into our Laura board this morning, if you want to open this now you can do. And this is with the structure that you're going to see inside your Kail environment. So we've got a documents folder, which has got a few explanations of some of the projects that are installed inside there. We've got our board support package. So this is for the discovery board, for all the other drivers that are needed to communicate with the rest of the chips that are integrated on the discovery board. You've got your standard CM Sys drivers from ARM. So they're all integrated in there. You've got the HAL drivers and the low layer drivers for on the SEM32L0, which is the micro controller that's inside the metal can. You've got the startup files from Kail. So the MDK ARM startup files. Then we've got actually our project, so our AT Slave project. So the first two C files are all the parts managing the different AT commands. So these are all doing the decoding of the message that you're typing in on your laptop's terminal window that's been sent into your module so it knows what to do to send out across the Laura. Debug, self-explanatory. Then we've got the relevant drivers that we're using to drive the hardware. So we are using the RTC. So the RTC is providing our timers so that we can keep the device in low power mode as long as possible. We're not using the SysTick or a conventional timer. We're using the RTC timer and it'll wake up on periodic alarms. And that provides the timer ticks for our Laura protocol stack. The SPI peripheral is what's actually driving the radio. So that's the link inside the Murata module that's communicating between the micro controller and the radio chip. And there's various GPIO pins inside there as well controlling some of the features. So these are all the communications between the two chips inside the module and what's waking us up inside there. Then we have our main file, main.c. And we also have a file called Laura.c. So Laura.c is our implementation of the Laura stack. So this is our finite state machine sits inside here. And the main.c will be calling this Laura.c file on a regular basis. So this is the main part of our application. Then we've got the drivers for doing scanf and printf. So these have to do our communications. Then we've got the VCOM, so our virtual COM port. So this is providing us with our terminal interface so that we can talk there. And then we've got some more hardware related for the micro controller. So the interrupts and the actual core hardware file for the micro controller. So that makes up the project side. So this is unique for every different project that we've got in the package. Then we've got our middlewares. So our Laura Mac and our Laura Mac security, so the crypto parts. So these are managed by SEMtec. Then we've got our utilities. So these are the middlewares, again, that are doing certain functions. So like time servers, low power modes, things like that. And then right at the bottom we've got our proper full encryption engine that's part of the Laura stack as well. So the implementation of the Laura package that we've got here. So it's split into three different areas. So we've got parts that are ST controlled, parts that are SEMtec controlled, and then there's parts where there's been a collaboration between ST and SEMtec. So anything that we're in control of is the HAL itself. So as I said, IO pins, SPI and RTC are all being directly used so that we can communicate with the radio and control time servers and things like that. So all the HAL and low-layer drivers are all 100% controlled by ST. The sensor drivers, so there's potentially MEM sensors that you can have interfacing through the Arduino connectors. These will be using I squared C and ADC and a few other things. So all these sensor drivers, they're all ST-rided, so we're in control of those. The application can also talk directly to the HAL drivers for all the periphery that's on the Murata module. So you can use them directly for the rest of your application. So all of that is just your application talking to ST drivers as you would with any STM32 design. Then we've got all the MAC area and the radio driver itself. This is all controlled by SEMtec. We don't have access to this IP so I can't really give you any details of what's actually going on in the MAC side of things or the radio side of things. Apart from we're using the SPI interface and some GPI opens to communicate with this radio driver chip. Then there's the block in the middle which is the middlewares. So these are the time servers, low power, random number generation and a few other utilities. These ones are elements where SEMtec control the functionality but the functionality is using the ST hardware so ST has to provide input on how best to use all these hardware. So as I said earlier, the time servers. These are providing the various timing functions that are going on in the Laura stack. The tick for the time servers is controlled by the RTC. So the module that's called the time servers has to know how all the RTC works. It has to know how to configure the RTC and set the various alarms to wake it up to provide the relevant ticks to generate whichever timing event you're looking at. Same for the low power modes. So you have to know how to put the device into low power mode to get the best power consumption while you're asleep. So all of these are combined functions between ST and SEMtec. So if we now have a look at the IEEE 802 protocol. So Laura uses the principles of this. It's not the entire protocol. It doesn't use everything. It just uses the main principles. So normally the Mac user will send a request down to the Mac layer to say that it wants to send something. And then you'll normally get a confirmed back from the Mac layer back to the Mac user to know that it's been received. When information arrives on the layer side it will then send an indication out to the Mac user and the Mac user can send a response back if it chooses to do so. So these are the service primitives that we have of IEEE 802 and Laura uses these service primitives. So the particular services that we're looking at are Mac management service or the Mac layer management entity so M-L-N-E. This provides all the management functions so the join requests and things like that. And then we've also got Mac data services which is the Mac common port service MCPS and this is where all the data throughput goes from when you send or receive data across the physical layer. So if we look at this in respect to our software so when the Mac layer receives a information over the radio side it will send an indication to the Mac user which will then generate a callback in the software so that you can go on action based on what indication you've received and you can send a return back if you want. So within our software so that callback will be the Laura Rx data subroutine and the indication that will be sent from the Mac layer to the Mac user will be Rx data equals true. So this will let the software stack know that we've received a message over the radio. In this particular case we don't send the confirmation or we don't have to send the confirmation back to the Mac layer. So this is our operation model of our class A device. So this is our finite state machine that is running in the laura.c software part of the stack. So this is the process that we go through when we power up the device and then it will sit in its infinite loop between sleep and send information. So as we power up our device we will move into the initialization phase so where we've set up all the parameters, set up the software enable our duty cycle function obviously when you're doing your development this will be disabled and then you'll move into the join state so this is where you're waiting to join an item. So you'll either do one of the two joins you'll either do over the air or you'll be personalization. If you've got personalization then your keys are already stored in there so you will transition straight into the send state and you can send your message at that point. If you're on the over the air you will enable the join timer send your information out and then you'll go to sleep at this point. Then after some time event based on one of your time servers you will either get one or two responses you will either get you've not joined in that case you will go back to the join state reset your timer and send all the information out again to join to sleep or you will get you have joined the network so therefore you'll transition into the joined network where you can then start your transmission so you'll then say joined will then become true you then move into the send state and then you will join the infinite loop between send and sleep so every time you send something you'll send the information prepare the next packet and then go to sleep when you've got a send event you will wake up check to make sure that you've joined you are still joined and then you'll go around that infinite loop until you downpower the system so back to our IEEE protocol again so our finite state machine is managing this protocol for us so our callbacks are in our Mac user part so this is our application layer where our finite state machine is and our callbacks and down in the Mac layer we have the Semtech software called laura mac.c so that's managing the radio itself for us so what is in our software for laura.c so first part of most.c files is an initialization so we have a laura initialization so this will set up all our callbacks that are available for our transmit and our receive parameters then we have our finite state machine entry point so we have our laura fsm routine so this is what we'll be getting called on a regular basis and then we'll have our actual two callbacks themselves so the laura txdata callback and the laura rxdata callback so these are the four main elements of our laura.c file we can also find out the states of where we are in our finite state machine so there is a command for us to get device state and you'll then get one of those particular responses so you'll have a get your in it state join, join, send or sleep there is one extra state there called cycle so this means you've just happened to have requested it while it's in between one of those defined states that we have inside the finite state machine diagram some of the utilities that you could use are time servers so in the afternoon sessions in the hands-on we will create a time server ourselves so the time servers are there so again it's the same similar steps that we had for our state machine so you will have an initialization part which will set up the various callbacks for each particular time or server that you're creating you'll be able to have a routine that sets the value of the time or server so you can set the delay for which timer you want and then you'll have two commands for start or stop the timer so again we will be using this in our example to control an LED so you can see how to use any of the timer servers available inside the system so this is what sits in main.c so this is the while one loop in main.c so we have there our Laura FSM so that's the call to our Laura state machine so that's doing the process of what we're doing and then under that we have our command process so this is managing our AT commands that we're receiving so every time we receive our AT command we will then load that into our Laura state machine to do whatever we want to do which is send message out, join the network whatever else all those then will go into our finite state machine and down here at the bottom of the while one loop we can keep entering low power mode all the time to make sure our device is consuming as little power as possible in our application while you're doing development potentially this part might not actually having your software until you've got the process of the communications all sorted out so there are other functions inside there so you saw one of these hardware.c files in the software stack so inside here we've got extra functions to do certain tasks so in the last hands on of the day we will be getting the temperature temperature level so inside all STM32 devices we have an embedded temperature sensor on one of the analog ADC inputs channel 17 and that gives us the temperature of the device so inside here we've got a support package which is taking that temperature value and converting it into a degrees c value for us which is then what we will transmit out to the gateway in the last hands on of the day there's also a routine for getting battery power so if you're running the device off battery you can use the ADC to monitor the battery levels and there's a routine already pre-written to get battery level there's routines for all the low power modes that we have on the STM32 and more routines to get the unique ID and communicate with other peripherals on the device so these are all pre-written routines in the hardware .c file that we have in the package so parameterization so the keys that we have stored inside the device and the unique ID application server address that we want to talk to are all stored in a file called commissioning.h so this is where we are declaring all the information so there's lots of different defines in here we have got over the air activation defined as 1 so we're going to use the over the air activation if we didn't have that enabled then down here at the bottom our network session key is already stored in there and our application session key is already stored there so again depending on what the define for over the air is will depend on if these two keys are going to actually be used in this particular example so here you can see the device unique ID you can see our Laura application unique ID so if you remember that was what was stored in my gateway all those 0x0 ones and then we have our application key so this is the address the encryption key we're going to use to send the information out to our servers so that we can get our session keys back so that's what we have programmed in there so the two ones that are specific are the application key and the application unique ID these are the two that are stored inside my multi-tech box so the application key is so that I know how to decrypt my message and the EUID is so that I know I'm talking to the correct gateway so if we had more than one multi-tech gateway in the room then we would need to change our application unique ID on one of the two gateways so we have a parameter that we were using inside our application so we've got our duty cycle so we're defining our duty cycle to be every 10 seconds so again we're not following the rules of the regulator at the moment so we're broadcasting every 10 seconds there we've enabled adaptive data rate so if you remember I said you can set the adaptive data rate where we'll decide on certain parameters to try and maximise battery power based on signal strength we've got confirmed messages as disabled and just as you do in Wi-Fi so in the IEEE we have an application port as well so you've got to define which port we're going to use inside the LoRa1 application another couple of parameters in LoRa.c file so LoRa1 duty cycle on is true so that means we're going to follow the rules inside our LoRa1 so in the 80 command session the messages are very small it's the size of whatever command that you've sent so therefore the 10 second duty cycle that we've just programmed in our main.c is within the limits of the EU regulations so we're saying that we're going to be true here and then we've also got over-the-air activation duty cycle so this is what happens when if your join fails first time round you will then have to wait 10 seconds before your system will go and try and join again by all the regulatory rules that we have available so we're actually following the rule book here in this particular example for basic debug we've got the vcon so we're doing our virtual comports in this particular example we are setting our board rate to 9600 the reason we are doing this is because we are using the low-power UART and the pre-scalers in the low-power UART because it's based on the RTC crystal so the 32 kilohertz crystal the largest board rate we can get from this particular UART is 9600 so this is so we can send all the information out to our terminal window and control the system from our laptops so in this particular example we are losing all the low-power modes so we keep dropping into stop mode at all times and we wait the MCU up process our information and then drop straight back down into stop mode so we are using the system as a full low-power based system in these examples the afternoon examples we'll be using the standard UART so we'll be on a higher board rate so we're doing development work and we're not using the full stop mode at that point some other basic features we have in the debug we have some other pins that we can monitor to show what is going on inside the application so pbs 13 14 and 15 they can be monitored to see wake up time calculations how which mode you are in if you are in sleep mode not and if you are in stop mode so you can monitor a few extra things there there are some extra debugs for hash defines that you can remove and these will add extra debug features in there so like the debug printf where you can actually get more information out of the system as well so it's all integrated inside the software stack that we are providing you in the iCube one package so here's a scope trace of pb 15 so this is monitoring the stop activity so you can see there the device wakes up to do its transmission then it goes back to sleep there is a very small spike there as it's the finite state machine starts one of the software time bases one second after end of transmission you can see that we wake up and that's one second is our programmed wait state to open our first rx window then it goes back to sleep again and then you can see another software timer happens a bit further on if we didn't receive a message back in our first rx window then there would be a second rx window open another one second after the first rx window so if we zoom in there now on our transmission part so you can see there that we are awake for 20 milliseconds in there and inside there remember there's all the preamble and everything else the payload the error correction as well as the two bytes that we're actually sending so you can send up to 220 bytes as the maximum payload but our particular message there is only two bytes long included inside that payload so you can also uncomment the defined low power mode disable this means that you don't keep dropping into all the low power modes and it means you can do more debugging etc without having to keep disconnecting your st link at that point so there's a few more commands available inside the package