Uuid bluetooth как узнать

Русские Блоги

Ямы и хитрости в Android ble (Bluetooth Low Energy)

1. Как определить uuid службы в ble?

В стандартной спецификации Bluetooth определено множество служебных uuid. Если они конфликтуют, это вызовет множество неожиданных проблем.

2. Устройство в центре экрана начинает сканирование и устанавливает соответствующий сервисный идентификатор.

new ScanFilter.Builder().setServiceUuid(ParcelUuid.fromString(«00007777-0000-1000-8000-00805f9b34fb»);

3. Периферийное устройство может установить магическое число AdvertiseData [ManufacturerId и ManufacturerSpecificData] во время трансляции. Таким образом, даже если определенный uuid сервиса конфликтует с другими, вы можете отфильтровать магическое число в центре, чтобы найти периферийное оборудование, которое соответствует вашим потребностям.

Периферийное построение AdvertiseData

Центральная обработка AdvertiseData

В настоящее время вы можете сопоставить периферийные устройства, которые вы установили, в соответствии с данными производителя.

4. Когда центр и периферия мира действительно соединятся? (Вы можете начать передачу данных)

В BluetoothGattCallback есть трехэтапные обратные вызовы по этой проблеме. 1、 public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState)

Это первый обратный вызов, запускаемый после соединения центра и периферии. newstate совпадает с BluetoothProfile. STATE_CONNECTED только означает, что центральное устройство подключено, на этот раз вам нужно вызвать BluetoothGatt, чтобы обнаружить службу.

Обратите внимание на case1, когда новое состояние — BluetoothProfile.STATE_DISCONNECTED, вы должны отключить BluetoothGatt, потому что каждый раз, когда вы звоните mBluetoothGatt = device.connectGatt(SpeakerApp.appContext, false, mGattCallBack); Будет генерировать новые объекты вместо активного закрытия старых

Обратите внимание на проблему case2, 133, iPhone и некоторых телефонов Android в качестве боковых ответвлений, начальное соединение Bluetooth — 133, в этом случае вам следует немедленно повторно просканировать соединение.133 Вопрос Ссылка

2、 public void onServicesDiscovered(BluetoothGatt gatt, int status) Обратный вызов, полученный после выполнения mBluetoothGatt.discoverServices (), если статус GATT_SUCCESS, вы можете получить службу и дескриптор ветви ble, которая инициирует широковещательную рассылку, и установить широковещательную рассылку, чтобы включить

3、 public void onDescriptorWrite(BluetoothGatt gatt, BluetoothGattDescriptor descriptor, int status) Только на этом шаге status == BluetoothGatt.GATT_SUCCESS данные могут быть действительно переданы. Если данные передаются на первом или втором шаге, это вызовет неизвестные ошибки или ошибки нулевого указателя в некоторых конкретных случаях.

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

Пять, проблема mtu-20 байт

Источник mtu20: GATT основан на протоколе ATT, и его основная спецификация определяет MTU по умолчанию для ATT как 23 байта. После удаления одного байта кода операции ATT и 2 байтов дескриптора ATT оставшиеся 20 слов Фестиваль для ГАТТ

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

Как понять что аккумулятор зарядился

Что делать, если вы хотите передать данные размером более 20 байт?

1. Системный MTU может поддерживать модификацию до 512 байт для завершения передачи больших объемов данных. Однако из-за необходимости изменить центральную и боковые ветви это вызовет большие ограничения и низкоуровневые модификации, а также вызовет ошибки, такие как некоторые устройства, которые не вступают в силу при первой модификации, и что другое устройство может быть изменено только один раз в соединении. Очень нежелательно и настоятельно не рекомендуется.

2. Передача субподряда. Наиболее предпочтительная схема разработки протокола передачи субподряда самостоятельно. Следует отметить, что после субподряда требуется интервал для записи данных между каждым пакетом, например 100 мс.

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

Семь, проблема потери пакетов

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

8. Проанализируйте данные.

После того, как периферийный конец mtu передан на субподряд и отправлен на центральный конец, центральный конец может быть public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic) Получать данные и восстанавливать исходные данные

Обратите внимание, что для некоторых устройств Bluetooth всегда есть какие-то особые состояния, и правильность полученных данных необходимо проверять.

Девять, другая яма

PROPERTY_WRITE_NO_RESPONSE в ble нельзя доверять. Некоторые версии Google не считывали значение этого атрибута, а устанавливали его напрямую так, чтобы он требовал ответа. В безопасном случае лучше всего настроить его на обязательный ответ

Если в проекте есть несколько соединений blu или ble + classic Bluetooth, в некоторых критических ситуациях (например, перезапуск устройства, сбой и перезапуск) может потребоваться подключение bluetooth для удаления устройства, созданного b ble (или b classic Bluetooth). В противном случае это приведет к сбою подключения.

BLE под микроскопом (ATTы GATTы. )

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

Solidworks легковесные детали что это

Уже прошло довольно большое время, с тех пор, когда вышла первая спецификация на Bluetooth 4.0. И, хотя тема BLE очень интересна, она до сих пор отталкивает многих разработчиков, из-за своей сложности. В своих предыдущих статьях я рассматривал в основном самый нижний уровень Link Layer и Physical Layer. Это позволяло не обращаться к таким сложным и запутанным понятиям как протокол атрибутов(ATT) и общий профиль атрибутов (GATT). Однако деваться некуда, не понимая их, невозможно разрабатывать совместимые устройства. Сегодня я хотел бы поделиться с вами этими знаниями. В своей статье я буду опираться на учебник для начинающих с сайта Nordic-а. Итак, давайте приступим.

Почему всё так сложно?

На мой взгляд, сразу было понятно, что управление устройствами через смартфоны — тема очень перспективная и долгоиграющая. Поэтому её решили структурировать сразу и по-максимуму. Что бы производители различных гаджетов не придумывали свои протоколы, которые потом будут не совместимы. Отсюда и сложность. Уже на первом этапе в протокол BLE попытались втиснуть всё что только было возможно. И не важно пригодится это в последствии или нет. Кроме того, предусмотрели возможность расширения списка устройств на будущее.

Давайте взглянем на картинку, где нарисована схема протокола BLE. Он состоит из нескольких слоев. Самый нижний, физический слой (PHY) отвечает за радиоканал устройства. Link Layer(LL) содержит всю последовательность байтов в передаваемом сообщении. В прошлых статьях мы изучали именно его. Host Controller Interface (HCI) — это протокол обмена между слоями или микросхемами BLE, если Controller и Host реализованы на разных чипах. За формирование пакетов, деление на кадры, контролем ошибок и сборку пакетов отвечает Logical Link Control and Adaptation Protocol (L2CAP). За шифрование пакетов отвечает Security Manager Protocol (SMP). Профиль общего доступа (GAP) отвечает за первоначальный обмен данными между устройствами, для определения «Who is who». К нему так же относятся scanning и advertising. В этой статье я остановлюсь на двух оставшихся частях протокола — GATT и ATT. GATT является надстройкой над ATT, поэтому они сильно переплетены.

Для упрощения повествования, я бы хотел обратиться к аналогии. Я её где то слышал и хотел бы поддержать. Представьте себе BLE устройство в качестве книжного шкафа с несколькими полками. Каждая полка — это отдельная тематика. К примеру, у нас есть полки с фантастикой, математикой, энциклопедиями. На каждой полке стоят книги с указанной темой. А в некоторых книгах есть даже бумажные закладки с записями. Кроме того, у нас есть небольшой бумажный каталог всех книг. Если помните школьные библиотеки — это узкий ящик с бумажными карточками. При такой аналогии шкаф — это профиль нашего устройства. Полки — это сервисы, книги — характеристики, а каталог — это таблица атрибутов. Закладки в книгах — это дескрипторы, о которых я так же расскажу позже, более подробно.

Все, кто разрабатывал устройства, знает, что во многих проектах есть похожие куски кода. Дело в том, что многие устройства имеют сходный функционал. К примеру, если устройства работают от аккумуляторов, то проблема зарядки и контроля их уровня, будет одинаковой. То же касается и датчиков. Собственно, объектно-ориентированный подход в программировании «предоставляет возможность создавать объекты, которые соединяют свойства и поведения в самостоятельный союз, который затем можно многоразово использовать». На мой взгляд, в BLE была предпринята попытка похожего подхода. Группой Bluetooth Special Interest Group (SIG) были разработаны профили. Устройства от разных производителей, имеющие одинаковые профили, должны без труда работать друг с другом. Профили в свою очередь состоят из сервисов, а сервисы из характеристик, дополняемых дескрипторами. В общем случае это может выглядеть так:

Для примера, рассмотрим схему профиля heart rate monitor (фитнес браслет). Он состоит из двух сервисов и нескольких характеристик. Из неё сразу становится понятна иерархия профиля. Характеристика контрольной точки сбрасывает общий подсчет расходов калорий в ноль.

Для того, чтобы мы могли однозначно обращаться к элементам профиля (сервисам, характеристикам и дескрипторам) нужно все их как то пронумеровать. Для этой цели вводят такое понятие как Universally Unique ID (UUID) или Универсальный уникальный идентификатор. В скобках каждой строки как раз и указан UUID. И здесь есть одна особенность. Для UUID решили использовать код длиной 16 и 128 бит. Зачем, спросите вы? В протоколе BLE всё подчинено сохранению энергии. Поэтому размерность в 16 бит вполне разумна. Вряд ли в ближайшем будущем будет создано больше 65тыс. уникальных сервисов и характеристик. На данный момент всё что могли, уже посчитали (помните откуда это — «он и вас посчитал» :-)) Пронумерованные элементы профилей, сервисов, характеристик и дескрипторов вы можете посмотреть по ссылкам.

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

Сбилась стрелка на тонометре как сделать

Однако, я думаю, все помнят историю с 4-мя байтами IPv4 адреса в интернете. Сначала думали что хватит, а теперь всё никак не перейдем на IPv6 адресацию. Что бы не повторять этой ошибки и дать простор шаловливым ручкам самодельщиков, SIG сразу решила ввести ещё и 128-ми битные UUID. Это лично мне напоминает нелицензионный диапазон 433МГц, который был дан на откуп всевозможным Кулибиным от радиоканала. В нашем случае, на откуп был отдан 128-ми битный идентификатор сервисов и характеристик. Это означает что мы, для своих сервисов и устройств, можем использовать практически любое 128 битное значение. Всё равно вероятность придумать одинаковый UUID стремится к нулю.

На самом деле, короткие 16-ти битные UUID имеют своё расширение до 128-ми битного значения. В спецификации это расширение называется Bluetooth Base UUID и имеет значение 00000000-0000-1000-8000-00805F9B34FB. Если, к примеру, 16-ти битный UUID аттрибута имеет значение 0x1234, то эквивалентный ему 128-ми битный UUID будет иметь значение 00001234-0000-1000-8000-00805F9B34FB. И даже приводится соответствующая формула:

128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

Откуда взялось это магическое число, мне не известно. Если кто нибудь из читателей знает — пусть напишет в комментариях (Пользователь с ником Sinopteek уже сделал это. Смотрите комментарии). Что касается придумывания 128-ти битных UUID, то в принципе можно воспользоваться специальным генератором, который сделает это за вас.

ATTы GATTы.

Собственно дальше начинается самое интересное. Я напомню, что ATT основан на клиентском-серверном отношении. Сейчас мы рассматриваем устройство сервера. Он содержит такую информацию, как значения датчиков, состояние выключателя света, данные о местоположении и т.д. Теперь, когда все «участники нашего парада» пронумерованы, надо как то их размещать в памяти устройства. Для этого мы помещаем их в таблицу, которая называется таблицей атрибутов. Запомните это хорошенько. Это самое сердце BLE. Именно его мы и будем рассматривать в дальнейшем. Теперь каждую строчку мы будем называть аттрибутом. Эта таблица находится в глубине стека и, как правило, мы не имеем к ней прямого доступа. Мы её инициализируем и к ней обращаемся, но что там происходит внутри, от нас скрыто за семью печатями.

Рассмотрим картинку из спецификации, однако перед этим, хочу сразу обратить внимание на частую путаницу в терминах, а именно в дескрипторах. Роль дескриптора — дополнить описание характеристики. Когда надо расширить её возможности, тогда и применяют дескрипторы. Они так же являются аттрибутами, и так же, наравне с сервисами и характеристиками, располагаются в таблице аттрибутов. Мы подробно разберем их во второй части статьи. Однако иногда дескрипторами называют номер строки в таблице аттрибутов. Это надо иметь ввиду. Мы же, что бы не путаться, будем для этих целей использовать термин «указатель атрибута».

Значение аттрибута — это собственно его значение, простите за тавтологию. Если тип аттрибута это строка, то значением аттрибута может быть например слоган «Hello World . ». Если тип аттрибута это «сервисная декларация», то значением его является сам сервис. А иногда это информация о том, где найти другие атрибуты и их свойства.

Как это выглядит

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

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

Как я похудел на велосипеде

В верхней части каждой группы мы всегда имеем атрибут объявления сервиса. Его тип всегда равен 0x2800, а указатель зависит от того, сколько атрибутов уже присутствует в таблице. Его разрешения всегда доступны только для чтения, без какой-либо проверки подлинности или авторизации. Об этих понятиях мы поговорим чуть позже. Значение — это еще один UUID, определяющий, что это за служба. В Таблице значение равно 0x180D, что определяется Bluetooth SIG как сервис частоты сердечных сокращений.

