как узнать uuid блютуз устройства
Передача данных по Bluetooth между Android и Arduino
В статье Arduino и Bluetooth был рассмотрен один из способов передачи информации между Android-устройством и ПК по Bluetooth-соединению. Там же, в двух словах было упомянуто и Android-устройство, но для принятия и передачи данных использовался Android Bluetooth терминал. Однако, для реальных устройств необходима полноценная программа (не будем же мы управлять тем же роботом из терминала. ), написанная для Android’а. В данной статье хотелось бы затронуть тему программного обеспечения для работы с Bluetooth, с применением языка Java и среды разработки Eclipse. Установка и настройка Eclipse хорошо описана в этой статье: Android и Arduino. Программное обеспечение.
Arduino
Я буду использовать Bluetooth модуль HC-06, однако для других модулей HC-04, HC-05 и т.п. схема подключения такая же (за исключением светодиода). Плата Arduino Nano V3.
Для наглядности, к плате Arduino я подключил красный светодиод, к 12-пину, но можно использовать и встроенный LED (обычно 13 пин).
Скетч для Arduino следующий:
Программа работает очень просто. После запуска или сброса устройства, в последовательный порт выводится сообщение с предложением нажать 1 или 0. В зависимости от нажатой (принятой) цифры светодиод будет загораться или гаснуть. В общем программа абсолютно такая же как и в статье: Arduino и Bluetooth.
Теперь, что касается Android. Мы рассмотрим два примера, в первом мы будем передавать данные от Android-устройства к arduino, а во втором примере мы рассмотрим двусторонний обмен данными между устройствами. Второй пример сложнее и в части понимания и по сложности кода, т.к. используются потоки (thread).
Мы будем использовать Java код, с явным указанием MAC-адреса устройства, к которому мы будем подключаться. Т.к. если делать интерфейс обнаружения Bluetooth-устройств, их выбора, подключения к ним и т.д., то код будет очень большой и для некоторых читателей труднопонимаем. Но для тех, кому интересно могут посмотреть стандартный пример Bluetooth Chat.
Узнать MAC-адрес можно к примеру в программе для Android’а: Bluetooth Terminal:
Нас интересует устройство BOLUTEK (наш модуль HC-06, подключенный к Arduino), его MAC адрес: 00:15:FF:F2:19:4C. Его и надо будет в дальнейшем прописать в программе.
В файле манифеста необходимо прописать 2 строки разрешения работы с Bluetooth:
Сам код главного активити:
Данный код найден на одном из зарубежных блогов и слегка модернизирован. Как видно выше, на кнопки мы вешаем обработчики событий. При нажатии на кнопку передается строка 1 или 0 через sendData() в буфер Bluetooth адаптера. Полный проект с исходными кодами приведен ниже. Для работы программы, необходим Android не ниже версии API15, т.е. 4.0.3 и выше.
А вот здесь пришлось повозиться. Дело в том, что в Android’е для приема данных от какого-либо устройства необходимо создавать отдельный фоновый поток, чтобы у нас не зависало основное активити. Для этого мы задействуем thread и все данные будут приниматься в отдельном потоке.
На окно главного активити мы добавим новый элемент TextView, который будет служить для отображения принятых данных от Arduino. Сам java-код главного активити я постарался хорошо прокомментировать, чтобы сделать его удобочитаемым:
К статье прилагаются скомпилированные файлы для Android: bluetooth1.apk и bluetooth2.apk, а также исходники проекта для Arduino IDE и Eclipse
Android: Как работают UUID для Bluetooth?
Я не понимаю, что означает UUID Bluetooth. Обозначают ли UUID протоколы (например, RFCOMM )? Если да, почему методы createRfcommSocketToServiceRecord() требуют UUID, когда они задают rfcomm прямо в их именах? Почему образец кода BluetoothChat имеет, по-видимому, произвольный, жестко запрограммированный UUID?
Мой вопрос возникает из-за того, что по этому вопросу я получаю исключение нулевого указателя, когда устройства, работающие под управлением 4.0.4, пытаются подключиться (к внешнему, не-андроидному устройству) с использованием отражения. Однако решение этого вопроса для меня не работает. UUID muuid = device.getUuids()[0].getUuid(); Вызывает исключение.
Редактирование : я решил эту проблему путем UUID.fromString(«00001101-0000-1000-8000-00805f9b34fb»); UUID для службы последовательного порта в соответствии с этим ответом (используя UUID.fromString(«00001101-0000-1000-8000-00805f9b34fb»); ).
Я также озадачен тем, почему мне нужно предоставить UUID для создания незащищенного сокета createInsecureRfcommSocketToServiceRecord(), используя createInsecureRfcommSocketToServiceRecord(), но не используя метод отражения.
Может ли кто-нибудь исправить меня?
Обычно это представляет собой обычную службу (протокол), поддерживаемую Bluetooth-устройством.
При создании собственного сервера rfcomm (с помощью listenUsingRfcommWithServiceRecord ) вы должны указать свой собственный UUID, чтобы подключенные к нему клиенты могли его идентифицировать; Это одна из причин, почему createRfcommSocketToServiceRecord требует параметр UUID.
В противном случае некоторые общие службы имеют одинаковый UUID, просто найдите тот, который вам нужен, и используйте его.
Устройства, такие как датчики здравоохранения, могут предоставлять услугу, заменяя первые восемь цифр на предопределенный код. Например, устройство, которое предлагает соединение RFCOMM, использует короткий код: 0x0003
Таким образом, телефон Android может подключаться к устройству, а затем использовать протокол обнаружения служб (SDP), чтобы узнать, какие услуги он предоставляет (UUID).
Во многих случаях вам не нужно использовать эти фиксированные UUID. В случае создания чат-приложения, например, один Android-телефон взаимодействует с другим телефоном Android, который использует одно и то же приложение и, следовательно, тот же UUID.
Таким образом, вы можете установить произвольный UUID для своего приложения, используя, например, один из множества случайных генераторов UUID в Интернете ( например ).
UUID аналогичен понятию номеров портов в Интернете. Однако разница между Bluetooth и Интернетом заключается в том, что в Bluetooth номера портов динамически назначаются сервером SDP (протокол обнаружения служб) во время выполнения, где каждому UUID присваивается номер порта. Другие устройства будут запрашивать сервер SDP, который зарегистрирован под номером зарезервированного порта, о доступных услугах на устройстве, и он будет отвечать различными службами, отличающимися друг от друга, будучи зарегистрированными в разных UUID.
UUID – это всего лишь число. Он не имеет никакого значения, кроме того, что вы создаете на стороне сервера приложения для Android. Затем клиент подключается с использованием того же UUID.
Например, на стороне сервера вы можете сначала запустить uuid = UUID.randomUUID () для генерации случайного числа, например fb36491d-7c21-40ef-9f67-a63237b5bbea. Затем сохраните этот, а затем жесткий код, который будет в вашей программе прослушивания следующим образом:
Ваша программа на Android-сервере будет прослушивать входящие запросы с этим UUID следующим образом:
BluetoothSocket socket = server.accept ();
Подводя итог: UUid используется для однозначной идентификации приложений. Каждое приложение имеет уникальный UUid
Итак, используйте один и тот же UUid для каждого устройства
Как узнать uuid блютуз устройства
В этом руководстве будет на примере показано создание устройства Bluetooth Low Energy (BLE) с использованием сервиса BLE (перевод, оригинал см. в [1]).
Примечание: новые термины и сокращения см. в Словарике [8].
[Оборудование и ПО]
Чтобы выполнить это руководство, понадобится следующее:
• nRF52 DK Development Kit [9].
• Среда разработки (IDE) SEGGER Embedded Studio или Keil V5.xx.
• Установленное приложение nRF Connect.
• nrfjprog.
• SDK V15.0.0 [10] **ВНИМАНИЕ! Это руководство написано для SDK V15.0.0.**.
• Для nRF52 DK используется SoftDevice V6.0.0 (S132).
• Файлы примеров можно скачать на github.
Могут быть использованы другие киты, отладочные платы и версии ПО, однако в этом списке приведено то, что использовалось автором [1].
Примечание: если испытываете трудности с самостоятельной закачкой перечисленных материалов, то воспользуйтесь ссылкой [11].
Это руководство создано как естественное продолжение руководства [3]. Поэтому рекомендуется, хотя и не обязательно, предварительно изучить это руководство. Необходимы также базовые знания по использованию Keil, nRF Connect и nrfjprog, как загружать приложение в память микроконтроллера Вашей платы разработчика. Ознакомьтесь с руководством [4], чтобы научиться пользованию оборудованием и скомпилировать Ваше первое приложение BLE.
Если столкнулись с проблемами, то посетите форум Nordic DevZone (devzone site:nordicsemi.com), просмотрите документацию в Infocenter, и ознакомьтесь с документацией на Ваш кит разработчика.
[Базовая теория]
Generic Attribute Profile (GATT). Bluetooth Core Specification определяет GATT следующим образом: «Профиль GATT определяет структуру, по которой осуществляется обмен данными профиля устройства BLE. Эта структура определяет такие базовые элементы, как службы (services) и характеристики (characteristics), используемые в профиле».
Другими словами, это набор правил, описывающих как объединять, представлять и передавать данные, используя BLE. См. [5], для дополнительной информации прочитайте Bluetooth Core Specification v4.2, Vol. 3, Part G. Возможно, это покажется непростым чтением, но в конце концов должно окупиться.
Services. Стандарт Bluetooth (Bluetooth Core Specification) определяет понятие службы (или сервиса) следующим образом: «Служба (service) это набор данных и связанных с ними алгоритмов поведения, предназначенных для реализации некоторой функции или свойства устройства. [. ] Определение службы может содержать в себе […] обязательные характеристики и не обязательные (опциональные) характеристики».
Другими словами, характеристика это место для некоторого значения параметра плюс информация о его представлении. Также в характеристике инкапсулируются параметры безопасности (security), единицы измерения (units) и другие метаданные, касающиеся характеристики.
Аналогией может служить склад, заставленный шкафами для хранения данных, где каждый шкаф имеет ряд выдвижных ящиков. Профиль GATT это как бы помещение склада. Шкафы это службы, а выдвижные ящики это характеристики, где хранится разная информация. У некоторых из этих ящиков могут быть замки, ограничивающие доступ к их информации.
Представим для примера монитор сердцебиения (Heart Rate Monitor, HRM). Наручные часы с такой функцией обычно будут использовать как минимум 2 службы:
1. Heart rate service. В этой службе инкапсулируются 3 характеристики:
a. Обязательная характеристика Heart Rate Measurement, где будет храниться частота пульса.
b. Опциональная характеристика Body Sensor Location, показывающая место положение тела человека.
c. Условная характеристика Heart Rate Control Point, точка контроля частоты пульса.
2. Battery service. В этой службе инкапсулируется одна характеристика:
a. Обязательная характеристика Battery Level, уровень заряда батареи.
Если продолжить аналогию: склад находится в маленьком офисе, где есть 2 заполненных комнаты. В первая комната используется бухгалтерами. Выдвижные ящики в шкафах содержат финансовую информацию по деловой активности, рассортированную по датам. Ящики закрыты на замок, открыть который могут только лишь бухгалтеры и высшее руководство. Вторая комната отведена под отдел кадров, и шкафы в ней содержат сведения по сотрудникам, рассортированные в алфавитном порядке. Здесь выдвижные ящики также снабжены замками, открывать которые могут только кадровики и высшее руководство. Каждый сотрудник в компании знает о местонахождении этих комнат, и что в них находится, но только некоторые сотрудники имеют право на доступ к находящейся под замком информации. Это гарантирует эффективность, безопасность и организованность бизнеса.
Universally Unique ID (UUID). С аббревиатурой UUID Вы будете часто встречаться в мире BLE. Это уникальный номер, используемый для идентификации служб, характеристик и дескрипторов, также известных как атрибуты. Эти ID передаются по радио, благодаря чему периферийное устройство информирует центральное устройство о предоставляемых службах. Для экономии времени передачи и занимаемой памяти в nRF52 существует 2 вида UUID: 16-битный и 128-битный.
16-bit UUID. Это короткий тип идентификатора. Предопределенной службе Heart Rate Service, например, присвоен UUID 0x180D, и одной из из её внутренних характеристик Heart Rate Measurement присвоит UUID 0x2A37. 16-разрядные UUID эффективным по занимаемой памяти и экономии энергии, однако они предоставляют относительно узкий диапазон уникальных значений; Вы можете передать по радио только лишь предопределенные заранее идентификаторы Bluetooth SIG UUID. Из-за этого появилась необходимость во втором типе UUID, благодаря которому можно будет также передавать свои собственные UUID-ы.
128-bit UUID. Это длинный UUID, который иногда называют уникальным идентификатором, специфичным для производителя (vendor specific UUID). Этот тип UUID нужно использовать, когда Вы хотите создать свои собственные службы и характеристики. 128-битный UUID может выглядеть примерно так: 4A98xxxx-1CC4-E7C1-C757-F1267DD021E8, и он называется базовым UUID (base UUID). Здесь четыре буквы x представляют поле, куда можно вставить свой собственный 16-битный ID для своих пользовательских служб и характеристик, и использовать их так же, как и предопределенные UUID. Таким способом можно сохранить базовый UUID в памяти только один раз, забыть о нем, и работать только со своими 16-битными ID, как с обычными. Вы можете генерировать base UUID-ы с помощью утилиты nRFgo Studio.
Интересный факт касательно UUID: не существует базы данных, гарантирующей отсутствие совпадений UUID, однако если Вы сгенерируете два случайных 128-разрядных UUID, то вероятность примерно
3e-39, что они будут одинаковыми (это примерно 1 шанс из 340,000,000,000,000,000,000,000,000,000,000,000,000).
[Пример]
Загрузите код примера с GitHub (также см. папку github архива [11]). Этот проект основан на шаблоне примера, который есть в SDK, но для упрощения из него вырезан весь код, который не является строго необходимым для наших целей. Чтобы скомпилировать проект, скопируйте его загруженные файлы в папку «nrf5x-ble-tutorial-service», находящуюся в каталоге «где_находится_ваш_SDK\examples\ble_peripheral». Если встретились с проблемами при компиляции, ищите подсказку на форуме Nordic devzone.
Если используете IDE Keil, откройте файл проекта «nrf52-ble-tutorial-service.uvprojx», который находится в папке arm5_no_packs. Если используете IDE SEGGER, то откройте файл «nrf52-ble-tutorial.services.emProject», который находится в папке ses. Автор внедрил SEGGER Real-Time Terminal (RTT) в проект, чтобы можно было легко понять, что происходит в программе. Подробнее про отладку с помощью текстовых сообщений терминала см. руководство [6].
Если кликнуть Connect, то увидите следующее:
Как можно увидеть, мы пока что ничего не делали, но уже существует 2 обязательных сервиса, предварительно настроенных для нас:
Generic Access service. У этой службы UUID 0x1800, и три обязательных характеристики:
1. Характеристика UUID 0x2A00: Device name (имя устройства).
2. Характеристика UUID 0x2A01: Appearance (внешний вид).
3. Характеристика UUID 0x2A04: Peripheral Preferred Connection Parameters (предпочтительные параметры подключения к устройству).
Generic Attribute service. У этой службы UUID 0x1801, и одна опциональная (не обязательная) характеристика:
1. Характеристика UUID 0x2A05: Service Changed (служба изменена).
Служба Generic Access Service содержит общую информацию об устройстве BLE. Вы можете распознать характеристику с именем устройства “OurService”. Вторая характеристика хранит значение внешнего вида (appearance), и в нашем случае мы в это значение ничего не установили, поэтому значение показывается просто как 0x0000. Третья характеристика хранит различные параметры, используемые для установки соединения. Вы можете найти эти значения в определениях #defines проекта, они называются MIN_CONN_INTERVAL, MAX_CONN_INTERVAL, SLAVE_LATENCY и CONN_SUP_TIMEOUT. Во врезке ниже дано короткое объяснение этих параметров.
Для связи BLE параметры соединения управляют частотой, с которой может осуществляться обмен данными между периферийным и центральным устройствами после установления связи между ними. Этими параметры согласовываются между периферийным и центральным устройствами в процессе установки связи. Параметры установки соединения следующие:
Интервал соединения (Connection Interval, CI). Центральное устройство устанавливает параметр CI, когда впервые устанавливается соединение между центральным и периферийным устройством. Периферийное устройство задает минимальное и максимальное значения, которые служат желательными пределами интервала соединения для периферийного устройства. Большинство центральных устройств будут использовать CI по умолчанию, и обычно будут игнорировать максимальные и минимальные значения, заданные периферийным устройством. Периферийному устройству обычно нужно генерировать запрос обновления параметров соединения (Connection Parameter Update Request) через некоторое время после установки соединения BLE, чтобы попытаться поменять CI для соответствия необходимому диапазону. Центральное устройство может как принять, так и отклонить этот запрос, и ответить интервалом соединения, который может как попадать, так и не попадать в указанный периферийным устройством диапазон. Если периферийное устройство примет это значение, то будет использоваться новый CI. Интервал соединения должен быть в диапазоне между 7.5 мс и 4000 мс.
Slave Latency (SL). Латентность (задержка) реакции периферийного устройства. Путем установки ненулевого значения SL периферийное устройство может несколько раз не отвечать на запрос данных со стороны центрального устройства. Однако если у периферийного устройства есть данные для отправки, то оно в любой момент может принять решение отправить данные. Это позволяет периферийному устройству спать в течение долгого времени, если у него нет данных для отправки, но в то же время быстро посылать данные при необходимости. Примерами такого поведения могут служить клавиатура и мышь, которым нужно спать как можно дольше, когда нет данных для отправки, но и сохранять при этом низкую латентность (и для мыши: малый интервал соединения CI), когда необходимо.
В зависимости от используемой для разработки платформы могут быть специфические рекомендации или требования по значениям этих параметров. Для iOS, компания Apple предоставляет документ «Accessory Design Guidelines for Apple Devices» (https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf), в котором, помимо всего прочего, есть правила по этим параметрам.
Просто так базу данных GATT на лету менять нельзя.
По факту, если Вы поменяли базу данных, то должны для противоположного участника соединения разрешить и показать изменение характеристики службы. Причина в том, что противоположной стороне разрешено кешировать структуру базы данных, и любые изменения в этой структуре требуют повторного (частичного) считывания структуры базы данных (rediscovery). Если не отправить оповещение Service Changed, то это приведет к нарушению спецификации. Также изменение в базе данных обычно должно использоваться только тогда, когда Вы хотите повторно инициализировать устройство с новым профилем.
[Наш первый сервис BLE]
В примере автор добавил два файла: our_service.h и our_service.c. В них декларированы некоторые пустые функции и маленькая структура, с которых нам было бы проще всего начать работу. Автор также использовал nRFgo Studio для создания 128-битного base UUID, определенного как BLE_UUID_OUR_BASE_UUID. Поищите шаги (STEP 1-6) в файлах проекта, и Вы найдете те места, куда нужно добавить свой код.
Примечание: Nordic считает приложение nRFgo Studio устаревшим, его рекомендуется использовать только для nRF8001 и nRF24. Для nRF52 рекомендуется использовать nRFConnect.
Шаг 1: декларация структуры сервиса. Прежде всего нам нужно место для хранения всех данных и информации, относящихся к нашему сервису (службе), и для этого будет использоваться структура ble_os_t. Как Вы можете видеть, эта структура в файле our_service.h сейчас содержит только один элемент. Значение service_handle это число, идентифицирующее эту отдельную службу, и оно назначается кодом библиотек SoftDevice. Декларированием переменной m_our_service типа ble_os_t в модуле main.c можно будет передавать эту структуру в различные функции, получая полный контроль над нашей службой.
Шаг 2: инициализация сервиса. В модуле main.c уже есть функция services_init(), из которой мы будем вызывать нашу функцию our_service_init(). В качестве параметра она берет указатель на структуру ble_os_t, так что убедитесь, что он указывает на нашу переменную m_our_service:
Шаг 3: добавление идентификаторов UUIDs в таблицу стека BLE. Найдите определение our_service_init() в модуле our_service.c. Как можно увидеть, там почти нет кода, и сейчас нам предстоит кое-что туда добавить. Сначала нужно создать UUID для нашей службы. Поскольку мы делаем кустарную (пользовательскую) службу, то будем использовать определенный 128-битный base UUID вместе с 16-битным UUID. Введите следующий код:
Этот код создает 2 переменные. Одна хранит 16-битный UUID службы, и другая хранит base UUID. Пятая стока добавляет наш специфичный для производителя UUID (vendor specific, об этом говорит сокращение ‘vs’) к таблице идентификаторов UUID в стеке BLE. Краткое описание того, что делает эта функция, можно найти во врезке ниже, также см. справочную систему nRF52 SDK. Шестая строка делает быструю проверку на случай возникновения ошибки. Хорошая практика по такому принципу оформлять код для всех вызовов API-функций, которые возвращают некоторый код ошибки, что позволяет формализовать отладку программы.
Использование vendor specific UUID в основном заключается в выполнении двух шагов:
1. Добавьте ваш собственный базовый 128-битный идентификатор (base UUID) в стек с помощью функции sd_ble_uuid_vs_add(). Сохраните возвращенное этой функцией значение в параметре p_type вызова этой функции.
2. Установите тип всех переменных ble_uuid_t, которые должны использовать это базовое значение, возвращенное из sd_ble_uuid_vs_add(). Когда Вы установите это поле в свой собственный тип вместо BLE_UUID_TYPE_BLE, значение будет использоваться поверх custom base UUID, заданного Вами, вместо базового Bluetooth SIG.
Своим вызовом функция sd_ble_uuid_vs_add() добавит Ваш base UUID в внутреннему списку базовых UUID кода SoftDevice, и вернет индекс таблицы для этого UUID в поле p_uuid_type. Когда этот тип позже будет использоваться в ble_uuid_t later, код SoftDevice сможет найти этот базу в той же самой таблице, используя этот индекс.
Ниже приведен небольшой кусок псевдокода, показывающий основные моменты этой схемы.
Шаг 4: добавление службы. Теперь все готово к инициализации нашего сервиса. Сразу после кода, введенного на шаге 3, добавьте следующее:
Функция sd_ble_gatts_service_add() принимает 3 параметра. В первом мы указываем, что хотим получить первичную (primary) службу. Как альтернативная опция здесь может быть указано BLE_GATTS_SRVC_TYPE_SECONDARY, что создаст вторичную (secondary) службу. Вторичная служба используется редко, однако иногда применяют вложение служб друг в друга (вторичная служба логически находится внутри первичной). Второй параметр это указатель на UUID службы, который мы создали. Путем передачи этой переменной в sd_ble_gatts_service_add() наша служба может быть уникально идентифицирована стеком BLE. Третья переменная, переданная в функцию это указатель на то место, куда должен быть сохранен числовой дескриптор service_handle этой уникальной службы. Функция sd_ble_gatts_service_add() создаст таблицу, содержащую наши службы, и service_handle это просто индекс, указывающий на нашу определенную службу в этой таблице.
Функция our_service_init() должна теперь выглядеть примерно так:
Если открыт Segger RTT, то также будет видна некоторая информация о ходе выполнения программы, которую выводят строки SEGGER_RTT. Если эти строки раскомментированы, то при запуске приложения Вы сможете увидеть, какие переменные используются в службе. Например, дескриптор службы (service handle) установлен в 0x000E. Если поместить курсор на нашу службу, то будет видно и это значение дескриптора:
Изначально главное устройство (Central) будет соединяться с периферийным устройством (Peripheral), по своему усмотрению назначая параметры соединения. После того, как соединение установлено, Peripheral может отправить для Central запрос на обновление параметров соединения (connection parameter update request), и скорее всего Central ответит обновлением параметров соединения. Однако по спецификации стандарта Bluetooth устройство Central не обязан отвечать на запрос обновления параметров соединения, и может просто его игнорировать. Принятое обновление от Central не обязательно будет тем, что запрашивало периферийное устройство. Если периферийное устройство не может принять обновление параметра от Central, то оно может выбрать отключение (разрыв соединения с Central).
Во время процесса согласования параметров соединения к Central посылаются следующие параметры, как пример:
Для интервала соединения установлен желаемый минимум и максимум, так что для устройства Central доступна некоторая гибкость в выборе интервала.
Если периферийное устройство получает обновление параметров соединения от Central, которое неприемлемо, то оно может отправить другой запрос на обновление параметров соединения к Central, чтобы заново договориться о параметрах, которые могли бы быть допустимы. Количество отправляемых запросов на обновление параметров соединения определяется константой MAX_CONN_PARAMS_UPDATE_COUNT, как это сделано в примере ble_app_hrs из SDK. Макрос FIRST_CONN_PARAMS_UPDATE_DELAY определяет, сколько времени должно пройти от начала оповещения до отправки первого запроса обновления параметров соединения, и NEXT_CONN_PARAMS_UPDATE_DELAY определяет, через какое время должны обновляться последующие запросы на обновление параметров соединения.
В примере ble_app_hrs запрос обновления параметров инициируется запуском таймера в приложении с идентификатором m_sensor_contact_timer_id. Таймер инициализируется вызовом conn_params_init() в функции main, и скорее всего запускается в обработчике события соединения.
Advertising. В предыдущем руководстве [3] мы обсуждали разные аспекты пакета оповещения (advertising), и сейчас время для оповещения с нашим base UUID. Поскольку у base UUID длина 16 байт, а advertising-пакет уже содержит некоторые данные, в самом этом пакете не будет достаточно места. Поэтому вместо этого нам нужно поместить его в пакет ответа сканирования (scan response).
Шаг 5: декларация переменной, где хранится UUID нашей службы. Перед функцией advertising_init() в модуле main.c декларируйте переменную, хранящую идентификатор нашей службы:
BLE_UUID_OUR_SERVICE, как Вы уже знаете, это UUID нашей службы, и BLE_UUID_TYPE_VENDOR_BEGIN показывает, что он является частью vendor specific base UUID. Если более конкретно, то BLE_UUID_TYPE_VENDOR_BEGIN это индекс, указывающий на наш base UUID в таблице идентификаторов UUID, которую мы инициировали в our_service_init().
Шаг 6: декларация и создание экземпляра scan response. Добавьте UUID к пакету scan response следующим образом:
Теперь процедура advertising_init() должна выглядеть примерно так:
Снова скомпилируйте и загрузите программу в память чипа. Теперь наше устройство должно отображаться в списке MCP распознанных устройств вот так:
Теперь Вы знаете, как настроить и создать свою первую базовую службу в устройстве BLE. Если нужно добавить в устройство больше служб, то можно просто реплицировать функцию our_service_init(), и таким образом определить больше идентификаторов UUID для служб.
Однако это только половина пути. Предстоит еще разобрать характеристики, которые должны хранить Ваши данные. Эта тема рассматривается в руководстве [7].