Bluetooth Low Energy
Android 4.3 (API Level 18) introduces built-in platform support for Bluetooth Low Energy in the central role and provides APIs that apps can use to discover devices, query for services, and read/write characteristics. In contrast to Classic Bluetooth, Bluetooth Low Energy (BLE) is designed to provide significantly lower power consumption. This allows Android apps to communicate with BLE devices that have low power requirements, such as proximity sensors, heart rate monitors, fitness devices, and so on.
Key Terms and Concepts
Here is a summary of key BLE terms and concepts:
- Generic Attribute Profile (GATT)—The GATT profile is a general specification for sending and receiving short pieces of data known as «attributes» over a BLE link. All current Low Energy application profiles are based on GATT.
- The Bluetooth SIG defines many profiles for Low Energy devices. A profile is a specification for how a device works in a particular application. Note that a device can implement more than one profile. For example, a device could contain a heart rate monitor and a battery level detector.
Roles and Responsibilities
Here are the roles and responsibilities that apply when an Android device interacts with a BLE device:
- Central vs. peripheral. This applies to the BLE connection itself. The device in the central role scans, looking for advertisement, and the device in the peripheral role makes the advertisement.
- GATT server vs. GATT client. This determines how two devices talk to each other once they’ve established the connection.
To understand the distinction, imagine that you have an Android phone and an activity tracker that is a BLE device. The phone supports the central role; the activity tracker supports the peripheral role (to establish a BLE connection you need one of each—two things that only support peripheral couldn’t talk to each other, nor could two things that only support central).
Once the phone and the activity tracker have established a connection, they start transferring GATT metadata to one another. Depending on the kind of data they transfer, one or the other might act as the server. For example, if the activity tracker wants to report sensor data to the phone, it might make sense for the activity tracker to act as the server. If the activity tracker wants to receive updates from the phone, then it might make sense for the phone to act as the server.
In the example used in this document, the Android app (running on an Android device) is the GATT client. The app gets data from the GATT server, which is a BLE heart rate monitor that supports the Heart Rate Profile. But you could alternatively design your Android app to play the GATT server role. See BluetoothGattServer for more information.
BLE Permissions
In order to use Bluetooth features in your application, you must declare the Bluetooth permission BLUETOOTH . You need this permission to perform any Bluetooth communication, such as requesting a connection, accepting a connection, and transferring data.
If you want your app to initiate device discovery or manipulate Bluetooth settings, you must also declare the BLUETOOTH_ADMIN permission. Note: If you use the BLUETOOTH_ADMIN permission, then you must also have the BLUETOOTH permission.
Declare the Bluetooth permission(s) in your application manifest file. For example:
If you want to declare that your app is available to BLE-capable devices only, include the following in your app’s manifest:
However, if you want to make your app available to devices that don’t support BLE, you should still include this element in your app’s manifest, but set required=»false» . Then at run-time you can determine BLE availability by using PackageManager.hasSystemFeature() :
Setting Up BLE
Before your application can communicate over BLE, you need to verify that BLE is supported on the device, and if so, ensure that it is enabled. Note that this check is only necessary if <uses-feature. /> is set to false.
If BLE is not supported, then you should gracefully disable any BLE features. If BLE is supported, but disabled, then you can request that the user enable Bluetooth without leaving your application. This setup is accomplished in two steps, using the BluetoothAdapter .
The BluetoothAdapter is required for any and all Bluetooth activity. The BluetoothAdapter represents the device’s own Bluetooth adapter (the Bluetooth radio). There’s one Bluetooth adapter for the entire system, and your application can interact with it using this object. The snippet below shows how to get the adapter. Note that this approach uses getSystemService() to return an instance of BluetoothManager , which is then used to get the adapter. Android 4.3 (API Level 18) introduces BluetoothManager :
Next, you need to ensure that Bluetooth is enabled. Call isEnabled() to check whether Bluetooth is currently enabled. If this method returns false, then Bluetooth is disabled. The following snippet checks whether Bluetooth is enabled. If it isn’t, the snippet displays an error prompting the user to go to Settings to enable Bluetooth:
If you want to scan for only specific types of peripherals, you can instead call startLeScan(UUID[], BluetoothAdapter.LeScanCallback) , providing an array of UUID objects that specify the GATT services your app supports.
Here is an implementation of the BluetoothAdapter.LeScanCallback , which is the interface used to deliver BLE scan results:
Note: You can only scan for Bluetooth LE devices or scan for Classic Bluetooth devices, as described in Bluetooth. You cannot scan for both Bluetooth LE and classic devices at the same time.
Connecting to a GATT Server
The first step in interacting with a BLE device is connecting to it— more specifically, connecting to the GATT server on the device. To connect to a GATT server on a BLE device, you use the connectGatt() method. This method takes three parameters: a Context object, autoConnect (boolean indicating whether to automatically connect to the BLE device as soon as it becomes available), and a reference to a BluetoothGattCallback :
This connects to the GATT server hosted by the BLE device, and returns a BluetoothGatt instance, which you can then use to conduct GATT client operations. The caller (the Android app) is the GATT client. The BluetoothGattCallback is used to deliver results to the client, such as connection status, as well as any further GATT client operations.
In this example, the BLE app provides an activity ( DeviceControlActivity ) to connect, display data, and display GATT services and characteristics supported by the device. Based on user input, this activity communicates with a Service called BluetoothLeService , which interacts with the BLE device via the Android BLE API:
When a particular callback is triggered, it calls the appropriate broadcastUpdate() helper method and passes it an action. Note that the data parsing in this section is performed in accordance with the Bluetooth Heart Rate Measurement profile specifications:
Back in DeviceControlActivity , these events are handled by a BroadcastReceiver :
Reading BLE Attributes
Once your Android app has connected to a GATT server and discovered services, it can read and write attributes, where supported. For example, this snippet iterates through the server’s services and characteristics and displays them in the UI:
Receiving GATT Notifications
It’s common for BLE apps to ask to be notified when a particular characteristic changes on the device. This snippet shows how to set a notification for a characteristic, using the setCharacteristicNotification() method:
Once notifications are enabled for a characteristic, an onCharacteristicChanged() callback is triggered if the characteristic changes on the remote device:
Closing the Client App
Once your app has finished using a BLE device, it should call close() so the system can release resources appropriately:
Bluetooth LE не так уж и страшен, или Как улучшить пользовательский опыт без особых усилий
Недавно мы в команде придумали и реализовали функцию передачи денег по воздуху с помощью технологии Bluetooth LE. Я хочу рассказать вам, как мы это сделали и что Apple предоставляет нам из инструментов. Многие разработчики думают что Bluetooth — это сложно, ведь это достаточно низкоуровневый протокол, и по нему не так много специалистов. Но всё не так страшно, и на самом деле использовать эту функцию очень просто! А те функции, которые можно реализовать с помощью Bluetooth LE, безусловно, интересны и впоследствии позволят выделить ваше приложение среди конкурентов.
Давайте сначала разберёмся, что это вообще за технология и в чём её отличие от классического Bluetooth.
Что такое Bluetooth LE?
Почему разработчики Bluetooth назвали эту технологию именно Low Energy? Ведь с каждой новой версией Bluetooth энергопотребление и без того многократно снижалось. Ответ кроется в этой батарейке.
Её диаметр всего 2 см, а ёмкость около 220 мА*ч. Когда инженеры разрабатывали Bluetooth LE, они стремились к тому, чтобы устройство с такой батарейкой работало несколько лет. И у них это получилось! Bluetooth LE-устройства c таким элементом питания могут работать от года. Кто из вас еще по-старинке выключает Bluetooth на телефоне для экономии энергии, как это делали в 2000-м? Зря вы это делаете — экономия будет меньше 10 секунд работы телефона в день. А функциональность вы отключаете очень большую, такую как Handoff, AirDrop и другие.
Чего же инженеры добились, разработав Bluetooth LE? Они усовершенствовали классический протокол? Сделали его более энергоэфективным? Просто оптимизировали все процессы? Нет. Они полностью переделали архитектуру стека Bluetooth и добились того, что теперь, чтобы быть видимым для всех других устройств, необходимо меньше времени находиться в эфире и занимать канал. В свою очередь это позволило хорошо сэкономить на энергопотреблении. А с новой архитектурой теперь можно стандартизировать любое новое устройство, благодаря чему разработчики со всего мира могут коммуницировать с устройством, а значит, и с легкостью писать новые приложения для управления им. Кроме того, в архитектуру заложен принцип self-discovery: при подключении к устройству не нужно вводить никакие пин-коды, и если ваше приложение умеет общаться с этим устройством, подключение занимает считанные миллисекунды.
- Меньше времени в эфире.
- Меньше расход энергии.
- Новая архитектура.
- Уменьшено время подключения.
Частота осталась та же: 2,4 ГГц, не сертифицируемая и свободная для использования во многих странах. А вот задержка подключения стала меньше: 15-30 мс вместо 100 мс у классического Bluetooth. Расстояние работы осталось таким же — 100 м. Интервал передачи не сильно, но изменился — вместо 0,625 мс стало 3 мс.
Но не могло же из-за этого энергопотребление уменьшиться в десятки раз. Конечно же, что-то должно было пострадать. И это скорость: вместо 24 Мбит/с стало 0,27 Мбит/с. Вы, наверное, скажете, что это смешная скорость для 2018 года.
Где используется Bluetooth LE?
Технология эта немолодая, впервые она появилась в iPhone 4s. И уже успела завоевать много сфер. Bluetooth LE используется во всех устройствах умного дома и в носимой электронике. Сейчас уже есть даже чипы размером с кофейное зерно.
А как эта технология применяется в программном обеспечении?
Поскольку Apple была первой, кто встроил в своё устройство Bluetooth и начал её использовать, то к настоящему времени они достаточно хорошо продвинулись и встроили технологию в свою экосистему. И сейчас вы можете встретить эту технологию в таких сервисах, как AirDrop, Devices quick start, Share passwords, Handoff. И даже уведомления в часах сделаны через Bluetooth LE. Вдобавок, Apple выложила в открытый доступ документацию, как сделать так, чтобы на ваши собственные устройства приходили уведомления из всех приложений. Какие бывают роли устройств в рамках Bluetooth LE?
Broаdcaster. Отправляет сообщения всем, кто находится рядом, к этому устройству нельзя подключиться. По такому принципу работают iBeacons и навигация в помещениях.
Observer. Слушает, что происходит вокруг, и получает данные только от общедоступных сообщений. Соединения не создаёт.
А вот с Central и Peripheral интереснее. Почему их не назвали просто Server-Client? Логично же, судя по названию. А вот и нет.
Потому что Peripheral, на самом деле, выступает как сервер. Это периферийное устройство, которое потребляет меньше энергии и к которому подключается более мощный Central. Peripheral может извещать, что он находится рядом и какие у него есть службы. К нему может подключиться только одно устройство, и у Peripheral есть какие-то данные. А Central может сканировать эфир в поиске устройств, отправлять запросы на подключение, подключаться к любому количеству устройств, может читать, записывать и подписывать на данные у Peripheral.
Что же нам, как разработчикам, доступно в экосистеме Apple?
Что нам доступно?
iOS/Mac OS:- Peripheral и Central.
- Фоновый режим.
- Восстановление состояния.
- Интервал подключения 15 мс.
- watchOS 4+/tvOS 9+.
- Только Сentral.
- Максимум два подключения.
- Apple watch series 2+/ AppleTv 4+.
- Отключение при переходе в фоновый режим.
- Интервал подключения 30 мс.
Как работает протокол
Как происходит процесс поиска и подключения?Peripheral сообщает о своем присутствии с частотой advertisement-интервала, его пакет очень маленький и содержит всего несколько идентификаторов сервисов, которые предоставляет устройство, а также имя устройства. Интервал может быть достаточно большим и способен варьироваться в зависимости от текущего статуса устройства, режима энергосбережения и других настроек. Apple советует разработчикам внешних устройств привязывать длину интервала к акселерометру: увеличивать интервал, если устройством не пользуются, а когда оно активно — уменьшать, чтобы быстро находить устройство. Advertisement-интервал никак не коррелирует c интервалом подключения и определяется самим устройством в зависимости от энергопотребления и своих настроек. Нам он в экосистеме Apple недоступен и неизвестен, им полностью управляет система.
После того, как мы нашли устройство, отправляем запрос на подключение, и вот тут на сцену выходит интервал подключения — время, через которое второе устройство может ответить на запрос. Но это при подключении, а что же происходит при чтении/записи?
Интервал подключения также фигурирует и при чтении данных — его уменьшение в 2 раза увеличивает скорость передачи данных. Но нужно понимать, что если оба устройства не поддерживают одинаковый интервал, то будет выбран максимальный из них.
Давайте рассмотрим, из чего состоит пакет с информацией, который передает Peripheral.
MTU (maximum transmission unit) такого пакета определяется в процессе подключения и варьируется от устройства к устройству и в зависимости от операционной системы. В протоколе версии 4.0 MTU был около 30, и размер полезных данных не превышал 20 байтов. В версии 4.2 всё поменялось, теперь можно передавать около 520 байтов. Но, к сожалению, эту версию протокола поддерживают только устройства младше IPhone 5s. Размер накладных расходов, независимо от размера MTU, составляет 7 байтов: сюда входят ATT и L2CAP заголовков. С записью, в целом, похожая ситуация.
Есть только два режима: с ответом и без. Режим без ответа значительно ускоряет передачу данных, поскольку нет интервала ожидания перед следующей записью. Но этот режим доступен не всегда, не на всех устройствах и не на всех системах. Доступ к этому режиму записи может ограничить сама система, потому что он считается менее энергоэкономичным. В iOS eсть метод, в котором можно проверить перед записью, доступен ли такой режим.
Теперь давайте рассмотрим, из чего состоит протокол.
Протокол состоит из 5 уровней. Слой приложения — эта ваша логика, описанная поверх CoreBluetooth. GATT (Generic Attributes Layer) служит для обмена сервисами и характеристиками, которые есть на устройствах. ATT (Attributes Layer) используется для управления вашими характеристиками и передачей ваших данных. L2CAP — низкоуровневый протокол обмена данными. Controller — это уже сам BT-чип.
Вы, наверное, спросите, что такое GATT и как мы можем с ним работать?
GATT состоит из характеристики и сервисов. Характеристика — это объект, в котором хранятся ваши данные, словно переменная. А сервис — это группа, в которой находятся ваши характеристики, словно пространство имён. У сервиса есть название — UUID, вы сами его выбираете. Сервис может содержать в себе дочерний сервис.
У характеристики тоже есть свой UUID — фактически, имя. Значение (Value) характеристики — это NSData, сюда вы можете записывать и хранить данные. Дескрипторы — это описание вашей характеристики, вы можете описать, какие данные вы ожидаете в этой характеристике, или что они означают. В протоколе Bluetooth есть много дескрипторов, но в Apple-системах пока доступно только два: человеческое описание и формат данных. Также есть уровни доступа (Permissions) для вашей характеристики:
Попробуем сами
У нас появилась идея сделать возможность передачи денег по воздуху, ничего не требуя от получателя. Представьте, вот ломаете голову над очень интересной задачей, пишете идеальный код, и тут коллега предлагает сходить за кофе. А вы так увлечены задачей, что не можете отлучиться, и просите его купить вам чашечку вкусного капучино. Он приносит вам кофе, и нужно вернуть ему деньги. Можно перевести по номеру телефона, работает отлично. Но вот неловкая ситуация — вы не знаете его номера. Ну вот так, три года работаете, а номерами не обменялись 🙂Поэтому мы решили сделать возможность передачи денег тем, кто находится рядом, без ввода каких-либо пользовательских данных. Как в AirDrop. Просто выбрать пользователя и отправить нужную ему сумму. Давайте посмотрим, что нам для этого нужно.
Отображение PUSH
Нам нужно, чтобы отправитель:- Мог найти все устройства, которые находятся рядом и поддерживают наш сервис.
- Мог прочитать реквизиты.
- И мог отослать сообщение получателю о том, что успешно отправил ему деньги.
Для начала нужно придумать названия нашего сервиса и характеристик. Как я говорил, это UUID. Просто генерируем их и сохраняем на Peripheral и Central, чтобы на обоих устройствах были одинаковые.
Вы вольны использовать любые UUID, кроме тех, которые оканчиваются вот так: XXXXXXXX-0000-1000-8000-00805F9B34FB, — они зарезервированы под разные компании. Вы сами можете купить себе такой номер и никто его использовать не будет. Это будет стоить $2500.
Далее нам нужно будет создать менеджеры: один для передачи денежных средств, другой для получения. Нужно просто указать делегатов. Передавать у нас будет Central, получать Peripheral. Мы создаем оба, потому что и отправителем, и получателем может быть одно лицо в разное время.
Теперь нам нужно сделать возможность обнаружения получателя и записать в нашу характеристику реквизиты получателя.
Для начала создадим сервис. Пропишем UUID и укажем, что он primary — то есть сервис является главным для этого устройства. Хороший пример: пульсомер, для которого главным сервисом будет текущее состояние пульса, а состояние батареи — это второстепенная информация.
Далее создаем две характеристики: одну для чтения реквизитов получателя, вторую для записи, чтобы получатель мог узнать об отправке денег. Регистрируем их в нашем сервисе, потом добавляем в менеджер, запускаем обнаружение и указываем UUID сервиса, чтобы все устройства, которые находятся рядом, могли узнать о нашем сервисе до подключения к нему. Эти данные помещаются в пакет, который отправляет Central в ходе вещания.
Получатель готов, приступим к отправителю. Запустим поиск и подключение.
При включении менеджера мы запускаем поиск устройств с нашим сервисом. При нахождении мы их получаем в методе делегата и сразу подключаемся. Важно: нужно сохранять strong-ссылку на все Peripheral, с которыми вы работаете, иначе они «утекут».
После успешного подключения настраиваем делегат, который будет работать с данным устройством, и получаем от устройства нужный нам сервис.
Мы успешно подключились к получателю, теперь нужно прочитать его реквизиты.
Мы после подключения уже запросили все сервисы с устройства. И после их получения будет вызван метод делегата, в котором будут перечислены все сервисы, доступные на данном устройстве. Находим нужный и запрашиваем его характеристики. Результат можно будет найти по UUID в методе делегата, в котором хранятся данные для перевода. Пробуем их прочитать, и получим искомое опять в методе делегата. Все сервисы, характеристики и их значения кешируются системой, так что запрашивать их впоследствии каждый раз необязательно.
Всё, мы отправили деньги за кофе, самое время показать получателю красивое уведомление, чтобы он ждал рубли на своем счёте. Для этого нужно реализовать процесс отправки сообщения.
У отправителя достаем нужную нам характеристику, в данном случае мы её взяли из сохраненного значения. Но до этого вам её нужно получить с устройства, как мы делали до этого. А дальше просто записываете данные в нужную характеристику.
После этого на другом устройстве получаем в методе делегата запрос на запись. Тут вы можете прочитать данные, которые вам отправляют, ответить на какую-либо ошибкой, например, нет доступа, или данной характеристики не существует. Всё будет работать, но только если оба устройства включены и приложения активны. А нам нужно, чтобы работало и в фоне!
Apple позволяет использовать Bluetooth в фоне. Для этого нужно в info.plist указать ключ, в каком режиме мы хотим использовать, в Peripheral или Central.
Далее в менеджере нужно указать ключ восстановления и создать метод делегата. Теперь нам доступен и фоновый режим. Если приложение заснёт или будет выгружено из памяти, то при нахождении нужного Peripheral или при подключении Central оно проснётся, а менеджер восстановится с вашим ключом.
Всё отлично, уже готовы релизиться. Но тут к нам прибегают дизайнеры и говорят: «Хотим вставить фотографии пользователей, чтобы им было легче находить друг друга». Что же делать? У нас в характеристику можно записать всего какие-то 500 байтов, а на каких-то устройствах вообще 20 🙁
Спустимся глубже
Чтобы решить эту проблему, нам пришлось спуститься глубже.
Сейчас мы общались устройствами на уровне GATT/ATT. Но в iOS 11 у нас есть доступ к протоколу L2CAP. Однако в этом случае придётся самостоятельно позаботиться о передаче данных. Пакеты отправляются с MTU 2 Кб, не нужно ни во что перекодировать, применяется обычный NSStream. Скорость передачи данных до 394 Килобит/с., по заверению Apple.
Допустим, вы передаёте какие-либо данные вашего сервиса от Peripheral к Central в виде обычных характеристик. И понадобилось открыть канал. Вы открываете его на Peripheral, в ответ получаете PSM — это номер канала, к которому можно подключиться, и нужно с помощью тех же характеристик передать его Central. Номер динамический, система сама выбирает, какой PSM открыть в данный момент. После передачи можно уже на Сentral подключиться к Peripheral и обмениваться данными в удобном для вас формате. Давайте рассмотрим, как это сделать.
Для начала на Peripheral открываем порт с шифрованием. Можно делать и без шифрования, тогда это немного ускорит передачу.
Далее мы в методе делегата получаем PSM и отправляем на другое устройство.
После подключения другого устройства у нас вызовется метод, в котором из канала мы можем достать нужные нам для передачи NSStream.
С Central еще проще, мы просто подключаемся к каналу с нужным номером…
… и после этого получаем нужные нам стримы. В них вы можете передавать абсолютно любые данные любого размера, и строить поверх L2CAP свой протокол. Так мы и реализовали у себя передачу фотографий получателя.
Но есть подводные камни, куда же без них.
Подводные камни
Давайте рассмотрим подводные камни при работе в фоновом режиме. Поскольку вам доступны роли Peripheral и Central, вы можете подумать. что в фоне можете определять, какие устройства рядом находятся в фоновом режиме, а какие в активном. В теории так и должно было быть, но Apple ввела ограничение: телефоны, которые находятся в фоновом режиме, будь то Central или Peripheral, не доступны для других телефонов, которые тоже находятся в фоновом режиме. Также телефоны, которые находятся в фоновом режиме, не видны с неiOS-устройств. Давайте рассмотрим почему так происходит.Когда ваше устройство активно, оно посылает обычный broadcast-пакет, в котором может быть имя устройства и список сервисов. которые предоставляет это устройство. И overflow данные — всё что не поместилось.
Когда же устройство переходит в фоновый режим, оно не передает название, а список поддерживаемых сервисов переносит в overflow-данные. Если приложение активно, то при сканировании с iOS-устройства оно читает эти данные, а при переходе в фон — игнорирует. Поэтому при переходе в фон вы не сможете видеть приложения, которые также находятся в фоне. Остальные операционные системы Apple всегда игнорируют overflow-данные, поэтому если вы будете искать устройства, поддерживающие ваш сервис, то получите пустой массив. А если подключиться к каждому устройству, которое находится рядом, и запросить поддерживаемые сервисы, то в списке, возможно, будет ваш сервис, и вы сможете с ним работать.
Дальше мы уже готовились передавать в тестирование, правили мелкие недочёты, занимались оптимизацией. И вдруг в какой-то момент мы стали получать в консоли эту ошибку:
Самое плохое было в том, что никакой метод делегата не вызывался, мы даже не могли никак обыграть эту ошибку для пользователя. Просто сообщение в лог — и тишина, всё замирало. Никаких особых изменений не вносилось, поэтому мы начали откатываться по коммитам. И обнаружили, что однажды оптимизировали код и переделали способ записи данных. Проблема крылась в том, что не все клиенты были обновлены, поэтому возникала такая ошибка.
Мы, счастливые, что всё исправили, побежали скорее передавать в тестирование, а они нам почти сразу возвращают: «Ваши модные фоточки не работают. Они все недогруженные приходят». Мы начали пробовать, и правда, иногда, на разных устройствах, в разное время приходят битые фотографии. Начали искать причину.
И тут снова увидели прежнюю ошибку. Сразу подумали, что дело в разных версиях. Но после полного удаления старой версии со всех тестовых устройств ошибка всё равно воспроизводилась. Мы взгрустнули…
Начали искать инструмент для отладки. Первое, что нам попалось, это Apple Bluetooth Explorer. Мощная программа, много всего умеет, но вот для отладки протокола Bluetooth LE одна маленькая вкладка с поиском устройств и получением характеристик. А нам-то нужно было анализировать L2CAP.
Потом нашли LightBlue Explorer. Оказалась вполне приличная программа, правда, с дизайном из iOS 7. Может делать то же самое, что и Bluetooth Explorer, а еще умеет подписываться на характеристики. И работает стабильнее. Всё хорошо, но опять без L2CAP.
И тут нам вспомнился всем известный сниффер WireShark.
Оказалось, он знаком с Bluetooth LE: может читать L2CAP, но только под Windows. Хотя это не страшно, что мы, не найдем винду, что ли. Самый большой минус — программа работает только с определенным устройством. То есть нужно было найти где-то устройство в официальном магазине. А вы сами понимаете, в большой компании вряд ли одобрят покупку непонятного устройства на барахолке. Мы даже начали просматривать зарубежные онлайн-магазины.
Но тут обнаружили в Additional Xcode Tools программу PacketLogger. Она позволяет смотреть траффик, которой идет на OS X-устройстве. А почему бы не переписать наш MoneyDrop под OS X? Он у нас уже был отдельной библиотеки. Мы просто заменили UIImage на NSImage, всё завелось само через 10 минут.
Наконец-то мы могли читать пакеты, которыми обмениваются устройства. Сразу стало понятно, что в момент передачи данных по L2CAP записывалась одна из характеристик. А из-за того, что канал был полностью занят передачей фотографии, iOS игнорировала запись, а отправитель после игнора обрывал канал. После исправления проблем с передачей фотографии не было.
How Bluetooth LE works? — Link layer
This is the first post and hopefully a series of upcoming postings about Bluetooth Low Energy. Above figure is the protocol stack of a whole Bluetooth LE system.
The Bluetooth LE is one part of Bluetooth v4.0 specification, it was designed not to pursue high transmission speed but for lower energy consumption. So the Bluetooth LE products can be powered by a button-cell battery for years. How did it do that? This article is a review of Robin Heydon’s excellent book — Bluetooth Low Energy, the developer’s handbook.
Bluetooth LE is completely redesigned of classic Bluetooth protocol, It seems that both the Bluetooth LE and classic Bluetooth has the same architecture from above figure, but actually they are so different inside, an event in the physical layer.
2. Bluetooth LE Physical layer
BLE still works in 2.4GHz ISM band of course, but it have 40 channels with 3 of them as advertising channels and the rest of them as data channels, and each channel’s bandwidth is 2 MHz. There is a website named 37channels, which is made to advertising Robin Heydon’s book Bluetooth Low Energy The Developer’s Handbook. Did you get the meaning of that name? BLE does has 37 data channels. This name was pretty cool, huh.
So, just to remember, BLE have 3 advertising channels and 37 data channels, and the packets transmitted between that channels are positioned in two kinds of events: Advertising and Connection events.
3. Bluetooth LE Link Layer states
The Link Layer of BLE is a state machine, which has five states: Standby, Advertising, Scanning(Active, Passive), Initiating, Connection(Master, Slave). While the scanning states include two sub-states: active and passive, and the connection state also includes two sub-states: Central & Peripheral.
Here is some terminology explanation, A Bluetooth devices can be considered in one of the following roles according to the states of its link layer:
- Advertisers: Devices that transmit the advertising packets on the advertising channels are referred to as advertisers.
- Scanners: Devices that receive advertising on the advertising channels without intention to connect to that are referred to as scanners.
- Initiators: Devices that need to form a connection to another device listens for connectable advertising packets.
- Central/Peripheral: Once a connection is established, the initiator become the Central device, the advertising device becomes the Peripheral device.
4. Bluetooth LE Link Layer packets
There are only two kinds of packets in Link Layer: Advertising packet and data packet, advertising packet was transmitted in the 3 advertising channels and data packet was transmitted in the 37 data channels.
The Link Layer’s packet structure is much annoying, so I didn’t decide to involve in this mess issues so mush. Maybe the upcoming articles should be focused on host protocol stacks and application levels.
Полное руководство по Bluetooth с низким энергопотреблением
Вы когда-нибудь задумывались, как умные устройства могут обнаруживать друг друга?, запрос на услуги, и делитесь информацией? С взрывным ростом технологии IoT, это явление можно увидеть повсюду, а еще куча умных персональных устройств появилась. Было бы интересно узнать, как ваш фитнес-трекер может передавать информацию о вашей утренней пробежке вашему смартфону.. Какая скрытая технология стоит за этими соединениями? Очень смущенный? Верно? В этом руководстве, мы отдернем шторы и углубимся в беспроводный протокол ближнего действия – Bluetooth с низким энергопотреблением.
Bluetooth с низким энергопотреблением: Определения и не только
Перед изучением того, как работает Bluetooth с низким энергопотреблением, мы рассмотрим определения и эволюция Bluetooth с низким энергопотреблением.
Что такое Bluetooth с низким энергопотреблением
Bluetooth с низким энергопотреблением – также известный как Bluetooth Smart, Bluetooth ЛЕ, или BLE – технология беспроводной персональной сети, нацелены на новые приложения в здравоохранении, фитнес, маяки, и индустрия домашних развлечений. BLE работает в 2.4 Спектр ISM в ГГц и предназначен для обеспечения связи между устройствами на относительно небольшом расстоянии.. По сравнению с другими маломощными сетями, Основная сила BLE заключается в его многоплатформенной совместимости..
Сегодня, BLE широко используется в различных приложениях, но лучше всего подходит для устройств, которым требуются сетевые возможности и которые очень ограничены в энергопотреблении.. Благодаря своей низкой стоимости, длительное время автономной работы, и простота развертывания, BLE привлекла внимание производителей электроники и машин, подключенных к Интернету.. В настоящее время, BLE управляется сегодняшним быстрорастущим Интернетом вещей. Он все чаще применим ко всему, что связано с Интернетом вещей., который сегодня переживает сильный взрыв роста.
Эволюция технологии BLE
Когда дело доходит до эволюции технологии BLE, мы могли бы уделить немного времени, чтобы вернуться к разработке Bluetooth. В 1999, родилась стандартная технология ближнего действия для беспроводной связи между стационарными и мобильными устройствами с помощью радиоволн.: блютуз. Постоянно прогрессирует с течением времени, он распространяется очень быстро и был интегрирован во многие повседневные устройства. Только через десять лет, BLE был представлен с выпуском версии 4.0 Основной спецификации. Он имеет те же характеристики, что и его старший брат, но отличается очень низким энергопотреблением..
По факту, BLE, который мы знаем сегодня, изначально был проектом под названием Wibree, разработанным Nokia до того, как он был принят SIG (Специальная интернет-группа Bluetooth). Хотя между BLE и Bluetooth Classic много общего., стоит отметить, что BLE не является усовершенствованной версией оригинального Bluetooth. – Классический Bluetooth, а скорее новая технология, которая использует бренд Bluetooth, чтобы сосредоточиться на приложениях IoT, где передача данных на короткие расстояния может потреблять наименьшее количество энергии..
Преимущества и недостатки Bluetooth с низким энергопотреблением
У каждой медали есть две стороны, и так же БЛЭ. Обращая внимание на преимущества Bluetooth LE, ограничения также нельзя игнорировать. Дело в том, что может быть важно знать плюсы и минусы, чтобы определить, подходит ли BLE для конкретного приложения и варианта использования..
Преимущества BLE
- Низкое энергопотребление: Выдающееся преимущество BLE заключается в низком энергопотреблении.. За счет минимизации ненужного времени работы на радиостанции и обеспечения передачи небольшого объема данных на маленьком расстоянии, BLE обеспечивает сверхнизкое энергопотребление.
- Сильный кредит экономической стабильности: BLE исходит от консорциума отраслевых гигантов (IBM, Майкрософт, Интел…), что дает ему лучшее принятие и сильную экономическую поддержку и стабильность.
- Более низкая стоимость модулей и чипсетов: По сравнению с другими аналогичными беспроводными протоколами и технологиями, BLE применяет менее дорогие модули и чипсеты.
Совместимость с несколькими телефонами: BLE уже интегрирован во все смартфоны, сделать его проще и удобнее в использовании.
Ограничения BLE
- Низкая пропускная способность данных: Пропускная способность устройств BLE составляет 100-250 Кбит / с, ограничено PHY (физический радиоуровень) скорость передачи данных.
- Узкий диапазон: Первоначально предназначен для периодической передачи небольших объемов данных на короткие расстояния., BLE, без сомнения, имеет ограниченный рабочий диапазон.
- Требования к шлюзу для подключения к Интернету: Чтобы включить подключение к Интернету только между устройствами BLE, когда устройство BLE отправляет данные, для получения данных требуется другое устройство с IP-соединением, который, в свою очередь, ретранслируется на другое IP-устройство (или Интернет).
Что такое Bluetooth-маяки
Маяки BLE, как подсказывает название, являются маяками устройств BLE, которые обеспечивают передачу широковещательных сигналов.. Устройства BLE действуют как небольшие радиопередатчики., стратегически расположен в разных локациях, трансляция сигналов Bluetooth Low Energy в заданном диапазоне. Обычно, этот диапазон зависит от аппаратных возможностей. В среднем, устройства-маяки могут передавать сигналы BLE до 80 метры, и передаваемые сигналы способны инициировать определенные действия, связанные с этим местоположением..
Маяки BLE позволяют отслеживать местоположение и перемещение устройств BLE.. Когда устройство BLE входит в определенную область и взаимодействует с другими совместимыми приложениями BLE или операционными системами в пределах досягаемости, действия на основе местоположения также могут быть вызваны. Кроме того, Маяки BLE отправляют информацию на принимающее устройство как широковещательное устройство в режиме успешной передачи., часто требуется установка специального программного обеспечения на устройство для взаимодействия с маяком BLE..
Как работает технология Bluetooth с низким энергопотреблением
BLE использует тот же 2.4 ГГц ISM спектр как Bluetooth для работы, который колеблется от 2402 МГц в 2480 МГц. более того, BLE делит его на 40 1 МГц каналы, а также 3 из них используются исключительно для отправки рекламных пакетов, а остальные каналы используются для передачи данных. В целом, связь BLE начинается с 3 важные рекламные каналы, а затем разгружаются на оставшиеся второстепенные каналы данных.
Существует два разных типа подключения BLE.: ориентированная на соединение связь и вещание. Для первого типа подключения, устройство BLE может действовать как центральное устройство или периферийное устройство. Центральное устройство играет роль в сканировании подключаемых устройств и инициировании запросов на подключение и обмен данными.. Периферийный, с другой стороны, может получать команды и запросы от центрального устройства. Связь между ними осуществляется в 4 шаги: рекламное объявление, посвящение, связь, и обмен.
Второй тип связи BLE называется Broadcasting или Bluecasting.. Что отличает его от первого подключения, так это то, что оно не требует установления соединения и является однонаправленным.. Здесь, устройство с поддержкой BLE отправляет данные в одностороннем порядке на любое устройство, которое наблюдает и способно получать широковещательные данные. Следует отметить, что этот метод не обеспечивает безопасность передаваемых данных и, следовательно, не подходит для обмена конфиденциальной информацией.. Это больше подходит для таких приложений, как обмен файлами общедоступных данных в офисе..
Все ли смартфоны поддерживают Bluetooth с низким энергопотреблением
Сегодня, поскольку BLE применяется к множеству различных устройств и интерфейсов., можно с уверенностью сказать, что почти все смартфоны BLE-совместимы. В главе истории рассказывается о первом смартфоне с поддержкой BLE., iPhone 4S от Apple. Сразу после того, как BLE получил штамп Apple, начали появляться другие производители смартфонов.. Это предоставило производителям периферийных устройств уникальную возможность создавать инновационные устройства, которые могут взаимодействовать с мобильными телефонами через BLE.. Сегодня у нас беспроводные наушники, цифровые вывески, умные часы, фитнес-трекеры, и аппаратные устройства, такие как маяки, которые могут беспрепятственно взаимодействовать со смартфонами..
Устройство Модели с поддержкой BLE Телефоны и планшеты Android Все телефоны Android с Android 4.3 и выше iPhone iPhone 4 и выше айпад iPad 3-го поколения и выше iPad mini и выше Ipod Touch iPod touch 5-го поколения и выше Есть ли разница между Bluetooth Low Energy и Bluetooth
Есть две основные технологии с базовой спецификацией Bluetooth.: Bluetooth и Bluetooth с низким энергопотреблением. Оба они предназначены для того, чтобы помочь пользователям установить беспроводную связь между смарт-устройствами., будь то для личного или коммерческого использования. тем не мение, Важно отметить, что два решения сильно различаются по техническим характеристикам., заявление, и дополнительные возможности.
Классический Bluetooth Bluetooth с низким энергопотреблением Потребление энергии 1 Вт 0.01 — 0.50 Вт Диапазон до 100 м Менее 100 м Скорость передачи данных 1-3 Мбит/с 125 кбит/с – 2 Мбит/с Голосовой способный да нет Сценарии использования Потоковая передача данных, беспроводная потоковая передача звука для динамиков, наушники, автомобильная аудиосистема, и больше. Новые приложения в здравоохранении, строительство, образование, индустрия домашних развлечений, так далее. Особенности позиционирования Никто Присутствие: Рекламное направление: RSSI, ХАДМ(Приходящий) Расстояние: Поиск направления (AoA / AoD) Как BLE изменил Интернет вещей
С присущей ему энергоэффективностью и доступностью смартфона, Технология Bluetooth с низким энергопотреблением является ведущим беспроводным протоколом малого радиуса действия для Интернета вещей.. За счет снижения энергопотребления, BLE позволяет устройствам IoT значительно уменьшаться и увеличивать срок их службы.. Кроме того, обмен данными между устройствами IoT может быть доступным из-за меньшей нагрузки на энергоаккумуляторы. Благодаря БЛЕ, Устройства IoT, работающие от батареек типа «таблетка», могут работать неделями, месяцы, или даже годы, не разряжая свои батареи.
Более чем очевидно, что многие из самых популярных приложений IoT были бы невозможны без технологии BLE.. В то же время, быстрый рост Интернета вещей заставил многие отрасли изменить себя, чтобы приспособиться к нему.. Bluetooth SIG также применила технологию BLE в своей версии Bluetooth. 4.0 чтобы это могло быть актуально для IoT. В целом, BLE было легче завоевать доверие среди разработчиков и инженеров IoT, и реализации доказывают, что BLE кардинально меняет IoT невообразимым образом..
Сочетание всех этих факторов делает BLE лучшим выбором для многих потребителей в приложениях IoT., и его положение еще больше укрепляется на рынке. Стоит отметить, что Bluetooth SIG еще не прекратил майнинг для BLE., другими словами, Bluetooth Low Energy по-прежнему постоянно развивается и совершенствуется, чтобы соответствовать самым актуальным требованиям рынка., так что это определенно должно остаться на вашем радаре.
Аппаратное обеспечение MOKOBlue с поддержкой BLE
BLE идеально подходит для приложений, которые требуют длительной или постоянной работы, но имеют короткие всплески беспроводной передачи.. MOKOBlue, компания, специализирующаяся на приложениях IoT, принесет вам самое энергодостаточное и доступное Bluetooth-решения передовой технологии BLE. Поддержка широкого спектра маяков и оборудования BLE., MOKOBlue удовлетворяет все ваши разнообразные потребности.
Если вы все еще сравниваете различные технологии отслеживания активов, умное освещение, обнаружение занятости, и т.п., пожалуйста, свяжитесь с MOKOBlue для получения дополнительной информации. Мы откроем для вас двери возможностей для достижения низкого бюджета, но ограниченного энергетического бюджета..