Bluetooth peripheral mode что это

Обновлено: 09.01.2025

В предыдущей статье мы подробно поговорили о подключении/отключении BLE устройств. Эта статья о чтении и записи характеристик, а также включении-выключении уведомлений.

Чтение и запись характеристик

Многие разработчики, которые начинают работать с BLE на Android, сталкиваются с проблемами чтения/записи BLE характеристик. На Stackoverflow полно людей, предлагающих просто использовать задержки… Большинство таких советов неверные.

Есть две основные причины проблем:

Операции чтения/записи асинхронные. Это значит, что вызов метода вернется немедленно, но результат вызова вы получите немного позже – в соответствующих колбеках. Например onCharacteristicRead() или onCharacteristicWrite() .

Одновременно может быть запущена только одна операция. Нужно дождаться выполнения текущей операции, и затем, запускать следующую. В исходном коде BluetoothGatt есть блокирующая переменная, которая при запуске операции устанавливается и при вызове колбека сбрасывается. Google забыла про это упомянуть в документации… (Прим. переводчика: речь идет о mDeviceBusy и mDeviceBusyLock здесь).

Первая причина, на самом деле, не является проблемой, такова природа BLE. Асинхронное программирование это распространенная штука, используется, например, при сетевых вызовах. Однако вторая причина раздражает и требует специального подхода.

Ниже кусок кода BluetoothGatt.java с блокировкой переменной mDeviceBusy , перед чтением характеристики:

Когда приходит результат чтения/записи, переменная mDeviceBusy сбрасывается в false снова:

Мы добавляем новый экземпляр Runnable в очередь при выполнении команды. Ниже пример чтения характеристики (readCharacteristic):

В этом методе, сначала проверяем все ли готово для выполнения (наличие и тип характеристики) и логгируем ошибки, если они есть. Внутри Runnable , фактически вызывается метод readCharacteristic() , который выдает команду на устройство. Мы также отслеживаем сколько было попыток, чтобы сделать повтор в случае ошибки (Прим. переводчика: это лучшая тактика, чтобы добиться стабильной работы с устройством). Если чтение характеристики возвращает false , мы логгируем ошибку, «завершаем» команду, чтобы можно было запустить следующую. Наконец вызывается nextCommand() , чтобы запустить следующую команду из очереди:

Обратите внимание, мы используем метод peek() для получения объекта Runnable из очереди, чтобы можно было повторить запуск позже. Этот метод не удаляет объект из очереди.

Результат чтения будет отправлен в ваш колбек:

Мы завершаем команду completedCommand() после обработки нового значения. Это помогает избежать одновременный вызов другой команды и состояния гонки.

Теперь мы готовы завершить команду, убираем Runnable из очереди через вызов poll() и запускаем следующую из очереди:

В некоторых случаях (ошибка, неожиданное значение), вам нужно будет повторить команду. Сделать это просто, так как объект Runnable остается в очереди до вызова completedCommand() . Чтобы не уйти в бесконечное повторение – проверяем лимит на повторы:

Запись характеристик

Чтение характеристики достаточно простая операция, а запись требует дополнительных пояснений. Для выполнения записи нужно предоставить характеристику, массив байтов и тип записи. Существует несколько типов записи, важные для нас это:

WRITE_TYPE_DEFAULT (вы получите ответ от устройства, например, код завершения);

WRITE_TYPE_NO_RESPONSE (никакого ответа от устройства не будет).

Использовать тот или иной тип зависит от вашего устройства и характеристики (иногда она поддерживает оба типа записи, иногда только один конкретный тип).

В Android каждая характеристика имеет дефолтный тип записи, который определяется при ее создании. Ниже фрагмент кода из исходников Android, где определяется тип:

Как вы видите, это работает нормально, если характеристика поддерживает только один их двух типов записи. Если характеристика поддерживает оба типа, то значение по умолчанию будет WRITE_TYPE_NO_RESPONSE . Имейте это ввиду!

Перед записью можно проверить характеристику, поддерживает ли она нужный тип записи:

Я рекомендую всегда явно указывать тип записи и не полагаться на дефолтные настройки выбранные Android!

Итак, запись массива байтов bytesToWrite в характеристику выглядит так:

Включение/выключение уведомлений

Кроме самостоятельного чтения и записи характеристик, вы можете включить или отключить уведомления от устройств. При включении уведомления, устройство сообщит вам о появлении новых данных и отправит их автоматически.

Для включения уведомлений нужно сделать две вещи в Android:

вызвать setCharacteristicNotification . Bluetooth стек будет ожидать уведомления для этой характеристики.

записать 1 или 2 как unsigned int16 в дескриптор конфигурации характеристик (Client Characteristic Configuration, сокращенно - ССС). Дескриптор CCC имеет короткий UUID 2902.

Почему 1 или 2? Потому что «под капотом» Bluetooth стека есть Уведомление и Индикация. Полученное Уведомление не подтверждаются стеком Bluetooth, а Индикация наоборот – подтверждается стеком. При использовании Индикации, устройство будет точно знать, что данные получены и может их, например, удалить из локального хранилища. С точки зрения Android приложения нет разницы: в обоих случаях вы просто получите массив байтов и Bluetooth стек уведомит устройство об этом, если вы используете Индикацию. Итак, 1 включает уведомления, 2 – индикацию. Чтобы выключить их, записываем 0. Вы должны самостоятельно определить, что записать в дескриптор CCC.

В iOS метод setNotify() делает всю работу за вас. Ниже пример, как сделать тоже самое на Android, там сначала идут проверки входных параметров, определяется что записать в дескриптор и, наконец команда отправляется в очередь:

Результат записи в CCC дескриптор обрабатывается в колбеке onDescriptorWrite . Здесь вы должны отличить запись в CCC от записей в другие дескрипторы. Во время обработки колбека, мы также должны хранить, какие в данный момент характеристики уведомляются.

Чтобы узнать из какой характеристики пришло уведомление – используйте метод isNotifying() :

Лимиты на установку уведомлений

К сожалению, нельзя включить столько уведомлений, сколько хочешь. Начиная с Android-5 лимит равен 15. В более старых версиях он был равен 7 или даже 4. Большинство смартфонов поддерживают 15 уведомлений. Не забывайте отключать их, если они вам больше не нужны, чтобы не исчерпать лимит.

Проблемы с потоками

Итак, мы научились читать/писать характеристики, включать/выключать уведомления, а значит готовы использовать это в реальном проекте. Я думаю, что устройства BLE можно разделить на две категории:

Простые устройства. Например, термометр, который использует официальный Bluetooth Health Thermometer сервис. Такие устройства легко использовать, вы просто включаете уведомления и данные начинают поступать. Здесь мы используем только операции чтения характеристики, запись не нужна;

Сложные устройства. Это может быть любое устройство, но обычно все они используют свой внутренний протокол обмена данными. Часто эти протоколы не спроектированы под BLE, а просто транслируют внутренний последовательный протокол в BLE, где одна характеристика используется для отправки данных, а другая для приема. Сложность в том, что вам требуется знать большое количество команд для работы с устройством: авторизация, обновление пользовательских параметров, параметров самого устройства, получение сохраненных данных и т.д.

Простые устройства обычно не создают проблем с потоками, для сложных – следует работать внимательно. Чтение, запись и уведомления в этом случае будут чередоваться и могут мешать друг другу, особенно если у вас устройство с высокой частотой передачи данных (30Hz или около).

Типичная проблема с потоками выглядит так:

вы отправляете событие в свою собственную очередь для обработки

запускается обработку полученных данных

в это время приходит новое уведомление и перезаписывает предыдущее значение в BluetoothGattCharacteristic

если ваша обработка данных медленная, вы потенциально теряете значение из первого уведомления.

Причины такого поведения:

Android переиспользует BluetoothGattCharacteristic объекты внутри. Они создаются в время обнаружения сервисов (services discovering) и после этого переспользуютсямногократно. Таким образом, когда приходит уведомления Android сохраняет значение в объект BluetoothGattCharacteristic . Если характеристика в этот момент обрабатывается в другом потоке мы получим гонку состояний (race condition) и результат будет непредсказуемым.

Очевидно, что нужно всегда работать с копией массива байтов. Получили данные, сразу же делаем копию и работаем с ней.

Ниже пример, который использует такую тактику:

Другие рекомендации по работе с потоками

Есть несколько дополнительных рекомендаций по работе с BLE на Android. Поскольку стек BLE в основном асинхронный, у нас есть мульти-поточная обработка задач.

Android использует потоки:

При сканировании (результаты приходят в main поток);

Вызове колбеков BluetoothGattCallback (выполняются в потоках Binder );

Обработка результатов сканирования на main потоке не будет проблемой. Но с потоками Binder все немного сложнее. При вызове колбека на потоке Binder, Android не будет отправлять новые данные пока не закончится обработка текущих, то есть поток Binder блокируется пока ваш код не завершится. Следует избегать тяжелых операций в колбеках, никаких sleep() или что-то подобное. Кроме того, никаких новых вызовов в объекте BluetoothGatt , пока вы находитесь в потоке Binder, хотя большинство методов асинхронные.

Я рекомендую следующее:

Всегда выполняйте вызовы BluetoothGattCallback в отдельном потоке, возможно даже из потока пользовательского интерфейса (Прим. переводчика: работать на main потоке - плохая идея, если у вас есть активный обмен с устройством, обязательно будут залипания UI, не делайте так);

Освобождайте потоки Binder как можно быстрее и никогда не блокируйте их;

Самый простой способ выполнить рекомендации выше – создать выделенный Handler и использовать его для обработки данных и выдачи новых команд. Обратите внимание, я уже использовал Handler на примере кода для колбека onCharacteristicUpdate .

Если хотите запустить Handler на main потоке:

Прокрутите назад и взгляните на наш метод nextCommand() , каждый Runnable выполняется в нашем собственном Handler , следовательно, мы гарантируем, что все команды выполняются вне потока Binder .

Следующая статья: сопряжение (bonding)

В этой статье мы разобрались с чтением и записью характеристик, включением и выключением уведомлений/нотификаций. В следующей статье, мы детально изучим процесс спряжения с устройством (bonding).

Не терпится поработать с BLE? Попробуйте мою библиотеку Blessed for Android. Она использует все подходы из этой серии статей и упрощает работу с BLE в вашем приложении.

Этичный хакинг и тестирование на проникновение, информационная безопасность

Bluetooth, как мы знаем, является одной из самых популярных и широко используемых беспроводных технологий в современном мире. В связи с быстрым ростом IoT, ускоряющим развитие технологии Bluetooth, Специальная группа по интересам Bluetooth (Bluetooth Special Interest Group (SIG)) предпринимает постоянные усилия по увеличению скорости передачи с максимальным акцентом на маяки, развлечения, сферу здравоохранения и фитнес.

Примечание: IoT - «Интернет вещей», термин относится к совокупности разнообразных устройств, обычно более простых, чем персональный компьютер, которые подключены к Интернету.

Bluetooth Low Energy (BLE) является частью спецификации Bluetooth 4.0, которая также включает протоколы классического Bluetooth и протокол высокоскоростного Bluetooth (Classic Bluetooth and Bluetooth High Speed Protocols). По сравнению с классическим Bluetooth, BLE предназначен для использования меньшей мощности при сохранении аналогичного диапазона связи. BLE — это технология, которая всегда отключена и передаёт только короткие объёмы данных, когда это необходимо. Это значительно снижает энергопотребление, что делает его идеальным для использования в случаях, когда требуется постоянное долговременное соединение с низкой скоростью передачи данных. BLE идеально подходит для пульта дистанционного управления телевизором, но не для беспроводного устройства потоковой передачи мультимедиа, которому для передачи требуется большой объем данных.

Bluetooth Low Energy встроен во многие гаджеты, которые мы используем сегодня. От смартфонов, умных телевизоров, передовых технологий, таких как медицинское оборудование, до базовых устройств, таких как наши кофемашины, - все используют BLE.

Изначально Nokia разработала BLE для собственного проекта под названием «WIBREE», который впоследствии был передан Bluetooth SIG. BLE был задуман с акцентом на лучшую скорость сопряжения и энергоэффективность.

Что выделяет BLE?

Обеспечивает многоплатформенную связь: может легко общаться через большое количество устройств, работающих на Android, iOS, Linux, Windows Phone, Windows 8 и OS X
Лучшая скорость сопряжения
Помогает поддерживать связь в течение более длительных периодов времени
Значительно ниже затраты на внедрение
Энергоэффективный

На бумаге BLE выглядит хорошо, а как на практике?

Это хороший вопрос с точки зрения безопасности. Дело в том, что BLE — это просто протокол. Изготовители должны безопасно внедрить BLE в своё устройство. Известно, что даже самый сильный криптографический протокол не будет работать, если генератор случайных чисел не является «достаточно случайным». То же самое относится и к BLE. Таким образом, можно сказать, что безопасность BLE лежит в руках его исполнителей.

В то время как все устройства Bluetooth с низким энергопотреблением были разработаны с основной целью улучшения взаимодействия с пользователем, безопасность заняла последнее место во время процесса?

Давайте посмотрим на три основные уязвимости, которым BLE могут подвергать своих пользователей:

Подслушивание: как следует из названия, подслушивание относится к стороннему устройству, прослушивающему данные, которыми обмениваются два сопряжённых устройства. Соединение между двумя сопряжёнными устройствами означает цепочку доверия. Цепь разрывается при удалении одного из устройств. Злоумышленник может использовать номер устройства для доступа к другим Bluetooth-устройствам. Даже если ключи шифрования/расшифровки должны были быть удалены, атакующий может офлайн брутфорсить ПИН, используя Bluetooth Sniffer (на основе идентификатора устройства). Как только PIN-код будет получен, устройство может быть легко взломано.
Атаки «человек посередине» (MITM). Атаки «человек посередине» включают стороннее устройство, имитирующее законное устройство, обманывая два легитимных устройства, заставляя их поверить в то, что они связаны друг с другом, когда на самом деле законные устройства подключены к имитатору (посреднику). Этот тип атаки позволяет злоумышленнику/имитатору получить доступ ко всем данным, которыми обмениваются устройства, а также манипулировать данными, удаляя или изменяя их, прежде чем они достигнут соответствующего устройства.
Отказ в обслуживании и Fuzzing атака. Поскольку большинство беспроводных устройств в наши дни работают на встроенных аккумуляторных батареях, эти устройства подвержены риску атак типа «отказ в обслуживании» (DoS). DoS-атаки подвергают систему частым сбоям, приводящим к полному истощению её батареи. Fuzzing атаки также приводят к сбою систем, поскольку злоумышленник может отправлять искажённые или нестандартные данные на радиомодуль устройства Bluetooth и проверять его реакцию, что в конечном итоге может сбить с толку устройство.

Итак, резюмируя, по своей задумке BLE это упрощённая версия Bluetooth, которая всегда не меняет каналы (частоты), что облегчает сниффинг и атаку человек-посередине. BLE не имеет встроенного протокола обеспечения безопасности. Реализация безопасности BLE возложена на производителей конечных устройств, которые не всегда подходят к этому добросовестно. По этой причине многие BLE устройства можно легко обнаружить практически в любое время их работы. При этом зачастую они не содержат каких-либо механизмов для ограничения чтения и даже записи на них, то есть открыты для подключения и модификации кому угодно.

Основные понятия в BLE

В BLE есть два основных понятия.

GAP - Generic Access Profile (общий профиль доступа)
GATT - Generic Attribute Protocol (протокол общих атрибутов)

Общий профиль доступа (GAP)

Он ответственен за подключение и распространения информации о наличии устройства BLE. GAP отвечает за видимость устройства во внешнем мире, а также играет важную роль в определении того, как устройство взаимодействует с другими устройствами.

Следующие две концепции являются неотъемлемой частью GAP:

Периферийные устройства. Это небольшие устройства с низким энергопотреблением, которые могут подключаться к сложным, более мощным центральным устройствам. Монитор сердечного ритма является примером периферийного устройства.

Центральные устройства: в основном это мобильные телефоны или гаджеты с увеличенной памятью и вычислительной мощностью.

Advertising process (обеспечение видимости устройства)

Процесс обнаружения устройств заключается в том, что Периферийное устройство в заданные интервалы отправляет в округу данные о своём существовании. Если эти данные получит Центральное устройство, то оно отправит запрос на сканирование. В ответ Периферийное устройство пришлёт данные результата сканирования.

Периферийное устройство будет отправлять «рекламные» данные каждые 2 секунды. Если центральное устройство готово прослушать рекламные пакеты, оно ответит запросом сканирования. В ответ на этот запрос периферийное устройство отправит данные ответа сканирования. Таким образом, центральное и периферийное устройства узнают друг о друге и связывается друг с другом.

Протокол общих атрибутов (GATT)

Используя общий протокол данных, известный как протокол атрибутов, GATT определяет, как два устройства BLE обмениваются данными друг с другом, используя понятия — сервис (service) и характеристика (characteristic). Этот протокол сохраняет все сервисы и характеристики в справочной таблице с использованием 16-битных идентификаторов, как указано в Bluetooth SIG. Важно отметить, что GATT инициируется только после того, как Advertising процесс, регулируемый GAP, завершён.

Две основные концепции, которые образуют GATT

Сервисы (service)
Характеристики (characteristic)

Сервисы

Сервисы можно представить просто как шкаф, в котором может быть много ящиков, которые в свою очередь называются характеристиками. Сервис может иметь много характеристик. Каждый сервис уникален сам по себе с универсально уникальным идентификатором (UUID), который может быть размером 16 бит для официальных адаптированных сервисов или 128 бит для пользовательских сервисов.

Характеристики

Характеристики являются наиболее фундаментальным понятием в рамках транзакции GATT. Характеристики содержат одну точку данных и схожи с сервисами, каждая характеристика имеет уникальный идентификатор или UUID, который отличается от другой характеристики.

Вот спецификации SIG для характеристик и сервисов для устройств BLE. Любое устройство BLE, которое официально приняло UUID от SIG, должно использовать идентификатор, указанный ими в своих приложениях.

Например, официальный UUID мощности передачи (TX power) в соответствии с мандатом SIG равен 0x1804.

Чтобы было наглядно, посмотрите на этот пример сервисов и характеристик конкретного устройства:

В нём «Generic Access (1800)» - это 16-битный сервис. Внутри этого сервиса, следующие 16-битные характеристики:

