enable bluetooth page scan что это значит
Как проводить сканирования Bluetooth на Android
В этой статье поговорим про сканирования Bluetooth на Android. И покажем, как это сделать двумя способами, в одном из которых нашей целью будет дальнейшая работа с устройством; второй способ будет заключаться в том, чтобы отследить информацию о найденных девайсах, узнать их тип, адрес и прочее.
Сканирование стандартным методом
Данную процедуру будем выполнять стандартными функциями, встроенными в ваше мобильное устройство. Как упомянули раньше, этот метод разрешит нам выполнять действия с найденными аппаратами, то есть, ваш, например, смартфон будет взаимодействовать с другим устройством.
Для того чтобы произвести такой поиск, выполните следующие действия:
После этих действий должно отобразиться окно, в котором будет список найденных устройств. Если же в списке нет ни одного устройства, нужно вручную просканировать находящиеся вблизи вас девайсы.
После чего должен отобразиться список с вариантами действий над выбранным гаджетом. Могут встретиться такие варианты, как:
Сканирование информации
Этот метод стоит использовать для вычисления данных об неизвестном устройстве, находящимся рядом с вами. А именно: узнать тип девайса, адрес и даже местоположение относительно вас.
Учтите, что программа имеет только англоязычную локализацию.
Рассмотрим, как работает данное приложение:
После запуска сразу начнется сканирование новых устройств. Все найденные аппараты будут показаны на дисплее с информацией о них.
По каждому аппарату будут предоставлены такие данные:
Android Bluetooth Low Energy (BLE) – готовим правильно, часть #3 (read/write)
Содержание
Часть #3 (read/write), вы здесь
В предыдущей статье мы подробно поговорили о подключении/отключении BLE устройств. Эта статья о чтении и записи характеристик, а также включении-выключении уведомлений.
Чтение и запись характеристик
Многие разработчики, которые начинают работать с BLE на Android, сталкиваются с проблемами чтения/записи BLE характеристик. На Stackoverflow полно людей, предлагающих просто использовать задержки… Большинство таких советов неверные.
Есть две основные причины проблем:
Одновременно может быть запущена только одна операция. Нужно дождаться выполнения текущей операции, и затем, запускать следующую. В исходном коде BluetoothGatt есть блокирующая переменная, которая при запуске операции устанавливается и при вызове колбека сбрасывается. Google забыла про это упомянуть в документации… (Прим. переводчика: речь идет о mDeviceBusy и mDeviceBusyLock здесь).
Первая причина, на самом деле, не является проблемой, такова природа BLE. Асинхронное программирование это распространенная штука, используется, например, при сетевых вызовах. Однако вторая причина раздражает и требует специального подхода.
Когда приходит результат чтения/записи, переменная mDeviceBusy сбрасывается в false снова:
Используем очередь
Мы добавляем новый экземпляр Runnable в очередь при выполнении команды. Ниже пример чтения характеристики (readCharacteristic):
Обратите внимание, мы используем метод peek() для получения объекта Runnable из очереди, чтобы можно было повторить запуск позже. Этот метод не удаляет объект из очереди.
Результат чтения будет отправлен в ваш колбек:
Мы завершаем команду completedCommand() после обработки нового значения. Это помогает избежать одновременный вызов другой команды и состояния гонки.
Теперь мы готовы завершить команду, убираем Runnable из очереди через вызов poll() и запускаем следующую из очереди:
Запись характеристик
Чтение характеристики достаточно простая операция, а запись требует дополнительных пояснений. Для выполнения записи нужно предоставить характеристику, массив байтов и тип записи. Существует несколько типов записи, важные для нас это:
WRITE_TYPE_DEFAULT (вы получите ответ от устройства, например, код завершения);
WRITE_TYPE_NO_RESPONSE (никакого ответа от устройства не будет).
Использовать тот или иной тип зависит от вашего устройства и характеристики (иногда она поддерживает оба типа записи, иногда только один конкретный тип).
В Android каждая характеристика имеет дефолтный тип записи, который определяется при ее создании. Ниже фрагмент кода из исходников Android, где определяется тип:
Перед записью можно проверить характеристику, поддерживает ли она нужный тип записи:
Я рекомендую всегда явно указывать тип записи и не полагаться на дефолтные настройки выбранные Android!
Итак, запись массива байтов bytesToWrite в характеристику выглядит так:
Включение/выключение уведомлений
Кроме самостоятельного чтения и записи характеристик, вы можете включить или отключить уведомления от устройств. При включении уведомления, устройство сообщит вам о появлении новых данных и отправит их автоматически.
Для включения уведомлений нужно сделать две вещи в Android:
Почему 1 или 2? Потому что «под капотом» Bluetooth стека есть Уведомление и Индикация. Полученное Уведомление не подтверждаются стеком Bluetooth, а Индикация наоборот – подтверждается стеком. При использовании Индикации, устройство будет точно знать, что данные получены и может их, например, удалить из локального хранилища. С точки зрения Android приложения нет разницы: в обоих случаях вы просто получите массив байтов и Bluetooth стек уведомит устройство об этом, если вы используете Индикацию. Итак, 1 включает уведомления, 2 – индикацию. Чтобы выключить их, записываем 0. Вы должны самостоятельно определить, что записать в дескриптор CCC.
В iOS метод setNotify() делает всю работу за вас. Ниже пример, как сделать тоже самое на Android, там сначала идут проверки входных параметров, определяется что записать в дескриптор и, наконец команда отправляется в очередь:
Чтобы узнать из какой характеристики пришло уведомление – используйте метод isNotifying() :
Лимиты на установку уведомлений
К сожалению, нельзя включить столько уведомлений, сколько хочешь. Начиная с Android-5 лимит равен 15. В более старых версиях он был равен 7 или даже 4. Большинство смартфонов поддерживают 15 уведомлений. Не забывайте отключать их, если они вам больше не нужны, чтобы не исчерпать лимит.
Проблемы с потоками
Итак, мы научились читать/писать характеристики, включать/выключать уведомления, а значит готовы использовать это в реальном проекте. Я думаю, что устройства BLE можно разделить на две категории:
Простые устройства. Например, термометр, который использует официальный Bluetooth Health Thermometer сервис. Такие устройства легко использовать, вы просто включаете уведомления и данные начинают поступать. Здесь мы используем только операции чтения характеристики, запись не нужна;
Сложные устройства. Это может быть любое устройство, но обычно все они используют свой внутренний протокол обмена данными. Часто эти протоколы не спроектированы под BLE, а просто транслируют внутренний последовательный протокол в BLE, где одна характеристика используется для отправки данных, а другая для приема. Сложность в том, что вам требуется знать большое количество команд для работы с устройством: авторизация, обновление пользовательских параметров, параметров самого устройства, получение сохраненных данных и т.д.
Простые устройства обычно не создают проблем с потоками, для сложных – следует работать внимательно. Чтение, запись и уведомления в этом случае будут чередоваться и могут мешать друг другу, особенно если у вас устройство с высокой частотой передачи данных (30Hz или около).
Типичная проблема с потоками выглядит так:
вы отправляете событие в свою собственную очередь для обработки
запускается обработку полученных данных
в это время приходит новое уведомление и перезаписывает предыдущее значение в BluetoothGattCharacteristic
если ваша обработка данных медленная, вы потенциально теряете значение из первого уведомления.
Причины такого поведения:
как только сообщение доставлено, Android будет отправлять следующее (если оно есть). Посколько обработка данных отправляется в другой поток, текущий освобождается и Android продолжит доставку уведомлений;
Очевидно, что нужно всегда работать с копией массива байтов. Получили данные, сразу же делаем копию и работаем с ней.
Ниже пример, который использует такую тактику:
Другие рекомендации по работе с потоками
Есть несколько дополнительных рекомендаций по работе с BLE на Android. Поскольку стек BLE в основном асинхронный, у нас есть мульти-поточная обработка задач.
Android использует потоки:
При сканировании (результаты приходят в main поток);
Вызове колбеков BluetoothGattCallback (выполняются в потоках Binder );
Я рекомендую следующее:
Освобождайте потоки Binder как можно быстрее и никогда не блокируйте их;
Если хотите запустить Handler на main потоке:
Следующая статья: сопряжение (bonding)
В этой статье мы разобрались с чтением и записью характеристик, включением и выключением уведомлений/нотификаций. В следующей статье, мы детально изучим процесс спряжения с устройством (bonding).
Не терпится поработать с BLE? Попробуйте мою библиотеку Blessed for Android. Она использует все подходы из этой серии статей и упрощает работу с BLE в вашем приложении.
Android Bluetooth Low Energy (BLE) — готовим правильно, часть #1 (scanning)
Содержание
Часть #1 (scanning), вы здесь.
Могу точно сказать – это было сложней, чем представлял, мне пришлось приложить немало усилий для стабильной работы под Android. Я изучил много статей в свободном доступе, некоторые оказались ошибочными, многие были очень полезными и помогли в деле. В этой серии статей я хочу описать свои выводы, чтобы вы не тратили уйму времени на поиски как я.
Особенности работы BLE под Android
Google документация по BLE очень общая, в некоторых случаях нет важной информации или она устарела, примеры приложений не показывают, как правильно использовать BLE. Я обнаружил лишь несколько источников, как правильно сделать BLE. Презентация Stuart Kent дает замечательный материал для старта. Для некоторых продвинутых тем есть хорошая статья Nordic.
Производители делают изменения в Android BLE стеке или полностью заменяют на свою реализацию. И надо учитывать разницу поведения для разных устройств в приложении. То что прекрасно работает на одном телефоне, может не работать на других! В целом не все так плохо, например реализация Samsung сделана лучше собственной реализации от Google!
В Android есть несколько известных (и неизвестных) багов которые должны быть обработаны, особенно в версиях 4,5 и 6. Более поздние версии работают намного лучше, но тоже имеют определенные проблемы, такие как случайные сбои соединения с ошибкой 133. Подробнее об этом ниже.
Не претендую на то, что я решил все проблемы, но мне удалось выйти на «приемлемый» уровень. Начнем со сканирования.
Сканирование устройств
Перед подключением к устройству вам нужно его просканировать. Это делается при помощи класса BluetoothLeScanner :
… дополнительные данные, см. документацию по ScanResult здесь.
Настраиваем фильтр для сканирования
Вообще можно передать null вместо фильтров и получить все ближайшие устройства, иногда это полезно, но чаще требуются устройства с определенным именем или набором UUID сервисов.
Сканирование устройств по UUID сервиса
Используется если вам необходимо найти устройства определенной категории, например мониторы артериального давления со стандартным сервисным UUID: 1810. При сканировании устройство может содержать в Advertisement data UUID сервис, который характеризует это устройство. На самом деле эти данные ненадежные, фактически сервисы могут не поддерживаться, или подделываться Advertisement data данные, в общем тут есть творческий момент.
Прим. переводчика: одно из моих устройств со специфичной прошивкой, вообще не содержало список UUID сервисов в Advertisement data, хотя все остальные прошивки этого устройства работали ожидаемо.
Пример сканирования службы с артериальным давлением:
Обратите внимание на короткий UUID (например 1810 ), он называется 16-bit UUID и является частью длинного 128-bit UUID (в данном случае 00001810-000000-1000-8000-000-00805f9b34fb ). Короткий UUID это BASE_PART длинного UUID, см. спецификацию здесь.
Сканирование устройств по имени
Поиск устройств использует точное совпадение имени устройства, обычно это применяется в двух случаях:
поиск конкретного устройства
Сканирование устройств по MAC-адресам.
Обычно применяется для переподключения к уже известным устройствам. Обычно мы не знаем MAC-адрес девайса, если не сканировали его раньше, иногда адрес печатается на коробке или на корпусе самого устройства, особенно это касается медицинских приборов. Существует другой способ повторного подключения, но в некоторых случаях придется еще раз сканировать устройство, например при очистке кеша Bluetooth.
Вероятно вы уже поняли, что можно комбинировать в фильтре UUID, имя и MAC-адрес устройства. Выглядит неплохо, но на практике я не применял такое. Хотя может быть вам это пригодится.
Настройка ScanSettings
ScanSettings объясняют Android как сканировать устройства. Там есть ряд настроек, которые можно задать, ниже полный пример:
ScanMode
Безусловно, это самый важный параметр. Определяет метод и время сканирования в Bluetooth стеке. Такая операция требует много энергии и необходим контроль над этим процессом, чтобы не разрядить батарею телефона быстро. Есть 4 режима работы, в соответствии с руководством Nordics и официальной документацией:
Callback Type
Эта настройка контролирует как будет вызываться callback со ScanResult в соответствии с заданными фильтрами, есть 3 варианта:
Match mode
Настройка того, как Android определяет «совпадения».
Number of matches
Параметр определяет сколько advertisement данных необходимо для совпадения.
Report delay
Важно: есть известный баг для Samsung S6 / Samsung S6 Edge, когда все результаты сканирования имеют один и тот же RSSI (уровень сигнала) при задержке больше нуля.
Кеширование Android Bluetooth стека
Очистка кеша
Bluetooth кеш, как и любой другой, не существует вечно, есть 3 ситуации, когда он очищается:
Выключение и включение системного переключателя Bluetooth
Очистка данных приложения (в ручном режиме в настройках телефона)
Это достаточно неудобный момент для разработчиков, потому что телефон часто перезагружается, пользователь может включать-выключать самолетный режим. Есть еще различия между производителями телефонов, например на некоторых телефонах Samsung, кеш не очищался при выключении Bluetooth.
Это значит, что нельзя полагаться на данные об устройстве из BT кеша. Есть небольшой трюк, он поможет узнать закешировано ли устройство или нет:
Это важный момент, если нужно подключиться к устройству позже, не сканируя его. Подробнее об этом позже.
Непрерывное сканирование?
Вообще хорошая практика – избегать непрерывного сканирования потому что, это очень энергоемкая операция, а пользователи любят, когда батарея их смартфона работает долго. Если вам действительно нужно постоянное сканирование, например при поиске BLE-маячков, выберите настройки сканирования с низким потреблением и ограничивайте время сканирования, например когда приложение находится только на переднем плане (foreground), либо сканируйте с перерывами.
Плохая новость в том, что Google в последнее время ограничивает (неофициально) непрерывное сканирование:
с Android 7 запуск и останов сканирования более 5 раз за 30 секунд временно отключает сканирование.
Непрерывное сканирование в фоне
Google значительно усложнил сканирование на переднем плане. Для фонового режима вы столкнетесь с еще большими трудностями! Новые версии Android имеют лимиты на работу служб в фоновом режиме, обычно после 10 минут работы, фоновый сервис прекращает свою работу принудительно. Посмотрите возможные решения этой проблемы:
Проверка разрешений (permissions)
Есть еще несколько важных моментов, прежде чем мы закончим статью. Для начала сканирования нужны системные разрешения (permissions):
Убедитесь, что все разрешения одобрены, или запросите их у пользователя. Разрешение ACCESS_COARSE_LOCATION Google считает «опасным» и для него требуется обязательное согласие пользователя.
Прим. переводчика, в моем проекте для корректной работы с BLE потребовалось еще 2 разрешения: ACCESS_FINE_LOCATION (для API ACCESS_BACKGROUND_LOCATION обсуждение на Stackoverflow.
В итоге полный список разрешений включая версию Android10:
Заключение
Мы научились запускать сканирование BLE устройств с учетом жизненного цикла Activity (Fragment / Service), использовать фильтры и различные настройки сканирования, также узнали все нужные разрешения (permissions) для удачного запуска сканирования и особенности работы Android-Bluetooth кеша. В следующей статье мы погрузимся глубже в процесс подключения и отключения к устройствам.
Создайте сканер Bluetooth с Android API Bluetooth
Bluetooth стал очень популярной технологией, особенно на мобильных устройствах. Это технология для обнаружения и передачи данных между соседними устройствами. В наши дни практически каждое современное мобильное устройство обладает возможностями Bluetooth. Если вы хотите создать интерфейс приложения с другим устройством с поддержкой Bluetooth, от телефонов до динамиков, вы должны знать, как использовать Bluetooth API Android.
В этом уроке мы будем создавать приложение, аналогичное встроенному приложению Bluetooth в настройках Android. Он будет включать в себя следующие функции:
1. Включение Bluetooth
Прежде чем мы сможем включить Bluetooth на устройстве Android, нам нужно запросить необходимые разрешения. Мы делаем это в манифесте приложения. Разрешение BLUETOOTH позволяет нашему приложению подключаться, отключаться и передавать данные с другого устройства Bluetooth. Разрешение BLUETOOTH_ADMIN позволяет нашему приложению обнаруживать новые устройства Bluetooth и изменять настройки Bluetooth устройства.
2. Получение списка сопряженных устройств
На этом этапе мы сканируем сопряженные устройства Bluetooth и отображаем их в виде списка. В контексте мобильного устройства устройство Bluetooth может быть:
3. Откройте для себя близлежащие устройства Bluetooth
Вот и все. Мы закончили наш сканер Bluetooth.
4. Подключение к устройству
Например, предположим, что вы создаете приложение для чата, которое использует Bluetooth для общения с другими соседними пользователями. Чтобы найти других пользователей для чата, вам нужно поискать другие устройства с установленным приложением чата. Для этого мы будем искать UUID в списке сервисов соседних устройств. Использование UUID для прослушивания и принятия подключений Bluetooth автоматически добавляет этот UUID в список служб телефона или в протокол обнаружения служб.
В следующем фрагменте кода показано, как подключиться к данному BluetoothDevice :
BLE под микроскопом
BLE под микроскопом. Часть 1
Зачем придумали BLE
Как только люди научились передавать информацию без помощи проводов, встала задача передачи данных, используя устройство с батарейным питанием. Проблема в том, что ему должно помогать другое устройство, которое будет постоянно либо прослушивать эфир, либо передавать данные. Проблема возникает в том случае, если и приемник и передатчик имеют батарейное питание. В этом случае приходит на помощь BlueTooth Low Energy (BLE). Он впервые вошел в протокол BlueTooth 4.0. На данный момент уже вышла спецификация BlueTooth 5.0, однако мы будем рассматривать в основном формат BlueTooth 4.0, иногда указывая нововведения для формата 5.0. В качестве одного из устройств обычно выступает смартфон, а второго — батарейный гаджет. Андроид поддерживает BLE с версии 4.3.
Для передачи и приема данных необходима энергия, поэтому поднимают скорость передачи данных, что бы в единицу времени успеть передать больше информации. Для этого в BLE принята скорость передачи информации в 1 Mbit/c. Однако не только скорость передачи данных важна. Самым важным в BLE является то, что устройства связи умеют переходить в синхронный режим работы. Другими словами, устройства спят 99% времени, потом просыпаются на очень короткое время, обмениваются информацией и опять засыпают. Однако перед тем как войти в этот режим, необходимо пройти процедуру синхронизации. Для этого существует режим «advertising». Его мы рассмотрим позднее. А перед тем как погрузится в описание протокола BLE, хотелось бы затронуть тему инструментальных средств, для работы с протоколом BLE.
Инструменты
Для того чтобы разобраться во всем многообразии посылок и запросов нам необходимы инструментальные средства. С их помощью мы смогли бы увидеть содержимое посылок и проконтролировать механизм взаимодействия между устройствами. Для этих целей мы будем использовать nRF51822 Development Dongle (PCA10000), программу сниффера и, для отображения результатов, хорошо известную всем сисадминам программу «Wireshark».
Программы бесплатные, но достать сам донгл может оказаться проблемой. Однако без инструментария, заниматься разработкой таких сложных устройств будет весьма проблематично. На первом этапе может помочь программа на андроиде «nRF Connect».
Она позволяет сканировать эфир, находить и разбирать посылки как присоединяемых, так и не присоединяемых устройств. У Nordic-a есть и ещё инструменты для разработки BLE устройств, но нам будет достаточно этих. На российском рынке присутствует представитель компании Nordic – фирма «Rutronik» (rutronik24.com, rutronik.com). Через её представителей можно приобрести необходимые микросхемы, отладочные платы и т.д. Кроме того, в интернете имеется форум, на котором представители фирмы отвечают на вопросы разработчиков.
Сначала вкратце поговорим о том, как пользоваться нашими инструментами. Вставим в разъем USB наш донгл и запустим программу ble_sniffer_win. Мы увидим следующее окно.
Если донгл увидит BLE устройства, то внизу появится информация о них. В данном случае, в эфире присутствует одно устройство с именем «TestBLE». Так же отображается его уровень сигнала, MAC адрес и то, что этот адрес является случайным (random). Забегая вперед, хочется заметить, что здесь кроется один из подводных камней для разработчиков. Некоторые телефоны (LG G3S, Samsung S6) работают только с устройствами, MAC адреса которых зарегистрированы (public).
У сниффера есть два режима работы. Если мы нажмем кнопку «w» на клавиатуре, то запустится программа «Wireshark». Сниффер будет сканировать три рекламных канала и выдавать информацию обо всех устройствах объявления. Если мы сначала нажмем цифру на клавиатуре, такую же, как напротив интересующего нас устройства, то включится другой режим работы. В нем сниффер будет отслеживать трафик только одного выбранного устройства, причем как на каналах объявления, так и на рабочих каналах
Используя «Wireshark», легко получить всю информацию о посылке. Программа состоит из трех окон. Сверху отображаются все принятые посылки, во втором окне – детальная информация о выбранном пакете, а в третьем окне отображается сам фрейм. В свою очередь, во втором окне имеется три блока информации. В самом верхнем – временные значения выбранного фрейма, во втором (Nordic BLE sniffer meta) – общая информация о фрейме, такие как уровень сигнала, частотный канал и некоторые другие. Самым интересным для нас является третий блок информации (Bluetooth Low Energy Link Layer). В нем можно посмотреть разбор самого фрейма. В дальнейшем мы будем говорить именно об этом блоке информации. Сначала мы разберем формирование рекламных пакетов.
Advertising
Посмотрим на рисунок ниже. На нем показаны распределения каналов по частотам для BLE. Рекламные каналы — это 37 (2402Мгц), 38 (2426Мгц) и 39 (2480Мгц) каналы. Такое распределение рекламных каналов выбрано не случайно. Во-первых, рекламные каналы попадают между каналами Wi-Fi (1, 6, 11 каналы), что позволяет даже при малом уровне мощности, быть услышанными другими устройствами. Во-вторых, когда мы разносим рекламные каналы далеко друг от друга, мы получаем гарантированную доставку сообщения. Это связано с интерференцией сигнала в помещениях. Известно, что в результате отражения радиосигналов от стен, может получиться ситуация, когда приемник и передатчик не слышат друг друга. Однако в нашем случае, когда передача рекламных пакетов идет последовательно на трех разных каналах, максимально удаленных друг от друга по частоте, этот эффект отсутствует.
Рассмотрим теперь формат самого пакета advertising. В спецификации длина данных измеряется в октетах. Для нас это байты. Самым первым байтом идет преамбула. Она состоит из чередующихся нулей и единиц. Это нужно для синхронизации передатчика и приемника. Следом за преамбулой передаются четыре байта адреса доступа(Access Address). После него идет пакет данных (PDU). В спецификции 4.0 максимальная длина PDU составляет 39 байт, а в версии 5.0 длина пакета данных увеличена до 257 байт. В конце каждого рекламного пакета идут три байта контрольной суммы (CRC).
Здесь надо заметить, что Access Address служит для того, что бы устройства понимали, для кого предназначен BLE пакет. Это своеобразный код доступа. Если этот код доступа не знаком устройству, то пакет игнорируется. На всех рекламных каналах, в отличии от рабочих, он одинаков (0x8E89BED6), поэтому все устройства на каналах объявления видят друг друга.
Рассмотрим теперь формат блока данных PDU. В самом начале пакета PDU идет заголовок длинной 16 бит. В нем содержится тип пакета, флаги TxAdd, RxAdd, а так же длина всего поля PDU в байтах. RFU – это зарезервированные поля. Для спецификации 4.0 это выглядит так:
Для спецификации 5.0 увеличена длина поля Payload до 255 байт, а так же добавлены новые поля в заголовок:
Поле TxAdd как раз и отвечает за то, как будет видеться MAC адрес устройства. Если это поле равно единице, то МАС устройства будет виден как random. Рассмотрим теперь какие бывают типы advertising пакетов. На рисунке приведен их список для спецификации 4.0. В формате 5.0 их число увеличено, но мы будем рассматривать то, что есть в обоих форматах.
ADV_IND – это ненаправленные пакеты, которые рассылают устройства, готовые к присоединению. Большинство гаджетов при рассылке рекламных пакетов используют именно их.
ADV_DIRECT_IND — направленные рекламные пакеты присоединяемых устройств. Присоединять и обмениваться данными с ними может только конкретное устройство с заранее известным МАС адресом.
ADV_NONCONN_IND – рекламные пакеты, которые рассылают не присоединяемые устройства. Это маяки (beacon). Обычно они служат для получения какой-либо справочной информации. Например, при входе в магазин могут информировать об акциях. Кроме того, измеряя уровень сигналов от маяков и зная карту их расположения, можно осуществить автоматическое позиционирование внутри помещений. Это актуально для автоматизированных складов.
SCAN_REQ, SCAN_RSP, CONNECT_REQ – пакеты, которыми обмениваются присоединяемое устройство и телефон в процессе установления синхронного соединения. Эти пакеты и сам процесс присоединения мы рассмотрим во второй части статьи.
ADV_SCAN_IND – эти пакеты рассылает не присоединяемое устройство, которое может предоставить дополнительную информацию в ответ на запрос при сканировании.
Во второй части статьи мы рассмотрим различные режимы работы BLE устройств, а так же механизм «присоединения» устройства к телефону и переход на рабочие частоты.