Okay, in terms of AI adoption and why we are talking about bias, you know, now one of the reason is, you know, in the early stages of adoption, right, you know, in terms of machine learning and AI, bias was not even thought about because everybody was just in a hurry to get the result, right? The outcome was more important than, you know, the quality of the outcome itself, right? But today, if you look at, you know, you can create a model maybe in 10 minutes, right? You may take a whole year to do the same stuff, right? Because what matters is the quality of the output you are getting. And one of the quality parameters is how good is your algorithms in terms of bias detection, right? In terms of making sure that, you know, if you give the, a new set of data, how it responds to the new set of data. And that's why we are here. And if you look at, you know, what we are trying to say is, when the AI adoption is increasing, one of the biggest issue in terms of the success of the AI itself is, because people don't trust the outcome, okay? There was a pretty good joke about IBM, you know, a couple of years back, IBM created a very simple application when you go to the airport. It tells you, you know, remember they do the screening, right? And at the moment, you know, basically the security guy will just stop you and say that, okay, I want to screen.  It was supposed to be random, but a lot of time, everybody, you know, who went through that screening process thought he was bias, right? So what they did is they asked IBM what they can do and we created a small app, right?  Now that app was like, you know, a few million dollars, okay? And someone put on the internet that, you know, it was written by maybe some interns or something, or maybe an hour, okay? So a million dollars for just, you know, a few lines of code, but that was not true, right? You know, inside, you know, we did a lot of stuff to make sure that we mitigate those biases and the very reason the application was created, okay? So what I wanted to say to you is, when you're embarking on the journey of, you know, creating a model, trust is very important, right? The correctness of the model is very important. It's not just about the model itself, okay? And that's what I'm going to focus today. Now for some of you who are new to machine learning, I heard a lot of you, you know, some of you said you are here for the first time, you are hearing something, okay? We don't have, like, you know, I'll say time to go through the whole machine learning exercise, but I just put up, like, what I call a cheat seat for machine learning, and I'll take one minute to walk you through, right? Basically, related to, like, for example, I want to predict about someone going to a college degree after 10 plus two, right? After your A-level, whatever you say. Now for that purpose, you know, because your data is already kind of categorical, right, you'll be using logistic regression instead of using basic regression, right? The same way, you know, if I want to do any kind of prediction, right? And basically the recommendation engine you see, where someone is trying to figure out whether you'll get a loan or not. For that purpose, we are using stuff like, you know, decision tree or the random forest kind of algorithms, okay? The idea behind no matter what you are using, the step what you go through is the same, okay? These algorithms are much more, I will say, trusted. The reason is when I'm doing a decision tree or a random forest, it gives me a pretty good, like, a diagram, like, on what basis the decision came, okay? So that's why if you look at, you know, the success of these algorithms are much higher as compared to deep learning algorithms.  And because a lot of things are black box over there, right? The trust is not that high. So, you know, if someone is starting, you know, it's good to learn, deep learning and all, but if you really want to be successful and if you really want to develop something, right, which you can put in production, which people can trust, I will say start from here, all right? So, yeah, so what I was saying is, you know, you got much better off trust and other things with this algorithm, because this algorithm itself to give you on what basis you came to a conclusion. But specifically the deep learning algorithm doesn't tell you, right? So here, we are going to talk about how do we, when we build a model, how do we develop trust, okay? Now, the beauty.ai application, which I showed you, you know, you can say, okay, even if it goes wrong, it was made for fun purpose, right? So, you know, doesn't, we'll have like a life-changing impact. But trust me, the algorithm which you build can have a life-changing impact, okay, just to give you an idea, okay? So this was one of the, you know, use keys regarding, you know, machine bias, okay? And this was really researched a lot, and what they figured out is just to, I'm giving you a summary of the result. So what happened is there was this algorithm put into like the, you know, criminal system, where they basically help you to identify, like how many years of imprisonment you have to go through, okay? So in this case, what happened is they were too tapped, okay? And this algorithm, which was being used by the police department, you know, looked at the picture and looked at the profile of the person as well. And based on that, it basically says that this guy is a low risk. And the other person, you know, Brisha Borden, high risk. If you look at the risk category, it's pretty high. So this is like on a score of 1 to 10, the risk basically tells you the algorithm was about what is a good chance that this person is going to do another crime, okay? So they waited, you know, high, okay? But what really happened, right, after, like, you know, you can't look at in the future, but you know, after some time you can look in the past and see what happens. So this is really what happened, okay?  And he did some subsequent offense as well, okay? In this case, there was no offense, right, either before or either after. So what it shows is your algorithm was totally wrong. And it happened because the bias, right? So what happened is the algorithm was trained based on historical data set. And one of the things which happens is, you know, even the beauty.ai, what happened is they trained the model based on a certain set of data. And this data was mostly from, let's say, you know, European countries or America, right? And that's why this bias happens, okay? So what I'm trying to say is it's not just fun, right? The trust and the bias, it's a very serious, it's a life changing impact on someone. So when you're developing your code, you need to be a responsible person. And make sure that you abide this on day one. Now, here I got a life cycle of how you make sure that there's no bias in your code, okay? Pretty complex stuff, but I'm trying to simplify. Not oversimplify, but trying to simplify so that we can cover in this session. So we talked about building a model. Let's say we are building this model for the same stuff, right? Trying to find out whether this person will do a crime again or not. The first thing is, of course, you have to do some, this is a life cycle of your machine learning model development as well. I've just added the bias steps as well over here. So first you do the preprocessing. What I mean by preprocessing is, you may get data, right? For example, if I'm looking at some web references, I may be getting the data and some HTML format, some JSON format, something else, right? What you need to do is you need to make sure that the data can be utilized for your algorithm. That basically means either you're doing the categorizations, right? Sometimes you're doing a standardization, and sometimes just grouping itself. You're converting your categorical into a numerical value, right? Just to give an example, for example, if I have age of every individual, if you give machine learning an age itself, it doesn't mean anything. So what you have to do is you have to categorize this age into age group, right? And that's part of the preprocessing, right? So you have to go through the preprocessing, and then what you do is you have some training data. So you get a samples of data, and based on this sample, right? You split the data into what we call as a testing data, test data, right? And doing the training part, you train your model using those algorithms, okay? And after that, you are testing it, okay? And then usually you go ahead and deploy it. Now, there are a couple of ways where you can do the mitigation. One is, of course, when you deploy, you learn from the experience. So in this case, it's very straightforward. I didn't do anything in the past. I deployed the model, but I have a mechanism by which I can monitor the model, okay? Figure out if the model is biased. If it is biased, I take that feedback, do some cleanup, right? And we deploy the model. So if you're going with this approach, that basically means you're monitoring the outcome, each and every outcome, okay? Over a period of time. But this is more like I will say reactive approach, right? Because what is happening is already someone's life has been impacted, and now you're trying to mitigate it. The proactive approach will be before even if you go to that step, right? You have the training data, okay? Do what I call as preprocessing on that training data and try to go through data, what I call is going through algorithm that mitigate biases from the data itself, okay? What it means is, let's see if I give you a data, right? And I'm just trying to simplify in the sense that, let's say I give you a data. And we are trying to say that, okay, the earlier example I took, how many people will go from 10 plus two to college, right? And if I'm picking a particular city, okay, let's say Singapore. And I'm going to use this model somewhere else, some other part of the world. Already I'm biased because over here, right, the living style, the economic is very different than the rest of the country. So when you're mitigating this kind of bias, what do you need to do? You need to generalize your data set, okay? You need to make sure that your data set is general enough to represent a larger population, okay? So that's what you do into this. If it is very simple, right, you can do that, but certain point of time you'll find that it's very complicated, okay? I will start from here, right? The proactive effort and then we'll go to the reactive effort. So for the proactive effort, we put something called AI Fairness 360. And this is a open source toolkit, okay? So all of you have access to this, okay? What the AI Fairness 360 Open Source Toolkit does, basically it gives you more than 70 different algorithm which can help you find risk in your data set itself, okay? Also, it provides more than 20 different matrices, which will basically tell you, right, whether if you develop an algorithm based on this data set will have a problem or not, okay? Also, you quickly, you know, how you can use this. So let me go to this. So this is the URL called AI Fairness 360. I'll put it on my PowerPoint if it is not visible. It's called aif360.mybulomics.net, okay? And this assets was developed by IBM Research, okay? And it has been there for last, like, we published it. We open source it six months back. We're getting pretty good, you know, interaction and what I would suggest if you are into open source, please contribute back. Use this and contribute back to this as well, okay? Now let's look at, you know, how this helps you to mitigate a risk, okay? So what we provide you, the API, we provide you the algorithm. But for this sake, you know, just to make it easier for you to understand, we also created a small demo. I'll just walk you through, this demo is available, okay? I'm going to use this, you know, this data called German credit scoring. And this is the same data sets we are going to use in our lab, okay? So I'm just trying to make sure that you get to understand this data set better. In this case, I have, like, you know, basically we are predicting individual credit risk, very common thing, right? We all go through that. The banks are doing on us. So we are going to do a credit risk prediction. Now, in this case, the first step is checking the bias, whether the data is good or the data is having some bias, okay? Now, how to find out bias, right? And this is not like rocket science, but again, it's a lot of mathematical, you know, equations as well. I will take the simplest one, okay? I'm not going to explain the complex one, the simplest one. So let's say, for example, there's something called a statistical pavity difference, okay? This basically tells, like, okay, there's this concept of privilege group and unprivileged group, right? So what you're saying is, let's say, you know, in our beauty.ai, we said, you know, the guys with the whitest skin is a privilege group, other is unprivileged group, right? Or we can say age, right? This algorithm, the statistical pavity difference, basically tells you, right? In terms of the outcome, where you are biased, okay? So basically, if you're getting a value of zero, that means you're neutral. If you're getting anywhere, then basically it means bias. So what we did is, we created more than, you know, 70 different, you know, such matrices, right? And over here, like, on this data sets, when I apply this algorithm, what we do is, we apply not just one algorithm, but multiple set of algorithm behind. And this is giving me a few matrices, right? Which will be, whether this data set is a problematic data set, or it is good to use, okay? So in this case, it says that, okay, statistical pavity difference, you know, the difference is 0.01. Means almost it is fair, right? But in certain cases, you know, you'll find that, you know, dis pavity impact, or in case of, you know, thrill index, right? I see, you know, a much higher or something. So if you find, in this case, you know, the data set is like, if you look at, you know, for, we are looking for two different entity, okay? One is the sex, right? Whether it's a male or female. So if you look at over here, it's basically that if I'm looking at protected attribute sex, right? You know, everything is pretty okay. The data set is fair, right? But if I'm looking at age, right? In this case, what you find is the data set is highly biased, okay? And this is not a rocket science, you know, means, you know, people figured out very easily why. Can anyone tell me why? Why the data, so this was actually based on real data set, right? The credit score of lot of people in Germany over a period of time. And they found that the data set was biased against age. Why? Exactly, right? Because lot of, you know, young people were applying for the credit card. And this is the data, you know, they had, sorry, other way, not lot of young people were applying, right? Because most of the time, by the time you make money, you know, 10 years back, you're already into a certain age group. So this is why it shows bias against, you know, younger population, okay? So now we know that, okay, there's some bias over here. How do we mitigate the bias? So this is where, you know, you go to this next process, okay, you can check some of those, okay? Now I have a different bias mitigation algorithms over here. I can look at, you know, which bias mitigation algorithm I'll be using it, right? One of the simple thing is re-weighting, right? That basically means, okay, earlier, if your age was, you know, 30 to 35, I was giving you a risk of, let's say, five. Now I'm making it maybe a bit lower, right? A bit higher, depends on the use case, right? So that basically means I have those 10 attributes which identify a result and I'm re-weighting them, okay? So that my data becomes much generalized and it supports every age group, okay? So that's what, you know, you can do as well. Now if you do manually, you have to prepare the data sets. In this case, what happens is I take the data sets, I pick up the algorithm and the AIF 360 helps you to generate the new data sets for you, okay? It will take some time, you know, to do that. And this basically saying that, you know, you have a certain set of data, you check if there's a bias on certain protected group and if you find the bias, you run through the next set of algorithms which mitigates and give you a new set of data and this new set of data is good for building your algorithm, okay? So very, you know, strong and very powerful, you know, set of algorithms over here, it makes your job much easier instead of you trying to, you know, change manually the data. And a lot of time it happens, right? If you look at, you know, even when people, machine learning was not popular, people say statistical analysis, there the sampling was very important, okay? And they were trying to take the right set of data for the sampling, right? Here, you're doing the same, but what you're doing is, you know, if you need to make some modification in the data sets for making sure that your algorithm is not biased, we are doing that as well, okay? So now once I have a new set of data, you can see that, you know, you can compare, right? I'm not going to the, this part, I look at the age part because this was where the bias was.  So what I can do is I can go back, had a different algorithm, so re-weighting is not helping me, okay? So I'll go back and pick the other algorithm and go through that. When I see that, this bias is removed or very close because it's not possible to have a perfect world, okay? You're never going to have an algorithm will be just perfect, right? You'll always have some issues, but we are trying to make sure you close, come as close as possible, okay? I'll pause over here for a moment. Any question on this? Yeah. So we're getting a new copy of the data set, right? And we are really changing the weight, or, yeah, okay? So different algorithm does this. In case of re-weighting, we are changing the weight. So that basically also means, let's say, you know, if I had like five records, right? I'll introduce, you know, 10 dummy records, right? So that will automatically, you know, when you're doing the analysis, right? Because you have more record of such type, your weight will change. That's what it means. You can say that, you know, some means, it's a similar approach, right? But what you're doing is we are looking more from a data bias perspective. Like there the, you know, objective is different, right? Here we are trying to look more from the bias perspective. Yeah, right, from the existing record set. Yeah, you can look at, you know, so that's why, you know, I said this is open source, the data set is open source. The algorithms are all open source. You can try yourself, right? And just bookmark this, aif360.mybloomix.net, okay? Let's go back to the other part of the agenda. So this was like proactively trying to clean up your data. Now let's say, you know, I built the algorithms. Now I put up in a production. What else I can do? Okay, so I went through this. Now for the second part, right? Where we talked about, you have built a model, right? You put it in a production. You deployed the model. You want to check for the biases. For that purpose, I like to introduce, you know, our technology, what we call as open scale AI, okay? And this is a technology which we, you know, is a product actually, which is available on the cloud and on-prem as well. Okay, that basically means you can do with your secure set of data as well. And the concept over here is you build your model, you deploy your model, and after deploying the model, you decide what are the protected attributes, what are the unprotected attributes, and based on the result, based on the outcome, it will continuously monitor your model and tell you about any kind of biases. Now it doesn't just, you know, do the monitoring, but also it gives you a kind of, I will say, insight, which is helpful in a production environment. So you can set a threshold, right? So for example, I can say that, okay, if the bias on this, let's say age group becomes, you know, goes beyond 80%, right? Then send me an alert or stop this model for running further, right? That is very important. So you can put those threshold over here as well, okay? So apart from the model, you know, the bias part, it also is giving you another important of trust, which is a lineage, okay? So what we mean by lineages, like when you do a prediction, there may be, you know, 20 different data elements which you pass to do the prediction, but what was those two data element which was most important for the algorithm to make decision, it will show you that as well, okay? So normally if you're doing, you know, algorithms like decision tree and other, it automatically shows you, right? But those are meant, you know, for the guy who is building the model itself. This is something we are targeting also for the guys who are consuming it, okay? So what I mean is you see a credit risk and you want to know how this credit risk was applied, right? And this is where, you know, today it's not happening, but you know, going forward, we see this future where you can very much ask, right? The bank, okay?  You gave me only this, why? Okay, because the decision will be made by machine, they need to justify through the machine, right? And this is where the open scale will actually give you a pretty good idea, like you had these three things, maybe your last loan was rejected and that's why your credit score goes down and this is why this is your score, okay?  So two things, one is the lineage, one is giving you the, you know, the bias reports and mitigating the bias report. Now, how do you do that? Like, let's say you want to build such a thing yourself, how do we do that? So there are two parts, three parts to this, one is developing it. So this is where we are going to, we have a tool called Watson Studio, okay? And specifically, if you look at doing the DevOps process for a data science and AI, it's all about, you know, open source, okay? So here we build a platform using open source, right? And this is like, you know, whole, like if you're looking for Python, you know, you're looking at Anaconda packages, whether you're looking at TensorFlow, you know, more than 75 different, you know, AI framework, the machine learning framework we embedded into this and we build a development process where you can actually build the code using your favorite tool.  Japlin, okay, you know, you can use this to build the code. So once you build the code, the next part is how do I do the deployment into the production? And this is where we have something called Watson Machine Learning.  Building the model, you can build through the Watson Studio or even some other tools, like for example, if you're using SAS or if you're using, you know, maybe, you know, just your notebook on your laptop, right? To build the model, that's perfectly fine. When you have to deploy the model, you want to deploy in a way which is skillable. It is easy to consume by the application. So when you deploy the model in Watson Machine Learning, two things is happening. One, a very secure way of assessing your model. So what we do is we provide you the rest API for anything which is deployed over here. That means as soon as you deploy the model over here, it's ready for consumption, okay? So anybody, you know, from your mobile apps, from your IoT applications, right? You can consume those model in a very secure way. So we have this authentication mechanism, another thing, all built in. What it means, this is very important. What it means is from your built to deploy is just a matter of few hours, okay? Until now, the built to deploy was a matter of at least couple of weeks. Why? Anyone over here? Why the built to deploy is a big challenge? You think something? Okay, so you got a spot on, right? So basically, if you look at, you know, when I'm building this model, right? You know, I may be using different kind of library. When I'm building on my laptop, right? I have like, you know, Python 2.7 is still on my Mac, and I build using that, right? When I'm doing it into the production, what happens is that machine may not have the same sort of library, right? Then what do you do? You try to figure out the library, right? And a lot of times, it happens that the code which you wrote for one package is not available into other package. And in open source, it's happening every day, right? You know, all my code in Python 2.7 doesn't work in Python 3.7, right? So a big change. So what we do is, we use this concept of, you know, we had this K native session, right? And most of you were here. You understand the concept of Docker, right? So we are using the same concept over here. So when you're building this library over here, instead of, you know, giving you the code on your host machine itself, we provide that as a containerized image. That means, you know, it gives you flexibility to build a model using different version, right? And in one tool, you have different environments. So I can have, you know, Spark, you know, to Spark 1.6 if you had some old codes as well, right? All in a single environment. And when you're building, going to the deployment part of it, I can use the same container to deploy it over here, okay? And you don't have to do anything manually. Automatically, as soon as you do the deployment, the containers are pushed to the production machine and you're all set to go. And that's what I'm saying, you know, from few weeks, three to four weeks depends on the maturity. Some people may take three months as well, right? Here we are doing the development to production in just a matter of few hours. Yeah, yes, it does allow you because, you know, even though we provide you like pre-built containers, five, six containers, but that's not good enough, right? You know, someone may come up with some new set of algorithms, right? So then only I saw one of our research team built an algorithm which basically fast track, like the performance of your normal logistic regression increases by 45 times. And that's their proprietary algorithm, but they want to develop on this platform. So they can containerize it. So what we do is we provide our toolkit, okay? So you can download the existing environment we have, right? And you can modify it, push it back over here. Okay, so you can very much bring your own environment, okay? So that helps you to do the production part. Once the production is done, right? You know, the next part is the monitoring thing. And this is where the open skills comes into the picture, right? And this, as I mentioned earlier, we are talking about bias, right? Which is the fairness part of it. Then we are talking about lineage, which is the explainability part of it. Apart from that, it also look at the model health, the model accuracy, right? And also the performance as well. Let's say for example, or 10,000 people suddenly start hitting your API, right? Of course, the response time will get slow. It will tell you whether the response time is slowing or increasing. The best thing is based on the feedback. So today you have 10,000, you know, concurrent user, suddenly it become a million concurrent user. Because we're using the container technology to deploy over here, automatically it will scale more containers and it will take care of your workload as well, okay? So that's why the build, deploy and monitor, right? So we are providing this with a set of tools to you and these are the tools we'll be using in the lab as well, okay? A bit more around this open scale and then I'll move to the lab part of it. So as I mentioned over here, it's doing your model explainability, right? One important thing is to use the open scale, it doesn't mean you have to deploy it on IBM Watson machine learning itself. You may have deployed on, like let's say, what about the existing deployment? So if you have some existing deployment, open scale can connect even to that, okay?  So if you have deployed it, there will be an endpoint URL. If you give us the endpoint URL, we can connect and start monitoring those algorithm. Of course, there are certain limitations, right? Because normally, you know, those kinds of bias and other things work pretty much well with logistic equations kind of algorithms and some of the things I talked about like recently. We are building up to match this, means basically generalize it to more common algorithms as well. But right now, you know, when you're using it, it supports the 70% of the algorithms which I talked about, yeah? Yes, so Kidman, you know, just put his laptop aside, I'll let him answer it, okay? So we have this, you know, whatever you have over here, we have a solution which we call as IBM Cloud Private for Data, okay? Which is like our container technology along with the applications, the data and AI applications all bundled together. And that you can deploy anywhere. You can deploy on your, you know, data center. You can deploy on Google Cloud, Microsoft, you know, anywhere, right? So the answer is yes, okay? So apart from, you know, the open skill, the other technology, right? And this is where I talked about, you know, deep learning in the beginning. Just wanted to close onto that. So deep learning, if you look at the most common use case for that is around two things. One is around basically picture classifications and the other is around natural language, right? Understanding. So TensorFlow, you know, how many of you heard about TensorFlow? Most of you heard, right? So it has been a common way and if you are doing the stuff right, you know, it takes a bit of effort to do some coding over here. There, right? And then you can build the model, the first thing very easily, but if you have to really get to a level where the algorithm is very accurate, it takes a lot more effort. So to simplify that, we came with something we call AI for AI, okay? And Kirtman is giving a talk later today at two o'clock, I think, which is about will AI take over developers, right? This is like, you know, just a preliminary stuff around that. You know, what here we are talking about is here we have a tool where you give an image, right? And it automatically built the whole neural network for you. Okay, of course, you know, when machine is doing and also this is just, we just got it started, right? So don't expect magic, right? But you know, this is doing pretty good job. Like if you give, I tried with some natural language, a classifier, and if you give like a set of text and say, you know, classify as a positive, negative, or classify based on the sentiment, right?  Whereas you'll have to build the code, you know, it may take some more time. So that's a new net. And in the lab, you're going to talk about that as well. So that was my chart. Let's go to the hands-on workshop, what we're going to do on the hands-on workshop. So this is our scenario, right? So let's assume that we are a credit card. We are going to do the same thing, like a credit risk analysis. For that, I'm using the same data set which I showed you earlier. So we have certain population data from the past where it automatically classified, whether this guys are, what is the credit risk for them? Okay, so we are going to use that data. And based on that, we are going to create a risk model, okay? And on this risk model, we will deploy our open scale to figure out, right, if there is any kind of bias, okay? We are not going through the AIF 360 where we were mitigating the bias, okay? Here we'll build it, just deploy it, and then look for if there's any bias, okay? So we'll be doing mostly on to the monitoring part of the bias. So how does this work?  So we are going to use these four tools. One is, you know, Watson Machine Learning, which will be basically used for the deployment of the model, open scale for the monitoring part, and in the backend, you know, our data set is in a DB2 warehouse, and for processing purpose, we are going to use Apache Spark, okay?  We are using the, this is openly available data sets, so why I'm bringing this, you know, just to give you an idea, like we are not using anybody personal data, this is open data sets what we have, and we are using this open data sets for the algorithms, okay, and these are certain, like, data elements which are available over here, which we'll be using to predict, and in this case, our protected group is going to be personal status and age, on which we are going to do the prediction for, which are going to monitor for the biases, okay? How the things will work in production, once the model is deployed, there'll be request, right? And this request goes to the Watson Machine Learning, where it is deployed, and the AI open scale is going to look for, you know, the training, look for the biases, and as I mentioned, if it finds there's a bias or something, which is happening over a period of time, we can look at a new training data sets and try to re-evaluate our model so that the problem can be fixed, okay? With that, I think we are all good to get started, okay? So I need a couple of things from you, everybody connect to the internet using this Wi-Fi, if you haven't done yet. So this, you want to join, and do you want to walk them through the content? Okay, where do I have? So let them note this first, and then I'll show you, just note this guys, because I'm going to show you another URL where you need to download some content. Let me know once you are done, okay? You guys are smart, so 30 seconds should be good enough to note this down. Let me go to the other URL. This was the one, right? You gave me that shortcut, okay? Where did you give me? On WhatsApp? Or in the PowerPoint? Did you copy it or no? I don't want to open WhatsApp here. Okay, I'm just noting it down over here, so you can note it down yours. Okay, don't note it down, let me just make sure that it works first. It was sttps-bit.ly2-d-r-i-l-capital. All right, this is correct, all right? So sorry, I have to ask you to do a bit of work, so I want you to put this on your browser, okay? And this will take you to a folder where you can download the content, okay? So once you get to this URL on the top, you'll find that you got certain data sets over here. Then we have two labs, okay? We will request you to start from the lab one, okay? The lab one basically, you know, goes through the building the model, deploying to open a scale, monitoring the model. Once you are done, then you can go to the lab two, which is about building a deep machine learning using the new nets, okay? The account information all there in the, okay? You want to go? Okay, I'll ask, you know, while you do this, right? I'll ask so there's just to walk you through the steps, how to get started on to this. Actually, so once you open the lab one, right? So you'll see there is a scenario that is given. But in terms of practically doing it, from the previous session, you already have a registered IBM cloud account, right? So you go into that account, right? And you'll see there is a catalog. Are you logged into cloud? Are you logged into the cloud? So in the previous lab, you didn't actually really create any services, right? So whatever was given, you just continue with the exercise because the clusters were already given. In this lab, you'll be creating these services. So, you know, once you go into the main catalog here, you'll see you have this whole IBM catalog, right? So what we are doing is for this exercise, we are using some of the APIs, right? So if you click on the AI tab, right? So you'll see there's all these different APIs. So for example, one of the services that we are using in this lab is let's say the machine learning. So you click on the machine learning, and then it'll come up with some name and some details about it. So what you do is you choose the light version, which is a free version for your account, and then you just click a create button, right? So that'll actually instantiate a machine learning service for you, which is needed for the lab. So, okay, so one more thing. So in your last exercise, some of you would have changed this account to IBM, right?  Suppose you have logged in as ABC at yahoo.com, you change that back to your account, right? Because you may not have permissions in the previous account to create services, right?  First thing, everybody is able to download the PDF. Everybody is able to download the PDF, right? So once you have downloaded the PDF, right? So you make sure the first step is you're able to log in to the IBM cloud, right? So that's the next step. So once you are there, you'll see you need to create some of the services, right? So make sure you are in the right organization. In your case, it'll just display your name here, right? Or the email address. Once you are there, you click on, let's say the first thing is instantiate Watson Studio Service. So you see here, there's a Watson Studio Service. You click here, right? It'll come up with some name here. And then make sure you're always in, for this exercise, make sure you're in Dallas.   Just follow through the lab. You should be able to get it through. Because there's no code that is needed to be written here. You just follow the scenario and then just progress. Okay, a couple of common things what I'm saying most of you are going through. So I'll just explain why it is happening. Some of the things you have to take care of while doing the lab. The number one is, I can't get the projector back, but I'll talk through. Make sure that all your services are in the same zone. Okay, so a lot of, a couple of guys I have seen when you're creating the services, the three services, make sure that they are in the same zone. Yeah, so that's one of the things. So over here, like if you look at, I have the Watson Studio. The other one which you need is the OpenScale and the machine learning. All the three services create in the same place. Okay, right now, we have this limitations where if you are running this OpenScale in a different zone, we have some network issues and other things. So you'll get some authorization or authentication kind of ever. Okay, so to avoid that, make sure that you get it in the same zone. So if you have done this by mistake, like if you have gone to some other zone, delete the services because you cannot create more than one services on the free account. So it will not allow you to create multiple OpenScale services. So delete the old services, create a new services and then you should be fine. Once you have done that, the next step is, the best way to move quickly is go to your Watson Studio, okay? And in Watson Studio, when you're creating the project, first you need to make sure that you have linked Watson Studio to the Watson Machine Learning, right? And that you do by adding it as a services. So what you need to make sure that you should be able to connect to your object to storage and the Watson Machine Learning services. There, the steps, what we have given to you is like going through the different experience, but typically what you're doing is either you can build your own model or you can go over here and say new Watson Machine Learning model. And when you do that, you have the option to select from the sample. So either you have your own model or you do it from the sample. In this case, the credit risk model is already there. So all you have to do is pick credit risk as the model to be deployed, okay? Give a name and that's all. Once the model is deployed, you do the testing, okay? You got a REST API, the JSON interface to test it, right? Typically that is given just for the testing purpose. In real case, you'll be using that API and include in your front-end application, okay? Now, once you do that, when you're going back to your open-scale configuration window, there'll be bit of latency. And this is very practical, right? Because what is happening is, these are two different services and you're trying to connect, okay? And the idea about monitoring is not like instantaneous, right? We are looking at the history of bias based on the history of prediction. So it doesn't need to be real-time. That's the reason there's a latency over there. The typical latency can be like an hour. So if you go to the open-scale, it says that whatever prediction is available for only last one hour and the latency may be like five minutes, okay? So if you have done a single prediction by the time it is available in open-scale to monitor, maybe around five minutes, okay? So there's no harm predicting it a couple of times, okay? So you can predict a couple of times so that it has got more transaction in the open-scale. And once it is done, then when you will come to the open-scale, right?  And also considering that, you know, we are serving lunch at 1.20, okay? So I want you to quickly finish, don't miss your lunch, and then be ready for the next session. This lapse you can also do later as well. So let's go through this interface, what this interface does.  One is like configuring the model itself, okay?  Once you have done this configuration, one of the things you can also do over here, not the chat, you click on that model once it is deployed. And one of the things I typically do is because I want to see some more transactions, right? You have the option of, you know, add feedback data, okay? So you can give some feedback data over here. So what it will do is, it will do actually the testing on each one of them. So it's like a batch scoring, okay? And that gives you a lot more transactions so that, you know, when you're looking at the output in OpenSQL, it makes more sense. At least when you're doing the testing part of it. So normally I'll put some feedback data over here. Let's go to the, you know, the interface itself. So in this case, my model is a bit different than what you're trying to do. Your model was around risk, right? Credit risk. Here, I've got a model about drug test. So basically, in the scenario over here is, I've got a set of drugs called ABC, right? And a set of like disease. And we are trying to figure out if my model is biased against a certain population, right? Based on, you know, age or based on actually over here, based on blood pressure, okay? So in this case, you know, if you look at, I don't have any new set of data because I haven't done any training. So you look at the timeline. The way to look at over here is, this is showing historical, right? So over here, it shows the accuracy, fairness, right? And on over here, it shows over a period of time. So if you have transaction, lot of transaction, you know, when I will move around, I'll get a lot of transactions over here. But I haven't done anything over here. So I'm saying for some last transaction, which was done on March 8th, okay? Now here, basically it shows me that, okay? Let's look at this. I'll go to the details, okay? Now in this case, if you look at, I have the, you know, some summary over here. It says 1% of the group is normal, right? And there is certain bias as well.  So in this case, what it is saying is, if the blood pressure was low, right? You know, 26% per time, a particular drug was given. And what we're trying to say is, the problem is the same, right? You know, the symptoms and everything is the same. Why we are giving different medicine, right? So in your case, you know, we were looking at age and sex, right? In this case, we are looking at blood pressure as one of the element. And whether we are seeing that, blood pressure influenced the decision, okay? You'll also be able to see the transactions, where it will do the transaction explainability as well. In my case, you know, if you look at, you know, I have some, the model, and it shows me, like, you know, the performance of that, okay? If I had more transactions, you know, I can actually look at the transactions over here. So I don't have the transactions history over here, because typically, one or something, okay? If you, that's by default, I can change the parameter to keep it for a month or whatever I want. And when you click on a particular transaction, over here is the scoring, okay? It will tell you how the prediction happened, okay? So that's something you'll be able to look at in your stuff. Okay?  But if it finds the, there's a bias, this is the good part. You know, it also give you a de-biased model, okay? So basically, it is, you know, modifying some of your, I will say, optimization parameter, right? And based on that, you know, it is creating, suggesting a de-biased model as well. If you want to take this model to production, you can take that as well, okay? So this was about your open-scale, and I apologize. I think some of you are having some issue with the services, okay? I think the latency from the machine learning to here shouldn't be more than five minutes when you're doing the configuration. But right now, make sure that you are putting up in the same zone. If you're putting up in different data center, we know that's a non-issue, all right? Also, one other thing I wanted to show you, like in this case, the model is deployed on our machine learning, you know, in our environment itself. But this is important, right? You can do it for, your model can be anywhere, okay? Your model can be deployed on Amazon, okay? Your model can be on Azure ML Cloud, right? The reason we are trying to do is because we understand that you're not going to bring, you know, whole thing just for the sake of using the open-scale, right? So if you are already using AWS or Microsoft, you know, services, you can still use this environment. The custom environment is nice. In this case, you know, even if it is somewhere else, right, it's, what you can do is you can give the individual a scoring endpoint and this way it will be able to connect to the custom services, okay? So that basically means, you know, I don't have to deploy everything in Watson machine learning. You know, you can deploy it anywhere and you can bring this stuff over here. And the new net thing, right? Because none of you did it, right? You know, what you'll do is there's a service in open-scale at the last. It will say new nets. And when you go to this, you can, you know, if you have provisioned the new net, it will say synthesize a model, right? And over here, it's basically two steps, right? One is you upload your data.  So yeah, I'll really like, you know, thanks for your time. I hope, you know, it helps you to learn something new, right? And, you know, basically you can play with it. Even this account will be there for a month, this services. If you get wrong anywhere, just delete those services, create a new services, okay? And, you know, that's all. So we have another 15 minutes, right? At 1.15, we'll break, right? They are serving lunch down at 1.30, so we'll break around 1.15, okay? Thank you. It'll be all good, man. Thank you.