Вслед за объявлением сервиса, следует объявление характеристики. По форме оно аналогично объявлению сервиса. Его UUID всегда имеет значение 0x2803, а разрешения так же всегда доступны только для чтения без какой-либо проверки подлинности или авторизации. Давайте посмотрим на поле Attribute Value, которое включает некоторые данные. Оно всегда содержит указатель, UUID и набор свойств. Эти три элемента описывают последующее объявление значения характеристики. Указатель естественным образом обозначает место объявления значения характеристики в таблице атрибутов. UUID описывает, какой тип информации или значения мы можем ожидать. Например, значение температуры, состояние выключателя света или какое-либо другое произвольное значение. И наконец свойства, которые описывают, как можно взаимодействовать с характеристическим значением.

Тут нас поджидает ещё один подводный камень. Он связан с разрешениями аттрибутов и свойствами характеристик. Давайте мы посмотрим на картинку свойств битового поля из спецификации.

Главное отличие разрешения аттрибутов от свойств характеристик состоит в том, что первые относятся к серверам, а вторые к клиентам. У сервера может быть разрешено чтение значения характеристики, но при этом стоять требование аутентификации или авторизации. Поэтому при запросе клиентом свойств характеристики, мы получим, что чтение разрешено. Но при попытке чтения получим ошибку. Поэтому можно смело говорить о приоритете разрешений над свойствами. Знание о том, какие разрешения есть у аттрибута, мы, со стороны клиента, получить не можем.

Дескриптор

В случае характеристики измерения частоты сердечных сокращений, в нашей таблице, объявление значения характеристики сопровождается объявлением дескриптора. Дескриптор — это атрибут с дополнительной информацией о характеристике. Существует несколько видов дескрипторов. О них мы подробно поговорим во второй части этой статьи. Сейчас же мы коснемся только дескриптора конфигурации характеристик клиента (Client Characteristic Configuration Descriptor — CCCD). Он имеет UUID равную 0х2902. При помощи этого дескриптора клиент имеет возможность включить на сервере индикацию или нотификацию. Разница между ними небольшая, но всё таки есть. Нотификация не требует подтверждения в получении со стороны клиента. Индикация же этого требует, хотя она и происходит на уровне GATT, не доходя до уровня приложения. Зачем так, спросите вы? Увы, это мне не ведомо. Скажу лишь, что специалисты Nordic-а рекомендуют использовать нотификацию. Тем более, что проверка целостности пакета (при помощи CRC) происходит в обоих случаях.

Заключение

В конце статьи я хотел бы сказать вот о чем. Последняя таблица несколько запутанна. Однако я остановился на ней из-за того, что она приводится в статье, на которую я опираюсь. Во второй части своей статьи я намерен углубиться в спецификацию BlueTooth 4.0. Там нас ждут более корректные схемы и рисунки. В третьей части, я хотел бы разобрать лог, полученный при помощи программы Wireshark от одного из гаджетов и увидеть «в живую» всю ту теорию, которую мы с вами изучаем.

How to find the UUID of serial port Bluetooth device?

I want to receive data from the serial port bluetooth device to android phone. But i don’t know the UUID of that device how to find the UUID of that device?

7 Answers 7

Extending what pwc said about the UUID being 0x1101, this is the 16 bit version of the UUID as far as I can tell. I could not work out how to instantiate an UUID with a 16 bit UUID. But as this post says you can do it by:

private static final UUID MY_UUID = UUID.fromString(«00001101-0000-1000-8000-00805f9b34fb»);

This worked for me to connect to a serial bluetooth module I bought from Deal Extreme

If the device is using serial port profile, then yes, it is simply:

For other pre-defined options, see the list of pre-defined UUIDs as listed in javax.bluetooth :

The UUID for the SPP Serial Port service is defined by the Bluetooth SIG to be 0x1101.

Just open your device in adb shell type sdptool and browse you got your device UUID

In the Android Bluetooth API documentation:

From API level 15, you can query the supported features (UUIDs) of the remote device, use the method on the BluetoothDevice object obtained in the search:

you can get Device UID by simple Calling

Linked

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Как найти UUID последовательного порта устройства Bluetooth?

Я хочу получать данные с устройства последовательного порта Bluetooth на телефон Android. Но я не знаю UUID этого устройства, как найти UUID этого устройства?

7 ответов

Насколько я могу судить, расширение того, что pwc говорит о том, что UUID равен 0x1101, это 16-битная версия UUID. Я не мог понять, как создать экземпляр UUID с 16-битным UUID. Но, как говорится в этом посте, вы можете сделать это: