 Okay, so now we're going to do the second hands-on of the day and this is the number guessing game. So in this hands-on we are going to actually do a proper embedded system now, so we're not going to use the AT commands as we did in the first hands-on. We're now going to write the code itself, compile the code and load the code into our target board through an IDE. We're going to use Kile for this particular hands-on session and we're going to program our board to do the specific tasks of guessing the numbers. So what we're going to do in this particular task, we are going to create the two routines for sending and receiving data. So we're going to create our Rx and Tx callback routines. We're going to manage the application data buffer which is an array of numbers and how we send that array of numbers out. We're going to configure a software timer so that you can visually see how to use one of these timers on one of the LEDs that's on our target board. So we're going to do all of this and then debug our application and see what our gateway comes back with. So we're going to have a look at the gateway response window as well so we can see all the different traffic that's going on on the network at that point. So what we have, we will have programmed into our discovery board on the left hand side an array of numbers somewhere between 0 and 19 and we will be sending these numbers out at a defined interval to our gateway. Our gateway will then do a comparison and send a response back to our node or mode and one of the LEDs there, blue, red or green will light up depending on what the response is from the gateway. So this is what we need to add to our code. So we've got to create an array of integers between the range of 0 and 20, store that inside our mode application source code. We then need to configure our mode to send out one of these numbers every 10 seconds. When the application server receives that number it will do a comparison. If the number is too low we will get a blue LED lit up and we will be told that we need to increase our number. If the number is too high we will get the red LED coming on and we will get the message that we need to decrease and if we select the correct number then our green LED will come on and we will be told that we've got the right number so we're equal to the saved number inside our application server. So what's going to go on while we do all that bit of software? So if you remember from earlier on in the morning we are now going to be playing around with our application user code which is the white box at the top of that diagram. We are now going to be using that user code to talk to our Mac layer which is the yellow boxes on the left and that's going to send out the information over the radio. We're also going to configure a time server so you can get experience of using the time server which will be controlling the joint ST-Semtec block in the middle, the bluey yellowy colour and that's what we're going to do in this application. So if we look at the IEEE standards from this morning as well. So our Mac user layer is going to send out a request so that's when we want to transmit data down to our Mac layer which will then do the transmission across the radio network. When we receive the response back the Mac layer will send an indication back up to the Mac user layer and that will then transfer the data into our software so that we can switch on whichever colour LED is required based on the message. For the services side it works in the end device and the application server so we will have a common port service request from our application layer to say we want to send data. The Mac layer will then receive that request and transmit the data across the network. In our network server and application server works in the same principle. We will get an indication from the Mac layer to say it has received some information and the common port services will send that indication up to the application layer of the network server application server so that we can transfer the information into the program that is stored in our application server which will do the comparison of the number that we have just sent. So when we receive the information from the Mac layer the indication will automatically call the Laura RX data callback software routine which we have to write in our software program and that will then decide what we do in our application based on the received information that we have. So if we look at our finite state machine when we program our board we will go through this routine so we will initialize our software then we will go through the joining process over the air. If that is successful we will then join that loop of send and sleep and we will continually go around that sending each individual number we have waiting for the response then waiting the 10 seconds then sending the second number out. So we will sit there in the middle of that finite state machine diagram between the two states of send and sleep. When it comes to the files that are getting used at this point so our Mac user layer or application layer is our main dot c and our Laura dot c file. So main dot c will contain the callbacks Laura dot c is the finite state machine so the finite state machine will send the request down to the Mac layer which is controlled by Laura Mac dot c and when we receive our radio event then we will trigger the indication from the Laura Mac dot c layer back up to the finite state machine which is in Laura dot c file. So as we showed earlier so this is what's going to happen we will initialize our Laura callback routines we will set the entry point for our Laura class A finite state machine and then we need to complete the two callback routines Laura tx data and Laura rx data so that we can build our payload in the tx data so that we can send out our message and then we need to decrypt the information from the inbound message in our Laura rx data service routine. At any point in this cycle we can always go and check on the status of our state machine so we can see where we are actually in the diagram of our state machine. We're also going to play around with a time server so that we control one of the LEDs so we need to initialize a timer event we will set the value of that timer in one of our callback routines and then we will start or stop the timer after a certain amount of time so we've got the abilities to demonstrate a timer event so you can see exactly what's going on with one of the time servers that's available in the Laura protocol. For this example we're not going to use the low power mode so therefore we can use one of the standard UARTs and it means we can increase our board rate so you will need to remember these parameters when we set up our termite program later on so we need to make sure that our board rate is set to 115 200 with eight data bits one stop bit and no parity so this is done through the virtualcomport.c so you'll need to remember those parameters when we get to enabling our termite window later on so how does all this work so the Laura mode will send out every 10 seconds one number through the system so this is controlled by a timer and a duty cycle which we configure in main.c all the processes within the Laura application are managed by timers so they're all controlled by the software time servers and laura.c which contains the finite state machine is what will be managing all the different time servers in the application so when we want to send information we will wait for an on send event timer to trigger this in the finite state machine will then call the process of prepare the transmit frame and send frame functions and in the prepare transmit frame the routine will call our laura txdata callback which we will write in our main.c then when the mac layer receives the indication that it is received some data the finite state machine will receive that information and it will then call the laura rxdata callback so that we can then use the code to decide what we want to do with the information that we have received so that's what's going to actually happen in the software so here's the same information in a flow diagram so you can see we start the timers laura state the finite state machine will take the parameters that we've keyed in to control those two timers when the next packet timer event triggers we will stop that timer and call a send event the send event will check the status of our finite state machine to make sure we are in a joint state then we will call the prepare tx frame which in consequence will call our laura txdata callback routine and then it'll go off and send the frame and send the request down to the laura mac part of the system through the common port services when the laura mac receives any information again through the common port services it will send the indication back to the finite state machine which in turn will trigger the laura rxdata callback and then we can decrypt the information that's been received and then the cycle will start again and go round so let's start doing some coding so what we need to do now we need to go and open our hands-on framework project for the end node number guessing i'm now going to open the end node number guessing i'm going to go into our mdk arm for our laura one target board and launch the u vision 5 project there's our kyle environment if you remember from when we went through this morning you can see the file structure here so it's slightly different so we haven't got the at command parts in our project folders this time that we have all the other elements in there and this is our main dot c so this is the file that we need to start editing first so the first elements that we need to create is some defines for our buffer size that we're going to transmit the information from so we need to define the size of our buffers so that we can put some labels in so i've already got my two lines here defined so we need an app data buffer size of three so we're going to send potentially up to two elements and a control element so it'd be three parts to our message so we're sending ASCII commands so potentially we could send up two digits one and a zero for 10 and then a termination command as well and the mine i've decided that i'm going to send a buffer of eight so somewhere between one and 20 zero and 20 i'm not going to send eight elements in this first attempt to see if i can find the secret number i need to set my duty cycle to be 10 seconds we'll change that to 10 so everything's measured in milliseconds here so the time base is milliseconds so we always have to put 10 000 and now i need to create my array of numbers so i've there created my array of numbers i've put eight different numbers inside there i have created a variable for my index so i know where i'm up to within my array so every time i go around my transmit loop my index will increment by one so it will move through my array of numbers and now i need to create my prototypes for my timer events so so here are my timer events here for my transmit led so that we can configure a time server as everybody's writing the same software with the same interval of 10 seconds we need to try and add some randomization to the transmission times otherwise everyone will be trying to transmit at exactly the same time to our gateway and we will have some data collisions so we need to add a random period function into our app transmit duty cycle so we've got a section of code here which is going to give us a bit of randomization from our 10 seconds variant so it will give us a random number somewhere between 10 or 20 as it's between duty cycle and that duty cycle multiplied by 2 so that will give us a random element so this will remove any issues of everybody's board just happened to be all synchronized at transmitting at exactly the same time and remove potential data collisions within the network remember laura 1 is designed for low frequency low data rate transmissions in the training room we are going to get lots of people transmitting in a very short period of time so you can see a response that will cause problems because laura 1 is not designed for that so this is why we have to use this random element to try and reduce the risk of data collisions the next item we need to set is our default data rate so inside our region eu868.h file there are various data rates defined so we need to go and find the default data rate and set that to a value of five which will give us the shortest spreading factor so a spreading factor of seven and then that will reduce the time on air i think by default this value will be set to zero so therefore we will have a spreading factor of 12 which means everybody's message or the time on air from everybody's messages will be the maximum time we can get and that will potentially cause issues with collisions so we need to go and find this region eu868.h and change our default data rate so if we go and have a look for where that is located it's in the middlewares laura mac regions if we expand region eu868 we will find our region eu868.h file we are looking for our default data rate which is there so line 71 and we need to make sure that that is set to five so then we go back to our main.c file and we now need to go and create our two callbacks so we need to do our transmit callback and our rx callback so if we scroll down to user code section number three we will get our tx callback and you can find the software from the slides to paste in so here we're initializing our timer event we're setting the value for that timer event of 1000 which means our led will come on for one second and then we will start our timer in the same time we are preparing the payload for our transmission message so we select our port we select do we want a confirmed message we set the buffer size and scroll across you can see all the information and then we load our number with the relevant index into our buffer and then we do a printf statement to our terminal window so we can see what number we've actually sent out in our message then we scroll down a bit further to use a code begin number four and we can see our rx data callback and in this one we have a case statement based on the value of the information received so if the value depending on what the value is will depend on which led we light up and do we move our index on to our next element if we are too high or too low if we're equal we leave our point to where it is and we'll always send out the correct number at this point so so again this section of code can be copied from the slides into the laura rx data routine and then finally right down at the bottom we need to put our timer event routine in to switch our led off so this is after our one second we will switch our led off again and because we're going to violate the transmission rules the duty cycle rules in our hands on here we need to go and look in our laura dot c file and make sure we declare our laura one duty cycle as false remember when you publish your software this will need to be true so that you can comply with the rules of the regulators in whichever territory you're selling your products in but for our tests here we need to make sure that this is set to false so that we can actually do a hands-on within a sensible time frame so now we can go and compile our code so we can go project and build target my compiler will go off so zero errors and zero warnings and now we can program our board with the load button there so we can download our software into our discovery board so this may take a while as it has to go and erase the device before it can reprogram so our board is now programmed what we have going on in our application server is every time we send a message out the application server will receive the message it'll then do a comparison on the number and i ever tell you to increase decrease or it'll tell you that it's equal and then transmit the message back to your target node my debug messages will come through on my laura gateway debug terminal so that i will see every inbound message and what the response was for each inbound message so if i now go back to my terminal window change my settings to be one one five two hundred board rates if i now reset my board i can also see that i've done an over-the-air activation i can see my device id and the application id i want to talk to and the encryption key i have used to do this then you can see all the information that's going on so you can see the version number i was initializing joining eventually joined and now i'm starting to send out numbers so i'm now actually transmitting my messages out so if i now go into my gateway i can now go and change my unique number and now i wait and see if that i have selected the right number in the sequence to match one that is programmed into my board there eventually digit number eight is the one that's equal and on my target board now i now have a green led lit up to show that my board has hit the equal number and if we look at the camera view which is monitoring my debug screen i move that across so you can see the debug screen it refocuses you should be held to see on the left hand side all my transmissions that's are coming through so if i reset my board again you will hopefully start seeing different numbers come through at the moment there it's hit the equals one and it stops incrementing the indexer at that point so there we go so you can see number four has just come through in the bottom left hand corner now number five i think that says not very clear on the screen unfortunately then number seven telling me that i still need to increase so number two has come through now and eventually hopefully number eight should come through next and there you go number eight has come through and you can just about read the letter e has been replied back to the target board so you can see there that the debug window is tracking what's going on