Skip to main content
W
Warsha Everything Mobile
Documentation / BLE Studio / macOS / Bluetooth LE Basics
Browse documentation

Start Here

Included with Warsha BLE Studio for macOS

v1.3.1

Bluetooth LE Basics

This page is for anyone new to Bluetooth Low Energy. It explains the handful of ideas the rest of the Studio is built on: who talks to whom, how devices find each other, and what the data looks like once they connect. You don’t need to know any of it to run a preset, but every screen in the app makes more sense once you do.

You can skip around. Each section stands on its own, and there is a short glossary at the end.

Two kinds of Bluetooth

“Bluetooth” names two different technologies that share a radio:

  • Bluetooth Classic streams a continuous connection: headphones, speakers, car audio, older keyboards.
  • Bluetooth Low Energy (BLE, or Bluetooth LE) sends small amounts of data, briefly and often. It runs heart-rate straps, fitness machines, smart locks, sensors, beacons, game controllers and most modern keyboards and mice.

They are not compatible with each other. A device that only speaks one can’t talk to a device that only speaks the other, even though both say “Bluetooth” on the box.

Warsha BLE Studio works with Bluetooth LE only. It can’t stand in for headphones or a speaker, because those use Bluetooth Classic.

Peripherals and centrals

Every Bluetooth LE connection has two sides:

  • A peripheral has the data and announces that it’s there. A heart-rate strap is a peripheral.
  • A central looks for peripherals, connects to one, and uses its data. The phone app that shows your heart rate is the central.

The roles describe what a device is doing at the moment, not what it is. A phone is usually a central, but it can also act as a peripheral. That is exactly what the Studio does.

You useThe Studio acts asThe other side
Build and SessionA peripheral, the device being testedYour app, a phone, a watch, a computer: the central
ExploreA central, the testerA real device nearby: the peripheral

Advertising: how devices find each other

A peripheral that wants to be found advertises. Several times a second, it broadcasts a tiny packet to anyone listening. A central scans: it listens for those packets and lists what it hears.

An advertisement is small, usually 31 bytes, so a peripheral puts only the essentials in it:

  • a name, often shortened to fit;
  • service UUIDs, which say what it can do, such as “I measure heart rate”;
  • manufacturer data, which is anything the maker wants and often identifies the product;
  • flags and, sometimes, its transmit power.

Some devices never accept a connection and only advertise. Beacons work this way: everything they have to say fits in the advertisement.

Signal strength (RSSI)

Each advertisement a central receives comes with an RSSI, the received signal strength, in dBm. The numbers are negative:

  • around −40 means very close;
  • around −90 means barely in range.

RSSI jumps around from one packet to the next, and walls, bodies and other devices all change it. Treat it as a rough “nearer or farther”, not as a distance.

Connecting

When a central finds a peripheral it wants, it connects. A connection is private between the two, and it’s where the real exchange of data happens. Many peripherals stop advertising while they’re connected, so a device that’s already in use by one phone can disappear from another phone’s scan. That’s often why “my device doesn’t show up”.

GATT: how the data is organized

Once connected, the central asks the peripheral what it offers. The answer is a tree called the GATT (Generic Attribute Profile):

Peripheral
├── Service: Heart Rate                       0x180D
│   ├── Characteristic: Heart Rate Measurement   0x2A37   notify
│   └── Characteristic: Body Sensor Location     0x2A38   read
└── Service: Battery                          0x180F
    └── Characteristic: Battery Level            0x2A19   read, notify
  • A service groups everything for one job, such as heart rate or battery.
  • A characteristic is one value inside a service: the current heart rate, the battery percentage. This is what you read, write or subscribe to.
  • A descriptor is a small note attached to a characteristic. It might give a human-readable description, or hold the switch that turns notifications on.

Explore’s GATT tab shows this tree for a real device. A preset or script builds the same kind of tree for the peripheral the Studio runs.

UUIDs

Every service and characteristic has a UUID that says what it is.

  • Short UUIDs such as 0x180D are assigned by the Bluetooth SIG, the group that maintains the standard. They mean the same thing on every device in the world. 0x180D is always Heart Rate.
  • Long UUIDs such as 6E400001-B5A3-F393-E0A9-E50E24DCCA9E are made up by a manufacturer for its own features. Only the manufacturer’s own app knows what they mean.

A device usually mixes both: standard services where one exists, and custom ones for everything else.

What you can do with a characteristic

Each characteristic lists the operations it supports, called its properties:

PropertyWhat happensExample
ReadThe central asks for the current valueReading the battery level once
WriteThe central sends a value and the peripheral confirms itSetting a fitness machine’s target speed
Write without responseThe central sends a value, with no confirmationSending a stream of key presses
NotifyThe peripheral sends each new value as it changes, without being askedHeart rate, every second
IndicateLike notify, but the central confirms each oneImportant status changes

To receive notifications or indications, a central subscribes. It switches them on by writing to a descriptor on that characteristic. In Explore, Subscribe does this for you.

Values are bytes

A characteristic’s value is a short sequence of bytes, usually written in hexadecimal. Standard characteristics define exactly how to read those bytes. A Heart Rate Measurement of 00 48, for example, means:

  • 00: flags. Here they say “the heart rate fits in one byte, and nothing else follows”.
  • 48: the heart rate. Hexadecimal 48 is 72 beats per minute.

Numbers that take more than one byte are usually sent smallest byte first, which is called little-endian. Explore decodes the standard values it knows and shows the rest as raw bytes. For a characteristic it doesn’t know, you can describe the fields yourself with Describe value….

Profiles

A profile is the rulebook for one kind of device: which services it must have, which characteristics, and how a central should use them. The Heart Rate Profile says a heart-rate sensor offers the Heart Rate service, and how a phone should subscribe to it. HID over GATT says how a Bluetooth LE keyboard or mouse works.

The Studio’s built-in presets each follow one or more of these profiles. That’s why an off-the-shelf fitness app can connect to one and treat it like real hardware. The Open BLE Protocols Reference goes through each profile in detail.

Pairing and bonding

Most Bluetooth LE devices let any central connect and read them, with no pairing at all. Some need more:

  • Pairing is a one-time exchange of keys, so the connection can be encrypted. It is when you see a prompt to confirm a code, or to just accept.
  • Bonding means both sides remember those keys, so they reconnect securely next time without asking again.

Keyboards, mice and anything holding personal data usually require pairing. Pair them from the host device’s own Bluetooth settings, the way you would pair a real accessory. If a device asks for pairing in Explore, the system’s pairing prompt appears.

Privacy and device addresses

Every Bluetooth device has an address, but many change theirs from time to time so they can’t be tracked. The same device can therefore appear under more than one address, or under a new one tomorrow.

macOS never shows a device’s Bluetooth address to apps. It gives each device an identifier that is valid on this Mac only, so the same device has a different identifier on another computer.

Because nearby devices can reveal where you are, operating systems treat Bluetooth scanning as a privacy-sensitive permission. On macOS, the app asks once for permission to use Bluetooth. You can change it later in System Settings → Privacy & Security → Bluetooth.

Limits worth knowing

  • Range. Typically ten meters or so indoors, and more in open space. Walls and bodies shorten it.
  • Small packets. By default, one notification carries up to 20 bytes of data. Devices can agree on a larger size, called the MTU, when they connect. That’s why fast data is sent as many small updates rather than one big one.
  • One device, one role at a time. A device can’t reliably scan for a peripheral it is itself advertising. To explore a peripheral you’re running in the Studio, use a second device.
  • Remembered services. Some centrals remember a device’s services from an earlier connection. If you change a peripheral’s services and a central still shows the old ones, forget the device in that central’s Bluetooth settings, or turn its Bluetooth off and on.

Try it

The quickest way to see all of this at once takes two devices with the Studio installed:

  1. On the first, run the Heart Rate Strap preset with the destination set to On-air BLE. It starts advertising.
  2. On the second, open Explore and scan. The strap appears with its name, its signal strength and the Heart Rate service in its advertisement.
  3. Connect to it. The GATT tab shows its Heart Rate, Battery and Device Information services.
  4. Open Heart Rate Measurement and choose Subscribe. A new value arrives every time the first device updates it, both as bytes and as beats per minute.

You’ve just seen a peripheral advertise, a central scan, connect, discover the GATT and subscribe to a notification. That’s the whole of Bluetooth LE in miniature.

With only one device, run the same preset in Local Simulation instead. The values and controls are the same, and nothing uses the radio.

Glossary

TermMeaning
AdvertisementA small packet a peripheral broadcasts so others can find it
BLE, Bluetooth LEBluetooth Low Energy: the low-power kind of Bluetooth this app uses
BondingRemembering pairing keys, so the next connection is secure without asking
CentralThe device that scans and connects: usually a phone, tablet or computer
CharacteristicOne value inside a service, which can be read, written or subscribed to
DescriptorA small note attached to a characteristic, such as the notification switch
GATTThe tree of services and characteristics a peripheral offers once connected
IndicateA value the peripheral sends on its own, which the central confirms
MTUThe largest single packet two connected devices have agreed on
NotifyA value the peripheral sends on its own whenever it changes
PairingExchanging keys so a connection can be encrypted
PeripheralThe device that advertises and holds the data, such as a sensor or strap
ProfileThe rules for one kind of device: which services, and how to use them
RSSIReceived signal strength, in dBm. Closer to zero is stronger
ScanListening for advertisements
ServiceA group of characteristics for one job, such as heart rate or battery
UUIDThe identifier of a service or characteristic. Short ones are standard, long ones custom

Next steps