Ещё один 16-битный сервис это «Generic Attribute (1801)», он содержит только одну 16-битную характеристику: Service Changed (2a05).

анализ приложения для управления устройством (многие устройства имеют программы под Android)
фаззинг — ввод различных данных и наблюдение за устройством, что в нём поменялось

Как взломать Bluetooth Low Energy

Суть процесса взлома Bluetooth Low Energy можно описать следующими стадиями:

Обнаружение устройства
Считывание его сервисов и характеристик
Обнаружение среди характеристик те, которые можно перезаписать
Определение, за что отвечают характеристики
Изменить значения характеристик

Четвёртый этап является творческим и самым сложным. Иногда роль характеристик можно найти в документации разработчиков для данного устройства. Иногда приходится перебирать значения и смотреть, что поменялось в устройстве. Самый сложный вариант — это обратная инженерия перехваченного Bluetooth трафика или приложения для управление устройством.

Я покажу пример изменения BLE параметров на устройстве с помощью bettercap.

Вводим команду для включения модуля по обнаружению BLE устройств:

Чтобы вывести устройства, которые в данный момент в пределах досягаемости, выполните команду:

Для показа характеристик конкретного устройства, запустите команду следующего вида, где вместо MAC укажите MAC-адрес устройства:

К примеру, меня интересует устройство C8:DF:84:1A:9F:26:

В столбце Properties вы увидите свойства данной характеристики, они могут быть:

READ (чтение)
WRITE (запись) — то есть возможно изменение данной характеристики
NOTIFY (уведомление)
INDICATE (индикатор)

В колонке Data присутствует текущее значение характеристики, либо дополнительная информация, например:

Для записи данных HEX_DATA в BLE устройство с указанным MAC адресом, в характеристику с идентификатором UUID:

Чтобы знать, что именно записывать, нужно понимать, за что отвечают характеристики. Вот пример значений для моего устройства — это электрическая зубная щётка Oral-B Genius 9000 (кстати, рекомендую). Значение характеристик я нашёл в Интернете.

Исследование и взлом Bluetooth Low Energy (BLE) с телефона

Поскольку на всех современных телефонах имеется Bluetooth, то вы можете использовать приложения для работы с Bluetooth Low Energy (BLE) окружающих устройств на телефоне.

Пример такого приложения — nRF Connect — бесплатная программа программа для Android, которая умеет сканировать для поиска BLE устройств, подключаться к ним и менять значение характеристик. Программа поддерживает макросы и другие продвинутые функции.

Просмотр сервисов устройства:

Просмотр свойств характеристик:

Редактирование значений характеристик:

Работа с Bluetooth Low Energy (BLE) в Linux

Конечно, в Linux можно работать с устройствами, поддерживающими BLE, напрямую, без таких программ как Bettercap.

К сожалению, этот аспект довольно запутанный. В Debian и производных программы для работы с Bluetooth Low Energy собраны в пакете bluez. В Arch Linux и производных, пакет bluez также имеется, но утилиты, которые нас интересуют, помещены в пакет bluez-utils. Но не это самая большая проблема.

После очередного обновления утилит bluez, авторы вдруг признали многие важные программы «устаревшими», а именно устаревшими объявлены:

Поразительно, но для них не было представлено полноценных замен. Путаницу добавляет отсутствие нормальной документации и даже справки по программам.

Была составлена такая таблица замены:

Устаревший инструмент	Самая подходящая замена
gatttool	btgatt-client, D-Bus Gatt API
hciattach	btattach
hciconfig	btmgmt (и bluetoothctl?)
hcidump	btmon (и btsnoop)
hcitool	отсутствует, доступно в D-Bus Device API
rfcomm	отсутствует, реализовано в D-Bus Profile1 API?
ciptool	отсутствует, реализовано в D-Bus Profile1 API?
sdptool	отсутствует, кажется, что функциональность разбросана по разным объектам D-Bus: Profile, Advertising, и массивы UUIDs в device и adapter.

Слова «отсутствует» не вселяют уверенности. По этой причине для Debian и производных этот пакет компилируется с ключом --enable-deprecated, а на Arch Linux в дополнении к пакету bluez-utils, доступному в стандартных репозиториях, в AUR имеется пакет bluez-utils-compat, в котором тоже включены устаревшие инструменты.

В относительно свежих инструкциях, для взаимодействия с Bluetooth Low Energy используются утилиты:

Поскольку они устарели и однажды всё-таки будут удалены окончательно, рассмотрим несколько простых вариантов использования их замен для поиска BLE устройств и получения с них данных.

Если запустить программу btmgmt:

И в ней выполнить команду:

То она выведет список обнаруженных устройств:

Будут выведены как BLE, так и обычные Bluetooth устройства.

Также умеет искать BLE устройства, если ввести:

С помощью команды connect можно подключиться к устройству, для этого нужно указать его MAC-адрес:

Информация по устройству:

Если перейти в меню GATT:

То можно получить список характеристик:

А также перезаписать характеристики устройства.

Для получения информации по отдельным характеристикам:

Ещё одна программа, которая выведет сразу все характеристики устройства — btgatt-client. Например, выполним подключение и посмотрим характеристики устройства с MAC C8:DF:84:1A:9F:26:

В дополнении к рассмотренным программам, в отдельной консоли можно запустить Bluetooth monitor:

Как и полагается программе-монитору, она будет выводить множество информации о происходящем с Bluetooth и об обнаруженных устройствах.

Заключение

Системные утилиты Linux для работы с Bluetooth заслуживают более внимательного изучения — с их помощью можно узнать более подробную информацию о своей системе и сделать тонкую настройку Bluetooth адаптера.

Также с помощью них можно реализовать сканеры BLE и Bluetooth устройств и/или написать или приспособить фаззеры для исследования назначения характеристик BLE устройств. Поэтому вполне возможно, что в одной из следующих статей будут более подробно рассмотрены программы для работы с BLE.

В классической беспроводной технологии Bluetooth профиль последовательного порта (SPP) обеспечивает возможность замены проводного интерфейса RS-232 беспроводным соединением между двумя устройствами. В устройствах, работающих на новом Bluetooth-стандарте BLE, структура стека для соединения через последовательный порт – иная. Как же организовать на них замену проводного интерфейса беспроводным соединением?

Изначально созданная для высокоскоростной передачи данных в сетях малого радиуса действия беспроводная технология Bluetooth с течением времени развивалась и совершенствовалась. Последнее существенное изменение произошло с появлением версии 4.0, известной также как Bluetooth Low Energy (BLE). Новейшая принятая спецификация имеет версию 4.2. Для BLE используется также и другое название – Bluetooth Smart.

В Bluetooth при создании соединения между двумя устройствами одно из них, инициирующее соединение, выступает в роли ведущего (Master), а другое будет находиться в роли ведомого (Slave). При этом оба устройства могут действовать как индивидуально (топология Point to Point), так и находясь в составе сети со структурой типа «звезда» (топология Star) (рисунок 1). В этом случае один узел функционирует как центральный и действует в роли ведущего, в то время как все остальные узлы функционируют в роли ведомых.

Рис. 1. Две топологии соединений в Bluetooth

В классическом варианте Bluetooth соединение между двумя точками поддерживается, даже если нет подлежащих передаче данных, что приводит к повышенному расходу энергии от автономного источника питания. Лишь при переходе в спящий режим удается несколько сократить потребляемый от батареи ток. В результате на основе классического Bluetooth практически невозможно реализовать компактные устройства длительного пользования с батарейным питанием. Значительно более экономичный в отношении потребляемого тока стандарт Bluetooth Low Energy позволяет создавать конечные устройства с питанием от батареек пуговичного типа, которые способны работать в течение нескольких месяцев и даже лет.

BLE можно рассматривать как расширение базовой технологии Bluetooth Classic, ориентированное в основном на передачу небольших объемов данных, которое оптимально подходит для Интернета вещей. Сравнение основных характеристик BLE и обычного Bluetooth приведено в таблице 1.

Таблица 1. Сравнение Bluetooth с Bluetooth Low Energy

BLE, как и обычный Bluetooth, работает в нелицензируемом частотном диапазоне 2,4 ГГц, используя 40 каналов вместо 79 в классическом варианте и довольствуясь сокращенным по длительности до 3 мс сеансом связи. При этом максимальный размер передаваемого пакета составляет 27 байт.

BLE использует меньше каналов, но с расширенной полосой пропускания. Как показано на рисунке 2, ширина каждого из 40 каналов Bluetooth Smart составляет 2 МГц. Для передачи служебных сигналов (Advertising) выделены три канала, разнесенные в пределах частотного спектра, чтобы минимизировать влияние помех. В течение сеанса связи используется скачкообразный алгоритм выбора частоты канала.

Рис. 2. Частотные каналы Bluetooth Smart (BLE)

Стек ПО Bluetooth Smart (BLE) для последовательного порта

Спецификация Bluetooth определяет структурные элементы, на базе которых разработчик создает совместимые друг с другом устройства. Архитектура программного обеспечения для устройств BLE имеет послойно упорядоченную структуру, обычно называемую стеком. Наборы протоколов и профили позволяют отдельным устройствам соединяться друг с другом и обмениваться данными определенного типа.

