Embedded - 232: Blob Is a Good Word

Episode Date: February 2, 2018

We spoke with Jackson Keating (@jacksonakeating) about Bluetooth Low Energy, going over GATTs layouts and the general BLE usage. While Jackson prefers the Bluetooth spec as the best reading explanation, Elecia liked the Adafruit BLE introduction. She wrote about some of her initial experiences with different chips and Chris Svec wrote about BLE roles. We all agreed that the examples and tutorials from your chip vendor is a good place to get experience. A random UUID generator is uuidgen on Mac or online on uuidgenerator.net. Elecia mentioned 108: Nebarious, an Embedded episode where we talked about how BLE lacks security. Jackson suggested looking at the Core Bluetooth API for IOS development as well as the Nordic and LightBlue apps for debugging.

Welcome to Embedded. I'm Elysia White, here with Christopher White. This week we're going to do a deep dive into Bluetooth Low Energy, that is BLE for those of you who prefer acronyms. I'm happy to have Jackson Keating to join us. Hey Jackson, nice to talk to you. Hello Chris, hello Elys Alicia, how are you guys? We are doing well.

Alright. Could you tell us about yourself? Yeah, so I'm an electrical engineer. I graduated in 2009 from U of I. And I work in the electronics industry. So I like to say that I make gizmos and gadgets. and I work in the electronics industry. So I like to say that I make gizmos and gadgets. In particular, I write firmware and work with Bluetooth designs.

So I got my start working with Bluetooth when I worked for Poto Labs. They're a company in San Francisco, and we made a Bluetooth camera. We had our own Bluetooth stack at that company, so I learned a lot about the different layers and protocols of Bluetooth. I wrote about half of the classic stack and the BLE stack as well. And now I work for a company called Identity Card and we make a Bluetooth enabled smart card. It's about the shape and size of a credit card. It fits in your wallet and we use it for storing data.

Neat. Well, we will ask you, well, I don't know if we'll ask you too much more about the card, although maybe we should. Because I want to do BLE introduction tutorial for those people who are thinking about such products. And before we get to even that, I want to ask you lightning round. I have heard you have heard the show, so you know that we are going to ask you short questions, and you're supposed to have short answers, and if all of this works, it's over in 30 seconds. All right.

Whew. Here we go. Favorite color? Red. Favorite BLE processor? Nordic. What's colder, Chicago winters or San Francisco summers? Chicago winters. Tip Francisco summers? Chicago winters.

Tip everyone should know. Yes. Oh, I get it now. Yes. Oh, I see. Okay. Wait, what? I thought the tip was that I thought you were making a comment that everyone should know that Chicago winters were colder than San Francisco summers.

Yeah. Okay. That wasn't what I meant. Do you want to answer that question or should we just go on? Yeah, I'll answer that. I got nothing. Complete one project or start a dozen? Complete one project.

What science fiction concept do you think will be real in our lifetimes? I don't know if it'll be real in our lifetimes, but I really like the idea of turning asteroids into spaceships. Yeah. I could get into that. Drive them carefully. Yeah. Okay. So now here's the big question that i figure we'll take the rest of the show uh

what is ble hmm okay it's a good place to start uh i like to always start with what ble is not which is kind of a an easy misconception to make. BLE is not a COM port. So although you can use it to emulate a COM port, it is just a little bit more complicated than that. That's just really not the right way to think of it. BLE is much more of a kind of a server-client model for exchanging data between two devices,

usually a server and a client. Sometimes those get referred to as centrals and peripherals as well. In that case, the central would be the client and the peripheral would be the server. It's a protocol... No, no, no. We should go back like 12 steps first. Yeah. Okay.

Bluetooth BLE is a child of Bluetooth. It's a wifi thing. It's a wifi thing. No, I mean, it's a wireless thing. It's a wireless thing. Yeah. So before we get into all of that, which we will, and yes, yes, he's right, centrals and clients, it's weird. When would you use BLE versus Wi-Fi or ZigBee?

That's a better place to start. Okay. Yeah, Bluetooth is for small amounts of data. Bluetooth Low Energy is for small amounts of data, basically. And also, it's for kind of local connections. You know, Wi-Fi, for instance, you would have to be in a house with a gateway. BLE is nice because you can maintain a connection between two devices without needing any kind of gateway at all.

But it doesn't go to the internet. It goes between two devices. Correct. Yeah. Yeah, BLE is just getting information from one device to another. A lot of times, one of the devices is connected to the internet. So you're connecting your phone to your smartwatch. Your smartwatch might not have an internet connection, but your phone does. And so your smartwatch can get information from the internet through that kind of gateway. Yeah, okay. So for BLE, when we talk about two devices, one of them is almost always a smartphone. Yeah, yeah, usually. Other things that can be used as one of the devices is computers, you know, laptops and Windows, Mac. Those are other options as well. Yeah, but I find that's usually with debugging we do that.

And when we send it out for real use, it's with the smartphones or tablets sometimes. Oh, yeah, absolutely. Okay, so you said it was way beyond com ports. It started out with BLE. It was always like a serial port between your device and your phone which was a weird concept but it was nice to have this wireless serial port but that's not really what it is anymore yeah yeah yeah yeah it's much more like a server and a client. So there's some data on the device, the peripheral that the phone wants, and it accesses it by requesting it. It reads the peripheral and gets the information. And then it writes commands to the peripheral and gets the responses kind of

a thing. So if I have a smartwatch, the central is my phone and the smartwatch is the peripheral. Correct. Yes. Yeah. Yeah. That's, that's the way, that's definitely the way to think of it. But my smartwatch weirdly is the server because it's the thing that has the information. This is what confuses the hell out of me. Yeah. Yeah. Yeah. Yeah. Your smartwatch is the server. So I like to think like the server is kind of the, uh, it's not doing a whole lot of thinking on its own, right? And so in that ways,

it's more, it makes more sense that the peripheral is the server because the peripheral is, it's a device, it's a smartwatch, it's a sensor, so it doesn't have as much processing power as the phone. So it's just, it's easier to set it up so that it's only responding to requests and then it, it doesn't do much else. So in that case, I know it's central and server, they sound like they go together, but the peripheral and the server are actually the usual method. Yeah. Yeah. So the peripheral is actually the server that's correct that makes sense i guess because the server is always something that has information that you're interested in getting and the confusing bit is just we think of smaller and smaller devices

that connect to a large device as a peripheral and i guess that's where the the terminology gets a little weird but because i always think of servers as cloud servers, big things, lots of processing power. But what it is, is something that serves data. Yeah. And the client is something that receives data. And it gets a little muddied because it isn't one directional. I mean, my phone sometimes has data that my smartwatch needs, like what time is it. Or the weather.

Or the weather if I'm displaying on my smartwatch. Yeah, yeah. And in that case, you know, that's just like 90% of the time the device is a peripheral and the phone is the central. You know, both devices can be both at the same time. Okay. Usually, we think of the phone being the central and the device being the peripheral, but you can have multiple devices

and multiple peripherals per central. Is that still true? I mean, is it still a star model where you have a smartphone and a bunch of devices, or is it switching? Yeah, yeah. No, it's still, you know, BLE is meant to make that process easier.

It's another thing that makes it different than Wi-Fi. You know, your phone can only have one connection to one Wi-Fi router. However, you can, BLE is set up to be much more like USB, where you can plug as many of them into your phone as you want. And so, yeah, that's still definitely the case. You can have your heart rate monitor and your headphones and your Bluetooth camera all connected to your phone at the same time. And that's one of the really cool things about Bluetooth. Okay. So we have a server and the server serves data and lives on our smartwatch. And we have a client that wants the data and lives in the central on our phone. Yeah. Okay. How do I know what data I can ask for?

I mean, how do I know that it's a smartwatch versus a heart monitor? Or a thermostat. There's a ton of BLE stuff out there. How do I know what data I can ask for if I'm writing the phone app? Right.

So that is one of the kind of fundamental parts of Bluetooth Low Energy is that it's set up like a database. The way you find out if a device has something you're interested in is by searching it for UUIDs. Those are unique identifiers. And for instance, with a heart rate monitor, there's a UUID associated with heart rate monitors. And that's to a peripheral, the first thing you normally do is you search through its database and you see if it has any services that you're interested in. And

in the case of a heart rate monitor, if you connect and you see that it has the UUID associated with heart rate monitors, you know that you found the device that you want to connect to. And so you can connect to it. And now that you know that it's a heart rate monitor, you also have ways, now you also understand how the rest of the database is laid out. And so there are UUIDs for fixed services. Yeah.

I mean, a heart rate monitor has the same information all over, but my smartwatch can do whatever I want, right? You're asking how would you add something that hasn't been classified yet? Well, just that there there exists uh custom services yeah and and some standard ones yeah exactly yeah so yeah the service is kind of the top level of um like a database entry and a BLE server. Now you can use a standardized one that Bluetooth specified, or you also have the option of making your own. For instance, when we had the Bluetooth camera, we had our own service because there wasn't a standard Bluetooth profile out there for

controlling a camera. So we had to make our own and there's nothing complicated about it you just go to a random uuid generator i think there's one on uh that's included in osx and yeah you generate a random uuid and now that's your uUID. And you can search for it and use it to identify which Bluetooth devices are, in this case, PODO cameras. Does anybody actually use the standard ones? I mean, I've made a lot of BLE devices at this point, and I've never gotten to use the standard ones. It kind of baffles me that they even exist.

I'm with you on that. I have no idea. It's like, I've certainly never used one. It's almost easier to not use it, especially, I don't know, because I mean, so many custom devices are, I mean, when you're building a device, there's always going to be something you want to do. You're never going to build just a heart rate monitor. Or maybe if you did, that would be a case where you would use a standardized service.

I have used a standardized service. I have used the standardized battery service. Ah, perfect. Yes. That's, yeah. You might think of, if you're making a device that you don't necessarily want to be tied to a particular app, so if you want a heart rate monitor, which I keep coming back to, and you want that to work with 15 different fitness apps,

that's the case where they're not going to be searching for some random one you made up. They're going to be looking for, hey, where's the heart rate monitor, right? Yeah, and what's really nice about using in that situation is you don't have to write your own app. And that's kind of a cool thing about using a standard service is if you just want to make the hardware and write the firmware, then you don't have to write your own app. You can piggyback on other people who use, who have heart rate monitor apps. So. Okay. So we have, we have these services and these services represent databases. Yeah. So when you're talking about storing data on a,

on a Bluetooth device, you know, it's a server, and on that server is a database. And that database is organized kind of like a tree, where the top level of every entry is a service. And so you could have a device with a heart rate monitor on it, and your own custom sensor on it and then maybe an accelerometer on it. And you could have separate services for each of those three functions. So in that way, a service is kind of like a singular function that's on a Bluetooth device. And below that service on the tree, you have what's called a characteristic.

And the characteristic is kind of the workhorse of what you deal with when you're dealing with Bluetooth low energy devices. The characteristic is what has the data. For instance, in a heart rate monitor, you might have a, a characteristic would be the heart rate. So you would read the heart rate characteristic to get what your heart rate is at that time. You might have another characteristic that I don't know what else you could have with a heart rate monitor. There'd be beats per minute and maybe instantaneous beats per second. Maybe. Yeah.

Or pulse oximetry. Or, well, I guess that'd be a different. Yeah. Some other characteristic. Well, actually,

no, you have a good point. Should it be in the same service? I guess not. It's always a question. And it's funny because services in the chips I've used to take a fair amount of memory. There is a lot of pressure to just shove everything into one service

unless you have a good reason to separate it out. Separating out battery is nice because then you can use the example standard service. You waste a little bit of memory, but maybe you save a lot of time. For this, maybe PulseOx would go in its own one if you were the sort of vendor who had PulseOx and other stuff. Or maybe it would all be going to one service. There's no hard and fast rule. It's kind of like breaking up your functions into different files.

Do you shove them all in one file or do you have one function per file is it's a style question neither one of those are the right answer okay yeah exactly okay so services have characteristics characteristics are the actual variables we care about right yeah and then uh kind of one step below that is what's called a descriptor. And these are super confusing. Yeah, they're the worst descriptors are just really painful. But the good news is that really, more often than not, you only use one descriptor, and it's called the CCCD, the Client Characteristic Configuration Descriptor. The most useful one has the longest, most annoying name. But yeah, the CCCD and all that does is basically enables you to listen for server-initiated communication from that characteristic. So the server might have data that it wants to send you on a specific characteristic. For instance, on a battery service,

you can read the battery level yourself, or you might want to set up your device to send you the battery level once a second. In that case, even though the device is set up to send it once a second, you won't receive that data unless you're actively listening. And you have to enable that listening. And the way you enable it is through one of these descriptors.

The CCCD descriptor. The CCCD, yeah. Okay, so you said once a second, and I've done the once a second thing, but I really like being able to listen in on my smartphone for the things that change. Like, my battery, for example, might not change once a second, so I don't need to have the battery draw of the communication. Instead, I can just set up this descriptor for listening and only update it when my battery percent changes. And so the server will always know what the current battery value is because it was whatever it was last time and nothing has changed. And you can optimize things like that,

but you can also do this timed thing where instead of the client, which is our phone, remember, instead of the client saying, okay, what's the value now? The CCCD descriptor allows the server to say, hey, client, ask me what the value is, because it's important something changed. Yeah, it's all about server-initiated communication. So it's a way for the device to notify you the the phone that something happened is happening and you can use it for any use case that you can think of yeah i sometimes think of it as the interrupt that the uh that my smartphone gets from my watch yeah that's yeah that's a great yeah that's a great analogy

since we're embedded people here we know that interrupts latency will be high relatively high and it's nice too because a lot of uh a lot of the frameworks that you use have uh event handlers for the notifications that come from your device. So they actually do look like interrupts in your software. Okay, so my peripheral, which is my watch, has a server. The server has multiple services, each of which has multiple characteristics, each of which has descriptors. Yeah. People wonder why we hate this because there are so many words.

And we haven't actually gotten to the thing that is GATT, which is one of the worst acronyms ever. So maybe we should cover that because we have been talking about GATT, but we haven't said the word. So what is a GATT? What is an AT? G-A-T-T versus A-T-T. A machine gun in like Chicago mob in the 20s. And AT&T is that telephone company we've heard about.

Yeah. Yeah, exactly. That's exactly it. Yeah, GET and AT are two of the protocols, or they're two of the layers that are associated with BLE in the specification. And one way to think of it is that AT is the protocol and get is the procedures so and so at has sorry go ahead so this hasn't helped you there's a committee behind this right there's such a committee oh man and you know what's you know what's awesome great though is that this is actually way better than Bluetooth Classic. Yes, I know that. Despite being so confusing, yeah, Bluetooth, they actually did make it way better than, a lot more simple than Bluetooth Classic.

