 Next talk is by Jeremy Stott, hardware hacker from Auckland, or something along those lines anyway. Thanks very much, I hope. Cool. So, you guys are here to see Bluetooth Low Energy, I hope. Show of hands if anyone's used Bluetooth Low Energy before. Oh, okay. There was a couple. And what about that classic Bluetooth, if there's a difference? Yeah, you got your car, you like connect up your phone or something like that. Okay, cool. So, at least know what I mean when I say Bluetooth, and some of you played with it, some of you know that it's everywhere already. Cool. So, a bit about me, I have like an embedded systems background. Most of my stuff is C and C++ on little robots or electronics platforms. And sort of say, okay, Python by night, sometimes quite literally, and then all morning I guess. But I hope to keep that to a minimum by sort of weaseling in Python to my day job. So, you'll find everywhere I go, there's a trail of Python scripts that are poorly written and terrible to maintain. And actually, it was funny, there's a guy who used to work, so I changed a few jobs and he actually joined just as I left on a couple of occasions, and so he'll be seeing the commit messages of this Jeremy guy, and who is this, who is writing this code? He didn't punch me when he met me, so I assume it was okay. And so, I run the IndiePug Auckland meetups, so if you're in Auckland and you wanted to give a talk about Python or just come and enjoy some talks about Python, you can find me or you can find the meetup page, and we also have like a hands-on meetup as well where you can come and bring your laptops and do some stuff. Currently, I'm in Marine Electronics, so I'm building electronics for big, big boats and millionaires, and that's quite odd, but it's okay. So, a bit of history about Bluetooth Low Energy. So, the classic Bluetooth has been around for a while, but sort of Nokia in 2001, they were like, oh, it's not really that good for our low-power applications, and we could maybe do a bit better, and they started some research. And then in about 2006, they released this thing called WeeBree. Well, that's what they branded it. And that was sort of, I don't think many people knew about it. I didn't even know about the name WeeBree until I researched this talk. And so, a couple of years later, sort of Bluetooth 4.0 in 2010, they included this WeeBree and rebranded it, I guess, as Bluetooth 4.0. And still, no one really had any devices or anything until the iPhone 4S, which was the first, which is quite cool. They were first to implement Bluetooth 4.0, and so shortly afterwards, everyone wanted to be smart, ready. So there weren't many peripherals out yet, but everyone wanted to sell their device as sort of smart, ready device, and no one really knew what that meant, but I guess I still don't know what that means. Sometimes, my phone's not that smart. And in 2013, that's when things started, like I spec got updated a little bit, we got 4.1, we got lots more devices now in the market, and everyone's running these peripherals. Now, the reason why it's quite awesome compared to the previous Bluetooth classic, especially for Apple hardware, is if you're developing classic Bluetooth, you actually needed to include a bit of Apple hardware in your product, to sort of say that and be part of their developer ecosystem, to say, oh, yes, this is an authorized peripheral and authorized device, but you didn't have to do that for low energy. It was kind of impractical, and I don't think anyone liked it anyway. So there were lots and lots of peripherals that were suddenly compatible with Apple devices, and there was so much Apple hardware out there that it's quite an awesome opportunity. If you were going to create a little fitness tracker or something, you suddenly have access to all these people with all these smartphones. And then 4.2 came along, which did some security updates and some IPv6 stuff, so your peripheral could potentially talk through your phone to the internet. I haven't seen many of those devices around, but it's spec's there, and then data length was extended a bit. And the reason that was done is it's really low power, but the data rate is actually also very low. I'll get to that in a minute, so they kind of improved a little bit to make it a bit faster. So you've got to trade off something. And maybe in 2017 we'll see Bluetooth 5.0, instant of things, I don't know if that's still a buzzword in 2017, it's kind of clobbered to death now, but they've got instant of things related in the mesh sense that you don't necessarily need a phone or a tablet to talk to these peripherals, they can kind of talk amongst themselves, and then when a phone comes in range, they could all sort of figure itself out. Now, I don't know if you've seen a bunch of different names for Bluetooth Low Energy, like there's been a couple, there's been, well, WeeBree, which I didn't know about, logo looked quite good too. 4.0, you see like low energy, you've got Bluetooth Smart, which is the latest one. I love this, I actually found this on a page, it's a compatibility chart of these different, I don't know in case you get confused. Smart Ready, compatible with Smart Ready, obviously, and then Bluetooth with Node Text, and then Bluetooth Smart, that's great. Bluetooth compatible with Smart Ready, well, we already knew that, but just in case we didn't look that line, so we know that one, it's also compatible with itself as well, we know that. Bluetooth Smart, that's compatible with Smart Ready. I think that's like a recursive thing now. No, no, it's okay, we're okay, we're all good. So it's nice to say these are all the same thing. Most people just say BLE, but that was never one of their official names. They had ultra-low power to start with, like Bluetooth ultra-low power, but anyway, you'll see, if you're going to search for this stuff, search for BLE or Bluetooth 4.0, even though you're going to be using the 4.2 spec, yeah. So what is this, Bluetooth Low Energy, in a wireless sense? If you can sort of suspend your disbelief of graphs and how that maps to wireless stuff, you've got frequency increasing along this axis, and this might be how loud the signal is. And the Bluetooth Low Energy sits between 2.4 GHz, so similar to the same band as Wi-Fi, to 2.4835. And so each of these little spikes is a channel that your Bluetooth device can talk on. So they kind of reserve these bits, and then so those are the frequencies that everyone's going to be listening on. Kind of like back in the 19th century where they had this, that was an awesome talk, wasn't it? So these are those kind of bands of frequencies. Now you've got three advertising channels which are kind of reserved for telling everyone that your device is in the room, and then you've got the rest of data channels. And these are sort of like the areas where you'd see a Wi-Fi channel overlap. None of this is to scale or anything. Not like, I don't know if anyone's got a photographic memory. Oh, there's going to be recorded, so, oh dear. But yeah, it's not to scale, it's kind of just like, okay, this is a general idea. And what happens when you're transferring data across these airwaves, these wireless spikes is this frequency-hopping thing. Now, the classic Bluetooth also did frequency-hopping, if you knew that, but it's a much more complicated scheme. This one was very simple. It just hopped to the next frequency based on like a predetermined sequence. So it knew the sequence. It can generate a new frequency number, and if the phone and the peripheral both know the same sequence to jump, they can kind of jump it at the same time. You know, you don't have to go to the new one and go, are you here yet? You know, they just know that it's sort of like synchronized. So that's a linear feedback shift register kind of scheme if you're interested in that kind of stuff. But it basically is like a random number, but one that you can predict. Yeah. Randomly predictable. So there's some technical stuff here. Don't worry about too much of it. Maybe you can pause it. That was it for your recording, if you were going to... No, I'm just kidding. So a lot of questions I get asked about Bluetooth low-energy is what's the range like? And it sort of really depends with a lot of like wireless stuff, that's what everyone's going to say, it depends. Practically, so I worked on a start-up where we did some Bluetooth low-energy wearable devices. And so it's like on your body, your body's interfering with everything, and you've got room, you've got other devices, you're in the train station, whatever. So really practically, you'd only be looking at about 10 meters. If you're further than 10 meters, you're going to get a lot of packet loss, like a single thing over and over again, you're going to have a bad time. You might get it further if it's line of sight, you know, no clouds, and this is the planets of a lion and everything, but about 10 meters don't do more than that. But it's much slower. It's like the data rate, the active throughput, way slower, 0.27 megabits per second. And actually you're sort of at the actual... Again, this number lies and you think, oh, that's okay, I only need 27 kilobits per second, but the actual data rate that you're going to see, like pushing data through this protocol, is going to be about 5 kilobytes per second. So if you're thinking, oh, I've got this new idea where I'm going to stream audio through Bluetooth Low Energy, I just remember it's 5 kilobytes per second, so that's not very much, and you're going to lose a lot of that data as well. So active slaves, you can't... There's no number to find in the spec, but this depends on each device. We found Apple hardware would do about 8 to 10, and Android, I can't remember which device I used, but around it's like a 10 mark. But if you're transferring that, if you're trying to get 5 kilobytes per second on all those eight channels, you can forget that. So it's actually only about four channels. We've got about 5 kilobytes per second on four connected devices, and there's no idea about it. And the power consumption, it's like, why would you want this, right? This sounds terrible, is way down. So we're using... These things last for years on batteries, coin cell batteries, so that's why they did this. You can still use classic Bluetooth, by the way, it's not as if it's superseded or anything, it's just one of the implementations, like a subspec. So there's a whole bunch of devices, and you may be using Bluetooth without knowing it, you've got a smartwatch, you've got a Fitbit, if you've... If you've found a beacon in the shopping mall, or not even known about your phone looking for beacons, there's skateboards, there's sense networks, a whole bunch of devices. I think mainly because there's sort of explosion of hardware that has Bluetooth 4.0 capability, because it's the same frequency as the classic Bluetooth, so you don't have to do much to also include Bluetooth 4.0. And this guy here is like a little... If you've ever seen Star Wars, the latest Star Wars has a little robot that runs around, and so there's a neat little Bluetooth enabled robot, and so you can use your phone or your tablet to run this around the room, it's quite fun. It scares the crap out of your dog. It wasn't my dog, it was my parent's dog, so that was okay. Maybe it'll never come back to my house again. So I didn't break mine open, mine's still here, but these guys on the tested YouTube channel, Adam Savage and a bunch of other clever guys do some interesting stuff, they break things apart, look at how things work, it's a really cool YouTube channel. So they broke theirs apart and figured out how it works, so if you just go and have a look at that. So how do you connect to these devices? You've got your central node, which is probably usually going to be your phone, you can use your tablet, you can use another device that can behave as a central or a peripheral and it's going to connect to a bunch, so it's this star kind of network where one peripheral can't talk to another peripheral and so you can have this limited number of connections. Now, this is what will change in that mesh where one peripheral can potentially talk to another peripheral without going through a central node. So it's actually a really good, I don't know if you'll be able to see this but I could make this available somehow. It's a good guide like Adafruit had a really good sort of Bluetooth low-energy description if you wanted to go through this. Again, my incredibly two-scale, you know, accurate representation of how this is happening, you kind of have these connection intervals which are set by the phone and then the peripheral has a chance to send some data, every connection interval. So it kind of like wakes up, listens for a bit, it's like, nothing's happening, go back to sleep. And then the next connection interval will wake up. Oh, I've got, you know, I've been asked for some data, here's the data, do you want some more data? Nope. Okay, let's go back to sleep. So that's really how it's really, really low power is you're only, it's only waking up for this sort of short amount of time. I can imagine this connection interval is quite long which is typically about 30 milliseconds which is very, very long in, you know, processor time. It's great for a processor. You're only using power for a very short amount of time. But it also means you can't get much data through the network. So the way that the standard works and I've deliberately made it a bit cryptic because don't expect you to understand any of it is, but the main point is that they define some services that you can then use. So if you were implementing a Fitbit clone you could then create one that had the heart rate service. And then it's got that ID and you need to implement a bunch of characteristics. And you say, I've got a heart rate measurement. I've got a location on my body. Maybe that one's an optional characteristic. So you can see the standards like built up like that. They say these are read-write. These are optional. These are notify. So you've got one that's a notify characteristic. That means that the peripheral can just send you data without having to ask for it. So it's kind of like a subscribe and then it's like a callback function essentially. That you get this data back to your device. If you were going to stream a lot of data quickly that's how you do it. You use the notify thing and you just, whenever you woke up you would just send, send, send, send, send, send, and then you get the next connection to send, send, send, send. So that's probably the only way you can stream data quite quickly. If you're going to do a server service that you can do, you just have to create a 128-bit ID instead of 16-bit. And it's recommended that you just generate a random UUID number like from a UUID. There's a couple of websites that will generate this for you. And you just use it. And so it's kind of like a free-for-all of characteristics and things like that. So it's manufacturer-specific. You can do whatever you want with it. The chance of a collision is astronomically low, so I guess that's pretty good. But it doesn't stop someone from reading your characteristics. If someone buys your device and you've put some custom secret squirrel profile on there, they can still read it and interrogate it and what happens when I write one to this field. And so it's not pretending to be secure anyway. So that's enough about low-level Bluetooth stuff. I'm using Python. I have to because I'm at a Python conference, right? No, I like to use Python and I want to do my Bluetooth low-energy stuff. Let's get going. So go to PiPi, Bluetooth low-energy. I was quite surprised to actually see the fit on one page. I don't know if it's because I search for Bluetooth low-energy and whether that's like I tried BLE but then that matched a whole bunch of stuff, like noble. So, all right, let's look at some of these. You know, BLEEP, that one looks all right. Low-energy, BLE, library for Python, awesome. Currently only supports Linux, experimental support for OS X. I don't really like that. I'm trying to do this for a window. If I'm doing this commercially, most of my clients will be using Windows. So that doesn't work for me. Even as a developer of experimental support, that sounds like a lot of work. So I don't like that one. BluePi, it's another good one using BlueZ. I don't know if any of you sort of know about BlueZ but that's kind of like a Linux-only tool. But even if you didn't know that, you kind of like go to like, oh, yes, I'm getting excited. Go to the GitHub page and it's like, oh, I've only tested this on Linux. Mostly developed with Raspberry Pi. Should also run on X86DBN. It's like, ah. That's not really going to help me either. I'm running a Mac. What am I going to do? No Windows support. This has been a big sort of thorn, I guess, in BlueZ. So this is like a landscape of what the support... I've just picked some random ones that it's not actually sort of complete or anything. So you've got some hotspots over there. You've got Linux. It's right in the middle. It's got everything. You've got OSX. Yeah, there's still some Python and some Go. No BlueZ now, although it's sort of maybe possible one day according to a mailing list. But let's just say, no BlueZ. And you can also use their libraries. They provide some very good Bluetooth-only libraries. And then you move over to the app world and you've got, okay, JavaScript or Swift or Objective-C or then the Android API or JavaScript. And so these native APIs are actually very good. They're very well thought out and they work very well. But I want to use Python. And Windows is down there somewhere. Pretty sure it's off-screen. So really you can kind of draw this, you can extend this out a bit because it's not really true that you can't run Python on iOS and Android and use Bluetooth-only energy. There are a few ways to do that. Kivi is a good example of you seeing that it's like a cross-platform GUI library. But their support for Bluetooth-only energy was at least, was a bit of a stretch. It was like a gist that I saw was created three years ago. An example of using Android and Python with Pajani was I think that might have been like a previous pajamas thing and then it's now this, I don't know. So that's what they were, I think they were using that for Kivi. If not, I apologize. There was a sort of a page on some guy saying it actually works. So that's tenable. But there's this thing called, so you saw this big JavaScript bubble which everyone's JavaScript, sort of that birth and death of JavaScript talk by Kivi. That might be coming true. If you know the reference, I might put the description up somehow. But JavaScript taking over, right? How is this including all these platforms? And the really crazy thing is web Bluetooth. So the name kind of implies it's Bluetooth on the web. So we'll do a quick demo if it's going to work. So it's a standard. It's not a W3C standard or part of their standard track. But it's a standard that's quite recent and has been adopted already by some of the browsers. Chrome had support since some version. So I grabbed a nightly version of Chrome and you have to enable it. You have to enable this thing by going to your flags, Chrome flags and then enable web Bluetooth. So it's by default still not on. But it's there if you want to play with it. So it's really cool. Windows is actually there and I'm not sure exactly how this is going to work on Windows yet, but I haven't tried it. But this looks really promising. What is this? It's a bit scary as well. So let's have a play. We've got this BB8 Droid and someone's already written this little app to, using web Bluetooth, connect to this guy. So what happens when you try and connect? So it kind of pops up this thing. This is part of the standard that you had to tell the user that something was going to happen. They were going to be scanning I guess it's scanned without my accepting, but at least it doesn't report those results back to the page yet. So I can find all of my BB8 Droid and then you can pair with it. And now we've actually got a connection to my physical device from the web browser. Which is kind of crazy. The other interesting thing was they were saying should also only work where's my spec? Somewhere they mentioned it should only work under HTTPS and like many other APIs that they're working on and it works over through web server not opening a file locally. But it seemed to work okay for me so maybe it's still in its early stages I don't know. So we've got this guy and you're not going to be able to see this real or maybe I can put it over here and just hope they don't drive off the edge. Can everyone see the little guy? Okay, so so I haven't installed anything to do this other than Chrome. I knew that was going to happen too. Oh no, his head. Thank you. So it's really good this guy. If you watch that tested video you'll find out that the shell is actually about almost a centimeter thick and they had a real trouble getting it open. So they were like saying it's actually really good from falling off things point of view. So that's enough of that. Let's connect this guy. Oh the other interesting thing is you can see like a little Bluetooth like boot logo like the volume icon would be in your Chrome tab. So that's kind of cool that you know at least which tab is doing the stealing your droid from your from your desk. So we can kind of do this thing here right and include windows in our JavaScript world if we're using Chrome with Bluetooth. But it still doesn't solve I'm still using Python. I don't want to use JavaScript but maybe another day maybe different conference. So what can I do to get windows going with JavaScript at least and then maybe Python as we'll see. This was like the installation for one of the JavaScript Node.js libraries for sort of windows and so I got to a point where it's like install Visual Studio and I'm like oh no no back out back out. But there is another option which is like transcript. So have you heard of transcript? It's a really interesting funny website but it works really interesting and well. It sort of transpiles doesn't compile it transpiles JavaScript to Python well sorry Python to JavaScript so you write your Python source and it generates JavaScript source so you can then use the web Bluetooth API but in a Pythonic way and apparently it works really really well. I tried it out and it did work. I didn't have time to actually go and create a demo with the web Bluetooth enabled stuff but this was one of the ways and that was quite cool. With web Bluetooth becoming a bit more popular and common maybe this would be quite an interesting way. You could also use PyPyJS which is like the JavaScript implementation of Python in the browser. There's various ways you can do this but they all get a bit messy really. The last way you can maybe get this working on Linux is to write your own driver for some custom hardware. So what manufacturers will typically do is like Fitbit that actually ship you a dongle as well and they've got some Bluetooth hardware on here and they can just talk USB to the Bluetooth hardware and then they don't have to implement it. The reason this is so difficult is Windows didn't include default drivers for Bluetooth energy before Windows 8. Windows 8 only when they said here's a generic way to access Bluetooth energy hardware. That's why it was a problem. You had to have a manufacturer-specific driver which didn't really help the user out of the box experience. We can draw this link and it's very, I guess, it's very sort of tenable Python using Bluetooth energy on Windows. All right. But actually a much easier way is to go with a Raspberry Pi. It's like if I'm going to buy a dongle anyway why not buy quite a powerful dongle? And you can just buy them at PB Tech these days which is awesome. It's quite accessible and so you can plug that in and it's easy to say. All of these examples that are out there for Linux and stuff work very, very easily which is awesome. I was after that easy to work. Now I can't quite ship a Raspberry Pi to each of my customers. They might sort of catch on and all want one of these products and then throw my Bluetooth bit away and then just keep the Raspberry Pi. But yeah. Anyway, it's how I was playing around with the development in Python. Okay. So we've got a camera set up here so you don't have to look down here. You can look up there. And this is my Raspberry Pi running and it is connected to my laptop via the Ethernet cable and then I've got a screen here just so I can remotely debug stuff if I actually have to. But it's not part of the talk. So the main thing is the Raspberry Pi is just acting as this giant dongle to talk to some of these interesting modules here. So this one here is like a beacon-style device. You can see that another one in the background here is more of a like a development platform if you're going to build one of these modules and then you've even got some sort of like this one here which is actually an Arduino connected to a Bluetooth module. So it can be actually really easy to write your own peripherals. The Arduino one is one of my favorites and you can just plug it in and listen to about four or five lines of code get going. So even as it's like a quite experienced, I guess, embedded system engineer I still love to pick up those tools that make things super easy because I don't want to worry about like installing a tool chain to get this thing working. I just wanted to make some lights go. That shouldn't be hard. So yeah, there's some really interesting devices you can talk to. There's some Pi. Let's just make sure. There we are. Okay, some Raspberry Pi running in ARM. Cool. And there's various tools you can install. If you followed that guide that was up on the screen you can get your blue Z tools which includes HCI tool and then LE scan. But before I do this, this is going to scan all the Bluetooth devices in the room. So I won't necessarily connect to your device. If you don't want your device scanned now would be the time to turn it off. All right. Didn't really give you enough time to turn it off, but here we go. So this is now appearing. You've got an address and then you've got a name if it can figure it out. So hopefully none of you have set the name on your Bluetooth device to be an interesting name. Digital shield. Oh, nice. We're going to stop this before this goes too bad. But there's some interesting devices here like this BB-8. That's our BB-8 droid. He's always sending, hey, come and play with me. We've got the MetaWear device which is that round one you can see. And then we've got some other ones which are various things in the room. So what can you do other than just scanning? You want to actually do some interesting scanning. This might not give you enough information. You want to know a bit more about these devices. So that's where you might use a product called Ubertooth. So this is a gadget by Great Scott Gadgets and so I'll just give you the name Great Scott Gadgets and it's the Ubertooth one. And what it lets you do is kind of do some really really clever Bluetooth stuff from your laptop. So this is kind of like the ultimate dongle if you will. It's open source and open hardware, so you can build your own but otherwise it costs you about $100. It's definitely not necessary if you wanted to get playing with Bluetooth OMG but you can start doing some really interesting stuff with this one. So what we do in Ubertooth BTLE and some argument that doesn't mean anything. So it's scanning now. It's doing the same thing that you saw before, except all the time. And you're getting all sorts of values and you're getting the signal strength of every device that's talking to this and then you're getting all the data that it's reporting as well. So did anyone see the BB8 go past? That's right. We'll do something a bit better. We can pipe this to a named pipe. So you can do a MK5o temp pipe and that will create your named pipe and then you can do Ubertooth BTLE DEF and then the name of that pipe. That shouldn't happen differently. So it's now waiting actually. So you're getting all the data until I open the other end of that pipe which we can do in Warshark. So the way you do this is you go into your capture settings and you go into your managed interfaces and pipes and you create the named pipe here you just add that in so that you can then in your capture interfaces you can see the named pipe as one of the inputs and then we can start capturing stuff. No interface selected. Okay. Start. So now it's going and if we just scoot over so now you can see that it's doing what it was before but now it's actually a much more readable format for us because while it's going we can have a look and see what else is happening like this one for example is a scanned request. There's not only advertisements going on, there's other stuff. This is one of your devices has now asked to scan the room for other devices. So you can see what it is and which device it is and you can look at the data in there and so that would be a source address and the scanning address what it's asking for. So we should be able to see our BB-8 in here. There are a lot of devices. So I cheated because I know the name of the address off by heart now because I had to try this the other day but you wouldn't normally know I guess that it was C90D, E, C, E, whatever. Oh no, I lied, this is the this is the meta-ware. But anyway, let's look at that one because that's also interesting. So we can see this, is that custom UID that I mentioned before? So they're implementing a custom profile and you can see what profile it is. If they implemented other profiles you could see those as well. It's kind of like optional to advertise these but some people do and there's some other interesting stuff about it. The names and the signal strength and stuff. Yeah, so that's Warshack. With the ubertooth you can do a lot more. You can actually follow active connections. So you can kind of like after you've connected to it and you're sending data you can grab those transactions as well and have a look down and see what went where and at what time. It is a bit fiddly though so it sometimes doesn't work very well. You can see here I've got some mouthform packets. Didn't quite make the whole packet. Yeah, so that's the ubertooth. We'll stop that now. No need to scan all of your devices. Oh, so that actually wasn't scanning. It wasn't sending out any scan requests. It was just listening. There is quite a difference because you can once you scan your device can actually respond with more information. It's like a scan response that it can do. Cool. So how are we going for time? Three minutes. All right. Just enough time to show you my Internet of Things wonderful application. How long has that occupied? When is the toilet occupied? How long has it been occupied for? This is the questions I want to know every day. Why not make an Internet of Things device to help me with this? So here's my little meter weird device and I want to put it on the little locking mechanism of the toilets at my work. I guess. Maybe if I cover it up with something people won't really get suspicious. So how does this thing work? There's an accelerometer on this that says XYZ and that means that it's measuring the acceleration in time and space. So what kind of forces have we got going on right now? We've got gravity which is downwards and we're all experiencing gravity but in a weird way because there's the seats that you're sitting on which is supporting you from hitting the center of the earth. So when you sort of sit down, if you sort of close your eyes at the bottom, from your point of view there's a force going upwards keeping you where you are and really if you did have if you tied this little guy to a piece of string and had a rocket that went up at 9.8 meters 1 second squared, it would sort of stay stationary. If you imagine this just hovering like a quadcopter if you will as well, it's got a force going upwards but it's not actually moving downwards. So measure this and use it for occupied. If you imagine here's here's the device and when I start rotating the device I still have my gravity going up but the measured gravity going down is on the actual device changes around. So if I were to measure that and it's just you'll see the quickest demo you'll want to you'll want to toilet toilet humor So this acceleration file is basically going to connect using the Python API that they've provided and print out some acceleration data so let's run that into the address okay so we'll just grab the address you can see acceleration values so basically this is now measuring the acceleration and so the final demo in case you have lots of toilets, by the way that's what you need oh C9's ready, oh cool come on, gotta work okay, here we are so we're occupied and then if we rotate around available okay, I'm done unfortunately we will not have time for questions but I'm sure Jeremy will be heavy to answer your questions in the hallway or somewhere else catch them around don't accost them in the toilet please don't and yeah, big round of applause for Jeremy wonderful demonstration