So my name is Michael Scott. I work for a company called Foundry's I.O. It's kind of a think of it as an easy button for product developers to kind of get a head start in the embedded development space. They can bring their own hardware or software, and we provide a lot of this sort of CI, test loop, security, infrastructure like that. You would have to hire several engineers to provide. My talk today is going to center around AT-based modems and their integration into the Zephyr RTOS. We're going to start with what's there currently, what was there prior to current. The stuff that mainly we're focusing on is going to be released with the 2.0 release. Just to show hands, who's familiar with Zephyr? All right, good, good. Who's familiar with AT-based modems? Oh, yeah, that's painful. All right. So without further ado, we're going to talk about several things here, and I'm going to try to get through it so we save some time at the end to kind of talk about your particular questions or something you might be interested in. So I'm going to start with a survey, we'll kind of cover the basics of the networking stack in Zephyr. Two key features there in how they offload data that comes into that stack, because that's where modems kind of come in. You don't want to use all of the underpinnings of stuff that are already provided by the modems. We're also going to cover what was the original modem implementation with Zephyr 114 and how we've changed it for Zephyr 2.0 coming up here. I think it's going to be released August 30th. We're going to talk about that new implementation has several components. Why we did it that way, what we hope to gain, and how we hope to kind of ramp that out in the future. Then we're going to talk about which modems are currently covered by Zephyr as far as either in the mainline or a mainline-based SDK, as well as modems that are in products that are currently either going to be shipped soon or out there. And then we're going to talk about what comes next, and we'll take some questions. So before we, again, I'm going to tell a little story because I'm always fascinated as to how people get involved with various projects and why they come up with the idea to actually submit something like a modem layer or some helper driver for something like Zephyr. And for me, my engineering manager came to me one day and said, you know, this AT&T modem thing that happened to be a shield, it kind of went on an XP part. He said, that thing looks really cool. This LTEM, NBIOT, this thing looks really neat. We need to investigate it and see if it's something that we can sort of present as options for our products. And so I downloaded the software and I think it was Mbed OS or one of those other ones. Not to throw anybody under the bus, but every single sample that I went to load had the entire modem driver and was totally customized to do that one thing.  What if I want to do MQTT or LWM to M or all these other things? I've got to like magically put together all these pieces and craft this thing. And I think it came down to the fact that they didn't have a central way of taking the network stack and kind of intercepting it with the driver and leaving that as sort of core to Mbed OS. And so I started thinking I was already an implementer. I had brought in the LWM to M subsystem for Zephyr and I was thinking to myself, well, maybe we could do something. This is, maybe we could submit something that would kind of make life better and maybe unify it a little bit and see what we can get. And so that was my start in the Zephyr modem layer. And just to highlight the network stack here, you can kind of see how samples live on the very top. They access most of the protocol layers directly so you can initialize MQTT. You can start the LWM sort of client. And then those protocol layers actually act through the sockets layer that's been implemented fairly recently down through the network context layers. And you get into the core of the TCPIP UDP down onto the actual hardware type driver, whether it's Ethernet, 802.15.4, BLE6, low pan, et cetera. Now, I highlighted two options on the right there. And these are called offloaded APIs. And so for instance, what you're seeing a lot lately is that on the NCP, the network, whatever it is, if it's a Wi-Fi or an AT-based modem, they do that stack for you. So you don't necessarily want to let a lot of that stuff go down into this lower layer because you're just going to hand it off the modem and make a call and it's going to give you a response. And that's going to be the end of it. So they have two different methods of offloading that data. One is at the top, you have a socket-based offload API. And on the bottom, you have sort of this net offloaded API. And we're going to cover those in just a little bit of detail once we talk about how the original implementation was done versus the new one. So here is how the modem implementation looked in 114. You've kind of got the net offloaded APIs on the left. That's where the injections are. We intercept our calls for send, receive, connect, those sort of basic network calls. And you've got sort of the core modem driver in the middle managing everything. And then you have your hardware is on the right. You're writing the pins. You're reading off of, say, the GPIOs or you aren't to get responses. And then you can see how this happens to be a Sarah R4 modem driver utilizes its own command parser to take that data, parse it up, and then do something on it. What you ended up with is kind of a driver that does everything. It's very hard for people to say, hey, where can I contribute? Oh, I noticed you got a bug in your command parser. Do you submit it to each driver? Is it just gets messy? Because in the beginning, I think I talk about this a little later, but it was really only one or two drivers. And so it's not really very scalable or sustainable as far as really growing that subsystem. So what we did was we kind of rearranged things. This is sort of the new model for 2.0. At the heart of everything is something called a modem context driver. And this is a helper layer that just sort of keeps the public shareable portions of the modem functions, read, write, processing. And it's able to share that out with some of the other subsystems. Right now, it really only works with sort of the modem shell, so you can actually send commands to the modem. But it doesn't know anything about that modem other than the fact that it exists. It has an ID number, and this is an API I can send a command to. Everything else happens kind of under the wheels. So you'll notice that in this other version, we used the net offload here. That's actually been changed. We now use the socket offload. And I'll cover those APIs and why we made that choice. Not only does the actual modem driver is kind of off to the left here. The main goal for the modem driver now is to configure everything underneath that modem context, hand it off, and just get callbacks. As commands come in, they get handled, there's a lot of surface area where the community can contribute. And you'll notice that those sort of four things around the center off of the modem context are really what we're going to be focusing today. There's like modem socket kind of abstraction. There's modem pins. You've got the command parser. And then hopefully power control, which would get into like EDRX or low power modes on the modems in the future. Because that's really what I think that's most interesting right now, is if you're going to use a low bandwidth, low resource usage modem, you kind of want to put it in the lowest power mode you can. Turns out we didn't quite get to everything. So the modem pins and sockets aren't really attached very well to the context. So in this first version that I'm going to talk about, that's kind of what it looks like right now. They really are just bolt-ons onto the driver. They set them up. We're going to probably move more and more into the center and hopefully get a better look there. But we are moving forward and hopefully it'll be better for contributions and everything. Next thing I'm going to talk about is this concept of offloaded APIs. And what I wanted to kind of start with is this is the past. This is the kind of access you had in these net offload APIs. You had things like get, bind, listen, connect, accept, send, receive. These are very basic network commands. They don't give you access to much else. And the kind of other things that we're talking about, I'll cover in a sec, but they also used kind of these cryptic parameters. So it's a net context. And you had to have this net package structure that you passed in. And that thing's like a linked list of buffers. It all made for very bloated drivers, very hard to handle. Iterating through these things and trying to sort it was really kind of a pain in the butt. This is where we move to the socket APIs. So this is a POSIX-based. I don't want to say it's compliant, because that's kind of a wiggly word. But you'll notice that if the functions that are offloaded, you actually have kind of some interesting other options. And a lot of modems or AT-based command sets, they provide things like TLS setup or DNS calls.  Whereas in the other layer, you almost couldn't do it. And so it was really frustrating at times for to implement certain modems. The thing you're handing around is not some cryptic net context. It's just a file descriptor, just like any other POSIX system. You hand that thing off, and it just makes sense when it enters and leaves the modem driver. That you turn around and hand that off to all of these offloaded APIs, and everything kind of stays in sync. The kind of network data that you're handing around is just buffers. These are just char pointers. They're very easy to handle. There's no sort of iteration through linked lists or trying to do funky allocation and freeing up of all this stuff. And so I think this is actually going to simplify the drivers over time. You're going to get a lot less bugs. And in many cases, you might even be able to port existing code because of the way it sort of POSIX-based. The other thing I noticed is a lot of these AT-based command modems really try to mimic the socket workflow. So when you create a connection, it gives you kind of a number back, and that's your socket number. And then every time you write to that connection, you've got to reference that number. And it's a lot like using sockets. So it just mirrored that workflow a lot better. We're going to talk about what the original idea of having a modem helper layer was.  This is the first thing that got submitted with the first modem driver. And it was done back in August of 2018, way, way back. And it was ancient for Zephyr. And it was submitted along the time, the very first modem driver that I did for that Wistron modem that we got from AT&T. It's just very simple. It's a tight loop. It handles an ISR. It offloads the data off the UART as fast as it possibly can into kind of a thread safe ring buffer. And then it's up to the modem driver to call back in and say, hey, do you have more data? When he has time, can I just receive something? And if nothing's there, fine, move on. If so, I'll grab it. And then basically once the modem driver got that data, everything else was handled in the driver. Everything was about the modem receiver was very UART specific. It didn't allow much abstraction. Like you had public and private data. There's semaphores in there. It's all kind of messed up. And unfortunately, now that has to live in there a while because there are other drivers that are using it. So now we have our problem. I want to submit a new driver. Maybe I want to change that implementation a little bit. The community started kind of like, hey, how would I do this? And maybe my thing needs to be tweaked a little. And I realized we kind of have a problem. Nowhere to land bug fixes. It's confusing as far as, what if I want to change a parser? Who do I copy paste everything? How do I set up a new one? There really was no future with that system. So let's do something better. Earlier this month, I actually finalized the contribution that landed in Zephyr for 2.0. And it centers around this concept of a modem context. You're taking a series of these underlying objects. You're configuring them. You have several different implementations. They have both public and private structures there. So in a modem context, it's what's public. So you get a basic read and write abstraction for the modem interface. You have a really basic process abstraction. For once you get that data, you hand it off to your command parser. And then you have some kind of helper layers in the pin config. And that's where I was talking about pin config. It's not really. We're getting there. It'll be better and better. Basically, what that did was it stopped all this boiler code from people having to import the GPIO layer and do all these other things. It just makes it a little easier. And then when you compare the new modem interface with what was the modem receiver, the biggest thing was what happens if we don't have a UART-based modem? How would we treat that? So if you have the public read and write APIs and you leave the private data up to each implementation, then you have the option of adding more. And that allows the community to really go crazy on it. The first implementation is clearly a UART-based implementation. So all it does is assigns itself the read and write functions. It has all of its own private little semaphore ring buffer. It's very similar to what was the modem receiver, but it allows other things to coexist. And what happens, as the modem drivers get more fully fledged, it's almost going to be like a buffet table of mix and match objects here. And as I described the other parts, you have to imagine I'm writing a modem driver. I'm going to take that piece, that piece, and that piece. I'm going to link them all up to the modem context and hand it off now. And everything just runs. We'll talk about the idea of centralizing command parsing and what it actually is. It's really tricky when you get into AT modems. You've got to deal with these carriage returns. And so you're sending a command. And you kind of need to wait for the right response. And so when I sat down and I tried to abstract this out and I wanted to make sure this is something the community can kind of help, I came up with that sort of generic sort of process. So at its heart, every driver has kind of a receive loop. And once they get data back from the interface, they just hand it off to the command parser that they've chosen. The initial command parser deals with very straightforward AT based commands. It uses carriage returns. But it does a lot of nice things. And I'll get into, how does this look? Basically, there's a define called modem command define, which is basically establishing this is going to be a callback. You then create three kinds of responses. So one response is a generic response. It's a OK. I had an error. Something maybe even extended error. And that's what I'm defining right here in the response commands. And then you have unsolicited commands. These are like, hey, there's some data ready to read. Or hey, you're now registered on the network. Or these are kind of things that you can't expect or wait for. And then there's a third kind of responses. That's the response to the command you're actually sending at the moment. And that's the one you're actually waiting on. So in a way, you can handle your unsolicited. I call the response commands at the top kind of those are the enders. Those are the ones that say, yep, I got what I wanted. Hopefully, in the middle, you were able to get some data out of that and use it. Because that's what triggers. Say, for instance, you're going to send a command to read the manufacturer data. In the middle of that, you're going to get that manufacturer data. It's going to hit the command callback. And then it's going to hit the OK. And the OK says, give up the semaphore. Let's move on. That command has been successful. Or it had an error. You'll notice that there's some interesting parameters here. The modem define defines the handler. The modem command itself matches what it's looking for with how many parameters you're going to get back from it and what the delimiter is. And that's why you're seeing this string of data there. And what that does is it actually handles kind of like an argv pointer, an array of strings back. So you don't have to sit there and iterate through that data looking for things. If you have your right delimiter, you get the right array of commands that you're looking for. You just grab it and copy it. It actually chews up a lot of the boilerplate that was ending up in the modem drivers that each one was implementing specifically. This is just going to talk about the config helper a little bit. Because every modem seems to have like a power, a reset, or some kind of generic. Sometimes there are GPOs to put it in low power mode. What I found was a lot of people had a lot of different code in there doing different ways to control the modem. And what I found was we want to encourage the right behavior. So in the example that I'm the one that we set up for this first iteration, we use DTS. And so the DTS portion here is actually coming from the binding. It's set up for that modem. It generates this sort of standard define. And that ended up with your controller number, the pin number, flags potentially. You put that in a nice big array. You can use it in a num. And then you can make generic modem pin writes. You turn things on, turn things off. If you have to wait for an interrupt, it could get a little more complicated. But at least this means you didn't have to deal with all the GPIO stuff that you end up setting up in Zephyr. Am I going too quick? No? Good? All right. Let's talk about what those socket offload APIs look in actual code. And so remember how I said, these are sort of positive space. You have a socket call, which allocates the FD. You've got a socket close where you pass the FD back and you're giving it up. These actually end up as functions with sort of these parameters where you then translate that into the AT modem command. And so in some point, you're probably you're busting out that text back on. OK, here's my, you create, sock, whatever. It seems like every modem has a different set of commands to manage this part of it. There's no 3GPP standard for all the socket-based network communication. But then what you do is you assign those functions to this offload structure. And you do have to register it at the bottom there. So somewhere in your modem in it, you're going to call register. It then says, ah, I need to intercept all this stuff. And instead of pushing it down the stack, I can deliver it over here. And it's actually really cool. You can turn off the stack at that point. And it makes your code size small. It's kind of neat that you can actually put these modems on very, very tiny devices. The next thing I'm going to talk about is how to get started. I know a lot of people on Slack and on IRC have like, I'm confused. I know I could probably build this modem driver. And I could connect it right up to your LWM time client. And that would be great. But I mean, I want to do that. I don't want this thing to all of a sudden try to get and receive data. I want to sit and maybe just tinker with it a little bit. And so here's some helpful tips. You're going to have to get your AT command reference, first of all, and get real familiar with it, especially the networking portions of it. How to create a socket, how to send data. Do you have limits on that data? Does it need to be hex encoded? All that sort of stuff you're going to have to know. The next part is really get familiar with the Sarah R4 modem driver. That's the first modem driver that really uses this modem context setup. There's not going to be much that you can copy and paste from it, but you can certainly set your driver up the same way. As far as here's your handlers, here's how you squash them down into an array and hand them off. That driver is probably going to get you on a good start. Here's some helpful config items. I love to enable modem shell. I think it's a great way to play with the modem. And I like to play the hello. So I'll compile the hello world sample, which literally prints hello world and stops. But meanwhile, behind the scenes, the modem shell is still running. You can send AT commands. You can watch for responses. You can really play with the modem driver a little bit. And what I'm illustrating at the bottom here, if you're familiar with Zephyr and the West Build System, you can actually tack on config items on the fly after the double hyphen. So I'm actually not running an overlay config to enable the modem. I'm literally just enabling the modem with all these commands. And you can do that with any sample in the Zephyr library. And there's a link to the Sarah R4 modem driver there at the bottom. So we're going to step away from the technical stuff a little bit, and we're going to back up. Here is basic lists of just which modems are covered in Zephyr right now. This is the original AT&T IoT starter kit. It's a WishDrawn modem. The AT commands are a little sketchy at times. There's a lot of workarounds. I'm not recommending people necessarily jump into this one. If you already had some investment there, you might want to take a look at this. The one thing I will point out is the first two are actually shields. And you can, any piece of Zephyr that has Arduino headers, and it has the DTS defined for them, these shields also have matching defines so that you can mate them via the Arduino headers. And it will just work if you specify it in the shield parameter there. We spent a lot of time really trying to abstract the shield layers out. And I think you can really see the benefit on these. This one and the next one, this is the one I kind of liked the toy with. And I would recommend if somebody does want to jump in and have a good time with it. This one is a SparkFun product that they took a Sarah R4 modem. They slapped it on our Arduino header. You only really have two pins plus the UArts. It's very easy to play with. It doesn't matter whether you have a Nordic dev kit that has Arduino headers. You can have the Freedom board which has Arduino headers, or you could have an SDM part that has Arduino headers. It'll pretty much work with almost anything, as long as you get the DTS. Actually, in this case, it's all taken for you. This one in particular, if you literally run it for any of the networking samples, it should just work. If it doesn't, it can hunt me down. And you lied to me.  This is an interesting one. And I wanted to talk about this one a little bit. This is a brand new product from Nordic or fairly new. It's a system on a package, the 9160. They use a Zephyr-based SDK. It's one of the first companies that actually has taken Zephyr, adapted it into their software development kit directly. They have all of their own samples written for this that are literally going to work out of the box. It's a really neat, they're really leveraging their SDK plus really well-built network samples. They have a cloud-based connector. I helped them get the LWM-TEM client up and working for this. It's kind of fun. I mean, if you guys have worked on Nordic dev kits, this is just like a dev kit style, but with the modem part included. It doesn't have BLE or any of the other things included. But it's that sort of same form factor. And the last one I'm talking about, so this is not a modem that's actually supported in Mainline. This is an actual product where they chose to implement it using Zephyr as the driver. And they hand that as the software piece out for people that are looking to customize the modem in some way or run some sort of custom software. I thought it was interesting because I communicated with this guy for a quarter of a while on the current modem driver and how we were going to make it better. And he was super excited. He was like, I'm not going to touch that because we're going to ship this thing and we're going to get it out the door. But I want to talk to you later. So I did want to mention it. Hopefully he's going to submit the actual driver to Mainland Zephyr here pretty soon. Maybe it'll get in for 2.1. But this is an interesting product. And again, they're going to hand Zephyr out as sort of the out-of-the-box demo that you can code on this. So now that we've covered all that, what's next? Clearly, I had a couple of fibs in my diagram there that we're going to try to work on. We should really abstract that network layer, the socket-based connections to it. So it's easier. There's a lot of boilerplate stuff in there. It just doesn't need to be in the drivers. We need to move more and more into the context so that the hard work of building the driver that shouldn't be there isn't there. We need to support the low power modes. One of the guys had a really interesting idea of actually being able to, one config, enable a bunch of standard 3GPP out-of-the-box modem commands, set up as handlers already. So for instance, a lot of reading the manufacturer data, the model, all of that stuff is set in stone. It's part of the standard. It should just work. So if we were to have a 3GPP layer, you would actually cut your probably modem driver in half. All those handlers would just exist. There's some other really interesting ideas of creating a new interface called a dummy interface. And then you would have a dummy modem driver. And what you're doing there is you're feeding data in and making sure that you get the right responses from command parsers. Or we would use it as more of like CI, make sure that we didn't break the modem layer. We need to work on that. There's some storage configuration for APN data and things like that. We need if you could just bolt that on the bottom. I know a lot of modems have internal storage for that. But if you wanted to do something special in this effort to kind of feed configurations into that, it would be interesting. And now we're open for drivers. I mean, it's more about as people get interested, you pick a driver, and it's not as hard as you might think. Once you get used to the code, it should be easier. It could not at least you have a place to post bugs. If you see problem, you can actually post it on the mailing list or post it up on the Git site. And with that, I'm going to open it to questions. Let's see if somebody has something specific as far as something you were interested in. Right here. That's right. They have an add-on. It's interesting. I think it's AT-based commands. So what would be fascinating for me is to someone that would pick the GPS module up, they do the add-on, and then perhaps write a subset of commands to work with GPS, and then you can enable it via config. And it would almost work with any of the CERA modules. The CERA R4 module happens to work with the U2 module as well, which was an interesting contribution. But that's a great idea, I think, is enabling GPS via that. Several of the modems have those type of add-ons as well, not just the CERAs. Was there any other questions? It really is. And as soon as you say, oh, no, it's POSIX compliant. And then they'll be like, wait a minute, you don't do this, and you don't handle this. So I hesitate to use POSIX compliant as a word. It is POSIX-esque. It is POSIX, and you should be very comfortable using those commands. They're going to give you a file descriptor. They're going to do the things they should do. I just didn't want to step on any. You can get into arguments real, real quick. It's almost as bad as tabs versus spaces once you step in the POSIX space. Absolutely. And there's code out there. And Zephyr has made a huge effort to become more and more POSIX compliant. And I think it's definitely stepped in the right direction because you're getting code reuse. You're not trying to reinvent the wheel. And there's so many of the drivers are already out there. Why not leverage them? It was more about implementing the reference. You're correct for the socket type stuff. Actually, what I meant was the 3GPP has a standard set of AT commands that almost every modem implements. And so I felt it might be interesting if we had a layer that you could just turn on, and it would automatically pre-query like the ops that you're connected to. It might actually pre-configure some of the past in commands and stuff and automatically be able to query the manufacturer info, the software version, things like that. It gets a little weird when you're implementing the OK error parts that are so specific to your driver, depending on are you waiting on something back and things like that. But I thought it might actually reduce the size of the drivers quite a bit. That was the 3GPP reference that I was talking about. I think the idea is that you're going to clear it out any time you do a receive call. So at that point, the driver's ready to handle data. The neat part is so if you get into the details here, the implementations have their own buffer sizes. So the ring buffer is one thing just to get the data off the york, because it doesn't stay there forever. And if you leave it on too long, you're generating ISRs. And so you want to get out of that context very, very quickly. The driver needs to then have its own processing buffer that's specific to the command parser. And that can be oftentimes a lot bigger than the ring buffer, because you might get half an AT command response. You might get a whole one. And whatever doesn't get processed in the current implementation actually gets left in there so that it gets picked up the next time. But that's a great question. Every driver might need different size buffers. And that's why we allowed the driver itself to configure all of the sort of private data for each component. And then when it registers it with the modem context, it's accessible then. So the command buffer has several different configurable items. And it's something that we're going to have to do a better job, I think, of documenting.  And typically, it revolves around the max length size. In the particular in the SARA R4, I think it's 1024 is the max sort of receive size. And that's what you'll see in the buffers. It reflects that. You have to, right? I love the fact that you brought this up, because the idea behind splitting out a UART specific implementation for the interface was that you might encounter exactly that. There might be another way to get the data.  But USB is actually a really great way, because you do see that implemented on a lot of the modems. And if you have sort of that sort of read and write methods that still apply, I don't know if they actually still apply when you get into USB, you might actually be doing more Ioc-tile type calls in the Linux side. Maybe it does end up being like a send and receive. It is a read. So you get one at a time, you get packets. OK, I love it, great. I would love to see somebody implement a USB interface for this particular, because that would just open up a whole another wave of drivers. So that just lets me know maybe we did the right thing. Was there a specific modem where you mentioned? Did they make a recommendation on which one to use if you're going to have certain use cases? It's usually the bands, too, that they support sometimes. I was thinking actually, I don't know how easy it is to do low power on USB.  Sometimes they go, if you're going to do low power, recommend UART. It's easy to turn the UART, like IP, off in many cases. But that brings us to what's next. I mean, there's things like, so I can tell you right now there are about four modem drivers in works. The one that I mentioned for the pinnacle is the one that's probably the closest. There was another modem driver written for, I think, one of the Qualcomm modems, which I thought was really interesting. Hopefully, he gets that up and running pretty quickly. And there were two others where I think they mentioned it, but I may have forgotten. So we'll see how quickly they can adopt sort of that. Because I really wanted to see new submissions using this. I don't want people to keep writing these sort of copy-paste drivers and really hard to manage. So we'll see how quickly they come up. But I think the more example drivers using this, it's actually going to get the snowball rolling. People are going to have an easier time implementing them. There'll be a lot of really good examples. I would love to see a USB implementation. Any other questions? All right. Well, with that, have a good afternoon.


Hi, my name is Danielle and I work here at the Center for Visual Art. I would like to talk today about one of my favorite works in our current exhibition by Carlos Raskos. It's this work behind me called El Corido Cosmica. When you walk in the room, it's one of the first things that catches your eye. And it's also situated among other works in the room that deal with a consistent theme in Carlos's work, which is Nature's Future. And that's the idea that the past or the present or the future are all co-existing in sort of merging timelines. And he illustrates that in this painting by pairing some art historical references like Rene Magritte's hat and this character that's reminiscent of Picasso with some characters from ancient history like this Nazel American figure. That's why I love the piece. So please come check it out in person. The show runs through March 24th and leave us a comment.


Well very pleased to be here today to talk about a civil forfeiture grant and obviously Touchstone has made a big difference in the lives of young people particularly those that are at risk of joining a gang so we're very pleased that they are the recipients of $210,000 through our civil forfeiture grant program to ensure that this program has sustainability over the next three years. Not going to school not caring who needs school if easy money is to be made right and to transition to waking up at 9 o'clock in the morning part-time job self-study doing some hobbies eating with my family treating them out to lunch when I get my paycheck you know that feeling of being self-satisfied that you know I'm also making money and doing something good for the community and helping out other kids that do need help. A very successful program $5.5 million in this round of applications seeing programs supported right across British Columbia. Great community partnerships making a difference.