But yeah, I mean, at is just a bunch of, that's what the protocol is. So that's what the, all the commands are at commands. The read command is an at command. The write command is an at command. Realistically, if I'm making a device, am I going to care at all about at? I'm going to care a lot about gat because that's what makes up our tree. But the att att is it i mean can i just like not read those sentences yeah yeah absolutely it'd be best if you didn't

for sure uh skip that part yeah we'll just skip that um so gat gat is basically that's those are the rules that we outlined just now. Services, characteristics, descriptors, how they're nested. That's what the GET specification is in charge of, more or less. Okay, so we have services, services, characteristics. How big can my characteristics be? What are my limitations on those? You know, that's a good question. I don't know the answer either.

Yeah, I think the answer is that they can actually be... Pretty big. Pretty big, yeah. The tricky thing is that BLE is meant for, you know, the data transfer size is small. So the MTU, that would be the amount of data you can transfer at one time. Maximum transmission unit. Yes. But actually, there's stuff built into the protocol for reading data that's larger than the maximum transmission unit.

So even if you can only read 50 bytes, it doesn't matter if your characteristic is 100 bytes. The stack will figure that out and assemble the data for you. So you can be pretty confident that whatever you need a characteristic to be, the data will fit to some extent. Which goes back to, there are a lot of style choices here. I could make my heart monitor give back beats per minute, instantaneous beats per second, and pulse ox. And I could make those be each individual characteristics,

or I could put them in a structure and make them be one characteristic. Yeah, yeah, absolutely. I just have blob of my data. Blob is a good word. Yeah. Jackson was talking about breaking things up into multiple packets, multiple BLE

transmissions, and blob is the word you have to look for for that. Yeah, yeah. The read blob command. Seriously, there's a read blob command. I really liked finding blobs was great, not because I had that much data to transmit, just because

it was way more amusing than most of these horrific acronyms and words. Yeah, that one was pretty straightforward. You understand what that one means right away. Ah, perfect. That's what I need. I need to read a blob. Okay, so I'm not going to summarize again i know some of you are probably already tired

of my summaries but we're going there'll be more oh yeah uh we have all these things we've made our own service at least mentally mentally i've come up with the idea that this is sort of like a structure and we have these descriptors oh maybe we should talk more about the descriptors um how do I know which things the watch is in charge of writing versus which things the smartphone is in charge of writing because there are parameters it isn't all one direction yeah yeah so are we talking about permissions on the characteristics yeah i think so those are in the descriptors aren't they those are actually laid out per characteristic so um i believe the descriptors have their own permissions as well.

So all these characteristics have permissions, read, write, notify, and the security permissions too, whether you need to have a secure connection before you can read them. So for instance, if you have a characteristic like your heart rate, you would want that to be a read characteristic because you want someone to be able to read the heart rate. But you don't want it to be a write characteristic because the heart rate comes from you. It doesn't come from the phone. And it's nice to be able to make it so it's impossible to write to it so it's a read-only characteristic in this case so your characteristics have those permissions associated with them and i'm pretty sure the descriptors also have permissions

associated with them so like the cccd is a read writewrite characteristic. Or it's a descriptor. And it has its own permissions. And part of that ties back to how, although we described it as a tree, the database is actually flat. So all of these things are, they're actually all called attributes, and so that's why they all have their own sets of permissions.

Okay, I'm a little confused. I thought the descriptors were the thing that had this read-write thing about the characteristics, but that's not true. From what you're saying, the characteristics, because their attributes have their own read-write notify, and the descriptors have their own rewrite notify attribute. What was the word you used? Permissions. Permissions. attribute what was the word you used um permissions permissions now actually okay it's starting to come back to me a little bit um i think the

since the descriptors are standardized um they they do have their own permissions, right? But the CCCD is in the spec. So it's specified as having read-write permissions. So some predefined stuff. Yeah, yeah. You wouldn't have a CCCD notify you. Okay. cccd notify you um okay but even though it even though it could um as an attribute it's a very flexible protocol i think we should leave it at things have permissions all right well and that's how we know that the watch should read the configured time of day parameter from the phone and the phone should read the smartwatch's number of steps um because one will be marked read and one will be marked right

and these are all from the perspective of the server which is the watch yeah absolutely okay and then that notify we talked about the about CCD and we talked about notify. So that all works in together. We'll let you look up that detail yourself. But you now have this idea of there's a tree of services at the top and services have characteristics, characteristics have descriptors. Everything has permissions. And none of it is actually a tree it's all very flat and they're called attributes because what we needed was more words yes but attributes all

have permissions and a tree is really a better mental model than some sort of flat thing yeah absolutely yeah knowing that it's flat can explain some things for instance the fact that you um you search through the database every time you like before you connect you you do this whole kind of search and cache thing so the fact that you can find something you're interested in and cache it um that's kind of relatable to the fact that it's a flat database. You being able to cache that information and access it directly. Okay, so actually this is a good point. So when we connect, we get all of the structure that is there. We find out both all of the services that exist, that they exist,