В новых версиях Bluetooth, начиная с 4.0, вводятся два типа устройств: однорежимные и двурежимные. Однорежимные устройства работают лишь с поддержкой спецификации BLE, тогда как двурежимные способны также работать и в режиме классического Bluetooth BR/EDR (с базовой/повышенной скоростью).

На рисунке 3 изображены варианты реализации коммуникационного стека Bluetooth. Имеющийся в обычном Bluetooth профиль последовательного порта (SPP) обеспечивает возможность замены проводного интерфейса RS-232 беспроводным соединением между двумя устройствами.

Рис. 3. Структура коммуникационного стека Bluetooth

Профиль SPP включает протоколы RFCOMM, L2CAP, Link Manager и базовый протокол радиосвязи. RFCOMM (Radio Frequency Communications), создает виртуальный последовательный поток данных и эмулирует управляющие сигналы RS-232.

Далее в дело вступает пакетный протокол L2CAP (Logical Link Control and Adaptation Protocol). Он передает пакеты данных между хостом и подсистемой контроллера Bluetooth через интерфейс HCI (Host to Controller Interface) или напрямую в Link Layer, например, как в BlueNRG (рисунок 4).

Рис. 4. Структура стека BlueNRG

В устройствах BLE используется несколько измененная структура стека для соединения через последовательный порт. Вместо SPP имеется профиль атрибутов, а вместо протоколов RFCOMM – протокол атрибутов, оптимизированный для используемых в BLE пакетов данных небольшого размера. Протокол L2CAP остается неизмененным, Link Manager заменен на Link Layer, который определяет для пакетов структуру/каналы, процедуры подключения и отправляемые/получаемые данные.

Последовательный канал связи для устройств BLE

Надо сразу отметить, что отдельные операции в процессе соединения выполняются на уровне микропрограммного обеспечения и не требуют пристального внимания со стороны разработчика конечного устройства. Ему остается лишь выбрать заложенные производителем чипов микрокоманды на уровне конфигурации стека и профилей программного обеспечения.

В комплекте c оценочными платами производства компании STMicroelectronics имеется пакет ПО для разработки новых устройств, включающий в себя встроенное программное обеспечение, примеры реализации различных сценариев и документацию.

Рассмотрим пример создания канала связи между двумя компьютерами с использованием микросхем BlueNRG-MS или BlueNRG-1, которые являются однорежимными чипами с поддержкой требований BLE из спецификации Bluetooth v4.0. BlueNRG взаимодействуют с микроконтроллером внешнего хоста, используя линии SPI и набор API, состоящий из команд стандартного Application Command Interface (ACI) и определенных производителем команд Host Controller Interface (HCI) (рисунок 4).

Для решения поставленной задачи можно использовать, например, модуль SPBTLE-RF с сетевым процессором BlueNRG-MS (рисунок 5) или другие устройства на основе приемопередатчиков BlueNRG-1. В случае использования BlueNRG-1 расширенные возможности аппаратной платформы позволяют ему в отдельных случаях выполнять также функции приложения и полностью реализовать стек протоколов в одном чипе.

Рис. 5. Модуль ST SPBTLE-RF

Образец программной реализации, которая демонстрирует простое двухполосное соединение между двумя устройствами BlueNRG-MS, доступен в комплекте для разработки ПО (SDK) BlueNRG-MS. Проект называется “BLE Chat”, он размещен в папке “Projects\Projects_STD_Library\BLE_Chat\EWARM_BlueNRG-MS” внутри ПО для оценочного комплекта STEVAL- IDB005V1 или STEVAL-IDB006V1 (рисунок 6).

Рис. 6. Модуль STEVAL-IDB006V1

Те, кто работает с оценочными платами NucleoL152RE и X-NUCLEO-IDB05A1, могут найти этот проект в папке “Projects\Projects_Cube\BLE_Chat\EWARM_BlueNRG-MS”.

Примечание: если работать с BlueNRG-1 в составе оценочной платы STEVAL-IDB007V1, проект можно найти в SDK BlueNRG-1, в папке “\BLE_Examples\BLE_Chat”. Имеется поддержка IAR Embedded Workbench, Keil Microcontroller Development Kit и Atollic TrueSTUDIO.

При работе с этим проектом доступны четыре конфигурации:

“Client” – роль клиента;
“Server” – роль сервера;
“Client throughput” – тестирование пропускной способности для режима клиент;
“Server throughput” – тестирование пропускной способности для режима сервер.

В процессе реализации чата BLE выполняются следующие действия:

Сервис Chat содержит две определенные производителем характеристики:

Максимальная длина значения характеристики – 20 байт.

