Thank you. So I'll be talking about writing an interpreter in Python itself from scratch. So let's get rid of the hard question first. How to distinguish between the different prompts during the demo? Because we have Python and we're writing Python in it, so we're not going to know where we are. So I'm going to use iPython for the regular Python interpreter. So if you see in bracket, number of bracket, that means we're in the regular Python interpreter. And if you see p greater, greater, then we are in our interpreter, the one we're trying to write. Okay, so then let me clarify a bit what I mean by from scratch. So we're not going to use exec eval, of course that would be too easy, or even the ast module for interpreting, and we're not going to use any of the existing internal libraries or external tools for parsing either. Actually, but we are going to use Python strings, Python lists, and all the functions associated with those. So let me just show you what the interpreter looks like now so we get a better idea. So you can't hear? Can I hear me now? Okay, so we're in the interpreter here, so let's try some simple things. X equals 3, and then maybe print X, we're in Python 2 here, you print, I don't need parentheses. And oh, we got an error with a terrible way to start the demo. Of course, this is deliberate. So also now you can distinguish between when we are in one interpreter and the other, right? So we had p greater than here and here I have in. So let me hit this and restart the same thing. And now what I'm going to do is as a first line, I'm going to write simple, simple ast. So simple it works more or less like import, but I'm going to explain how that works slightly later on. So now if I do the same demo, so print X, I don't get an error and it prints 3 as expected. The command something is just for debugging. Let me move that a bit higher. Okay, and to get an idea of the scope of what the interpreter can do, let me just compute the squares of all odd numbers between 1 and 5 and see that it gives me the right result when 1925 here. Okay, so also for those of you for whom writing a Python interpreter is too boring, you can try to figure out before the second half of the talk why it gave me an error. If I didn't run that first line and why it did not give me an error afterwards, I mean, it's not just a if check that says if you didn't run this magical thing, then give a deliberate error. Okay, so we want to write a Python interpreter and so the user is going to write something in the file, like commands in a file or in the repo as we've seen here, so something like X equals f of 3, but we don't want to treat this as a string all the time, although in theory it would be possible. So the first thing we usually want to do is just turn this thing into a data structure that's more malleable for execution. So and that's an abstract syntax tree which we have on the bottom left there. So for this statement we have as a root a regular assignment node and with the first child which is a name node with the value X, the second child is a call node which itself has two children, name node f and an argument list node arg list with a single argument number three. So an abstract syntax tree is just a tree like this where each node has some kind of name like regular assignment call arg list and so on. And if you see it in the console during the demo, you're going to see what's on the right, so this is the textual representation of the same tree on the left we have there. Okay so to write our interpreter we're going to have two steps. So the first step is parsing, we're going to turn Python source code into an abstract syntax tree as we've just seen and in the second step we're going to take this abstract syntax tree and run it, so run the corresponding program. Okay so let's start with the first step parsing. So of course I'm only going to give glimpses of this because there's many parts to this interpreter. So for parsing right so that's when we want to transform text into the abstract syntax tree. So the core of it is an algorithm which takes as first input a description of a language so in this case Python I'll come to that so I'll describe that in a bit more detail and a bit a second input some piece of text right which we think of as the source code and which gives us either an abstract syntax tree or a syntax error if the second input string didn't match the grammar which was given there. Okay so I'm going to call this a grammar matcher and we see a black box here because the idea I won't have time to go into detail of how that's going to work. Okay and usually so for the black box that I'm not going to talk about this steps involves you know multiple sub steps like tokenizing lexing parsing and so on but actually in this implementation we'll just have one step so to go from these two inputs to the output we want. So let me talk a bit about the grammar so actually the grammar we have to give as first input is also going to be represented as an abstract syntax tree it's just an abstract syntax tree for describing some language. It also usually has a textual representation which can be turned into this right so the main function we're going to use for parsing is this so it takes an abstract syntax tree piece of text and turn it into the abstract syntax tree of the second input. Okay so maybe it's easier so normally this is sort of the textual representation of the grammar which I'm not going to go into detail about but this is the piece of text we're going to start off with so let me just show you how the parsing works. So let me exit here so I'm going to run the first few lines of the demo we've seen earlier so let's import some stuff from our library and here I'm defining a function a match function which corresponds to that black box we've seen I'm defining it here just so that it looks more like what was already on the slide oops so here I have a piece of text I've imported right it's like about 20 lines and it's going to describe a first language that we're going to turn into a tree okay and we have some kind of start tree so I'm not going to show you what this is and now the first step is we're going to match right so this is the black box we have here the first input is this start tree which I'm not going to show you yet and the second input is this grammar which is just this piece of text and now match tree should be a tree which corresponds to this piece of text so let's see what's in there right so now we have an abstract syntax tree as I've shown earlier except that this is a tree describing a language instead of a tree describing a Python program right and so one interesting thing here is now I'm going to show you what was in start tree right which was imported and it looks exactly the same in fact if you check this start tree equals match tree they're actually exactly equal right so the only information contained in start tree is that piece of text but in the tree form okay so this was unnecessary because we already had start tree we could have just used that so I'm going to in the second step I'm going to pass so give as first input the match tree we got in the first step and as second input the grammar we had so the piece of text we had plus some extra stuff so I can show you what that is but it's not oops that's not too important okay and as third step we're going to take what we had from the second step and give it as first input and then as second input we're going to have something that actually describes the Python programming language so let me show you what that piece of text is okay so this is again you know because Python is still fairly complicated as a language so we have lots of things in this piece of text actually something similar is in the C Python source so you can see something very similar in there so maybe let me just focus on a few things so here we have file input right so if you want to parse a file and it just says well what's the file input it's just either an empty line or some indent followed by a statement and repeated many times the star is some kind of regular expression repetition star and a statement is just a compound statement or a simple statement a simple statement is just small statements separated by semicolons and the small statement is either a print statement the delete statement the pass statement that's all one and let's just take a look at so a pass statement it's just the the string pass followed by nothing a delete statement it's just a string delete followed by some spaces followed by a least list of expressions it's all okay so you have this entire string which is going to describe the Python programming language and now we have the string in the tree form in match tree three okay so let's actually try to parse some Python program so again this is we're going to use a slightly more advanced black box although we could have used this one the entire way instead of match and we're going to try to parse this file and to parse it well we actually just do exactly the same thing so we run match and as first input we give it the tree describing the Python programming language and as second input we give it the text which is the content of the file and now if we look at this file oops yeah so it's what you expect from a Python program right so we have regular assigned as in the example we had in the very beginning okay so that's all I'm going to talk about for the pricing parsing part but I should mention that so the black box isn't that complicated actually the entire thing isn't that complicated so if we could just take everything in the parsing library and put it into a file which is about 510 lines of Python and that file is able to parse itself so let me maybe show you that now so this is the file single file right so 508 lines this is actually this part you don't need to read this is sort of like the start tree which and this is all the strings we had in there and in the beginning you actually have you know the semantics of how like what to do was each of these trees right like the match function which was in there okay so let me just run it see that right so here it parsed itself and it gave itself as an abstract syntax tree just to show that parsing worked right so this is you know what we had at the very end here so this looks like that okay and the bootstrapping part so the part where we started that fits in about 120 lines maybe a few things that were interesting so the thing which allows us to do this in a single step instead of what it says is the fact that we're using a parser expression grammar instead of one of the other grammars and the other thing which is interesting is that this parser is a parser interpreter in some sense it's not a parser generator right we're just making abstract syntax trees but we're never generating Python code for parsing the next step okay so that's all I'm going to say about the parsing part so if you get lost you can wake up again and I'm going to talk about running now so let's assume that if the user types some text we can have it in some kind of tree which is representative of the program and now we just want to run it okay so did anybody think about that simport puzzle at the beginning so why did it give an error if I didn't run simport which runs more or less like import and why did not give an error if I did that okay so let me give the answer to that right now so simple st.py right so if you were trying to import simple st then it would look for this file it contains the phone following a function definition so it defines a function which is called print statement which takes a single argument and then does the right thing to print its content so what happened here is actually that some of the semantics for the abstract syntax notes for so for how we're supposed to run it they're not included in the core of the running part of the interpreter they're actually included in the library so since they're in the library if you don't import them the interpreter doesn't know what to do with them right so they're actually going to be run through our interpreter instead of being hard coded into the interpreter okay so let's see another example so this was print statement right so let's look at end test right so if you have some if you're writing some condition and some other condition how are we supposed to run this well there's a function defined in there which is called end test which takes two parameters right so the first argument so which we think about as the first argument and the second argument but actually the argument it receives are the children in the abstract syntax tree right and so this one it just if the first argument evaluates to true and then we try to evaluate the second argument and if that's a value is true we return true and otherwise we return false right so this corresponds to our run of n okay so let me now that we've seen two examples let me go into the details of how the main loop so here's a slightly simplified version of how the running part of the interpreter works in its main loop so it initializes the scope at first so some environment with your globals in there then it initializes the stack with a single element in there right a single frame which just contains the root of the file we are trying to run and then it just goes into this while loop so it looks at the top of the stack and it looks at the name of the node at the top of the stack if it's in some module called boot then it just calls that function in boot passing a star node so passing the children of that node as argument to that function otherwise it looks in simple st and so if there is a module called simple st and there is a function corresponding to the node's name then it just calls that function and passes the children and otherwise it looks into the built-in so the things hardcoded into the interpreter and if it finds that then it calls that function and passes the children of the node and otherwise that's in there so that's the first error we've seen okay so let's look at okay so let's look at some more examples uh so if statement so this is normally something you would need hardcoded in but actually uh we're going to be able to get away with having it in the library instead of in the core of the running interpreter so and if statement just has a list of pairs of conditions and blocks and if uh so we go through all these conditions and blocks in order and if a condition evaluates true then we evaluate the block and return it oh and by the way evaluate as a function we're restricted this main loop all it does it just adds that node at the top of the stack it doesn't really do anything else and then the main loop will take care of evaluating anything as expected okay so let's take look take a look at fourth statement so fourth statement well there's an index variable some iterable and then the block we want to execute and maybe some kind of else block in some cases when we want to execute a block of code if we didn't break from the loop and so the loop just works this way so evaluate this iterable take an iterator of it right iterator of it so this gives you an iterator and then run the following indefinitely so try to assign the next value of the iterator to the index variable so here we can't do index r equals iterator dot next because that would assign the value of iterator dot next in the wrong scope it would assign it in the scope of the fourth statement function whereas we wanted in the function which calls it and if we we do this until we get a so sorry we assign iterator dot next to the index variable and then we just run the block evaluate block at the bottom and we do this until we get a stop iteration right which means iterator dot next ran out of values here and then we just check run the else block if there was one and then return okay and so let's look at one more example so try statement well try statement it's just a block and then a bunch of exceptions right so some list of of exceptions we're looking for and the block to run if we catch that exception so it just works like this evaluate the block and if we catch some kind of exception well let's put it in a variable called error and then just check it against each of the clauses that the that try statement is trying to check against and if we find one then just evaluate that exception block and return and stop checking for the others and otherwise just keep going okay so does anybody notice any problems with the last three definition we have seen here so if we have this thing in the library what's going to happen is that this is going to loop indefinitely because when we translate this function into an abstract syntax tree so the first thing in this function is going to be a try statement node and if we think about our loop for that try statement node well it's going to look in simple st for a function called try statement and it's going to call it with its children but that's this function so it's going to call itself and then it's going to call itself so it's never actually going to run anything right so the call graph actually this was a problem with its statement also right so our definition of its statement included in if and so if we include it in library it's just going to call itself there which and loop indefinitely so that's not what we want right the call graph looks like this try statement calls itself if statements calls itself for statements calls both of the two others which calls it back so that's going to also loop indefinitely so it seems we are a bit in a bind in a bit of a bind here right so where what we are actually going to do is um we are so one way would be just to put all of this uh coded into the interpreter right so if he this was run in c python it would be okay because the try statement inside would be run in c python uh but then actually evaluate is going to be hard to implement because currently evaluate just adds uh the node we put there at the top of the sack and then what it's supposed to do is run a few iterations of the main loop and then when it's done we extract the return value and do something with that so if we have a python function inside the interpreter there then when we run evaluate we have to exit that function and then when evaluated it's done after a few iterations of the main loop we have to come back so we have to do some fancy state tracking uh even if we wanted to put this into the core of our interpreter okay so uh what the actual solution we're going to use is the following so uh we're going to write three more functions which are simpler versions of the three we've seen so instead of so the simpler version of this statement is single statement which is only able to handle a single block the simpler version of four statement is simple four statement which is only able to handle iterations which are indexable and the simpler version of trice statement is trice statement error which only handles uh so only does the second part when an exception happens so the first part we're actually going to run it inside the core and actually there was also a while true there so we'll also have a simpler version of while which is only able to do while true so this is what a single if looks like so it's only able to take one condition and one block and then it evaluates the condition uh turn it into a boolean checks so we built a dictionary here such that if that boolean is true then we'll evaluate the block that was passed here uh so this is some kind of a bit of a small talk inspired function and if it falls then it just evaluates a block which contains a single pass statement which basically just does nothing right so that's the definition of single if uh here's the definition of simple four right so simple four uh takes so it takes no else block it still takes an index variable and the block and uh here we assume that the iterable is indexable so then we can have an index variable which starts at zero we evaluate the iterable evaluates its length and then do the assignments we had before evaluate the block just increment the index and then check if we have attained the length and in that case just return from this function right because that should be the end of the loop okay and trice statement error is more or less the same thing as we had uh in trice statement right so the last few lines of trice statement that stays the same there's no problem here uh but here you can see that is calling simple four instead of four right there's no simple four statement in Python normally and uh we should also write single if instead of if on this cert line here but actually uh we'll just uh delegate that to the parser so when the parser sees that an if statement only has a single block it's going to put a single if abstract syntax re node instead of an if statement abstract syntax node syntax node okay so here's the new call graph again right so by doing this we're able to put all of these things in the library instead of in the core of the interpreter okay so i want to talk about one last thing and that's postmortem debugging so here i have a file that i'm going to run which is buggy right here there's a typo ii and there's two total which should be total so let me run this uh in c python first so the right the python interpreter we're used to okay so we got an error here as accepted right it printed the first few iterations and then we got an error at the first error so uh normally in regular python what we can do when we get an error is uh import pdb so the python debugger module i think someone's going to talk about this later and we can import this and run pdb.pm so uh for postmortem debugging and if we run this uh we'll get the python debugger uh interpreted here and now we can look at the values at the last error we got right so we can print i print total and if we had function calls we could go up and down the stack so that we can evaluate expressions in different uh context okay so that's uh how postmortem debugging works uh in python normally so let's see how postmortem debugging works uh in our interpreters test so i'm going to oh whoops uh i forgot to uncomment simple simple way import simple asc so let's do that again okay so it it prints the first few lines like regular python and then we got this error it's this key error because it's tries to find this variable ii in scope and can't find it so let's first see a uh stack trace of this right so here you can uh as a demonstration you can also see that it arsenates between going into this uh erroneous file and this lib slash simple st so that's what we've been talking about right so it's currently in the augmented assign function because it's trying to run total plus equals ii and then you can see uh you know it also has uh column indent instead of line indent okay so let's uh look at the last stack frame where we got this error so here's the node associated with it right so it says name ii and that's wrong so let's try to fix that right so the correct uh value is i and now what we're going to do is just continue so now we hit the second error but before that it printed total which means it passed by this line but it didn't print all the rest of the stuff so it really did just continue so let's examine this one and fix it too and continue right so and now it goes along its way and also in the last iteration it didn't hit this bug which we already fixed right so this is something which as far as i know you cannot do uh with just a regular Python debugger okay uh so uh here so just to say that you know everything i've shown today even though i didn't show you all the details isn't that complicated so here's the current line count and as i've mentioned the first part for parsing if you only wanted parsing you could have just had all of that uh in about 500 and 10 lines instead so we tried i tried to move as much as possible uh into the library and of course it's not fully featured right now but maybe as the last thing to show you i can show you that it's able to run its own uh parser in itself so this is probably going to take some time so maybe let me just mention that uh this project is looking for help so please talk to me uh here so where i mean we by we i mean me i'm mainly interested in reducing the complexity of everything we have here right so reducing these number of parser uh and also reducing the dependency on cpython and make more steps sort of self-generating right so you know uh each of these library functions like simple if helped us make if statement and so on so have more things created in steps like that uh okay so it almost started here so here's uh this was just some test to see if my implementation of objects work so here it is right so now it's trying to parse itself so it's matching things from the beginning uh i see so the index here the number is just the index in the input of course this is going to be very slow right i'm running an interpreter inside another interpreter and actually the parser is also uh sort of a parser interpreter instead of a parser generator so of course it's very slow uh it's not going to end so i'm going to just stop it here okay so that's all i wanted to say thank you anybody has questions so this is part of something bigger i guess i showed it like two months ago so so i guess i want to so uh first of all so this is so that it's possible to experiment with changes to the programming like it's more easily and so other like if you wanted to do that with c plus on you have to add things in multiple places in the source and then recompile every time you want to test out the change and here since it's all in plus on you can sort of just test it out right away right you don't even need to exit the interpreter in theory uh but it's actually also to write something else i guess uh with a graphical layer uh after this so to make changes so that the next step is easier to write or can be right written in a more succinct and natural way though well actually i mean the new statements are actually just for bootstrapping for now right like simple live for uh single single live for a simple four statement uh i haven't added anything i mean the thing i wanted to add is actually this debugging thing and also uh late binding so you know change how class lookup works so that i can reload my class definitions so that all my instances use the new definition uh but i haven't added anything else in you know any particular statement but it's made so that it's easy for anybody else to add new statements so for the python part yes so this is i mean it's derived from the uh python two grammar in the source it's at this part so it's i mean if you look at the one in the python source i mean it's of course not exactly the same thing and also the handle intends slightly differently uh but otherwise it looks more or less the same except you know for things we uh i talked about right like a single if things like that which are here which are of course not in the normal by cell interpreter in the back the future of python sorry do you intend to spur all the future of python life generator dictionary completion uh so there's dictionaries so though so the primary goal isn't to have all the features of python it's really to make it so that experimenting with languages is easier and to get a shorter description of the interpreter right maybe a subset but a subset where it's easy to add new things right because now that even the abstract syntax is right so generators for example are not there but if you wanted them then you could just add a definition in the library at some point and then just get that but the primary goal isn't to be fully python compatible no so thank you