what's in them, the characteristics, what their permissions are, what their descriptors are, and what their values are. And then after that, we can just dive into the one we want. We don't have to query everything every time. Yeah, yeah. That's how most, if you're ever writing a test app or you're working with your software engineer, that's what they're going to be doing when they connect to the device. They're going to be searching through it and finding what they're interested in

and then keeping it and using that information later in the program. So my characteristic value might change as my watch is doing stuff. Of course, that's the thing, that's the variable. But what characteristics i have available shouldn't change right yeah for the most part they will stay static um or you have to think you have to tell the phone that you changed something it needs to reread everything yeah yeah there's something yeah there's something in there about that. You can change what's on

your device in terms of what services are available, potentially even what characteristics are available, but I think it might be more on the service level. And there is a way to, there are like somewhere in the spec, there's a way to negotiate that landscape where a service disappears and you have to let the phone know that next time it connects, it can't take anything for granted. But I'm not sure about the details on that. That's pretty advanced. Yeah, it's not something I've ever used. It's more like I define the get and the characteristics and just go from there. Yeah.

Okay, so we got connected and we did this. But how did we get connected? I mean, we boot up our watch and we have our phone on. And from a consumer perspective, usually I do something and something and numbers and something. What happens here? Advertising? Yeah, yeah. So advertising is kind of the default mode for most Bluetooth applications. And so BLE device has the ability to send data into the air, kind of at periodic intervals, and we call that advertising. it's a small amount of data that that that that feature supports i think it's man it's like 64

bytes or something um and you can use this however you want to you can put whatever data you could put the heart rate into people use advertising as a way to avoid connecting altogether. In other cases, people use advertising as a way to enable connecting. For instance, a really popular thing for you to advertise would be your custom UUID. So if you have a device that's particular to your company and you're writing an app, what you can do is have the app look for advertising signals that have your company or your service's UUID and only connect to those devices.

And so that's a very common use case and very popular way to establish a connection with the device. So you pull it out of the box, it starts advertising, you start up your app, and what your app is doing is it's looking at all the advertisements that it can find. And it's looking for the one that has the UUID that it's interested in. And then when it finds that UUID, it will connect to it. Another popular thing to advertise would be the name of your device. Something that's unique that maybe you, you know, imagine you have, you've unboxed two things.

And, like, this happens to me all the time when I'm looking through, you know, at work, and I've got a million different smart cards around me. You can filter by UUID and maybe have the user select the specific device that they're interested in connecting by name. And so when I choose a name, usually it's something like my company name and then some part of the serial number so that it shows not only what it belongs to, so that the human can read it, but it also gives a little bit of information.

So if there are a thousand of these in the factory and I have 10 of them close to me, I can put my hands on the one that is advertising. So not just Craig. Yeah. I mean, there's always a big temptation to put as little information as possible in there because you don't want hackers to hack. But that serial number is pretty useful when you're building them. Yeah.

I think that's the way we've done... That's the way we did the camera. That's the way we're doing our smart card right now is we advertise ID for identity, dash and then we give two numbers based on the serial number of the microcontroller and that means that

pretty much all of the devices are unique, or all the names are unique out of the box. And then something you can do that's kind of fun is you can let the user rename or change their Bluetooth name in your app. That's reprogrammable, and it's kind of a fun feature to have too. I don't think I've ever done that yeah so then so then whenever you know it looks it's podo xqyz to them when they get it out of the box but then then it can become craig then it become then it can become craig yeah okay so how does advertising work inside Bluetooth?

I mean, I know that there's an interval, and then there's this data I can advertise, and some of it has... Yeah, how does advertising really work? Yeah, I think that's pretty much it. I mean, there's an interval, and then there's data. And so when you're writing your Bluetooth program, you will, on startup, you'll initialize the Bluetooth stack with all the data that you want in the advertising packet. And then you also pick out your interval.

And the interval is basically directly related to battery consumption. So people talk about how Bluetooth is really low power, and that's because it spends most of its time asleep. And, well, in a lot of use cases, it does anyway. And so advertising is kind of then your how you control how much battery power it's it's taking you know a um because there's a wide range of frequency intervals that you can pick from so fast that and it all relates to user experience if it's really fast then the user will find your device very quickly.

And if it's really slow, it might take a while. But if it's really slow, you save a lot of battery life. And if it's really fast, then you waste a lot of battery. So you kind of have to find the happy medium. Freaking trade-offs. Yeah. Okay, so advertising, I can put actual data in the packet, but there is a follow-up advertising thing.

So I can advertise, hey, I'm a heart rate monitor, and I will tell you what you want to know if only you reply to me. And then my phone can say, oh, yeah, heart rate monitor, I know that. So I don't really want to connect with you. Just give me your data and send me your second advertising packet. And then there's the expanded advertising packet that the heart rate monitor can send over. Have you ever used that feature?

Yeah, yeah. So, yeah, I think it's called scan response data. Yes. Yeah, so yeah, I kind of use it as a way to, I think I still use it to connect, but it's just a way to cram more data in there because you can always, depending on what app you're using,

the scan response data might be read automatically. I can't remember whether I think it is in iOS. But yeah, it's like you only get 23 bytes in the advertising packet or 64 bytes or whatever it is. And if you need more data, the scan response packet is there for you if you want to put more data in there. Okay, so I want to go, I found the device I want,

and now I want to connect. And there's often this pin stage from a consumer perspective. What does that look like from the device's perspectives? So the security settings on the... Are we talking about pairing at this point? Yeah, pairing.

Ooh, yikes. So pairing is a very complicated subject with Bluetooth Low Energy because it's so flexible. We're all used to seeing the pin, or at least we were from the early days of Bluetooth that was really popular, like the 1234 or the 0000. Great pins always. Yeah, yeah. And they moved away from that because it was – they decided to make it because i think the pin was required at first and then they decided that it was it would actually be more secure if they allowed you if they just beefed up the security in a way that let you skip the pin then

uh forcing you to use a pin that everyone knows but yeah the pin is actually optional a lot of that depends on how your device is configured whether you have a pin pad um on your device like a smart, you might be able to actually use a pin, but like on a sensor, you can't really, you know? So there's different types of pairing that you can use depending on what kind of interfaces you have on your device or also what kind of user experiences you want your customer to go through. A lot of times, like a pin might not be the favorite you know a great thing from

a user experience perspective and if the data doesn't need to be so secure then you might decide to skip it um and to that extent pairing is actually optional altogether on ble yeah my little bb8 robots will, um, we'll pair with anything that comes nearby and, and you can control it. They don't, they aren't, uh, attached to my phone or my tablet,

but my smartwatch, uh, is of course mine and I don't want other people to read my data. And so there's usually some pairing there. And even for devices without displays, you can often do something, whether it's LED-based or whatever, but it allows you, again, in the factory,

to find the one that is currently squawking. And to make sure that your phone and your device are both pairing with each other and not pairing with somebody across the room. When we talk about user experiences, there's the goodness of not having to work hard to pair, but there's also the idea of Christmas morning for consumer devices where multiple people open a very similar thing and want to pair it with their own things, and they need to identify in a crowded BLE environment. Yeah, LEDs are a great way to do that at least from the way i've done it in the past is um i've never used see i've used led patterns to indicate

when you know you've successfully paired but um i've never used it quite like in a pin situation. That's kind of interesting. In a low stakes, doesn't have to be secure, but does have to be paired to the right one. I've used tricolor LED on both sides. And so the pin is sort of the color. Oh, wow. And you ask the user, is it blue? Is it yellow? Is it cyan? So they choose

part of the color wheel. And so it's one of like eight pins. It's not secure. It's just making sure that everybody has their own and not somebody else's. Yeah, that's really cool. Speaking of security, this whole pin thing, it's really cool. Speaking of security, this whole pin thing, it's not secure.

I mean, there are some great videos of people just showing how to hack BLE security. Mike Ryan has a really good how to crack BLE security in two minutes or less sort of thing. Wow. How do most people handle that? You know, honestly, this is not a subject I'm super up to date on. Okay. Well, I will say that one company that I cared about that really needed security did the pairing in their factory. They, of course, had to send out the client central smartphone device along with their paired sensor.

So that's one way to do it. That's always very secure. Completely impractical for most things. Right. Can't always ship your own cell phone. But other places will do this pin thing and then exchange security keys at that point or have security keys on board

that once the pin has been confirmed, they will start using. And so that assumes that your device and your application originally had the same pin and can then exchange more keys so that you get a per device security system. Yeah. It gets really complicated. Security, of course, is complicated. And I think we have done a show or two where we talked more about security. I think Jen Castillo's Nabarius is my favorite. I'll link it in the show notes.

Oh, yeah. Great. Was that one? I don't think it was that one. Well, we talked about all sorts of things with security at that point. All right. We'll find it. Plus I giggled through it, so you know.

It's always a good show then. Okay. So let's see. What haven't we covered? How do I do this? Yeah, that's a good one. Jackson, you said one of your favorite processors is the the nordic um nrf 51 52 52 is new i haven't tried it yet no wait a minute no 52 is has been out a while there's a

new one at 54 i think it goes 52832 and then 52840 i think think, is the new one. Yeah, there was a 4 in it somewhere. Yeah, there was a 4 in it somewhere. But yeah, those Nordic chips, they're great. I really like the way that their API is laid out for the stack, for the Bluetooth Low Energy. I think it's really customizable. It doesn't really, it's fully featured. So it doesn't skip anything in terms of what you're capable of doing.

All the features of the spec are pretty much there. And so that makes it really nice. It can possibly be a little bit intimidating, but what's nice about Nordic is they have great developer resources too. All kinds of example apps and tutorials, and their forum is pretty incredible. So I would highly recommend them for getting started i would too um i think the hardest part about their tutorials and their examples is that there are so many of them um

that it's a little easy to get lost and they have different ble stacks and you have to be kind of consistent with what you're using if you're you need to check the version i mean use whatever the latest is or or use two back or whatever your your strategy is but make sure that if you're on 13 you're on 13 the whole time and you're not getting data from 16 or 12 or 4. Oh, yeah, because they update it. They do. Regularly, yeah. And the updates are good.

I mean, it brings interesting things. We talked about centrals usually have multiple peripherals, but they can change roles. And I've seen some devices doing some interesting meshing things where centrals and peripherals, where the device, where the sensor will change the role and collect data from other devices. And then it will also talk to, it will aggregate it, which is really neat. It's a great thing, but it's kind of complicated. And boy, am I glad it wasn't in the first version because the first versions it was in were not good. Yeah. Yeah.

Yeah, they were pretty cool. And yeah, it's not too bad to update your stack either. I think it's just like a little folder that you drop in. I think it is now. I remember the shift from 4 to 6 and screaming. It was awful. And then there's the TI CC26XX, 2640, I think, 2650. I've used those too, and I liked them.

It was a very different setup because they were running the BLE stack on a different CPU inside the same package right so is that more of like you were using UART commands to initialize it kind of a thing

no no they were they shared memory so it was it really was like it was it wasn't one of these two processor situations where one is a serial port. It was really running in the stack. And I had my own GATs and all of that. Cool.

Yeah, I haven't used that one. I use TI's older chip right now, their dual-mode chip. Do you know the name of that one? Or the numbers? Yeah, let me see. Oh, Bluetopia. Yeah, the Bluetopia stack. Oh, yeah.

Wait a minute. You're saying, do you know Bluetopia? Yeah. I know of Bluetopia. a minute you're saying you know do you know blue topia yeah oh wow blue topia oh so this is the cc 256x yeah two five six four yeah two five six x yeah that's their um 8051 based system that was hilarious hilarious yeah i think it uh i think bluetopia goes on lots of things yeah so that bluetopia is a host stack and that's uh you know when i worked at podo that's what i was building was a host stack and what it does is you you were what's nice about it is you can use it with

um any run-of-the-mill well potentially any run-of-the-mill uh bluetooth controller it just so happens that ti has some kind of deal with them and they distribute plutopia with this dual-mode controller. Okay, cool. So, this stack thing, you've written them, but most people don't have to. When we talk about using Nordic, you just use the Nordic one, right? Why would you write your own?

That decision, it was made before I joined the company. And I think potentially part of the reasoning was licensing fees and also affordability. So I don't know too much in detail, but basically the hypothesis was that when you buy a Bluetooth controller, like a Broadcom one or a CSR one, you can get them for really, really, really cheap. So it's nice to have your own host stack so that you can buy these really cheap Bluetooth controllers. But then host stacks are pretty complicated pieces of software. So there aren't any good free ones or there, there weren't too many good free ones out there at the time. So all the other ones had licensing fees. So they decided to start writing their own and it went well enough that they continued the project.

And so it was mostly about, at least in some ways, trying to save money. That was the reasoning. And now there's the Minute has their BLE stack, although I don't know if it's certified yet. But it's Apache, so if you out there are thinking about writing your own, at least read that one. You know, we've been talking about Minute for a while. I've never heard of Minute. Someone on the show, and I just got the pun now.

Aditi. That's right, Aditi. I just got the pun. Because it's small? It's minute. It's minute. It's small. But it's spelled minute, like the animal. Right. But I just got the small

bit just now. We talked about this in the show. Well, okay, then maybe I got it a while ago and forgot about it. Because I didn't get it the first time. All right. Most people won't be writing their own host stack. Well, and it's taking up resources on your chip, and you need an RTOS, and it gets very complicated.

Not that I know. Yeah, yeah. I liked having Bluetopia with this new project I'm working on on the smart card. It's very nice to not be troubleshooting the stack. Yeah. Yeah, you rely reasonably well on the stack that exists. Oh, yeah, yeah, and that's a huge relief. You don't have to be on the protocol analyzer

looking at the packet counts and all that stuff. It just kind of works, and that's great. And so I would suggest always going with something like Nordic or an actual bought-and-sold kind of of host stack and if you really want to make your life very easy although more expensive uh there exist modules that are pre-fcc certified i know regatta makes some um and those are based on the nordic and it And it's all very nice to have it, that part not be a big worry. Depends on what electrical resources you have,

but I've been happy with knowing there are modules out there. Yeah, so in that case, do you send, is that kind of like you're sending serial commands to it? Or? No, you're still running in the processor just as you are in Nordic. It's just that the hardware has been pre-qualified. I see.

Great. That's cool. I think if you ran your own stack, you would have to recertify it. But why would you be buying Nordic chips if you weren't going to use their software? Yeah, absolutely. I'm sure somebody's going to explain to me why you would, but I don't know. We've covered a lot.

I asked you if you had any books or blogs or anything to get started for people who are new to this. You told me you read the spec. Who reads the spec? The spec's great. The spec's great. I guess once you get used to it um just through you know writing through that whole experience of writing the stack now i kind

