Epic Intro Music: BLE Beacons and Ruby
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Sexton, Christopher
Would you like to stroll into the office to your own dramatic theme music? We can arrive in style with an epic score. Learn how to use RubyMotion, a Raspberry Pi and iBeacon Technology to play the Imperial March when the CEO walks in. The ability for mobile devices to detect their proximity to beacons is relatively new. We will learn how they work, the common gotchas, and how to integrate with a bigger system. Let's build something fun with Ruby and Beacons. Plus, who doesn't want an awesome theme song?
 official Now I gotta figure out why the keyboard wasn't working. Hi, I'm Christopher. Seriously, I have no keyboard focus. It's very annoying. I like to build things. This particular thing, I built mostly out of cardboard, but we also used our Arduino to make the light on the top of the TARDIS work. That was a lot of fun. And I work for a company called Radius Networks. We build products around proximity and location, and one of the things that we do a lot with is beacons. We actually build and sell the hardware devices as well as a bunch of services that kind of go on top of it. And this is our office. It's the powerhouse in DC, one of two locations where you don't have to give a street or number in DC if you want to send a letter to it. It's really cool. It is like a 100 year old renovated powerhouse kind of turned into an office space. And we all work on a mezzanine, and the doors to come in are down low on the main floor where everyone will walk in. And as they come in, then you stomp up these loud metal stairs, but you don't know who's coming in, which made us wonder, well, we're a proximity company. We can figure this out. Wouldn't it be really cool if some music would just magically play when somebody walks into the office? And so we, of course, started talking about, cool, we play when the CEO walks into the office and comes up the stairs. And the same thing when we were talking about the chief financial officer, what's he going to do when he walks up carrying all his ledgers and things that he carries? That was pretty obvious. And then I was faced with a real dilemma, which was, what am I going to play when I walk in? And I thought about it for a long time, and then it seemed just so blatantly obvious. I was very happy that I had the first slot talking, because I thought I'd be the very first person at this RubyConf to Rick Roll You. OK, so we have this thing. Let's build it. What do we need? We're going to need three different things. First, we're going to need speakers, some way to actually play the music connected to a small computer. We're going to need a mobile app, so something on your phone. Luckily, you always carry your phone with you, so this is a good representation of where you are. And then we're going to need a beacon. And you probably already know about computers and mobile phones, but I don't know if everyone's familiar with what exactly is a beacon. So there's a couple of different things that could be a beacon. The one I'm talking about today are the Bluetooth Low Energy Beacons, or the BLE Beacons, or the Bluetooth Smart, or the Bluetooth 4.0, which are all the same thing. They're just marketing terms that the Bluetooth SIG has come up with to talk about these things. I think most people tend to have settled on Bluetooth Low Energy at this point. And what exactly are one of these beacons? It's kind of like a PA system. It just makes announcements over and over, and it ignores everything else. That means that you don't connect to it. It doesn't know if you've heard it. It doesn't know pretty much anything. It's just sending out the same thing over and over again. And what it's sending out is just identifiers. This is nothing complicated. It looks something like this, which is just a big UUID and plus a couple other numbers. And that's kind of all that it has. And you can use these identifiers as like a foreign key, like you would in a database, or something to do a lookup to figure out what it means when you see that beacon. So there's a couple of different types of beacons, and choices are good, right? It's never bad to have too many players, too many cooks in the kitchen. The obvious one is iBeacon. So this is a spec by Apple. And whenever I talk about beacons, I almost always mean this. And I kind of use the word beacon synonymous with a beacon with iBeacon technology, which is the way you're supposed to say it. This came out with iOS 7. They introduced it. And it works really good on iOS. But the iBeacon spec isn't completely free of proprietary intellectual property. So there's this thing called alt beacon. And to be completely honest, this is a little bit of a shameless plug because my company authored that spec. And it's also a little different than some of the other specifications that are out there, because it was written with the idea of interoperability. And it's supposed to work one to one with iBeacons. And in fact, we have a number of hardware devices that do both, and you wouldn't notice the difference between the two. It's just kind of a mechanism that we were using. And then finally, there are other proprietary beacons. These can do some really cool stuff, include other sensors. You might notice on Kickstarter these sorts of things will come around that help you find your lost bike or have an accelerometer or temperature sensor and can do other cool things. But these are outside of the scope of what I'm talking about, which are the simple BLE beacons. So cool. We kind of know the different parts we're going to need. Let's kind of whiteboard and walk through exactly what we would do to make all of this work. So first, we're going to need a beacon. We'll set that up. We'll need a mobile device, some sort of Ruby back-end server. And then the thing that it's actually going to play the audio. And what happens first is the beacon will broadcast out its identifiers, and it just shouts these out, not knowing anything around it, sending those, and the phone is going to notice that. So on the operating system on the phone, we'll wake up the app and tell it that I've seen this beacon. That app can now post off to the server, which will in turn tell whatever needs to play the music that it should go ahead and play the music. And this is, of course, the point where the epic music actually plays. So cool. So what exactly are all these kind of abstract, weird drawings? So if we're going to build it, how does this fit all together? And what I do is, for the demo for this talk, I built it altogether. So everything in the box all runs on a Raspberry Pi. And it's all sitting there together. And then we have the phone kind of as a separate system. And these are the two things that need to interact together. And this is the actual system that I built. I brought it along. So you can see we have Raspberry Pi. It's got a little Bluetooth nub plugged in. I had some speakers. The USB hub, it was only for power. And you'll notice that there's a network cable because it needed to be connected. Because that was the only way that we could actually tell the Pi to play anything. Since the beacon that's sticking out here would only broadcast out, it wasn't receiving anything back. All right. So we have this epic music system running on a Raspberry Pi. There's a few things that we needed to do for us. One is broadcast as a beacon. So if you're just using a generic Bluetooth module, you can still have it broadcast as a beacon. And luckily, the command line that you need to run is pretty intuitive. So you can do that. It's using the BlueZ stack, which is kind of the drivers for Linux for Bluetooth. And use something called HCI tool. You can basically just command your Bluetooth radio to broadcast something. And I kind of highlighted the different identifiers. So the thing that's kind of in the dark red is the main UID and then the other two identifiers are that kind of mustard in dark blue. Or the easy approach is just plug in a Bluetooth powered beacon. And so it looks almost the exact same thing as a Bluetooth radio, but it has our firmware running on it. And you can just configure it in advance. All it needs is power and it'll broadcast. So that's kind of the cheap, easy way that I was able to get it to broadcast as a beacon. Or if I want to cover more doors. So if you're walking into the office, we have two doors. I need beacons at every entrance. So when you walk past them, I'll know that you're there. OK, so now we need a music player. We have it the system broadcasts. We need something that's going to listen for events and play the music. And I did it with a Sinatra app, which is very complicated. And you'll see, we'll start at the bottom. It takes a post. When the post comes in, it just converts the pram. It looks for a pram called name. And then what we do is we call it calls up to the method at the top, which is play. All I'm going to do is shout out to a little command line app called impeg321. And then I resolve the path and tack on.mp3. So if I want to add more songs for other people, I would just add chris.mp3 to the Raspberry Pi. And you can change out whatever song you wanted. Now, since I want to alter run on one device, and I didn't want to have a server and a Raspberry Pi connected somewhere with sockets going and pushing events up and down, I wanted to just tunnel out to the internet. And so this was an easy way to have my server run within the firewall that's at my office connected to that network there. And I just used a tool called ngrok. This thing is amazing. I discovered it while I was working on this little project, but it actually gives you introspective tones. So you can see what's going over the wire for the stuff that you've tunneled out. So if you've ever worked with web hooks and other things, and you want to test them, just check this out. OK, so the iOS app. So I have an iPhone, so I decided I wanted to write an iOS app, and I used Ruby Motion for it because we were talking about it at RubyConf. So this is a little more scary. This is how you tell the core location APIs to listen for a beacon. And there's a couple of things. Like I say, look for any beacons with a specific UID, and then tell me about it in any possible time that you can. And so I would set this up. When I first launched the app, I set up all these things, and I register with the operating system. Please tell me about these beacons. And then I need to implement some sort of a callback. So I have a method that's just a delegate to the core location. But all that means is that when the core location system sees something happening, it's going to notice that and call back to my app and let me know. What's really cool about this, and what was novel about when Apple introduced iBeacons, was that this happens even if my app is in the background. And it also happens even if you went through and explicitly terminated the app. The phone is locked in your pocket. All these sorts of things, it gives you an extra little hook, that event that you need to make something happen, that you just didn't have before. And then once we do all that, we are going to post it up to the server. On RubyMotion, I used a library called bubblewrap, which, if you've done anything with RubyMotion, bubblewrap is awesome. Because in order to do this same amount of work of just doing HTTP posts, and Ruby were spoiled by it because you can do it in three lines. But if you were trying to use the APIs, the native APIs, it winds up being something like 30 lines of code in order to handle all of that. So cool. Now we basically have a working system. We have the two components, the Raspberry Pi that's going to be listening to things, and the phone that will react to it, take that event and post it back to the Raspberry Pi. So it's kind of a full circle of the events are coming out of the music player, so that the phone can react to being near it. And it sends it off to the phone, which then turns around and sends it back to the actual Raspberry Pi system. Cool. So we have a working prototype. Let's go over. I'd like to talk a little more about how iBeacons work, in particular about some of the misconceptions and the other kind of nuances of working with them, because there's definitely a lot of things when you're working with iBeacons that's not obvious. So a couple of the big misconceptions that we see over and over again are that the Beacons actually deliver the content. They don't. They just send out identifiers. And I feel like I should just be up here just saying that over and over again, because that's something that seems that's hard for people to really ingest. And people tend to actually think that they're getting something off of these little Bluetooth devices, that they need to get the content and the pictures. Or God help us all more coupons off of these devices. And that doesn't work that way at all. The way it works is it sends out those identifiers, and you see those. And then that gives you a chance to react to them. Go look up at those identifiers in some other place. Pull those down onto the phone or to whatever device is actually using them. And take action on it. So it really is just providing you the event and none of the actual data or messaging or content. The other one is that the Beacons know when they're detected. They don't have a clue. They are just dumb broadcasters. And all they do are announce their identifiers over and over again. The way it works is actually using a Bluetooth ad packet. And so as it's sending out these advertising packets, it contains a couple of bytes of information. That's it, and sends it out. This one's important. We haven't talked about the distance estimate at all. In our demo, it was just, if you see the beacon at all, take this action. But one of the things that you can do with the beacon is you can use the RSSI, the relative signal intensity, to figure out approximately, and it's very important, approximately, how far away you are from the beacon. Now this uses Bluetooth. It uses RF. And neither one of these, the Bluetooth wasn't intended for figuring out how far away you are from something. So there are other RF-based things that you can use that are more accurate. But this is great because it's built into my phone by default, and so at the door, I have something in my pocket that can estimate distance. The problem is on your phone, you get back an estimate. You can convert it to meters using the signal strength, and you can configure the devices to have a baseline broadcast power. And what that is, is you configure it, you set it up, and you set something exactly one meter away, and you figure out what the signal strength is at that one meter away. And it's all very environmental. So if I plugged one in underneath the podium, and I wanted to measure one meter in front of it, it would make a difference whether or not this podium was wood or metal, and how much of the signal you'll see. And we've seen a lot of use cases where folks come in, and they're like, oh, it'd be great. I want to use beacons. We're going to do something amazing at our cash register. And I need to know when the person is the second person in line. And that's just not going to work. Because even standing still at one meter away in the lab, under control situation, you'll see the distance estimate jump around. And you can do things like running averages to kind of figure these things out. But it's not very accurate. And over enough time, you could probably get accurate. But that's not going to work for somebody standing in line at the cash register. And the other thing to know is that the accuracy gets less accurate the further away you get. So if you are immediate, like you want to be within an inch of the beacon, you want to hold your phone right up next to it, and you want to know if whether or not somebody is holding the phone right next to it, that's actually pretty reliable. And once you get out to a couple of meters away, it kind of starts to jump around. But when you're at 15, 20 meters away, it'll be all over the place. And sometimes the Bluetooth on the phone will be like, I don't even know what the RSSI is. So one thing to know is that not all the platforms behave the same way. A lot of people tend to think that you can set up an app on your iPhone and have it look for all the beacons that are out there. You can't. That's not allowed by the core location APIs that might be allowed on other platforms. And it might be allowed on other platforms that are using the Android beacon library, which is another slightly shameless plug, which is a completely open source reimplementation of kind of how the core location beacon API works. But being on Android, you have a much more open platform for better or worse, for exactly what you can do. All right. The other thing, another misconception, is that the beacons track you. There's been some interesting things in the news where I think in London, they put a bunch of beacons in trash cans and then people flipped out and made them rip them out of the trash cans. And then in New York, they were doing something similar where they had some sort of big fashion show and somebody made an amazing app that interacted to you wandering around the city. And so they used old phone booths because two uses pay phones anymore. And they installed a bunch of beacons, which could make the apps do interesting things. And of course, people flipped out. And the mayor announced that they were going to have to go and rip all of these things out. That was very frustrating working at a place where we think about this stuff all day long. The beacons aren't tracking you. They're not doing anything. They are giving your phone something that they can trigger to make the tracking happen. But there's a lot of other ways to do this. There's nothing inherently bad about how the beacons system works. It's not more invasive. And the thing I like about it is it's completely up to you to control whether or not you leave it on or turn it off. And on iOS, it's all opt in. And so it's a pretty good way of actually using it to engage people. It's really helpful when I want to play music, when I walk into the office. That's cool. If I'm going to my local sports ball event and I don't want to hear events or offers to upgrade my seat because seriously, no more coupons, then you can opt out of that sort of thing. And I actually really like the way it works. And I get frustrated when you hear politicians politicianing and doing their thing and causing some sort of massive backlash and saving the day by having a bunch of phone booths. Bluetooth beacons ripped out. Awesome. All right, well thank you guys very much. Thank you. Cool.
 official  Now I gotta figure out why the keyboard wasn't working.  Hi, I'm Christopher.  Seriously, I have no keyboard focus.  It's very annoying.  I like to build things.  This particular thing, I built mostly out of cardboard,  but we also used our Arduino to make the light  on the top of the TARDIS work.  That was a lot of fun.  And I work for a company called Radius Networks.  We build products around proximity and location,  and one of the things that we do a lot with is beacons.  We actually build and sell the hardware devices  as well as a bunch of services that kind of go on top of it.  And this is our office.  It's the powerhouse in DC, one of two locations  where you don't have to give a street or number in DC  if you want to send a letter to it.  It's really cool.  It is like a 100 year old renovated powerhouse  kind of turned into an office space.  And we all work on a mezzanine, and the doors to come in  are down low on the main floor where everyone will walk in.  And as they come in, then you stomp up these loud metal  stairs, but you don't know who's coming in, which made us  wonder, well, we're a proximity company.  We can figure this out.  Wouldn't it be really cool if some music would just  magically play when somebody walks into the office?  And so we, of course, started talking about, cool,  we play when the CEO walks into the office  and comes up the stairs.  And the same thing when we were talking about the chief  financial officer, what's he going to do when he walks up  carrying all his ledgers and things that he carries?  That was pretty obvious.  And then I was faced with a real dilemma, which was, what am I  going to play when I walk in?  And I thought about it for a long time, and then it seemed  just so blatantly obvious.  I was very happy that I had the first slot talking, because  I thought I'd be the very first person at this RubyConf to  Rick Roll You.  OK, so we have this thing.  Let's build it.  What do we need?  We're going to need three different things.  First, we're going to need speakers, some way to actually  play the music connected to a small computer.  We're going to need a mobile app, so something on your phone.  Luckily, you always carry your phone with you, so this is a  good representation of where you are.  And then we're going to need a beacon.  And you probably already know about computers and mobile  phones, but I don't know if everyone's familiar with  what exactly is a beacon.  So there's a couple of different things that could be a  beacon.  The one I'm talking about today are the Bluetooth Low  Energy Beacons, or the BLE Beacons, or the Bluetooth  Smart, or the Bluetooth 4.0, which are all the same thing.  They're just marketing terms that the Bluetooth SIG has  come up with to talk about these things.  I think most people tend to have settled on Bluetooth Low  Energy at this point.  And what exactly are one of these beacons?  It's kind of like a PA system.  It just makes announcements over and over, and it ignores  everything else.  That means that you don't connect to it.  It doesn't know if you've heard it.  It doesn't know pretty much anything.  It's just sending out the same thing over and over again.  And what it's sending out is just identifiers.  This is nothing complicated.  It looks something like this, which is just a big UUID and  plus a couple other numbers.  And that's kind of all that it has.  And you can use these identifiers as like a foreign key,  like you would in a database, or something to do a  lookup to figure out what it means when you see that beacon.  So there's a couple of different types of beacons,  and choices are good, right?  It's never bad to have too many players, too many cooks in  the kitchen.  The obvious one is iBeacon.  So this is a spec by Apple.  And whenever I talk about beacons, I almost always  mean this.  And I kind of use the word beacon synonymous with a beacon  with iBeacon technology, which is the way  you're supposed to say it.  This came out with iOS 7.  They introduced it.  And it works really good on iOS.  But the iBeacon spec isn't completely free of proprietary  intellectual property.  So there's this thing called alt beacon.  And to be completely honest, this is a little bit of a  shameless plug because my company authored that spec.  And it's also a little different than some of the  other specifications that are out there, because it was  written with the idea of interoperability.  And it's supposed to work one to one with iBeacons.  And in fact, we have a number of hardware devices that do  both, and you wouldn't notice the difference between the two.  It's just kind of a mechanism that we were using.  And then finally, there are other proprietary beacons.  These can do some really cool stuff,  include other sensors.  You might notice on Kickstarter these sorts of things will  come around that help you find your lost bike or have an  accelerometer or temperature sensor and can do other cool  things.  But these are outside of the scope of what I'm talking  about, which are the simple BLE beacons.  So cool.  We kind of know the different parts we're going to need.  Let's kind of whiteboard and walk through exactly what we  would do to make all of this work.  So first, we're going to need a beacon.  We'll set that up.  We'll need a mobile device, some sort of Ruby back-end  server.  And then the thing that it's actually going to play the  audio.  And what happens first is the beacon will broadcast out its  identifiers, and it just shouts these out, not knowing  anything around it, sending those, and the phone is going  to notice that.  So on the operating system on the phone, we'll wake up the  app and tell it that I've seen this beacon.  That app can now post off to the server, which will in turn  tell whatever needs to play the music that it should go  ahead and play the music.  And this is, of course, the point where the epic music  actually plays.  So cool.  So what exactly are all these kind of abstract, weird  drawings?  So if we're going to build it, how does this fit all  together?  And what I do is, for the demo for this talk, I built it  altogether.  So everything in the box all runs on a Raspberry Pi.  And it's all sitting there together.  And then we have the phone kind of as a separate system.  And these are the two things that need to interact  together.  And this is the actual system that I built.  I brought it along.  So you can see we have Raspberry Pi.  It's got a little Bluetooth nub plugged in.  I had some speakers.  The USB hub, it was only for power.  And you'll notice that there's a network cable because it  needed to be connected.  Because that was the only way that we could actually tell  the Pi to play anything.  Since the beacon that's sticking out here would only  broadcast out, it wasn't receiving anything back.  All right.  So we have this epic music system running on a Raspberry  Pi.  There's a few things that we needed to do for us.  One is broadcast as a beacon.  So if you're just using a generic Bluetooth module, you  can still have it broadcast as a beacon.  And luckily, the command line that you need to run is  pretty intuitive.  So you can do that.  It's using the BlueZ stack, which is kind of the drivers  for Linux for Bluetooth.  And use something called HCI tool.  You can basically just command your Bluetooth radio to  broadcast something.  And I kind of highlighted the different identifiers.  So the thing that's kind of in the dark red is the main UID  and then the other two identifiers are that kind of  mustard in dark blue.  Or the easy approach is just plug in a  Bluetooth powered beacon.  And so it looks almost the exact same thing as a Bluetooth  radio, but it has our firmware running on it.  And you can just configure it in advance.  All it needs is power and it'll broadcast.  So that's kind of the cheap, easy way that I was able to  get it to broadcast as a beacon.  Or if I want to cover more doors.  So if you're walking into the office, we have two doors.  I need beacons at every entrance.  So when you walk past them, I'll  know that you're there.  OK, so now we need a music player.  We have it the system broadcasts.  We need something that's going to listen for events and play  the music.  And I did it with a Sinatra app, which is very complicated.  And you'll see, we'll start at the bottom.  It takes a post.  When the post comes in, it just converts the pram.  It looks for a pram called name.  And then what we do is we call it calls up to the method  at the top, which is play.  All I'm going to do is shout out to a little command line  app called impeg321.  And then I resolve the path and tack on.mp3.  So if I want to add more songs for other people, I would  just add chris.mp3 to the Raspberry Pi.  And you can change out whatever song you wanted.  Now, since I want to alter run on one device, and I didn't  want to have a server and a Raspberry Pi connected  somewhere with sockets going and pushing events up and down,  I wanted to just tunnel out to the internet.  And so this was an easy way to have my server run within  the firewall that's at my office connected to that  network there.  And I just used a tool called ngrok.  This thing is amazing.  I discovered it while I was working on this little  project, but it actually gives you introspective tones.  So you can see what's going over the wire for the stuff  that you've tunneled out.  So if you've ever worked with web hooks and other things,  and you want to test them, just check this out.  OK, so the iOS app.  So I have an iPhone, so I decided I wanted to write an  iOS app, and I used Ruby Motion for it because we were  talking about it at RubyConf.  So this is a little more scary.  This is how you tell the core location APIs to listen  for a beacon.  And there's a couple of things.  Like I say, look for any beacons with a specific UID,  and then tell me about it in any possible time that you can.  And so I would set this up.  When I first launched the app, I set up all these things,  and I register with the operating system.  Please tell me about these beacons.  And then I need to implement some sort of a callback.  So I have a method that's just a delegate to the core  location.  But all that means is that when the core location system  sees something happening, it's going to notice that and  call back to my app and let me know.  What's really cool about this, and what was novel about when  Apple introduced iBeacons, was that this happens even if my  app is in the background.  And it also happens even if you went through and  explicitly terminated the app.  The phone is locked in your pocket.  All these sorts of things, it gives you an extra little  hook, that event that you need to make something happen,  that you just didn't have before.  And then once we do all that, we are going to post it up to  the server.  On RubyMotion, I used a library called bubblewrap, which,  if you've done anything with RubyMotion,  bubblewrap is awesome.  Because in order to do this same amount of work of just  doing HTTP posts, and Ruby were spoiled by it because you  can do it in three lines.  But if you were trying to use the APIs, the native APIs, it  winds up being something like 30 lines of code in order to  handle all of that.  So cool.  Now we basically have a working system.  We have the two components, the Raspberry Pi that's going to  be listening to things, and the phone that will react to it,  take that event and post it back to the Raspberry Pi.  So it's kind of a full circle of the events are coming out of  the music player, so that the phone can react to being  near it.  And it sends it off to the phone, which then turns around  and sends it back to the actual Raspberry Pi system.  Cool.  So we have a working prototype.  Let's go over.  I'd like to talk a little more about how iBeacons work, in  particular about some of the misconceptions and the other  kind of nuances of working with them, because there's  definitely a lot of things when you're working with iBeacons  that's not obvious.  So a couple of the big misconceptions that we see over  and over again are that the Beacons actually  deliver the content.  They don't.  They just send out identifiers.  And I feel like I should just be up here just saying that  over and over again, because that's something that seems  that's hard for people to really ingest.  And people tend to actually think that they're getting  something off of these little Bluetooth devices, that they  need to get the content and the pictures.  Or God help us all more coupons off of these devices.  And that doesn't work that way at all.  The way it works is it sends out those identifiers, and you  see those.  And then that gives you a chance to react to them.  Go look up at those identifiers in some other place.  Pull those down onto the phone or to whatever device is  actually using them.  And take action on it.  So it really is just providing you the event and none of the  actual data or messaging or content.  The other one is that the Beacons know when they're  detected.  They don't have a clue.  They are just dumb broadcasters.  And all they do are announce their identifiers over and  over again.  The way it works is actually using a Bluetooth ad packet.  And so as it's sending out these advertising packets, it  contains a couple of bytes of information.  That's it, and sends it out.  This one's important.  We haven't talked about the distance estimate at all.  In our demo, it was just, if you see the beacon at all,  take this action.  But one of the things that you can do with the beacon is you  can use the RSSI, the relative signal intensity, to figure  out approximately, and it's very important, approximately,  how far away you are from the beacon.  Now this uses Bluetooth.  It uses RF.  And neither one of these, the Bluetooth wasn't intended for  figuring out how far away you are from something.  So there are other RF-based things that you can use that  are more accurate.  But this is great because it's built into my phone by  default, and so at the door, I have something in my pocket  that can estimate distance.  The problem is on your phone, you get back an estimate.  You can convert it to meters using the signal strength,  and you can configure the devices to have a  baseline broadcast power.  And what that is, is you configure it, you set it up,  and you set something exactly one meter away, and you figure  out what the signal strength is at that one meter away.  And it's all very environmental.  So if I plugged one in underneath the podium, and I  wanted to measure one meter in front of it, it would make a  difference whether or not this podium was wood or metal, and  how much of the signal you'll see.  And we've seen a lot of use cases where folks come in,  and they're like, oh, it'd be great.  I want to use beacons.  We're going to do something amazing at our cash register.  And I need to know when the person is the second person  in line.  And that's just not going to work.  Because even standing still at one meter away in the lab,  under control situation, you'll see the distance estimate  jump around.  And you can do things like running averages to kind of  figure these things out.  But it's not very accurate.  And over enough time, you could probably get accurate.  But that's not going to work for somebody standing in line  at the cash register.  And the other thing to know is that the accuracy gets less  accurate the further away you get.  So if you are immediate, like you want to be within an inch  of the beacon, you want to hold your phone right up next  to it, and you want to know if whether or not somebody is  holding the phone right next to it, that's actually pretty  reliable.  And once you get out to a couple of meters away, it kind of  starts to jump around.  But when you're at 15, 20 meters away, it'll be all over  the place.  And sometimes the Bluetooth on the phone will be like, I  don't even know what the RSSI is.  So one thing to know is that not all the platforms behave  the same way.  A lot of people tend to think that you can set up an app  on your iPhone and have it look for all the beacons that are  out there.  You can't.  That's not allowed by the core location APIs that might be  allowed on other platforms.  And it might be allowed on other platforms that are using  the Android beacon library, which is another slightly  shameless plug, which is a completely open source  reimplementation of kind of how the core location beacon  API works.  But being on Android, you have a much more open platform  for better or worse, for exactly what you can do.  All right.  The other thing, another misconception, is that the  beacons track you.  There's been some interesting things in the news where I  think in London, they put a bunch of beacons in trash cans  and then people flipped out and made them rip them out of  the trash cans.  And then in New York, they were doing something similar  where they had some sort of big fashion show and somebody  made an amazing app that interacted to you wandering  around the city.  And so they used old phone booths because two uses  pay phones anymore.  And they installed a bunch of beacons, which could make the  apps do interesting things.  And of course, people flipped out.  And the mayor announced that they were going to have to go  and rip all of these things out.  That was very frustrating working at a place where we  think about this stuff all day long.  The beacons aren't tracking you.  They're not doing anything.  They are giving your phone something that they can  trigger to make the tracking happen.  But there's a lot of other ways to do this.  There's nothing inherently bad about how the beacons system  works.  It's not more invasive.  And the thing I like about it is it's completely up to you  to control whether or not you leave it on or turn it off.  And on iOS, it's all opt in.  And so it's a pretty good way of actually using it to  engage people.  It's really helpful when I want to play music, when I walk  into the office.  That's cool.  If I'm going to my local sports ball event and I don't  want to hear events or offers to upgrade my seat because  seriously, no more coupons, then you can opt out of that  sort of thing.  And I actually really like the way it works.  And I get frustrated when you hear politicians  politicianing and doing their thing and causing some sort  of massive backlash and saving the day by having a bunch of  phone booths.  Bluetooth beacons ripped out.  Awesome.  All right, well thank you guys very much.  Thank you.  Cool.
Epic_Intro_Music_0_71.png Epic_Intro_Music_72_143.png Epic_Intro_Music_144_239.png Epic_Intro_Music_240_347.png Epic_Intro_Music_348_707.png Epic_Intro_Music_708_851.png Epic_Intro_Music_852_1043.png Epic_Intro_Music_1044_1115.png Epic_Intro_Music_1116_1187.png Epic_Intro_Music_1188_1247.png Epic_Intro_Music_1248_1571.png Epic_Intro_Music_1572_8903.png Epic_Intro_Music_8904_9803.png Epic_Intro_Music_9804_13823.png Epic_Intro_Music_13824_16439.png Epic_Intro_Music_16440_19307.png Epic_Intro_Music_19308_27011.png Epic_Intro_Music_27012_36731.png Epic_Intro_Music_36732_36779.png Epic_Intro_Music_36780_36851.png Epic_Intro_Music_36852_37007.png Epic_Intro_Music_37008_37067.png Epic_Intro_Music_37068_37187.png Epic_Intro_Music_37188_37234.png