 All right, so I guess we can start. My name is Luis von Denz, I work for Intel in OTC in Finland. So I'm gonna be presenting about Luzi meets Zephyr. It's more like a tutorial on how we use the tools of Luzi to develop Zephyr sample application and testing. A little bit of voice coding resolution. Yeah, maybe just do like that. Okay, so a little bit of my background. I started contributing to Luzi in 2006 while I was working for a Brazilian company. I'm in the team in Brazil. So then I helped design the Bluetooth audio subsystem in Linux, connecting Luzi with both audio to actually hand away to DP connections and whatnot in classic. Then later 2009, I joined Nokia and moved to Finland to start working with, at that time I was still in Miami and then later on become MIGO. And then later on 2011, well I guess everybody know what happens in 2011 regarding MIGO, I moved to Intel OTC and then start working for Intel. 2013 I became the user space maintainer of Luzi in quite a while in Luzi community and mainly maintaining and doing other stuff for Luzi, other profiles and whatnot, especially automotive. I was heavily involved with automotive until last year and then later last year I joined the Zephyr Bluetooth subsystem where we started doing the Zephyr Bluetooth the early stages bringing up the subsystem to what it is now. Let's see how we switch. I'll write a little bit about the agenda. I'm gonna start explaining what tools we use to well develop Zephyr applications and what they do and how useful they are to actually develop new applications and debug and do other testing that might be useful at least in the prototyping stage and later on even qualification. Then I'm gonna talk about Zephyr tests in samples that we currently have in Zephyr. They are quite extensive actually. A little bit of demos if everything works well now that we arrange the presentation and then finally the test automation. What are the tests that we are executing and whatnot and regarding a little bit the qualification. So well let's start with the Bluezy big picture. Well the presentation is not really about Bluezy but I guess it's a good idea to show what the Bluezy is capable of because a lot of times people may confuse okay Bluezy is just the user space or it's the kernel space and we have a lot of modularity and we can use a lot of the Bluetooth subsystem in the kernel to write tools and other stuff. So that's why it's important especially like things like HCI on the kernel and other models like Sixlopan and whatnot that are coming up. So we can actually do testing with Zephyr with Linux as well and then test each other. So it's kind of a good synergy between the Linux subsystem and then Zephyr subsystem so we can actually share a lot of tools and do a lot of testing with each other. So well I guess everybody knows or should already seen this picture before we have in the user space. We have the Bluetooth of the demon. There is a lot of plugins and even you can connect external profiles nowadays. On top of that we have Obex although this is not really relevant for this presentation. In the kernel space we have a lot of things that we actually may use the measurement for actually tuning up the controller. So it's low level access for a adapter connected to the system. And then we have all the basic profiles and that are implemented there. AutoCAP including connection oriented channels that we use for 6.1 and then the drivers and whatnot. So it's quite easy to actually hook USB dongle and then do stuff with it even if you're gonna use directly on your host or if you're gonna use for example with KMO and then another virtual machine maybe running Zephyr or something else. Okay so one of the first or the first tool we're gonna explain is the BT Proxy. It's under tools BT Proxy in user space. It uses the user channel. The users channel is well it's quite neat because we can actually open a socket with the kernel saying okay I want this controller adapter to have, I want to have exclusive access to this adapter. So it shuts down all the other parts of the stack and then just leave up to the tool to actually deal with the controller. So in this case we can actually then use it for the user channel to create a HI UART proxy so you can actually start proxying HI events directly with the controller and then interacting in some other manner. So in that case you can actually use this to forward your controller to a virtual machine like running Zephyr and then it can just start doing your drivers with that. So it's very interesting also support TCP. So if you want to do with another host you can actually do it with another host. So it's really useful and has been used like since beginning for us when we start doing the Bluetooth subsystem because then we don't depend on actually doing any kind of having real hardware to ramp up the HI driver stack. Of course we want more support for that for and whatnot but this kind of prototyping this is like much faster because you don't have to deal with any details of like the board doesn't work or there is something the GPIO or something that is missing. This is just cutting like a lot of time for prototyping. You just use this tool and then just go with it. And then another one that is really, really nice is our emulation. So those we actually have for emulation of HI which is really, really useful. So instead of just having kind of any controller that you could hook up for example with a BT proxy and then forward to the virtual machine you can actually emulate a virtual controller and then use BT proxy. So in that case you don't need any hardware it's just a full emulation of HI on software. And in fact we also have this HI MO instance that can create then, create this internally this BT depth they are connected together when you create these instances so they can see each other if you advertise or attempt to connect. They can see each other like they are in the same network. And then on top of that we have like a kind of second stack that's called BT host that has much lower access to the stack is kind of raw mode. And then you can create invalid test cases using that. So we can fully automate kind of any kind of test with that because it's completely not, well it doesn't have even to follow the Bluetooth specification because it's just a talking role, HI there and then you can send like, well do invalid tests and whatnot. So it's really useful. And then it's using the Bluetooth system, the VHI to create virtual controllers. So and this has been for a while there and we have support for all the LE HI commands as well as the classic. So it's fully supported and it's been quite handy to actually test new stuff that, well maybe if we don't have like commands for let's say Bluetooth 5 or any upcoming Bluetooth specification you can actually implement first in the emulator and then try it out first with the emulator. So you don't actually need to bring your, have the real hardware ready all the time. You can actually do the testing with the emulator first. Prototyping becomes really easy with that. All right, so moving next. Okay, so this is another one that's, it really has been evolving recently. It's the BT monitor. It's a full HCI tracer that it was, before we used to have the HI dump but the HIN dump couldn't decode actually the neat sequence because the kernel would first do the neat sequence and only then you could see the adapter and then monitor it. So we would like to see the neat sequence which is actually quite useful when we are doing a kind of new driver or something. You see what, if there is any errors in the neat sequence or kind of the firmware doesn't load or other things then now you can see with the monitor. It can include also logs, other logs that you may have like if Bluetooth crashes or something can actually log in the tool. So not only you see the HI traces but also if they're causing any kind of crash then you're gonna just report right in the tool. I'm gonna show it more in the demos. So you're gonna see how it actually decodes everything and can see the traffic and whatnot. It can also save in the file so it uses the well-known format called bitisnup for storing the logs and then you can even use Wireshark to decode this. So it's both useful for like doing a real-time monitoring of the packets or you can actually store this for later and check if there's something wrong with the logs or something, you can actually do that as well. And then later on because the things we were doing with Zephyr it's starting to support also TTY. So if you have like a serial console with your board or I mean your virtual machine or whatnot, you can actually connect this and see the logs from the remote board. So it doesn't, the Zephyr doesn't need to actually have a full HIL decoder because we can just use the Linux one to do that including saving the file or something like that. So it's really easy to debug problems using this feature. All right, so let's move on. Okay, well the measurement interface is a bit management. This is not that relevant for Zephyr in itself but if you want to tune some settings or something like that on the Linux side you can use a bit management for example to turn it in a single mode or something like that. So it's a much more lower level than what we have in Buzzi Debase API for example but then you can do a lot of more stuff and well you can basically do most of the HIL layer and more because it has full access to the kernel side. Of course then it requires permission to do that because it can do things like advertising and whatnot that may interfere with the usage of Bluetooth D. So it's usually you go with either these or you run Bluetooth D separately and then use Debase Client to actually control it. So they don't interfere with each other. That's probably the usual operation of the tools, the Buzzi APIs. The next one is the Bluetooth CTL. So this one also come a long way so we have been introducing more and more commands to it. It's a command line tool that you can control Bluetooth D and then you can start things like scanning, advertising, connect pair and even the gut operations is all supported so you can test pretty much everything that Buzzi offers over Debase. And then of course this is used to interact with the Zephyra in the other end and that's why I'm bringing this up because a lot of times you start an application and you don't know how to test it or sometimes you need to install something on your phone like the Nordic application that do this kind of gut browsing or whatnot but you cannot compare side by side with this you can actually compare side by side what is the results on each other so when connecting or when scanning what's the latency of how often it's showing, et cetera. So it's really useful especially if you don't have a UI environment or something like that. Yeah, it replaced the GAT2 as well. Yeah, yeah, yeah. So the measurement interface actually replace a lot of these raw HII access that we used to have so most of the tools starting with HII are now deprecated because of that so we use the measurement tool to do most of it and then for like higher level like the GAT2 we use Bluetooth CTL now can do most of it already. It's Bluetooth CTL. I'm actually gonna show in the demo so you're gonna be a bit more clear what it is, all right? All right, so let's continue with Zephyr. What's the main point here, right? So in Zephyr we have like a lot of tests and samples. For tests we have two main ones, we have the shell which you can use for like testing almost or pretty much everything that we have in the Zephyr APIs. So you can do advertisement, you can do scanning and et cetera, GAT and whatnot, AutoCAP as well. And we have the tester. The tester is quite special as well because the tester implements our automation with PTS which I'm gonna talk a little bit more later about the PTS test automation but the test is for that. So we have, it's quite big. It actually have interface to program what you want in the GAT database and et cetera. So this can actually be connected with PTS and go back and forth. For the samples we have the minimal one is the beacon. It basically beacons Edstone URL. So you can see like Zephyr website as the beacon. We have the central that does the testing the central APIs so you can actually connect to a peripheral or something like that. We have the Edstone. The Edstone there is actually for configuration. So it actually does more than just the beacon. You can configure it with a different URL et cetera. It's still not complete. There is still this pending support for some of the locking and unlocking logic that they have and then it uses security actually to lock it and whatnot. So it's still pending completion for that. So for now you're gonna advertise for with the Edstone configuration service for about 30 seconds and then turn back to a beacon mode it's basically beacon Edstone URL. And then we have IPSP. So six Lopan support over Bluetooth. We do have support for either the old stack or I mean the contiki stack that we used to we still have in Zephyr. And I'm working on to add support for the upcoming native stack. So that's still ongoing of course and there's a talk even about that later today by Yucca. And well, I'm gonna try even to show a demo about that and show how is this state right now, what you can do with it. And then we have a bunch of peripherals. We have heart rate. We have HID service. Although the HID service is right now is not doing much because it's just emulating a mouse. So we have the USB descriptor you connect to it. You can see that is a mouse but it doesn't move or do anything. So we're missing integration with some sort of sensor but the main point was to exercise Bluetooth which it does, right? So that's pretty much what we have in terms of what the tests and samples we have. And of course, if anybody has another idea for a good sample, you'll welcome any samples that people might use for exercising our APIs. Okay, a little bit more about the beacon. Well, that's basically explaining what the advertising API does. So currently we have a kind of, well, almost raw interface but we have some macros to actually define what is the data that goes into the advertisement packet. So this is actually what the beacon is doing. It's adding this data to the advertisement and it's starting the advertisement and that's how you can get the Zephyr URL going. For the peripherals, you basically define and got database. So you define for, in this case, is a heart rate monitor, service, sorry. We have a set of macros to define what is the characteristics, the descriptors, the CCC, so you can actually do a notification with it. And then you define the permissions for each of the attributes. Some permissions may require, for example, authentication, encryption, et cetera. So this is, well, the periphery API for GAT is basically doing that. So you can see you define a table and it actually becomes the service there. When the remote do a discovery, it's actually gonna figure out what is the handles of this which we generate when we register the table and then it can actually access each of the attributes doing that. So it's quite simple and well, we decide to put this actually on this, that's in the application side because then we don't have to define like a size of a database ourselves with a K-config. So it's not as strict on the K-config. It's the application will have enough memory and once you define a huge database, you can do that or it can even split between files. So it becomes more like a list of a different service. So you can do that as well. All right, so let's see if I can show us some demos here. The beacon? Perfect, okay. Yes, it can. We are not using section right now, but we could, in theory we could. Yeah, yeah. Yeah, this one is using a link list. We have a K-config saying, okay, it's a dynamic database so it actually can use a link list for that. Yes. Okay, let's try the demo then. Okay, so on the bottom, I actually set up the root of monitor to monitor the controller. So I have two virtual controllers that gonna talk to each other using the emulation. You can see that even the text that's a virtual adapters, both on the bottom. And then here, I'm gonna try to run the, let's see if I can run it. So this is, oh, let me switch to this one first. Want to show the shell first. Well, it's the same setup. You can see that it's doing the same setup for foreshowing what is the traces where it's gonna appear in the bottom. And then I have, in this, in the left side, your left side, is there is the Bluetooth CTL, so it's the Linux box running in the left side and then on the right side is Zephyr gonna be running. Okay, so let's see if the demo effect is gonna work or not. Okay. So let's start, well, there is a bunch of commands that you can do with the shell. It's almost exercising, as I said before, almost exercising our API. So we have like really almost everything there. So every time we add a new API or a new feature, we might actually change the shell, so we include that. So you can do authentication with that. You can do connections, you can do guides. You can even do AutoCup with that. So the first thing normally you do, you do init. And then you see right in the bottom that it's doing init already. It's showing the init sequence here. So you can see all the commands. I hope you can see. Virtual controller, all virtual. It's doing the init sequence. So it's initialized as it is even using a temporary or, I mean, it's using RQ to generate a private address. So, and then if I advertise, actually let me start scanning. So I can just scan. Oops, this is what I'm not doing. That's a real device, yeah. That's a demo effect. So I want probably this one. So I have another two dongles going to connect to me. That's why it's showing so many. I'm gonna select this. So as you can see, but the city actually support multiple adapters. So we can actually switch back. So the adapter we want to test. I mean, the do is scanning, it's scoring, then I advertise here. Then we have the test shell there. And you can connect to it. You see it's not even using the same address that was configured initially because it's using a private address. So you can see it's already different. And then you go into connect, and then it's connected. And then from here you can also, well, can do a disconnect for example. And then if I want to show, for example, the heart rate monitor simulation. Oops. Yeah, okay. So it started. So it's on. Ah, it's already advertising. Yeah, okay. Now it's connected. And then let's expand this one. So we have heart rate monitor now. And you can access this. So we have like, as I said, the API has evolved. So you can actually access the measurement. You can access this one. And then you can do notify on. And then it should start notifying. So this is all running with the emulation. So if I do this, you can see on the bottom they are transferred to each other. And with the shell actually you can do the opposite as well. You can connect as a central. So it's not only doing peripheral, it's also doing central. So you can test pretty much everything. And use the space. We have the emulation code under blue Z3 under emulator. So there you can see all the code, what it's doing. And then we also have this kind of simulated stack, a BT host there. So you can do other tests if you want. So now disconnect, okay? Now it's disconnected. So, well, let's try something more advanced or at least that the latest thing I've been trying. I don't think we emulate like per spec, but the HCI emulation, right? The timing may be different. Actually it's different, right? Not gonna do kind of add the latencies of the going over the radio and et cetera. It's basically a socket pair or something like that. But for prototyping like a gut or something is just perfect because then you don't depend on any kind of hardware. Okay, let's see if I leave anything. Let's close this one. And then let's try the, well this is gonna be running the echo server from IP. It's basically to initialize the IP stack and then initialize the link layer with Bluetooth. So we can try IPSP with the new stack. Actually this is using the native stack. So this code is quite recent. Can do this. Okay, looks like it works. So we have initialize and then we have the AutoCup also initialize. So it's listing on the PSP and I think it's 35, if I'm not mistaken, of the IPSP. So now let's try to connect. So this is, well, I'm trying to connect from the NUCs machine. We don't have yet the full APIs for the main APIs to do this properly from Bluetooth T but otherwise it probably would be Bluetooth T that would initialize the connection to IPSP. So I have to use debug FS. This is actually documented on the samples. So you can see in the samples how to set up these in the IPSP with me. So I'm gonna start connecting to it. Nothing happened. There's two scanning here. Yeah, right. Let me, yeah, demo effect. Let me see if there is something here. But I stopped this one. Ah, this one was scanning. It shouldn't be a big deal but yeah, it might be that it's not the default anymore. Yeah, okay, I can figure. We can test this later on. It might be just the wrong adapter so it's not coming from the, it's not trying to connect from the virtual machine and then of course it doesn't find because it's emulated and never goes over there. I can figure out this later. So we can continue with the presentation. Okay, well done with the demos. So what else we have? We have the Bluetooth PTS for doing the qualification testing. Actually it's an official tool for doing qualification testing. It's provided by Bluetooth SIG. So it's basically the official way to do a qualification. It implements the test specification. So you can actually see from the test specification what tests are necessary for each of the profiles. As I said, it's mandatory if you want to qualify. Sometimes PTS doesn't implement all the test specification and then you have to provide the results yourself one way or the other. It's a Windows tool. So yeah, it's not gonna be able to at least run on Linux. So like not directly except you can run a virtual machine. It requires quite some level of expertise of knowing what the profile requires and stuff like that. It's very often that you have to kind of unpair and repair because something changes or PTS is confused by some of the service that you have before or stuff like that. So it's quite demanding. We were like measuring like a few days actually to compete test run for just get or something like that. So it is really demanding to do manual testing with PTS. But recently they introduced some means to do automation with their core API. Before it was basically doing, if I remember correctly, basically doing this dialogue automation. So you would have to know the dialogue each of the requests to accept or reject or whatever. So it was even harder. But now this is a bit better. Let's see if it keeps improving. So, well regarding the idea that we have to automate this we create this PTS automation framework. It probably not be the official name or we're still studying how we're gonna open source this but we intend to. The server is actually implemented in Python then the client as well. So the client run on a Linux box and of course the server has to be run on a Windows because it's well, talking to PTS. So that's the way it does. And then the implementation, it could be Zephyr, it could be other implementation like Linux as well. So we are trying to make it as generic as possible. So we can also test a blue Z as well. And then we have the BTP protocol or we call BTP protocol, boot of testing protocol to actually program what the test should be doing, what is the execution of the test and programming for example, what the database or data database should be present for that test and all this stuff like that. So the big picture is something like this. So we have the Windows host running PTS. It's talking over XML RPC to the Linux host and then the Linux host can be talking to the implementation itself with a BTP protocol. But you can actually or which could be Zephyr or some other implementation. So it could be emulated as well. If you're more real hardware, we have been testing actually both. So we know that it works with both. So it's the, well, basically the BTP is already there the tester applications already implemented the BTP protocol. So you can see what commands are there. It's documented on the source tree. We are just working now with a lot of sick to know well, when we can open source, how we can open source the solution. So it would make a lot of things much simpler for us for testing, maybe we could rerun the test every release or something and qualify or stuff like that. So at least we have where we know that is a qualification readiness of the stack. A little bit more the kind of the BTP protocol tester is as it's split in different services. So we have the core service that can register other service. For now we have the gap service for doing discovery connection and whatnot. Well, the gap procedure. We get the gap service that can register attributes and can also act as a client. So we can test both the server and the client side. And we have the outcome service. This is doing connection or in the channel. So we can do connections, send and receive data. This is what is used for doing IPSP for example. And we have been running this with PTS at least the tests that are implemented there. The BTP is more like our local solution to program just the interface with the OS itself. It's not the interface with the PTS. Well, I guess it's gonna be open source anyway. It's already, we already have this under Zephyr tree. Of course if people want to replicate the same protocol, we would be fine. It's probably useful. I mean, in that sense it's very useful. What would be trying to minimize the amount of code? The one that we control basically. Okay, so here's a bit of diagram. What the BTP is about. We have commands and response and then events if something has changed or some kind of notification or reports or something that is not requested by a command. So we also have events for that. So it's really simple. There's not much to actually explain about BTP. This is very simple interface to program the service there. A little bit of the test case example, how we run the test. So this is, for example, for GAP. Then we have the test name. This is basically coming from the test specification where you can see exactly what they are testing. And then we have a set of steps. How to do it. You can actually program some stuff like the, it's called PICSIT as the configuration of each of the tests. So you can configure what is the address and whatnot. So this is basically how you would define a test and then that is run for testing the, well, testing the test that was specified. And this is the current results. So we are quite happy because it's passing almost everything already. So we have from GAP to well to GAP including the secret manager as well is running there. We have some fails that I mean, we are trying to fix those. I think we actually already reduced those because by the time I was doing the presentation there was already some discussions about fixing those. And then of course we have BTS issues as well. BTS is not perfect so it sometimes has issues. And then of course every time that they release a new version and they have more tests, they're gonna update this. It's probably never gonna end. I mean, this testing is never like fully complete but at least we have something and this is actually covering most of it already. So if somebody goes takes the Bluetooth stack right now from Zephyr, it's gonna be, I mean, not losing too much time doing qualification with this test results. All right, so with that I'm ready for questions. Hope I didn't go over time. Roughly. Sorry about the demo, it didn't work. Sure, I actually was thinking about that because for example, we don't have, we do have the configuration to do the proxy, the BIT proxy, but we don't do the configuration for the emulation. So that's something I'm probably gonna write in the readme file. So you can actually do with full emulation with just doing the BIT proxy and whatnot. So it's actually quite easy to set up. Yeah, for prototyping, I mean, it's the fastest way to go. Yeah, yeah, yeah. Well, because of the samples we are running, we can do that. But of course if people want to do with Bluezy as well, no problem, I mean, we have the tools there. Yeah, I was running basically just emulation. The shell was just emulated both ways. The whole HIE. Yeah. Kimu, yeah. Kimu. The Tesla is actually using the ARM because we need more ports. So the BTP actually used the serial port to communicate with Zephyr, for example. All right. Any more questions? Oh, I guess it's it. Thank you.