of i know how to get through the spec and um find the information i need and so that's my favorite resource but i was looking through it the other day, and I was like, yeah, this would be a bad place for a beginner to go. I think some other places you can look is Nordic tutorials look like they're pretty good. And then also programming with something really basic like an OSX app with Core Bluetooth. Their API is pretty straightforward with how Bluetooth low energy actually works, and their tutorials on how to use it are pretty great. And yeah, Core Bluetooth is a really good resource. It's really solid, and it works really well.

And then also experimenting around with the Nordic iPhone app. They have different shape buttons for whether you're notifying or indicating reading and writing for navigating between services and characteristics it's just a great when you play around with the app you get a much more intuitive feel for how the database is organized used to be an app called uh light or something. Is it similar to that? Yeah, yeah. Yeah, Nordic. Yeah, Light Blue is another great app. It got a little out of date for a while.

Yeah, that's what I think. But now I think it's gotten, somehow they updated it or something. I've been using it more often. But yeah, Nordic has a similar app. It's like Nordic Explorer or something. And yeah, that can be a great way to learn too. So all this stuff seems really confusing when you talk about it, but when it's laid out, it's actually very simple to understand and get a feeling for it helps if you think about it as a tree and and you try to take what other people have done and modify it and knowing that the att wasn't that important is really helpful and realizing that there is so much flexibility that it there isn't one right path. So you kind of have to choose something and try it. They're all good stuff.

Yeah, absolutely. And then I have a book that I liked, although sort of with the spec, these books make a lot more sense after you've tried it. I've done B ble a few times and the first time was really really hard and i tried to read uh the o'reilly book i tried to read this robin hayden's uh bluetooth low energy the developers handbook and it was it was okay but it didn't really make sense and then when

i went back six months later because i was starting a new project these things suddenly were laid out and made a lot more sense so you need a newbie guide um the adafruit intro to ble i thought was not bad a little uh starting to show its age but since this whole podcast has been about BLE4 instead of about BLE5, I guess we're showing our age too. Do you know anything about BLE5? Because I know nothing about BLE5. It's one more. It's one more. It seems magical. Plus one. Higher data rates, more distance, less power. I mean, breaking the laws of physics here yeah you know i i uh i think what was nice

for me is i i looked at the bluetooth 5 spec and they did not add any more protocols so that was great because um kind of like i said like the classic protocol was really super confusing uh even like way more confusing to use than the LE protocol with at and get. And so I was a little nervous that they were going to add a new protocol, you know, kind of like how in BLE 4, they added at and get. It looks like though, in the BLE 5 spec, there aren't any more host protocols. So if you learn BLE now, it looks like BLE 5 is going to use the same kind of GAT setup. I only kind of infer that from looking at the spec,

but I find that pretty reassuring, that at least it's going to be a good and easy to use kind of protocol. And all those benefits like extra range and more data, those are all going to come from the radio side, the controller side. And it's not going to make it any more difficult for kind of your embedded developers out there when you try and incorporate audio and things like that. Right now, BLE audio isn't a thing. Right. Because it isn't fast enough.

So when I'm working, when I have BLE headphones or Bluetooth headphones, it's maybe BLE setup, but then the old Bluetooth is what's actually sending the data, right? Yeah, most headphones are all headphones, and Bluetooth speakers are Bluetooth Classic. So they still use the old standard for transferring data with Bluetooth 2.1. And it'll be interesting to see if they try and incorporate audio into Bluetooth 5 because they're going to have to maintain backwards compatibility anyway.

But who knows? We'll see what it turns into. Well, I think that's about all we have time for. Chris, do you want to ask any last questions? Not without starting another long back and forth, I think. I do have some questions about how apps work and do they need to be running all the time?

Because it seems like they don't to be connected to simple things. But that's kind of an iOS question or an Android question more than a Bluetooth question. Yeah, I agree. But, I mean, there's power implications on not just for your sensor but also for your phone when you're connected to things persistently but i think the os's do stuff

the os's do stuff and they they do let you go in the background um there are a lot of parameters we haven't talked about, such as intervals. But that really requires a whiteboard. So I'm not going to ask you those questions. Instead, I will just ask if you have any thoughts you'd like to leave us with. Yeah, honestly, I can't think of any final thoughts. I'm a little bit frazzled from this conversation. It was sort of like a giant quiz, wasn't it?

Defending the BLE thesis. My head is kind of spinning right now. So yeah, no final thoughts from me. But this was a lot of fun. Thank you very much for being with us and helping us convey the BLE information. Yeah, thank you for having me. This was a lot of fun. Thank you.

Our guest has been Jackson Keating. He's a firmware engineer at Identity Card. Thank you to Christopher for producing and co-hosting. Thank you to Chris Gamble from the Enemy podcast, The Amp Hour, for hooking me up with Jackson Keating. And once again, I want to let our Patreon supporters know how much I appreciate being able to send mics to guests. You make the show better and my life a little easier. And for the rest of you, and well, I mean, for everyone who is

still listening, thank you for listening you can always contact us at show at embedded.fm or hit the contact link on embedded.fm a quote to leave you with which now seems so appropriate this one's from Lewis Carroll you're entirely bonkers but I'll tell you a secret. All the best people are. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show,

we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.