Чтобы установить соединение между двумя устройствами BlueNRG-MS (двумя оценочными платами BlueNRG), необходимо на одном из них реализовать режим «ведущий», а на втором должен быть установлен режим «ведомый». Как только соединение установлено – две точки могут начать передачу данных по каналу связи, используя эти две характеристики.

При использовании оценочных плат участвующие в обмене данные посылаются и принимаются с использованием подключенного к плате через эмулятор терминала на ПК, например, TeraTerm. Каждая оценочная плата будет отображаться на ПК как виртуальный порт COM. Эмулятор терминала конфигурируется следующим образом:

скорость передачи: 115200;
стоповые биты: 1;
проверка на четность: нет;
количество бит данных на символ: 8;
контроль потока: нет.

Проектные конфигурации “Client throughput” и “Server throughput” позволяют пользователю тестировать пропускную способность (определенный идентификатор препроцессора “THROUGHPUT_TEST” будет представлен в обеих проектных конфигурациях).

Тест на пропускную способность включает следующие этапы:

Задать режим Client на одной из платформ BlueNRG-MS и сбросить ее. Платформа появится как виртуальный COM-порт на ПК. Открыть порт COM в терминальном эмуляторе. Клиент запустится через 4 секунды после сброса.
Задать режим Server на второй платформе BlueNRG-MS и сбросить ее. После этого две платформы попытаются установить соединение. Как только им удастся это сделать, ведомый будет постоянно отправлять клиенту уведомления, состоящие из 20 байт.
После каждых 500 пакетов, полученных от клиента, текущая пропускная способность приложения будет отображаться на эмуляторе клиентского терминала.

Примечание: при работе с BlueNRG-1 в составе оценочной платы STEVAL-IDB007V1 контроллер STM32L1 выполняет роль моста между USB и последовательным портом BlueNRG-1, что позволяет непосредственно проверить пропускную способность от ПК к BlueNRG-1. Прошивка представлена в двоичной форме в SDK BlueNRG-1. Приложение BLE Chat запускается на устройстве BlueNRG-1 и сохраняется во Flash-памяти.

Заключение

Производимые STMicroelectronics приемопередатчики BlueNRG стандарта Bluetooth Low Energy подходят для использования в самом широком спектре устройств персонального назначения, в системах сбора и учета данных, находят широкое применение в промышленной и домашней автоматике.

Встроенное ПО BlueNRG обеспечивает эффективное решение стоящих перед разработчиком задач и не требует от него углубленных познаний в радиочастотной технике и спецификации Bluetooth. Имеющийся в комплекте с SDK набор демонстрационных приложений позволяет использовать некоторые типичные рабочие сценарии BLE.

Постоянно расширяемый набор библиотек ПО, предоставляемые производителем оценочные платы и SDK обеспечивают быстрое начало работ и позволяют в кратчайшие сроки создать законченное устройство с поддержкой Bluetooth Low Energy.

Ну так вам сюда:

качайте драйвер для Vista, распаковывайте и ставьте. Или у вас возможно есть диск с драйверами для ноутбука - ставьте с него.

Щелкните значок Bluetooth в System tray (справа внизу) правой клавишей мыши, выберите Открыть параметры устройства Bluetooth, затем в поле Телефоны и модемы выделите свой телефон и нажмите Свойства. Перейдите на вкладку Службы и снимите галочку в поле OBEX SyncML Client. Теперь откройте Диспетчер задач. Ну, что? Неизвестное устройство Bluetooth Peripheral Device исчезло из списка? Для Nokia сработало убирание двух галочек:

- "Nokia OBEX PC Suite Services"
- "Nokia SyncML Server"

Остальные галочки (включая "Sync MLClient", "Передача объектов (Obex)", "Передача файлов (Obex)") убирать не обязательно.

Если необходимо соединяться с интернетом через телефон, наличие галочки "Удаленный доступ к сети" обязательно. В этом случае в системе появляется Standart Bluetooth Modem

Скачала, распаковала, НЕ СТАВИТСЯ (((((( Говорит, не может найти чип Bluetooth.

Щелкните значок Bluetooth в System tray (справа внизу) правой клавишей мыши, выберите Открыть параметры устройства Bluetooth, затем в поле Телефоны и модемы выделите свой телефон и нажмите Свойства. Перейдите на вкладку Службы и снимите галочку в поле OBEX SyncML Client. Теперь откройте Диспетчер задач. Ну, что? Неизвестное устройство Bluetooth Peripheral Device исчезло из списка? Для Nokia сработало убирание двух галочек:

- "Nokia OBEX PC Suite Services"
- "Nokia SyncML Server"

Остальные галочки (включая "Sync MLClient", "Передача объектов (Obex)", "Передача файлов (Obex)") убирать не обязательно.

Читайте также: