 Okay, so we're now on to the last hands-on and this one is now going to add some Metro hardware features now from the Discovery board into our previous example which was the number guessing game. So we're now going to turn it more into a real-life application for a typical Laura sensing node or moat. So the key learning features for this hands-on are pretty much the same. We're still going to look at the two callback functions so we will have to change our parameters that are in our callback functions because the application is slightly different. We're still handling a data buffer of some sort so this time it's a single element of temperature. We're going to continue using our software timer but now we're going to use some of the extra hardware functions built into the Laura bound software stacks or some of the pre-compiled libraries that we have inside the Laura one stack for supporting additional hardware on the target device. So this time we're now going to turn our Laura moat into a temperature sensor so it's a real-life application it's going to measure temperature of wherever it is located around the world. Rather than sending the Ramon number as we did before we're now sending a temperature value and then we are going to compare that temperature value to a comfortable temperature value stored inside our gateway and we'll either get a command to tell us to increase the temperature decrease the temperature or we've got the correct temperature set. So now we're going to change the moat measurements to go every 60 seconds so temperature is not normally a fast changing item so 60 seconds is quite reasonable for a temperature change and now we're going to let people know if we're above the threshold below the threshold or we are at the correct temperature so the LEDs will light up to blue to say it's too cold red to say it's too hot green to say we're at the correct temperature so if you look at the datasheet from the SDM32 L0 device inside the ADC connected to channel 18 we have a temperature sensor integrated inside the silicon so we've got two calibration values for that temperature one done at 30 degrees C and one done up at 130 degrees C and those are stored in system memory at final test in our factory so we store these two calibration values then in the datasheet you can see the average slope of millivolts per degree C so all these parameters are used to calculate the value that we're getting into a degree C value which we will then transmit across the Laura network so if we're now looking the SDM32 L0XX hardware dot C we can see the routine for compute temperature and we can see where our two calibrations are defined as well so all these parameters now go into the calculation process to give us the degree C value so when we ask for a get temperature reading it's already being computed correctly based on all the parameters and the calibration values that we have stored inside so the architecture is exactly the same as we've seen so we've still got the application layer talking to all the different libraries and then the how below it's still using the IEEE protocol for requests and indications between the Mac user layer and the Mac layer itself we're still using the layer management entities and the common port services to do the communications between joining and transmitting data when we get these requests in our software this all links back to the callback routines for either transmit data or receive data and that's all controlled by our finite state machine where we will normally sit in the sleep and send modes and every time we send a message we will transition between these two modes so this means the files that we're still using are main dot C and Laura dot C and they are communicating with the Laura Mac dot C so the implementation stays the same so we're still initializing the Laura dot C in exactly the same way we're still using the two callback routines even though the code inside these callback routines has now changed we're still got the get device state available to us so that feature is still there in the Laura dot C and we're still using a time server so we're still initializing a timer setting a value and then starting one of the timers to control our transmit LED the new features we're using now are this hardware get temperature level so we're now calling this specific routine to providers with the degree C temperature value and as we're still doing development work we're not using the low power you are we're still on the main you art which means we're still at 115 200 board so that we need to make sure our term might terminal window is set to the correct board rate for us to see the information being passed between our device and the Laura gateway so how does it all work well it works pretty much in the same way as it did on the past example so the flow of the information is still traveling in the same way and our flow diagram here is exactly the same as before so the procedure hasn't changed it's just what we're doing in our Laura Tx data and Laura Rx data that had going to be different compared to our previous hands on that we ran so let's go straight into the coding then so we need to go into our projects this time for the end node temperature sensor so if we go back to our Kyle environment I want to close the previous project so it's project close project and now if I go into our Laura end node temperature sensor it's the MDK arm and launch the project file again reopens I now go and find my main dot C we can then start adding our code so so this time we need to add our buffer size to be four because our temperature sensor now can potentially go over a hundred degrees so that means we need three digits plus the return character so we need to increase that to four and to make it more of a realistic application we're now going to set our duty cycle to be 45 seconds so remember the random number features will still get added later so we'll be somewhere between 45 and 90 seconds for our transmissions so we need to add these two lines to our code first you need to go in at line number 72 so that adds our two lines for those variables then we need to initialize our timers so after our timer events so this is exactly as we did in the previous example so they need to be added to the software we've got line number 97 I'll place mine then as I said we need to put our random effect in to make sure that we're not having multiple nodes transmitting at the same time so that needs to go into user code beginning and section number one just like we did on the previous example we need to make sure that our default data rate is set to a value of five which means we have a spreading factor of seven by default it should always be set to zero so if we go and find that region EU.h file again in our code regions file region EU 868 region EU 868.h default data rate there is set to five that's okay that's already on five now we need to put our transmit data callback routine in place so this goes in user code section number three and this is now going to prepare the temperature information that we're receiving from the get temperature level hardware sub routine into the format so that we can load it into our payload down here at the bottom so we need to take all of that code and placed it into user code begin and end section number three remember if you're copying and pasting from the PowerPoint you will notice delete the end of line limiter that was added in the PowerPoint slide then we need to sort out our Laura RX data sub routine so this is pretty much structured exactly the same as what we had in the number guessing game apart from the text in the printf statements that will appear in our terminal window have been changed so again this needs to be copied into the user code begin and end number four finally don't forget our timer event routine to switch off our LED so we need to paste that into the section just below or just after user code end number four and before we do our build we need to make sure that the duty cycle restrictions in our lorda.c file are set to false remember for a real-life application you need to leave that as true it's already set to false in my software so I can now go project and build while my code is building there inside our application server now rather than having our random number in our compare value I have now replaced this with a temperature threshold so when we look at our debug we'll see our incoming temperatures and then our outbound messages to either tell us to increase the temperature decrease the temperature or to let you know that we are at the correct temperature so we'll see that going on on the debug screen shortly so I've got zero errors so I can now program my target board so I'll download I'll now have to wait for the array cycle to go through so there we go our device is now being reprogrammed I go back to my terminal window you can see that we've done the over-the-air version we've done the join process and we've now sent out our first temperature reading which is 27 degrees and temperature is now too high if I place that board nearer to part of my laptop which generating a lot more heat you should see my temperature increase quite significantly there we go so it's already jumped up to 31 degrees and it will probably jump up a little more there we go 34 degrees you can see the information going through and if we now look at the webcam that's monitoring my gateway laptop and it refocuses you should see the various temperatures coming in of 34 degrees 35 degrees and now I believe it is on my screen it's 38 degrees now I'm transmitting so you can now see 38 degrees coming in 39 degrees so you can see there that the information is scrolling through as it would in a real life application as my laptop is working quite hard at the moment generating the web live webcam on such a high resolution the exhaust fan of my laptop is actually getting quite warm so if I'll move my board away again somewhere that's a little cooler in the room you should see the temperature drop down every now and then you will see that there's another temperature reading coming in so you can see there just near the top of the screen on the left-hand side there's a 24 degrees that's from a remote temperature sensor somewhere else in the room so you should now hopefully see my normal board drop down to around 24 degrees now it's no longer sat next to my laptop exhaust fan you can see it slowly dropping down now the value so this is more like what you would have in a real-life application where you're sending different temperature readings to monitor what's going on around either building management or refrigeration units things like that