 Okay, my name is Marcel Altmann. I will give the presentation about what has happened to build open source firmware for IoT devices which Bluetooth BLE. So a little bit on me for the few people that don't know me. I've been working on Bluetooth since 2000 so I've been doing this way too long. I maintained the Bluezy Linux stack since 2004, also quite a while now. While I joined Intel in 2007 at the open source technology center I created Conman which is a connection manager, Ophono which is a full telephony stack pack runner which handles your proxy support which finally gets all the JavaScript stuff that you need for this one sorted into nice place L which I mentioned yesterday in my wireless talk our embedded Linux library that allows us to shrink things down and also IWD which is our new wireless daemon. So if you don't have seen the talk yesterday go ahead and watch this. I think the Linux foundation recorded most of these ones and it will be on at some point. I sit on the Bluetooth architectural review board since a year now and do many work on the specs on this one. I share the internet working group in the Bluetooth SIG and I also work on Bluetooth Mesh while I will be able to talk about Mesh. If you want to talk about this find me in the hallway during the conference. So today I'm doing a little bit of history in Bluetooth so just get you up to speed and see where the road we've traveled so far on this one and that you actually learned how to appreciate what has happened and what's going to changing really soon and in the future. I show you how low energy has evolved and how low energy works today and what we are really driving toward this one because my energy will be one of the technologies making a huge difference in Bluetooth these days and then how this has changed actually give the control to the people that actually want to build something because previous a lot of these things were the manufacturers were in charge and are telling you what to do and things actually changing and changing rapidly right now and then what's coming next because we have bunch of new technologies coming out that will be interesting and we want to give people early access to play with it and soon as we are standardized them and be able to talk about this in public. So a little bit about the history. Bluetooth is 1.0 B, 1.0 A was a disaster spec, 1.0 B was the first thing you could actually use, 99 so that's a pretty old spec by now. I still have devices that support 1.0 B, hard to find by I think the two or three in the world that still exist. They still work with Linux so it's kind of cool if you take them out in a while every now and then and try them to work with them but I don't recommend doing this one because first of all you need a PCMCA card slot which is hard to find these days. Most prominence back is 2.1 from 2007 so pretty much a 90 old spec. It's prominent because the car manufacturers move at a slow pace and that's still used in some of the cars out there and will be still be used for the next three or four years before they've moved on to something else. With Classic the latest spec that actually got an update for Classic is 4.1 where we added AS support for the encryption into the controller from 2013. Previously Bluetooth was using E0 cipher, finally they went into we need FIPS compliance and so AS went into this one a long time later after the first release. There's an interim version with or an interim feature with high speed version 3.0 from 2009 it kind of died down since considering using Wi-Fi alter white band as the high speed transport was a nice idea but it never took off. So there was one spec released with this one major feature never went anywhere and that's why 2.1 got stuck there as the one big one they wanted to support. There will be devices that declare themselves at 3.0 compliant they are compliant but you will not find a high speed feature in these ones because you need a Wi-Fi controller supporting this one. Linux actually does support high speed but I haven't really seen this used by anybody. It's one of these features we mentioned we got into the Linux kernel at some point and then it got never used by anybody. The interesting part and this is the main focus of the talk we started with 4.0 with low energy support in 2010. So we're right now six years in a cycle of 4.0 being released and my standard rule of thumb is if you have wireless technologies from the day the spec gets released publicly to mass adoption is around four to five years. So as you see 4.0 came out really six years ago and about a year or two years ago finally low energy is everywhere you find it in every phone you find that every phone supported you can buy devices for really cheap in the market you can go to amazon ebay god knows who and then you just buy a thermometer or any kind of sensor and chips are cheap that cost a couple of bucks. So version 4.1 was the interesting one while it added a support for a classic it removed the topology limitations on 4.0 and I will get to that one in the later slide and say where you had this topology limitations but to drive low energy further we needed to remove these ones where we had limitations on who can talk to who. The interesting spec really recently released this 4.2 which finally moved the security handling of low energy into a FIPS compliance with AS sorry 4.0 always had AS support so the encryption was always done with AS but the pairing and the key exchange was fundamentally broken it took you less than a second to break the keys once you're actually able to sniff the communication. 4.1 introduced Liptic Curves ACDH P256 Curves so it's pretty much a strong crypto and we'll make sure that your keys never we're going to leak. So 2014 if you go with my role we're still about a year in before 4.2 will be seen in mass market devices and what we have a reality right now everything supports 4.0 but you will not find anything with supporting 4.1 or if you have a 4.1 chip you will not find a host that supports it. On Linux we have actually done this it has fully 4.2 support but if you don't have 4.2 hardware we won't get any farm. What's coming next for the technology and this is a copy from the Bluetooth SIG press announcement since I'm actually officially not allowed to talk to about this in public. We're going to have longer range so they're talking about we're actually going to extend the range of Bluetooth from your average 10 meters into a stadium size ranges we get faster speed and we also get mesh topologies supported in 2016. So there will be two things that will be coming that adds mesh topology and we will have Bluetooth 5 they changed the versioning and the branding a little bit and on this quadruple range doubles of speed and the broadcasting capabilities for beacons they say 800% take these numbers with a grain of salt that are made up numbers the technical ones a little bit different but we increasing the technology a lot with Bluetooth 5 coming out this year. So back to what I mentioned earlier the ecosystem when 4.0 got released they had the fundamental idea the devices that support classic and low energy are your main hubs in your system so that's your desktop computer your laptop your phone and so on and so forth and on the right side you have the new energy devices like sensors keys keyboards and so on and so forth which is super neat and they can just talk to these devices and your phone is collecting the data the desktop is collecting data and so on and so forth and then you had the legacy ones that you had your cars your headsets and everything else that was actually using Bluetooth classic and they can talk to this one but they'll also meet the right side could never talk to the left side because the over the air protocol was completely incompatible and they wanted it this way with a 4.0 and then to polish your rotation because I always wanted to have the hub in between so even low energy devices couldn't talk to themselves pretty much. That is what 4.1 changed because they moved the focus onto low energy and we only do low energy. So 4.2 never had any updates for a classic and 5 will have I think only single or two features that extending classic a little bit but you see where the trend is going with this one I think classic is at its end of the evolution of new features and all the new features are going into low energy as a technology so that's where you're focusing on but while we're on the history to appreciate what actually has changed and how this has changed this is the early stack diagrams that you can find on how Bluetooth 1.0b looked like it looks really complex you have the the most important part you have the split in the middle which is called host control interface which separates the hardware from the from the host operating system and then you have an audio that always was special but you always have the legacy stuff we have to emulate PPP we have emulate AT commands and and so forth some of these things got deprecated over time but some of the stuff is still there so the serial port emulation is still existing and hard to get out headset still use AT commands to actually trigger call state changes and and so on and forth some protocols like TCVS bin which was way superior got deprecated at some point it's a binary audio control protocol mainly coming from the decked world died a couple of years back um there was an attempt which is kind of interesting that I actually built a java api but they weren't really successful in this one oracle still supports it on the website says we still supporting this one uh it never succeeded in anything but it was trying to grab the whole stack and build an api on top of it and it's one of the things where trying to unify the api and provide an api for Bluetooth classic completely failed I think no no operating system has a really good api either feature supported by the operating system or you can't use it and that's was the biggest problem with Bluetooth classic that unless there's a profile and the operating system supports it you're not going to use it which then also for fall back into the car industry which they were really slowly adopting these new profiles and so your car might support or might not support it um to scare you off a little bit that's the windows side of the Bluetooth stack these days um that supports classic and BLE and the interesting part is really pretty much everything on the right side is classic the part is where they actually do low energy actually can anybody find this by any chance just for the sake of it the teeny tiny onesy over here that's pretty much your low energy support and they have a little bit in hardware and then have a little bit api is on the top everything on the right side is to actually make classic work and integrate with the operating system and then BLE is this thing um it's not as bad as in Linux but Linux has a lot of extra support for classic as well where you need a lot of overhead and the percentage that it goes that you want you end up with 20 percent of the stack if you just would support le only it's just to scare you off a little bit the controller side doesn't look much better if you actually have a controller that has a dual modes support for classic and le we have this little bit le side that integrates with this one and then you have legacy old big handling how the controller does it and you have the device manager in there which in le went up into the whole stack is like we're not gonna do this anymore we're treating the hardware to actually get us on the air and we doing the most of the other stuff inside the host this also implies the security which in classic was inside the controller so you had nothing to do there it will do all the pairing for you just tell it to do it while ali it actually went in those said look the only thing the controller has to do is the encryption because we want to offload this one as much as possible or everything else around pairing and keys we actually do in the host which also means it's easier to update so after scaring you a little bit on this one getting this one into a little bit more control shape and the ones we actually want to talk about is how does the le only stack actually looks like so you have the hardware side it doesn't really change much you have your host controller interface which hti was bluetooth has actually done absolutely right since the beginning that this unified hardware interface would make it really easy to integrate no matter what transport you're operating on compared to wi-fi where you actually have to play a lot of tricks to get windows supported and still hardware that isn't supported on linux which is kind of bad you have your link layer which is pretty much your schedule on how to put the packets on the air and do a little bit of extra handling for the exchange how to set things up you have a test mode and you have your physical layer and that's basically pretty much your radio i have at that point and that's about it that's all what your controller is doing so four point zero controllers for le only are really really really simple the host side has to do a little bit more we kept around the l2cap link logical link control and adaptation protocol it pretty much gives you multiplexing for channels and we four point one extended this one into actually a connection on the channel so you have data streams there as well but then at the end of point there's just an attribute protocol and we'll get into this one how that works a little bit later and you have a security manager as i said earlier the security manager war was moved out of the controller into the host so you can easily adopt this which meant also for us you can run support for elliptic curves on a really old controller because there's nothing has to change there the only thing the controller does is as encryption then you put this together the attribute profile and the access profile and then pretty much that and you have your applications so all the complicated profile things are moved out and the logic on what to do is moved into the applications which makes it a lot simpler and a lot more useful if you want to actually do any kind of sensor devices and talk them from the phone everything becomes an application pretty much so a little bit of background the roles we have with low energy we have a central that's normally your desktop phone etc is the master device and you can't actually switch roles classic allowed to switch roles between master and slaves that has been gone away with low energy because there was always a pain point like look one point one device is the master and it sticks with it forever so the center is the master device you use this normally for access and information so you want to take your phone grab your temperature from your sensor and that's about it that's the master device the peripheral is the slave device that is the sensor device where she provides the data so just oh I have a I have a temperature I can tell it to you if you want to and then you have the other role roles observer and broadcaster which are not widely known because mainly nobody talks about them they are the scanner so you want to find beacons if you're an observer as like if you want to scan for I beacons Eddystone or something like that and you have the broadcaster which would be the beacon itself fundamentally observer and is a sub part of the central and the broadcaster sub part of the peripheral because you actually need to implement observer if you want to be a central and you implemented broadcast if you want to be peripheral this also means if you want to build a really cheap and dirty broadcaster device that's just a beacon you only need half of the link layer because you don't have to do any connections you just broadcasting information which makes it even easier to do this to build these kind of devices and this will become more important when we go into apologies like mesh where you can run with observer and broadcaster only roles for certain devices inside the mesh which means oh I can actually remove certain functionality and make the devices even cheaper and the topology diagram you see on the right is where this fund me goes you have the master being a central of the devices so you actually know what it's doing but it can also talk to the other devices but a peripheral will never talk to peripheral that's not possible but what is possible you can actually support peripheral and central mode at the same time with four point one because the limitations have been removed so if you want to be a peripheral and a central at the same time you can do this but you have to be both if you want to talk in both directions when coming to get this is pretty much a database and that's all it is its key value pairs on your device and it puts a little bit of semantics around this but at the base of it you have a key which is a handle 16 bit handle and then you get a value so you ask the database what is the value for this handle and then you get the information some of the handles are characteristics that give you extra information about what the service provides other one give you information about the service you can then have magic UIDs that allows you to find things but at the end of the day it's just a key value pair on the database which makes it really easy for the peripheral to implement because they just implement the database if it's a static one for example you just implement the database and you hand out the information and on the client side which would be the central or the master device you just have to use case you go like I need the temperature value and then you have a list of key value pairs that you asked for to find your key value that actually represents the temperature and then you go for this one so it goes from the client to the master asking the database going through them so you discover the services you discover the characteristics and then you get your values it's a simplified view on this one if you actually read the literature it gets a more complicated by the end of the day that's about it what you have to do which means all the over-air protocol is simple and stays simple so now to the open source part after the little bit introduction into what we have with low energy so the linux bluetooth stack bluesy has been around for a long time it's a dual mode stack supports classic and low energy it also supports high speed as I mentioned but it's pretty much unused but it's a stack that sits above HCI so it never deals with the hardware directly it always relies on that the hardware provides an HCI interface for the separation it's integrated into linux kernel so it has been there since 2.46 if anybody remembers that kernel it's pretty wild and it provides standard application and socket api so you have an programming interface for control and you have socket apis for all the layers that including l2 cup and r2 com so they behave like tcp and udp kind of neat and easy to use best api ever to become up with and there have been a lot of use cases but at the end of the day it was classic it was always we actually need to implement the profiles inside the user space in the demon and give dedicated apis to the ui to use them otherwise never going to be used i'll each change this a little bit with a gut api that we recently officially declared stable and then you can actually just use the gut api to implement central and peripheral usages um what we did recently when we announced the first that we announced it with a ble stack so zephyr got a ble only stack um that sits above hci implemented so after bluesy we also started now implementing a second bluetooth stack that is ble only dedicated for the zephyr atos and the zephyr talks have been there and you can see the stack in action at the demo booth uh upstairs it provides gut apis and also provides additionally the l2 cup apis for connection audit channel so if you're on the stream socket you can do this as well but if you just want to talk gut you can do this as well pretty simple support central and peripheral rules the website is there as well um the only problem with zephyr is that it requires you have hci while on a linux site that was a given all the desktop cases uh or where linux was running in phones everything else you have hcis interface nobody actually tried to invent something dedicated if you look at the abetted space uh and the maker devices hci was not the default interface so hci is defined but it's defined as optional um so that means that a lot of devices never used it and the reason for this one was that classic was not supposed to do this because the headphone case is a single mode chip where you actually want direct access to this one and eight getting hci would be getting in your way at least that used to be the argument um that nobody wanted to actually do this and the headset manufacturers got away with this one because in classic everything was profiles everything was dedicated um so they give you the whole solution you put your xyz extra features on there compile them ship them as a device and you have a bluetooth headset uh worked well uh worked well for the companies to lock you in um so if you get a csr one no qualcomm or if you get the broadcom one or if you get any other ones headset and um you basically locked into that manufacturer until you actually make the big switch to something else um and they liked it this way so the only problem is that lock in actually extended to ble uh which was really bad since ble had this nice uh easy and simple stack you can really build it really small you don't have to do any tricks you don't have to any shortcuts um but for us with effort this meant we actually couldn't get the zephyr bluetooth stack working against any hardware because we didn't have any hci interfaces the only thing that most of these had was gut so instead of just saying oh we have hci we're just exposing this one and the arthos has to implement the bluetooth stack they go all all these arthoses will never implement a bluetooth stack uh we just give you gut and then you have to talk gut the pros every gut api looks different so if you want to change the chipset manufacturer you're doing all your work all over again and some things might actually not work because they have dedicated use case in a simple use case well it's a heart rate monitor and that one works and you want to do something more complicated than you run into problems so uh when i gave this presentation for the first time there was literally no device that i could find that actually has hci support or that you actually could buy and use to use um so means it's all zephyr bluetooth stack couldn't really be used to actually make it work and you're just locked into a closed system if you keep doing this one that's fine but at some point you're going to regret this that you actually are completely locked into the system um um it was even worse for dual chip solutions uh where even the transport was completely different and really didn't help you so they even changed the transport in an easier so it wasn't a you out all the time that might put the some other transport and so on and so forth um the biggest problem for us was since we knew how the specs were developing with bluetooth 5 and bluetooth mesh and ipv6 over ble we couldn't do it because ipv6 or ble doesn't run over gut it uses a connection or you're in a channel over l2cap so it's like how do you take these apis that they're providing from the mcu's and actually run ipv6 over it it was impossible so they were pretty much stuck with this one it's like look this is not going to work um and for the longest time we were actually looking at what we can do different um mainly since we had this nice device the anise adrino 101 sitting on the desk and look well that's actually a pretty neat device so we have an x86 quark we have 30 big arc on this for sensors and we have an nr51 bluetooth controller from nordic and we support zephyr on the arc core and the quark um but the nr51 was giving us a gut api so what are we going to do with it so yes support bluetooth but we couldn't really use it so we could build uh some api that emulated some of these gut apis mapped this into the api of zephyr bluetooth stack and could pretend to do something um but at the end of the day it really didn't give us anything to run with because it was gut only it was pretty much boring it was stuck with 4.0 so while zeffa supported 4.1 and 4.2 features including secure connections for really secure pairing we couldn't use them we were stuck with the nordic soft device and the api built on top of this one so no hei access okay fine we have to figure something else we can run some emulation on this one but no l2 cup channels so ipsp not possible no 4.1 features no 4.2 features secure connections out of the window the privacy stuff where bluetooth le actually rotates your addresses every 15 minutes to avoid that you are trackable not possible with this one since it didn't support it the data lengths extensions that were available we actually have higher higher packets and get higher throughput we couldn't use these either the hardware would support it but the software uh just didn't expose this so we are stuck with the uh 27 octets instead of 255 octets per mtu um and then we look forward uh what do we do with bluetooth 5 or mesh support uh yeah that's not going to happen either on this one since we have no control on this one um so what we really really needed is to actually make sure that the bluetooth controller doesn't run a closed source firmware we really need to go to also run an open source firmware so we actually use the security manager from zephyr to actually implement the or we already had implemented the newer security features so we can just start using them um and then we also can start use ipsp and do everything else so full control from the hardware to the operating system that's what we really were after because otherwise we're going to get stuck and if you expect my five to four to five years prediction of how things progress and how to get mass market adoption if you want to make this faster you have to take things in your own hand actually get something going so we really needed an hchi firmware for uh the Nordic chip or we needed a different chip that actually proposes an hchi firmware um as i said earlier it's actually really hard to find i think the world is changing a little bit and you will find some people saying we have hchi firmware for early ownership but when i looked around um there were rumors that dialogue has one so they're announcing it i couldn't get it but maybe this has changed and cypress had an extra firmware that you might be able to flush in there to actually give you an hchi uh access so i've not tried any of these ones it's up to the audience if you want to try and please tell me back if this actually worked um we couldn't get any one of these or we couldn't actually get this tried or it was too complicated um the alternative would be you stick a dual mode controller in there um which actually support hchi which is um way more expensive way way way more expensive your power consumption will go up and uh they optimize for BADR connections which is the biggest problem if you buy a dual mode controller they prefer and will prioritize BADR connections and the schedule is designed this way one only only controller is designed for elite operations and they are optimized for these ones so we are very stuck with between a rock and a hard place on this one it's like what are we going to do um luckily um there was a new project popping up at some point uh called minute and they said okay we're actually going to take an nr 51 and nr 52 chip and instead of just using the Nordic firmware we start at the hardware level which is interesting since Nordic has the register sets for their um uh chip open so you can actually just download them and see what you can do on the chip and how you program the i've side of this one and they went through the whole uh complication actually accessing the Nordic chip porting their RTOS on this one and then say oh look we're going to write our link manager because we actually don't want to deal with the complications that we're going to have a binary only link manager and um have the problems that we actually have to can't fix this and that was the main problem that they can't fix the link manager and they had had complications for some use cases look we want to use this xyz but it doesn't actually work and we can't get anybody in Nordic to fix it or we are too small company that somebody takes a series of and so on and so forth and we want new features like the data length extension because we want to put a lot more data over the year um but they are not coming any time soon so they went through the effort and actually writing their own link layer uh and then put this in and they decided uh the spec says HCI is the communication interface we should be using between the controller so the hardware and the host why don't we just start using this one and it was one of the first projects that actually proved that even if you use HCI internally which was previously always declared is like overhead it actually doesn't make a lot of difference it actually helps you to uh simplify the way how you're going to work because it's well known interface is well understood and it gives you a nice separation okay this is a hardware problem this is a host stack problem um there's an additional benefit actually helps you with qualification since you can qualify one part of this one and qualify the other part so your certification comes overall a lot easier if you only change one side you don't have to rule the whole stack again um so they had this running but they were essentially essentially all focusing on getting this running on the nr 51 and 52 so even the BLE stack they were building was only running on this device um as I said earlier the adreno actually has three cores so as a legmon core on x86 it has the BLE chip from Nordic and has a sensor core we wanted to run um the bluetooth hci firmware on the bluetooth chip on the Nordic chip but we wanted to run the uh bluetooth host stack on the quark so what we did is we actually wrote a simple application and it was really really simple couple hundred lines of code and lately I heard after the refactoring of my new this is actually only like 10 or 20 lines of code because it become really simple to write this application and it provides hci back out of the uart so the adreno 101 has a uart in there in the nr 51 that is hooked up properly and you can just then push the hci data back out of this one and then out of sudden started working with our BLE stack and we had full access to this one so this works on the adreno 101 it works on the nr 51 dongle which is a neat dongle as a USB dongle previously absolutely useless unless you actually want to do some dedicated development on the nr f chip but we can turn this now into a BLE only dongle so you can attach this to your desktop pc and start uh uh testing new features and since you're full control of the firmware you can actually do whatever you want there and the nr 52 dev boards are a little bit bigger but they behave fundamentally the same thing um we tested this against thefer but he also tested against bluesy um and we open sourced this and upstreamed this one into my nudes and my nude has support for this one default now and they refactored it by now as i said the code for the BLE application turned into like really tiny now since they saw what we are doing with this one and they even using this internally for testing now against bluesy if you want to use this on bluesy it's pretty much as simple as this you attach the dongle if you use an nr 51 dongle you attach the dongle to your pc and then you do an vat attach uh to attach the serial line uh at a high speed and then it goes like okay fine i'm doing this one and then you have your device and when bluesy starts taking this device address would be a normal usb dongle uh works perfectly fine also works with dev kits uh i enjoy using the dongle um and you can just refresh this anytime you want to and modify the firmware um the same would work for all the external models what you said you find on spark phone everything else for the raspberry pi or the minnow board they all you have to put this on the shield x y z and then attach this together all these ones that are previously only exposed the gut apis cannot be turned into hsi and then if you run nukes on your raspberry pi you can actually start using these one and have a integrated dongle on this one with bluetooth le that you actually start using something with it and don't have to deal with this apis that uh previously in nordic or some other manufacturer exposed so with this one looking at the dreamer 101 again so finally we have x86 quad core that runs all our energy host deck secure connection support so we have 4.2 in there we provide gut and elder cap interfaces and we can do ip 6 via ip sp so we got to the level where you actually have a full stack running on this one on this hardware and we can do whatever you want with one with it uh and the guys uh upstairs at the zephyr demo booth actually showing this one on the adrino 101 with a heart rate monitor running the full stack as full open source so there's no binary component running that um the minute runs on the nf 51 mcu and it provides the low-engine firmware and the price the hei uad application um there's instructions uh i know zephy went to 1.5 but this link is still working and the instruction is still the same the instruction there and how to build the firmware and flash it on the adrino 101 and hold flash the adrino 101 completely now we didn't stop at this one because once you actually have control of what your firmware is doing you can actually do some neat things with this one where you actually provide advanced features that you will love as a developer as a as an as anybody who wants to actually tend with advice or someone that actually has to figure out what went wrong so we went one step further and said look um it's kind of nice that we have the adrino 101 but actually if you want to debug this if something went wrong you have to do a lot of work and since the number of uads are kind of limited you have to figure out who actually want to get traces of this one do i get a log message or what do i want so zephyr has a funny mode where you can enable the debug monitor and the debug monitor means that we will combine the hchi traces that are talked between the two cores and actually spit them out over the debug line but we can also combine any kind of log message into this one so the special mode you compile the application and you can leave it on all the time but it gets a little bit chatty which allows you to actually take the hchi traces and the debug information and any kind of log information and trace them back out the interesting part is bluesy has a tool called btmon that has been supported there since a long time it used to be called hchi dump but we made this more unified and more simpler and then you can just connect that one now to a tty and tty would be your tty of your adrino 101 and then you can just take the logs and it will decode them for you and you can actually have an easy tool for running all these logs and you get hchi traces and all logging information done you can also store them so you can't just read them and have to read them at high speed you can just store them we use the bt snoop it's a version of the snoop file format for people who are still back from solaris it can store hchi packets it can store logging information it can store a lot of extra meta information we keep extending this format so btmon supports it for reading and writing but also wireshark supports it for reading and writing so you can just take that trace the store that file and open in wireshark if you want to look at this one later on it's pretty nice if you want to do see what's going on with your hardware we did or we always had this but we never really announced this but in case you actually don't have an adrino 101 and try to try this you can run zeff and qmo which is kind of nice but you don't have any hardware to support so if you want to write application you might actually want to just use an existing dongle that you have on your host machine and just use this and bluesy always had the support for taking hardware converting this into a serial port or unix socket in this case and then hand it over to qmo and inside qmo just shows up as a standard serial port and it will work everything works as the same so zeff has support for this one on the linux side you just need a bt proxy which proxies your qmo into an existing hardware and then it creates a unix socket with the minus u stands for unix socket you can also use tcp circuits or something else it creates a unix socket and then qmo connects to this one and inside qmo when you run zeff it looks like a serial port and looks like any kind of hardware you're going to have there's instructions on also how to build your first zeff application running ble pretty simple pretty straightforward if you want to beacon and if you just can run this in qmo if you don't have any hardware to test this out and then use your usb dongle that or you are dongle or whatever dongle you have on your host machine to connect to this one pretty easy to do so with the interesting things now with my new providing an open source link layer out of a sudden the world actually changed quite a bit so the first company or the first community that actually starts building a link layer as open source and saying look we're giving this away under permissive license go take it mess with it we actually have we actually think it makes a lot more sense the world actually changed really rapidly and about i would say a month or two months ago we actually had finally the second open source link layer implementation so nordic what they labeled their phoenix link layer they merged this into zeffa it's merged upstream into zeffa so you have this available so there's a new our link layer natively to zeffa that you actually can use and it will support bluetooth 4.2 right now but we're also working on extending this one for new features it provides hci so it integrates natively with hci and with the zeffa hci which means you can actually have this working nicely on the nf51 and we hope that at some point in the really near future i expect like a week or two or something where we can ever replace the mynew stack on the adrino 101 with zeffa and we're just running zeffa on all three cores with providing fully open source software for the whole hardware work is ongoing towards more radio abstraction so we actually want to include not that just the knowledge chip we want to include other chips as well from other manufacturers so we can just have fully open source link layer and no matter where you're going to walk with this one and that's the whole vision for zeffa that we actually have bluetooth fully open source all the way through um there are a few other things zeffa will get a classic support as well i don't expect an open source classic baseband i don't think that's happening anytime soon um but there will be an open source classic stack for zeffa so you don't have to go out and buy one or trying to find one so this is work in progress with main target for headset and headphones you should watch forward for this one i think parts of this one are already merged by now and we will start extending this one so we're putting a couple of extra features in there obviously optional because the main focus is ble for zeffa and that's the technology of the future but we will get dual mode support for this one as well there's even more debugging and tracing work ongoing because we want to even get more information out of the hardware when you actually need to debug something um HCI is great and HCI helps you a lot but sometimes you actually need the link messages that go over the air so we're going to take the link traces also out of the hardware and actually we'll provide them with a standardized interface so this will be done for minute and also therefore link layer stack trying to get these ones out so if something goes wrong you actually can debug it because you can switch on the mode where the link messages will be forward to you and btmon will just decode them btmon can already do this for um uh existing dual mode hardware like from broadcom or from intel where you actually have these traces available if you enable them but we actually want to make sure that we have these ones as well so you don't need to buy a 30 000 sniffer if you have a teeny tiny problem you can just tell them okay just tell me what you sent the other side and what the other side responded and don't try to hide things for me which is great and you can only do this if you have really open source because you don't need to rely on a vendor to provide you these informations and we will be extending the bt snoop format even further with these ones um the really next step is to actually get the open source firmware certified and we will try to actually do a qualification for this one and see uh how far we're getting it looks pretty good right now there's no deadline set for this one but we will actually provide a certification for this bluetooth firmware at some point as i mentioned earlier bluetooth five is around the corner the buddhist sigori announced that it's coming this year um there's only a few months left for this year and i think you can predict which months this will be released into based on some historic data um bluetooth five is coming we have we want to end uh add bluetooth five to the zephyr link layer uh there's some nice features that are coming there that will make a huge difference and then bluetooth mesh is also coming we're also trying to get bluetooth mesh into zephyr so we actually have that one out of the box as open source available for everybody to talk with and the main reason is that the my four to five years prediction that takes to get mass market adoption we can actually shrink this a little bit with the help of the community and open source and actually get let's look maybe we can do this in two or three years and get a mass market adoption for these technologies they're not come overnight but you have to give everybody a starting point and we will be trying to be as open as possible to get these features uh available as soon as the specifications have been made public obviously if the specification will be met prior we can't really talk about this since they are confidential to the buddhist sig um and with that one i'm happy to open this for questions yes please okay so the question i'll just repeat the questions my question was what we actually going to certify uh if this deck is on the running on the knowledge chip so the bluetooth sig has the certification program set up like the way that you can separate the controller from the host deck so you certify the host deck which is the first target so our host existing host deck we want to certify this and then everybody can use this no matter hardware what you're going to choose because it's hardware independent as soon as you use hci so when you actually want to certify the controller it's hardware dependent so we can run the test case on one and then assume they're going to apply to the same one but fundamentally you have to do this for Nordic ones you have to do this for Intel one once you have to do this one Cypress one once pick your favorite chip manufacturer you have to repeat them um but maybe and this is maybe maybe the chip manufacturer say that's actually useful for us so we actually going to certify this for you give you controller certification so Nordic would do one Intel would do one etc and then you can just as a developer you just have to combine them you can just take this okay we're running this one you take this one I take the host controller one that we have provided as well and then we combine them and you're pretty much 90 percent there there's still paperwork and everything else to do if you want to certify your application and your product but you have a jump start ahead because everything else already done any other questions yes please okay I'm just trying to quickly summarize this for the tape so the question was about a licensing of the Nordic provided stack to Zephyr the open source one so the answers rather simple it might not be the ones that you like to hear but the answers are simple so Zephyr is released under Apache 2.0 license and everything that is Zephyr core and Zephyr owned will be Apache 2.0 so now license compatibility I'm not giving an answer to this one because I'm not getting to myself into trouble that's up to your legal interpretation of what's combinable or was not combinable but Apache 2.0 is a permissive license with a few obligations and if that works for you you can happily use it if you need to do a license for a piece of Zephyr that's really up to the companies contributing to Zephyr and seeing if they can give a different license so if you're looking for a BSD type of license or a copy of type of license so the Nordic guys are here feel free to talk to them they're around somewhere they're probably showing up the booth or somewhere in the hallway and see what they think about this but I think the main focus is Apache 2.0 license for Zephyr natively integrated sharing outside of Zephyr is currently not in focus that said if you're fine with using something on HCI and just having an HCI interface and two separate cores license don't really generally extend over a use of a generalized standardized transport and HCI is a generalized transport because it actually specified in the Bluetooth pack I hope that answers your questions there was another one okay so right now there's the minute link layer that the minute project has written and after that one Nordic open source they call it Phoenix so right now it's a Zephyr link layer because the name Phoenix is just for historical reasons they open source this one and merge it into Zephyr a heart for me to answer maybe maybe not ask them by yourself it is it's heavily worked on I can tell you this one right now and we're trying to actually heavily make a radio abstraction for other chip manufacturers so it will become generally useful for everybody but the goal is to have one link layer one scheduler for the link layer and then the BSP so to speak specific part is the radio abstraction hope that answers your question yes please so the BLE host deck is full featured they're always working in progress since we're moving towards bluetooth 5 and they're they're really a couple of bugs 4.2 is fully supported there's a test suite for it but we're using the test suite that comes with bluesy so it's hooked up into the bluesy test cases you can run the bluesy test cases against Zephyr that's why running this in QMO with a BT proxy is quite useful so we just pretend to be a device it doesn't have to be physical it'll be just a fake device that we have with bluesy but there's also integrated into the bluetooth pts pts stands for a profile tuning suite which they use for the qualification test so there's an automated setup for pts against Zephyr so you can actually basically start your pts system and then start Zephyr in QMO and then just run it against it or even with real hardware we're trying to open source the integration with the bluetooth pts as well just just hasn't happened yet i think that will happen my prediction is if all went well in the next couple of months there's a little bit of issues with the bluetooth sik and they are interface into the pts and the licensing around this so we're trying to sort this out but it looks like the bluetooth sik is interested in this one and we are trying to solve this one as well so the test suite yes is available and you can run this by yourself and you also need this for qualification if you want to run your own qualification any other questions if not then thanks everybody and enjoy the rest of the conference