Rheumatoid arthritis, i, is a chronic inflammatory disease affecting multiple organs and systems. It is characterized by persistent synovitis, joint destruction, and functional impairment. Recent advances have provided insight into the underlying causes of i, with particular focus on the role of immunologic and genetic factors. Research has identified several key signaling pathways involved in the development and progression of i, as well as potential drug targets. This review summarizes the current state of knowledge regarding these pathways and their potential use in the development of novel treatments. This article was authored by Chen Ding, Wei Hu, Ran Wang, and others.


What's up guys, Michael Roojaspi is doing a quick recap for our eight box baseball mixer containing 2015 Bowman Chrome, 22 Bowman Chrome, 22 luminaries, top scrum jumbo and a bunch more. You guys will see the hits here but here is the list and then if you look just to your right you'll see a little message from Joe Jaspi that says hello and then right under it Jason's response, hey this was done live on the stream just through Google Sheets. You up? Yeah, anyway some of the hits you guys came for, not that, Will Benson auto, Nolan Gorman this was very nice, Blue Lava out of 150, Rookie Auto and some other stuff, Jonathan Ronda, Rookie Auto, Robin Yant Relic, Stanton Relic, Joey Gallo Relic and then from 2015 Bowman Chrome, Michael De Leon, first auto, 2022 Bowman Chrome, Tyler Collins, Green Auto out of 99 and then Jorge Barosta, first Bowman auto, starting Marte Gold, some other parallels Spencer Steer out of 99, Oscar Gonzalez out of 350, other stuff, there's a Correa Rookie car, T. Oscar Hernandez Relic, this was interesting here, Ronnie Williams, first Bowman auto, that's 5 of 10 but it's 2014, this is 2014, came out of 2015 and then some randomizers we had to do and then from luminaries we got Edgar Martinez Home Run Kings 1 out of 15 and a Gold Rush Vintage Box hit this beauty, 1968 tops, Mickey Mantle, graded a Beckett 5 by Beckett Vintage Grading, not bad for a car like that, very nice car, but yeah that does it for the recap, thank you to everyone who got into the break, thank you guys for watching and I'll see you guys in the next one, bye guys.