The Two Flavours of Bluetooth
There are two distinct types of Bluetooth.Bluetooth BR/EDR is the original Bluetooth. Sometimes you see this referred to as Bluetooth Classic.
Bluetooth LE has been around since about 2010. Sometimes you see it referred to as BLE. Bluetooth LE was designed to be extremely power efficient, with devices often able to run off a small, coin-sized battery for years.
Bluetooth BR/EDR and Bluetooth LE are not the same and you cannot use one to talk to the other. Both devices must be using the same type of Bluetooth.
1. Bluetooth BR/EDR
Think of Bluetooth BR/EDR as being like an invisible serial cable. Raw data can flow in either direction down this invisible cable, connecting two devices.Bluetooth BR/EDR has been around for about 20 years and it's still dominant in audio products like wireless headphones.
Developers often use something called the Serial Port Profile to send and receive data using Bluetooth BR/EDR.
BBC micro:bits do not support Bluetooth BR/EDR.
2. Bluetooth Low Energy (LE)
Bluetooth LE supports direct communication between two devices but it also has the ability to broadcast data so that one broadcasting device can communicate with many (a limitless number) of other, in-range devices acting as receivers. This broadcast capability is technically known as advertising.The programming concepts for Bluetooth LE are quite different to those that typically apply to Bluetooth BR/EDR and the invisible serial cable idea no longer applies.
Programming and Bluetooth LE
Understanding some key terminology and concepts will help you get started with Bluetooth LE.Bluetooth LE is typically used in conjunction with a Bluetooth concept known as GATT. Technically, it's possible to use GATT with Bluetooth BR/EDR but this is uncommon. GATT and Bluetooth LE normally go together.
GATT makes the device we connect to and want to communicate with, look much more structured than the Bluetooth BR/EDR invisible cable idea. Devices appear to have different parts or components, that we can easily talk independently to.
Services
A device like a micro:bit consists of a number of different components and can also have things connected to it. It makes sense (because it's useful) to be able to exchange data with or interact with some of those components wirelessly, from another device.For example, the micro:bit contains an accelerometer which measures acceleration in three dimensions. It would be useful if the data measured by the accelerometer could somehow be available to other devices over a Bluetooth LE connection so that it can be captured, visualised and so on. If you've used Bitty Data Logger, you'll know that this is in fact possible.
Similarly, a micro:bit has a couple of buttons. It would be useful if another device, connected over Bluetooth, could be informed whenever one of these buttons was pressed. And... you guessed it.... this is indeed possible.
GATT services represent a particular component or device capability and make it available over Bluetooth from another device. If you include a particular service in your code (we'll come to that), what you're doing is saying "I want it to be possible for another device to interact with this component over a Bluetooth connection" or "I want to receive/send data relating to this aspect of my micro:bit" or words to that effect.
So micro:bit has a collection of pre-defined services which make the various things a micro:bit contains and can do, available over Bluetooth from another device, like a smartphone application.
There's a full list and further details of the micro:bit's Bluetooth services here. As you'll quickly notice, this includes an accelerometer service, which makes accelerometer data available over Bluetooth and a button service which will report changes in the state of buttons to the connected device. Simples!
Characteristics
A characteristic is a data item. It has a type and a value and belongs to a service. For example, the accelerometer service contains two characteristics. Accelerometer Data contains the latest accelerometer reading and is automatically updated by the micro:bit firmware for you. Accelerometer Period indicates how frequently, accelerometer values should be transmitted to a connected device, assuming it has requested this.Descriptors
A descriptor is attached to a characteristic and provides extra information or sometimes a configuration setting for that characteristic. It might indicate the way the value of the characteristic should be presented to the user, for example. Or it might be a flag which switches on or off, the transmission of characteristic values to the connected device.Bluetooth LE and MakeCode
MakeCode makes it really easy to include Bluetooth LE in your micro:bit code. Some services, like the event service are included automatically, without you needing to do anything. Others, like the button service must be included by you in your code. To do this, you must first add the Bluetooth extension to your project (look in the Advanced section for +Extensions) and then drag the service blocks you want, into your on start block.
Don't include services unless you know you are going to use them. They take up memory.
In many cases, this is all you'll need to do when using MakeCode. Add the appropriate service and it's then up to the connected device to use it appropriately.
Bluetooth LE and micro:bit Events
micro:bit has a powerful event system which is made available to other devices via its very own Bluetooth service, the event service. Events are an important programming concept. Read all about events here.Using the Bluetooth event service involves your code raising (i.e. creating) events, to send data to another device connected using Bluetooth or handling events which your code receives. Events are not a Bluetooth concept, by the way. They can come from or be sent to all sorts of other micro:bit components, but we're talking about Bluetooth here.
Here's some code which sends different events to Bitty Blue, depending on whether the temperature is too cold or too hot.
Here's some code which handles events sent from Bitty Blue to set the upper and lower temperature limits for monitoring purposes.
Events and the Bluetooth event service feature in many of our coding examples and tutorials, like this one for temperature monitoring with Bitty Blue.
Bluetooth LE connections
A micro:bit is either connected to another device over Bluetooth or it is not. You can track these two states using MakeCode blocks, as shown in this example.
Profiles
You've already encountered the term profile. What does it mean? Put simply, it's just the set of rules for how a device is used with Bluetooth. It includes, for example an indication of the GATT services that are involved.Device Roles
Bluetooth LE defines a number of different roles that a device can play and these roles determine what it can or cannot do when it comes to communicating with other devices. There are two which have particular relevance to the BBC micro:bit. Formally, these roles are defined by a part of the Bluetooth LE specification known as GAP.A micro:bit is a GAP Peripheral. This means it can invite other devices, playing the GAP Central role to discover and connect to it. A GAP Peripheral cannot, discover and connect to another device.
A smartphone usually plays the part of a GAP Central device. This means it can scan for GAP Peripheral devices and attempt to connect. A GAP Central cannot be connected to. It initiates the connection to GAP Peripheral devices, not the other way around.
Bluetooth LE devices can play all roles at the same time and, for example, be both a Peripheral and a Central device so that either device can initiate and accept a connection. Unfortunately though, a BBC micro:bit cannot. Due to its very limited memory, it can only act as a GAP Peripheral and be connected to. Consequently it is not possible to use Bluetooth LE for one micro:bit to communicate directly with another since in that scenario, one would need to be playing the Peripheral role and the other the Central role.
Pairing
Bluetooth pairing is a security procedure. It equips the two devices in a pairing with a series of shared security keys which allow communication to be encrypted. It also ensures that only paired devices can connect to your micro:bit. Other devices attempting to connect (and therefore, stopping you from connecting from your device!) are ignored if they have not been paired.micro:bit supports two different ways of pairing and you can select them from the MakeCode project settings screen.
Whichever pairing method you use, the result is the same level of security. During the pairing procedure itself though, one of the two methods is more secure than the other.
Passkey Pairing is the most secure of the two procedures and requires you to enter a 6 digit number, displayed on the micro:bit into the other device, often a smartphone. This offers protection against man-in-the-middle (MITM) attacks.
Just Works Pairing is not as secure but it does not require you to enter anything and therefore is very simple to use. It may well be secure enough for your purposes. But only you can decide whether that is the case or not.
Opting to use No Pairing provides the greatest simplicity but obviously, no security. Communication is not encrypted and any other GAP Central device can connect to your micro:bit, which could be disruptive.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.