1. Human mesenchymal stem cells, MSCs, communicate with other cells in the body and respond to signals of cellular damage by migrating to areas of injury. 2. The migration of MSCs is facilitated by favourable cellular conditions and the in-vivo environment, which are required for effective homing. 3. Strategies for enhancing both environmental and cellular conditions can improve the homing of MSCs, allowing them to quickly find and migrate to injured tissues where they may exert clinical benefits. 4. This article was authored by Sun Kim Kang, Illinois C-Option, Myeong-Soon K-O, and others.


And welcome back to BUTV News. Big night in hockey last night. Lauren, what can you tell us? It was a big night last night. We didn't get to see the men's beanpot final, but the women's team brought home a win for BU. In last night's consolation game, the number seven women terriers defeated northeastern three to one. It was a close game all night, but the terriers persevered. Harvard snatched the women's beanpot from defending champion Boston College with a close three to two win. Last time number four Harvard won was back in 2010. We'll have more beanpot coverage for you in two weeks. When BU and northeastern go head-to-head for the men's beanpot championship.


Over the past half-century, more and more supposed Western Islamic historians have been attempting to revise traditional Muslim narratives, and their attempts are focused on weakening the foundations of Islam by introducing doubt on its most important persona, the Prophet Muhammad. And what are they trying to prove? Uncertainty, of course, but not with regard to the details of his lifetime, nor his teachings or actions, but something much more destructive. An uncertainty towards his existence. Trying to question whether there ever was a Messenger of God who lived in the 7th century CE who received the Qur'an and who, as the Seal of Prophets, eventually spearheaded the foundations of the religion of Islam. Revisionist history justifies itself by claiming that the Prophet Muhammad was a mystical persona created much later in the development of Islam, almost a full two centuries after his supposed lifetime. These historians state that there is no tangible proof within the lifetime of the Prophet that links to his major role and involvement with the foundation of the Islamic faith and teachings. As per their investigations, the earliest references to Muhammad come almost 150 years after his death. These historians discount many Muslim writings that traditionally have provided substantial credibility as well as the many references to the Prophet in the various documented Hadiths handed down over the generations through proven oral tradition. In such evidence, they consider as unreliable as they categorize it, more in line with hearsay at the very best. And to top it all off, this group of skeptics also ignore the many sources that do indeed prove the existence of the Prophet, be it from an archaeological evidence perspective or proven non-Muslim written documentation. So what I'll be presenting to you in this video is proof that refutes the idea that the Prophet Muhammad never existed, or was some mystical fabrication of history. And to do that, we won't need to dive into the various and hundreds of Muslim scholars and their writings, who from the mid eighth century onwards generated in-depth knowledge about the Prophet, his sayings, and his life. But first, let us recount the basics of the life of the Prophet Muhammad. He was born in 570 CE within the family of Quraish and Mecca in Arabia. At the age of 40, he would receive the first of many revelations by the angel Gabriel of the Qur'an, the word of God. And three years later would begin his preaching of the monotheistic faith, the singularity of God, and submission to Allah. In his lifetime and in accordance with his teachings and practices, the Islamic faith would spread across the Arabian Peninsula, and in 632 CE, at the age of 61, he would pass away. So as I said, we won't need to go into the contentious historical narratives and their supposed inaccuracies that contradicted a unified narrative of the Prophet's biography. Nor will we need to explore the many hadiths that recorded the Prophet's teachings since they are, as per Western revisionists, orally handed down in an imprecise manner. What we will get into, though, are tangible proofs that include contemporaneous Islamic documents, archaeological evidence, as well as non-Muslim writings. Although this document doesn't exist in its original state, the Constitution of Medina has been referenced by many subsequent Muslim historians, as well as Western scholars who widely accept the authenticity of this text. The Constitution is a set of documents that established governance of tribal affairs during the Prophet Muhammad's time in Medina, and it established a kind of alliance or federation between the various tribes of the city, including non-Muslim communities. And of course, this document lists Muhammad by name numerous times, as well as identifies him as both messenger of God and as the leading mediator between the various tribes. The Quran, as we know it today, was compiled in its final and comprehensive written form well after the passing of the Prophet, by approximately 30 years. Note that the Quran mostly is a series of verses that deals with the creation, history of prophets, singularity of Allah, and submission to him. It rarely relates to contemporary times of the 6th century, yet still, the Quran is a vital source in locating the Prophet in history, as it mentions his name within certain verses. Muhammad, as a proper name, is mentioned four times, as well as another 27 times when referencing his titles, Prophet, Messenger of God, and others. One such physical archaeological authentication within the Quran referencing the Prophet Muhammad is the Birmingham Quran manuscript. It's a single sheet of parchment of which two leaves of an early Quranic manuscript has been written. In 2015, the manuscript which is held by the University of Birmingham was radiocarbon dated to between 568 and 645 CE. This text in the parchment calls on Taha, an early and common title for Muhammad. Beyond Islamic written proof are the instances of archaeological evidence that exhibit the existence of the Prophet Muhammad. The first comes in the form of etchings found on the walls of Mount Salah, just outside Medina. The site where these etchings were found are in the same location as the historic Battle of the Khandaq, or Battle of the Trench, in 627 CE. When Muslim armies overcame the armies of the anti-Islamic Quraish tribe and their allies. The inscription reads, I am Muhammad ibn Abdullah. I am Salman al-Farisi. I am Sa'ad ibn Mu'ath. I am Ali ibn Abi Talib. The names listed in such a grouping complements the historic and traditional Islamic narrative that tells of the leaders of the Muslim army that achieved victory in battle. Here the Prophet is named clearly with his companions. The Dome of the Rock, one of Islam's most important shrines at the center of the Aqsa mosque compound in the old city of Jerusalem, is the world's oldest surviving work of Islamic architecture. Built by the Khalifa Abdul Malik during the Umayyad period in 691 to 692 CE, it contained inscriptions that are the earliest epic graphic proclamations of the Prophet Muhammad. Other forms of confirmation of the Prophet's existence come in the form of minted coins in the mid to late 7th century. In the year 696 CE, the first Umayyad golden hour was struck, heralding the birth of a new purely Islamic coinage and his further documentation of the existence of the Prophet Muhammad, as his name and title were included on the many variations of coins in circulation at the time. The final element that confirms the life of Muhammad in the 6th and 7th century is the abundance of non-Muslim writings during that era, which references him by name, title and deed. The Chronicle of 640, written by Thomas the Presbyter, a Syriac Orthodox priest from the vicinity of Reshena in Upper Mesopotamia, records the happenings of a battle between the Muslims and the Romans. Although dead for two years, the Muslim army is referenced as the Arabs of Muhammad. On Friday, the 4th of February 634 CE, at the 9th hour, there was a battle between the Romans and the Arabs of Muhammad in Palestine, 12 miles east of Gaza. The Romans fled, leaving behind the patrician Jordan, whom the Arabs killed. Another written piece of evidence of Muhammad's life are the fragments on the Arab conquests. These are notes that were written around the year 636 CE on the front blank pages of a 6th century Syriac Christian manuscript of the Gospel of Mark. The fragments depict events from the early 7th century conflict between the Byzantines and the Arabs of Muhammad, particularly at the Battle of Yarmouk. And in January, they took the word for the lives of the sons of Emesa, and many villages were ruined with the killing by the Arabs of Muhammad, and a great number of people were killed and captives were taken from Galilee. Another account of the early 7th century comes from Sebyos, an Armenian bishop of the house of Bakruti. At that time, a certain man from along those same sons of Ismail, whose name was Muhammad, a merchant, as if by God's command appeared to them as a preacher and the path of truth. He taught them to recognize the God of Abraham, especially because he was learned and informed in the history of Moses. So, Muhammad legislated for them not to eat carrion, not to drink wine, not to speak falsely, and not to engage in fornication. These are but some of the non-Muslim historic writings that do indeed confirm the life of Muhammad, as well as highlight his leadership and substantial following. One could go on listing many more examples of such facts and add to the substantial evidence of Muhammad's life. But there are more complexities that confront Western revisionists and their intentions to discredit the traditional Islamic narrative and faith. For example, genealogy is a very powerful tool that in modernity can confirm the existence of ancestral lineage all the way back to the Prophet. Indeed, many families in existence in the Arab world can date their ancestry to the house of the Prophet. Another obstacle that debunks the concept of Muhammad as myth are the many proofs of the existence of his family, companions as well as his enemies, whose existence in history all include detailed narratives of his story. And the final nail in the coffin of these missionary propagandists and their attempt to rock the foundations of Islam is to simply look at the state of the Islamic nation in the decades that followed the passing of the Prophet. The nation was in disarray. In fighting and revolt amongst the fledgling religion was a bitter reality.  How can Muslims agree on the life of a single man in its full detail and account while they could not agree on the religion itself? How? Unless it was all true. At the end of it all, this listing of evidence and theoretical gesticulation is insignificant and unnecessary. Today, approximately two billion people across the world are Muslim. Every single one of them know in their heart of hearts that Muhammad existed, and that he was the messenger of God. The power of faith and belief far outweigh the necessity for proof and documentation. No Western revisionist or their attempts to belittle Muhammad's impact on Islam or history have a minute chance of being heard. And maybe that's where the core of the problem lies, with a need to evidence everything, to have proof, to doubt faith and the power of belief, to see so that one can believe. Blessed are those who had faith in me and saw me, and blessed seven times are those who had faith in me and never saw me.


Okay, so welcome to the session. We'll talk a little bit about how to build multi-protocol IoT nodes with a specific focus to those three protocols over there, so Thread, BLE, and ZigBee. And here's the summary of the session. So we're going to talk about the advantages of the benefits of developing such IoT systems with a focus to new platforms that make it feasible to implement such multi-protocol system, also at the edge node of IoT, so not only in a gateway. We'll summarize a little bit the main use cases for the different protocol standards, focusing on those three, but some use cases, and go a little bit deeper into the anatomy of such systems. So we'll look at the platforms, the stacks that are being used there, some considerations for applications if you're building a multi-protocol device. And finally, we'll do some examples at the end where we'll actually work with actual development hardware and firmware and software and see how such a system behaves. Okay, first a little bit about myself. My name is Alain Lazar. I'm a software engineering manager with NXP Semiconductors. I've been working with low power wireless protocols for about 10 years now. I've been involved during this time in shipping stacks, tools, application software that deals with ZigBee threat and BLE stacks, focusing a lot also on the standardization and the certification aspect with respect to interoperability, so multi-vendor interoperability with respect to these standards. And right now I'm also serving as a vice-chair of the Thread Group Technical Committee. So let's get into it. So let's first understand why it would be good to have a system that implements multiple protocols. So there are about three main reasons for doing that. And again, we're talking and focusing on the edge node here, so not necessarily on the gateway. First of all, it greatly expands the connectivity, so basically the number of devices and the number of networks that an IoT device can actually connect to. So if you implement, for instance, one of the standards, let's say, BLE can connect to smart for other BLE devices, but also if you implement one of the other standards, then it's possible to connect to mesh networks and other such devices. So it greatly expands and makes it very flexible to add multiple connectivity, multiple direct connectivity ways of an IoT edge node device. And with that comes a reduction in design costs. So just think about the fact that if you're building an IoT device and maybe it's a BLE and then you implement another standard, you don't need to do two different SKUs. So you just do one SKU with potentially a single firmware build.  And this can greatly make such a design advantage just from a cost perspective. And finally, with such systems, that in multiple protocols, usually you get some processing associated with them, also some security features. So what that gets you is actually for the application, it blurs the radio interface. So it doesn't matter too much whether you're doing BLE or ZigBee or Thread or some of the other protocols at the application level is just a firmware decision of those interfaces you use. So basically it's choosing the best of all worlds. So a lot of these protocol standards have some strengths and some weaknesses. So it's basically exploiting a lot of the current strengths with such a multi-proc system. So also future-proofing your design and reducing a lock-in in a certain vertical, let's say, as it's being deployed now. So let's look at these three protocol standards that are the focus of our session. So how many of you have worked with Bluetooth flow energy or did Bluetooth flow energy designs? Okay, quite a few. How about ZigBee? Okay, and Thread. Okay, got one for Thread. Okay, so let's go a little bit through their main points and, again, strengths and weaknesses. So Bluetooth First, so we're talking here mainly about Bluetooth LE used in IoT devices. We usually use that to connect your accessory or your wearable device to a smartphone or a PC or a tablet. It's very good for devices that don't have user interfaces to go to your mobile app and use that as the user interface for the IoT device. It's mainly direct connections from your smart device to that accessory. Also, we've seen a lot of usage of Bealeen in Beacons. ZigBee has been with us for quite a number of years. I think the initial development of the protocol started early 2001, 2002. It's quite a mature mesh protocol focused on home automation and lighting deployments. So right now I think there's a few hundreds of ZigBee devices which are certified in those areas, so mainly home automation lighting. ZigBee also had some attempts to go also into the smart grid markets. They've got a smart energy profile, that works. But mostly the focus and especially the newest version of the standard gets dubbed ZigBee 3.0. A lot of that is focused on home automation and lighting. A lot of the current smart home hubs, which you can buy in retail, come with a ZigBee radio and those certified devices can interact with that ZigBee radio. What about Thread? Thread is a newer protocol. It's being defined by the Thread group. It's reusing the Mac 5, so the layer 1, layer 2, I888 or do 15.4 that ZigBee is also using. But what it does, it defines a full IPv6 network stack on top of that. That IPv6 network stack is built in the Thread standard to also scale at the same category of devices that Bluetooth and ZigBee cover. So these very small IoT devices like a coin cell battery device. Also, Thread improves a little bit the mesh concept from the other protocols in that it's no single point of failure mesh network. So if the gateway or one of the main routers in the network that coordinates the routing and maintains the network as a whole is decommissioned or is turned off, then other routers can take over for some of those more centralized functions in the other protocols. So that makes Thread network overall and Thread mesh networks a little bit more resilient. Also, being IPv6, Thread goes and defines border router architecture. So border router are gateway type devices at the edge. So it could be a networking device, but it could also be appliance device. And those devices are multi-procalling that they implement also an interface like Wi-Fi or Ethernet and the Thread IEEE 8.15.4 radio. And then you can actually send IP packets from the Edge node, IPv6 Edge node up to maybe a mobile device in the LAN through Wi-Fi or further on to the cloud. So all these three protocol standards are open standards. So they're being developed by industry standard groups like the Bluetooth sync, the ZigBee Alliance and the Thread group. So all of them are similar from this perspective in that you need to be a member in order to be able to influence the specification and get access to the interoperability and certification program. So these alliances basically offer a set of tools or a full certification program in order to ensure that your devices work together seamlessly. Yeah, sure. So we're focusing on these three as part of this talk. I have some points at the end that touch a little bit on those items that you mentioned. So ZigFox and Laura are basically wide area, low power networks. They're implemented in some ways with different platforms that these, the platforms that implement these three protocols. And then Z-Wave is similar in that due to the fact that it's using another frequency band, it's a little bit difficult to build very integrated systems that also add Z-Wave. So it's mainly all these three protocols that I'm listing here are in the 2.4 gigahertz band. So they operate globally. So again, you just need to do one hardware design and that works globally as part of the 2.4 band. So that's, again, one of the advantage here. But that doesn't preclude using those scenarios. We're focusing on these three in this talk because we're going to see a little bit on how the integration goes and you actually have all these three protocols in a single chip. Okay, so let's look at a use case for how you would get the benefit of having two or three of these standards in your single device. So let's imagine you have your mesh network here, a home automation network or maybe a different type of network. So you've got these router devices, the orange hexagons over there, the end nodes. They all form a mesh network and communicate as part of the mesh. And let's say you've got a home automation network and you've got a connected smart lock. So that mesh today may be implemented with ZigBee or Thread. But if you also implement Bluetooth in that smart lock device, then you can go and meet such use cases where the user interacts via their smart phone or their smart watch or their wearable directly via BLE to that node. So outside the band of the main mesh network. But at the same time, the device continues to operate and be controlled in the mesh. So let's say that the smart lock implements Thread and it also has an IPv6 address that it can be used to communicate with a cloud device management service. At the same time, with its BLE operation, which allows a more seamless operation by users for when they actually need to talk to that smart lock or need to interact with that device. So basically, the multi-protocol implementation facilitates these kind of new interaction scenarios where multiple standards are combined and some of their strengths are exploited. Okay, so let's see how one would go and build such a device. So what do you need first? So right now we see an emergence of integrated microcontroller that have multi-mode radios and those really stand at the base of the multi-protocol systems that implement such standards as we saw earlier. And actually there have been quite a bit of those released lately. So NXP has one of them, the schematic is pictured here, but a lot of our competitors also have very similar devices. So what's common among these devices is that they usually implement an ARM Cortex-M as a main processing unit and that's usually implemented in the same silicon package as a system on a chip with a multi-mode radio. Usually the multi-mode radio in most cases is BLE-4 plus capable and I888-15.4 capable, which means that it can implement those three standards that I mentioned earlier and that's one of the reasons. There are some similarities because these all operate in 2.4 so it's pretty easy to actually these build this multi-mode radio and integrate it with a processing core. These devices usually differentiate through their memory capacity, pretty standard memory for the microcontroller core for instance, 512K of flash, 128K of RAM. So we see maybe on the RAM side an increase versus what people were usually using up until a year or so ago just because for some of these multi-procal use cases the RAM is very helpful to do things like packet buffering and be able to run several of the stacks concurrently which need both the flash and RAM for storing state and tables and also allow some space for the application. And usually also have a set of security blocks integrated so you'll have some commonalities also with that because a lot of these standards reuse AES-128 and random number generator because of the way you can actually implement true random number generators. Okay so that's the first step of having such a platform. Then going to the firmware. You need a multi-procal stack, right? So you've got pictured here the high-level architecture of how such a stack would look like. So at the bottom we've got a multi-mode transceiver as we mentioned and because the Zigbian thread reuse the IEEE to 15.4MAC5 you only need one implementation of that. That runs in parallel or is the same layer in the protocol maybe with a BLE controller. And then going further up in the stack layers we've got a BLE host, GAP, JTT profiles on the BLE site so this is pretty much its own vertical these days. And then similar for ZigBee, for ZigBee 3 and previous versions you'll have a ZigBee Pro mesh layer that does some of the base networking and then got a ZigBee cluster library framework that does some of the application semantics around application functionality. And then thread is an IPv6 stack that's made for constrained devices so it reuses 6LowPan as defined by ITF and then it adds IPv6-based routing for the mesh side. But then on top of that you've got a pretty standard IPv6 and UDP socket layer so the application can interact pretty seamlessly in the usual IP way with that. What's regularly built on top of that though is other application layer frameworks that are made for constrained devices such as those based on co-app. So we've got these blocks of the stack layer and then the application layer can have the single chip device application that can actually take advantage of all the flexibility that the stack layer offers. So for instance if the application for that IoT device demands that you will get some UI display to a user for a short time then it will enable the BLE stack. So it will enable that and the user will get a user interface on its smartphone. It needs to be active in a mesh and communicate to smart blocks of lights that it might enable the ZigBee interface. We've got IP scenarios where it communicates to a cloud or other thread devices than that we implement the thread. You can actually mix and match so all these are usually implemented as pretty modular blocks and as we'll see a bit later can also be coordinated in order to run concurrently. A few considerations on such multi-mode application, multi-protocol application. So I have a set of items that are relevant in this case. So first on the firmware system. So the firmware system perhaps as we saw in the stack picture has a bit more complexity just because you need to manage all these items. For item cyber you usually only need to build a single piece of firmware even though your device, a single piece of firmware for these multiple ROCCOs instead of doing maybe a multi-chip scenario where you need to have different firmware for each of the chips that are in the system. An RTOS usually helps here because what you could do is run some of the, especially the lower layers such as the PLE controller such as the MAC-FI, also the upper layers in different RTOS stacks and exploit the advantages that an RTOS brings with this. But a bare metal system is also an option. Then what you also have in terms of firmware is some sort of management module that allows the concurrency management. So if you do want to use multiple of those protocols at the same time at runtime basically so choose dynamically between those then you need to manage their concurrency or their coexistence. Depending on the category of the device whether it's a battery powered, sleepy device or maybe it's a mains powered, that's kind of a smart plug or another light bulb let's say that doesn't have that much constraints on the power side. So what you can do is actually that could implement one of the router functions in the protocols that allow it. However, the messaging pattern of the device of how often do they transmit, whether there are sleepy devices which pull their pattern, whether there are sleepy BLE devices which for instance in some cases establish connections and then detach from that connection. All these communication patterns need to be considered in order to take advantage of the concurrency management APIs and the application kind of coordinate between these. OTA updates, it's probably in such a system you'd have a common way of the platform level of updating the firmware. So probably have a common boot loader that supports updating the firmware, probably modules or items that allow you to verify that firmware image and do the firmware update itself but on the actual protocol and interface that's being used in order to do the firmware updates perhaps not all of those two or three would be used. It would use maybe the ones that have the better throughput or are more handy in terms of accessing the OTA server. So if you go and update such a multi protocol device you could actually connect it through BLE and use your app to update it with a new firmware even if that device also communicates on another protocol, another stack in another network for the ZigBee or the thread without necessarily having to do OTA over those network interfaces. So that's the OTA updates. The application protocol in the ecosystem also plays a role, so most likely for protocols that will be IP based so there are quite a few number of options there. For instance you could use lightweight M2M or OCF constrained IoT or other application layers that use IP. So that's another design consideration. With BLE and ZigBee you kind of need to choose the respective profiles and see if those would be standard profiles or there are some manufacturing extensions that are needed for those. And last but not least of course security. So from a security perspective definitely such a multi protocol system creates new or expands the attack surface because right now you could actually access that device through multiple interfaces so care and consideration needs to be given to that aspect. Again a lot of the common platform and software security blocks may be reusable across those multiple protocols so you'd use similar AES modules for instance between all three because all use that. But then from a perspective of key provisioning let's say probably have different key materials across those three. So that needs to be taken in consideration and considered when building such a system. So I'll go a little bit further to the concurrent radio protocol. So this is an example of how an API that lets one application manage between all these multiple stacks or multiple modes of the radio would be implemented. So it's basically a variation of your concurrent API. This one in particular is also based on the mobile wireless standard that also says a few things about how you do protocol coexistence. And it's got your regular like acquire release APIs or it allows one of the protocols to send an idle signal call back when the radio is no longer used by that respective protocol stack or the operation has ceased. It also could get something like an inactivity duration. This basically allows to one of the protocols to coordinate with the others and the system that's being managed by this API. And you can actually get information on when the next operation of the radio will be done by another protocol. So you can actually knowing that timeframe you can actually use that it's at its best. And no, for instance, if you've got different priorities between these stacks or radio modes, then no one you might be preempted by a higher priority mode. Yeah, sure. So all three are basically optimized in some capacity for very deep sleep power states. So nodes, for instance, that put the MC on the radio in deep sleep mode for extended periods, starting with a few seconds, but expanding until minutes, hours maybe. And once the node wake up then either it uses BLE to sync up with a quick connection. If it's using the IEEE to 15.4 connection then it will probably have that sleepy node will probably have a parent device. So once it wakes up it can synchronize through a 15.4 data request to pull that parent for data. But yeah, a lot of these protocols allow for that and are designed for that. And in a multi protocol system that makes things a little bit easier because if you don't need to do this multiplexing of the radio being always on for some of the protocols, being on for that small amount of time when the device is out of sleep and that's usually a few milliseconds at each wake up then it's much easier to manage because it doesn't have any tight timing characters. You can just wake up and then serialize multiple operation in terms of if you're running all these protocols. So you'll probably have, so one, the node is in deep sleep. It's probably doing that based on a low power timer. So when it went to sleep it set a certain timer. So the node has the control of how much it's in that deep sleep power state. So it's not kind of a wake on radio type of operation. Okay, so an expansion of the coexistence API for instance, there's an example here of additional API if you don't do a single chip operation so you don't have those synchronization primitives then you might do a pin based coexistence. If you have multiple chips that you use to implement a multi protocol system you could use some of the GPIO pins to actually synchronize the radios at the low layer in terms of when they transmit. Again all these are using the same RF space or same RF and so it's very useful to coordinate. If the application has control on all the radio operation it's useful to coordinate using this coexistence mechanism. And basically it can do various things like setting the priorities of these operation. Some higher priorities modes can preempt lower priority modes and get idle indication, get acquired release for the radio operation with such APIs. Okay, so we saw what happens at the edge, what about the gateways? Of course gateways are still in the equation these days so for some of the devices that don't have a direct connection to your smartphone or to a LAN interface that you probably use such a gateway or hub and that's also a multi protocol system. So we've got one pictured here. What's happening for these and again with this standard especially going with thread, Wi-Fi, Ethernet all supporting IPs that we see a transition from application layer gateways as they are very common these days especially implemented in things like smart home hubs to more like network layer gateways. So probably see a lot of these IoT standard protocols be deployed more into things that are part of the network infrastructure like access point, customer premise equipment from your ISP and things like that. But of course in the gateway, on the gateway side you've got a much more complex configuration. So you usually use embedded Linux for that. That's one of our reference design pictured here. I won't go into all the details of the schematic. Just wanted to point out some of the differences maybe to a device that's multi protocol at the edge. So you don't have the same cost constraints. You can do a lot more complex operation through the Linux system. So in many cases for a gateway it actually makes sense to put multiple radio interfaces even if they are similar, even if it's the same radio if you want to do multi protocol. Just because these gateways also have some requirements that they need to be close to 100% on for the network interface doing things like the concurrency operation that sometimes switches between the different stacks is probably not a good thing to do on a gateway. Another thing is that the way such gateways are implemented you probably have the Bluetooth size of BLE and maybe the full Bluetooth combined with a Wi-Fi device rather than we saw with some of the IoT radio in a multi-mode device. So the quick... Well we've got two concurrency aspects. The first is the concurrent operation in terms of the processing. So in terms of how the stacks get access to the core in order to run and maybe in the case of BLE you've got very tight timing constraints so you need to do microsecond operation. So from a processing perspective there are some actual type requirements to that from a processing perspective. Then you've got the RF operation. So the RF operation definitely if you have multiple cores that run your radios it would be good to synchronize if you're using the same band, if you're not using the same band then it's fine to not synchronize. So these are those two concurrency aspects. First if you've got this monolithic single chip specifically edge note type device you can run into both scenarios. If you kind of get this system you usually have a lot of the heavy weight of the tight timing constraint be done by the auxiliary modules not by the main application processor but it's still good to apply a coexistence product or up here in the Linux space. So the 2.4 transmissions are not overlapping. So this is actually available. So I'll have some of the information is at the end of the slide. I can also give the information later. What's next in this area? Let's say of devices that implement multi protocols. So there was a question earlier. So I'll probably see in the edge note even more integration that was possible. So it's kind of the low hanging fruit right now with those 2.4 standards that actually are pretty commonly used. It makes sense from a cost perspective to be implemented in a single integration a single chip with a single multimode radio but I'll probably see other radio patterns being added to the edge note in a single integrated system. So the most probable will be Wi-Fi especially for the 2.4. Again there's some commonality of reusing some of the deep-fi and radio configuration but of course some of the wide area network low pan networks such as Lora, Sigfox. Those are using subgearhertz but you could design radios that actually multimode between 2.4 and subgearhertz. So that's probably the next frontier in terms of this integration. Another next gen development that we could see and there's also already some talk on that with some announcements from the center body to see a lot more of these devices being implemented beyond the smart home. So you'll see those in things like office buildings in professional installation scenarios. An example there for instance would be using the beacon aspect of the BLE in order to do location awareness but then exploiting some of the mesh network and the other characteristics that enable 6.0 pan and co-app-based networks to operate on the other side of the protocol and the stacks. So even more flexibility on the radio side, even more programmability and definitely those two trends at the end you'll see mesh networks really everywhere because right now it's Zigbian thread that have that native but a lot of the latest Wi-Fi router packs, access point packs actually implement some sort of mesh protocols if you go to ERA or Google or Linksys and these guys you can actually right now buy these mesh router systems. They still have some proprietary characteristics. It's similar for BLE. In Bluetooth you'll see some implementation of mesh networks that run over BLE and probably see more standardization in both of those two areas on Wi-Fi and BLE. So a lot of mesh capability and that's a good thing. So it will exploit these multi-mode characteristics of these radios and then depending on the various use case, the various network, one needs to connect to the various devices. One needs to have direct connectivity and then you'll have the possibility to operate in one of the mesh configuration of the other. Definitely IPv6, there are a lot of other discussions here this week on IPv6 and 6.0 plan protocol and end-to-end principles. We'll see more and more of those. It's been going on for a while and I think we now see enough critical mass in IPv6 from the infrastructure. So it kind of makes sense to actually use IPv6 up to the edge node. So that would allow kind of simplifying the stack a little bit. So if you've got this projection of what can be more deployed in a few months or years and it's possible to do now but it's really not typical. It's kind of simplified the protocol stack that we saw earlier. Okay, this multi-mode transceiver, all these five interfaces which are blurred for the application, they're just interfaces. So similar to how you use IP over Wi-Fi and Ethernet and cellular, you'd use IP over BLE or 15.4 or Wi-Fi for the IoT and the set of common modules and common software stacks starting with UDP, DTLS, with some helper application there. Again, I don't see, we'll see reduced fragmentation on that side but one can help and then a device application. Definitely from a stack and from a perspective, it would be a simplified and more seamless operation. Okay, yeah. Well, yeah, so again, I think this is beyond necessarily the frequency band. So as we saw, it's more common right now to see multi-mode radios operating in 2.4 but you can have multiple radios that do multiple frequency. For instance, you go on Wi-Fi multiple of the brands that Wi-Fi provides in that area. So I don't think that necessarily this increases the usage of the 2.4 with such systems, right? Because you'll still see in individual systems enough usage. So it's perhaps a more coordinated use of it if you've got this kind of systems. Okay. So next steps and I think we'll be able to access these so I'm going to the links. Again, NXP provides some of these platforms along with the drivers and stacks, a lot of the other microcontroller and connect microcontroller vendors for similar capabilities. So it's really go to your favorite platform vendor and choose one of their platforms there, both for the edge node and the gateway side. It's good if you're not already member to maybe join the standard bodies because then you'd be able to influence some of the specification directions and first and foremost you'd be able to take part in the certification program that those standard bodies offer that guarantee interoperability if you want to actually get more details on the less common like ZigBee and Thread standards. There are a couple of events that are open to everyone. So the first one for ZigBee is in March 6th in Austin and 4th Thread got an event March 27th in Mountain View, which again opens up public and you can actually get a deep dive of these standards more than we'd be able to do here. And of course, contributing open source software around those, starting with Zephyr which adds a lot of the building blocks for building the multi-procal systems and stacks right now but also Minute, Nimble, IOTVT or Open Thread. So those are some of the, let's say, higher profile open source software that are relevant for building such systems. Most of them are work in progress so not all the blocks are there and available so definitely would use some help. So at the end also wanted to have a quick overview and a quick example in practice. So for that, actually we'll go back to that system that we saw. So we've got this mesh network. I'll use Thread for that and then we've got this multi-procal node that also has BLE, Radion. So for that I'm going to use the NXP Freedom KW41Z which is our latest generation launch in October. Multimode device that implements these standards. So I've got a couple of boards here. So I'll go then just to see what's going on. I also have one of the other variants of the KW41 which is operating as a protocol sniffer. So I'll plug that in, actually plug two of these in because again it's a multi-procal. And then let me go to the... Yeah, I plugged in two and you'll see why. So I've got this adapter that actually allows me to use these to unit as virtual interfaces that are Wireshark compatible. So with this small add-on I'll just launch Wireshark. And going back to this I can see here in Ethernet 7 is the virtual interface. So going to Wireshark I'll choose this virtual interface. I'll start monitoring on it. And I see here the two devices that I plugged in. So what I'll do is actually... I have the 15.4 channels at the top. So I'll start the first one on channel 25. And then I'll power up one of these nodes which is the thread node. So I can then see the MLE messages that thread uses in order to synchronize the mesh network. So this is now operational on thread. And then going to the second one. So these will now do a link synchronization between them. So you can see here there has been some link requests, parent requests, parent response. So these two devices are now talking to each other from a thread perspective. I'll also create a small network. It's four devices. We usually deploy significantly more in testing like 10s or I think the largest network really is about 250 devices. I've got just four here in the thread mesh. Okay. I can see in the Wireshark how the devices change the thread management messages between them. And one thing that I can do, actually I can use the board button interface to actually send messages that are application layer messages. So you can actually see some of the co-app messages that are being exchanged. So you can see the con messages here. Okay. But what I can actually do, because all these devices actually have the BLE radio, have my smart device. So I'll launch an app. So it's a Kinetics BLE toolbox that we use for our BLE reference design. And here in the app I have a thread shell interface. So if I tap that, I actually see the beacon advertisements of these nodes that operate on thread, but they're also sending BLE advertisements telling me that I can actually connect to these devices along with their RSSI. So if I tap one of them in the app, I can actually go and connect through a shell interface. So it's now connecting over BLE. Okay. And then I've got a set of shortcuts here, probably not very visible, but I also can show on the slides. I just did an if config. So with an if config in the shell, I can actually see the IPv6 addresses that the device configures on the thread side. So if I go back to the slides, this is kind of how it looks like. So I've got a set of IPv6 addresses on the thread side and I can actually go in the application. They also send a co-op messages for my application over the thread mesh. Yeah. I've been sending one byte to the NXP TR5 over and over again, but I don't see anything happening. On BLE. Oh, you connected it? Yeah. Probably need to implement a specific profile. I'm not sure if you're using the same app or... I'm using it. Okay. Then it's probably not the same profile on the wireless UART, because it's kind of a UART transport over JDD. So it's probably that's why it's not reacting. So this is, I guess, still a bit to standardize in one of these standard bodies. How do you actually do the transport over BLE? Things like you want to do IP over BLE or a common generic raw transport. Okay. So this shows basically the use case picture here. You've got a BLE connection. Maybe it's not always that you need to do that. Maybe you only need that to show a certain UI temporarily. And at the same time, the device is also operational on the thread network. And actually going back here, so then the reason I had two devices is that I can use another one for BLE. And definitely with a single radio for BLE, you don't get all the information, for instance, in the connection. But going to Wireshark, I've started seeing also the BLE advertisements. So it's on the same interface with threads. So I can actually, if I've got a debug system that's plugged into Wireshark or TCP dump or something that's using pcap, I can actually be able to verify and test both protocols simultaneously. And it's useful to do things like see how the two protocols coordinate with each other. So I've got a lot of advertisements here, but if I filter, let's say, UDP, I'll also see the thread-only messages that are also showing up, okay? And finally, okay, sorry. We're close to the end of the time, but I think we're the last session in this room, so maybe have a couple of minutes. Another example I wanted to show you is using two boards. So I'll just turn off these ones that I use and plug in others. So I'll plug this actually to my PC. And the reason for that is to show the host SDK. So this is, if you do things like a gateway, a multi-pro call gateway, then the host SDK comes, it's a set of tools and BSD license software that runs on things like Linux, Windows, most sport Mac systems. And you can actually build a set of library and interface with the devices for a serial interface, being able to control and coordinate on two or more of these protocols. So with that, for instance, I can... Let me see, for instance, okay, I'll go to the device manager and the two devices that I plugged in the J-Link comport on 6 and 15. Okay, so I can then go to a shell interface here and just use one of the multi-mode Python scripts that I wrote, so 15, and let's say the thread channel is 24. So now I can actually, for testing purposes, also for better use of development, while I go and develop and integrate such protocols, I can actually use this set of host-based tools to start my thread networks. You'll see a lot of log events as the thread network and, for instance, right now, it's running the mesh commissioning protocol to authenticate these two devices to each other. So it's a lot of scripting that I can do with these host APIs. Okay, so the thread initialization completed, so with these two nodes, I now have a small thread network created. But then, and you can already start to see here, a lot of GAT messages. So I started also using the CRL interface to connect to the... and control the BLE interface. So right now, these two devices started sending some ping, so you see the ping at the thread level, but if I go back to my BLE app, just to differentiate around the heart rate, I also see one of those devices implementing the heart rate profile application, so I can connect to it. And actually, I'm starting getting the heart rate information, even those two devices are also sending pings to each other on the thread network. So pretty useful for testing and scripting and batching various commands. So with that, thanks very much for your time and I'm sure there are other questions at the end. They're not open source. For this device, we do provide them in source with a BSD license, but they're not part of an open source project. Again, a lot of the open source, the true open source in projects like Zephyr or others are still working in progress and being now ramped up and hopefully everybody's help is appreciated on that. Yeah. So if that's not running Zephyr, what's producing the co-app packets? It's a co-app module that runs, in this case, this device is actually using FreeRTOS, so it's actually a co-app module that runs over FreeRTOS. It's running FreeRTOS, so you get this in the package from Welter, Digikey or something like that, but I think it doesn't have FreeRTOS by default. So, no, going to the... So what's currently available for this platform in terms of enablement? So if you see these toolings here, so from a driver perspective but also from a stack perspective, for the firmware of these devices, there are a set of firmware modules that you can actually deploy through Eclipse GCC, ARM GCC or IAR based that NXP provides. It's, for instance, similar to on BLE, I've got a soft device stack or something similar. You'll get all the enablement for these devices as you get the boards. You just need to go and download them from those links. So you get everything to build these solutions, but again, a lot of these is not yet fully implanted in open source projects. And now it's still early, and a lot of the coding this SDK packages are... It's not binary blob, so it's both the radio drivers as well as the coexistence framework that I showed as well as the upper layers of the stacks are provided in source, that can be modified and used as a model. Okay, yes? Static routing. Yeah, well, it's a bit difficult to do that with one of the standards because the standards already do mesh, kind of have their own specification around how you do that. So that's usually dynamic, especially for these IoT devices. In ZigBee, it's different versus how you do it in thread, for instance, it's usually handled by the stack based on the specification. So from a static route perspective, device to device, it's more difficult, but if you consider things like border hours or devices at the edge where you've got, for instance, IPv6 provisioning from your ISP, you can definitely do more on such devices and kind of configure which packets, based on the source prefix on IPv6, which packets get routed across the border which go from the upper-layer infrastructure to the IoT network. Okay, so I think we're at the end of the time. So thanks again, everyone, and I'll have some of the next steps, links here. If you want to look at the slide next lecture. Thanks.